Informazioni sulla scalabilità automatica dei cluster

Questa pagina spiega come 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. 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 scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti 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.

Best practice:

Pianifica e progetta la configurazione del cluster con gli amministratori e gli architetti, gli sviluppatori o un altro team della tua organizzazione responsabile dell'implementazione e della manutenzione dell'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 del cluster riduce le dimensioni a una dimensione minima da te designata. In questo modo puoi aumentare la disponibilità dei carichi di lavoro quando ne hai bisogno, tenendo sotto controllo i costi. Non è necessario aggiungere o rimuovere manualmente i nodi o eseguire un provisioning eccessivo 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 attivare l'autoscaler del cluster, progetta i carichi di lavoro in modo da tollerare potenziali interruzioni o assicurati che i pod critici non vengano interrotti.

Best practice:

Per aumentare la tolleranza del carico di lavoro alle interruzioni, esegui il deployment del carico di lavoro utilizzando un controller con più repliche, ad esempio un deployment.

Puoi aumentare le prestazioni di Cluster Autoscaler con il streaming di immagini, che consente di eseguire lo streaming dei dati delle immagini richiesti dalle immagini container idonee da remoto, memorizzando contemporaneamente l'immagine nella cache localmente per consentire l'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 per pool di nodi. Quando configuri un pool di nodi con il gestore della scalabilità automatica dei cluster, specifichi una dimensione minima e 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 istanze di macchine virtuali (VM) nel gruppo di istanze gestite (MIG) di Compute Engine sottostante per il pool di nodi. Il gestore della scalabilità automatica del 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 dei pod e dei 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 nodo piscina. Per ulteriori informazioni 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 aggiunge tutti i nodi necessari, fino a per pool di nodi o per cluster limiti.
  • Il gestore della scalabilità automatica dei cluster non attende l'avvio di un nodo prima di crearne un altro. 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 possono essere pianificati anche con meno nodi nel pool di nodi, il gestore della scalabilità automatica del cluster rimuove i nodi fino alle dimensioni minime 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 del cluster non tenta di ridurre il numero di nodi di quel nodo. Se i pod possono essere spostati in altri nodi, ma non possono essere svuotati automaticamente dopo un periodo di timeout (attualmente 10 minuti) il nodo viene 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. Nei cluster di piccole dimensioni, l'ispezione potrebbe avvenire ogni pochi secondi. Non è possibile definire un periodo di tempo esatto necessario per questa ispezione.

Se i nodi presentano carenze perché i pod hanno richiesto o impostato come predefinito risorse insufficienti, il gestore della scalabilità automatica del cluster 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. Il gestore della scalabilità automatica del cluster di GKE è distinto dalla scalabilità automatica di Compute Engine. Ciò può comportare lo scale up o lo scale down dei pool di nodi in modo anomalo perché il gestore della scalabilità automatica di Compute Engine sarà in conflitto con il gestore della scalabilità automatica del cluster di GKE.

Criteri operativi

Quando ridimensiona un pool di nodi, il gestore della scalabilità automatica dei cluster fa le seguenti supposizioni:

  • Tutti i pod replicati possono essere riavviati su un altro nodo, causando eventualmente una breve interruzione.
  • Gli utenti o gli amministratori non gestiscono manualmente i nodi. Il gestore della scalabilità automatica dei cluster può eseguire l'override di qualsiasi operazione di gestione manuale dei nodi eseguita.
  • Tutti i nodi in un singolo pool di nodi hanno lo stesso set di etichette.
  • Il gestore della scalabilità automatica dei cluster prende in considerazione il costo relativo dei tipi di istanze nei vari 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 prende in considerazione le richieste dei container di inizializzazione prima di pianificare i pod. Le richieste container di inizializzazione possono utilizzare qualsiasi risorsa non allocata disponibile dei 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 scoprire di più, consulta la documentazione di Kubernetes sull'utilizzo dei container di inizializzazione.
  • 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 del cluster vengono assegnate le etichette specificate con --node-labels al momento della creazione del pool di nodi.
  • In GKE versione 1.21 o precedente, lo strumento di scalabilità automatica del cluster considera le informazioni sull'alterazione degli attuali nodi di 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. Il gestore della scalabilità automatica dei cluster rileva anche le modifiche manuali apportate al nodo e al pool di nodi.
Best practice:

Non abilitare il gestore della scalabilità automatica dei cluster se le tue applicazioni non sono a tolleranza di interruzione.

Bilanciamento tra le 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. In questo modo si evita 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 durante 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 avranno esattamente le stesse dimensioni, perché il gestore della scalabilità automatica del cluster 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 dei cluster dà la priorità all'utilizzo delle prenotazioni inutilizzate e tiene conto dei vincoli attuali delle risorse disponibili.
Best practice:

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 hanno la priorità quando si sceglie il pool di nodi per lo scale up, anche se 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 preemptivi, 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 le dimensioni minime e massime per ogni pool di nodi del cluster e il gestore della scalabilità automatica del cluster prende decisioni di ridimensionamento in base a questi vincoli di scalabilità. Per aggiornare le dimensioni minime, imposta manualmente le dimensioni del cluster in modo che rientrino nei nuovi vincoli dopo aver specificato il nuovo 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 del cluster Vincoli di scalabilità
Inferiore al minimo specificato Il gestore della scalabilità automatica dei cluster esegue 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. L'aumento di dimensioni è disattivato. Il pool di nodi non esegue la scalabilità oltre il valore specificato.

