Risolvi i problemi relativi alle TPU in GKE

Quando esegui carichi di lavoro di addestramento o inferenza su larga scala su Google Kubernetes Engine (GKE), potresti riscontrare problemi di provisioning o utilizzo delle Tensor Processing Unit (TPU). I tuoi pod potrebbero bloccarsi nello stato Pending perché GKE non riesce a eseguire il provisioning di nuovi nodi di slice TPU oppure il tuo carico di lavoro potrebbe non riuscire a causa di quota insufficiente, configurazioni di topologia errate o configurazioni errate del carico di lavoro.

Utilizza questo documento per scoprire come verificare la presenza di problemi relativi alla quota, controllare che le richieste di nodeSelector e risorse del tuo workload siano corrette e trovare i log per identificare la causa principale degli errori di pianificazione o inizializzazione.

Queste informazioni sono destinate agli amministratori e agli operatori della piattaforma che eseguono il provisioning e la gestione dei node pool con topologie di slice TPU specifiche e agli sviluppatori di applicazioni che risolvono i problemi relativi all'addestramento TPU su larga scala o ai workload di inferenza. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Quota insufficiente per soddisfare la richiesta di TPU

Un errore simile a Insufficient quota to satisfy the request indica che il tuo progettoGoogle Cloud non dispone di quota sufficiente per soddisfare la richiesta.

Per risolvere il problema, controlla il limite di quota e l'utilizzo attuale del progetto. Se necessario, richiedi un aumento della quota TPU.

Controllare il limite della quota e l'utilizzo attuale

Le sezioni seguenti ti aiutano a verificare di avere una quota sufficiente quando utilizzi le TPU in GKE.

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 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.1 Puoi saltare questa sezione in tutta sicurezza 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 Google Cloud :

    Vai a Quote

  2. Nella casella 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
      Ironwood (TPU7x) (anteprima),
      tpu7x-standard-4t 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

    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, al progetto non è stata concessa nessuna delle quote specificate per la regione di cui hai bisogno e devi richiedere un aggiustamento 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.

  1. Quando crei un pool di nodi slice TPU, utilizza i flag --reservation e --reservation-affinity=specific per creare unistanza dedicata. Le prenotazioni TPU sono disponibili al momento dell'acquisto di un impegno. ↩

  2. Quando crei un pool di nodi slice TPU, utilizza il flag --spot per creare un'istanza spot. ↩

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 sul numero massimo di nodi GKE che prevedi di creare.

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

Come GKE gestisce i problemi di capacità

Se GKE non riesce a creare il pool di nodi di slice TPU a causa di una capacità TPU insufficiente, la richiesta potrebbe non andare a buon fine con un errore di esaurimento scorte oppure GKE potrebbe mettere in coda la richiesta di provisioning finché non sarà disponibile la capacità.

Se le risorse TPU non sono temporaneamente disponibili, potresti ricevere un errore contenente i campi GCE_STOCKOUT o ZONE_RESOURCE_POOL_EXHAUSTED. Per maggiori informazioni, vedi Risorse TPU insufficienti per soddisfare la richiesta TPU.

In altri casi, GKE mette in coda la richiesta e viene visualizzato un messaggio di errore che indica che non è possibile creare nodi slice TPU a causa della mancanza di capacità. GKE crea i nodi quando la capacità diventa disponibile.

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

1 node 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 di sezioni TPU multihost, 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 tua richiesta di provisioning TPU può rimanere in coda a lungo e rimane nello stato Provisioning mentre è in coda.

Quando la capacità è disponibile, GKE crea i nodi 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.

Risorse TPU insufficienti per soddisfare la richiesta di TPU

Un errore che contiene GCE_STOCKOUT indica che le risorse TPU non sono temporaneamente disponibili per soddisfare la richiesta. GKE soddisfa la richiesta di provisioning quando le risorse TPU diventano disponibili.

Per risolvere il problema, puoi utilizzare una delle seguenti opzioni di consumo:

Per scegliere l'opzione di consumo che soddisfa i requisiti del tuo workload, consulta Informazioni sulle opzioni di consumo degli acceleratori per i workload AI/ML in GKE.

