Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni sulla scalabilità automatica dei cluster

Autopilot Standard

Questa pagina spiega in che modo Google Kubernetes Engine (GKE) ridimensiona automaticamente i pool di nodi del cluster Standard in base alle esigenze dei tuoi carichi di lavoro. Quando la domanda è elevata, il gestore della scalabilità automatica dei cluster aggiunge nodi al pool di nodi. Per scoprire come configurare il gestore della scalabilità automatica dei cluster, consulta Scalabilità automatica di un cluster.

Con i cluster Autopilot, non devi preoccuparti del provisioning dei nodi o della gestione dei pool di nodi, perché il provisioning dei pool di nodi viene eseguito automaticamente tramite il provisioning automatico dei nodi e viene scalato automaticamente per soddisfare i requisiti dei tuoi carichi di lavoro.

Perché utilizzare il gestore della scalabilità automatica dei cluster

Il gestore della scalabilità automatica dei cluster di GKE ridimensiona automaticamente il numero di nodi in un determinato pool di nodi, in base alle esigenze dei tuoi carichi di lavoro. Quando la domanda è bassa, il gestore della scalabilità automatica dei cluster torna indietro fino alla dimensione minima da te designata. Questo può aumentare la disponibilità dei carichi di lavoro quando ne hai bisogno, controllando al contempo i costi. Non è necessario aggiungere o rimuovere manualmente i nodi o eseguire l'overprovisioning dei pool di nodi. Puoi invece specificare una dimensione minima e una massima per il pool di nodi, il resto è automatico.

Se le risorse vengono eliminate o spostate durante la scalabilità automatica del cluster, i carichi di lavoro potrebbero subire interruzioni temporanee. Ad esempio, se il carico di lavoro è costituito da un controller con una singola replica, il pod della replica potrebbe essere ripianificato su un nodo diverso se il nodo attuale viene eliminato. Prima di abilitare il gestore della scalabilità automatica dei cluster, progetta i carichi di lavoro in modo da tollerare potenziali interruzioni o garantire che i pod critici non vengano interrotti.

Puoi aumentare le prestazioni del gestore della scalabilità automatica dei cluster con il flusso di immagini, che invia in remoto i flussi di dati delle immagini richiesti dalle immagini container idonee e memorizza nella cache l'immagine in locale per consentire un avvio più rapido dei carichi di lavoro sui nuovi nodi.

Come funziona il gestore della scalabilità automatica dei cluster

Il gestore della scalabilità automatica dei cluster funziona in base al pool di nodi. Quando configuri un pool di nodi con il gestore della scalabilità automatica dei cluster, devi specificare una dimensione minima e una massima per il pool di nodi.

