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

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

Con i cluster Autopilot, non devi preoccuparti del provisioning dei nodi o della gestione dei pool di nodi perché i pool di nodi vengono sottoposti a provisioning 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 come funzionano le richieste e i limiti delle risorse.

Best practice:

Pianifica e progetta la configurazione del cluster con gli amministratori e gli architetti, gli sviluppatori o altri team della tua organizzazione responsabili dell'implementazione e della manutenzione della tua applicazione.

Perché utilizzare il gestore della scalabilità automatica dei cluster

Il gestore della scalabilità automatica dei cluster di GKE ridimensiona automaticamente il numero di nodi in un determinato pool di nodi, in base alle esigenze dei tuoi carichi di lavoro. Quando la domanda è bassa, il gestore della scalabilità automatica dei cluster riduce di nuovo le dimensioni fino a un valore minimo che hai designato. 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. Invece, devi specificare una dimensione minima e massima per ilpool di nodil e 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 tuo workload è costituito da un controller con una singola replica, il pod di questa replica potrebbe essere ripianificato su un nodo diverso se il nodo attuale viene eliminato. Prima di abilitare lo scalatore automatico del cluster, progetta i tuoi workload in modo che tollerino potenziali interruzioni o assicurati che i pod critici non vengano interrotti.

Best practice:

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

Puoi aumentare le prestazioni del gestore della scalabilità automatica dei cluster con lo streaming di immagini, che trasmette in streaming da remoto i dati delle immagini richiesti dalle immagini container idonee memorizzando contemporaneamente l'immagine nella cache locale per consentire l'avvio più rapido dei workload 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 riduce automaticamente le dimensioni del pool di nodi aggiungendo o rimuovendo le 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 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 vengono 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 pool di nodi, il gestore della scalabilità automatica dei 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 creare il successivo. Una volta che GKE decide quanti nodi creare, la creazione dei nodi 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, Cluster Autoscaler attende finché le risorse non possono essere pianificate correttamente.
  • Se i nodi sono sottoutilizzati e tutti i pod potrebbero essere pianificati anche con un numero inferiore di 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 in altri nodi del cluster, il gestore della scalabilità automatica del cluster non tenta difare lo scale downi di quel nodo. Se i pod possono essere spostati su altri nodi, ma il nodo non può essere svuotato in modo controllato dopo un periodo di timeout (attualmente 10 minuti), il nodo viene terminato forzatamente. Il periodo di tolleranza non è configurabile per i cluster GKE. Per ulteriori informazioni sul funzionamento dello fare lo scale down, consulta la documentazione sul gestore della scalabilità automatica dei cluster.

La frequenza con cui il gestore della scalabilità automatica dei cluster ispeziona un cluster alla ricerca di 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 richiesto per questa ispezione.

Se i nodi sono in carenza perché i pod hanno richiesto o impostato risorse insufficienti, 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 effettuando richieste di risorse esplicite per tutti i tuoi carichi di lavoro.

Non abilitare la scalabilità automatica di Compute Engine per i gruppi di istanze gestite per i nodi del cluster. Il gestore della scalabilità automatica dei cluster di GKE è separato dalla scalabilità automatica di Compute Engine. Ciò può comportare un errore di scale up o fare lo scale down dei node pool perché il gestore della scalabilità automatica di Compute Engine sarà in conflitto con il gestore della scalabilità automatica del cluster GKE.

Criteri operativi

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

  • Tutti i pod replicati possono essere riavviati su un altro nodo, causando possibilmente una breve interruzione.
  • Gli utenti o gli amministratori non gestiscono manualmente i nodi. Il gestore della scalabilità automatica dei cluster può ignorare qualsiasi operazione di gestione manuale 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 prende in considerazione il costo relativo dei tipi di istanza nei vari pool e tenta di espandere il pool di nodi meno costoso possibile. Tuttavia, a questo comportamento dello strumento di scalabilità automatica del cluster si applicano le seguenti condizioni:
    • Il gestore della scalabilità automatica dei cluster tiene conto del costo ridotto dei pool di nodi che contengono VM spot, che sono prerilasciabili. Tuttavia, il gestore della scalabilità automatica del cluster considera anche la disponibilità di risorse in ogni zona e potrebbe scegliere la risorsa più costosa, ma disponibile.
    • Quando più node pool utilizzano VM spot, il gestore della scalabilità automatica del cluster non seleziona automaticamente l'opzione più economica. Per ottimizzare l'utilizzo delle VM spot economiche ed evitare questo scenario, ti consigliamo di utilizzare le classi di calcolo personalizzate.
  • Il gestore della scalabilità automatica dei cluster prende in considerazione le richieste dei container init prima di pianificare i pod. Le richieste di container init possono utilizzare qualsiasi risorsa non allocata disponibile sui nodi, il che potrebbe impedire la pianificazione dei pod. Il gestore della scalabilità automatica del cluster segue le stesse regole di calcolo delle richieste utilizzate da Kubernetes. Per saperne 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 precedenti, lo strumento di scalabilità automatica dei cluster considera le informazioni di taint dei nodi esistenti di unpool di nodil per rappresentare l'interopool di nodil. 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 abilitare il gestore della scalabilità automatica dei cluster se le tue applicazioni non sono tolleranti alle interruzioni.

