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.
Questa pagina è rivolta ad amministratori, architetti e operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base e pianificano le esigenze di capacità e infrastruttura. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
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 vuoi apportare modifiche alla configurazione in risposta a un errore regionale, crea una seconda istanza di Config Controller.
Se non apporti modifiche alla configurazione, utilizza una singola istanza Config Controller.
Informazioni sugli scenari di errore
Config Controller utilizza un cluster GKE a livello di regione. Sebbene il cluster regionale possa tollerare l'errore di una singola zona in una regione, il cluster non è più disponibile se si verificano errori in più zone della 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 applicazioni sono ancora in esecuzione, non puoi modificarne la configurazione quando Config Controller non è disponibile. Questo vale per le risorse nella stessa regione e per le risorse in altre regioni che gestisci da Config Controller nella regione non disponibile.
Poiché non puoi ricollegare le risorse nella stessa regione, se un errore regionale colpisce le risorse Google Cloud esistenti nella regione del controller di configurazione, non puoi ripararle.
Poiché non puoi nemmeno riconfigurare le risorse in altre regioni, un errore in una regione ha ora influito sulla tua capacità di apportare modifiche in un'altra regione.
Sono possibili anche altri scenari di errore. Ad esempio, se configuri la sincronizzazione della configurazione in modo da estrarre i dati da un fornitore Git esterno, devi prendere in considerazione le modalità di errore del fornitore Git. Potresti non essere in grado di apportare modifiche alla configurazione perché non puoi inviare le modifiche al provider Git. In alternativa, se Config Sync non può leggere da Git, le eventuali modifiche a Git non vengono applicate al cluster e quindi Config Connector non le applica. Tuttavia, l'errore regionale è spesso lo scenario di errore più importante, perché gli altri scenari di errore non sono tipicamente correlati all'errore del controller di configurazione.
Utilizza un singolo cluster per la disponibilità a livello di regione
In molti scenari, in caso di errore di una regione non eseguiresti alcuna riconfigurazione. In questo caso, puoi scegliere di accettare che un errore regionale causi la mancata disponibilità del piano di controllo della configurazione.
Ad esempio, se operi solo in una singola regione, potrebbero non esserci 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à.
Se posizioni l'istanza di Config Controller nella stessa regione, la sorte è condivisa: Config Controller è disponibile finché è disponibile la regione principale. Anche l'ubicazione dell'istanza del controller di configurazione in una regione diversa può essere una buona scelta. Anche se ora devi considerare i potenziali errori in due regioni, eviti l'errore correlato del piano di controllo 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, potresti non voler eseguire la riconfigurazione in caso di errore di una regione. In questo caso, potresti scegli una singola istanza Config Controller.
Esegui il failover manuale a una seconda istanza di Config Controller
Ti consigliamo di riconfigurare una regione in caso di errore in modo da risolvere l'errore. Potresti anche voler continuare a configurare le risorse in altre regioni, anche se l'istanza di Config Controller si trova in una regione con problemi. In questo caso, ti consigliamo di utilizzare una seconda istanza di Config Controller in una seconda regione.
Anche se è sconsigliato, è possibile eseguire due istanze Config Controller configurazioni identiche. Entrambe le istanze cercano 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 di Config Controller osservano il repository Git in momenti leggermente diversi e potrebbero tentare di applicare versioni leggermente diverse della configurazione di 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.
Ti consigliamo invece, se la regione in cui è in esecuzione il tuo Config Controller non funziona, di eseguire un altro Config Controller in un'altra 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 di Config Controller, Config Sync legge e applica lo stato desiderato da Git a Kubernetes, mentre Config Connector sincronizza lo stato desiderato con Google Cloud.
In questa situazione, devi fare attenzione a due aspetti:
Se il primo cluster di Config Controller è ancora in esecuzione o inizia a funzionare quando la prima regione si ripristina, potrebbe tentare di applicare lo stato precedente a Google Cloud. Se puoi arrestare il cluster del Controller di configurazione nella prima regione prima di avviare un secondo cluster del Controller di configurazione, puoi 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 la federazione delle identità per i carichi di lavoro per GKE).
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 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 di Config Controller nella stessa regione comporta il problema di errori correlati: vuoi ricollegare le risorse esattamente quando un errore regionale interessa Config Controller in quella regione.
Devi suddividere le risorse di Config Connector in base alla regione.
Config Controller non è attualmente disponibile in tutte le regioni.
Configurazione diretta delle risorse Google Cloud
In circostanze eccezionali, potresti apportare modifiche direttamente alle risorse Google Cloud sottostanti, senza passare da Git o Config Connector. Config Connector tenta di correggere eventuali "deviazioni", pertanto, se l'istanza di Config Controller è ancora in esecuzione, considera le modifiche apportate manualmente come "deviazioni" e tenta di annullarle.
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 viene ripristinata, Config Connector tenterà probabilmente di annullare le modifiche manuali. Per evitare questa situazione, puoi rendere modifiche in Git per le modifiche apportate manualmente.