Introduzione alle TPU in GKE

I clienti di Google Kubernetes Engine (GKE) ora possono creare Pool di nodi Kubernetes contenenti sezioni TPU v4 e v5e. Per ulteriori informazioni sulle TPU, vedi Architettura di sistema.

Quando lavori con GKE, devi prima creare Cluster GKE. Quindi aggiungi pool di nodi ai tuoi in un cluster Kubernetes. 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 una sezione multi-host è connessa tramite un'interconnessione ad alta velocità (ICI). Una volta sia stato creato un pool di nodi con sezioni multi-host, non puoi aggiungervi nodi. Ad esempio: non puoi creare un pool di nodi v4-32 per poi aggiungere un altro cluster 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 nella sezione, dei nodi della sezione.

Se è necessario riparare un nodo all'interno di una sezione TPU multi-host, GKE arresta tutte le VM TPU nella sezione, forzando tutti i pod Kubernetes da rimuovere. Quando tutte le VM TPU della sezione sono in esecuzione, I pod Kubernetes possono essere pianificati sulle VM TPU nella nuova sezione.

Il seguente diagramma mostra un esempio di una TPU multi-host v5litepod-16 (v5e) sezione. 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 TensorCore.

Diagramma della sezione TPU multi-host

Il seguente diagramma mostra un cluster GKE contenente uno Sezione TPU v5litepod-16 (v5e) (topologia: 4x4) e una TPU v5litepod-8 (v5e) sezione (topologia: 2x4):

Diagramma del pod TPU v5e

Per un esempio di esecuzione di un carico di lavoro su una sezione TPU multi-host, vedi Esegui il carico di lavoro sulle TPU.

Pool di nodi della sezione TPU con host singolo

Un pool di nodi con una sezione dell'host singolo è un pool di nodi che contiene una o più VM TPU indipendenti. A ogni VM è connesso un dispositivo TPU. Mentre le VM all'interno di un pool di nodi con sezione dell'host singolo possono comunicare di rete (DCN), le TPU collegate alle VM non sono interconnesse.

Il seguente diagramma mostra un esempio di una sezione TPU a host singolo con sette v4-8 macchina:

Diagramma del pool di nodi della sezione dell'host singolo

Per un esempio di esecuzione di un carico di lavoro su una sezione di TPU con host singolo, consulta Esegui il carico di lavoro sulle TPU.

Tipi di macchine TPU per i pool di nodi GKE

Prima di creare pool di nodi, devi scegliere la versione e la dimensione di TPU Sezione TPU richiesta dal carico di lavoro. TPU v4 è supportato in GKE Versione standard 1.26.1-gke.1500 e successive, v5e in GKE Versione standard 1.27.2-gke.2100 e successive e v5p in GKE versione Standard 1.28.3-gke.1024000 e 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 TPU versioni, vedi Architettura di sistema. Quando creando un pool di nodi TPU, seleziona una dimensione della sezione TPU (una topologia TPU) in base le dimensioni del modello e la quantità di memoria richiesta. Il tipo di macchina specificato quando crei i tuoi pool di nodi dipende dalla versione e dalle dimensioni delle sezioni.

V5e

Di seguito sono riportati i tipi di macchina TPU v5e e le topologie 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 host singolo
ct5lp-hightpu-4t 2x2 4 1 Addestramento, inferenza su host singolo
ct5lp-hightpu-8t 2x4 8 1 Addestramento, inferenza su host singolo
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 ottimizzati per velocità effettiva e disponibilità, mentre i job di inferenza sono ottimizzati una latenza di pochi millisecondi. Per ulteriori informazioni, consulta la sezione sui tipi di acceleratori di addestramento v5e e i tipi di acceleratori 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. Autopilot di GKE deve eseguire il piano di controllo versione 1.29.2-gke.1521000 o successiva. Per ulteriori informazioni sulla versione v5e, vedi Addestramento di Cloud TPU v5e.

Confronto tra tipi 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 nodi NUMA 1 1 2
Probabilità di prerilascio Alta Medie Bassa

