Esegui il deployment dei carichi di lavoro TPU in GKE Standard

Questa pagina fornisce le basi per imparare ad accelerare i workload di machine learning (ML) utilizzando le TPU in Google Kubernetes Engine (GKE). Le TPU sono progettate per l'elaborazione della moltiplicazione di matrici, ad esempio l'addestramento di modelli di deep learning su larga scala. Le TPU sono ottimizzate per gestire gli enormi set di dati e i modelli complessi del machine learning e sono quindi più convenienti ed efficienti dal punto di vista energetico per i carichi di lavoro ML grazie alle loro prestazioni superiori. In questa guida scoprirai come eseguire il deployment dei carichi di lavoro di machine learning utilizzando gli acceleratori Cloud TPU, configurare le quote per le TPU, configurare gli upgrade per i pool di nodi che eseguono le TPU e monitorare le metriche dei carichi di lavoro TPU.

Questo tutorial è rivolto a ingegneri di machine learning (ML) e amministratori e operatori di piattaforme interessati a utilizzare l'orchestrazione di container Kubernetes per gestire workload di addestramento, ottimizzazione e inferenza di modelli su larga scala utilizzando le TPU. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui si fa riferimento nei contenuti di Trusted Cloud by S3NS , consulta Ruoli utente e attività comuni di GKE Enterprise.

Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

• Cloud TPU
• Architettura di sistema di Cloud TPU
• TPU in GKE

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Pianificare la configurazione TPU

Pianifica la configurazione della TPU in base al modello e alla quantità di memoria richiesta. Prima di utilizzare questa guida per eseguire il deployment dei carichi di lavoro sulla TPU, completa i passaggi di pianificazione descritti in Pianificare la configurazione della TPU.

Assicurati di avere una quota TPU

Quota per le VM on demand o spot

Se stai creando un pool di nodi di slice TPU con VM on demand o spot, devi disporre di una quota TPU sufficiente disponibile nella regione che vuoi utilizzare.

La creazione di un pool di nodi di slice TPU che utilizza una prenotazione TPU non richiede alcuna quota TPU.¹ Puoi saltare questa sezione per le TPU riservate.

La creazione di un pool di nodi di slice TPU on demand o spot in GKE richiede una quota dell'API Compute Engine. La quota dell'API Compute Engine (compute.googleapis.com) non è la stessa della quota dell'API Cloud TPU (tpu.googleapis.com), necessaria per creare TPU con l'API Cloud TPU.

Per controllare il limite e l'utilizzo attuale della quota API Compute Engine per le TPU, segui questi passaggi:

1. Vai alla pagina Quote nella console Trusted Cloud :

   Vai a Quote

2. Nella casella filter_list Filtro, procedi nel seguente modo:

   1. Utilizza la seguente tabella per selezionare e copiare la proprietà della quota in base alla versione della TPU e al tipo di macchina. Ad esempio, se prevedi di creare nodi TPU v5e on demand il cui tipo di macchina inizia con ct5lp-, inserisci Name: TPU v5 Lite PodSlice chips.

      Versione TPU, il tipo di macchina inizia con	Proprietà e nome della quota per le istanze on demand	Proprietà e nome della quota per le istanze Spot2
      TPU v3, ct3-	Dimensions (e.g. location): tpu_family:CT3	Non applicabile
      TPU v3, ct3p-	Dimensions (e.g. location): tpu_family:CT3P	Non applicabile
      TPU v4, ct4p-	Name: TPU v4 PodSlice chips	Name: Preemptible TPU v4 PodSlice chips
      TPU v5e, ct5lp-	Name: TPU v5 Lite PodSlice chips	Name: Preemptible TPU v5 Lite Podslice chips
      TPU v5p, ct5p-	Name: TPU v5p chips	Name: Preemptible TPU v5p chips
      TPU Trillium, ct6e-	Dimensions (e.g. location): tpu_family:CT6E	Name: Preemptible TPU slices v6e

   2. Seleziona la proprietà Dimensioni (ad es. località) e inserisci region: seguito dal nome della regione in cui prevedi di creare TPU in GKE. Ad esempio, inserisci region:us-west4 se prevedi di creare nodi slice TPU nella zona us-west4-a. La quota TPU è regionale, quindi tutte le zone all'interno della stessa regione consumano la stessa quota TPU.

Se nessuna quota corrisponde al filtro inserito, significa che al progetto non è stata concessa nessuna delle quote specificate per la regione di cui hai bisogno e devi richiedere una modifica della quota TPU.

Quando viene creata una prenotazione TPU, sia il limite che i valori di utilizzo attuali per la quota corrispondente aumentano del numero di chip nella prenotazione TPU. Ad esempio, quando viene creata una prenotazione per 16 chip TPU v5e il cui tipo di macchina inizia con ct5lp-, sia il limite che l'utilizzo attuale per la quota TPU v5 Lite PodSlice chips nella regione pertinente aumentano di 16.

Quote per risorse GKE aggiuntive

Potresti dover aumentare le seguenti quote relative a GKE nelle regioni in cui GKE crea le risorse.

