Configura Config Controller per l'alta disponibilità

Questa pagina mostra come utilizzare al meglio Config Controller quando operi con servizi ad alta disponibilità o gestisci 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 sulle attività di esempio 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, quindi può tollerare l'errore di una zona di disponibilità, ma se si verifica un errore in un'intera regione, Config Controller perde la disponibilità. Esistono due diverse strategie per gestire un errore regionale e la tua scelta dipende da cosa faresti se una regione non funziona:

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.

Se l'istanza di Config Controller non va a buon fine, le risorse Google Cloud esistenti rimangono nello stato corrente. 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 Config Sync 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, non esegui alcuna riconfigurazione se una regione non funziona. 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, potrebbe non essere possibile eseguire alcuna riconfigurazione utile in caso di guasto della regione. Allo stesso modo, se hai un database con un singolo punto di errore in una singola regione, potresti non essere in grado di eseguire il recupero finché la regione non viene ripristinata. Per le applicazioni che non richiedono la massima disponibilità assoluta, questa situazione può essere un compromesso ragionevole rispetto a costi e 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 multiregionale, il sistema potrebbe evitare automaticamente le regioni in cui si sono verificati errori. Anche in questo caso, potrebbe non essere consigliabile eseguire la riconfigurazione se una regione non funziona. In questo caso, puoi scegliere una singola istanza di Config Controller.

Esegui il failover manuale a una seconda istanza di Config Controller

Se una regione non funziona, ti consigliamo di eseguire una reimpostazione per risolvere il problema. 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 non è consigliato, due istanze di Config Controller possono essere eseguite con configurazioni identiche. Entrambe le istanze cercano di leggere dallo stesso repository Git e applicare le stesse modifiche a Google Cloud. Tuttavia, numerosi casi limite rendono 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ù autori attivi su Google Cloud aumentano le probabilità di riscontrare quote o limiti di frequenza. Anche un numero limitato di risorse di Config Connector è non idempotente e richiede un'attenzione particolare, come discusso nel resto di questa sezione. Pertanto, sconsigliamo di avere due cluster di controller di configurazione in cui la riconciliazione sia attiva.

Se la regione in cui è in esecuzione il tuo Config Controller non funziona, ti consigliamo 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. In questo scenario potrebbe essere utile preparare in anticipo uno script per avviare e configurare l'istanza di Config Controller. 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 cose:

  • 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, consulta le risorse con limitazioni relative all'acquisizione. In particolare, ti consigliamo di prestare attenzione alle risorse Folder ed evitare le risorse IAMServiceAccountKey (ad esempio, utilizzando la federazione delle identità per i carichi di lavoro di GKE).

Un'istanza di Config Controller per regione

Se vuoi evitare che un'istanza di Config Controller in una regione influisca su un'altra regione, puoi anche valutare la possibilità di eseguire un'istanza di Config Controller per regione, in cui ogni istanza di Config Controller gestisce le risorse nella regione in questione.

Questa configurazione è utilizzabile, ma non è una delle opzioni consigliate per i seguenti motivi:

  • Alcune risorse si estendono su più regioni (ad esempio Cloud DNS), il che rende questa strategia limitata.

  • In genere, avere un cluster di Config Controller nella stessa regione comporta il problema dei guasti correlati: vuoi ricollegare le risorse esattamente quando un guasto regionale interessa Config Controller in 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, 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 interrompi l'istanza di Config Controller o se la regione è offline, questa può essere una misura temporanea utile.

Quando l'istanza di Config Controller viene ripristinata, Config Connector tenterà probabilmente di annullare le modifiche manuali. Per evitare questa situazione, puoi apportare modifiche corrispondenti in Git per eventuali modifiche apportate manualmente.