Questa pagina spiega in che modo Google Kubernetes Engine (GKE) ridimensiona automaticamente 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. A scopri come configurare il gestore della scalabilità automatica dei cluster, consulta Scalabilità automatica di un cluster.
Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che pianificare capacità e esigenze infrastrutturali, nonché ottimizzare l'architettura dei sistemi per garantire il costo totale di proprietà più basso per l'azienda o in un'unità aziendale. Per saperne di più sui ruoli comuni e sulle attività di esempio che nei contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.
Con i cluster Autopilot, non devi preoccuparti il provisioning dei nodi o la gestione dei pool di nodi, perché i pool di nodi vengono automaticamente mediante il provisioning automatico dei nodi, e vengono scalati automaticamente per soddisfare i requisiti dei tuoi carichi di lavoro.
Pianifica e progetta la configurazione del cluster con gli amministratori e gli architetti della tua organizzazione, gli sviluppatori o un altro team responsabile dell'implementazione e della manutenzione della tua applicazione.
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 scala di nuovo fino a una dimensione minima da te designati. 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. Devi invece specificare un valore minimo e massimo dimensione massima per il pool di nodi, mentre il resto è automatico.
Se le risorse vengono eliminate o spostate durante la scalabilità automatica del cluster, potrebbero subire interruzioni temporanee. Ad esempio, se il carico di lavoro è costituito un controller con una singola replica, il pod di quella replica potrebbe essere ripianificato su un nodo diverso se quello attuale viene eliminato. Prima di abilitare il cluster del gestore della scalabilità automatica, progetta i carichi di lavoro in modo da tollerare le potenziali interruzioni per impedire che i pod critici vengano interrotti.
Per aumentare la tolleranza del carico di lavoro all'interruzione, esegui il deployment il carico di lavoro utilizzando un controller con più repliche, ad esempio un deployment.
Puoi aumentare le prestazioni del gestore della scalabilità automatica dei cluster con Streaming di immagini, che trasmette in remoto i dati immagine richiesti dalle immagini container idonee mentre memorizzando nella cache l'immagine in locale per consentire ai carichi di lavoro sui nuovi nodi si avvia più velocemente.
Come funziona il gestore della scalabilità automatica dei cluster
Il gestore della scalabilità automatica dei cluster funziona per pool di nodi. Quando configuri un nodo con il gestore della scalabilità automatica dei cluster, devi specificare una dimensione minima e una massima 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 richieste di risorse (anziché l'utilizzo effettivo delle risorse) dei pod in esecuzione dai nodi del pool di nodi. Controlla periodicamente lo stato dei pod nodi e agisce:
- 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 nodo piscina. Per saperne di più su quando il gestore della scalabilità automatica dei cluster modifica la dimensione vedi Quando il gestore della scalabilità automatica del cluster modifica le dimensioni di un cluster?
- Se GKE decide di aggiungere nuovi nodi al pool di nodi, il gestore della scalabilità automatica aggiunge tutti i nodi necessari, fino a un pool di nodi o al cluster limiti.
- Il gestore della scalabilità automatica dei cluster non attende la comparsa di un nodo prima di creare
il prossimo. Una volta che GKE ha deciso quanti nodi creare,
avviene in parallelo. L'obiettivo è ridurre al minimo il tempo necessario
non pianificabili in modo che diventino
Active
. - Se alcuni nodi non vengono creati a causa della quota esaurimento, il gestore della scalabilità automatica dei cluster attende il completamento pianificato correttamente.
- Se i nodi sono sottoutilizzati e tutti i pod potrebbero essere pianificati anche con meno nodi nel pool di nodi, il gestore della scalabilità automatica dei cluster rimuove i nodi, della dimensione minima del pool di nodi. Se su un nodo sono presenti pod che non possono essere spostati ad altri nodi del cluster, il gestore della scalabilità automatica dei cluster non tenta di fare lo scale down su quel nodo. Se i pod possono essere spostati in altri nodi, ma non possono essere svuotati automaticamente dopo un periodo di timeout (attualmente pari a 10 minuti) il nodo è stato terminato forzatamente. Il periodo di tolleranza non è configurabile per cluster GKE. Per ulteriori informazioni 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 ispeziona un cluster per individuare elementi non pianificabili I pod dipendono in gran parte dalle dimensioni del cluster. In cluster di piccole dimensioni, potrebbe verificarsi a intervalli di pochi secondi. Non è possibile definire un periodo di tempo esatto necessario per questa ispezione.
Se i nodi stanno riscontrando una carenza I pod hanno richiesto risorse insufficienti o per impostazione predefinita il cluster il gestore della scalabilità automatica non corregge la situazione. Puoi contribuire a garantire che la configurazione il gestore della scalabilità automatica opera nel modo più accurato possibile inviando richieste di risorse esplicite per tutti i tuoi carichi di lavoro.
Non abilitare la scalabilità automatica di Compute Engine per l'istanza gestita gruppi di archiviazione per i nodi cluster. GKE della scalabilità automatica dei cluster con la scalabilità automatica di Compute Engine. Ciò può causare errori nei pool di nodi fare lo scale up o fare lo scale down perché è in conflitto il gestore della scalabilità automatica di Compute Engine con il gestore della scalabilità automatica dei cluster GKE.
Criteri operativi
Quando ridimensiona un pool di nodi, il gestore della scalabilità automatica dei cluster fa le seguenti ipotesi:
- Tutti i pod replicati possono essere riavviati su qualche altro nodo, causando probabilmente un una breve interruzione.
- Gli utenti o gli amministratori non gestiscono manualmente i nodi. Il gestore della scalabilità automatica dei cluster può eseguire l'override le operazioni manuali di gestione dei nodi che esegui.
- Tutti i nodi in un singolo pool di nodi hanno lo stesso insieme di etichette.
- Il gestore della scalabilità automatica dei cluster considera il costo relativo dei tipi di istanza diversi pool e tenta di espandere il pool di nodi meno costoso possibile. Il gestore della scalabilità automatica dei cluster tiene conto del costo ridotto dei pool di nodi contenenti VM spot, che sono prerilasciabili.
- Il gestore della scalabilità automatica dei cluster considera le richieste del container init prima della pianificazione i pod. Le richieste container di inizializzazione possono utilizzare qualsiasi risorsa non allocata disponibile dei nodi, il che potrebbe impedire la pianificazione dei pod. Segue il gestore della scalabilità automatica dei cluster le stesse regole di calcolo delle richieste usate da Kubernetes. Per saperne di più, vedi la documentazione di Kubernetes sull'utilizzo dei container init.
- Le etichette aggiunte manualmente dopo la creazione iniziale del cluster o del pool di nodi non vengono
tracciata. 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 precedente, 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 e dai nodi esistenti nel cluster e nel pool di nodi. Gruppo il gestore della scalabilità automatica rileva anche le modifiche manuali apportate ai nodi e al pool di nodi.
Non abilitare il gestore della scalabilità automatica dei cluster se le tue applicazioni non sono a tolleranza di interruzione.
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 questo gruppo di istanze gestite di dimensioni bilanciate durante lo scale up. Ciò aiuta a evitare una distribuzione non uniforme dei nodi tra 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.
Il gestore della scalabilità automatica dei cluster esegue il bilanciamento tra le zone solo durante un evento di scale up. Il gestore della scalabilità automatica dei cluster fa lo scale down dei nodi sottoutilizzati indipendentemente delle dimensioni dei gruppi di istanze gestite sottostanti in un pool di nodi, di distribuire i nodi in modo non uniforme tra le zone.
Criteri di posizione
A partire da GKE versione 1.24.1-gke.800, puoi modificare
criteri sulla località del gestore della scalabilità automatica dei cluster. Puoi controllare
i criteri di distribuzione del gestore della scalabilità automatica dei cluster specificando location_policy
con uno qualsiasi dei seguenti valori:
BALANCED
: il gestore della scalabilità automatica dei cluster considera i requisiti dei pod e la disponibilità di risorse in ogni zona. Ciò non garantisce che i gruppi di nodi simili abbiano esattamente le stesse dimensioni, perché il gestore della scalabilità automatica dei cluster prende in considerazione molti fattori, tra cui: capacità disponibile in una determinata zona e affinità di zona dei pod che hanno attivato lo scale up.ANY
: il gestore della scalabilità automatica dei cluster dà la priorità all'utilizzo delle prenotazioni inutilizzate e tiene conto dei vincoli attuali delle risorse disponibili.
Utilizza il criterio ANY
se usi VM spot o se vuoi usare una VM
a prenotazioni diverse da una zona all'altra.
Prenotazioni
A partire dalla versione 1.27 di GKE, il gestore della scalabilità automatica dei cluster considera sempre prenotazioni quando effettui decisioni di scale up. I pool di nodi con prenotazioni inutilizzate corrispondenti la priorità al momento di scegliere il pool di nodi per lo scale up, anche quando non è il più efficiente. Inoltre, le prenotazioni inutilizzate vengono sempre con priorità quando si bilanciano gli scale up multi-zona.
Valori predefiniti
Per i pool di nodi delle VM spot,
il criterio di distribuzione predefinito del gestore della scalabilità automatica dei cluster è ANY
. In queste norme,
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 ogni pool di nodi nel tuo cluster e il gestore della scalabilità automatica dei cluster le decisioni all'interno di questi vincoli di scalabilità. Per aggiornare la dimensione minima, devi ridimensiona il cluster a una dimensione all'interno dei nuovi vincoli dopo aver specificato il nuovo il valore minimo. Il gestore della scalabilità automatica dei cluster prende quindi decisioni di ridimensionamento in base i 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 li automaticamente fa lo scale down di un cluster fino a zero nodi. Uno o più nodi devono essere sempre disponibili nel cluster per eseguire i pod di sistema. Inoltre, se il numero attuale di nodi è zero a causa della rimozione manuale dei nodi, del gestore della scalabilità automatica dei cluster e il provisioning automatico può fare lo scale up da cluster a 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 per il gestore della scalabilità automatica dei cluster
da usare durante la scalabilità di un pool di nodi. Utilizzare 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 --total-min-nodes
e --total-max-nodes
per i nuovi cluster. Questi flag impostano il valore minimo e
numero massimo del numero totale di nodi nel pool di nodi in tutte le zone.
Esempio di numero minimo e massimo di nodi
Il comando seguente crea una scalabilità automatica cluster multi-zona con sei nodi in tre zone inizialmente, 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 3 e 12 di nodi distribuiti tra le tre zone. Se una delle zone presenta errori, la dimensione totale del cluster può essere compreso tra due e otto nodi.
Esempio di numero totale di nodi
Il comando seguente, disponibile in GKE versione 1.24 o successiva, crea una scalabilità automatica cluster multi-zona inizialmente con sei nodi in tre zone, con un minimo di tre nodi 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 all'utilizzo o alla disponibilità delle risorse. Rimuovere i nodi sottoutilizzati migliora l'utilizzo del cluster, ma i nuovi carichi di lavoro potrebbero dover attendere le risorse di eseguire nuovamente il provisioning 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 dà la priorità alla conservazione di un maggior numero di risorse immediatamente disponibili per i pod in entrata, riducendo così il tempo necessario attivarli per i cluster standard. Il profilobalanced
non è disponibile per i cluster Autopilot.optimize-utilization
: dai la priorità all'ottimizzazione dell'utilizzo che alla conservazione degli spazi di riserva di risorse nel cluster. Quando abiliti questo profilo, il gestore della scalabilità automatica dei cluster fa lo scale down il cluster in modo più aggressivo. GKE può rimuovere più nodi e nodi più velocemente. GKE preferisce pianificare i pod in nodi che hanno già l'allocazione elevata di CPU, memoria o GPU. Tuttavia, ci sono altri fattori programmazione dell'influenza, come la diffusione di pod appartenenti allo stesso deployment, StatefulSet servizio tra nodi.
Il profilo di scalabilità automatica optimize-utilization
consente
il gestore della scalabilità automatica dei cluster
per identificare e rimuovere i nodi sottoutilizzati. Per raggiungere questo obiettivo
dell'ottimizzazione, GKE imposta il nome scheduler nella specifica del pod
gke.io/optimize-utilization-scheduler
. 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 che un nodo venga eliminato da gestore della scalabilità automatica. Potrebbe essere impedita l'eliminazione di un nodo se contiene un pod con di queste 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
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 nel Domande frequenti sul gestore della scalabilità automatica dei cluster:
- Come funziona lo scale down?
- Il gestore della scalabilità automatica dei cluster funziona con PodDisruptionBudget in scale down?
- Quali tipi di pod possono impedire al gestore della scalabilità automatica dei cluster di rimuovere un nodo?
- Come ottimizzare il gestore della scalabilità automatica dei cluster in GKE?
Scalabilità automatica delle TPU in GKE
GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia pool di nodi della sezione TPU a host singolo sia Il pool di nodi della sezione TPU multi-host supporta la scalabilità automatica e il provisioning automatico.
Con
--enable-autoprovisioning
su un cluster GKE,
GKE crea o elimina i pool di nodi di sezioni TPU a host singolo o multi-host con una TPU
la versione e la topologia che soddisfano 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 a host singolo: GKE aggiunge o rimuove i nodi TPU nella pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU tra zero e la dimensione massima del pool di nodi come determinato dalla --max-nodes e il --total-max-nodes e i flag facoltativi. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool ricevono lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare una TPU con host singolo una sezione del pool di nodi, consulta Creare un nodo pool.
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. Per esempio, con un pool di nodi TPU con un tipo di macchina
ct5lp-hightpu-4t
e di16x16
, il pool di nodi contiene 64 nodi. Lo strumento GKE il gestore della scalabilità automatica garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante la scalabilità di nuovo, GKE rimuove tutti i pod pianificati e svuota l'intera pool di nodi a zero. Per scoprire di più su come creare un nodo della sezione TPU multi-host consulta Creare un pool di nodi.
Informazioni aggiuntive
Puoi trovare ulteriori informazioni sul gestore della scalabilità automatica dei cluster nel 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 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 con zero nodi utilizza le unità SSD locali come spazio di archiviazione temporaneo.
- Limitazioni delle dimensioni del cluster: fino a 15.000 nodi. Tieni conto di altri limiti del cluster e le 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 la ripianificazione dei pod del nodo su un nodo diverso prima terminando forzatamente il nodo.
- A volte, il gestore della scalabilità automatica dei cluster non può fare lo scale down completo esistente dopo lo scale down. Questo può verificarsi quando i pod di sistema richiesti pianificato su nodi diversi, perché per nessuno di questi di spostare i pod su un nodo diverso. Consulta: Ho un paio di nodi con basso utilizzo, ma non è stato fatto lo scale down. Perché? Per aggirare questa limitazione, puoi configurare Budget per l'interruzione dei pod.
- Pianificazione personalizzata con filtri modificati non è supportato.
- Non è possibile fare lo scale up dei nodi se i pod hanno un oggetto
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 da utilizzare
di aggiungere nuovi nodi o pod, con conseguenti errori di scale up, indicati da
eventResult
eventi con il motivoscale.up.error.ip.space.exhausted
. Puoi aggiungere altri indirizzi IP per i nodi espandendo la subnet principale, oppure aggiungi nuovi indirizzi IP per i pod utilizzando CIDR multi-pod discontinui. Per maggiori informazioni, consulta Spazio IP libero insufficiente per i pod. - Il gestore della scalabilità automatica dei cluster GKE è diverso dal gestore della scalabilità automatica dei cluster il progetto Kubernetes open source. I parametri dell'API GKE Il gestore della scalabilità automatica dei cluster dipende dalla configurazione del cluster e sono soggetti modifica. Se hai bisogno di un maggiore controllo sul comportamento della scalabilità automatica, disabilita Gestore della scalabilità automatica dei cluster GKE ed esegui il gestore della scalabilità automatica dei cluster 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 interrompe lo scale up di tutti i pool di nodi cluster vuoti (con zero nodi). Questo comportamento non si verifica in GKE versione 1.22 e successive.
Passaggi successivi
- Scopri come scalare automaticamente i nodi.
- Scopri come eseguire l'upgrade automatico dei nodi.
- Scopri come riparare automaticamente i nodi.
- Scopri come ridurre i tempi di pull delle immagini sui nuovi nodi.