• Quota SSD Persistent Disk (GB): il disco di avvio di ogni nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata almeno sul prodotto del numero massimo di nodi GKE che prevedi di creare e 100 GB (nodi * 100 GB).
• Quota di indirizzi IP in uso: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno sul numero massimo di nodi GKE che prevedi di creare.
• Assicurati che max-pods-per-node sia in linea con l'intervallo di subnet: ogni nodo Kubernetes utilizza intervalli IP secondari per i pod. Ad esempio, max-pods-per-node di 32 richiede 64 indirizzi IP, il che si traduce in una subnet /26 per nodo. Tieni presente che questo intervallo non deve essere condiviso con nessun altro cluster. Per evitare di esaurire l'intervallo di indirizzi IP, utilizza il flag --max-pods-per-node per limitare il numero di pod che possono essere pianificati su un nodo. La quota per max-pods-per-node deve essere impostata almeno al livello del numero massimo di nodi GKE che prevedi di creare.

Per richiedere un aumento della quota, consulta Richiedi un aggiustamento delle quote.

Garantire la disponibilità della prenotazione

La creazione di un pool di nodi di sezioni TPU riservate, che utilizza una prenotazione, non richiede alcuna quota TPU. Tuttavia, la prenotazione deve avere un numero sufficiente di chip TPU disponibili o inutilizzati al momento della creazione del pool di nodi.

Per vedere quali prenotazioni esistono all'interno di un progetto e quanti chip TPU sono disponibili in una prenotazione TPU, visualizza un elenco delle tue prenotazioni.

Opzioni per il provisioning delle TPU in GKE

GKE ti consente di utilizzare le TPU direttamente nei singoli workload utilizzando i nodeSelector di Kubernetes nel manifest del workload o creando pool di nodi in modalità Standard con le TPU.

In alternativa, puoi richiedere TPU utilizzando classi di calcolo personalizzate. Le classi di calcolo personalizzate consentono agli amministratori della piattaforma di definire una gerarchia di configurazioni dei nodi che GKE deve dare la priorità durante le decisioni di scalabilità dei nodi, in modo che i workload vengano eseguiti sull'hardware selezionato.

Per istruzioni, consulta la sezione Provisioning di TPU utilizzando classi di calcolo personalizzate.

Crea un cluster

Crea un cluster GKE in modalità Standard in una regione con TPU disponibili.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del nuovo cluster.
• LOCATION: la regione con la capacità TPU disponibile.
• VERSION: la versione di GKE, che deve supportare il tipo di macchina che vuoi utilizzare. Tieni presente che la versione GKE predefinita potrebbe non essere disponibile per la TPU di destinazione. Per scoprire quali sono le versioni GKE minime disponibili per tipo di macchina TPU, consulta Disponibilità di TPU in GKE.

Crea un node pool

Puoi creare un pool di nodi TPU slice single-host o multi-host.

Crea un pool di nodi TPU slice single-host

Puoi creare un pool di nodi di slice TPU a singolo host utilizzando Google Cloud CLI, Terraform o la console Trusted Cloud .

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Crea un pool di nodi TPU multislice multi-host