Il gestore della scalabilità automatica dei cluster aumenta o diminuisce automaticamente le dimensioni del pool di nodi aggiungendo o rimuovendo le istanze di macchine virtuali (VM) nel gruppo di istanze gestite di Compute Engine sottostante per il pool di nodi. Il gestore della scalabilità automatica dei cluster prende queste decisioni di scalabilità in base alle richieste di risorse (anziché all'utilizzo effettivo delle risorse) dei pod in esecuzione sui nodi del pool di nodi. Controlla periodicamente lo stato di pod e nodi e interviene:

Se non è possibile pianificare i pod su nessuno dei nodi attuali, il gestore della scalabilità automatica dei cluster aggiunge nodi fino alla dimensione massima del pool di nodi. Per saperne di più su quando il gestore della scalabilità automatica dei cluster modifica le dimensioni di un cluster, consulta Quando il gestore della scalabilità automatica dei cluster modifica le dimensioni di un cluster?
Se GKE decide di aggiungere nuovi nodi al pool di nodi, il gestore della scalabilità automatica del cluster aggiunge tutti i nodi necessari, fino a un limite per pool di nodi o per cluster.
Il gestore della scalabilità automatica dei cluster non attende la comparsa di un nodo prima di creare quello successivo. Una volta che GKE ha deciso quanti nodi creare, la creazione dei nodi avviene in parallelo. L'obiettivo è ridurre al minimo il tempo necessario ai pod non pianificabili per diventare Active.
Se alcuni nodi non vengono creati a causa dell'esaurimento della quota, il gestore della scalabilità automatica dei cluster attende che le risorse vengano pianificate correttamente.
Se i nodi sono sottoutilizzati e tutti i pod possono essere pianificati anche con meno nodi nel pool di nodi, il gestore della scalabilità automatica dei cluster rimuove i nodi fino alla dimensione minima del pool di nodi. Se su un nodo sono presenti pod che non possono essere spostati su altri nodi del cluster, il gestore della scalabilità automatica dei cluster non tenta di fare lo scale down del nodo. Se i pod possono essere spostati in altri nodi, ma il nodo non può essere svuotato in modo controllato dopo un periodo di timeout (attualmente 10 minuti), il nodo viene arrestato in modo forzato. Il periodo di tolleranza non è configurabile per i cluster GKE. Per saperne di più su come funziona lo fare lo scale down, consulta la documentazione del gestore della scalabilità automatica dei cluster.

La frequenza con cui il gestore della scalabilità automatica dei cluster controlla un cluster per individuare pod non pianificabili dipende in gran parte dalle dimensioni del cluster. In cluster di piccole dimensioni, l'ispezione potrebbe avvenire a intervalli di pochi secondi. Non è possibile definire un periodo di tempo esatto necessario per questa ispezione.

Se i pod hanno richiesto poche risorse (o non hanno modificato i valori predefiniti, che potrebbero essere insufficienti) e i nodi stanno riscontrando carenze, il gestore della scalabilità automatica del cluster non corregge la situazione. Puoi contribuire a garantire che il gestore della scalabilità automatica del cluster funzioni nel modo più accurato possibile effettuando richieste di risorse esplicite per tutti i tuoi carichi di lavoro.

Criteri operativi

Il gestore della scalabilità automatica dei cluster fa le seguenti ipotesi quando ridimensiona un pool di nodi:

Tutti i pod replicati possono essere riavviati su qualche altro nodo, causando potenzialmente una breve interruzione. Se i tuoi servizi non sono a tolleranza di interruzione, non è consigliabile utilizzare il gestore della scalabilità automatica dei cluster.
Utenti o amministratori non gestiscono manualmente i nodi, ma possono sostituire qualsiasi operazione di gestione manuale dei nodi eseguita.
Tutti i nodi in un singolo pool di nodi hanno lo stesso insieme di etichette.
Il gestore della scalabilità automatica dei cluster tiene conto del costo relativo dei tipi di istanza nei vari pool e tenta di espandere il pool di nodi meno costoso possibile. Viene preso in considerazione il costo ridotto dei pool di nodi contenenti VM spot.
Il gestore della scalabilità automatica dei cluster considera le richieste del container init prima di pianificare i pod. Le richieste di container init possono utilizzare qualsiasi risorsa non allocata disponibile sui nodi, il che potrebbe impedire la pianificazione dei pod. Il gestore della scalabilità automatica dei cluster segue le stesse regole di calcolo delle richieste utilizzate da Kubernetes. Per saperne di più, consulta Utilizzo dei container init.
Le etichette aggiunte manualmente dopo la creazione iniziale del cluster o del pool di nodi non vengono monitorate. Ai nodi creati dal gestore della scalabilità automatica dei cluster vengono assegnate etichette specificate con --node-labels al momento della creazione del pool di nodi.
In GKE versione 1.21 o precedenti, il gestore della scalabilità automatica dei cluster considera le informazioni sull'incompatibilità dei nodi esistenti da un pool di nodi per rappresentare l'intero pool di nodi. A partire dalla versione 1.22 di GKE, il gestore della scalabilità automatica dei cluster combina le informazioni dei nodi esistenti nel cluster e nel pool di nodi. Il gestore della scalabilità automatica del cluster rileva le modifiche manuali ai nodi e al pool di nodi da fare lo scale up.

Bilanciamento tra zone

Se il pool di nodi contiene più gruppi di istanze gestite con lo stesso tipo di istanza, il gestore della scalabilità automatica dei cluster tenta di mantenere bilanciate le dimensioni dei gruppo di istanze gestite durante lo scale up. Ciò aiuta a evitare una distribuzione non uniforme dei nodi tra i gruppi di istanze gestite in più zone di un pool di nodi. GKE non prende in considerazione il criterio di scalabilità automatica per lo scale down.

Criteri di posizione

A partire da GKE versione 1.24.1-gke.800, puoi modificare i criteri di località del gestore della scalabilità automatica dei cluster GKE. Puoi controllare i criteri di distribuzione del gestore della scalabilità automatica dei cluster specificando il flag location_policy con uno dei seguenti valori:

BALANCED: il gestore della scalabilità automatica tiene conto dei requisiti dei pod e della disponibilità delle risorse in ogni zona. Ciò non garantisce che gruppi di nodi simili avranno esattamente le stesse dimensioni, poiché il gestore della scalabilità automatica prende in considerazione molti fattori, tra cui la capacità disponibile in una determinata zona e le affinità di zona dei pod che hanno attivato lo scale up.
ANY: il gestore della scalabilità automatica dà la priorità all'utilizzo delle prenotazioni e degli account inutilizzati per i vincoli attuali delle risorse disponibili. Questo criterio è consigliato se utilizzi VM spot o se vuoi utilizzare prenotazioni di VM diverse tra le zone.

Prenotazioni

A partire dalla versione 1.27 di GKE, il gestore della scalabilità automatica dei cluster prende in considerazione sempre le prenotazioni quando prendono le decisioni di scale up. I pool di nodi con prenotazioni corrispondenti inutilizzate hanno la priorità quando si sceglie il pool di nodi per lo scale up, anche quando il pool di nodi non è il più efficiente. Inoltre, le prenotazioni inutilizzate hanno sempre la priorità quando si bilanciano gli scale up multi-zona.

Valori predefiniti

Per i pool di nodi Spot VM, il criterio di distribuzione predefinito del gestore della scalabilità automatica dei cluster è ANY. In questo criterio, le VM spot hanno un rischio inferiore di prerilascio.

Per i pool di nodi non prerilasciabili, il criterio di distribuzione predefinito del gestore della scalabilità automatica dei cluster è BALANCED.

Dimensione minima e massima del pool di nodi

Quando crei un nuovo pool di nodi, puoi specificare la dimensione minima e massima per ciascun pool di nodi nel tuo cluster e il gestore della scalabilità automatica dei cluster prende decisioni in merito al ridimensionamento all'interno di questi vincoli di scalabilità. Per aggiornare la dimensione minima, ridimensiona manualmente il cluster a una dimensione compresa nei nuovi vincoli dopo aver specificato il nuovo valore minimo. Il gestore della scalabilità automatica dei cluster prende quindi decisioni di ridimensionamento in base ai nuovi vincoli.

Dimensione attuale del pool di nodi	Azione del gestore della scalabilità automatica dei cluster	Vincoli di scalabilità
Inferiore al minimo specificato	Il gestore della scalabilità automatica dei cluster fa lo scale up per eseguire il provisioning dei pod in attesa. Lo scale down è disabilitato.	Non viene fatto fare lo scale down del pool di nodi al di sotto del valore specificato.
Entro le dimensioni minime e massime specificate	Il gestore della scalabilità automatica dei cluster fa lo scale up o lo scale down in base alla domanda.	Il pool di nodi rimane entro i limiti di dimensioni specificati.
Superiore al limite massimo specificato	Il gestore della scalabilità automatica dei cluster fa lo scale down solo per i nodi che possono essere rimossi in sicurezza. Lo scale up è disabilitato.	La scalabilità del pool di nodi non è superiore al valore specificato.

Nei cluster standard, il gestore della scalabilità automatica dei cluster non esegue mai automaticamente lo scale down di un cluster fino a zero nodi. Nel cluster devono essere sempre disponibili uno o più nodi per l'esecuzione dei pod di sistema. Inoltre, se il numero attuale di nodi è pari a zero a causa della rimozione manuale dei nodi, il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi possono fare lo scale up da cluster con zero nodi.

Per scoprire di più sulle decisioni del gestore della scalabilità automatica, consulta Limiti del gestore della scalabilità automatica dei cluster.

Limiti di scalabilità automatica

Puoi impostare il numero minimo e massimo di nodi che il gestore della scalabilità automatica dei cluster utilizza durante la scalabilità di un pool di nodi. Utilizza i flag --min-nodes e --max-nodes per impostare il numero minimo e massimo di nodi per zona

A partire dalla versione 1.24 di GKE, puoi utilizzare i flag --total-min-nodes e --total-max-nodes per i nuovi cluster. Questi flag impostano il numero minimo e massimo del numero totale di nodi nel pool di nodi in tutte le zone.

Esempio di numero minimo e massimo di nodi

Il seguente comando crea un cluster multi-zona a scalabilità automatica con sei nodi inizialmente distribuiti su tre zone, con un minimo di un nodo per zona e un massimo di quattro nodi per zona:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

In questo esempio, la dimensione totale del cluster può essere compresa tra tre e dodici nodi, distribuiti nelle tre zone. In caso di errore di una delle zone, la dimensione totale del cluster può essere compresa tra 2 e 8 nodi.

Esempio di numero totale di nodi

Il comando seguente, disponibile in GKE versione 1.24 o successiva, crea un cluster multi-zona a scalabilità automatica con sei nodi in tre zone inizialmente, con un minimo di tre nodi e un massimo di dodici nodi nel pool di nodi in tutte le zone:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --zone=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

In questo esempio, la dimensione totale del cluster può essere compresa tra 3 e 12 nodi, indipendentemente dalla distribuzione tra le zone.

Profili di scalabilità automatica

La decisione su quando rimuovere un nodo è un compromesso tra l'ottimizzazione per l'utilizzo e la disponibilità delle risorse. La rimozione dei nodi sottoutilizzati migliora l'utilizzo del cluster, ma i nuovi carichi di lavoro potrebbero dover attendere il provisioning delle risorse prima di poter essere eseguiti.

Puoi specificare il profilo di scalabilità automatica da utilizzare quando prendi queste decisioni. I profili disponibili sono:

balanced: il profilo predefinito che assegna la priorità al mantenimento di più risorse prontamente disponibili per i pod in entrata, riducendo così il tempo necessario per averle attive per i cluster standard. Il profilo balanced non è disponibile per i cluster Autopilot.
optimize-utilization: assegna la priorità all'ottimizzazione dell'utilizzo anziché alla conservazione delle risorse di riserva nel cluster. Quando abiliti questo profilo, il gestore della scalabilità automatica dei cluster fa lo scale down del cluster in modo più aggressivo. GKE può rimuovere più nodi e rimuoverli più rapidamente. GKE preferisce pianificare i pod in nodi che hanno già un'allocazione elevata di CPU, memoria o GPU. Tuttavia, altri fattori influiscono sulla pianificazione, come la diffusione di pod appartenenti allo stesso deployment, StatefulSet o Service, tra i nodi.

Il profilo di scalabilità automatica optimize-utilization consente al gestore della scalabilità automatica dei cluster di identificare e rimuovere i nodi sottoutilizzati. Per ottenere questa ottimizzazione, GKE imposta il nome dello scheduler nella specifica del pod su gke.io/optimize-utilization-scheduler. I pod che specificano uno scheduler personalizzato non sono interessati.

Il seguente comando abilita il profilo di scalabilità automatica di optimize-utilization in un cluster esistente:

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Valutare la pianificazione e l'interruzione dei pod

Durante lo scale down, il gestore della scalabilità automatica dei cluster rispetta le regole di pianificazione ed eliminazione impostate sui pod. Queste restrizioni possono impedire l'eliminazione di un nodo da parte del gestore della scalabilità automatica. È possibile impedire l'eliminazione di un nodo se contiene un pod con una delle seguenti condizioni:

Le regole di affinità o anti-affinità del pod impediscono la ripianificazione.
Il pod non è gestito da un controller, ad esempio un oggetto Deployment, StatefulSet, Job o ReplicaSet.
Il pod ha uno spazio di archiviazione locale e la versione del piano di controllo GKE è precedente alla 1.22. Nei cluster GKE con piano di controllo versione 1.22 o successive, i pod con archiviazione locale non bloccano più lo scale down.
Il pod ha l'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
L'eliminazione del nodo supererebbe il valore di PodDisruptionBudget configurato.

Per saperne di più sul gestore della scalabilità automatica dei cluster e su come prevenire le interruzioni, consulta le seguenti domande nelle Domande frequenti sul gestore della scalabilità automatica dei cluster:

Scalabilità automatica delle TPU in GKE

GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia il pool di nodi della sezione TPU con host singolo che il pool di nodi della sezione TPU multi-host supportano la scalabilità automatica e il provisioning automatico.

Con il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina i pool di nodi della sezione TPU a host singolo o multi-host con una versione e una topologia TPU che soddisfa i requisiti dei carichi di lavoro in attesa.

Quando utilizzi --enable-autoscaling, GKE scala il pool di nodi in base al tipo, come segue:

Pool di nodi della sezione TPU con host singolo: GKE aggiunge o rimuove i nodi TPU nel pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi come determinata dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi della sezione TPU a host singolo, consulta Creare un pool di nodi.
Pool di nodi della sezione TPU multi-host: GKE fa lo scale up atomico del pool di nodi da zero al numero di nodi necessario per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con tipo di macchina ct5lp-hightpu-4t e topologia 16x16, il pool di nodi contiene 64 nodi. Il gestore della scalabilità automatica di GKE garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante lo scale down down, GKE rimuove tutti i pod pianificati e svuota l'intero pool di nodi fino a zero. Per saperne di più su come creare un pool di nodi della sezione TPU multi-host, consulta Creare un pool di nodi.

Informazioni aggiuntive

Per saperne di più sul gestore della scalabilità automatica dei cluster, consulta le Domande frequenti sulla scalabilità automatica nel progetto Kubernetes open source.

Limitazioni

Il gestore della scalabilità automatica dei cluster ha le seguenti limitazioni:

Gli oggetti PersistentVolume locali non sono attualmente supportati dal gestore della scalabilità automatica dei cluster.
Nella versione del piano di controllo GKE precedente alla 1.24.5-gke.600, quando i pod richiedono l'archiviazione temporanea, il gestore della scalabilità automatica dei cluster non supporta lo scale up di un pool di nodi senza nodi che utilizza SSD locali come archiviazione temporanea.
Limitazioni delle dimensioni del cluster: fino a 15.000 nodi. Tieni conto di altri limiti del cluster e delle nostre best practice quando esegui cluster di queste dimensioni.
Durante lo scale down, il gestore della scalabilità automatica dei cluster rispetta un periodo di terminazione controllato di 10 minuti per ripianificare i pod del nodo su un nodo diverso prima di terminare forzatamente il nodo.
A volte, il gestore della scalabilità automatica dei cluster non può fare lo scale down completo e, dopo lo scale down, esiste un nodo in più. Questo può verificarsi quando i pod di sistema richiesti sono pianificati su nodi diversi, perché non esiste un trigger per lo spostamento di questi pod in un nodo diverso. Vedi Ho un paio di nodi con basso utilizzo, ma non è stato fatto lo scale down. Perché? Per aggirare questa limitazione, puoi configurare un budget di interruzione dei pod.
La pianificazione personalizzata con filtri alterati non è supportata.
Non sarà possibile fare lo scale up dei pod se il valore PriorityClass è inferiore a -10. Scopri di più, vedi Come funziona il gestore della scalabilità automatica dei cluster con priorità e prerilascio dei pod?
Il gestore della scalabilità automatica dei cluster potrebbe non disporre di spazio di indirizzi IP non allocato sufficiente per aggiungere nuovi nodi o pod, causando errori di scale up, indicati da eventi eventResult con il motivo scale.up.error.ip.space.exhausted. Puoi aggiungere altri indirizzi IP per i nodi espandendo la subnet principale oppure puoi aggiungere nuovi indirizzi IP per i pod utilizzando un CIDR multipod discontinuo. Per maggiori informazioni, consulta Spazio IP libero insufficiente per i pod.
Il gestore della scalabilità automatica dei cluster GKE è diverso da quello del progetto Kubernetes open source. I parametri del gestore della scalabilità automatica dei cluster GKE dipendono dalla configurazione del cluster e sono soggetti a modifiche. Se hai bisogno di un maggiore controllo sul comportamento della scalabilità automatica, disabilita il gestore della scalabilità automatica dei cluster GKE ed esegui il gestore della scalabilità automatica dei cluster di Kubernetes open source. Tuttavia, Kubernetes open source non supporta Google Cloud.

Problemi noti

Nella versione del piano di controllo GKE precedente alla 1.22, il gestore della scalabilità automatica dei cluster GKE smette di fare lo scale up di tutti i pool di nodi nei cluster vuoti (con zero nodi). Questo comportamento non si verifica in GKE 1.22 e versioni successive.