Informazioni sul provisioning automatico dei nodi

Questa pagina spiega come funziona il provisioning automatico dei nodi nei cluster Google Kubernetes Engine (GKE) standard. Con il provisioning automatico dei nodi, i nodi vengono scalati automaticamente per soddisfare i requisiti dei tuoi carichi di lavoro.

Con i cluster Autopilot, non è necessario eseguire il provisioning manuale dei nodi o gestire i node pool perché GKE gestisce automaticamente lo scaling e il provisioning dei nodi.

Perché utilizzare il provisioning automatico dei nodi

Il provisioning automatico dei nodi gestisce e scala automaticamente un insieme di node pool per conto dell'utente. Senza il provisioning automatico dei nodi, il gestore della scalabilità automatica dei cluster GKE crea nodi solo dai node pool creati dall'utente. Con il provisioning automatico dei nodi, GKE crea ed elimina automaticamente i node pool.

Funzionalità non supportate

Il provisioning automatico dei nodi non crea node pool che utilizzano una delle seguenti funzionalità. Tuttavia, il gestore della scalabilità automatica ridimensiona i nodi nei node pool esistenti con queste funzionalità:

Come funziona il provisioning automatico dei nodi

Il provisioning automatico dei nodi è un meccanismo dello strumento di scalabilità automatica del cluster. Il gestore della scalabilità automatica dei cluster scala solo i node pool esistenti. Con il provisioning automatico dei nodi abilitato, il gestore della scalabilità automatica dei cluster può creare automaticamente node pool in base alle specifiche dei pod non pianificabili.

Il provisioning automatico dei nodi crea i pool di nodi in base alle seguenti informazioni:

Limiti delle risorse

Il provisioning automatico dei nodi e lo strumento di scalabilità automatica del cluster hanno limiti ai seguenti livelli:

  • A livello di node pool: i node pool di cui è stato eseguito il provisioning automatico sono limitati a 1000 nodi.
  • Livello di cluster:
    • I limiti di provisioning automatico che definisci vengono applicati in base alle risorse totali di CPU e memoria utilizzate in tutti i node pool, non solo in quelli con provisioning automatico.
    • Il gestore della scalabilità automatica del cluster non crea nuovi nodi se ciò supera uno dei limiti definiti. Se i limiti sono già stati superati, GKE non elimina i nodi.

Separazione dei workload

Se i pod in attesa hanno affinità e tolleranze dei nodi, il provisioning automatico dei nodi può eseguire il provisioning dei nodi con etichette e incompatibilità corrispondenti.

Il provisioning automatico dei nodi potrebbe creare node pool con etichette e taint se si verificano tutte le seguenti condizioni:

  • Un pod in attesa richiede un nodo con una chiave e un valore di etichetta specifici.
  • Il pod ha una tolleranza per un'incompatibilità con la stessa chiave.
  • La tolleranza è per l'effetto NoSchedule, l'effetto NoExecute o tutti gli effetti.

Per istruzioni, consulta la sezione Configurare la separazione dei workload in GKE.

Limitazioni dell'utilizzo delle etichette per la separazione dei workload

Il provisioning automatico dei nodi attiva la creazione di un nuovo pool di nodi quando utilizzi etichette supportate dal provisioning automatico dei nodi, come cloud.google.com/gke-spot o famiglie di macchine. Puoi utilizzare altre etichette nei manifest dei pod per restringere i nodi su cui GKE posiziona i pod, ma GKE non utilizzerà queste etichette per eseguire il provisioning di nuovi pool di nodi. Per l'elenco delle etichette che non attivano esplicitamente la creazione del pool di nodi, vedi Limitazioni della separazione dei workload con taint e tolleranze.

Eliminazione dei node pool di cui è stato eseguito il provisioning automatico

Quando non ci sono nodi in un pool di nodi di cui è stato eseguito il provisioning automatico, GKE elimina ilpool di nodil. GKE non elimina i node pool che non sono sottoposti al provisioning automatico.

Tipi di macchine supportati

Il provisioning automatico dei nodi prende in considerazione i requisiti dei pod nel cluster per determinare il tipo di nodi più adatto a questi pod.

Per impostazione predefinita, GKE utilizza la serie di macchine E2, a meno che non si verifichi una delle seguenti condizioni:

Se il pod richiede GPU, il provisioning automatico dei nodi assegna un tipo di macchina sufficientemente grande da supportare il numero di GPU richieste dal pod. Il numero di GPU limita la CPU e la memoria che il nodo può avere. Per ulteriori informazioni, consulta Piattaforme GPU.

I tipi di macchine C4D sono supportati con GKE versione 1.32.3-gke.1717000 e successive, mentre i tipi di macchine C3D sono supportati con GKE versione 1.28 e successive.

Immagini dei nodi supportate

Il provisioning automatico dei nodi crea node pool utilizzando una delle seguenti immagini dei nodi:

  • Container-Optimized OS (cos_containerd).
  • Ubuntu (ubuntu_containerd).

