Questa pagina mostra come utilizzare al meglio Config Controller per gestire servizi ad alta disponibilità o gestire risorse in più regioni Google Cloud.
Config Controller viene eseguito in una singola regione, quindi è in grado di tollerare l'errore di una zona di disponibilità, ma se un'intera regione presenta errori, Config Controller perde la disponibilità. Esistono due diverse strategie per gestire gli errori a livello di regione e la tua scelta dipende da ciò che faresti in caso di errore in una regione:
Se vuoi apportare modifiche alla configurazione in risposta a un errore a livello di regione, crea una seconda istanza di Config Controller.
Se non vuoi apportare modifiche alla configurazione, utilizza una singola istanza di Config Controller.
Comprendere gli scenari di errore
Config Controller utilizza un cluster GKE a livello di regione. Anche se un cluster a livello di regione può tollerare l'errore di una singola zona in un'area geografica, il cluster diventa non disponibile in caso di errore in più zone nella regione.
In caso di errore dell'istanza di Config Controller, le risorse Google Cloud esistenti rimarranno 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 di Config Controller, non puoi ripararle.
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 regione.
Sono possibili anche altri scenari di errore. Ad esempio, se configuri Config Sync in modo da eseguire il pull da un provider Git esterno, dovresti prendere in considerazione le modalità di errore del provider Git. Potresti non riuscire ad apportare modifiche alla configurazione perché non puoi eseguire il push delle modifiche a quel provider Git. Oppure, se Config Sync non può leggere da Git, le eventuali modifiche di 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 non sono in genere correlati all'errore di Config Controller.
Usa un unico cluster per la disponibilità a livello di regione
In molti scenari, non eseguireresti alcuna riconfigurazione se si verifica un errore in una regione. In questo caso, puoi scegliere di accettare che un errore a livello di regione comporti la disattivazione 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 errore della regione. Allo stesso modo, se hai un database single point of failure in un'unica regione, potresti non essere in grado di eseguire il ripristino fino al ripristino di quella regione. Per le applicazioni che non hanno bisogno della massima disponibilità assoluta, questa situazione può rappresentare un compromesso ragionevole rispetto a costi e complessità.
Se si trova l'istanza di Config Controller nella stessa regione, avrai un destino condiviso: Config Controller è disponibile fintanto che è disponibile la regione principale. Anche localizzare l'istanza di Config Controller in una regione diversa può essere una buona scelta; anche se ora devi considerare potenziali errori in due regioni, eviterai l'errore correlato del piano di controllo della configurazione con l'errore della regione principale.
In alternativa, se hai una configurazione ridondante per più regioni, il sistema potrebbe allontanarsi automaticamente dalle regioni in errore. Anche in questo caso potresti non voler fare una riconfigurazione in caso di errore di una regione. In questo caso, puoi scegliere una singola istanza di Config Controller.
Failover manuale a una seconda istanza di Config Controller
Potrebbe essere necessario eseguire una riconfigurazione in caso di errore di una regione, in modo da poter risolvere l'errore. Ti consigliamo inoltre di continuare a configurare le risorse in altre regioni, anche se l'istanza di Config Controller si trova in una regione che non è riuscita. In questo caso, consigliamo di utilizzare una seconda istanza di Config Controller in una seconda regione.
Sebbene non sia consigliabile, è possibile eseguire due istanze Config Controller con configurazioni identiche. Entrambe le istanze cercano di leggere dallo stesso repository Git e applicano le stesse modifiche a Google Cloud. Tuttavia, numerosi casi limite rendono inaffidabile questa configurazione. Le due istanze di Config Controller osservano il repository Git in momenti leggermente diversi; potrebbero tentare di applicare versioni leggermente diverse della configurazione di Google Cloud. Più writer attivi su Google Cloud aumentano le probabilità di imbattersi in quote o limiti di frequenza. Inoltre, un numero ridotto di risorse di Config Connector non è idempotente e richiede un'attenzione particolare, come illustrato nel resto di questa sezione. Consigliamo quindi di non avere due cluster Config Controller in riconciliazione attiva.
In caso di errore nella regione che esegue Config Controller, ti consigliamo di eseguire un altro Config Controller in una seconda regione. La nuova istanza di Config Controller deve essere configurata in modo identico alla prima, in quanto si legge dallo stesso repository Git. In questo scenario potrebbe essere utile la preparazione di uno script per visualizzare 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; Config Connector sincronizza lo stato desiderato su Google Cloud.
In questa situazione devi fare attenzione a due aspetti:
Se il primo cluster Config Controller è ancora in esecuzione o inizia a essere in esecuzione 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 interruzioni da Git. Per l'elenco delle risorse che richiedono attenzione speciale, consulta le risorse con restrizioni sull'acquisizione. In particolare, consigliamo di fare attenzione alle risorse
Foldere di evitare le risorseIAMServiceAccountKey(ad esempio, utilizzando GKE Workload Identity).
Un'istanza Config Controller per regione
Se vuoi evitare un'istanza di Config Controller in una regione che interessa un'altra regione, puoi anche eseguire un'istanza di Config Controller per ogni regione, nella quale ogni istanza di Config Controller gestisce le risorse in quella regione.
Questa configurazione è attuabile, ma non è una delle nostre opzioni consigliate per i seguenti motivi:
Alcune risorse coprono più regioni (come Cloud DNS), il che rende limitata questa strategia.
In genere, se un cluster di Config Controller si trova nella stessa regione, si verifica il problema di guasto correlato: vuoi riconfigurare le risorse esattamente quando un errore regionale influisce su 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, puoi apportare modifiche direttamente alle risorse Google Cloud sottostanti, senza utilizzare Git o Config Connector. Config Connector cerca di risolvere eventuali deviazioni. Se l'istanza di Config Controller è ancora in esecuzione, Config Connector considera tutte le modifiche apportate manualmente come "deviazioni" e tenta di annullarle.
Tuttavia, se arresti l'istanza di Config Controller o se la regione è offline, questa può essere una misura temporanea utile.
Una volta ripristinata l'istanza di Config Controller, è probabile che Config Connector tenterà di annullare le modifiche manuali. Per evitare questa situazione, puoi apportare quelle corrispondenti in Git a qualsiasi modifica apportata manualmente.