Informazioni sulla scalabilità automatica dei cluster

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é viene eseguito automaticamente il provisioning dei pool di nodi tramite il provisioning automatico dei nodi e la scalabilità viene eseguita 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 riduce lo scale down alle dimensioni minime da te indicate. Ciò 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 le dimensioni minima e massima per il pool di nodi, mentre 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 un'unica 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 tuoi carichi di lavoro in modo da tollerare potenziali interruzioni o assicurati che i pod critici non vengano interrotti.

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

Come funziona il gestore della scalabilità automatica dei cluster

Il gestore della scalabilità automatica dei cluster funziona sulla base del pool di nodi. Quando configuri un pool di nodi con il gestore della scalabilità automatica dei cluster, specifichi 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 sottostante di Compute Engine 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 i pod non sono pianificabili perché il pool di nodi non dispone di un numero sufficiente di nodi, il gestore della scalabilità automatica dei cluster aggiunge nodi, fino alla dimensione massima del pool.
  • Se i nodi sono sottoutilizzati e tutti i pod possono essere pianificati anche con meno nodi nel pool, il gestore della scalabilità automatica dei cluster rimuove i nodi fino al limite delle dimensioni minime del pool di nodi. Se su un nodo sono presenti pod che non possono essere spostati in altri nodi del cluster, il gestore della scalabilità automatica dei cluster non tenta di fare lo scale down del nodo. Se è possibile spostare i pod su altri nodi, ma quest'ultimo non può essere svuotato automaticamente dopo un periodo di timeout (attualmente di 10 minuti), il nodo viene arrestato forzatamente. Il periodo di tolleranza non è configurabile per i cluster GKE. Per ulteriori informazioni su come funziona lo fare lo scale down, consulta la documentazione relativa al gestore della scalabilità automatica dei cluster.

Se i tuoi pod hanno richiesto un numero insufficiente di risorse (o non hanno modificato i valori predefiniti, che potrebbero non essere sufficienti) e i tuoi nodi sono carenti, il gestore della scalabilità automatica del cluster non corregge la situazione. Puoi contribuire a garantire che il gestore della scalabilità automatica dei cluster funzioni 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 esegue le seguenti ipotesi durante il ridimensionamento di un pool di nodi:

  • Tutti i pod replicati possono essere riavviati su altri nodi, causando probabilmente una breve interruzione. Se i tuoi servizi non sono a tolleranza di interruzioni, non è consigliabile utilizzare il gestore della scalabilità automatica dei cluster.
  • Gli utenti o gli amministratori non gestiscono manualmente i nodi, ma possono sostituire qualsiasi operazione manuale di gestione dei nodi che esegui.
  • Tutti i nodi in un singolo pool di nodi hanno lo stesso set di etichette.
  • Il gestore della scalabilità automatica dei cluster considera il costo relativo dei tipi di istanza nei vari pool e tenta di espandere il pool di nodi meno costoso. Viene preso in considerazione il costo ridotto dei pool di nodi contenenti VM spot.
  • Il gestore della scalabilità automatica dei cluster considera le richieste dei container init prima di pianificare i pod. Le richieste di container di inizializzazione 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 usate da Kubernetes. Per scoprire di più, consulta Utilizzare i 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 1.21 o versioni precedenti, il gestore della scalabilità automatica dei cluster considera le informazioni sull'incompatibilità dei nodi esistenti 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 le informazioni provenienti dai nodi esistenti nel cluster e dal pool di nodi. Il gestore della scalabilità automatica del cluster rileva le modifiche manuali ai nodi e al pool di nodi per 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 considera i criteri di scalabilità automatica durante lo scale down.

Criteri di posizione

A partire dalla versione 1.24.1-gke.800 di GKE, puoi modificare i criteri di località del gestore della scalabilità automatica dei cluster GKE. Puoi controllare il criterio 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 considera i requisiti dei pod e la disponibilità di 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 inutilizzate e tiene conto degli attuali vincoli delle risorse disponibili. Questo criterio è consigliato se usi VM spot o se vuoi usare prenotazioni di VM diverse da una zona all'altra.