Errore durante l'attivazione del provisioning automatico dei nodi in un pool di nodi di slice TPU

Il seguente errore si verifica quando abiliti il provisioning automatico dei nodi in un cluster GKE che non supporta le TPU.

Il messaggio di errore è simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
  message=Invalid resource: tpu-v4-podslice.

Per risolvere il problema, esegui l'upgrade del cluster GKE alla versione 1.27.6 o successive.

GKE non esegue automaticamente il provisioning dei nodi delle sezioni TPU

Le sezioni seguenti descrivono i casi in cui GKE non esegue automaticamente il provisioning dei nodi slice TPU e come risolverli.

Configurazione errata del limite

Se i limiti di provisioning automatico del cluster non sono presenti o sono troppo bassi, GKE non esegue automaticamente il provisioning dei nodi slice TPU. In questi scenari potresti osservare i seguenti errori:

  • Quando GKE tenta di eseguire il provisioning automatico di un pool di nodi di slice TPU che non ha limiti definiti, i log di visibilità del gestore della scalabilità automatica dei cluster mostrano il seguente messaggio di errore:

    messageId: "no.scale.up.nap.pod.tpu.no.limit.defined"

  • Se esiste un pool di nodi di sezioni TPU, ma GKE non riesce a scalare i nodi a causa della violazione dei limiti delle risorse, puoi visualizzare il seguente messaggio di errore quando esegui il comando kubectl get events:

    11s Normal NotTriggerScaleUp pod/tpu-workload-65b69f6c95-ccxwz pod didn't
trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 max
cluster cpu, memory limit reached

    Inoltre, in questo scenario, nella console Google Cloud puoi visualizzare messaggi di avviso simili ai seguenti:

    "Your cluster has one or more unschedulable Pods"

  • Quando GKE tenta di eseguire il provisioning automatico di un pool di nodi di sezioni TPU che supera i limiti delle risorse, i log di visibilità del gestore della scalabilità automatica dei cluster mostrano il seguente messaggio di errore:

    messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"

    Inoltre, in questo scenario, nella console Google Cloud puoi visualizzare messaggi di avviso simili ai seguenti:

    "Can't scale up because node auto-provisioning can't provision a node pool for
the Pod if it would exceed resource limits"

Per risolvere questi problemi, aumenta il numero massimo di chip TPU, core CPU e memoria nel cluster.

