Questa pagina mostra come utilizzare al meglio Config Controller durante il funzionamento ad alta disponibilità o per la gestione di risorse in più regioni Google Cloud.
Config Controller viene eseguito in una singola regione, in modo che possa tollerare l'errore di una zona di disponibilità, ma nel caso in cui un'intera regione un errore, Config Controller perde la disponibilità. Esistono due diversi strategie per gestire i guasti a livello di regione e la scelta dipende da ciò che in caso di errore di una regione:
Se apporti modifiche alla configurazione in risposta a un errore a livello di regione, crea una seconda istanza di Config Controller.
Se non apporti modifiche alla configurazione, utilizza una singola istanza Config Controller.
Comprendi gli scenari di errore
Config Controller utilizza un cluster GKE a livello di regione. Sebbene il cluster a livello di regione possa tollerare l'errore di una singola zona in regione, il cluster non è disponibile se si verificano errori in più zone nella regione.
In caso di errore dell'istanza di Config Controller, la configurazione attuale di Google Cloud le risorse rimangono nello stato attuale. Tuttavia, anche se le tue applicazioni sono è ancora in esecuzione, non puoi modificarne la configurazione quando Config Controller non è disponibile. Questo vale per le risorse nella stessa regione risorse in altre regioni che gestisci da Config Controller nella regione non disponibile.
Poiché non puoi riconfigurare le risorse nella stessa regione, se un server l'errore interessa le risorse Google Cloud esistenti in Config Controller non puoi riparare quelle risorse.
Dato che non puoi riconfigurare le risorse in altre regioni, un errore in una regione ha influenzato la tua capacità di apportare modifiche in un'altra.
Sono possibili anche altri scenari di errore. Ad esempio, se configuri Config Sync per eseguire il pull da un provider Git esterno, dovresti prendere in considerazione le modalità di errore del provider Git. Potresti non essere in grado di effettuare la configurazione perché non puoi eseguire il push delle modifiche al provider Git. Oppure se Config Sync non può leggere da Git, pertanto le modifiche a Git non verranno applicate al cluster e quindi Config Connector non li applica. Tuttavia, l'errore regionale spesso lo scenario di errore più importante, perché vengono generalmente non correlati all'errore di Config Controller.
Usa un singolo cluster per la disponibilità a livello regionale
In molti scenari, in caso di errore di una regione non eseguiresti alcuna riconfigurazione. In questo caso, potresti scegliere di accettare che un errore a livello di regione causi la causa la configurazione del piano di controllo per rendere non disponibile.
Ad esempio, se operi solo in una singola regione, potrebbero non essere presenti utile riconfigurazione che puoi fare in caso di errore della regione. Analogamente, un database single point of failure in una singola regione, potresti non essere in grado di per il ripristino fino a quando quella regione non avrà luogo. Per le applicazioni che non necessitano massima disponibilità, questa situazione può rappresentare un ragionevole compromesso rispetto ai costi e alla complessità.
L'individuazione dell'istanza di Config Controller nella stessa regione ti offre una destino: Config Controller è disponibile purché la tua regione principale disponibili. Localizzazione dell'istanza Config Controller in una regione diversa può essere una buona scelta, anche se ora devi pensare a potenziali in due regioni, eviterai il relativo errore della configurazione con l'errore della regione principale.
In alternativa, se hai una configurazione ridondante in più regioni, il sistema potrebbe allontanarsi automaticamente dalle aree in cui si verificano errori. Anche in questo caso, potrebbe non voler fare la riconfigurazione in caso di errore di una regione. In questo caso, potresti scegli una singola istanza Config Controller.
Esegui manualmente il failover a una seconda istanza Config Controller
Ti consigliamo di riconfigurare una regione in caso di errore in modo da risolvere l'errore. Puoi anche continuare a configurare le risorse in ad altre regioni, anche se l'istanza di Config Controller si trova in regione con errori. In questo caso, consigliamo di utilizzare un secondo Config Controller in una seconda regione.
Sebbene sia sconsigliato, è possibile eseguire due istanze Config Controller configurazioni identiche. Entrambe le istanze si assicurano di leggere dallo stesso repository Git e applicare le stesse modifiche a Google Cloud. Tuttavia, numerosi casi limite rendere questa configurazione inaffidabile. Le due istanze Config Controller osservano il repository Git in momenti leggermente diversi; potrebbero tentare di applicare leggermente diverse della tua configurazione Google Cloud. Più di uno gli autori di scrittura attivi in Google Cloud aumentano le probabilità di imbattersi in quote o limiti di frequenza. Un numero ridotto di risorse Config Connector non idempotente, e richiedono un'attenzione particolare, come discusso nel resto di questa sezione. Pertanto, consiglia di evitare di avere due cluster Config Controller attivi nella riconciliazione.
Consigliamo invece di fare in modo che, se la regione che esegue Config Controller un errore, poi esegui un altro Config Controller regione. La nuova istanza di Config Controller deve essere configurata in modo identico alla prima, leggendo dallo stesso repository Git. Preparazione uno script per visualizzare e configurare l'istanza di Config Controller in questo scenario. Quando crei la nuova istanza Config Controller, Config Sync legge e applica lo stato desiderato da Git a Kubernetes; Config Connector sincronizza lo stato desiderato in Google Cloud.
Ci sono due aspetti a cui prestare attenzione in questa situazione:
Se il primo cluster Config Controller è ancora in esecuzione o viene avviato in esecuzione al momento del ripristino della prima regione, potrebbe tentare di applicare il valore precedente in Google Cloud. Se puoi arrestare il cluster Config Controller prima di avviare un secondo cluster Config Controller, per evitare questo potenziale conflitto.
Non tutte le risorse di Config Connector possono essere riapplicate senza problemi da Git. Per l'elenco delle risorse che richiedono un'attenzione particolare, vedi risorse con restrizioni legate all'acquisizione. In particolare, consigliamo di fare attenzione a
Folderrisorse e evitando risorseIAMServiceAccountKey(ad esempio, utilizzando GKE Workload Identity).
Un'istanza Config Controller per regione
Se vuoi evitare che un'istanza di Config Controller in una regione interessi in un'altra regione, valuta l'opportunità di eseguire per regione, in cui ogni istanza di Config Controller gestisce di risorse in quella regione.
Questa configurazione è utilizzabile, ma non è una delle nostre opzioni consigliate per i seguenti motivi:
Alcune risorse coprono più regioni (ad esempio Cloud DNS), il che rende strategia limitata.
In genere, avere un cluster Config Controller nella stessa regione incontra il problema di guasto correlato: si vuole riconfigurare le risorse esattamente quando un errore a livello di regione influisce sul Config Controller quella regione.
Devi suddividere le risorse di Config Connector per regione.
Config Controller non è attualmente disponibile in tutte le regioni.
Configurazione diretta delle risorse Google Cloud
In circostanze eccezionali, puoi apportare modifiche direttamente alle risorse Google Cloud sottostanti, senza utilizzare Git o Config Connector. Config Connector cerca di correggere eventuali "deviazioni", quindi se il tuo Config Controller è ancora in esecuzione, Config Connector prenderà in considerazione le modifiche apportate manualmente di essere "deviazione" e tenta di ripristinarle.
Tuttavia, se arresti l'istanza di Config Controller o se la regione viene offline, può essere una misura alternativa.
Quando l'istanza di Config Controller si recupera, Config Connector probabilmente tenterà per annullare le modifiche manuali. Per evitare questa situazione, puoi rendere modifiche in Git per le modifiche apportate manualmente.