Bilanciamento tra le zone

Se il tuo 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 bilanciate le dimensioni di questi gruppo di istanze gestite durante lo scale up. Ciò contribuisce a evitare 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 la policy di scalabilità automatica durante la riduzione della scalabilità.

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 esegue lo scale down dei 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 tra le 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à automatica del cluster specificando il flag location_policy con uno 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 degli attuali vincoli delle risorse disponibili.
Best practice:

Utilizza il criterio ANY se utilizzi VM spot o se vuoi utilizzare prenotazioni di VM che non sono 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à verticale. I node pool con prenotazioni inutilizzate corrispondenti hanno la priorità quando si sceglie il pool di nodi di cui eseguire lo scale up, anche se il pool di nodi non è il più efficiente. Inoltre, le prenotazioni inutilizzate vengono sempre assegnate la priorità quando si bilanciano gli aumenti di scalabilità multizona.

Tuttavia, il gestore della scalabilità automatica dei cluster controlla le prenotazioni solo nel proprio progetto. Di conseguenza, se è disponibile un'opzione di nodo meno costosa all'interno del progetto del cluster, lo strumento di scalabilità automatica potrebbe selezionarla al posto della prenotazione condivisa. Se devi condividere le prenotazioni tra i progetti, valuta la possibilità di utilizzare le classi di calcolo personalizzate, che ti consentono di configurare la priorità utilizzata dal gestore della scalabilità automatica dei cluster per scalare i nodi, comprese le prenotazioni condivise.

Valori predefiniti

Per i pool di nodi 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 node pool non preemptive, il criterio di distribuzione predefinito del gestore della scalabilità automatica dei cluster è BALANCED.

Dimensione minima e massima del node pool

Quando crei un nuovo pool di nodi, puoi specificare la dimensione minima e massima per ogni pool di nodi nel 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, ridimensiona manualmente il cluster a una dimensione compresa nei 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.

Dimensioni attuali del pool di nodi Azione del gestore della scalabilità automatica dei cluster Vincoli di scalabilità
Inferiore al minimo specificato Il gestore della scalabilità automatica del cluster esegue lo scale up per eseguire il provisioning dei pod in attesa. La riduzione delle dimensioni è disattivata. Il pool di nodi non viene fare lo scale down 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 pool di nodi rimane entro i limiti di dimensioni specificati.
Superiore al massimo specificato Il gestore della scalabilità automatica del cluster esegue lo scale down solo dei nodi che possono essere rimossi in sicurezza. Lo scale up è disattivato. Il pool di nodi non viene scalato al di sopra del valore specificato.

Nei cluster Standard, il gestore della scalabilità automatica del cluster non esegue mai lo scale down automatico di un cluster 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, il gestore della scalabilità automatica del cluster e il provisioning automatico dei nodi possono scalare i cluster da zero nodi.

Per saperne di più sulle decisioni del gestore della scalabilità automatica, consulta 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 del cluster deve utilizzare durante 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 nodi minimi e massimi

Il seguente comando crea un cluster multizona con sei nodi inizialmente 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 \
    --location=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 tre e dodici nodi, distribuiti nelle tre zone. Se una delle zone non funziona, la dimensione totale del cluster può essere compresa tra due e otto nodi.

Esempio di totale nodi

Il seguente comando, disponibile in GKE 1.24 o versioni successive, crea un cluster multizona con scalabilità automatica con sei nodi in tre zone inizialmente, con un minimo di tre nodi e un massimo di dodici nodi npool di nodiool in tutte le zone:

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=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 tre e 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 workload debbano attendere il provisioning delle risorse prima di poter essere eseguiti.

