Introduzione alle TPU in GKE
I clienti di Google Kubernetes Engine (GKE) possono ora creare pool di nodi Kubernetes contenenti pod TPU v4 e v5e. Un pod TPU è un gruppo di dispositivi TPU collegati da interconnessioni ad alta velocità. È diverso dal pod Kubernetes, che è l'unità di computing più piccola di cui è possibile eseguire il deployment che puoi creare e gestire in Kubernetes. Per i carichi di lavoro che non richiedono un pod di TPU completo, puoi utilizzare un sottoinsieme di un pod di TPU completo chiamato sezione TPU. Come i pod TPU completi, ogni dispositivo TPU in una sezione ha la propria VM TPU. Ci riferiamo a una VM TPU e al relativo dispositivo connesso come host o nodo TPU. Per ulteriori informazioni sui pod TPU, consulta Architettura di sistema.
Poiché il termine pod utilizzato nel contesto di GKE indica in genere un pod Kubernetes, per evitare confusione, faremo sempre riferimento a una raccolta di uno o più dispositivi TPU come sezione.
Quando lavori con GKE, devi prima creare un cluster GKE.
Quindi aggiungi pool di nodi al cluster. I pool di nodi GKE sono raccolte di VM che condividono gli stessi attributi. Per i carichi di lavoro TPU, i pool di nodi sono costituiti da VM TPU.
Tipi di pool di nodi
GKE supporta due tipi di pool di nodi TPU:
Pool di nodi della sezione TPU multi-host
Un pool di nodi della sezione TPU multi-host è un pool di nodi che contiene due o più VM TPU interconnesse. A ogni VM è connesso un dispositivo TPU. Le TPU in una sezione multi-host sono connesse tramite un'interconnessione ad alta velocità (ICI). Un pool di nodi della sezione TPU multi-host è immutabile. Una volta creato un pool di nodi della sezione multi-host, non puoi aggiungervi nodi. Ad esempio,
non puoi creare un pool di nodi v4-32
e poi aggiungere in un secondo momento un ulteriore nodo
Kubernetes (VM TPU) al pool di nodi. Per aggiungere un'ulteriore sezione TPU a un cluster GKE, devi creare un nuovo pool di nodi.
Gli host in un pool di nodi della sezione TPU multi-host vengono trattati come una singola unità atomica. Se GKE non è in grado di eseguire il deployment di un nodo della sezione, non verrà eseguito il deployment di tutti i nodi nella sezione.
Se è necessario riparare un nodo in una sezione TPU multi-host, GKE arresta tutte le VM TPU (nodi) nella sezione, forzando l'eliminazione di tutti i pod Kubernetes nel carico di lavoro. Quando tutte le VM TPU nella sezione sono operative, è possibile pianificare i pod di Kubernetes sulle VM TPU nella nuova sezione.
Il seguente diagramma mostra un esempio di sezione TPU multi-host v5litepod-16 (v5e). Questa sezione ha quattro VM TPU. Ogni VM TPU ha quattro chip TPU v5e connessi con interconnessioni ad alta velocità (ICI) e ogni chip TPU v5e ha un chip TensorCore.
Il seguente diagramma mostra un cluster GKE contenente una sezione TPU v5litepod-16
(v5e) (topologia: 4x4) e una sezione TPU v5litepod-8
(v5e) (topologia: 2x4):
Per un esempio di esecuzione di un carico di lavoro su una sezione TPU multi-host, consulta Eseguire il carico di lavoro su una sezione TPU multi-host.
Pool di nodi della sezione TPU con singolo host
Un pool di nodi di sezione con singolo host è un pool di nodi che contiene una o più VM TPU indipendenti. A ciascuna di queste VM è connesso un dispositivo TPU. Mentre le VM all'interno di un pool di nodi della sezione con un singolo host possono comunicare tramite la rete di data center (DCN), le TPU collegate alle VM non sono interconnesse.
Il seguente diagramma mostra un esempio di sezione TPU con singolo host con sette macchine v4-8
:
Per un esempio di esecuzione di un carico di lavoro su una sezione TPU con singolo host, consulta Eseguire i carichi di lavoro su nodi TPU.
Tipi di macchine TPU per i pool di nodi GKE
Prima di creare pool di nodi, devi scegliere la versione della TPU e le dimensioni della sezione TPU richieste dal tuo carico di lavoro. TPU v4 è supportato in GKE Standard 1.26.1-gke.1500
e versioni successive, v5e in GKE Standard 1.27.2-gke.2100
e versioni successive e v5p in GKE Standard 1.28.3-gke.1024000
e versioni successive.
TPU v4, v5e e v5p sono supportate in GKE Autopilot versione 1.29.2-gke.1521000
e successive.
Per ulteriori informazioni sulle specifiche hardware delle diverse versioni di TPU, consulta Architettura di sistema. Quando crei un pool di nodi TPU, seleziona le dimensioni della sezione TPU (una topologia TPU) in base alle dimensioni del modello e alla quantità di memoria necessaria. Il tipo di macchina specificato durante la creazione dei pool di nodi dipende dalla versione e dalle dimensioni delle sezioni.
Versione 5e
Di seguito sono riportati i tipi di macchine e le topologie TPU v5e supportati per i casi d'uso di addestramento e inferenza:
Tipo di macchina | Topologia | Numero di chip TPU | Numero di VM | Caso d'uso consigliato |
---|---|---|---|---|
ct5lp-hightpu-1t |
1x1 | 1 | 1 | Addestramento, inferenza su singolo host |
ct5lp-hightpu-4t |
2x2 | 4 | 1 | Addestramento, inferenza su singolo host |
ct5lp-hightpu-8t |
2x4 | 8 | 1 | Addestramento, inferenza su singolo host |
ct5lp-hightpu-4t |
2x4 | 8 | 2 | Addestramento, inferenza multi-host |
ct5lp-hightpu-4t |
4x4 | 16 | 4 | Addestramento su larga scala, inferenza multi-host |
ct5lp-hightpu-4t |
4x8 | 32 | 8 | Addestramento su larga scala, inferenza multi-host |
ct5lp-hightpu-4t |
8x8 | 64 | 16 | Addestramento su larga scala, inferenza multi-host |
ct5lp-hightpu-4t |
8x16 | 128 | 32 | Addestramento su larga scala, inferenza multi-host |
ct5lp-hightpu-4t |
16x16 | 256 | 64 | Addestramento su larga scala, inferenza multi-host |
Cloud TPU v5e è un prodotto combinato di addestramento e inferenza. I job di addestramento sono ottimizzati per velocità effettiva e disponibilità, mentre i job di inferenza sono ottimizzati per la latenza. Per saperne di più, consulta Tipi di acceleratore di addestramento v5e e Tipi di acceleratore di inferenza v5e.
Le macchine TPU v5e sono disponibili in us-west4-a
, us-east5-b
e us-east1-c
.
I cluster GKE Standard devono eseguire il piano di controllo versione 1.27.2-gke.2100 o successiva.
GKE Autopilot deve eseguire il piano di controllo versione 1.29.2-gke.1521000 o successive.
Per maggiori informazioni su v5e, consulta
Addestramento di Cloud TPU v5e.
Confronto del tipo di macchina:
Tipo di macchina | ct5lp-hightpu-1t | ct5lp-hightpu-4t | ct5lp-hightpu-8t |
---|---|---|---|
Numero di chip v5e | 1 | 4 | 8 |
Numero di vCPU | 24 | 112 | 224 |
RAM (GB) | 48 | 192 | 384 |
Numero di NUMA nodi | 1 | 1 | 2 |
Probabilità di prerilascio | Alta | Medie | Bassa |
Per fare spazio alle VM con più chip, lo scheduler GKE potrebbe prerilasciare e riprogrammare le VM con meno chip. È probabile quindi che le VM a 8 chip preritino le VM a 1 e 4 chip.
v4 e v5p
Di seguito sono riportati i tipi di macchina TPU v4 e v5p:
Tipo di macchina | Numero di vCPU | Memoria (GB) | Numero di NUMA nodi |
---|---|---|---|
ct4p-hightpu-4t |
240 | 407 | 2 |
ct5p-hightpu-4t |
208 | 448 | 2 |
Quando crei una sezione TPU v4, utilizza il tipo di macchina ct4p-hightpu-4t
che ha un host e contiene 4 chip. Per saperne di più, consulta le topologie v4 e l'architettura del sistema TPU. I tipi di macchine pod TPU v4 sono disponibili in us-central2-b
. I cluster GKE Standard devono eseguire la versione del piano di controllo 1.26.1-gke.1500
o successiva.
I cluster GKE Autopilot devono eseguire il piano di controllo
versione 1.29.2-gke.1521000
o successiva.
Quando crei una sezione TPU v5p, utilizza il tipo di macchina ct5p-hightpu-4t
che ha un host e contiene 4 chip. I tipi di macchine pod TPU v5p sono disponibili in us-west4-a
e us-east5-a
.
I cluster GKE Standard devono eseguire il piano di controllo versione 1.28.3-gke.1024000
o successiva.
GKE Autopilot deve eseguire 1.29.2-gke.1521000
o versioni successive.
Per ulteriori informazioni su v5p, consulta l'introduzione all'addestramento per la versione v5p.
Problemi noti e limitazioni
- Numero massimo di pod Kubernetes: puoi eseguire un massimo di 256 pod Kubernetes in una singola VM TPU.
- Solo prenotazioni SPECIFICHE: quando si utilizzano TPU in GKE,
SPECIFIC
è l'unico valore supportato per il flag--reservation-affinity
del comandogcloud container node-pools create
. - Sono supportate solo le varianti di VM spot delle TPU prerilasciabili: le VM spot sono simili alle VM prerilasciabili e sono soggette alle stesse limitazioni di disponibilità, ma non hanno una durata massima di 24 ore.
- Nessun supporto per l'allocazione dei costi: l'allocazione dei costi di GKE e la misurazione dell'utilizzo non includono dati sull'utilizzo o sui costi delle TPU.
- Il gestore della scalabilità automatica potrebbe calcolare la capacità: il gestore della scalabilità automatica dei cluster potrebbe calcolare in modo errato la capacità per i nuovi nodi TPU prima che questi nodi siano disponibili. Il gestore della scalabilità automatica dei cluster potrebbe quindi eseguire un ulteriore scale up e, di conseguenza, creare più nodi del necessario. Il gestore della scalabilità automatica dei cluster eseguirà fare lo scale down di altri nodi, se non sono necessari, dopo una regolare operazione di fare lo scale down.
- Il gestore della scalabilità automatica annulla lo scale up: il gestore della scalabilità automatica dei cluster annulla lo scale up dei pool di nodi TPU che rimangono in attesa per più di 10 ore. Il gestore della scalabilità automatica del cluster proverà di nuovo queste operazioni di scale up in un secondo momento. Questo comportamento potrebbe ridurre l'ottenimento di TPU per i clienti che non utilizzano le prenotazioni.
- La violazione può impedire lo scale down: i carichi di lavoro non TPU che tollerano l'incompatibilità della TPU possono impedire fare lo scale down del pool di nodi se vengono ricreati durante lo svuotamento del pool di nodi TPU.
Assicurati che le quote TPU e GKE siano sufficienti
Potrebbe essere necessario aumentare determinate quote relative a GKE nelle regioni in cui vengono create le risorse.
Le seguenti quote hanno valori predefiniti che probabilmente dovranno essere aumentati:
- Quota SSD (GB) su disco permanente: il disco di avvio di ciascun nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata su un valore almeno pari a (il numero massimo di nodi GKE che prevedi di creare) * 100 GB.
- Quota di indirizzi IP in uso: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno pari al numero massimo di nodi GKE che prevedi di creare.
Per richiedere un aumento della quota, consulta Richiedere una quota più alta. Per ulteriori informazioni sui tipi di quote TPU, consulta Quota TPU.
Potrebbero essere necessari alcuni giorni prima che le tue richieste di aumento della quota vengano approvate. Se riscontri problemi nell'approvazione delle richieste di aumento della quota entro alcuni giorni, contatta il team degli Account Google.
Esegui la migrazione della prenotazione TPU
Se non prevedi di utilizzare una prenotazione TPU esistente con TPU in GKE, salta questa sezione e vai a Creare un cluster Google Kubernetes Engine.
Per utilizzare TPU riservate con GKE, devi prima eseguire la migrazione della prenotazione TPU a un nuovo sistema di prenotazione basato su Compute Engine.
Ci sono diversi aspetti importanti da sapere su questa migrazione:
- La capacità TPU di cui è stata eseguita la migrazione nel nuovo sistema di prenotazione basato su Compute Engine non può essere utilizzata con l'API Queued Resource di Cloud TPU. Se intendi utilizzare risorse in coda TPU con la tua prenotazione, dovrai eseguire solo la migrazione di una parte della prenotazione TPU al nuovo sistema di prenotazione basato su Compute Engine.
- Nessun carico di lavoro può essere in esecuzione attivamente sulle TPU quando viene eseguita la migrazione al nuovo sistema di prenotazione basato su Compute Engine.
- Seleziona un orario per eseguire la migrazione e collabora con il team dedicato al tuo account Google Cloud per programmarla. La finestra temporale della migrazione deve avvenire durante l'orario lavorativo (dal lunedì al venerdì, dalle 9:00 alle 17:00 fuso orario del Pacifico).
Crea un cluster Google Kubernetes Engine
Consulta Creazione di un cluster nella documentazione di Google Kubernetes Engine.
Crea un pool di nodi TPU
Consulta Creazione di un pool di nodi nella documentazione di Google Kubernetes Engine.
In esecuzione senza modalità con privilegi
Se vuoi ridurre l'ambito delle autorizzazioni sul container, consulta Modalità privilegio TPU.
Esegui carichi di lavoro su nodi TPU
Consulta Esecuzione dei carichi di lavoro su nodi TPU nella documentazione di Google Kubernetes Engine.
Selettori di nodi
Per consentire a Kubernetes di pianificare il carico di lavoro sui nodi TPU, devi specificare due selettori per ciascun nodo TPU nel manifest di Google Kubernetes Engine:
- Imposta
cloud.google.com/gke-accelerator-type
sutpu-v5-lite-podslice
otpu-v4-podslice
. - Imposta
cloud.google.com/gke-tpu-topology
sulla topologia TPU del nodo TPU.
Le sezioni carichi di lavoro di addestramento e carichi di lavoro di inferenza contengono manifest di esempio che mostrano l'uso di questi selettori di nodi.
Considerazioni sulla pianificazione del carico di lavoro
Le TPU hanno caratteristiche uniche che richiedono una pianificazione e una gestione speciali dei carichi di lavoro in Kubernetes. Per ulteriori informazioni, consulta Considerazioni sulla pianificazione dei carichi di lavoro nella documentazione di GKE.
Riparazione dei nodi TPU
Se un nodo TPU in un pool di nodi della sezione TPU multi-host non è integro, l'intero pool di nodi viene ricreato. Per maggiori informazioni, consulta Riparazione automatica dei nodi nella documentazione di GKE.
Multisezione: andare oltre una singola sezione
Puoi aggregare sezioni più piccole in una sezione multisezione per gestire carichi di lavoro di addestramento più grandi. Per ulteriori informazioni, vedi Cloud TPU Multislice.
Tutorial sui carichi di lavoro di addestramento
Questi tutorial sono incentrati sull'addestramento dei carichi di lavoro su una sezione TPU multi-host (ad esempio, 4 macchine v5e). Riguardano i seguenti modelli:
- Modelli FLAX con faccina che abbraccia: Allena Diffusione di Pokémon
- PyTorch/XLA: GPT2 su WikiText
Scarica le risorse del tutorial
Scarica gli script Python e le specifiche YAML del tutorial per ogni modello preaddestrato con il seguente comando:
git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git
Crea e connettiti al cluster
Creando un cluster GKE a livello di regione, in modo che il piano di controllo
Kubernetes venga replicato in tre zone, per garantire una disponibilità maggiore.
Crea il tuo cluster in us-west4
, us-east1
o us-central2
a seconda della versione TPU che stai utilizzando. Per ulteriori informazioni sulle TPU e sulle zone, consulta
Regioni e zone di Cloud TPU.
Il comando seguente crea un nuovo cluster GKE a livello di regione sottoscritto al canale di rilascio rapido con un pool di nodi che inizialmente contiene un nodo per zona. Il comando abilita inoltre le funzionalità del driver CSI di Workload Identity e Cloud Storage FUSE sul cluster perché i carichi di lavoro di inferenza di esempio in questa guida utilizzano i bucket Cloud Storage per archiviare i modelli preaddestrati.
gcloud container clusters create cluster-name \ --region your-region \ --release-channel rapid \ --num-nodes=1 \ --workload-pool=project-id.svc.id.goog \ --addons GcsFuseCsiDriver
Per abilitare le funzionalità del driver CSI di Workload Identity e Cloud Storage FUSE per i cluster esistenti, esegui questo comando:
gcloud container clusters update cluster-name \ --region your-region \ --update-addons GcsFuseCsiDriver=ENABLED \ --workload-pool=project-id.svc.id.goog
I carichi di lavoro di esempio sono configurati in base ai seguenti presupposti:
- il pool di nodi utilizza
tpu-topology=4x4
con quattro nodi - il pool di nodi utilizza
machine-type
ct5lp-hightpu-4t
Esegui questo comando per connetterti al cluster appena creato:
gcloud container clusters get-credentials cluster-name \ --location=cluster-region
Modelli FLAX con faccina che abbraccia: Allena Diffusione di Pokémon
Questo esempio addestra il modello Stable Diffusion da HuggingFace utilizzando il set di dati Pokémon.
Il modello stabile di diffusione è un modello da testo a immagine latente che genera immagini fotorealistiche da qualsiasi input di testo. Per ulteriori informazioni sulla trasmissione stabile, vedi:
Crea immagine Docker
Il Dockerfile si trova nella cartella ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/
. Esegui i comandi seguenti per creare l'immagine Docker ed eseguirne il push.
cd ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/ docker build -t gcr.io/project-id/diffusion:latest . docker push gcr.io/project-id/diffusion:latest
Esegui il deployment del carico di lavoro
Crea un file con il contenuto seguente e assegnagli il nome tpu_job_diffusion.yaml
.
Compila il campo dell'immagine con l'immagine appena creata.
apiVersion: v1
kind: Service
metadata:
name: headless-svc
spec:
clusterIP: None
selector:
job-name: tpu-job-diffusion
---
apiVersion: batch/v1
kind: Job
metadata:
name: tpu-job-diffusion
spec:
backoffLimit: 0
# Completions and parallelism should be the number of chips divided by 4.
# (e.g. 4 for a v5litepod-16)
completions: 4
parallelism: 4
completionMode: Indexed
template:
spec:
subdomain: headless-svc
restartPolicy: Never
nodeSelector:
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
cloud.google.com/gke-tpu-topology: 4x4
containers:
- name: tpu-job-diffusion
image: gcr.io/${project-id}/diffusion:latest
ports:
- containerPort: 8471 # Default port using which TPU VMs communicate
- containerPort: 8431 # Port to export TPU usage metrics, if supported
command:
- bash
- -c
- |
cd examples/text_to_image
python3 train_text_to_image_flax.py --pretrained_model_name_or_path=duongna/stable-diffusion-v1-4-flax --dataset_name=lambdalabs/pokemon-blip-captions --resolution=128 --center_crop --random_flip --train_batch_size=4 --mixed_precision=fp16 --max_train_steps=1500 --learning_rate=1e-05 --max_grad_norm=1 --output_dir=sd-pokemon-model
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Quindi, esegui il deployment utilizzando:
kubectl apply -f tpu_job_diffusion.yaml
Pulizia
Al termine dell'esecuzione del job, puoi eliminarlo utilizzando:
kubectl delete -f tpu_job_diffusion.yaml
PyTorch/XLA: GPT2 su WikiText
Questo tutorial mostra come eseguire GPT2 sulle TPU v5e utilizzando HuggingFace su PyTorch/XLA utilizzando il set di dati wikitext.
Crea immagine Docker
Il Dockerfile si trova nella cartella ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/
.
Esegui i comandi seguenti per creare l'immagine Docker ed eseguirne il push.
cd ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/ docker build -t gcr.io/project-id/gpt:latest . docker push gcr.io/project-id/gpt:latest
Esegui il deployment del carico di lavoro
Copia il seguente codice YAML e salvalo in un file denominato tpu_job_gpt.yaml
. Completa il campo dell'immagine con l'immagine appena creata.
apiVersion: v1
kind: Service
metadata:
name: headless-svc
spec:
clusterIP: None
selector:
job-name: tpu-job-gpt
---
apiVersion: batch/v1
kind: Job
metadata:
name: tpu-job-gpt
spec:
backoffLimit: 0
# Completions and parallelism should be the number of chips divided by 4.
# (for example, 4 for a v5litepod-16)
completions: 4
parallelism: 4
completionMode: Indexed
template:
spec:
subdomain: headless-svc
restartPolicy: Never
volumes:
# Increase size of tmpfs /dev/shm to avoid OOM.
- name: shm
emptyDir:
medium: Memory
# consider adding `sizeLimit: XGi` depending on needs
nodeSelector:
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
cloud.google.com/gke-tpu-topology: 4x4
containers:
- name: tpu-job-gpt
image: gcr.io/$(project-id)/gpt:latest
ports:
- containerPort: 8479
- containerPort: 8478
- containerPort: 8477
- containerPort: 8476
- containerPort: 8431 # Port to export TPU usage metrics, if supported.
env:
- name: PJRT_DEVICE
value: 'TPU'
- name: XLA_USE_BF16
value: '1'
command:
- bash
- -c
- |
numactl --cpunodebind=0 python3 -u examples/pytorch/xla_spawn.py --num_cores 4 examples/pytorch/language-modeling/run_clm.py --num_train_epochs 3 --dataset_name wikitext --dataset_config_name wikitext-2-raw-v1 --per_device_train_batch_size 16 --per_device_eval_batch_size 16 --do_train --do_eval --output_dir /tmp/test-clm --overwrite_output_dir --config_name my_config_2.json --cache_dir /tmp --tokenizer_name gpt2 --block_size 1024 --optim adafactor --adafactor true --save_strategy no --logging_strategy no --fsdp "full_shard" --fsdp_config fsdp_config.json
volumeMounts:
- mountPath: /dev/shm
name: shm
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Esegui il deployment del flusso di lavoro utilizzando:
kubectl apply -f tpu_job_gpt.yaml
Pulizia
Al termine del job, puoi eliminarlo utilizzando:
kubectl delete -f tpu_job_gpt.yaml
Tutorial: carichi di lavoro di inferenza con host singolo
Questo tutorial mostra come eseguire un carico di lavoro di inferenza con un singolo host sulle TPU GKE v5e per i modelli preaddestrati con JAX, TensorFlow e PyTorch. A livello generale, esistono quattro passaggi separati da eseguire sul cluster GKE:
Crea un bucket Cloud Storage e configura l'accesso al bucket. Per archiviare il modello preaddestrato viene utilizzato un bucket Cloud Storage.
Scarica e converti un modello preaddestrato in un modello compatibile con TPU. Applica un pod Kubernetes che scarica il modello preaddestrato, utilizza il convertitore Cloud TPU e archivia i modelli convertiti in un bucket Cloud Storage utilizzando il driver CSI di Cloud Storage FUSE. Il convertitore Cloud TPU non richiede hardware specializzato. Questo tutorial mostra come scaricare il modello ed eseguire il convertitore Cloud TPU nel pool di nodi CPU.
Avvia il server per il modello convertito. Applica un deployment che gestisce il modello utilizzando un framework server supportato dal volume archiviato nel volume permanente ReadOnly Many (ROX). Le repliche di deployment devono essere eseguite su un nodo Pod TPU v5e con un pod Kubernetes per nodo.
Eseguire il deployment di un bilanciatore del carico per testare il server del modello. Il server è esposto a richieste esterne mediante il servizio LoadBalancer. È stato fornito uno script Python con una richiesta di esempio per testare il server modello.
Il seguente diagramma mostra come vengono instradate le richieste dal bilanciatore del carico.
Esempi di deployment del server
Questi carichi di lavoro di esempio sono configurati in base ai seguenti presupposti:
- Il cluster è in esecuzione con un pool di nodi TPU v5 con 3 nodi
- Il pool di nodi utilizza il tipo di macchina
ct5lp-hightpu-1t
in cui:- la topologia è 1 x 1
- il numero di chip TPU è 1
Il seguente manifest GKE definisce un singolo deployment server host.
apiVersion: apps/v1
kind: Deployment
metadata:
name: bert-deployment
spec:
selector:
matchLabels:
app: tf-bert-server
replicas: 3 # number of nodes in node pool
template:
metadata:
annotations:
gke-gcsfuse/volumes: "true"
labels:
app: tf-bert-server
spec:
nodeSelector:
cloud.google.com/gke-tpu-topology: 1x1 # target topology
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # target version
containers:
- name: serve-bert
image: us-docker.pkg.dev/cloud-tpu-images/inference/tf-serving-tpu:2.13.0
env:
- name: MODEL_NAME
value: "bert"
volumeMounts:
- mountPath: "/models/"
name: bert-external-storage
ports:
- containerPort: 8500
- containerPort: 8501
- containerPort: 8431 # Port to export TPU usage metrics, if supported.
resources:
requests:
google.com/tpu: 1 # TPU chip request
limits:
google.com/tpu: 1 # TPU chip request
volumes:
- name: bert-external-storage
persistentVolumeClaim:
claimName: external-storage-pvc
Se utilizzi un numero diverso di nodi nel pool di nodi TPU, modifica il campo replicas
con il numero di nodi.
Se il tuo cluster Standard esegue GKE versione 1.27 o precedente, aggiungi il seguente campo al manifest:
spec:
securityContext:
privileged: true
Non è necessario eseguire i pod Kubernetes in modalità con privilegi in GKE 1.28 o versioni successive. Per maggiori dettagli, consulta Eseguire i container senza modalità con privilegi.
Se utilizzi un tipo di macchina diverso:
- Imposta
cloud.google.com/gke-tpu-topology
sulla topologia per il tipo di macchina in uso. - Imposta entrambi i campi
google.com/tpu
inresources
in modo che corrispondano al numero di chip per il tipo di macchina corrispondente.
Configurazione
Scarica gli script Python e i manifest YAML del tutorial utilizzando il seguente comando:
git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git
Vai alla directory single-host-inference
:
cd ai-on-gke/gke-tpu-examples/single-host-inference/
Configura l'ambiente Python
Gli script Python utilizzati in questo tutorial richiedono Python 3.9 o versioni successive.
Ricordati di installare requirements.txt
per ogni tutorial prima di eseguire gli script di test di Python.
Se non disponi della configurazione Python corretta nel tuo ambiente locale, puoi utilizzare Cloud Shell per scaricare ed eseguire gli script Python in questo tutorial.
configura il cluster
Crea un cluster utilizzando il tipo di macchina
e2-standard-4
.gcloud container clusters create cluster-name \ --region your-region \ --release-channel rapid \ --num-nodes=1 \ --machine-type=e2-standard-4 \ --workload-pool=project-id.svc.id.goog \ --addons GcsFuseCsiDriver
I carichi di lavoro di esempio presuppongono quanto segue:
- Il cluster è in esecuzione con un pool di nodi TPU v5e con 3 nodi.
- Il pool di nodi TPU utilizza il tipo di macchina
ct5lp-hightpu-1t
.
Se utilizzi una configurazione del cluster diversa da quella descritta in precedenza, devi modificare il manifest del deployment del server.
Per la demo di JAX Stable Diffusion, avrai bisogno di un pool di nodi CPU con un tipo di macchina con 16 Gi+ di memoria disponibile (ad esempio e2-standard-4
).
Questa configurazione è configurata nel comando gcloud container clusters create
o
aggiungendo un pool di nodi aggiuntivo al cluster esistente con il seguente
comando:
gcloud beta container node-pools create your-pool-name \ --zone=your-cluster-zone \ --cluster=your-cluster-name \ --machine-type=e2-standard-4 \ --num-nodes=1
Sostituisci quanto segue:
your-pool-name
: il nome del pool di nodi da creare.your-cluster-zone
: la zona in cui è stato creato il cluster.your-cluster-name
: il nome del cluster a cui aggiungere il pool di nodi.your-machine-type
: il tipo di macchina dei nodi da creare nel pool di nodi.
Configura l'archiviazione dei modelli
Esistono diversi modi per archiviare il modello per la pubblicazione. In questo tutorial utilizzeremo il seguente approccio:
- Per convertire il modello preaddestrato in modo che funzioni sulle TPU, utilizzeremo un virtual private cloud supportato da un Persistent Disk con accesso
ReadWriteMany
(RWX). - Per gestire il modello su più TPU con singolo host, utilizzeremo lo stesso VPC supportato dal bucket Cloud Storage.
Esegui questo comando per creare un bucket Cloud Storage.
gcloud storage buckets create gs://your-bucket-name \ --project=your-bucket-project-id \ --location=your-bucket-location
Sostituisci quanto segue:
your-bucket-name
: il nome del bucket Cloud Storage.your-bucket-project-id
: l'ID progetto in cui hai creato il bucket Cloud Storage.your-bucket-location
: la località del bucket Cloud Storage. Per migliorare le prestazioni, specifica la località in cui è in esecuzione il cluster GKE.
Segui questi passaggi per concedere al tuo cluster GKE l'accesso al bucket. Per semplificare la configurazione, gli esempi seguenti utilizzano lo spazio dei nomi predefinito e l'account di servizio Kubernetes predefinito. Per maggiori dettagli, consulta Configurare l'accesso ai bucket Cloud Storage utilizzando GKE Workload Identity.
Crea un account di servizio IAM per la tua applicazione o utilizza un account di servizio IAM esistente. Puoi utilizzare qualsiasi account di servizio IAM nel progetto del bucket Cloud Storage.
gcloud iam service-accounts create your-iam-service-acct \ --project=your-bucket-project-id
Sostituisci quanto segue:
your-iam-service-acct
: il nome del nuovo account di servizio IAM.your-bucket-project-id
: l'ID del progetto in cui hai creato l'account di servizio IAM. L'account di servizio IAM deve trovarsi nello stesso progetto del bucket Cloud Storage.
Assicurati che l'account di servizio IAM disponga dei ruoli di archiviazione necessari.
gcloud storage buckets add-iam-policy-binding gs://your-bucket-name \ --member "serviceAccount:your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com" \ --role "roles/storage.objectAdmin"
Sostituisci quanto segue:
your-bucket-name
: il nome del bucket Cloud Storage.your-iam-service-acct
: il nome del nuovo account di servizio IAM.your-bucket-project-id
: l'ID del progetto in cui hai creato l'account di servizio IAM.
Consenti all'account di servizio Kubernetes di impersonare l'account di servizio IAM aggiungendo un'associazione di criteri IAM tra i due account di servizio. Questa associazione consente all'account di servizio Kubernetes di agire come account di servizio IAM.
gcloud iam service-accounts add-iam-policy-binding your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:your-project-id.svc.id.goog[default/default]"
Sostituisci quanto segue:
your-iam-service-acct
: il nome del nuovo account di servizio IAM.your-bucket-project-id
: l'ID del progetto in cui hai creato l'account di servizio IAM.your-project-id
: l'ID del progetto in cui hai creato il cluster GKE. I bucket Cloud Storage e il cluster GKE possono trovarsi nello stesso progetto o in progetti diversi.
Annota l'account di servizio Kubernetes con l'indirizzo email dell'account di servizio IAM.
kubectl annotate serviceaccount default \ --namespace default \ iam.gke.io/gcp-service-account=your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com
Sostituisci quanto segue:
your-iam-service-acct
: il nome del nuovo account di servizio IAM.your-bucket-project-id
: l'ID del progetto in cui hai creato l'account di servizio IAM.
Esegui questo comando per completare il nome del bucket nei file YAML di questa demo:
find . -type f -name "*.yaml" | xargs sed -i "s/BUCKET_NAME/your-bucket-name/g"
Sostituisci
your-bucket-name
con il nome del tuo bucket Cloud Storage.Crea un volume permanente e un'attestazione di volumi permanenti con il seguente comando:
kubectl apply -f pvc-pv.yaml
Inferenza e gestione del modello JAX
Installa le dipendenze Python per eseguire script Python del tutorial che inviano richieste al servizio del modello JAX.
pip install -r jax/requirements.txt
Esegui la demo di gestione di JAX BERT E2E:
Questa demo utilizza un modello BERT preaddestrato di Hugging Face.
Il pod Kubernetes esegue i seguenti passaggi:
- Scarica e utilizza lo script Python
export_bert_model.py
dalle risorse di esempio per scaricare il modello bert preaddestrato in una directory temporanea. - Utilizza l'immagine del convertitore Cloud TPU per convertire il modello preaddestrato da CPU a TPU e lo archivia nel bucket Cloud Storage che hai creato durante la setup.
Questo pod Kubernetes è configurato per l'esecuzione sulla CPU del pool di nodi predefinito. Esegui il pod con questo comando:
kubectl apply -f jax/bert/install-bert.yaml
Verifica che il modello sia stato installato correttamente con quanto segue:
kubectl get pods install-bert
Potrebbero essere necessari un paio di minuti prima che STATUS
legga Completed
.
Avvia il server del modello TF per il modello
I carichi di lavoro di esempio in questo tutorial presuppongono quanto segue:
- Il cluster è in esecuzione con un pool di nodi TPU v5 con tre nodi
- Il pool di nodi utilizza il tipo di macchina
ct5lp-hightpu-1t
che contiene un chip TPU.
Se utilizzi una configurazione del cluster diversa da quella descritta in precedenza, devi modificare il manifest del deployment del server.
Applica deployment
kubectl apply -f jax/bert/serve-bert.yaml
Verifica che il server sia in esecuzione con quanto segue:
kubectl get deployment bert-deployment
Potrebbe volerci un minuto prima che AVAILABLE
legga 3
.
Applica servizio del bilanciatore del carico
kubectl apply -f jax/bert/loadbalancer.yaml
Verifica che il bilanciatore del carico sia pronto per il traffico esterno con quanto segue:
kubectl get svc tf-bert-service
Potrebbero essere necessari alcuni minuti prima che EXTERNAL_IP
venga elencato un IP.
Invia la richiesta al server del modello
Ottieni IP esterno dal servizio bilanciatore del carico:
EXTERNAL_IP=$(kubectl get services tf-bert-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Esegui uno script per inviare una richiesta al server:
python3 jax/bert/bert_request.py $EXTERNAL_IP
Output previsto:
For input "The capital of France is [MASK].", the result is ". the capital of france is paris.."
For input "Hello my name [MASK] Jhon, how can I [MASK] you?", the result is ". hello my name is jhon, how can i help you?."
Pulizia
Per eseguire la pulizia delle risorse, esegui kubectl delete
in ordine inverso.
kubectl delete -f jax/bert/loadbalancer.yaml kubectl delete -f jax/bert/serve-bert.yaml kubectl delete -f jax/bert/install-bert.yaml
Esegui la demo di servizio di JAX Stable Diffusion E2E
Questa demo utilizza il modello stabile di diffusione preaddestrato di Hugging Face.
Esporta modello salvato TF2 compatibile con TPU dal modello Flax Stable Diffusion
L'esportazione dei modelli di diffusione stabile richiede che il cluster abbia un pool di nodi CPU con un tipo di macchina con oltre 16 G di memoria disponibile, come descritto in Cluster di configurazione.
Il pod di Kubernetes esegue i seguenti passaggi:
- Scarica e utilizza lo script Python
export_stable_diffusion_model.py
dalle risorse di esempio per scaricare il modello di diffusione stabile preaddestrato in una directory temporanea. - Utilizza l'immagine del convertitore Cloud TPU per convertire il modello preaddestrato da CPU a TPU e lo archivia nel bucket Cloud Storage che hai creato durante la configurazione dell'archiviazione.
Questo pod Kubernetes è configurato per essere eseguito sul pool di nodi CPU predefinito. Esegui il pod con questo comando:
kubectl apply -f jax/stable-diffusion/install-stable-diffusion.yaml
Verifica che il modello sia stato installato correttamente con quanto segue:
kubectl get pods install-stable-diffusion
Potrebbero essere necessari un paio di minuti prima che STATUS
legga Completed
.
Avvia il container del server del modello TF per il modello
I carichi di lavoro di esempio sono stati configurati con le seguenti ipotesi:
- il cluster è in esecuzione con un pool di nodi TPU v5 con tre nodi
- il pool di nodi utilizza il tipo di macchina
ct5lp-hightpu-1t
in cui:- la topologia è 1 x 1
- il numero di chip TPU è 1
Se utilizzi una configurazione del cluster diversa da quella descritta in precedenza, devi modificare il manifest del deployment del server.
Applica il deployment:
kubectl apply -f jax/stable-diffusion/serve-stable-diffusion.yaml
Verifica che il server funzioni come previsto:
kubectl get deployment stable-diffusion-deployment
Potrebbe volerci un minuto prima che AVAILABLE
legga 3
.
Applica il servizio di bilanciamento del carico:
kubectl apply -f jax/stable-diffusion/loadbalancer.yaml
Verifica che il bilanciatore del carico sia pronto per il traffico esterno con quanto segue:
kubectl get svc tf-stable-diffusion-service
Potrebbero essere necessari alcuni minuti prima che EXTERNAL_IP
venga elencato un IP.
Invia la richiesta al server del modello
Ottieni un IP esterno dal bilanciatore del carico:
EXTERNAL_IP=$(kubectl get services tf-stable-diffusion-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Esegui lo script per inviare una richiesta al server
python3 jax/stable-diffusion/stable_diffusion_request.py $EXTERNAL_IP
Output previsto:
Il prompt è Painting of a squirrel skating in New York
e l'immagine di output verrà salvata come stable_diffusion_images.jpg
nella directory attuale.
Pulizia
Per eseguire la pulizia delle risorse, esegui kubectl delete
in ordine inverso.
kubectl delete -f jax/stable-diffusion/loadbalancer.yaml kubectl delete -f jax/stable-diffusion/serve-stable-diffusion.yaml kubectl delete -f jax/stable-diffusion/install-stable-diffusion.yaml
Esegui la demo di gestione di TensorFlow ResNet-50 E2E:
Installa le dipendenze Python per eseguire script Python del tutorial che inviano richieste al servizio del modello TF.
pip install -r tf/resnet50/requirements.txt
Passaggio 1: converti il modello
Applica la conversione del modello:
kubectl apply -f tf/resnet50/model-conversion.yml
Verifica che il modello sia stato installato correttamente con quanto segue:
kubectl get pods resnet-model-conversion
Potrebbero essere necessari un paio di minuti prima che STATUS
legga Completed
.
Passaggio 2: gestisci il modello con la gestione di TensorFlow
Applica il deployment della pubblicazione del modello:
kubectl apply -f tf/resnet50/deployment.yml
Verifica che il server funzioni come previsto utilizzando il seguente comando:
kubectl get deployment resnet-deployment
Potrebbe volerci un minuto prima che AVAILABLE
legga 3
.
Applica il servizio di bilanciamento del carico:
kubectl apply -f tf/resnet50/loadbalancer.yml
Verifica che il bilanciatore del carico sia pronto per il traffico esterno con quanto segue:
kubectl get svc resnet-service
Potrebbero essere necessari alcuni minuti prima che EXTERNAL_IP
venga elencato un IP.
Passaggio 3: invia una richiesta di test al server del modello
Ottieni l'IP esterno dal bilanciatore del carico:
EXTERNAL_IP=$(kubectl get services resnet-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Esegui lo script della richiesta di test (HTTP) per inviare la richiesta al server del modello.
python3 tf/resnet50/request.py --host $EXTERNAL_IP
La risposta dovrebbe essere simile alla seguente:
Predict result: ['ImageNet ID: n07753592, Label: banana, Confidence: 0.94921875', 'ImageNet ID: n03532672, Label: hook, Confidence: 0.0223388672', 'ImageNet ID: n07749582, Label: lemon, Confidence: 0.00512695312
Passaggio 4: esegui la pulizia
Per eseguire la pulizia delle risorse, esegui questi comandi kubectl delete
:
kubectl delete -f tf/resnet50/loadbalancer.yml kubectl delete -f tf/resnet50/deployment.yml kubectl delete -f tf/resnet50/model-conversion.yml
Assicurati di eliminare il pool di nodi e il cluster GKE quando hai finito.
Inferenza e pubblicazione del modello PyTorch
Installa le dipendenze Python per eseguire script Python del tutorial che inviano richieste al servizio del modello PyTorch:
pip install -r pt/densenet161/requirements.txt
Esegui la demo di gestione di TorchServe Densenet161 E2E:
Genera l'archivio dei modelli.
- Applica l'archivio dei modelli:
kubectl apply -f pt/densenet161/model-archive.yml
- Verifica che il modello sia stato installato correttamente con quanto segue:
kubectl get pods densenet161-model-archive
Potrebbero essere necessari un paio di minuti prima che
STATUS
leggaCompleted
.Gestire il modello con TorchServe:
Applica il deployment della pubblicazione di modelli:
kubectl apply -f pt/densenet161/deployment.yml
Verifica che il server funzioni come previsto utilizzando il seguente comando:
kubectl get deployment densenet161-deployment
Potrebbe volerci un minuto prima che
AVAILABLE
legga3
.Applica il servizio di bilanciamento del carico:
kubectl apply -f pt/densenet161/loadbalancer.yml
Verifica che il bilanciatore del carico sia pronto per il traffico esterno con il seguente comando:
kubectl get svc densenet161-service
Potrebbero essere necessari alcuni minuti prima che
EXTERNAL_IP
venga elencato un IP.
Invia una richiesta di test al server del modello:
Ottieni IP esterno dal bilanciatore del carico:
EXTERNAL_IP=$(kubectl get services densenet161-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Esegui lo script di richiesta di test per inviare la richiesta (HTTP) al server del modello.
python3 pt/densenet161/request.py --host $EXTERNAL_IP
Dovresti visualizzare una risposta simile alla seguente:
Request successful. Response: {'tabby': 0.47878125309944153, 'lynx': 0.20393909513950348, 'tiger_cat': 0.16572578251361847, 'tiger': 0.061157409101724625, 'Egyptian_cat': 0.04997897148132324
Esegui la pulizia delle risorse eseguendo questi comandi
kubectl delete
:kubectl delete -f pt/densenet161/loadbalancer.yml kubectl delete -f pt/densenet161/deployment.yml kubectl delete -f pt/densenet161/model-archive.yml
Assicurati di eliminare il pool di nodi e il cluster GKE quando hai finito.
Risoluzione dei problemi più comuni
Puoi trovare informazioni sulla risoluzione dei problemi di GKE in Risolvere i problemi relativi a TPU in GKE.
Inizializzazione TPU non riuscita
Se si verifica il seguente errore, assicurati di eseguire il container TPU in modalità privilegi o di aver aumentato ulimit
all'interno del container. Per ulteriori informazioni, consulta Esecuzione senza modalità con privilegi.
TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance
Pianificazione del deadlock
Supponi di avere due job (Job A e Job B) ed entrambi da pianificare su sezioni TPU con una determinata topologia TPU (ad esempio v4-32
). Supponi inoltre di avere due sezioni TPU v4-32
all'interno del cluster GKE, che chiameremo X e Y. Poiché il cluster ha un'ampia capacità per pianificare entrambi i job, in teoria entrambi i job dovrebbero essere pianificati rapidamente, ovvero un job per ciascuna delle due sezioni v4-32
di TPU.
Tuttavia, senza un'attenta pianificazione, è possibile che si verifichi un deadlock di pianificazione. Supponiamo che lo scheduler Kubernetes pianifica un pod Kubernetes dal Job A nella sezione X, quindi un pod Kubernetes dal job B nella sezione X. In questo caso, date le regole di affinità dei pod di Kubernetes per il job A, lo scheduler tenterà di pianificare tutti i pod Kubernetes rimanenti per il job A sulla sezione X. Lo stesso per il lavoro B. Quindi né il job A né il job B potranno essere completamente pianificati su una singola sezione. Il risultato sarà un deadlock di pianificazione.
Per evitare il rischio di un deadlock di pianificazione, puoi utilizzare l'anti-affinità dei pod Kubernetes con cloud.google.com/gke-nodepool
come topologyKey
, come mostrato nell'esempio seguente:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
parallelism: 2
template:
metadata:
labels:
job: pi
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job
operator: In
values:
- pi
topologyKey: cloud.google.com/gke-nodepool
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job
operator: NotIn
values:
- pi
topologyKey: cloud.google.com/gke-nodepool
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
containers:
- name: pi
image: perl:5.34.0
command: ["sleep", "60"]
restartPolicy: Never
backoffLimit: 4
Creazione di risorse del pool di nodi TPU con Terraform
Puoi anche utilizzare Terraform per gestire le risorse del cluster e del pool di nodi.
Crea un pool di nodi della sezione TPU multi-host in un cluster GKE esistente
Se hai già un cluster in cui vuoi creare un pool di nodi TPU multi-host, puoi utilizzare il seguente snippet Terraform:
resource "google_container_cluster" "cluster_multi_host" {
…
release_channel {
channel = "RAPID"
}
workload_identity_config {
workload_pool = "my-gke-project.svc.id.goog"
}
addons_config {
gcs_fuse_csi_driver_config {
enabled = true
}
}
}
resource "google_container_node_pool" "multi_host_tpu" {
provider = google-beta
project = "${project-id}"
name = "${node-pool-name}"
location = "${location}"
node_locations = ["${node-locations}"]
cluster = google_container_cluster.cluster_multi_host.name
initial_node_count = 2
node_config {
machine_type = "ct4p-hightpu-4t"
reservation_affinity {
consume_reservation_type = "SPECIFIC_RESERVATION"
key = "compute.googleapis.com/reservation-name"
values = ["${reservation-name}"]
}
workload_metadata_config {
mode = "GKE_METADATA"
}
}
placement_policy {
type = "COMPACT"
tpu_topology = "2x2x2"
}
}
Sostituisci i seguenti valori:
your-project
: il progetto Google Cloud in cui esegui il carico di lavoro.your-node-pool
: il nome del pool di nodi che stai creando.us-central2
: la regione in cui esegui il carico di lavoro.us-central2-b
: la zona in cui esegui il carico di lavoro.your-reservation-name
: il nome della prenotazione.
Crea un pool di nodi della sezione TPU con host singolo in un cluster GKE esistente
Utilizza il seguente snippet Terraform:
resource "google_container_cluster" "cluster_single_host" {
…
cluster_autoscaling {
autoscaling_profile = "OPTIMIZE_UTILIZATION"
}
release_channel {
channel = "RAPID"
}
workload_identity_config {
workload_pool = "${project-id}.svc.id.goog"
}
addons_config {
gcs_fuse_csi_driver_config {
enabled = true
}
}
}
resource "google_container_node_pool" "single_host_tpu" {
provider = google-beta
project = "${project-id}"
name = "${node-pool-name}"
location = "${location}"
node_locations = ["${node-locations}"]
cluster = google_container_cluster.cluster_single_host.name
initial_node_count = 0
autoscaling {
total_min_node_count = 2
total_max_node_count = 22
location_policy = "ANY"
}
node_config {
machine_type = "ct4p-hightpu-4t"
workload_metadata_config {
mode = "GKE_METADATA"
}
}
}
Sostituisci i seguenti valori:
your-project
: il progetto Google Cloud in cui esegui il carico di lavoro.your-node-pool
: il nome del pool di nodi che stai creando.us-central2
: la regione in cui esegui il carico di lavoro.us-central2-b
: la zona in cui esegui il carico di lavoro.