Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Configura Config Controller per l'alta disponibilità

Questa pagina mostra come utilizzare al meglio Config Controller quando si utilizzano servizi a disponibilità elevata o si gestiscono risorse in più aree geografiche di Google Cloud.

Config Controller viene eseguito in una singola area geografica, quindi può tollerare l'errore di una zona di disponibilità, ma se un'intera area geografica non riesce, Config Controller perde la disponibilità. Esistono due strategie diverse per gestire un errore a livello di area geografica e la tua scelta dipende da ciò che faresti se un'area geografica non riuscisse:

Informazioni sugli scenari di errore

Config Controller utilizza un cluster GKE a livello di area geografica. Sebbene il cluster a livello di area geografica possa tollerare l'errore di una singola zona in un'area geografica, il cluster diventa non disponibile se più zone nell'area geografica hanno esito negativo.

Se l'istanza di Config Controller non riesce, 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 della stessa area geografica e per le risorse di altre aree geografiche che gestisci dal controller di configurazione nell'area geografica non disponibile.

Poiché non puoi riconfigurare le risorse nella stessa area geografica, se un errore a livello di area geografica interessa le risorse Google Cloud esistenti nell'area geografica Config Controller, non puoi ripristinarle.

Poiché non puoi riconfigurare le risorse in altre aree geografiche, un errore in un'area geografica adesso influisce sulla tua capacità di apportare modifiche in un'altra.

Sono possibili anche altri scenari di errore. Ad esempio, se configuri Config Sync per il pull da un provider Git esterno, ti conviene considerare le modalità di errore di tale provider Git. Potresti non essere in grado di apportare modifiche alla configurazione poiché non puoi eseguire il push delle modifiche al provider Git in questione. Se Config Sync non è in grado di leggere da Git, le eventuali modifiche Git non verranno applicate al cluster e, di conseguenza, Config Connector non le applicherà. Tuttavia, spesso l'errore a livello di area geografica è lo scenario di errori più importante, perché altri scenari in genere non sono correlati all'errore di Config Controller.

Utilizza un cluster singolo per la disponibilità a livello di area geografica

In molti scenari, non viene eseguita alcuna riconfigurazione se un'area geografica presenta problemi. In questo caso, potresti scegliere di accettare che un errore a livello di area geografica causi l'indisponibilità del piano di controllo per la configurazione.

Ad esempio, se operi solo in una singola area geografica, potresti non effettuare alcuna riconfigurazione utile in caso di errore. Allo stesso modo, se hai un database di single point of failure in una singola area geografica, potresti non essere in grado di eseguire il ripristino finché tale area non viene recuperata. Per le applicazioni che non richiedono la massima disponibilità assoluta, questa situazione può rappresentare un ragionevole compromesso rispetto a costi e complessità.

Individuando l'istanza Config Controller nella stessa area geografica, hai un criterio condiviso: Config Controller è disponibile a condizione che la tua area geografica principale sia disponibile. Anche l'individuazione dell'istanza del controller Config in un'area geografica diversa può essere un'ottima scelta; anche se devi ora pensare a potenziali errori in due aree geografiche, puoi evitare il problema correlato al piano di controllo della configurazione con il failover dell'area geografica principale.

In alternativa, se hai una configurazione ridondante in più aree geografiche, il tuo sistema potrebbe allontanarsi automaticamente dalle aree geografiche con errori. Anche in questo caso, potrebbe non essere necessario eseguire una riconfigurazione in caso di errore. In questo caso, potresti scegliere una singola istanza di Config Controller.

Fai manualmente il failover su una seconda istanza di Config Controller

Potrebbe essere utile riconfigurare un'area geografica per poter risolvere il problema. Potrebbe essere utile continuare a configurare le risorse in altre aree geografiche, anche se la tua istanza di Config Controller si trova in un'area geografica con errori. In questo caso, ti consigliamo di utilizzare una seconda istanza di Config Controller in una seconda area geografica.

Anche se non è consigliabile, due istanze Config Controller possono essere eseguite con configurazioni identiche. Entrambe le istanze competono per 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; potrebbero provare ad applicare versioni leggermente diverse della configurazione di Google Cloud. Più autori attivi in Google Cloud aumentano le probabilità di incorrere in quote o limiti di frequenza. Anche un numero ridotto di risorse di Config Connector non è idempotente e richiede un'ulteriore attenzione, come illustrato nel resto di questa sezione. Sconsigliamo quindi di utilizzare due cluster Config Controller attivi durante la riconciliazione.

È consigliabile, invece, che se l'area geografica che esegue il tuo controller di configurazione non va a buon fine, ne esegui un altro in una seconda area geografica. La nuova istanza di Config Controller deve essere configurata in modo identico alla prima, ossia leggendo dallo stesso repository Git. La preparazione di uno script per aprire e configurare l'istanza di Config Controller potrebbe essere utile in questo scenario. Quando crei la nuova istanza di Config Controller, Config Sync legge e applica lo stato desiderato da Git a Kubernetes; Config Connector sincronizza lo stato desiderato su Google Cloud.

Ci sono due aspetti da tenere presenti in questa situazione:

  • Se il primo cluster di Config Controller è ancora in esecuzione o inizia a essere eseguito quando la prima area geografica recupera, il sistema potrebbe tentare di applicare il vecchio stato a Google Cloud. Se puoi arrestare il cluster Config Controller nella prima area geografica prima di avviare un secondo cluster Config Controller, puoi evitare questo potenziale conflitto.

  • Non tutte le risorse di Config Connector possono essere applicate nuovamente da Git. Per l'elenco delle risorse che richiedono un'assistenza particolare, consulta le risorse con limitazioni sull'acquisizione. In particolare, consigliamo di prestare attenzione alle risorse Folder e di evitare IAMServiceAccountKey risorse (ad esempio, utilizzare GKE Workload Identity).

Un'istanza di Config Controller per area geografica

Se vuoi evitare un'istanza di Config Controller in un'area geografica che interessa un'altra area geografica, puoi eseguire un'istanza di Config Controller per area geografica in cui ogni istanza di Config Controller gestisce le risorse in quell'area geografica.

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

  • Alcune risorse si estendono su più aree geografiche (come Cloud DNS), il che rende questa strategia limitata.

  • In genere, un cluster di Config Controller nella stessa area geografica incontra il problema di errore correlato: vuoi riconfigurare le risorse esattamente quando un errore a livello di area geografica interessa il controller di configurazione di quella area geografica.

  • Devi suddividere le risorse di Config Connector per area geografica.

  • Config Controller non è attualmente disponibile in tutte le aree geografiche.

Configurazione diretta delle risorse Google Cloud

In circostanze eccezionali, puoi apportare modifiche direttamente alle risorse sottostanti di Google Cloud, senza dover utilizzare Git o Config Connector. Config Connector prova a correggere qualsiasi "drift"

Tuttavia, se interrompi l'istanza di Config Controller o se l'area geografica è offline, questa può essere un'utile misura di interruzione.

Quando l'istanza di Config Controller viene recuperata, è probabile che Config Connector tenti di ripristinare le modifiche manuali. Per evitare questa situazione, puoi apportare le modifiche corrispondenti in Git per qualsiasi modifica manuale.