Per fare spazio alle VM con più chip, lo scheduler GKE prerilasciare e riprogrammare le VM con meno chip. Quindi le VM a 8 chip hanno maggiori probabilità prerilascia VM con 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 quattro chip. Vedi topologie v4 e l'architettura del sistema TPU informazioni. I tipi di macchina sezione TPU v4 sono disponibili in us-central2-b. Il tuo I cluster GKE Standard devono eseguire il piano di controllo versione 1.26.1-gke.1500 o successiva. Autopilot di GKE i cluster 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 è un host e contiene 4 chip. I tipi di macchina sezione TPU v5p sono disponibili in us-west4-a e us-east5-a. GKE Standard i cluster devono eseguire il piano di controllo versione 1.28.3-gke.1024000 o successiva. GKE Autopilot deve eseguire 1.29.2-gke.1521000 o in un secondo momento. Per ulteriori informazioni su v5p, consulta l'introduzione alla formazione v5p.

Problemi noti e limitazioni

  • Numero massimo di pod Kubernetes: puoi eseguire un massimo di 256 Kubernetes in una singola VM TPU.
  • Solo prenotazioni SPECIFICHE: quando utilizzi le TPU in GKE, SPECIFIC è l'unico valore supportato per il flag --reservation-affinity del comando gcloud container node-pools create.
  • È supportata solo la variante delle VM spot delle TPU prerilasciabili: VM spot sono simili alle VM prerilasciabili e sono soggette alla stessa disponibilità limitazioni, ma non prevedono una durata massima di 24 ore.
  • Nessun supporto per l'allocazione dei costi: allocazione dei costi di GKE e misurazione dell'utilizzo non includono dati sull'utilizzo o sui costi delle TPU.
  • Il gestore della scalabilità automatica può calcolare la capacità: potrebbe calcolare il gestore della scalabilità automatica dei cluster non era corretta per i nuovi nodi contenenti VM TPU prima che vengano disponibili. Il gestore della scalabilità automatica dei cluster può quindi eseguire ulteriori scale up e creare più nodi del necessario. Lo scale down del gestore della scalabilità automatica dei cluster nodi aggiuntivi, se non necessari, dopo una normale 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 di TPU pool di nodi che rimangono in stato di attesa per più di 10 ore. Gruppo Il gestore della scalabilità automatica riproverà queste operazioni di scale up in un secondo momento. Questo comportamento può ridurre l'ottenimento di TPU per i clienti che non utilizzano le prenotazioni.
  • La macchia potrebbe impedire lo scale down: carichi di lavoro non TPU che sono tollerati per l'incompatibilità della TPU potrebbe impedire fare lo scale down del pool di nodi se vengono ricreati durante lo svuotamento del pool di nodi TPU.

Assicurati che siano sufficienti quote TPU e GKE

Potresti dover aumentare determinate quote relative a GKE le regioni in cui vengono create le tue risorse.

Le seguenti quote hanno valori predefiniti che probabilmente dovranno essere aumentati:

  • Quota di dischi permanenti SSD (GB): il disco di avvio di ogni nodo Kubernetes. richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata almeno (il numero massimo di nodi GKE che prevedi creazione) * 100 GB.
  • Quota di indirizzi IP in uso: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno su un valore pari al numero massimo i nodi GKE che prevedi di creare.

Per richiedere un aumento della quota, consulta Richiedere un aumento di quota. Per ulteriori informazioni sui tipi di quote TPU, consulta la pagina relativa alla quota TPU.

L'approvazione delle richieste di aumento della quota potrebbe richiedere alcuni giorni. Se difficoltà a ottenere l'approvazione delle richieste di aumento della quota entro un 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, ignora 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 in una nuova prenotazione basata su Compute Engine di un sistema operativo completo.

Ci sono diverse cose importanti da sapere su questa migrazione:

  • Migrazione della capacità TPU alla nuova prenotazione basata su Compute Engine non può essere utilizzato con l'API Queued Resource di Cloud TPU. Se intendi utilizzare risorse in coda TPU con la prenotazione, devi eseguire la migrazione di una parte della prenotazione TPU Sistema di prenotazione basato su Compute Engine.
  • Nessun carico di lavoro può essere in esecuzione attiva sulle TPU quando viene eseguita la migrazione alle il nuovo sistema di prenotazione basato su Compute Engine.
  • Seleziona un'ora per eseguire la migrazione e collabora con il tuo team Google Cloud team dedicato all'account per pianificare la migrazione. La finestra temporale della migrazione deve essere durante l'orario lavorativo (dal lunedì al venerdì, dalle 9:00 alle 17:00 fuso orario del Pacifico).

Crea un cluster Google Kubernetes Engine

Vedi Creare un cluster in consulta la documentazione di Google Kubernetes Engine.