Nei cluster standard, lo strumento di scalabilità automatica dei cluster non esegue mai lo scale down di un cluster a zero nodi automaticamente. Uno o più nodi devono essere sempre disponibili nel cluster per eseguire i pod di sistema. Inoltre, se il numero corrente 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 eseguire lo scale up da cluster senza 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 da utilizzare dal gestore della scalabilità automatica del cluster quando esegui il ridimensionamento 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 multizonale con scalabilità automatica 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, le dimensioni totali del cluster possono variare da tre a dodici nodi, distribuiti nelle tre zone. Se una delle zone non funziona, la dimensione totale del cluster può variare da due a otto nodi.

Esempio di numero totale di nodi

Il seguente comando, disponibile in GKE 1.24 o versioni successive, crea un cluster multizonale con 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ò variare da tre a dodici 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. La rimozione dei nodi sottoutilizzati migliora l'utilizzo del cluster, ma è possibile che i nuovi carichi di lavoro debbano attendere il provisioning delle risorse prima di poter essere eseguiti.

Puoi specificare quale profilo di scalabilità automatica utilizzare per prendere 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 rispetto al mantenimento di risorse di riserva nel cluster. Quando attivi questo profilo, il gestore della scalabilità automatica dei cluster riduce il numero di istanze del cluster in modo più aggressivo. GKE può rimuovere più nodi e farlo più velocemente. GKE preferisce pianificare i pod nei nodi che hanno già un'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. I pod che specificano un programma 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 la riduzione, il gestore della scalabilità automatica del cluster rispetta le regole di pianificazione ed espulsione impostate su Pods. Queste limitazioni possono impedire l'eliminazione di un nodo da parte del 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 riprogrammazione.
  • Il pod non è gestito da un controller, ad esempio un oggetto Deployment, StatefulSet, Job o ReplicaSet.
  • Il pod dispone di 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 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 il pool di nodi con sezione TPU a host singolo sia il pool di nodi con sezione TPU a più host supportano 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 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 compreso tra zero e la dimensione massima del pool di nodi, come stabilito dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU del pool hanno 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. Ad esempio, con un pool di nodi TPU con un tipo di macchina ct5lp-hightpu-4t e una topologia 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. Quando si riduce nuovamente la scalabilità, GKE esegue l'espulsione di tutti i pod pianificati e svuota l'intero 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 nelle Domande frequenti sulla scalabilità automatica nel progetto Kubernetes open source.

Limitazioni

Il gestore della scalabilità automatica del cluster presenta le seguenti limitazioni:

  • I volumi permanenti locali non sono supportati dallo strumento di scalabilità automatica del cluster.
  • Nelle versioni del piano di controllo GKE precedenti alla 1.24.5-gke.600, quando i pod richiedono spazio di archiviazione temporaneo, lo strumento di scalabilità automatica del cluster non supporta lo scale up di un pool di nodi con zero nodi che utilizza SSD locali come spazio di archiviazione temporaneo.
  • Limiti di dimensione del cluster: fino a 15.000 nodi. Tieni conto di altri limiti dei 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 interruzione graduale di 10 minuti per ripianificare i pod del nodo su un altro nodo prima di interrompere forzatamente il nodo.
  • A volte, il gestore della scalabilità automatica dei cluster non può fare lo scale down completo esistente dopo lo scale down. Ciò può verificarsi quando i pod di sistema richiesti sono pianificati su nodi diversi, perché non esiste alcun attivatore per lo spostamento di questi pod su un altro nodo. Vedi Ho un paio di nodi con un utilizzo ridotto, ma non sono ridotti. Perché? Per aggirare questa limitazione, puoi configurare Budget per l'interruzione dei pod.
  • La pianificazione personalizzata con filtri modificati non è supportata.
  • 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 avere spazio indirizzi IP non allocato sufficiente da utilizzare per aggiungere nuovi nodi o pod, con conseguenti errori di scalabilità automatica, indicati dagli eventi eventResult con il motivo scale.up.error.ip.space.exhausted. Puoi aggiungere altri indirizzi IP per i nodi espandendo la subnet principale oppure aggiungere nuovi indirizzi IP per i pod utilizzando il CIDR multi-pod non contiguo. 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 del progetto Kubernetes open source. I parametri del gestore della scalabilità automatica del 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 Gestore della scalabilità automatica dei cluster GKE ed esegui il gestore della scalabilità automatica dei cluster Kubernetes open source. Tuttavia, Kubernetes open source non è supportato da 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 su cluster vuoti (senza nodi). Questo comportamento non si verifica in GKE versione 1.22 e successive.

Passaggi successivi