Puoi specificare quale profilo di scalabilità automatica utilizzare quando prendi queste decisioni. I profili disponibili sono:

  • balanced: il profilo predefinito che dà la priorità a mantenere più risorse facilmente disponibili per i pod in entrata e quindi a ridurre il tempo necessario per renderli attivi 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 abiliti questo profilo, il gestore della scalabilità automatica dei cluster riduce le dimensioni del cluster in modo più aggressivo. GKE può rimuovere più nodi e rimuoverli più rapidamente. GKE preferisce pianificare i pod nei nodi che hanno già un'allocazione elevata di CPU, memoria o GPU. Tuttavia, altri fattori influenzano la pianificazione, come la distribuzione dei pod appartenenti allo stesso deployment, StatefulSet o servizio tra i nodi.

Il profilo di scalabilità automatica optimize-utilization aiuta il gestore della scalabilità automatica del cluster a 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 optimize-utilization in un cluster esistente:

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

Considerazioni sulla pianificazione e sull'interruzione dei pod

Durante la riduzione della scalabilità, il gestore della scalabilità automatica del cluster rispetta le regole di pianificazione e 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 qualsiasi di queste condizioni:

  • Le regole di affinità o anti-affinità del pod impediscono la riprogrammazione.
  • Il pod non è gestito da un controller come un deployment, uno StatefulSet, un job o un ReplicaSet.
  • Il pod dispone di spazio di archiviazione locale e la versione del control plane GKE è precedente alla 1.22. Nei cluster GKE con versione del control plane 1.22 o successive, i pod con spazio di archiviazione locale non bloccano più la riduzione della scalabilità.
  • 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 node pool di sezioni TPU single-host sia il node pool di sezioni TPU multi-host supportano la scalabilità automatica e il provisioning automatico.

Con il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina node pool di sezioni TPU single-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 suo tipo, come segue:

  • Pool di nodi della sezione TPU single-host: GKE aggiunge o rimuove i nodi TPU nel node pool esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi determinata dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool di nodi hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi TPU a host singolo, consulta Creare un node pool.

  • Pool di nodi della sezione TPU multi-host: GKE aumenta in modo atomico il pool di nodi da zero al numero di nodi necessari 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 di scalabilità automatica di GKE garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Quando esegui lo scale down, GKE espelle 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 TPU multi-host, consulta Crea un pool di nodi.

VM spot e gestore della scalabilità automatica del cluster

Poiché il gestore della scalabilità automatica dei cluster preferisce espandere i node pool meno costosi, quando i workload e la disponibilità delle risorse lo consentono, il gestore della scalabilità automatica dei cluster 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 tuoi pod venga eseguita su questi tipi di VM. Le VM spot possono essere prerilasciate. A causa di questo prelazione, i pod sulle VM spot hanno maggiori probabilità di essere eliminati. Quando vengono sfrattati, hanno solo 15 secondi per terminare.

Ad esempio, immagina uno scenario in cui hai 10 pod e un mix 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 i 10 pod, quindi il gestore della scalabilità automatica dei cluster rimuove due pod e arresta 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 ridurre di nuovo lo scale down, è probabile che le VM spot vengano prerilasciate 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à più alta rispetto ai nodi on demand. Per massimizzare ulteriormente la probabilità che i tuoi 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 assegnare 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 computing abilita anche activeMigration, consentendo al gestore della scalabilità automatica dei cluster di eseguire la migrazione dei carichi di lavoro alle VM spot quando la capacità diventa disponibile.

Se non puoi utilizzare le classi di calcolo personalizzate, aggiungi un taint, una tolleranza o un'affinità dei nodi. Ad esempio, la seguente regola di affinità dei nodi dichiara una preferenza per la pianificazione dei pod sui nodi supportati da VM spot (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à, incompatibilità e tolleranze dei nodi per pianificare le VM spot, consulta il post del blog Esecuzione di un'applicazione GKE su nodi spot con nodi on demand come fallback.

CRD ProvisioningRequest

Una ProvisioningRequest è una risorsa personalizzata con spazio dei nomi che consente agli utenti di richiedere capacità per un gruppo di pod dal gestore della scalabilità automatica del cluster. Questa funzionalità è particolarmente utile per le applicazioni con pod interconnessi che devono essere pianificati insieme come una singola unità.

Corsi di cui è stato eseguito il provisioning supportati

Esistono tre ProvisioningClass supportate:

  • queued-provisioning.gke.io: questa classe specifica per GKE si integra con Dynamic Workload Scheduler, 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 AI con Dynamic Workload Scheduler per scoprire come utilizzare il provisioning in coda in GKE. Supportato a partire 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 a partire dalla versione GKE 1.30.2-gke.1468000.

  • best-effort-atomic.autoscaling.x-k8s.io: questa classe open source tenta di eseguire il provisioning di tutte le risorse dei pod nella richiesta. Se è impossibile 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 a partire dalla versione 1.31.27 di GKE.

