Configura Config Controller per l'alta disponibilità

Questa pagina mostra il modo migliore per utilizzare Config Controller quando si utilizzano servizi ad alta disponibilità o si gestiscono risorse in più regioni. Google Cloud

Questa pagina è rivolta ad amministratori, architetti e operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante e pianificano la capacità e le esigenze dell'infrastruttura. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta la pagina Ruoli e attività comuni degli utenti GKE.

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 strategie diverse per gestire l'errore regionale e la tua scelta dipende da cosa fare se una regione non funziona:

Comprendere gli scenari di errore

Config Controller utilizza un cluster GKE regionale. 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 funziona, le risorse Google Cloud esistenti rimangono nel loro stato attuale. Tuttavia, anche se le tue applicazioni sono ancora in esecuzione, non puoi modificarne la configurazione quando Config Controller non è disponibile. Ciò 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 regionale influisce sulle risorse Google Cloud esistenti nella regione Config Controller, non puoi ripararle.

Poiché non puoi 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 che esegua il pull da un provider Git esterno, devi prendere in considerazione le modalità di errore di questo provider Git. Potresti non essere in grado di apportare modifiche alla configurazione perché non puoi eseguire il push delle modifiche al provider Git. Se Config Sync non riesce a leggere da Git, le 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 in genere non sono correlati all'errore del controller di configurazione.

Utilizzare un singolo cluster per la disponibilità regionale

In molti scenari, non esegui alcuna riconfigurazione se una regione ha esito negativo. In questo caso, potresti scegliere di accettare che un guasto regionale causi l'indisponibilità del piano di controllo della configurazione.

Ad esempio, se operi solo in una singola regione, potrebbe non esserci alcuna riconfigurazione utile che puoi eseguire se la regione non funziona. Allo stesso modo, se hai un database single point of failure in una singola regione, potresti non essere in grado di eseguire il ripristino finché la regione non viene ripristinata. Per le applicazioni che non richiedono la 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, si ha un destino condiviso: Config Controller è disponibile finché la regione principale è disponibile. Individuare l'istanza Config Controller in una regione diversa può essere una buona scelta. Anche se ora devi pensare a 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 allontanarsi automaticamente dalle regioni non riuscite. Anche in questo caso, potresti non voler eseguire la riconfigurazione se una regione non funziona. In questo caso, potresti scegliere una singola istanza di Config Controller.

Esegui manualmente il failover a una seconda istanza di Config Controller

Se una regione non funziona, potresti voler eseguire una riconfigurazione per risolvere il problema. Potresti anche voler continuare a configurare le risorse in altre regioni, anche se l'istanza Config Controller si trova in una regione non riuscita. In questo caso, ti consigliamo di utilizzare una seconda istanza di Config Controller in una seconda regione.

Anche se non è consigliato, è possibile eseguire due istanze di Config Controller 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 tentare di applicare versioni leggermente diverse della tua configurazione Google Cloud . Più writer attivi Google Cloud aumentano la probabilità di raggiungere quote o limiti di frequenza. Un numero ridotto di risorse Config Connector non sono idempotenti e richiedono maggiore attenzione, come descritto nel resto di questa sezione. Pertanto, sconsigliamo di avere due cluster Config Controller che eseguono attivamente la riconciliazione.

Ti consigliamo invece di eseguire un altro Config Controller in una seconda regione se la regione in cui è in esecuzione Config Controller non funziona. La nuova istanza di Config Controller deve essere configurata in modo identico alla prima, leggendo dallo stesso repository Git. La preparazione di uno script per visualizzare 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 con Google Cloud.

In questa situazione, devi prestare attenzione a due aspetti:

  • Se il primo cluster Config Controller è ancora in esecuzione o inizia a essere eseguito quando la prima regione viene ripristinata, potrebbe tentare di applicare il vecchio stato a Google Cloud. Se puoi 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 Config Connector possono essere riapplicate senza problemi da Git. Per l'elenco delle risorse che richiedono un'attenzione particolare, consulta 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 per GKE).

Un'istanza di Config Controller per regione

Se vuoi evitare che un'istanza di Config Controller in una regione influenzi un'altra regione, potresti anche prendere in considerazione l'esecuzione di un'istanza di Config Controller per regione, in cui ogni istanza di Config Controller gestisce le risorse in quella regione.

Questa configurazione è fattibile, 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 Config Controller nella stessa regione comporta il problema di errore correlato: vuoi riconfigurare le risorse esattamente quando un errore regionale influisce su Config Controller in quella regione.

  • Devi dividere le risorse 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 per Git o Config Connector. Config Connector tenta di correggere qualsiasi "deviazione", quindi se l'istanza di Config Controller è ancora in esecuzione, Config Connector considera qualsiasi modifica apportata manualmente come "deviazione" e tenta di ripristinarla.

Tuttavia, se arresti l'istanza di Config Controller o se la regione è offline, questa può essere una misura provvisoria utile.

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