Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni sul provisioning automatico dei nodi

Standard

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 pool di nodi perché GKE gestisce automaticamente il provisioning e la scalabilità dei nodi.

Perché utilizzare il provisioning automatico dei nodi

Il provisioning automatico dei nodi gestisce e scala automaticamente un insieme di pool di nodi per conto dell'utente. Senza il provisioning automatico dei nodi, il gestore della scalabilità automatica del cluster GKE crea i nodi solo dai pool di nodi 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 create pool di nodi che utilizzano le seguenti funzionalità. Tuttavia, il gestore della scalabilità automatica dei cluster scala i nodi nei pool di nodi esistenti con le seguenti funzionalità:

GKE Sandbox.
Sistemi operativi Windows.
Controllo dell'affinità delle prenotazioni.
Scalabilità automatica dei PersistentVolume locali.
Provisioning automatico dei nodi con unità SSD locali come spazio di archiviazione temporaneo.
Provisioning automatico tramite pianificazione personalizzata che utilizza Filtri modificati.
Configurazione del multi-threading simultaneo (SMT).

Come funziona il provisioning automatico dei nodi

Il provisioning automatico dei nodi è un meccanismo del gestore della 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 i node pool in base alle specifiche dei pod non pianificabili.

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

Richieste di risorse di CPU, memoria e spazio di archiviazione temporaneo.
Richieste GPU.
Affinità dei nodi e selettori di etichette dei pod in attesa.
Incompatibilità e tolleranze dei nodi dei pod in attesa.

Limiti delle risorse

Il provisioning automatico dei nodi e il gestore della scalabilità automatica del cluster hanno limiti ai seguenti livelli:

A livello di pool di nodi: i pool di nodi con provisioning automatico sono limitati a 1000 nodi.
A livello di cluster:
- Eventuali limiti di provisioning automatico che definisci vengono applicati in base alle risorse di CPU e memoria totali utilizzate in tutti i pool di nodi, non solo nei pool con provisioning automatico.
- Il gestore della scalabilità automatica del cluster non crea nuovi nodi se ciò supererebbe uno dei limiti definiti. Se i limiti sono già stati superati, GKE non elimina i nodi.

Separazione dei carichi di lavoro

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 pool di nodi con etichette e contaminazioni se sono soddisfatte tutte le seguenti condizioni:

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

Per le istruzioni, consulta Configurare la separazione dei carichi di lavoro in GKE.

Limitazioni dell'utilizzo delle etichette per la separazione dei carichi di lavoro

Il provisioning automatico dei nodi attiva la creazione di nuovi pool di nodi quando utilizzi le etichette supportate dal provisioning automatico dei nodi, ad esempio cloud.google.com/gke-spot o le famiglie di macchine. Puoi utilizzare altre etichette nei manifest dei pod per restringere i nodi su cui GKE posiziona i pod, ma GKE non le utilizzerà per il provisioning di nuovi pool di nodi. Per l'elenco delle etichette che non attivano esplicitamente la creazione del pool di nodi, consulta Limitazioni della separazione dei carichi di lavoro con mancate convalide e tolleranze.

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

Quando non sono presenti nodi in un pool di nodi con provisioning automatico, GKE lo elimina. GKE non elimina i node pool non sottoposti a 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 applichi una delle seguenti condizioni:

Il carico di lavoro richiede una funzionalità non disponibile nella serie di macchine E2. Ad esempio, se il carico di lavoro richiede una GPU, per il nuovo pool di nodi viene utilizzata la serie di macchine N1.
Il workload richiede risorse TPU. Per scoprire di più sulle TPU, consulta l'introduzione a Cloud TPU.
Il carico di lavoro utilizza l'etichetta machine-family. Per ulteriori informazioni, consulta Utilizzare una famiglia di macchine personalizzata.

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.

Immagini dei nodi supportate

Il provisioning automatico dei nodi crea pool di nodi 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

Cloud TPU

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 dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU del pool hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi 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.

