Informazioni sulla scalabilità automatica dei cluster GKE

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. Per imparare a configurare il gestore della scalabilità automatica del cluster, consulta Scalabilità automatica di un cluster.

Questa pagina è rivolta ad amministratori, architetti e operatori che pianificano le esigenze di capacità e infrastruttura e ottimizzano l'architettura e le risorse dei sistemi per ottenere il costo totale di proprietà più basso per la propria azienda o unità aziendale. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Con i cluster Autopilot, non devi preoccuparti di eseguire il provisioning dei nodi o gestire i pool di nodi perché il provisioning dei pool di nodi viene eseguito automaticamente tramite il provisioning automatico dei nodi e vengono scalati automaticamente per soddisfare i requisiti dei tuoi carichi di lavoro.

Prima di leggere questa pagina, assicurati di conoscere i concetti di base di Kubernetes e il funzionamento delle richieste e dei limiti delle risorse.

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 che hai specificato. 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. Specifica invece una dimensione minima e massima per il pool di nodi e il resto è automatico.

Se le risorse vengono eliminate o spostate durante la scalabilità automatica del cluster, i carichi di lavoro potrebbero subire interruzioni transitorie. Ad esempio, se il tuo workload è costituito da un controller con una singola replica, il pod di questa replica potrebbe essere riprogrammato su un altro nodo se il nodo corrente viene eliminato. Prima di attivare l'autoscaler del cluster, progetta i tuoi workload 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 i pod non riescono a essere pianificati su nessuno dei nodi attuali, il gestore della scalabilità automatica del cluster aggiunge nodi, fino alle dimensioni massime del pool di nodi. 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 node pool, il gestore della scalabilità automatica del cluster aggiunge tutti i nodi necessari, fino ai limiti per node pool o per cluster.
  • Il gestore della scalabilità automatica dei cluster non attende l'avvio di un nodo prima di crearne un altro. Una volta che GKE decide quanti nodi creare, la creazione avviene in parallelo. L'obiettivo è ridurre al minimo il tempo necessario affinché i pod non pianificabili diventino Active.
  • Se alcuni nodi non vengono creati a causa dell'esaurimento della quota, il gestore della scalabilità automatica del cluster attende che le risorse possano essere 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 del cluster non tenta di ridurre il numero di nodi di quel nodo. Se i pod possono essere spostati su altri nodi, ma il nodo non può essere svuotato in modo ordinato dopo un periodo di timeout (attualmente 10 minuti), il nodo viene interrotto forzatamente. Il periodo di tolleranza non è configurabile per i cluster GKE. Per ulteriori informazioni sul funzionamento della riduzione della scalabilità, consulta la documentazione del gestore della scalabilità automatica dei cluster.

La frequenza con cui il gestore della scalabilità automatica del cluster ispeziona un cluster per rilevare i pod non pianificabili dipende 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 ad assicurare 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.

Non abilitare la scalabilità automatica per i gruppi di istanze gestite di Compute Engine per i nodi del 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 dei cluster di GKE.

Criteri di funzionamento

Quando ridimensioni 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 insieme 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 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 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 monitorate. 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 le informazioni dei 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 attivare il gestore della scalabilità automatica dei cluster se le tue applicazioni non sono tolleranti alle interruzioni.

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 del cluster tenta di mantenere bilanciati i relativi dimensioni durante il ridimensionamento in aumento. 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 la riduzione.

Il gestore della scalabilità automatica del cluster esegue il bilanciamento tra le zone solo durante un evento di scale up. Il gestore della scalabilità automatica del cluster riduce i nodi sottoutilizzati indipendentemente dalle dimensioni relative dei gruppi di istanze gestite sottostanti in un pool di nodi, il che può causare una distribuzione non uniforme dei nodi nelle zone.

Policy di posizione

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

  • BALANCED: il gestore della scalabilità automatica dei cluster prende in considerazione 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 utilizzi VM spot o se vuoi utilizzare prenotazioni VM non uguali tra le zone.

Prenotazioni

A partire dalla versione 1.27 di GKE, il gestore della scalabilità automatica del cluster prende sempre in considerazione le prenotazioni quando prende le decisioni di scalabilità verso l'alto. I node pool con prenotazioni inutilizzate corrispondenti hanno la priorità quando si sceglie il node pool da aumentare, anche se non è il più efficiente. Inoltre, le prenotazioni inutilizzate hanno sempre la priorità quando si esegue il bilanciamento degli upgrade multizonali.

Valori predefiniti

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

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

Dimensione minima e massima del node pool

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 ai nuovi vincoli.