Per completare questi passaggi:

  1. Calcola i requisiti delle risorse per un determinato tipo e conteggio di macchine TPU. Tieni presente che devi aggiungere risorse per i pool di nodi slice non TPU, come i carichi di lavoro di sistema.

  2. Ottieni una descrizione della TPU, della CPU e della memoria disponibili per un tipo di macchina e una zona specifici. Utilizza gcloud CLI:

    gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE

    Sostituisci quanto segue:

    • MACHINE_TYPE: Il tipo di macchina da cercare.
    • COMPUTE_ZONE: il nome della zona di computing.

    L'output include una riga di descrizione simile alla seguente:

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```

  3. Calcola il numero totale di CPU e memoria moltiplicando questi valori per il numero di nodi richiesto. Ad esempio, il tipo di macchina ct4p-hightpu-4t utilizza 240 core CPU e 407 GB di RAM con 4 chip TPU. Supponendo che tu abbia bisogno di 20 chip TPU, che corrispondono a cinque nodi, devi definire i seguenti valori:

    • --max-accelerator=type=tpu-v4-podslice,count=20.
    • CPU = 1200 (240 volte 5)
    • memory = 2035 (407 volte 5)

    Devi definire i limiti con un certo margine per ospitare nodi di slice non TPU come i carichi di lavoro di sistema.

  4. Aggiorna i limiti del cluster:

    gcloud container clusters update CLUSTER_NAME \
    --max-accelerator type=TPU_ACCELERATOR \
    count=MAXIMUM_ACCELERATOR \
    --max-cpu=MAXIMUM_CPU \
    --max-memory=MAXIMUM_MEMORY

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • TPU_ACCELERATOR: il nome dell'acceleratore TPU.
    • MAXIMUM_ACCELERATOR: il numero massimo di chip TPU nel cluster.
    • MAXIMUM_CPU: il numero massimo di core nel cluster.
    • MAXIMUM_MEMORY: il numero massimo di gigabyte di memoria nel cluster.

Non tutte le istanze sono in esecuzione

ERROR: 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.

Questo errore potrebbe essere visualizzato quando l'operazione GKE è scaduta o la richiesta non può essere soddisfatta e messa in coda per il provisioning di node pool TPU single-host o multi-host. Per mitigare i problemi di capacità, puoi utilizzare le prenotazioni o prendere in considerazione le VM spot.

Configurazione errata del workload

Questo errore si verifica a causa di una configurazione errata del workload. Di seguito sono riportate alcune delle cause più comuni dell'errore:

  • Le etichette cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology non sono corrette o mancano nella specifica del pod. GKE non eseguirà il provisioning dei node pool delle sezioni TPU e il provisioning automatico dei nodi non sarà in grado di scalare il cluster.
  • Le specifiche del pod non specificano google.com/tpu nei requisiti delle risorse.

Per risolvere il problema, esegui una delle seguenti operazioni:

  1. Verifica che non siano presenti etichette non supportate nel selettore dei nodi del carico di lavoro. Ad esempio, un selettore di nodi per l'etichetta cloud.google.com/gke-nodepool impedirà a GKE di creare node pool aggiuntivi per i tuoi pod.
  2. Assicurati che le specifiche del modello di pod, in cui viene eseguito il workload TPU, includano i seguenti valori:
    • cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology nel relativo nodeSelector.
    • google.com/tpu nella sua richiesta.

Per scoprire come eseguire il deployment dei carichi di lavoro TPU in GKE, consulta Esegui un carico di lavoro che mostra il numero di chip TPU disponibili in un node pool di sezioni TPU.

Errori di pianificazione durante il deployment di pod che utilizzano TPU in GKE

Il seguente problema si verifica quando GKE non riesce a pianificare i pod che richiedono TPU sui nodi delle sezioni TPU. Ad esempio, ciò potrebbe verificarsi se alcune sezioni non TPU sono già state pianificate sui nodi TPU.

Il messaggio di errore, emesso come evento FailedScheduling sul pod, è simile al seguente:

Cannot schedule pods: Preemption is not helpful for scheduling.

Error message: 0/2 nodes are available: 2 node(s) had untolerated taint
{google.com/tpu: present}. preemption: 0/2 nodes are available: 2 Preemption is
not helpful for scheduling

Per risolvere il problema, segui questi passaggi:

Verifica di avere almeno un pool di nodi di CPU nel cluster in modo che i pod critici per il sistema possano essere eseguiti nei nodi non TPU. Per saperne di più, vedi Esegui il deployment di un pod in un node pool specifico.

Risoluzione dei problemi comuni relativi a JobSet in GKE

Per problemi comuni relativi a JobSet e suggerimenti per la risoluzione dei problemi, consulta la pagina Risoluzione dei problemi di JobSet. Questa pagina tratta problemi comuni come l'errore "Webhook non disponibile", il job secondario o i pod non creati e il problema di ripristino dei carichi di lavoro preempted utilizzando JobSet e Kueue.

Inizializzazione della TPU non riuscita

Il seguente problema si verifica quando GKE non riesce a eseguire il provisioning di nuovi workload TPU a causa della mancanza di autorizzazione per accedere ai dispositivi TPU.

Il messaggio di errore è simile al seguente:

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

Per risolvere il problema, assicurati di eseguire il container TPU in modalità con privilegi o di aumentare il valore di ulimit all'interno del container.

Stallo della pianificazione

La pianificazione di due o più job potrebbe non riuscire a causa di un deadlock. Ad esempio, nello scenario in cui si verificano tutti i seguenti eventi:

  • Hai due job (job A e job B) con regole di affinità dei pod. GKE pianifica le sezioni TPU per i job con una topologia TPU di v4-32.
  • Nel cluster sono presenti due sezioni TPU v4-32.
  • Il cluster ha una capacità sufficiente per pianificare sia i job sia, in teoria, ogni job può essere pianificato rapidamente su ogni slice TPU.
  • Lo scheduler Kubernetes pianifica un pod dal job A su una slice, quindi pianifica un pod dal job B sulla stessa slice.

In questo caso, date le regole di affinità pod per il job A, lo scheduler tenta di pianificare tutti i pod rimanenti per il job A e per il job B su una singola slice TPU ciascuno. Di conseguenza, GKE non sarà in grado di pianificare completamente il job A o il job B. Pertanto, lo stato di entrambi i job rimarrà In attesa.

Per risolvere il problema, utilizza Pod anti-affinity con cloud.google.com/gke-nodepool come topologyKey, come mostrato nell'esempio seguente:

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

Autorizzazione negata durante la creazione del cluster in us-central2

Se tenti di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti visualizzare un messaggio di errore simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).

Questo errore si verifica perché la regione us-central2 è una regione privata.

Per risolvere il problema, invia una richiesta di assistenza o contatta il tuo team dell'account per richiedere che us-central2 sia reso visibile all'interno del tuo progettoGoogle Cloud .

Quota insufficiente durante la creazione del pool di nodi TPU in us-central2

Se stai tentando di creare un pool di nodi di sezioni TPU in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti dover aumentare le seguenti quote correlate a GKE quando crei per la prima volta i node pool TPU v4:

  • Quota SSD Persistent Disk (GB) in us-central2: il disco di avvio di ogni nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata almeno pari al prodotto del numero massimo di nodi GKE che prevedi di creare in us-central2 e 100 GB (maximum_nodes x 100 GB).
  • Quota di indirizzi IP in uso in us-central2: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno sul valore del numero massimo di nodi GKE che prevedi di creare in us-central2.

Subnet mancante durante la creazione del cluster GKE

Se tenti di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti visualizzare un messaggio di errore simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=404,
message=Not found: project <PROJECT> does not have an auto-mode subnetwork
for network "default" in region <REGION>.

Nella tua rete VPC è necessaria una subnet per fornire connettività ai tuoi nodi GKE. Tuttavia, in alcune regioni come us-central2, potrebbe non essere creata una subnet predefinita, anche quando utilizzi la rete VPC predefinita in modalità automatica (per la creazione di subnet).

Per risolvere il problema, assicurati di aver creato una subnet personalizzata nella regione prima di creare il cluster GKE. Questa subnet non deve sovrapporsi ad altre subnet create in altre regioni nella stessa rete VPC.

Abilita la porta kubelet di sola lettura

Se utilizzi una versione del cluster GKE precedente alla 1.32, assicurati che il campo insecureKubeletReadonlyPortEnabled sia impostato su true.

Puoi controllare il valore del campo insecureKubeletReadonlyPortEnabled descrivendo il tuo pool di nodi:

gcloud container node-pools describe NODEPOOL_NAME --cluster=CLUSTER_NAME

Se l'output include insecureKubeletReadonlyPortEnabled: false, abilita la porta eseguendo il seguente comando:

gcloud container node-pools update NODEPOOL_NAME --cluster CLUSTER_NAME --enable-insecure-kubelet-readonly-port

I seguenti errori di esempio menzionano un errore di connessione TCP alla porta 10255, il che indica che potresti dover abilitare la porta.

error sending request: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

failed to get TPU container Info: failed to call kubelet: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

Errore di connessione durante l'esecuzione di un workload di addestramento con JAX

Se stai tentando di inizializzare il framework JAX per eseguire un carico di lavoro di addestramento sulle macchine TPU, potresti visualizzare un messaggio di errore simile al seguente:

E0115 19:06:10.727412 340 master.cc:246] Initialization of slice failed with
error status: INVALID_ARGUMENT: When linking node TPU_ID:pe0:0
to TPU_ID:pe0:3</code> with link TPU_ID:pe0:0:p5:x couldn't find opposite link in destination node.; Failed to create the mesh (xW, xW, xW); Please make sure the topology is correct.;
Failed to discover ICI network topology

Questo errore si verifica quando GKE non riesce a stabilire la topologia di rete di interconnessione interchip (ICI) ad alta velocità in sezioni TPU di grandi dimensioni.

Per risolvere il problema, completa i seguenti passaggi:

  1. Identifica gli slice TPU che riscontrano l'errore di connettività. Per visualizzare i log eventi, utilizza la seguente query:

    resource.type="k8s_container"
resource.labels.project_id=PROJECT_ID
severity>=DEFAULT
SEARCH("`[/dev/vfio/0` `TPU_ID` Driver `opened.`")

    Sostituisci quanto segue:

    • PROJECT_ID: il tuo ID progetto.
    • TPU_ID: l'ID della TPU che presenta errori. Puoi visualizzare l'ID TPU nel messaggio di errore.

  2. Contamina il pool di nodi o uno dei nodi inclusi nel messaggio di errore. Per scoprire di più, consulta Applicare taint ed etichette a un pool di nodi per i tuoi workload.

  3. Esegui di nuovo il job su un altro pool di nodi.

Se il problema persiste, apri una richiesta di assistenza o contatta il tuo team dell'account.

Visualizzare i log TPU di GKE

Per visualizzare tutti i log correlati alla TPU per un carico di lavoro specifico, Cloud Logging offre una posizione centralizzata per eseguire query su questi log quando il logging del sistema e dei carichi di lavoro GKE è abilitato. In Cloud Logging, i log sono organizzati in voci di log e ogni singola voce di log ha un formato strutturato. Di seguito è riportato un esempio di voce di log di un job di addestramento TPU.

{
  insertId: "gvqk7r5qc5hvogif"
  labels: {
  compute.googleapis.com/resource_name: "gke-tpu-9243ec28-wwf5"
  k8s-pod/batch_kubernetes_io/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/batch_kubernetes_io/job-name: "mnist-training-job"
  k8s-pod/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/job-name: "mnist-training-job"
}
logName: "projects/gke-tpu-demo-project/logs/stdout"
receiveTimestamp: "2024-06-26T05:52:39.652122589Z"
resource: {
  labels: {
    cluster_name: "tpu-test"
    container_name: "tensorflow"
    location: "us-central2-b"
    namespace_name: "default"
    pod_name: "mnist-training-job-l74l8"
    project_id: "gke-tpu-demo-project"
}
  type: "k8s_container"
}
severity: "INFO"
textPayload: "
  1/938 [..............................] - ETA: 13:36 - loss: 2.3238 - accuracy: 0.0469
  6/938 [..............................] - ETA: 9s - loss: 2.1227 - accuracy: 0.2995
 13/938 [..............................] - ETA: 8s - loss: 1.7952 - accuracy: 0.4760
 20/938 [..............................] - ETA: 7s - loss: 1.5536 - accuracy: 0.5539
 27/938 [..............................] - ETA: 7s - loss: 1.3590 - accuracy: 0.6071
 36/938 [>.............................] - ETA: 6s - loss: 1.1622 - accuracy: 0.6606
 44/938 [>.............................] - ETA: 6s - loss: 1.0395 - accuracy: 0.6935
 51/938 [>.............................] - ETA: 6s - loss: 0.9590 - accuracy: 0.7160
……
937/938 [============================>.] - ETA: 0s - loss: 0.2184 - accuracy: 0.9349"
timestamp: "2024-06-26T05:52:38.962950115Z"
}

Ogni voce di log dei nodi della slice TPU ha l'etichetta compute.googleapis.com/resource_name con il valore impostato come nome del nodo. Se vuoi visualizzare i log di un nodo specifico e conosci il nome del nodo, puoi filtrare i log in base a quel nodo nella query. Ad esempio, la seguente query mostra i log del nodo TPU gke-tpu-9243ec28-wwf5:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" = "gke-tpu-9243ec28-wwf5"

GKE associa le etichette cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology a tutti i nodi contenenti TPU. Pertanto, se non hai la certezza del nome del nodo o vuoi elencare tutti i nodi dello slice TPU, puoi eseguire il seguente comando:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator

Esempio di output:

NAME                    STATUS   ROLES    AGE     VERSION
gke-tpu-9243ec28-f2f1   Ready    <none>   25m     v1.30.1-gke.1156000
gke-tpu-9243ec28-wwf5   Ready    <none>   7d22h   v1.30.1-gke.1156000

Puoi applicare filtri aggiuntivi in base alle etichette dei nodi e ai relativi valori. Ad esempio, il seguente comando elenca il nodo TPU con un tipo e una topologia specifici:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator=tpu-v5-lite-podslice,cloud.google.com/gke-tpu-topology=1x1

Per visualizzare tutti i log nei nodi della sezione TPU, puoi utilizzare la query che corrisponde all'etichetta del suffisso del nodo della sezione TPU. Ad esempio, utilizza la seguente query:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*"
log_id("stdout")

Per visualizzare i log associati a un particolare carico di lavoro TPU utilizzando un job Kubernetes, puoi filtrare i log utilizzando l'etichetta batch.kubernetes.io/job-name. Ad esempio, per il job mnist-training-job, puoi eseguire la seguente query per i log STDOUT:

resource.type="k8s_container"
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job"
log_id("stdout")

Per visualizzare i log di un workload TPU utilizzando un JobSet Kubernetes, puoi filtrare i log utilizzando l'etichetta k8s-pod/jobset_sigs_k8s_io/jobset-name. Ad esempio:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"

Per esaminare in dettaglio, puoi filtrare in base alle altre etichette dei carichi di lavoro. Ad esempio, per visualizzare i log di un workload multislice dal worker 0 e dallo slice 1, puoi filtrare in base alle etichette: job-complete-index e job-index:

​​resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
labels."k8s-pod/batch_kubernetes_io/job-completion-index"="0"
labels."k8s-pod/jobset_sigs_k8s_io/job-index"="1"

Puoi anche filtrare utilizzando il pattern del nome del pod:

resource.labels.pod_name:<jobSetName>-<replicateJobName>-<job-index>-<worker-index>

Ad esempio, nella seguente query jobSetName è multislice-job e replicateJobName è slice. Sia job-index che worker-index sono 0:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
resource.labels.pod_name:"multislice-job-slice-0-0"

Per altri carichi di lavoro TPU, ad esempio un singolo carico di lavoro del pod GKE, puoi filtrare i log in base ai nomi dei pod. Ad esempio:

resource.type="k8s_container"
resource.labels.pod_name="tpu-job-jax-demo"

Se vuoi verificare se il plug-in del dispositivo TPU è in esecuzione correttamente, puoi utilizzare la seguente query per controllare i log dei container:

resource.type="k8s_container"
labels.k8s-pod/k8s-app="tpu-device-plugin"
resource.labels.namespace_name="kube-system"

Esegui la seguente query per controllare gli eventi correlati:

jsonPayload.involvedObject.name=~"tpu-device-plugin.*"
log_id("events")

Per tutte le query, puoi aggiungere filtri aggiuntivi, come nome cluster, posizione e ID progetto. Puoi anche combinare le condizioni per restringere i risultati. Ad esempio:

resource.type="k8s_container" AND
resource.labels.project_id="gke-tpu-demo-project" AND
resource.labels.location="us-west1" AND
resource.labels.cluster_name="tpu-demo" AND
resource.labels.namespace_name="default" AND
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" AND
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job" AND
log_id("stdout")

L'operatore AND è facoltativo tra i confronti e può essere omesso. Per ulteriori informazioni sul linguaggio di query, puoi leggere la specifica del linguaggio di query di Logging. Puoi anche leggere Query di log correlate a Kubernetes per altri esempi di query.

Se preferisci SQL utilizzando Analisi dei log, puoi trovare esempi di query in Query SQL con Analisi dei log. In alternativa, puoi eseguire le query utilizzando Google Cloud CLI anziché in Esplora log. Ad esempio:

gcloud logging read 'resource.type="k8s_container" labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" log_id("stdout")' --limit 10 --format json

Passaggi successivi