Acceleratori di machine learning supportati

Il provisioning automatico dei nodi può creare pool di nodi con acceleratori hardware come GPU e Cloud TPU. Il provisioning automatico dei nodi supporta le TPU in GKE versione 1.28 e successive.

GPU

Se il pod richiede GPU, il provisioning automatico dei nodi assegna un tipo di macchina sufficientemente grande da supportare il numero di GPU richieste dal pod. Il numero di GPU limita la CPU e la memoria che il nodo può avere. Per ulteriori informazioni, consulta Piattaforme GPU.

Cloud TPU

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.

Se una sezione TPU specifica non ha pod in esecuzione o in attesa di essere pianificati, GKE riduce il pool di nodi. I node pool delle sezioni TPU multi-host vengono ridimensionati in modo atomico. I node pool di sezioni TPU single-host vengono ridotti rimuovendo le singole sezioni TPU single-host.

Quando abiliti il provisioning automatico dei nodi con le TPU, GKE prende decisioni di scalabilità in base ai valori definiti nella richiesta del pod. Il seguente manifest è un esempio di specifica di Deployment che genera un node pool contenente una sezione di TPU v4 con una topologia 2x2x2 e due macchine ct4p-hightpu-4t:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: tpu-workload
      labels:
        app: tpu-workload
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx-tpu
      template:
        metadata:
          labels:
            app: nginx-tpu
        spec:
          nodeSelector:
            cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
            cloud.google.com/gke-tpu-topology: 2x2x2
            cloud.google.com/reservation-name: my-reservation
          containers:
          - name: nginx
            image: nginx:1.14.2
            resources:
              requests:
                google.com/tpu: 4
              limits:
               google.com/tpu: 4
            ports:
            - containerPort: 80

Dove:

  • cloud.google.com/gke-tpu-accelerator: la versione e il tipo di TPU. Ad esempio, puoi utilizzare uno dei seguenti metodi:
    • TPU v4 con tpu-v4-podslice
    • TPU v5e con tpu-v5-lite-podslice.
    • TPU v5p con tpu-v5p-slice.
    • TPU Trillium (v6e) con tpu-v6e-slice.
  • cloud.google.com/gke-tpu-topology: il numero e la disposizione fisica dei chip TPU all'interno di una sezione TPU. Quando crei un pool di nodi e attivi il provisioning automatico dei nodi, selezioni la topologia TPU. Per maggiori informazioni sulle topologie Cloud TPU, consulta la sezione Configurazioni TPU.
  • limit.google.com/tpu: il numero di chip TPU sulla VM TPU. La maggior parte delle configurazioni ha un solo valore corretto. Tuttavia, la configurazione della topologia tpu-v5-lite-podslice con 2x4:
    • Se specifichi google.com/tpu = 8, il provisioning automatico dei nodi aumenta le dimensioni del pool di nodi della sezione TPU single-host aggiungendo una macchina ct5lp-hightpu-8t.
    • Se specifichi google.com/tpu = 4, il provisioning automatico dei nodi crea un pool di nodi di sezioni TPU multihost con due macchine ct5lp-hightpu-4t.
  • cloud.google.com/reservation-name: il nome della prenotazione utilizzata dal carico di lavoro. Se omesso, il carico di lavoro non utilizza alcuna prenotazione.

Se imposti il tipo di acceleratore su tpu-v6e-slice (per indicare TPU Trillium), il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod Deciso dal provisioning automatico dei nodi
gke-tpu-topology limit.google.com/tpu Tipo di pool di nodi Dimensioni del node pool Tipo di macchina
1x1 1 Sezione TPU single-host Flessibile ct6e-standard-1t
2x2 4 Sezione TPU single-host Flessibile ct6e-standard-4t
2x4 8 Sezione TPU single-host Flessibile ct6e-standard-8t
2x4 4 Sezione TPU multi-host 2 ct6e-standard-4t
4x4 4 Sezione TPU multi-host 4 ct6e-standard-4t
4x8 4 Sezione TPU multi-host 8 ct6e-standard-4t
8x8 4 Sezione TPU multi-host 16 ct6e-standard-4t
8x16 4 Sezione TPU multi-host 32 ct6e-standard-4t
16x16 4 Sezione TPU multi-host 64 ct6e-standard-4t

Se imposti il tipo di acceleratore su tpu-v4-podslice (per indicare TPU v4), il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod Deciso dal provisioning automatico dei nodi
gke-tpu-topology limit.google.com/tpu Tipo di pool di nodi Dimensioni del node pool Tipo di macchina
2x2x1 4 Sezione TPU single-host Flessibile ct4p-hightpu-4t
{A}x{B}x{C} 4 Sezione TPU multi-host {A}x{B}x{C}/4 ct4p-hightpu-4t