Dimensioni attuali del node pool Azione del gestore della scalabilità automatica dei cluster Vincoli di scalabilità
Più basso del valore minimo specificato Il gestore della scalabilità automatica dei cluster esegue lo scale up per eseguire il provisioning dei pod in attesa. Il ridimensionamento verso il basso è disattivato. Il node pool non esegue lo scale down al di sotto del valore specificato.
All'interno delle dimensioni minime e massime specificate Il gestore della scalabilità automatica del cluster esegue lo scale up o lo scale down in base alla domanda. Il node pool rientra nei limiti di dimensioni specificati.
Superiore al valore massimo specificato Il gestore della scalabilità automatica dei cluster esegue lo scale down solo dei nodi che possono essere rimossi in sicurezza. L'aumento di dimensioni è disattivato. Il pool di nodi non viene scalato 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. Nel cluster devono essere sempre disponibili uno o più nodi per l'esecuzione dei 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 del 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 le limitazioni 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 node pool in tutte le zone.

Esempio di nodi minimi e massimi

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 nodi totali

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 dell'utilizzo e la 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à al mantenimento di più risorse disponibili per i pod in arrivo e, di conseguenza, riduce il tempo necessario per attivarle 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 nodi 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, altri fattori influiscono sulla pianificazione, come la distribuzione dei 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 un programmatore personalizzato non sono interessati.

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

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

Prendere in considerazione 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. 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 come 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 il piano di controllo versione 1.22 o successive, i pod con spazio di archiviazione locale non bloccano più il ridimensionamento verso il basso.
  • Il pod ha l'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "false".
  • L'eliminazione del nodo supererebbe il PodDisruptionBudget configurato.

Per ulteriori informazioni sul gestore della scalabilità automatica dei cluster e sulla prevenzione delle interruzioni, consulta le seguenti domande nelle domande frequenti sul gestore della scalabilità automatica dei cluster:

Scalabilità automatica delle TPU in GKE

GKE supporta le Tensor Processing Unit (TPU) 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 il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina pool di nodi di sezioni TPU mono 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 a un solo host: 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 stabilito dagli indicatori --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 un node pool di slice TPU con un solo host, consulta Creare un node pool.

  • Pool di nodi della sezione TPU multi-host: GKE esegue lo scaling 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 un tipo di macchina ct5lp-hightpu-4t e una topologia 16x16, il pool di nodi contiene 64 nodi. L'autoscaling GKE garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Quando si riduce 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 pool di nodi con sezioni TPU su più host, consulta Creare un pool di nodi.

VM spot e gestore della scalabilità automatica del cluster

Poiché il gestore della scalabilità automatica dei cluster preferisce espandere i pool di nodi meno costosi, se i tuoi carichi di lavoro lo consentono, aggiunge VM spot durante lo scale up.

Tuttavia, anche se il gestore della scalabilità automatica del cluster preferisce aggiungere VM spot, questa preferenza non garantisce che la maggior parte dei pod verrà eseguita su questi tipi di VM. Le VM spot possono essere prelevate. A causa di questo prelievo, i pod sulle VM spot hanno maggiori probabilità di essere espulsi. Quando vengono espulsi, hanno solo 15 secondi per uscire.

Ad esempio, immagina uno scenario in cui hai 10 pod e una combinazione di VM on demand e spot:

  • Inizi con 10 pod in esecuzione su VM on demand perché le VM spot non erano disponibili.
  • Non hai bisogno di tutti e 10 i pod, quindi il gestore della scalabilità automatica dei cluster rimuove due pod e spegne le VM on demand aggiuntive.
  • Quando hai di nuovo bisogno di 10 pod, il gestore della scalabilità automatica dei cluster aggiunge VM Spot (perché sono più economiche) e pianifica due pod su queste VM. Gli altri otto pod rimangono sulle VM on demand.
  • Se il gestore della scalabilità automatica del cluster deve eseguire nuovamente la riduzione della scalabilità, è probabile che le VM spot vengano prelevate per prime, lasciando la maggior parte dei pod in esecuzione su VM on demand.

Per dare la priorità alle VM spot ed evitare lo scenario precedente, ti consigliamo di utilizzare le classi di calcolo personalizzate. Le classi di calcolo personalizzate ti consentono di creare regole di priorità che favoriscono le VM spot durante lo scale-up assegnando loro una priorità superiore rispetto ai nodi on demand. Per massimizzare ulteriormente la probabilità che i pod vengano eseguiti su nodi supportati da VM spot, configura la migrazione attiva.

L'esempio seguente mostra un modo per utilizzare le classi di calcolo personalizzate per dare la priorità alle VM spot:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

Nell'esempio precedente, la regola di priorità dichiara una preferenza per la creazione di nodi con il tipo di macchina g2-standard-24 e le VM Spot. Se le VM Spot non sono disponibili, GKE utilizza le VM on demand come opzione di riserva. Questa classe di calcolo abilita anche activeMigration, consentendo al gestore della scalabilità automatica del cluster di eseguire la migrazione dei carichi di lavoro alle VM spot quando la capacità diventa disponibile.