Se una sezione TPU specifica non ha pod in esecuzione o in attesa di essere pianificati, GKE riduce il pool di nodi. I pool di nodi con sezione TPU multi-host vengono ridotti in modo atomico. I pool di nodi con sezioni TPU a host singolo vengono ridotti rimuovendo i singoli sezioni TPU a host singolo.

Quando attivi 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 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 una delle seguenti opzioni:
- TPU v4 con tpu-v4-podslice
- TPU v5e con tpu-v5-lite-podslice.
- TPU v6e con tpu-v6e-slice. TPU v6e è in anteprima.
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, seleziona la topologia TPU. Per maggiori informazioni sulle topologie Cloud TPU, consulta la sezione Configurazioni TPU.
limit.google.com/tpu: il numero di chip TPU nella 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 esegue il ridimensionamento up del pool di nodi con slice TPU a host singolo 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 multi-host con due macchine ct5lp-hightpu-4t.
cloud.google.com/reservation-name: il nome della prenotazione utilizzata dal workload. Se omesso, il carico di lavoro non utilizza alcuna prenotazione.

Se imposti la versione 6e (disponibile in Anteprima), il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod		Determinato 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 a host singolo	Flessibile	`ct6e-standard-1t`
2x2	4	Sezione TPU a host singolo	Flessibile	`ct6e-standard-4t`
2x4	8	Sezione TPU a host singolo	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 tpu-v4-podslice, il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod		Determinato 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 a host singolo	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 {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 come4x4x4. Se utilizzi topologie più grandi di 64 chip, i valori assegnati a {A}, {B} e {C} devono soddisfare le seguenti condizioni:

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

Se imposti tpu-v5-lite-podslice, il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod		Determinato 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 a host singolo	Flessibile	`ct5lp-hightpu-1t`
2x2	4	Sezione TPU a host singolo	Flessibile	`ct5lp-hightpu-4t`
2x4	8	Sezione TPU a host singolo	Flessibile	`ct5lp-hightpu-8t`
2x4¹	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`

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

Se imposti il tipo di acceleratore su tpu-v5-lite-device, il provisioning automatico dei nodi prende le seguenti decisioni:

Valori impostati nel manifest del pod		Determinato 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 a host singolo	Flessibile	`ct5l-hightpu-1t`
2x2	4	Sezione TPU a host singolo	Flessibile	`ct5l-hightpu-4t`
2x4	8	Sezione TPU a host singolo	Flessibile	`ct5l-hightpu-8t`

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 pool di nodi 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. L'alterazione viene applicata automaticamente ai nodi dei node pool di cui è stato eseguito il provisioning automatico e che si basano su VM Spot.

Puoi combinare l'utilizzo della tolleranza con una regola di affinità dei nodi nodeSelector o 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 workload vengano eseguiti solo su pool di nodi basati su VM Spot.

Supporto per i pod che richiedono spazio di archiviazione temporaneo

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

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

Il provisioning automatico dei nodi eseguirà il provisioning di un pool di nodi solo se lo spazio di archiviazione temporaneo allocabile di un nodo con un disco di avvio specificato è maggiore o uguale alla richiesta di spazio di archiviazione temporaneo di un pod in attesa. Se la richiesta di spazio di archiviazione temporaneo è superiore a quella allocabile, il provisioning automatico dei nodi non eseguirà il provisioning di un pool di nodi. 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 dell'autoscaling del cluster, nonché i seguenti limiti aggiuntivi:

Limite al numero di carichi di lavoro separati: Il provisioning automatico dei nodi supporta un massimo di 100 workload distinti e separati.
Limite al numero di pool di nodi: Il provisioning automatico dei nodi riduce la priorità della creazione di nuovi node pool quando il numero di pool nel cluster si avvicina a 100. È possibile creare più di 100 pool di nodi, ma solo se la creazione di un pool di nodi è l'unica opzione per pianificare un pod in attesa.