Crea un pool di nodi TPU

Consulta Creare un pool di nodi nella documentazione di Google Kubernetes Engine.

Esecuzione senza modalità con privilegi

Se vuoi ridurre l'ambito delle autorizzazioni sul tuo container, consulta Modalità privilegio TPU.

Esegui i carichi di lavoro nei pool di nodi TPU

Vedi Eseguire carichi di lavoro GKE su TPU nella documentazione di Google Kubernetes Engine.

Selettori dei nodi

Per consentire a Kubernetes di pianificare il carico di lavoro su nodi contenenti VM TPU, devi specificare due selettori per ciascun nodo nel file manifest di Google Kubernetes Engine:

  • Imposta cloud.google.com/gke-accelerator-type su tpu-v5-lite-podslice oppure tpu-v4-podslice.
  • Imposta cloud.google.com/gke-tpu-topology sulla topologia TPU del nodo.

I carichi di lavoro di addestramento e i carichi di lavoro di inferenza contengono manifest di esempio che illustrano l'utilizzo di questi selettori di nodi.

Considerazioni sulla pianificazione del carico di lavoro

Le TPU hanno caratteristiche uniche che richiedono una pianificazione dei carichi di lavoro e e la gestione dei container in Kubernetes. Per saperne di più, consulta Considerazioni sulla pianificazione del carico di lavoro nella documentazione di GKE.

Riparazione dei nodi

Se un nodo in un pool di nodi della sezione TPU multi-host non è integro, GKE ricrea l'intero pool di nodi. Per ulteriori informazioni, consulta Riparazione automatica dei nodi nella documentazione di GKE.

Più sezioni - andare oltre una singola sezione

Puoi aggregare sezioni più piccole in una multisezione per gestire per l'addestramento dei carichi di lavoro. Per ulteriori informazioni, vedi Cloud TPU Multislice.

Tutorial di formazione sui carichi di lavoro

Questi tutorial sono incentrati sull'addestramento dei carichi di lavoro su una sezione di TPU multi-host (ad ad esempio 4 macchine v5e). Riguardano i seguenti modelli:

  • Modelli FLAX Hugging Face: Train Diffusion su Pokémon
  • PyTorch/XLA: GPT2 su WikiText

Scarica le risorse dei tutorial

Scarica gli script Python e le specifiche YAML tutorial per ogni modello preaddestrato con il seguente comando:

git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git

Crea e connettiti al cluster

crea un cluster GKE a livello di regione, in modo che Kubernetes viene replicato in tre zone, per offrire una disponibilità maggiore. Crea il cluster in us-west4, us-east1 o us-central2 in base a quale La versione di TPU in uso. Per ulteriori informazioni su TPU e zone, consulta Regioni e zone di Cloud TPU.

Il comando seguente crea un nuovo cluster GKE a livello di regione è iscritto al canale di rilascio rapido con un pool di nodi che inizialmente contiene un nodo per zona. Il comando abilita inoltre Workload Identity le funzionalità del driver CSI di Cloud Storage FUSE sul tuo cluster perché nell'esempio di inferenza in questa guida usano i bucket Cloud Storage per archiviare 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 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 Hugging Face: Train Diffusion su Pokémon

Questo esempio addestra il modello Stable Diffusion di HuggingFace utilizzando Pokémon del set di dati.

Il modello Stable Diffusion è un modello da testo a immagine latente che genera immagini fotorealistiche da qualsiasi input di testo. Per ulteriori informazioni sul canale stabile Diffusione, consulta:

Crea immagine Docker

Il Dockerfile si trova all'interno della cartella ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/.

Prima di eseguire questo comando, assicurati che il tuo account abbia autorizzazioni per Docker di eseguire il push nel repository.

Crea ed esegui il push dell'immagine Docker:

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 i seguenti contenuti 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

Poi esegui il deployment utilizzando:

kubectl apply -f tpu_job_diffusion.yaml

Pulizia

Al termine del job, puoi eliminarlo utilizzando:

kubectl delete -f tpu_job_diffusion.yaml

PyTorch/XLA: GPT2 su WikiText

Questo tutorial mostra come eseguire GPT2 su 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/.

Prima di eseguire questo comando, assicurati che il tuo account abbia autorizzazioni per Docker di eseguire il push nel repository.

Crea ed esegui il push dell'immagine Docker:

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 campo 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 su host singolo