Se non puoi utilizzare classi di calcolo personalizzate, aggiungi un'affinità, un'alterazione o una tolleranza del nodo. Ad esempio, la seguente regola di affinità dei nodi dichiara una preferenza per la pianificazione dei pod sui nodi supportati da VM a pagamento per utilizzo (GKE aggiunge automaticamente l'etichetta cloud.google.com/gke-spot=true a questi tipi di nodi):

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

Per scoprire di più sull'utilizzo di affinità dei nodi, incompatibilità e tolleranze per pianificare le VM spot, consulta il blog Eseguire un'applicazione GKE su nodi spot con nodi on demand come fallback.

CRD ProvisioningRequest

Una richiesta di provisioning è una risorsa personalizzata con nome nello spazio dei nomi che consente agli utenti di richiedere la capacità per un gruppo di pod dal gestore della scalabilità automatica del cluster. Questo è particolarmente utile per le applicazioni con pod interconnessi che devono essere pianificati insieme come un'unica unità.

Classi di provisioning supportate

Esistono tre ProvisioningClasses supportati:

  • queued-provisioning.gke.io: questa classe specifica per GKE si integra con la pianificazione dei carichi di lavoro dinamici, ti consente di mettere in coda le richieste e di soddisfarle quando le risorse diventano disponibili. Questa opzione è ideale per job batch o carichi di lavoro tolleranti ai ritardi. Consulta Esegui il deployment di GPU per carichi di lavoro batch e di IA con Dynamic Workload Scheduler per scoprire come utilizzare il provisioning in coda in GKE. Supportato dalla versione GKE 1.28.3-gke.1098000 nei cluster standard e dalla versione GKE 1.30.3-gke.1451000 nei cluster Autopilot.

  • check-capacity.autoscaling.x-k8s.io: questa classe open source verifica la disponibilità delle risorse prima di tentare di pianificare i pod. Supportato dalla versione GKE 1.30.2-gke.1468000.

  • best-effort-atomic.autoscaling.x-k8s.io: questo corso open source tenta di eseguire il provisioning delle risorse di tutti i pod nella richiesta. Se non è possibile eseguire il provisioning di risorse sufficienti per tutti i pod, non verrà eseguito il provisioning di alcuna risorsa e l'intera richiesta non andrà a buon fine. Supportato dalla versione 1.31.27 di GKE.

Per scoprire di più sulle classi CheckCapacity e BestEffortAtomicScaleUp, consulta la documentazione open source.

Limitazioni relative all'utilizzo di ProvisioningRequest

  • Il gestore della scalabilità automatica dei cluster GKE supporta un solo PodTemplate per ProvisioningRequest.
  • Il gestore della scalabilità automatica dei cluster GKE può eseguire lo scale up di un solo node pool alla volta. Se la richiesta di provisioning richiede risorse di più pool di nodi, devi creare richieste di provisioning separate per ogni pool di nodi.

Best practice per l'utilizzo di ProvisioningRequest

  • Utilizza total-max-nodes: anziché limitare il numero massimo di nodi (--max nodes), utilizza --total-max-nodes per limitare le risorse totali consumate dall'applicazione.
  • Utilizza location-policy=ANY: questa impostazione consente di pianificare i pod in qualsiasi località disponibile, il che può velocizzare il provisioning e ottimizzare l'utilizzo delle risorse.
  • (Facoltativo) Integrazione con Kueue: Kueue può automatizzare la creazione di ProvisioningRequests, semplificando il flusso di lavoro. Per ulteriori informazioni, consulta la documentazione di Kueue.

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 dall'autoscaler 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 del cluster non può eseguire lo scale down completamente e dopo lo scale down esiste un nodo aggiuntivo. 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 ovviare a questo limite, puoi configurare un budget di interruzione dei pod.
  • La pianificazione personalizzata con filtri modificati non è supportata.
  • I nodi non verranno scalati se i pod hanno un valore PriorityClass inferiore a -10. Scopri di più in Come funziona il gestore della scalabilità automatica dei cluster con la priorità e la prelazione 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 scale up, 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 ulteriori 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, disattiva GKE Cluster Autoscaler ed esegui Cluster Autoscaler di Kubernetes open source. Tuttavia, Kubernetes open source non è Google Cloud supportato.

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 sui cluster vuoti (senza nodi). Questo comportamento non si verifica in GKE versione 1.22 e successive.

Risoluzione dei problemi

Per consigli sulla risoluzione dei problemi, consulta le seguenti pagine:

Passaggi successivi