Puoi creare un pool di nodi slice TPU multi-host utilizzando Google Cloud CLI, Terraform o la console Trusted Cloud .

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    [--num-nodes=NUM_NODES] \
    [--spot \]
    [--flex-start \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
    [--placement-type=COMPACT]

Come GKE gestisce i problemi di capacità

Se GKE non riesce a creare il node pool della sezione TPU a causa di una capacità TPU insufficiente, restituisce un messaggio di errore che indica che i nodi della sezione TPU non possono essere creati a causa della mancanza di capacità.

Se stai creando un pool di nodi TPU slice single-host, il messaggio di errore è simile al seguente:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Se stai creando un pool di nodi TPU multislice, il messaggio di errore è simile al seguente:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

La richiesta di provisioning della TPU può rimanere in coda a lungo e rimane nello stato "Provisioning" mentre è in coda.

Una volta disponibile la capacità, GKE crea i nodi rimanenti che non sono stati creati.

Se hai bisogno di capacità prima, valuta la possibilità di provare le VM spot, anche se tieni presente che le VM spot consumano una quota diversa rispetto alle istanze on demand.

Puoi eliminare la richiesta TPU in coda eliminando il pool di nodi dello slice TPU.

Esegui il carico di lavoro sui nodi delle sezioni TPU

Questa sezione spiega come preparare i carichi di lavoro ed esempi di come puoi eseguirli.

Prepara i tuoi workload

I carichi di lavoro TPU hanno i seguenti requisiti di preparazione.

1. Framework come JAX, PyTorch e TensorFlow accedono alle VM TPU utilizzando la libreria condivisa libtpu. libtpu include il compilatore XLA, il software di runtime TPU e il driver TPU. Ogni release di PyTorch e JAX richiede una determinata versione di libtpu.so. Per utilizzare le TPU in GKE, assicurati di utilizzare le seguenti versioni:

   Tipo di TPU	libtpu.so versione
   TPU Trillium (v6e) tpu-v6e-slice	Versione jax[tpu] consigliata: v0.4.9 o successive Versione consigliata di torchxla[tpuvm]: v2.1.0 o successive
   TPU v5e tpu-v5-lite-podslice	Versione jax[tpu] consigliata: v0.4.9 o successive Versione consigliata di torchxla[tpuvm]: v2.1.0 o successive
   TPU v5p tpu-v5p-slice	Versione jax[tpu] consigliata: 0.4.19 o successive. Versione consigliata di torchxla[tpuvm]: si consiglia di utilizzare una versione nightly creata il 23 ottobre 2023.
   TPU v4 tpu-v4-podslice	jax[tpu] consigliato: v0.4.4 o versioni successive torchxla[tpuvm] consigliato: v2.0.0 o versioni successive
   TPU v3 tpu-v3-slice tpu-v3-device	jax[tpu] consigliato: v0.4.4 o versioni successive torchxla[tpuvm] consigliato: v2.0.0 o versioni successive

2. Imposta le seguenti variabili di ambiente per il container che richiede le risorse TPU:
   • TPU_WORKER_ID: un numero intero univoco per ogni pod. Questo ID indica un worker-id univoco nella slice TPU. I valori supportati per questo campo vanno da zero al numero di pod meno uno.
   • TPU_WORKER_HOSTNAMES: un elenco separato da virgole di nomi host o indirizzi IP delle VM TPU che devono comunicare tra loro all'interno dello slice. Deve essere presente un nome host o un indirizzo IP per ogni VM TPU nello slice. L'elenco di indirizzi IP o nomi host è ordinato e indicizzato a zero in base a TPU_WORKER_ID.

   GKE inserisce automaticamente queste variabili di ambiente utilizzando un webhook di mutazione quando viene creato un job con le proprietà completionMode: Indexed, subdomain, parallelism > 1 e google.com/tpu. GKE aggiunge un servizio headless in modo che i record DNS vengano aggiunti per i pod che supportano il servizio.

   Quando esegui il deployment di risorse TPU multi-host con Kuberay, GKE fornisce un webhook di cui è possibile eseguire il deployment nell'ambito dei modelli Terraform sperimentali per l'esecuzione di Ray su GKE. Le istruzioni per eseguire Ray su GKE con le TPU sono disponibili nella guida per l'utente TPU sperimentale. Il webhook di mutazione inserirà queste variabili di ambiente nei cluster Ray che richiedono proprietà google.com/tpu e un selettore di nodi cloud.google.com/gke-tpu-topology multihost.

   • Nel manifest del workload, aggiungi i selettori dei nodi Kubernetes per assicurarti che GKE pianifichi il workload TPU sul tipo di macchina TPU e sulla topologia TPU che hai definito:

       nodeSelector:
         cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
         cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
       

     Sostituisci quanto segue:

     • TPU_ACCELERATOR: il nome dell'acceleratore TPU.
     • TPU_TOPOLOGY: la topologia fisica per la sezione TPU. Il formato della topologia dipende dalla versione della TPU. Per saperne di più, consulta Pianificare le TPU in GKE.

Una volta completata la preparazione del workload, puoi eseguire un job che utilizza le TPU.

Le sezioni seguenti mostrano esempi di come eseguire un job che esegue un semplice calcolo con le TPU.

Esempio 1: esegui un carico di lavoro che mostra il numero di chip TPU disponibili in un pool di nodi di sezioni TPU

Il seguente carico di lavoro restituisce il numero di chip TPU in tutti i nodi di una sezione TPU multi-host. Per creare una sezione multihost, il carico di lavoro ha i seguenti parametri:

• Versione TPU: TPU v4
• Topologia: 2x2x4

Questa selezione di versione e topologia genera una sezione multi-host.

1. Salva il seguente manifest come available-chips-multihost.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: headless-svc
   spec:
     clusterIP: None
     selector:
       job-name: tpu-available-chips
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: tpu-available-chips
   spec:
     backoffLimit: 0
     completions: 4
     parallelism: 4
     completionMode: Indexed
     template:
       spec:
         subdomain: headless-svc
         restartPolicy: Never
         nodeSelector:
           cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
           cloud.google.com/gke-tpu-topology: 2x2x4
         containers:
         - name: tpu-job
           image: python:3.10
           ports:
           - containerPort: 8471 # Default port using which TPU VMs communicate
           - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
           securityContext:
             privileged: true
           command:
           - bash
           - -c
           - |
             pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
             python -c 'import jax; print("TPU cores:", jax.device_count())'
           resources:
             requests:
               cpu: 10
               memory: 407Gi
               google.com/tpu: 4
             limits:
               cpu: 10
               memory: 407Gi
               google.com/tpu: 4

2. Esegui il deployment del manifest:

   kubectl create -f available-chips-multihost.yaml
   

   GKE esegue una sezione TPU v4 con quattro VM (sezione TPU multi-host). La sezione ha 16 chip TPU interconnessi.

3. Verifica che il job abbia creato quattro pod:

   kubectl get pods
   

   L'output è simile al seguente:

   NAME                       READY   STATUS      RESTARTS   AGE
   tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
   tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
   tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
   tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
   

4. Recupera i log di uno dei pod:

   kubectl logs POD_NAME
   

   Sostituisci POD_NAME con il nome di uno dei pod creati. Ad esempio, tpu-job-podslice-0-5cd8r.

   L'output è simile al seguente:

   TPU cores: 16
   

5. (Facoltativo) Rimuovi il workload:

   kubectl delete -f available-chips-multihost.yaml
   

Esempio 2: esegui un carico di lavoro che mostra il numero di chip TPU disponibili nella sezione TPU

Il seguente workload è un pod statico che mostra il numero di chip TPU collegati a un nodo specifico. Per creare un nodo a singolo host, il workload ha i seguenti parametri:

• Versione TPU: TPU v5e
• Topologia: 2x4

Questa selezione di versione e topologia genera una sezione a singolo host.

1. Salva il seguente manifest come available-chips-singlehost.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: tpu-job-jax-v5
   spec:
     restartPolicy: Never
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
       cloud.google.com/gke-tpu-topology: 2x4
     containers:
     - name: tpu-job
       image: python:3.10
       ports:
       - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
       securityContext:
         privileged: true
       command:
       - bash
       - -c
       - |
         pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
         python -c 'import jax; print("Total TPU chips:", jax.device_count())'
       resources:
         requests:
           google.com/tpu: 8
         limits:
           google.com/tpu: 8

2. Esegui il deployment del manifest:

   kubectl create -f available-chips-singlehost.yaml
   

   GKE esegue il provisioning dei nodi con otto sezioni TPU a singolo host che utilizzano TPU v5e. Ogni nodo TPU ha otto chip TPU (sezione TPU a host singolo).

3. Recupera i log del pod:

   kubectl logs tpu-job-jax-v5
   

   L'output è simile al seguente:

   Total TPU chips: 8
   

4. (Facoltativo) Rimuovi il workload:

     kubectl delete -f available-chips-singlehost.yaml
     

Esegui l'upgrade dei node pool utilizzando gli acceleratori (GPU e TPU)

GKE esegue automaticamente l'upgrade dei cluster Standard, inclusi i node pool. Puoi anche eseguire l'upgrade manuale dei pool di nodi se vuoi che i tuoi nodi utilizzino una versione successiva prima. Per controllare il funzionamento degli upgrade per il tuo cluster, utilizza i canali di rilascio, i periodi di manutenzione e le esclusioni e il sequenziamento del rollout.

Puoi anche configurare una strategia di upgrade dei nodi per il tuo pool di nodi, ad esempio upgrade di incremento, upgrade blue-green o upgrade di breve durata. Configurando queste strategie, puoi assicurarti che i pool di nodi vengano sottoposti a upgrade in modo da ottenere l'equilibrio ottimale tra velocità e interruzione per il tuo ambiente. Per i node pool TPU multi-host, anziché utilizzare la strategia di upgrade dei nodi configurata, GKE ricrea in modo atomico l'intero pool di nodi in un unico passaggio. Per scoprire di più, consulta la definizione di atomicità nella sezione Terminologia relativa a TPU in GKE.

L'utilizzo di una strategia di upgrade dei nodi richiede temporaneamente a GKE di eseguire il provisioning di risorse aggiuntive, a seconda della configurazione. Se Trusted Cloud by S3NS ha una capacità limitata per le risorse del pool di nodi, ad esempio se visualizzi errori di disponibilità delle risorse quando tenti di creare più nodi con GPU o TPU, consulta Eseguire l'upgrade in un ambiente con risorse limitate.

Esegui la pulizia

Per evitare che al tuo account Trusted Cloud vengano addebitati costi relativi alle risorse utilizzate in questa guida, valuta la possibilità di eliminare i node pool di slice TPU che non hanno più workload pianificati. Se i workload in esecuzione devono essere terminati in modo controllato, utilizza kubectl drain per pulirli prima di eliminare il nodo.

1. Elimina un pool di nodi di slice TPU:

   gcloud container node-pools delete POOL_NAME \
       --location=LOCATION \
       --cluster=CLUSTER_NAME
   

   Sostituisci quanto segue:

   • POOL_NAME: il nome del pool di nodi.
   • CLUSTER_NAME: il nome del cluster.
   • LOCATION: la posizione di computing del cluster.

Configura le impostazioni aggiuntive

Le sezioni seguenti descrivono le configurazioni aggiuntive che puoi applicare ai tuoi carichi di lavoro TPU.

Gestire la pianificazione della raccolta

In TPU Trillium, puoi utilizzare la pianificazione della raccolta per raggruppare i nodi delle sezioni TPU. Il raggruppamento di questi nodi slice TPU semplifica la regolazione del numero di repliche per soddisfare la domanda del carico di lavoro. Trusted Cloud controlla gli aggiornamenti software per garantire che siano sempre disponibili slice sufficienti all'interno della raccolta per gestire il traffico.

TPU Trillium supporta la pianificazione della raccolta per i node pool single-host e multi-host che eseguono carichi di lavoro di inferenza. Di seguito viene descritto come il comportamento di pianificazione della raccolta dipende dal tipo di sezione TPU che utilizzi:

• Sezione TPU multi-host:GKE raggruppa le sezioni TPU multi-host per formare una raccolta. Ogni pool di nodi GKE è una replica all'interno di questa raccolta. Per definire una raccolta, crea uno slice TPU multihost e assegna un nome univoco alla raccolta. Per aggiungere altre sezioni di TPU alla raccolta, crea un altro pool di nodi di sezioni di TPU multi-host con lo stesso nome della raccolta e tipo di carico di lavoro.
• Sezione TPU single-host:GKE considera l'intero pool di nodil della sezione TPU single-host come una raccolta. Per aggiungere altre sezioni TPU alla raccolta, puoi ridimensionare ilpool di nodil di sezioni TPU single-host.

Per gestire una raccolta, esegui una di queste azioni in base al tipo di pool di nodi che utilizzi.

Gestire la pianificazione della raccolta nei node pool TPU multi-host

Utilizza le seguenti attività per gestire i node pool delle sezioni di TPU multi-host.

• Per verificare se un pool di slice TPU multihost fa parte di una raccolta, esegui questo comando:

  gcloud container node-pools describe NODE_POOL_NAME \
      --location LOCATION \
      --cluster CLUSTER_NAME \
      --format="json" | jq -r \
      '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'
  

  L'output è simile al seguente:

  nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
  gke-workload-type: HIGH_AVAILABILITY
  

  Se il pool di sezioni TPU multi-host fa parte di una raccolta, l'output ha le seguenti etichette:

  • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
  • cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

• Per ottenere l'elenco delle raccolte nel cluster, esegui questo comando:

  #!/bin/bash
  
  # Replace with your cluster name, project, and location
  CLUSTER_NAME=CLUSTER_NAME
  PROJECT=PROJECT_ID
  LOCATION=LOCATION
  
  declare -A collection_names
  
  node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")
  
  # Iterate over each node pool
  for pool in $node_pools; do
      # Describe the node pool and extract labels using jq
      collection_name=$(gcloud container node-pools describe "$pool" \
          --cluster "$CLUSTER_NAME" \
          --project "$PROJECT" \
          --location "$LOCATION" \
          --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')
  
      # Add the collection name to the associative array if it's not empty
      if [[ -n "$collection_name" ]]; then
          collection_names["$collection_name"]=1
      fi
  done
  
  # Print the unique node pool collection names
  echo "Unique cloud.google.com/gke-nodepool-group-name values:"
  for name in "${!collection_names[@]}"; do
      echo "$name"
  done
  

  L'output è simile al seguente:

  Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}
  

• Per ottenere un elenco dei node pool appartenenti a una raccolta, esegui questo comando:

  #!/bin/bash
  
  TARGET_COLLECTION_NAME=COLLECTION_NAME
  CLUSTER_NAME=CLUSTER_NAME
  PROJECT=PROJECT_ID
  LOCATION=LOCATION
  
  matching_node_pools=()
  
  # Get the list of all node pools in the cluster
  node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")
  
  # Iterate over each node pool
  for pool in $node_pools; do
      # Get the value of the cloud.google.com/gke-nodepool-group-name label
      collection_name=$(gcloud container node-pools describe "$pool" \
          --cluster "$CLUSTER_NAME" \
          --project "$PROJECT" \
          --location "$LOCATION" \
          --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')
  
      # Check if the group name matches the target value
      if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
          matching_node_pools+=("$pool")
      fi
  done
  
  # Print the list of matching node pools
  echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
  for pool in "${matching_node_pools[@]}"; do
      echo "$pool"
  done
  

  L'output è simile al seguente:

  Node pools with collection name 'COLLECTION_NAME':
  {NODE_POOL_NAME_1}
  {NODE_POOL_NAME_2}
  {NODE_POOL_NAME_3}
  

• Per scalare la raccolta, crea un altro pool di nodi di slice TPU multi-host e aggiungi cloud.google.com/gke-workload-type e cloud.google.com/gke-nodepool-group-name. Utilizza lo stesso nome della raccolta in cloud.google.com/gke-nodepool-group-name ed esegui lo stesso tipo di workload. Se il provisioning automatico dei nodi è abilitato sul cluster, GKE crea automaticamente i pool in base alle esigenze del carico di lavoro.

• Per fare lo scale down della raccolta, elimina il node pool.

• Per eliminare la raccolta, rimuovi tutti i pool di nodi collegati. Puoi eliminare il node pool o eliminare il cluster. L'eliminazione del cluster rimuove tutte le raccolte al suo interno.

Gestire la pianificazione della raccolta nei pool di nodi delle sezioni TPU single-host

Utilizza le seguenti attività per gestire i node pool delle sezioni TPU single-host.

• Per verificare se il pool di slice TPU a un solo host ha la pianificazione della raccolta abilitata, esegui questo comando:

  gcloud container node-pools describe NODE_POOL_NAME \
      --cluster CLUSTER_NAME \
      --project PROJECT_NAME \
      --location LOCATION \
      --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
  

  L'output è simile al seguente:

  gke-workload-type: HIGH_AVAILABILITY
  

  Se il pool di sezioni TPU single-host fa parte di una raccolta, l'output ha l'etichetta cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

• Per scalare orizzontalmente la raccolta, ridimensiona il pool di nodi manualmente o automaticamente con il provisioning automatico dei nodi.

• Per fare lo scale down della raccolta, elimina il node pool.

• Per eliminare la raccolta, rimuovi tutti i pool di nodi collegati. Puoi eliminare il node pool o eliminare il cluster. L'eliminazione del cluster rimuove tutte le raccolte al suo interno.

Utilizzare Multislice

Puoi aggregare sezioni più piccole in un multislice per gestire carichi di lavoro di addestramento più grandi. Per maggiori informazioni, consulta TPU multislice in GKE.

Migra la prenotazione TPU

Se hai prenotazioni TPU esistenti, devi prima eseguire la migrazione della prenotazione TPU a un nuovo sistema di prenotazione basato su Compute Engine. Puoi anche creare un sistema di prenotazione basato su Compute Engine in cui non è necessaria alcuna migrazione. Per scoprire come eseguire la migrazione delle prenotazioni TPU, consulta Prenotazione TPU.

Abilita il logging

I log emessi dai container in esecuzione sui nodi GKE, incluse le VM TPU, vengono raccolti dall'agente di logging GKE, inviati a Logging e sono visibili in Logging.

Utilizza il provisioning automatico dei nodi GKE

Puoi configurare GKE in modo da creare ed eliminare automaticamente i node pool per soddisfare le esigenze di risorse dei tuoi workload TPU. Per ulteriori informazioni, consulta la pagina Configurazione delle Cloud TPU.

Eseguire il provisioning delle TPU utilizzando classi di calcolo personalizzate

Puoi anche configurare GKE per richiedere TPU durante le operazioni di scalabilità che creano nuovi nodi utilizzando classi di calcolo personalizzate.

Puoi specificare le opzioni di configurazione della TPU nella specifica della classe di calcolo personalizzata. Quando un carico di lavoro GKE utilizza questa classe di calcolo personalizzata, GKE tenta di eseguire il provisioning delle TPU che utilizzano la configurazione specificata durante lo scale up.

Per eseguire il provisioning delle TPU con una classe di calcolo personalizzata che segue le regole TPU ed eseguire il deployment del carico di lavoro, completa i seguenti passaggi:

1. Salva il seguente manifest come tpu-compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: tpu-class
   spec:
     priorities:
     - tpu:
         type: tpu-v5-lite-podslice
         count: 4
         topology: 2x4
     - spot: true
       tpu:
         type: tpu-v5-lite-podslice
         count: 4
         topology: 2x4
     - flexStart:
         enabled: true
       tpu:
         type: tpu-v6e-slice
         count: 4
         topology: 2x4
     nodePoolAutoCreation:
       enabled: true
   

2. Esegui il deployment della classe di computing:

   kubectl apply -f tpu-compute-class.yaml
   

   Per saperne di più sulle classi di calcolo personalizzate e sulle TPU, consulta la sezione Configurazione TPU.

3. Salva il seguente manifest come tpu-job.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: headless-svc
   spec:
     clusterIP: None
     selector:
       job-name: tpu-job
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: tpu-job
   spec:
     backoffLimit: 0
     completions: 4
     parallelism: 4
     completionMode: Indexed
     template:
       spec:
         subdomain: headless-svc
         restartPolicy: Never
         nodeSelector:
           cloud.google.com/compute-class: tpu-class
         containers:
         - name: tpu-job
           image: python:3.10
           ports:
           - containerPort: 8471 # Default port using which TPU VMs communicate
           - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
           command:
           - bash
           - -c
           - |
             pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
             python -c 'import jax; print("TPU cores:", jax.device_count())'
           resources:
             requests:
               cpu: 10
               memory: MEMORY_SIZE
               google.com/tpu: NUMBER_OF_CHIPS
             limits:
               cpu: 10
               memory: MEMORY_SIZE
               google.com/tpu: NUMBER_OF_CHIPS
   

   Sostituisci quanto segue:

   • NUMBER_OF_CHIPS: il numero di chip TPU da utilizzare per il container. Deve essere lo stesso valore per limits e requests, uguale al valore nel campo tpu.count nella classe di calcolo personalizzata selezionata.
   • MEMORY_SIZE: la quantità massima di memoria utilizzata dalla TPU. I limiti di memoria dipendono dalla versione e dalla topologia della TPU che utilizzi. Per saperne di più, consulta Valori minimi e massimi per gli acceleratori.
   • NUMBER_OF_CHIPS: il numero di chip TPU da utilizzare per il container. Deve essere lo stesso valore per limits e requests.

4. Esegui il deployment del job:

   kubectl create -f tpu-job.yaml
   

   Quando crei questo job, GKE esegue automaticamente le seguenti operazioni:

   • Esegue il provisioning dei nodi per eseguire i pod. A seconda del tipo di TPU, della topologia e delle richieste di risorse che hai specificato, questi nodi sono sezioni single-host o multi-host. A seconda della disponibilità delle risorse TPU nella priorità più alta, GKE potrebbe ricorrere a priorità inferiori per massimizzare l'ottenibilità.
   • Aggiunge incompatibilità ai pod e tolleranze ai nodi per impedire l'esecuzione di altri carichi di lavoro sugli stessi nodi dei carichi di lavoro TPU.

   Per saperne di più, consulta Informazioni sulle classi di calcolo personalizzate.

5. Al termine di questa sezione, puoi evitare l'addebito di ulteriori costi eliminando le risorse create:

   kubectl delete -f tpu-job.yaml
   

Configura la riparazione automatica per i nodi slice TPU

Se un nodo di sezione TPU in un pool di nodi di sezioni TPU multi-host non è integro, l'intero pool di nodi viene ricreato. In un pool di nodi TPU a host singolo, invece, viene riparato automaticamente solo il nodo TPU non integro.

Le condizioni che comportano nodi di sezioni TPU non integri includono quanto segue:

• Qualsiasi nodo di sezione TPU con condizioni comuni.
• Qualsiasi nodo di sezione TPU con un conteggio TPU non allocabile maggiore di zero.
• Qualsiasi istanza VM in una sezione TPU che è stata arrestata (a causa del prerilascio) o terminata.
• Manutenzione dei nodi: se un nodo di una sezione TPU all'interno di un pool di nodi di una sezione TPU multi-host non funziona per la manutenzione dell'host, GKE ricrea l'intero pool di nodi della sezione TPU.

Puoi visualizzare lo stato della riparazione (incluso il motivo dell'errore) nella cronologia delle operazioni. Se l'errore è causato da una quota insufficiente, contatta il tuo rappresentante dell'accountTrusted Cloud per aumentare la quota corrispondente.

Configura l'arresto controllato per i nodi slice TPU

Nei cluster GKE con il control plane che esegue la versione 1.29.1-gke.1425000 o successive, i nodi delle sezioni TPU supportano i segnali SIGTERM che avvisano il nodo di un arresto imminente. La notifica di arresto imminente è configurabile fino a cinque minuti nei nodi TPU.

Per configurare GKE in modo che termini i tuoi carichi di lavoro in modo controllato entro questo periodo di notifica, segui i passaggi descritti in Gestire l'interruzione dei nodi GKE per GPU e TPU.

Esegui container senza modalità con privilegi

I container in esecuzione nei nodi di GKE 1.28 o versioni successive non devono avere la modalità con privilegi abilitata per accedere alle TPU. I nodi in GKE 1.28 e versioni precedenti richiedono la modalità con privilegi.

Se il nodo slice TPU esegue versioni precedenti alla 1.28, leggi la sezione seguente:

Un container in esecuzione su una VM in una sezione TPU deve accedere a limiti più elevati per la memoria bloccata, in modo che il driver possa comunicare con i chip TPU tramite l'accesso diretto alla memoria (DMA). Per abilitare questa opzione, devi configurare un valore di ulimit più elevato. Se vuoi ridurre l'ambito delle autorizzazioni sul tuo contenitore, completa i seguenti passaggi:

1. Modifica securityContext per includere i seguenti campi:

   securityContext:
     capabilities:
       add: ["SYS_RESOURCE"]
   

2. Aumenta ulimit eseguendo il seguente comando all'interno del container prima di configurare i carichi di lavoro per utilizzare le risorse TPU:

   ulimit -l 68719476736
   

Per TPU v5e, l'esecuzione di container senza modalità privilegiata è disponibile nei cluster nella versione 1.27.4-gke.900 e successive.

Osservabilità e metriche

Dashboard

L'osservabilità del node pool nella Trusted Cloud console è disponibile pubblicamente. Per visualizzare lo stato dei tuoi node pool TPU multi-host su GKE, vai alla dashboard Stato del node pool TPU GKE fornita da Cloud Monitoring:

Vai a Stato del node pool GKE TPU

Questa dashboard fornisce informazioni complete sullo stato dei tuoi node pool TPU multi-host. Per saperne di più, consulta Monitorare le metriche di integrità per i nodi TPU e i pool di nodi.

Nella pagina Cluster Kubernetes della consoleTrusted Cloud , la scheda Osservabilità mostra anche le metriche di osservabilità delle TPU, come l'utilizzo delle TPU, sotto l'intestazione Acceleratori > TPU. Per ulteriori informazioni, consulta Visualizzare le metriche di osservabilità.

La dashboard TPU viene compilata solo se hai abilitato le metriche di sistema nel tuo cluster GKE.

Metriche di runtime

In GKE 1.27.4-gke.900 o versioni successive, i carichi di lavoro TPU che utilizzano JAX versione 0.4.14 o successive e specificano containerPort: 8431 esportano le metriche di utilizzo della TPU come metriche di sistema GKE. In Cloud Monitoring sono disponibili le seguenti metriche per monitorare le prestazioni di runtime del carico di lavoro TPU:

• Ciclo di lavoro: percentuale di tempo nell'ultimo periodo di campionamento (60 secondi) durante il quale i TensorCore hanno eseguito attivamente l'elaborazione su un chip TPU. Una percentuale maggiore indica un migliore utilizzo della TPU.
• Memoria utilizzata: quantità di memoria dell'acceleratore allocata in byte. Campionamento eseguito ogni 60 secondi.
• Memoria totale: memoria totale dell'acceleratore in byte. Campionamento eseguito ogni 60 secondi.

Queste metriche si trovano nello schema del nodo Kubernetes (k8s_node) e del container Kubernetes (k8s_container).

Container Kubernetes:

• kubernetes.io/container/accelerator/duty_cycle
• kubernetes.io/container/accelerator/memory_used
• kubernetes.io/container/accelerator/memory_total

Nodo Kubernetes:

• kubernetes.io/node/accelerator/duty_cycle
• kubernetes.io/node/accelerator/memory_used
• kubernetes.io/node/accelerator/memory_total

Monitora le metriche di integrità per i nodi TPU e i pool di nodi

Quando un job di addestramento genera un errore o termina con esito negativo, puoi controllare le metriche relative all'infrastruttura sottostante per capire se l'interruzione è stata causata da un problema con il nodo o il pool di nodi sottostante.

Stato nodo

In GKE versione 1.32.1-gke.1357001 o successive, la seguente metrica di sistema GKE mostra la condizione di un nodo GKE:

• kubernetes.io/node/status_condition

Il campo condition riporta le condizioni del nodo, ad esempio Ready, DiskPressure e MemoryPressure. Il campo status mostra lo stato segnalato della condizione, che può essere True, False o Unknown. Si tratta di una metrica con il tipo di risorsa monitorata k8s_node.

Questa query PromQL mostra se un determinato nodo è Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Per risolvere i problemi in un cluster, potresti voler esaminare i nodi che hanno mostrato altre condizioni:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Potresti voler esaminare in modo specifico i nodi che non sono Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Se non sono presenti dati, i nodi sono pronti. La condizione di stato viene campionata ogni 60 secondi.

Puoi utilizzare la seguente query per comprendere lo stato dei nodi in tutto il parco macchine:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

Stato del node pool

La seguente metrica di sistema GKE per la risorsa monitorata k8s_node_pool mostra lo stato di unpool di nodil GKE:

• kubernetes.io/node_pool/status

Questa metrica viene segnalata solo per i node pool TPU multi-host.

Il campo status indica lo stato del pool di nodi, ad esempio Provisioning, Running, Error, Reconciling o Stopping. Gli aggiornamenti dello stato vengono eseguiti al termine delle operazioni dell'API GKE.

Per verificare se un determinato pool di nodi ha lo stato Running, utilizza la seguente query PromQL:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Per monitorare il numero di pool di nodi nel tuo progetto raggruppati in base al loro stato, utilizza la seguente query PromQL:

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Disponibilità del node pool

La seguente metrica di sistema GKE mostra se un pool di nodi TPU multi-host è disponibile:

• kubernetes.io/node_pool/multi_host/available

La metrica ha un valore pari a True se tutti i nodi nel pool di nodi sono disponibili, e False in caso contrario. La metrica viene campionata ogni 60 secondi.

Per controllare la disponibilità dei node pool TPU multi-host nel tuo progetto, utilizza la seguente query PromQL:

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Conteggio interruzioni dei nodi

La seguente metrica di sistema GKE riporta il conteggio delle interruzioni per un nodo GKE dall'ultimo campione (la metrica viene campionata ogni 60 secondi):

• kubernetes.io/node/interruption_count

I campi interruption_type (ad esempio TerminationEvent, MaintenanceEvent o PreemptionEvent) e interruption_reason (ad esempio HostError, Eviction o AutoRepair) possono contribuire a fornire il motivo per cui un nodo è stato interrotto.

Per ottenere una suddivisione delle interruzioni e delle relative cause nei nodi TPU nei cluster del tuo progetto, utilizza la seguente query PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Per visualizzare solo gli eventi di manutenzione dell'host, aggiorna la query per filtrare il valore HW/SW Maintenance per interruption_reason. Utilizza la seguente query PromQL:

```promql
sum by (interruption_type,interruption_reason)(
  sum_over_time(
kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))
```

Per visualizzare il conteggio delle interruzioni aggregato per pool di nodi, utilizza la seguente query PromQL:

```promql
sum by (node_pool_name,interruption_type,interruption_reason)(
  sum_over_time(
    kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))
```

Tempi di ripristino (TTR) dei node pool

La seguente metrica di sistema GKE riporta la distribuzione delle durate del periodo di recupero per i node pool TPU multi-host GKE:

• kubernetes.io/node_pool/accelerator/times_to_recover

Ogni campione registrato in questa metrica indica un singolo evento di ripristino per il pool di nodi da un periodo di inattività.

Questa metrica è utile per monitorare il tempo di ripristino e il tempo tra le interruzioni del pool di nodi TPU multi-host.

Puoi utilizzare la seguente query PromQL per calcolare il tempo medio di ripristino (MTTR) degli ultimi 7 giorni nel tuo cluster:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Tempo tra le interruzioni (TBI) dei node pool

Il tempo tra le interruzioni del node pool misura il tempo di esecuzione dell'infrastruttura prima di subire un'interruzione. Viene calcolato come media in un periodo di tempo, in cui il numeratore misura il tempo totale di attività dell'infrastruttura e il denominatore misura le interruzioni totali dell'infrastruttura.

Il seguente esempio di PromQL mostra il tempo medio tra le interruzioni (MTBI) di 7 giorni per il cluster specificato:

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Metriche host

In GKE 1.28.1-gke.1066000 o versioni successive, le VM in una sezione di TPU esportano le metriche di utilizzo della TPU come metriche di sistema GKE. In Cloud Monitoring sono disponibili le seguenti metriche per monitorare le prestazioni dell'host TPU:

• Utilizzo di TensorCore: percentuale attuale di TensorCore utilizzata. Il valore di TensorCore è uguale alla somma delle unità di moltiplicazione a matrice (MXU) più l'unità vettoriale. Il valore di utilizzo di TensorCore è la divisione tra le operazioni TensorCore eseguite nell'ultimo periodo di campionamento (60 secondi) e il numero di operazioni TensorCore supportate nello stesso periodo. Un valore più alto indica un utilizzo migliore.
• Utilizzo della larghezza di banda della memoria: percentuale attuale della larghezza di banda della memoria dell'acceleratore in uso. Viene calcolata dividendo la larghezza di banda della memoria utilizzata in un periodo di campionamento (60 secondi) per la larghezza di banda massima supportata nello stesso periodo di campionamento.

Queste metriche si trovano nello schema del nodo Kubernetes (k8s_node) e del container Kubernetes (k8s_container).

Container Kubernetes:

• kubernetes.io/container/accelerator/tensorcore_utilization
• kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nodo Kubernetes:

• kubernetes.io/node/accelerator/tensorcore_utilization
• kubernetes.io/node/accelerator/memory_bandwidth_utilization

Per ulteriori informazioni, consulta Metriche Kubernetes e Metriche di sistema GKE.

Problemi noti

• Il gestore della scalabilità automatica del cluster potrebbe calcolare in modo errato la capacità dei nuovi nodi slice TPU prima che questi segnalino le TPU 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 del cluster esegue lo scale down dei nodi aggiuntivi, se non sono necessari, dopo l'operazione di fare lo scale down regolare.
• Il gestore della scalabilità automatica del cluster annulla lo scale up dei pool di nodi delle slice TPU che rimangono in stato di attesa per più di 10 ore. Il gestore della scalabilità automatica del cluster riprova queste operazioni di scale up in un secondo momento. Questo comportamento potrebbe ridurre la disponibilità di TPU per i clienti che non utilizzano le prenotazioni.
• I carichi di lavoro non TPU che hanno una tolleranza per la taint TPU possono impedire fare lo scale down delle dimensioni del pool di nodi se vengono ricreati durante lo svuotamento del pool di nodi della sezione TPU.
• La metrica di utilizzo della larghezza di banda della memoria non è disponibile per le TPU v5e.

Passaggi successivi

• Scopri di più sulla configurazione di Ray su GKE con le TPU
• Crea machine learning su larga scala su Cloud TPU con GKE
• Servire modelli linguistici di grandi dimensioni con KubeRay su TPU
• Risolvere i problemi relativi alle TPU in GKE
• Scopri di più sul sandboxing dei carichi di lavoro TPU con GKE Sandbox