Prenotazioni

A partire dalla versione 1.27 di GKE, il gestore della scalabilità automatica dei cluster tiene sempre conto delle prenotazioni quando prende le decisioni di scale up. Ai pool di nodi con prenotazioni inutilizzate corrispondenti viene assegnata la priorità nella scelta del pool di nodi di cui fare lo scale up, anche quando il pool di nodi non è il più efficiente. Inoltre, le prenotazioni inutilizzate hanno sempre la priorità durante il bilanciamento degli 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 questo criterio, le VM spot hanno un rischio inferiore di essere prerilasciate.

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 cluster e il gestore della scalabilità automatica dei cluster prende decisioni di ridimensionamento all'interno di questi vincoli di scalabilità. Per aggiornare la dimensione minima, ridimensiona manualmente il cluster a una dimensione entro i nuovi vincoli dopo aver specificato il nuovo valore minimo. Il gestore della scalabilità automatica dei cluster prende quindi decisioni di scalabilità 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 è disattivato. Lo fare lo scale down del pool di nodi non è inferiore al valore specificato.
Entro le dimensioni minima e massima 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 dimensione specificati.
Maggiore del massimo specificato Il gestore della scalabilità automatica dei cluster fa lo scale down solo dei nodi che possono essere rimossi in sicurezza. Lo scale up è disattivato. Il pool di nodi non scala al di sopra del valore specificato.

Nei cluster standard, il gestore della scalabilità automatica dei cluster non fa mai automaticamente lo scale down di un cluster a zero nodi. Nel cluster devono essere sempre disponibili uno o più nodi per eseguire i 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 saperne di più sulle decisioni del gestore della scalabilità automatica, consulta le limitazioni 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 deve utilizzare per scalare un pool di nodi. Usa 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 inizialmente sei nodi in 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 3 e 12 nodi, distribuiti nelle tre zone. Se si verifica un errore in una delle zone, la dimensione totale del cluster può essere compresa tra due e otto nodi.

Esempio di nodi totali

Il seguente comando, disponibile in GKE versione 1.24 o successive, crea un cluster multi-zona a scalabilità automatica con inizialmente sei nodi in tre zone, 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 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 per l'esecuzione potrebbe essere necessario attendere il provisioning delle risorse per i nuovi carichi di lavoro.

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

  • balanced: il profilo predefinito per i cluster standard. Il profilo balanced non è disponibile per i cluster Autopilot.
  • optimize-utilization: privilegia l'ottimizzazione dell'utilizzo anziché la conservazione delle risorse di riserva nel cluster. Se 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ù velocemente. GKE preferisce pianificare i pod in nodi con un'allocazione elevata di CPU, memoria o GPU. Tuttavia, altri fattori influenzano la pianificazione, come la diffusione di pod appartenenti allo stesso deployment, StatefulSet o servizio, 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

Considerare la pianificazione e l'interruzione dei pod

Durante lo scale down, il gestore della scalabilità automatica dei cluster rispetta le regole di pianificazione ed rimozione impostate sui pod. Queste limitazioni possono impedire l'eliminazione di un nodo da parte del gestore della scalabilità automatica. L'eliminazione di un nodo potrebbe essere impedita se contiene un pod con una 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 deployment, uno StatefulSet, un job o un ReplicaSet.
  • Il pod ha 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 limite di PodDisruptionBudget configurato.

Per ulteriori informazioni 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:

TPU con scalabilità automatica 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 singolo host sia 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 delle sezioni TPU con singolo host o multi-host con una versione e una topologia TPU 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 host singolo: GKE aggiunge o rimuove 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 stabilito dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi è scalabile, 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 con singolo host, 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 richiesti 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 assicura che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante lo scale down, GKE rimuove tutti i pod pianificati e svuota l'intero pool di nodi fino a zero. Per scoprire 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 presenta le seguenti limitazioni:

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 nei cluster vuoti (nessun nodo). Questo comportamento non si verifica in GKE 1.22 e versioni successive.

Passaggi successivi