Per saperne 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 solo un PodTemplate per ProvisioningRequest.
  • Il gestore della scalabilità automatica dei cluster GKE può scalare solo un pool di nodi alla volta. Se ProvisioningRequest richiede risorse da più pool di nodi, devi creare ProvisioningRequest 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 dalla tua applicazione.
  • Utilizza location-policy=ANY: questa impostazione consente di pianificare i pod in qualsiasi posizione disponibile, il che può accelerare il provisioning e ottimizzare l'utilizzo delle risorse.
  • (Facoltativo) Integra Kueue: Kueue può automatizzare la creazione di ProvisioningRequest, semplificando il tuo flusso di lavoro. Per saperne di più, consulta la documentazione di Kueue.

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 del cluster presenta le seguenti limitazioni:

  • I volumi permanenti locali non sono supportati da Cluster Autoscaler.
  • Nella versione del control plane GKE precedente 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.
  • Limitazioni delle dimensioni del cluster: fino a 15.000 nodi. Tieni conto degli altri limiti del cluster e delle nostre best practice quando esegui cluster di queste dimensioni.
  • Durante lo scale down, il gestore della scalabilità automatica del cluster rispetta un periodo di terminazione controllata di 10 minuti per ripianificare i pod del nodo su un nodo diverso prima di terminare forzatamente il nodo.
  • A volte, il gestore della scalabilità automatica del cluster non riesce a eseguire completamente fare lo scale down e rimane un nodo aggiuntivo dopo lo scale down. Ciò può verificarsi quando i pod di sistema richiesti vengono pianificati su nodi diversi, perché non esiste alcun trigger per spostare i pod su un nodo diverso. Vedi Ho un paio di nodi con un utilizzo ridotto, ma non vengono ridimensionati. Perché? Per ovviare a questa limitazione, puoi configurare un budget di interruzione dei pod.
  • La pianificazione personalizzata con Filtri modificati non è supportata.
  • Cluster Autoscaler considera il comportamento predefinito di kube-scheduler quando decide di eseguire il provisioning di nuovi nodi per i pod in attesa. L'utilizzo di scheduler personalizzati non è supportato e potrebbe comportare un comportamento di scalabilità imprevisto.
  • I nodi non vengono 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 preemption dei pod?
  • Il gestore della scalabilità automatica dei cluster potrebbe non disporre di spazio di 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 primaria o aggiungere nuovi indirizzi IP per i pod utilizzando il CIDR multi-pod non contiguo. Per saperne di più, vedi Spazio IP libero insufficiente per i pod.
  • Il gestore della scalabilità automatica del cluster GKE è diverso dal gestore della scalabilità automatica del cluster del progetto Kubernetes open source. I parametri del gestore della scalabilità automatica dei cluster GKE dipendono dalla configurazione del cluster e sono soggetti a modifiche. Se hai bisogno di un maggiore controllo sul comportamento di scalabilità automatica, disattiva il gestore della scalabilità automatica del cluster GKE ed esegui il gestore della scalabilità automatica del cluster di Kubernetes open source. Tuttavia, Kubernetes open source non ha Google Cloud supporto.
  • Quando elimini un pool di nodi GKE con la scalabilità automatica abilitata, i nodi ricevono il flag NoSchedule e tutti i pod su questi nodi vengono rimossi immediatamente. Per mitigare la riduzione improvvisa delle risorse disponibili, il gestore della scalabilità automatica del pool di nodi potrebbe eseguire il provisioning di nuovi nodi all'interno dello stesso pool di nodi. Questi nodi appena creati diventano disponibili per la pianificazione e i pod rimossi vengono ripianificati su di essi. Alla fine, viene eliminato l'intero pool di nodi, inclusi i nodi di cui è stato eseguito il provisioning e i relativi pod, il che può causare potenziali interruzioni del servizio. Come soluzione alternativa, per impedire al gestore della scalabilità automatica di eseguire il provisioning di nuovi nodi durante l'eliminazione, disattiva la scalabilità automatica sul node pool prima di avviare l'eliminazione.

Problemi noti

  • Nella versione del piano di controllo GKE precedente alla 1.22, il gestore della scalabilità automatica del cluster GKE interrompe lo scale up di tutti i node pool sui cluster vuoti (con zero nodi). Questo comportamento non si verifica in GKE versione 1.22 e successive.

Risoluzione dei problemi

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

Passaggi successivi