Questo tutorial mostra come eseguire un carico di lavoro di inferenza su host singolo TPU GKE v5e per modelli preaddestrati con JAX, TensorFlow e PyTorch. A livello generale, ci sono quattro passaggi distinti da eseguire sulla Cluster GKE:

  1. Creare un bucket Cloud Storage e configurare l'accesso al bucket. Utilizzi un Il bucket Cloud Storage viene utilizzato per archiviare il modello preaddestrato.

  2. Scarica e converti un modello preaddestrato in un modello compatibile con TPU. Applica un Il pod Kubernetes che scarica il modello preaddestrato utilizza Convertitore Cloud TPU e archivia i modelli convertiti in un utilizzando il driver CSI di Cloud Storage FUSE. Il convertitore Cloud TPU non richiede hardware specializzato. Questo tutorial mostra come scaricare il modello ed esegui il convertitore Cloud TPU nel pool di nodi CPU.

  3. Avvia il server per il modello convertito. Applica un deployment che fornisce il modello utilizzando un framework del server supportato dal volume archiviato il volume permanente ReadOnlyMol (ROX). Le repliche di deployment devono essere eseguite in un pool di nodi con sezioni v5e, con un pod Kubernetes per nodo. in un pool di nodi con sezioni v5e, con un pod Kubernetes per nodo.

  4. Eseguire il deployment di un bilanciatore del carico per testare il server del modello. Il server è esposto richieste esterne mediante il servizio LoadBalancer. È stato fornito uno script Python con una richiesta di esempio per testare del modello di machine learning.

Il seguente diagramma mostra come le richieste vengono instradate dal bilanciatore del carico.

Diagramma che mostra il routing del 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:
    • è 1 x 1
    • il numero di chip TPU è 1

Il seguente manifest GKE definisce un singolo host al tuo server di deployment.

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 valore replicas al numero di nodi.

Se il cluster Standard esegue GKE versione 1.27 o precedente, aggiungi il seguente campo al file manifest:

spec:
  securityContext:
    privileged: true

Non è necessario eseguire pod Kubernetes in modalità con privilegi in GKE versione 1.28 o successive. Per maggiori dettagli, vedi Esegui 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 che stai utilizzando.
  • Imposta entrambi i campi google.com/tpu sotto resources in modo che corrispondano al numero di per il tipo di macchina corrispondente.

Configurazione

Scarica gli script Python e i manifest YAML dei tutorial utilizzando quanto segue :

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 che utilizzi in questo tutorial richiedono Python versione 3.9 o successiva. Ricordati di installare l'requirements.txt per ogni tutorial prima di eseguire il Script per il test Python.

Se non disponi della configurazione Python corretta nel tuo ambiente locale, puoi Cloud Shell per scaricare ed eseguire gli script Python in questo tutorial.

configura il cluster

  1. 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

  2. Crea il pool di nodi TPU con host singolo.

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 Stable Diffusion JAX, è necessario un pool di nodi CPU con un tipo di macchina con 16 Gi+ di memoria disponibile (ad esempio e2-standard-4). La configurazione avviene nel comando gcloud container clusters create o tramite Aggiungendo un altro pool di nodi al cluster esistente con quanto segue :

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 in cui aggiungere il pool di nodi.
  • your-machine-type: il tipo di macchina del nodi da creare nel tuo pool di nodi.

Configura archiviazione modello

