Cluster a livello di regione

Questa pagina spiega come funzionano i cluster di regione in Google Kubernetes Engine (GKE).

I cluster a livello di regione aumentano la disponibilità di un cluster replicando il control plane in più zone di una regione.

Questa configurazione offre i seguenti vantaggi:

  • Resilienza in caso di errore di una singola zona: i cluster regionali sono disponibili in una regione anziché in una singola zona all'interno di una regione. Se una singola zona non è più disponibile, il tuo control plane non viene interessato.
  • Upgrade continui del control plane, ridimensionamenti del control plane e tempi di inattività ridotti a causa di errori del control plane. Con le repliche ridondanti del control plane, i cluster regionali offrono una maggiore disponibilità dell'API Kubernetes, in modo da poter accedere al control plane anche durante gli upgrade.

Inoltre, per impostazione predefinita, i cluster regionali vengono creati come cluster multizona, in modo che i nodi worker siano distribuiti in più zone di una regione. In questo modo aumenta la disponibilità del carico di lavoro, se esegui un numero sufficiente di repliche.

I cluster GKE Autopilot sono sempre regionali. Se utilizzi GKE Standard, puoi scegliere di creare cluster regionali o di zona. Per scoprire di più sui diversi tipi di disponibilità dei cluster, consulta Disponibilità dei cluster.

Nei cluster regionali, inclusi i cluster Autopilot, il control plane viene replicato in più zone di una regione. GKE replica automaticamente i nodi tra le zone della stessa regione. Nei cluster Standard e nei node pool, puoi specificare facoltativamente le zone in cui vengono eseguiti i nodi. Tutte le zone devono trovarsi nella stessa regione del control plane.

Dopo aver creato un cluster regionale, non puoi convertirlo in un cluster zonale.

Come funzionano i cluster a livello di regione

I cluster regionali replicano il control plane e i nodi del cluster in più zone all'interno di una singola regione. Ad esempio, utilizzando la configurazione predefinita, un cluster regionale nella regione us-east1 crea più repliche del control plane in diverse zone us-east1 e esegue il provisioning dei nodi in tre zone us-east1: us-east1-b, us-east1-c e us-east1-d. In caso di interruzione dell'infrastruttura, i carichi di lavoro Autopilot continuano a essere eseguiti e GKE ribilancia automaticamente i nodi. Se utilizzi cluster Standard, devi ribilanciare i nodi manualmente o utilizzando il gestore della scalabilità automatica dei cluster.

Limitazioni

  • Il pool di nodi predefinito creato per i cluster Standard regionali è costituito da nove nodi (tre per zona) distribuiti uniformemente in tre zone di un'area geografica. Vengono utilizzati nove indirizzi IP per i cluster che utilizzano nodi pubblici. Se necessario, puoi ridurre il numero di nodi a uno per zona. Ai nuovi account fatturazione Cloud vengono concessi solo otto indirizzi IP per regione, pertanto potresti dover richiedere un aumento delle quote per gli indirizzi IP in uso a livello regionale, a seconda delle dimensioni del cluster regionale. Se hai un numero troppo basso di indirizzi IP in uso disponibili, la creazione del cluster non va a buon fine.

  • Per eseguire GPU nel cluster regionale, scegli una regione che abbia almeno una zona in cui sono disponibili le GPU richieste. Quando crei il pool di nodi, devi utilizzare il flag --node-locations per specificare la zona o le zone contenenti le GPU richieste.

    Se la regione che scegli non ha almeno una zona in cui sono disponibili le GPU richieste, potresti visualizzare un errore simile al seguente:

    
ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=
    Accelerator type "nvidia-l4" does not exist in zone europe-west3-a.

    Per un elenco completo delle regioni e delle zone in cui sono disponibili le GPU, consulta GPU su Compute Engine.

  • Le zone per i pool di nodi in modalità Standard devono trovarsi nella stessa regione del control plane del cluster. Se necessario, puoi modificare le zone di un cluster, in modo che tutti i nodi nuovi ed esistenti si estendano a queste zone.

Prezzi

Tutti i cluster Autopilot sono regionali e sono soggetti al modello di prezzi Autopilot.

In modalità Standard, i cluster regionali richiedono un numero maggiore di quote regionali del tuo progetto rispetto a un cluster zonale o multi-zonale simile. Assicurati di comprendere le tue quote e i prezzi standard prima di utilizzare i cluster regionali. Se si verifica un errore Insufficient regional quota to satisfy request for resource, la tua richiesta supera la quota disponibile nella regione corrente.

Inoltre, ti viene addebitato il traffico da nodo a nodo tra le zone. Ad esempio, se un workload in esecuzione in una zona deve comunicare con un workload in un'altra zona, il traffico tra zone comporta costi. Per ulteriori informazioni, consulta In uscita tra zone nella stessa regione (per GB) nella pagina dei prezzi di Compute Engine.

Archiviazione permanente nei cluster regionali

I dischi permanenti a livello di zona sono risorse a livello di zona e i dischi permanenti regionali sono risorse multizona. Quando aggiungi spazio di archiviazione permanente, a meno che non venga specificata una zona, GKE assegna il disco a una singola zona casuale. Per scoprire come controllare le zone, consulta Zone nei dischi permanenti.

Scalabilità automatica dei cluster regionali

Tieni presente le seguenti considerazioni quando utilizzi il gestore della scalabilità automatica dei cluster per scalare automaticamente i node pool nei cluster regionali in modalità Standard.

Puoi anche scoprire di più sui limiti di scalabilità automatica per i cluster regionali o su come il gestore della scalabilità automatica dei cluster bilancia le zone.

Queste considerazioni si applicano solo ai cluster in modalità Standard con il gestore della scalabilità automatica del cluster.

Limiti di scalabilità dell'overprovisioning

Per mantenere la capacità nell'improbabile caso di errore a livello di zona, puoi consentire a GKE di eseguire l'overprovisioning dei limiti di scalabilità, per garantire un livello minimo di disponibilità anche quando alcune zone non sono disponibili.

Ad esempio, se esegui il provisioning eccessivo di un cluster a tre zone al 150% (50% di capacità in eccesso), puoi assicurarti che il 100% del traffico venga indirizzato alle zone disponibili se viene persa un terzo della capacità del cluster. Nell'esempio precedente, puoi ottenere questo risultato specificando un massimo di sei nodi per zona anziché quattro. Se una zona ha esito negativo, il cluster viene scalato a 12 nodi nelle zone rimanenti.

Analogamente, se esegui il provisioning eccessivo di un cluster a due zone al 200%, puoi assicurarti che il 100% del traffico venga reindirizzato se viene persa la metà della capacità del cluster.

Puoi scoprire di più sul gestore della scalabilità automatica dei cluster o leggere le domande frequenti sulla scalabilità automatica nella documentazione di Kubernetes.

Passaggi successivi