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 manualmente il provisioning dei nodi o gestire i pool di nodi, poiché GKE gestisce automaticamente la scalabilità e il provisioning 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 dei cluster GKE crea nodi solo dai pool di nodi creati dall'utente. Con il provisioning automatico dei nodi, GKE crea ed elimina automaticamente i pool di nodi.
Funzionalità non supportate
Il provisioning automatico dei nodi non crea pool di nodi che utilizzano nessuna delle funzionalità seguenti. 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.
- Controlla l'affinità della prenotazione.
- PersistentVolume locali con scalabilità automatica.
- Nodi di provisioning automatico con SSD locali come spazio di archiviazione temporaneo.
- Provisioning automatico tramite pianificazione personalizzata che utilizza filtri alterati.
- Configurare il multi-threading simultaneo (SMT).
Come funziona il provisioning automatico dei nodi
Il provisioning automatico dei nodi è un meccanismo del gestore della scalabilità automatica dei cluster, che scala solo i pool di nodi esistenti. Se il provisioning automatico dei nodi è abilitato, il gestore della scalabilità automatica dei cluster può creare automaticamente pool di nodi 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 dei cluster prevedono dei limiti ai seguenti livelli:
- Livello del pool di nodi: i pool di nodi di cui è stato eseguito il provisioning automatico sono limitati a 1000 nodi.
- Livello di cluster:
- Eventuali limiti di provisioning automatico che definisci vengono applicati in base alle risorse totali di CPU e memoria utilizzate in tutti i pool di nodi, non solo in base ai pool di cui è stato eseguito il provisioning automatico.
- Il gestore della scalabilità automatica dei 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 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 incompatibilità se vengono soddisfatte tutte le seguenti condizioni:
- Un pod in attesa richiede un nodo con una chiave e un valore di etichetta specifici.
- Il pod tollera un'incompatibilità con la stessa chiave.
- La tolleranza riguarda l'effetto
NoSchedule
, l'effettoNoExecute
o tutti gli effetti.
Per le istruzioni, consulta Configurare la separazione dei carichi di lavoro in GKE.
Eliminazione dei pool di nodi di cui è stato eseguito il provisioning automatico
Se non ci sono nodi in un pool di nodi di cui è stato eseguito il provisioning automatico, GKE lo elimina. GKE non elimina i pool di nodi di cui non è stato eseguito il provisioning automatico.
Tipi di macchine supportati
Il provisioning automatico dei nodi considera i requisiti dei pod nel cluster per determinare il tipo di nodi più adatto a quei 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 carico di lavoro richiede risorse TPU. Per saperne di più sulle TPU, consulta Introduzione a Cloud TPU.
- Il carico di lavoro utilizza l'etichetta
machine-family
. Per maggiori informazioni, consulta Utilizzo di una famiglia di macchine personalizzate.
Se il pod richiede GPU, il provisioning automatico dei nodi assegna un tipo di macchina sufficientemente grande per 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 la pagina dedicata alle 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 1.28 e versioni successive.
GPU
Se il pod richiede GPU, il provisioning automatico dei nodi assegna un tipo di macchina sufficientemente grande per 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 la pagina dedicata alle piattaforme GPU.
Cloud TPU
GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia il pool di nodi della sezione TPU con singolo host sia il pool di nodi della sezione TPU multi-host supportano la scalabilità automatica e il provisioning automatico.
Con il flag --enable-autoprovisioning
su un cluster GKE, GKE crea o elimina i pool di nodi delle sezioni TPU con singolo host o multi-host con una versione e una topologia TPU che soddisfano i requisiti dei carichi di lavoro in attesa.
Quando utilizzi --enable-autoscaling
, GKE scala il pool di nodi in base al tipo, come segue:
Pool di nodi della sezione TPU host singolo: GKE aggiunge o rimuove nodi TPU nel pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi, come stabilito dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi è scalabile, tutti i nodi TPU nel pool hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi della sezione TPU con singolo host, consulta Creare un pool di nodi.
Pool di nodi della sezione TPU multi-host: GKE fa lo scale up atomico del pool di nodi da zero al numero di nodi richiesti per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con tipo di macchina
ct5lp-hightpu-4t
e topologia16x16
, il pool di nodi contiene 64 nodi. Il gestore della scalabilità automatica di GKE assicura che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante lo scale down, GKE rimuove tutti i pod pianificati e svuota l'intero pool di nodi fino a zero. Per scoprire di più su come creare un pool di nodi della sezione TPU multi-host, consulta Creare un pool di nodi.
Se una sezione TPU specifica non contiene pod in esecuzione o in attesa di pianificazione, GKE fa lo scale down del pool di nodi. Lo scale down dei pool di nodi delle sezioni TPU multi-host viene eseguito a livello atomico. I pool di nodi della sezione TPU con host singolo vengono scalati verso il basso rimuovendo le singole sezioni TPU con singolo 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 file manifest è un esempio di specifica del deployment che genera un pool di nodi 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, TPU v4 contpu-v4-podslice
o TPU v5e contpu-v5-lite-podslice
.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 abiliti il provisioning automatico dei nodi, selezioni la topologia TPU. Per ulteriori informazioni sulle topologie Cloud TPU, consulta 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,tpu-v5-lite-podslice
con configurazione della topologia2x4
:- Se specifichi
google.com/tpu = 8
, il provisioning automatico dei nodi fa lo scale up del pool di nodi della sezione TPU con singolo host aggiungendo una macchinact5lp-hightpu-8t
. - Se specifichi
google.com/tpu = 4
, il provisioning automatico dei nodi crea un pool di nodi della sezione TPU multi-host con due macchinect5lp-hightpu-4t
.
- Se specifichi
cloud.google.com/reservation-name
: il nome della prenotazione utilizzato dal carico di lavoro. Se omesso, il carico di lavoro non utilizza alcuna prenotazione.
Se imposti tpu-v4-podslice
, il provisioning automatico dei nodi prende le seguenti decisioni:
Valori impostati nel manifest del pod | Decisione dal provisioning automatico dei nodi | |||
---|---|---|---|---|
gke-tpu-topology |
limit.google.com/tpu |
Tipo di pool di nodi | Dimensione del pool di nodi | Tipo di macchina |
2x2x1 | 4 | Sezione TPU con singolo host | Flessibile | ct4p-hightpu-4t |
{A}x{B}x{C} | 4 | Sezione TPU con più 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 superiori a 64 chip, i valori assegnati a {A}, {B} e {C} devono soddisfare le seguenti condizioni:
- {A}, {B} e {C} sono tutti minori di o uguali a quattro o multipli di quattro.
- La topologia più grande supportata è
12x16x16
. - I valori assegnati mantengono il pattern A ≤ B ≤ C. Ad esempio,
2x2x4
o2x4x4
per piccole topologie.
Se imposti tpu-v5-lite-podslice
, il provisioning automatico dei nodi prende le seguenti decisioni:
Valori impostati nel manifest del pod | Decisione dal provisioning automatico dei nodi | |||
---|---|---|---|---|
gke-tpu-topology |
limit.google.com/tpu |
Tipo di pool di nodi | Dimensione del pool di nodi | Tipo di macchina |
1x1 | 1 | Sezione TPU con singolo host | Flessibile | ct5lp-hightpu-1t |
2x2 | 4 | Sezione TPU con singolo host | Flessibile | ct5lp-hightpu-4t |
2x4 | 8 | Sezione TPU con singolo host | Flessibile | ct5lp-hightpu-8t |
2x41 | 4 | Sezione TPU con più host | 2 (4/8) | ct5lp-hightpu-4t |
4x4 | 4 | Sezione TPU con più host | 4 (16/4) | ct5lp-hightpu-4t |
4x8 | 4 | Sezione TPU con più host | 8 (32/4) | ct5lp-hightpu-4t |
4x8 | 4 | Sezione TPU con più host | 16 (32/4) | ct5lp-hightpu-4t |
8x8 | 4 | Sezione TPU con più host | 16 (64/4) | ct5lp-hightpu-4t |
8x16 | 4 | Sezione TPU con più host | 32 (128/4) | ct5lp-hightpu-4t |
16x16 | 4 | Sezione TPU con più 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 | Decisione dal provisioning automatico dei nodi | |||
---|---|---|---|---|
gke-tpu-topology |
limit.google.com/tpu |
Tipo di pool di nodi | Dimensione del pool di nodi | Tipo di macchina |
1x1 | 1 | Sezione TPU con singolo host | Flessibile | ct5l-hightpu-1t |
2x2 | 4 | Sezione TPU con singolo host | Flessibile | ct5l-hightpu-4t |
2x4 | 8 | Sezione TPU con singolo host | Flessibile | ct5l-hightpu-8t |
Per scoprire come configurare il provisioning automatico dei nodi, consulta Configurare le TPU.
Supporto per le VM spot
Il provisioning automatico dei nodi supporta la creazione di pool di nodi basati sulle VM spot.
La creazione di pool di nodi basati su VM spot viene considerata solo se esistono pod non pianificabili con una tolleranza per l'incompatibilità cloud.google.com/gke-spot="true":NoSchedule
. L'incompatibilità viene applicata automaticamente ai nodi nei pool di nodi di cui è stato eseguito il provisioning automatico basati su VM spot.
Puoi combinare l'uso della tolleranza con una regola di affinità nodo nodeSelector
o di affinità 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 garantire che i tuoi carichi di lavoro vengano eseguiti solo su pool di nodi basati sulle 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. Queste dimensioni del disco di avvio possono essere personalizzate.
Il valore predefinito è 100 GiB. L'archiviazione temporanea supportata da SSD locali non è supportata.
Il provisioning automatico dei nodi esegue il provisioning di un pool di nodi solo se lo spazio di archiviazione temporaneo allocabile di un nodo con un disco di avvio specificato è superiore o uguale alla richiesta di archiviazione temporanea di un pod in attesa. Se la richiesta di archiviazione temporanea è superiore all'importo allocabile, il provisioning automatico dei nodi non eseguirà il provisioning di un pool di nodi. Le dimensioni dei dischi per i nodi non sono configurate in modo dinamico in base alle richieste di archiviazione temporanee dei pod in attesa.
Limitazioni della scalabilità
Il provisioning automatico dei nodi presenta le stesse limitazioni del gestore della scalabilità automatica dei cluster, nonché le seguenti limitazioni aggiuntive:
- Limite al numero di carichi di lavoro separati
- Il provisioning automatico dei nodi supporta un massimo di 100 carichi di lavoro separati distinti.
- Limite al numero di pool di nodi
- Il provisioning automatico dei nodi riduce la priorità della creazione di nuovi pool di nodi quando il numero di pool nel cluster si avvicina a 100. È possibile creare oltre 100 pool di nodi, ma solo quando si crea un pool di nodi è l'unica opzione per pianificare un pod in attesa.
Passaggi successivi
- Scopri di più su come abilitare il provisioning automatico dei nodi
- Scopri di più sul gestore della scalabilità automatica dei cluster