Risolvi i problemi delle TPU in GKE


Questa pagina mostra come risolvere i problemi relativi alle TPU in Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

Quota insufficiente per soddisfare la richiesta di TPU

Un errore simile a Insufficient quota to satisfy the request indica che la quota disponibile per il progetto Google Cloud non è sufficiente per soddisfare la richiesta.

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

Controlla il limite quota e l'utilizzo attuale

Per controllare il limite e l'utilizzo attuale della tua quota dell'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. Seleziona la proprietà Servizio, inserisci API Compute Engine e premi Invio.

    2. Seleziona la proprietà Tipo e scegli Quota.

    3. 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 della sezione TPU nella zona us-west4-a. La quota TPU è a livello di regione, pertanto tutte le zone all'interno della stessa regione utilizzano la stessa quota TPU.

Se nessuna quota corrisponde al filtro inserito, al progetto non è stata concessa nessuna della quota specificata per la regione desiderata e devi richiedere un aumento della quota di TPU.

Errore durante l'abilitazione del provisioning automatico dei nodi in un pool di nodi della sezione 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 successiva.

GKE non esegue automaticamente il provisioning dei nodi sezione TPU

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

Limita configurazione errata

GKE non esegue automaticamente il provisioning dei nodi sezione TPU se i limiti di provisioning automatico che hai definito per un cluster sono troppo bassi. In questi scenari, potresti notare i seguenti errori:

  • Se esiste un pool di nodi della sezione TPU, ma GKE non può fare lo scale up dei nodi a causa della violazione dei limiti delle risorse, puoi visualizzare il seguente messaggio di errore durante l'esecuzione del 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, puoi visualizzare nella console Google Cloud messaggi di avviso simili al seguente:

    "Your cluster has one or more unschedulable Pods"
    
  • Quando GKE tenta di eseguire il provisioning automatico di un pool di nodi della sezione TPU che supera i limiti delle risorse, i log di visibilità del gestore della scalabilità automatica dei cluster mostreranno il seguente messaggio di errore:

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

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

    "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 della CPU e memoria nel cluster.

Per completare questi passaggi:

  1. Calcola i requisiti delle risorse per un determinato tipo di macchina TPU e effettua il conteggio. Tieni presente che devi aggiungere risorse per i pool di nodi delle sezioni non TPU, come i carichi di lavoro del sistema.
  2. Ottieni una descrizione delle 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 in cui eseguire la ricerca.
    • COMPUTE_ZONE: il nome della zona di computing.

    L'output include una riga descrittiva simile alla seguente:

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
      ```
    
  3. Calcola il numero totale di CPU e memoria moltiplicando queste quantità per il numero di nodi richiesto. Ad esempio, il tipo di macchina ct4p-hightpu-4t utilizza 240 core della CPU e 407 GB di RAM con 4 chip TPU. Supponendo di aver 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 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 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 può verificarsi quando l'operazione GKE è scaduta o la richiesta non può essere evasa e messa in coda per il provisioning di pool di nodi TPU a host singolo o multi-host. Per ridurre i problemi di capacità, puoi utilizzare le prenotazioni o prendere in considerazione le VM spot.

Configurazione errata del carico di lavoro

Questo errore si verifica a causa di un'errata configurazione del carico di lavoro. Di seguito sono riportate alcune delle cause più comuni di questo 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 pool di nodi della sezione TPU e il provisioning automatico dei nodi non sarà in grado di fare lo scale up del cluster.
  • La specifica del pod non specifica google.com/tpu nei requisiti delle risorse.

Per risolvere il problema, procedi in uno dei seguenti modi:

  1. Verifica che non siano presenti etichette non supportate nel selettore dei nodi dei carichi di lavoro. Ad esempio, un selettore di nodi per l'etichetta cloud.google.com/gke-nodepool impedirà a GKE di creare pool di nodi aggiuntivi per i tuoi pod.
  2. Assicurati che le specifiche del modello di pod, dove viene eseguito il carico di lavoro 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 richiesta.

Per informazioni su come eseguire il deployment di carichi di lavoro TPU in GKE, consulta Eseguire un carico di lavoro che visualizza il numero di chip TPU disponibili in un pool di nodi della sezione TPU.

Pianificazione degli errori durante il deployment di pod che utilizzano TPU in GKE

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

Il messaggio di errore, emesso come evento FailedScheduling nel 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:

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

Risoluzione dei problemi comuni relativi ai JobSet in GKE

Per conoscere i problemi comuni relativi a JobSet e i suggerimenti per la risoluzione dei problemi, consulta la pagina relativa alla risoluzione dei problemi di JobSet. Questa pagina illustra problemi comuni come l'errore "Webhook non disponibile", job figlio o pod che non vengono creati e il ripristino dei carichi di lavoro prerilasciati utilizzando JobSet e Kueue.

Inizializzazione della TPU non riuscita

Il seguente problema si verifica quando GKE non può eseguire il provisioning di nuovi carichi di lavoro TPU a causa della mancanza di autorizzazioni 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 ulimit all'interno del container.

Programmazione deadlock

La pianificazione di due o più job potrebbe non riuscire in un deadlock. Ad esempio, nello scenario in cui si verificano tutte le seguenti condizioni:

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

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 sezione TPU ciascuno. Di conseguenza, GKE non sarà in grado di pianificare completamente il job A o il job B. Di conseguenza, lo stato di entrambi i job rimarrà In attesa.

Per risolvere il problema, utilizza l'anti-affinità dei pod 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 stai tentando di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti ricevere 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 è perché la regione us-central2 è una regione privata.

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

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

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

  • Quota di SSD (GB) su Persistent Disk in us-central2: il disco di avvio di ciascun nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata almeno su un valore pari almeno al prodotto del numero massimo di nodi GKE che prevedi di creare in us-central2 e di 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 pari al numero massimo di nodi GKE che prevedi di creare in us-central2.

Subnet mancante durante la creazione del cluster GKE

Se stai tentando di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti ricevere 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>.

È necessaria una subnet nella rete VPC per fornire connettività ai nodi GKE. Tuttavia, in alcune regioni, come us-central2, è possibile che non venga 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.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.