Esistono diversi modi per archiviare il modello per la pubblicazione. In questo tutorial, adotteremo il seguente approccio:

  • Per convertire il modello preaddestrato in modo che funzioni sulle TPU, utilizzeremo un'istruzione Virtual Private Cloud supportato da Persistent Disk con accesso ReadWriteMany (RWX).
  • Per fornire il modello su più TPU con host singolo, 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 Cloud Storage di sincronizzare la directory di una VM con un bucket.
  • your-bucket-location: la posizione del tuo nel 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 a nel bucket. Per semplificare la configurazione, i seguenti esempi utilizzano il valore predefinito e l'account di servizio Kubernetes predefinito. Per maggiori dettagli, vedi Configura l'accesso ai bucket Cloud Storage utilizzando GKE Workload Identity.

  1. Crea un account di servizio IAM per l'applicazione o utilizza un con 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 servizio IAM .
    • your-bucket-project-id: l'ID del progetto in cui hai creato Account di servizio IAM. L'account di servizio IAM devono trovarsi nello stesso progetto del tuo bucket Cloud Storage.

  2. Assicurati che il tuo account di servizio IAM disponga dei ruoli di archiviazione necessaria.

    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 tuo bucket Cloud Storage.
    • your-iam-service-acct: il nome del nuovo servizio IAM .
    • your-bucket-project-id: l'ID del progetto in cui hai creato Account di servizio IAM.

  3. Consenti all'account di servizio Kubernetes di impersonare IAM di account di servizio aggiungendo un'associazione di criteri IAM tra due account di servizio. Questa associazione consente all'account di servizio Kubernetes fungono da 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 servizio IAM .
    • your-bucket-project-id: l'ID del progetto in cui hai creato Account di servizio IAM.
    • your-project-id: l'ID del progetto in cui hai creato cluster GKE. I tuoi bucket Cloud Storage Il cluster GKE può trovarsi nello stesso progetto o in progetti diversi.

  4. Annota l'account di servizio Kubernetes con l'indirizzo email del 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 servizio IAM .
    • your-bucket-project-id: l'ID del progetto in cui hai creato Account di servizio IAM.

  5. Esegui questo comando per inserire il nome del tuo bucket nei file YAML 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.

  6. Crea il volume permanente e la richiesta di volume permanente con quanto segue :

    kubectl apply -f pvc-pv.yaml

Inferenza e pubblicazione del modello JAX

Installa le dipendenze Python per eseguire gli script Python dei tutorial che inviano richieste al servizio del modello JAX.

pip install -r jax/requirements.txt

Esegui la demo di pubblicazione di JAX BERT E2E:

Questa demo utilizza un modello BERT preaddestrato di Hugging Face.

Il pod Kubernetes esegue questi passaggi:

  1. Scarica e utilizza lo script Python export_bert_model.py dall'esempio per scaricare il modello BERT preaddestrato in una directory temporanea.
  2. Utilizza l'immagine Cloud TPU Converter per convertire il modello preaddestrato dalla CPU alla TPU e archivia il modello nel bucket Cloud Storage creato durante la setup.

Questo pod Kubernetes è configurato per essere eseguito sulla CPU del pool di nodi predefinita. Esegui l' pod il comando seguente:

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 l'app 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 ne contiene uno 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

La lettura di 3 da parte di AVAILABLE potrebbe richiedere un minuto.

Applica il servizio 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 visualizzi un IP.

Invia la richiesta al server del modello

Ottieni un 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 pubblicazione di JAX Stable Diffusion E2E

Questa demo utilizza il modello stabile Diffusion preaddestrato di Hugging Face.

Esporta il modello salvato TF2 compatibile con TPU dal modello Flax Stable Diffusion

L'esportazione dei modelli di diffusione stabile richiede che il cluster abbia un nodo CPU con un tipo di macchina con 16 Gi+ di memoria disponibile, come descritto Configura cluster.

Il pod Kubernetes esegue i seguenti passaggi:

  1. Scarica e utilizza lo script Python export_stable_diffusion_model.py da le risorse di esempio per scaricare il modello di diffusione stabile preaddestrato una directory temporanea.
  2. Utilizza l'immagine Cloud TPU Converter per convertire il modello preaddestrato Dalla CPU alla TPU e archivia il modello nel bucket Cloud Storage che hai creato durante la configurazione dello spazio di archiviazione.

Questo pod Kubernetes è configurato per essere eseguito sul pool di nodi CPU predefinito. Esegui l' pod il comando seguente:

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 l'app STATUS legga Completed.

avvia il container del server del modello TF per il modello

I carichi di lavoro di esempio sono stati configurati in base ai seguenti presupposti:

  • 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:
    • è 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

La lettura di 3 da parte di AVAILABLE potrebbe richiedere un minuto.

Applica il servizio del bilanciatore 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 visualizzi 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 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à salvato 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 pubblicazione di TensorFlow ResNet-50 E2E:

Installa le dipendenze Python per eseguire gli script Python dei tutorial che inviano 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 l'app STATUS legga Completed.

Passaggio 2: pubblica il modello con la pubblicazione di TensorFlow

Applica il deployment della distribuzione del modello:

kubectl apply -f tf/resnet50/deployment.yml

Verifica che il server sia in esecuzione come previsto con il seguente comando:

kubectl get deployment resnet-deployment

La lettura di 3 da parte di AVAILABLE potrebbe richiedere un minuto.

