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 piano di controllo e i nodi in più zone di una regione.

I cluster a livello di regione offrono tutti i vantaggi dei cluster multizonali con i seguenti vantaggi aggiuntivi:

  • Resilienza in caso di errore in 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 diventa non disponibile, il tuo piano di controllo e le tue risorse non sono interessati.
  • Upgrade continui del piano di controllo, ridimensionamenti del piano di controllo e tempi di inattività ridotti a causa di errori del piano di controllo. Con le repliche ridondanti del piano di controllo, i cluster a livello di area geografica offrono una maggiore disponibilità dell'API Kubernetes, in modo da poter accedere al piano di controllo anche durante gli upgrade.

I cluster GKE Autopilot sono sempre a livello di regione. Se utilizzi GKE Standard, puoi scegliere di creare cluster regionali, a livello di zona o multi-zona. Per informazioni sui diversi tipi di disponibilità del cluster, consulta Informazioni sulle scelte di configurazione del cluster.

Nei cluster a livello di regione, inclusi i cluster Autopilot, il piano di controllo viene replicato in tre zone di una regione. GKE replica automaticamente i nodi nelle zone della stessa regione. Nei cluster e nei pool di nodi standard, puoi facoltativamente specificare manualmente le zone in cui vengono eseguiti i nodi. Tutte le zone devono trovarsi nella stessa regione del control plane.

Una volta creato un cluster a livello di regione, non puoi convertirlo in un cluster a livello di zona.

Come funzionano i cluster a livello di regione

I cluster a livello di regione replicano il piano di controllo e i nodi del cluster in più zone all'interno di un'unica regione. Ad esempio, utilizzando la configurazione predefinita, un cluster regionale nella regione us-east1 crea repliche del piano di controllo e 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 funzionare e GKE riequilibra automaticamente i nodi. Se utilizzi i cluster standard, devi riequilibrare i nodi manualmente o utilizzando il gestore della scalabilità automatica del cluster.

Limitazioni

  • Il pool di nodi predefinito creato per i cluster standard regionali è costituito da nove nodi (tre per zona) distribuiti uniformemente su tre zone in una regione. Vengono utilizzati nove indirizzi IP per i cluster che utilizzano nodi pubblici. Se necessario, puoi ridurre il numero di nodi a uno per zona. Gli account di fatturazione Cloud appena creati ricevono solo otto indirizzi IP per regione, pertanto potresti dover richiedere un aumento delle quote per gli indirizzi IP regionali in uso, a seconda delle dimensioni del cluster regionale. Se hai un numero troppo ridotto di indirizzi IP in uso, la creazione del cluster non va a buon fine.

  • Per eseguire le GPU nel tuo cluster a livello di regione, scegli una regione con almeno una zona in cui sono disponibili le GPU richieste. Devi utilizzare il --node-locations quando crei il pool di nodi per specificare la zona o le zone contenenti le GPU richieste.

    Se la regione scelta 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 piano di controllo 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 determinazione dei prezzi di Autopilot.

In modalità standard, i cluster regionali richiedono più quote regionali del progetto rispetto a un cluster a livello di zona o multi-zona simile. Assicurati di conoscere le quote e i prezzi standard prima di utilizzare i cluster regionali. Se si verifica un Insufficient regional quota to satisfy request for resource errore, la 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 altro workload in una zona diversa, il traffico tra zone comporta un costo. 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, mentre i dischi permanenti a livello di regione 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.

Cluster regionali con scalabilità automatica

Tieni presenti le seguenti considerazioni quando utilizzi il gestore della scalabilità automatica dei cluster per scalare automaticamente i pool di nodi nei cluster regionali in modalità standard.

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

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

Limiti di scalabilità per il sovraprovisioning

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

Ad esempio, se esegui l'overprovisioning 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 perso un terzo della capacità del cluster. Nell'esempio precedente, lo faresti specificando un massimo di sei nodi per zona anziché quattro. Se una zona non funziona, il cluster si espande a 12 nodi nelle altre zone.

Analogamente, se esegui l'overprovisioning di un cluster a due zone al 200%, puoi assicurarti che il 100% del traffico venga reindirizzato se viene persa 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