Questa pagina mostra come utilizzare al meglio Config Controller quando si utilizzano servizi ad alta disponibilità o si gestiscono risorse in più regioni Google Cloud.
Config Controller viene eseguito in una singola regione, quindi può tollerare l'errore di una zona di disponibilità, ma se un'intera regione si verifica, Config Controller perde la disponibilità. Esistono due diverse strategie per gestire gli errori a livello di regione e la scelta dipende da cosa faresti 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 di 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 una regione, il cluster non è disponibile se si verifica un errore in più zone nella regione.
In caso di errore dell'istanza Config Controller, le risorse Google Cloud esistenti 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 riconfigurare le risorse nella stessa regione, se un errore a livello di regione interessa le risorse Google Cloud esistenti nella regione Config Controller, non puoi riparare queste risorse.
Poiché non puoi riconfigurare le risorse in altre regioni, un errore in una regione ora ha influito 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, devi considerare le modalità di errore di quel provider. Potresti non essere in grado di apportare modifiche alla configurazione perché non puoi eseguire il push delle modifiche al provider Git. Oppure, se Config Sync non è in grado di leggere da Git, le modifiche a Git non vengono applicate al cluster e, di conseguenza, Config Connector non le applica. Tuttavia, l'errore regionale è spesso lo scenario di errore più importante, perché altri scenari di errore in genere non sono 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, puoi scegliere di accettare che un errore a livello di regione renda non disponibile il piano di controllo di configurazione.
Ad esempio, se operi solo in un'unica regione, potrebbe non essere necessaria una riconfigurazione utile che puoi eseguire se quella regione non funziona. Allo stesso modo, se hai un singolo database point of failure in una singola regione, potresti non essere in grado di recuperarlo fino al ripristino di quella regione. Per le applicazioni che non hanno bisogno della massima disponibilità assoluta, questa situazione può rappresentare un ragionevole compromesso in termini di costi e complessità.
L'individuazione dell'istanza di Config Controller nella stessa regione genera un destino condiviso: Config Controller è disponibile purché sia disponibile la tua regione principale. Anche individuare l'istanza Config Controller in una regione diversa può essere una buona scelta; anche se ora devi pensare ai potenziali errori in due regioni, in questo modo eviterai il correlato errore del piano di controllo di configurazione con l'errore della regione principale.
In alternativa, se hai una configurazione ridondante in più regioni, il sistema potrebbe allontanare automaticamente le regioni in errore. Anche in questo caso, ti conviene non eseguire la riconfigurazione in caso di errore di una regione. In questo caso, puoi scegliere una singola istanza di Config Controller.
Esegui manualmente il failover a una seconda istanza Config Controller
In caso di errore di una regione, ti consigliamo di eseguire una riconfigurazione, per rimediare all'errore. Potresti anche voler continuare a configurare le risorse in altre regioni, anche se l'istanza di Config Controller si trova in una regione in errore. In questo caso, consigliamo di usare una seconda istanza di Config Controller in una seconda regione.
Anche se non è consigliato, è possibile eseguire due istanze Config Controller con configurazioni identiche. Entrambe le istanze devono leggere dallo stesso repository Git e applicare le stesse modifiche a Google Cloud. Tuttavia, numerosi casi limite rendono questa configurazione inaffidabile. Le due istanze Config Controller osservano il repository Git in momenti leggermente diversi; potrebbero tentare di applicare versioni leggermente diverse della configurazione di Google Cloud. Con più writer attivi in Google Cloud è più probabile che vengano riscontrati quote o limiti di frequenza. Anche un numero limitato di risorse di Config Connector non è idempotente e richiede un'ulteriore attenzione, come discusso nel resto di questa sezione. Consigliamo quindi di evitare la riconciliazione attiva di due cluster Config Controller.
Ti consigliamo invece di eseguire un altro Config Controller in una seconda regione se la regione che esegue il Config Controller non ha esito positivo. La nuova istanza Config Controller deve essere configurata in modo identico alla prima, leggendo dallo stesso repository Git. In questo scenario potrebbe essere utile preparare uno script per visualizzare e configurare l'istanza di Config Controller. 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 su 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 quando viene ripristinata la prima regione, potrebbe tentare di applicare il vecchio stato a Google Cloud. Se riesci ad arrestare il cluster Config Controller nella prima regione prima di avviare un secondo cluster Config Controller, 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, consigliamo di fare attenzione a
Folderrisorse e a evitareIAMServiceAccountKeyrisorse (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 un'altra regione, puoi anche valutare di eseguire un'istanza di Config Controller per regione, in cui ogni istanza di Config Controller gestisce le 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 questa strategia limitata.
In genere, la presenza di un cluster Config Controller nella stessa regione riscontra il problema di errore correlato: conviene riconfigurare le risorse esattamente quando un errore a livello di regione influisce sul 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 utilizzare Git o Config Connector. Config Connector tenta di correggere eventuali "deviazioni", quindi se l'istanza di Config Controller è ancora in esecuzione, Config Connector considera qualsiasi modifica apportata manualmente come "deviazione" e tenta di annullarle.
Tuttavia, se arresti l'istanza di Config Controller o se la regione è offline, questa può essere una misura alternativa utile.
Quando l'istanza di Config Controller si recupera, Config Connector probabilmente tenterà di annullare le modifiche manuali. Per evitare questa situazione, puoi apportare le modifiche corrispondenti in Git a tutte le modifiche apportate manualmente.