Applica il servizio del bilanciatore 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 individui un IP.

Passaggio 3: invia una richiesta di test al server del modello

Recupera 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 GKE e cluster quando hai finito.

Inferenza e pubblicazione del modello PyTorch

Installa le dipendenze Python per eseguire gli script Python dei tutorial che inviano richieste al servizio del modello PyTorch:

pip install -r pt/densenet161/requirements.txt

Esegui la demo di pubblicazione di TorchServe Densenet161 E2E:

  1. Genera un archivio dei modelli.

    1. Applica archivio modelli:
    kubectl apply -f pt/densenet161/model-archive.yml
    1. 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 l'app STATUS legga Completed.

  2. Distribuisci il modello con TorchServe:

    1. Applica il deployment di pubblicazione del modello:

      kubectl apply -f pt/densenet161/deployment.yml

    2. Verifica che il server sia in esecuzione come previsto con il seguente comando:

      kubectl get deployment densenet161-deployment

      La lettura di 3 da parte di AVAILABLE potrebbe richiedere un minuto.

    3. Applica il servizio del bilanciatore del carico:

      kubectl apply -f pt/densenet161/loadbalancer.yml

      Verifica che il bilanciatore del carico sia pronto per il traffico esterno con seguente comando:

      kubectl get svc densenet161-service

      Potrebbero essere necessari alcuni minuti prima che EXTERNAL_IP visualizzi un IP.

  3. Invia richiesta di test al server del modello:

    1. Ottieni un IP esterno dal bilanciatore del carico:

      EXTERNAL_IP=$(kubectl get services densenet161-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

    2. Esegui lo script della richiesta di test per inviare la richiesta (HTTP) al server del modello:

      python3 pt/densenet161/request.py --host $EXTERNAL_IP

      Dovresti vedere 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

  4. 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 GKE e cluster quando esegui se ne finiamo.

Risoluzione dei problemi più comuni

Le informazioni sulla risoluzione dei problemi di GKE sono disponibili all'indirizzo Risolvi i problemi relativi alle TPU in GKE.

Inizializzazione della TPU non riuscita

Se si verifica il seguente errore, assicurati di eseguire la tua TPU container in modalità con privilegi o hai aumentato ulimit all'interno del containerizzato. Per maggiori informazioni, vedi 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

Programmazione deadlock

Supponi di avere due job (Job A e Job B) ed entrambi devono essere pianificati sulla TPU sezioni con una determinata topologia TPU (ad esempio, v4-32). Supponiamo inoltre di avere due sezioni TPU v4-32 all'interno del cluster GKE; il nostro chiameremo queste sezioni X e Y. Poiché il cluster ha un'ampia capacità pianificare entrambi i lavori, in teoria entrambi dovrebbero essere pianificati rapidamente: un job ciascuna delle due sezioni v4-32 TPU.

Tuttavia, senza un'attenta pianificazione, è possibile entrare in una pianificazione una situazione di stallo. Supponiamo che lo scheduler Kubernetes pianifica un pod Kubernetes da Job A sulla sezione X, quindi pianifica un pod Kubernetes dal job B nella sezione X. Nel In questo caso, date le regole di affinità dei pod di Kubernetes per il job A, tentare di pianificare tutti i pod Kubernetes rimanenti per il job A nella sezione X. Lo stesso per Lavoro B. Quindi né il job A né il job B potranno essere pianificati singola sezione. Il risultato sarà un deadlock di pianificazione.

Per evitare il rischio di un deadlock di pianificazione, puoi utilizzare Kubernetes Pod anti-affinità con cloud.google.com/gke-nodepool come topologyKey come mostrato nel seguente esempio:

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 un cluster esistente in cui vuoi creare una TPU multi-host pool di nodi, 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 stai eseguendo il carico di lavoro.
  • your-node-pool: il nome del pool di nodi che stai creando.
  • us-central2: la regione in cui stai eseguendo il carico di lavoro.
  • us-central2-b: la zona in cui stai eseguendo il carico di lavoro.
  • your-reservation-name: il nome della prenotazione.

Crea un pool di nodi della sezione TPU a host singolo in un cluster GKE esistente

Usa 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 stai eseguendo il carico di lavoro.
  • your-node-pool: il nome del pool di nodi che stai creando.
  • us-central2: la regione in cui stai eseguendo il carico di lavoro.
  • us-central2-b: la zona in cui stai eseguendo il carico di lavoro.