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 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.

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.

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.

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 in base al 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. Quando GKE decide quanti nodi creare, la creazione dei nodi che poi avvengono 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 tuoi pod hanno richiesto troppe poche risorse (o non hanno modificato i valori predefiniti, che potrebbero essere insufficienti) e i tuoi nodi stanno riscontrando carenze, 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.

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 probabilmente un una breve interruzione. Se i tuoi servizi non sono a tolleranza di interruzione, puoi utilizzare il gestore della scalabilità automatica dei cluster non è consigliato.
Gli utenti o gli amministratori non gestiscono manualmente i nodi, può prevalere su qualsiasi 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 i vari pool e tenta di espandere il nodo meno costoso possibile piscina. Il costo ridotto dei pool di nodi contenenti VM spot viene preso in .
Il gestore della scalabilità automatica dei cluster considera le richieste del container init prima della pianificazione di 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 Utilizzo di container init.
Le etichette aggiunte manualmente dopo la creazione iniziale del cluster o del pool di nodi non sono 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 le modifiche manuali ai nodi e al pool di nodi per 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 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.

Criteri di posizione

A partire da GKE versione 1.24.1-gke.800, puoi modificare criterio di località del gestore della scalabilità automatica dei cluster GKE. 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 considera i requisiti dei pod e la disponibilità di risorse in ogni zona. Ciò non garantisce che i gruppi di nodi simili abbiano delle stesse dimensioni, in quanto il gestore della scalabilità automatica prende in considerazione capacità disponibile in una determinata zona e affinità di zona dei pod che hanno attivato fare lo scale up.
ANY: il gestore della scalabilità automatica dà la priorità all'utilizzo delle prenotazioni inutilizzate tiene conto dei vincoli attuali delle risorse disponibili. Queste norme sono consigliata se utilizzi 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 possono essere compresi 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 profilo balanced 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 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:

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 con 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 delle 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 con 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 di 16x16, 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 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 le unità SSD locali come spazio di archiviazione temporaneo.
Limiti delle dimensioni del cluster: fino a 15.000 nodi. Considera 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 motivo scale.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 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.