Il prodotto di {A}x{B}x{C} definisce il numero di chip nel pool di nodi. Ad esempio, puoi definire una piccola topologia di 64 chip con combinazioni come 4x4x4. Se utilizzi topologie più grandi di 64 chip, i valori che assegni a {A}, {B} e {C} devono soddisfare le seguenti condizioni:

  • {A}, {B} e {C} sono tutti inferiori o uguali a quattro oppure multipli di quattro.
  • La topologia più grande supportata è 12x16x16.
  • I valori assegnati mantengono il pattern A ≤ B ≤ C. Ad esempio, 2x2x4 o 2x4x4 per topologie di piccole dimensioni.

Se imposti il tipo di acceleratore su tpu-v5-lite-podslice (per indicare TPU v5e con tipi di macchine che iniziano con ct5lp-), il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod Deciso dal provisioning automatico dei nodi
gke-tpu-topology limit.google.com/tpu Tipo di pool di nodi Dimensioni del node pool Tipo di macchina
1x1 1 Sezione TPU single-host Flessibile ct5lp-hightpu-1t
2x2 4 Sezione TPU single-host Flessibile ct5lp-hightpu-4t
2x4 8 Sezione TPU single-host Flessibile ct5lp-hightpu-8t
2x41 4 Sezione TPU multi-host 2 (8/4) ct5lp-hightpu-4t
4x4 4 Sezione TPU multi-host 4 (16/4) ct5lp-hightpu-4t
4x8 4 Sezione TPU multi-host 8 (32/4) ct5lp-hightpu-4t
4x8 4 Sezione TPU multi-host 16 (32/4) ct5lp-hightpu-4t
8x8 4 Sezione TPU multi-host 16 (64/4) ct5lp-hightpu-4t
8x16 4 Sezione TPU multi-host 32 (128/4) ct5lp-hightpu-4t
16x16 4 Sezione TPU multi-host 64 (256/4) ct5lp-hightpu-4t

  1. Caso speciale in cui il tipo di macchina dipende dal valore definito nel campo google.com/tpu dei limiti. ↩

Per scoprire come configurare il provisioning automatico dei nodi, consulta Configurazione delle TPU.

Supporto per le VM spot

Il provisioning automatico dei nodi supporta la creazione di node pool basati su VM spot.

La creazione di pool di nodi basati su VM spot viene presa in considerazione solo se esistono pod non pianificabili con una tolleranza per l'incompatibilità cloud.google.com/gke-spot="true":NoSchedule. Il taint viene applicato automaticamente ai nodi nei node pool di cui è stato eseguito il provisioning automatico basati su VM spot.

Puoi combinare l'utilizzo della tolleranza con una regola di affinità dei nodi nodeSelector per le etichette dei nodi cloud.google.com/gke-spot="true" o cloud.google.com/gke-provisioning=spot (per i nodi che eseguono GKE versione 1.25.5-gke.2500 o successive) per assicurarti che i tuoi carichi di lavoro vengano eseguiti solo sui node pool basati su VM spot.

Supporto per i pod che richiedono spazio di archiviazione temporanea

Il provisioning automatico dei nodi supporta la creazione di node pool quando i pod richiedono spazio di archiviazione temporaneo. La dimensione del disco di avvio di cui è stato eseguito il provisioning nei node pool è costante per tutti i nuovi node pool di cui è stato eseguito il provisioning automatico. Questa dimensione del disco di avvio può essere personalizzata.

Il valore predefinito è 100 GiB. L'archiviazione temporanea supportata da SSD locali non è supportata.

Il provisioning automatico dei nodi eseguirà il provisioning di un pool di nodi solo se lo spazio di archiviazione effimero allocabile di un nodo con un disco di avvio specificato è maggiore o uguale alla richiesta di spazio di archiviazione effimero di un pod in attesa. Se la richiesta di spazio di archiviazione effimero è superiore a quella allocabile, il provisioning automatico dei nodi non eseguirà il provisioning di upool di nodiol. Le dimensioni dei dischi per i nodi non vengono configurate dinamicamente in base alle richieste di archiviazione temporanea dei pod in attesa.

Limitazioni di scalabilità

Il provisioning automatico dei nodi presenta le stesse limitazioni del gestore della scalabilità automatica del cluster.

Devi anche prendere in considerazione i limiti pool di nodi per i carichi di lavoro distinti. Un workload distinto si riferisce all'utilizzo della separazione dei workload per indicare a GKE di separare i pod su nodi diversi, posizionare i pod su nodi che soddisfano criteri specifici o pianificare workload specifici insieme.

Il provisioning automatico dei nodi preferisce sempre utilizzare pool di nodi esistenti e compatibili anziché crearne uno nuovo. L'importanza di questa preferenza aumenta man mano che il numero di pool di nodi nel cluster cresce. Man mano che il numero di node pool distinti si avvicina al limite supportato, il provisioning automatico dei nodi assegna una priorità inferiore alla creazione di nuovi node pool. Per saperne di più sui limiti dei cluster, consulta la sezione Limiti e best practice della pagina Pianificare cluster di grandi dimensioni.

Per i cluster con molti requisiti di workload diversi, consigliamo di utilizzare classi di calcolo personalizzate.

Passaggi successivi