Risolvere i problemi relativi alle GPU in GKE

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

Installazione dei driver GPU

Questa sezione fornisce informazioni per la risoluzione dei problemi relativi all'installazione automatica dei driver dei dispositivi NVIDIA in GKE.

L'installazione del driver non riesce nei nodi Ubuntu

Se utilizzi nodi Ubuntu a cui sono collegate GPU L4, H100 o H200, il driver GPU predefinito installato da GKE potrebbe non essere alla versione richiesta per queste GPU o a una versione successiva. Di conseguenza, il pod del plug-in del dispositivo GPU rimane bloccato nello stato In attesa e i tuoi carichi di lavoro GPU su questi nodi potrebbero riscontrare problemi.

Per risolvere questo problema per le GPU L4 e H100, ti consigliamo di eseguire l'upgrade alle seguenti versioni di GKE che installano la versione 535 del driver GPU come driver predefinito:

  • 1.26.15-gke.1483000 e versioni successive
  • 1.27.15-gke.1039000 e versioni successive
  • 1.28.11-gke.1044000 e versioni successive
  • 1.29.6-gke.1073000 e versioni successive
  • 1.30.2-gke.1124000 e versioni successive

In alternativa, puoi installare manualmente la versione 535 o successive del driver eseguendo il seguente comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

Per risolvere il problema per le GPU H200, devi installare manualmente la versione del driver 550 o successive eseguendo il seguente comando:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

I plug-in del dispositivo GPU non riescono a causa di errori CrashLoopBackOff

Il seguente problema si verifica se hai utilizzato il metodo di installazione manuale dei driver nel tuo pool di nodi prima del 25 gennaio 2023 e in seguito hai eseguito l'upgrade del node pool a una versione GKE che supporta l'installazione automatica dei driver. Entrambi i workload di installazione esistono contemporaneamente e tentano di installare versioni di driver in conflitto sui nodi.

Il container di inizializzazione del plug-in del dispositivo GPU non funziona con lo stato Init:CrashLoopBackOff. I log per il container sono simili ai seguenti:

failed to verify installation: failed to verify GPU driver installation: exit status 18

Per risolvere il problema, prova i seguenti metodi:

  • Rimuovi il DaemonSet di installazione manuale dei driver dal cluster. In questo modo viene eliminato il workload di installazione in conflitto e GKE installa automaticamente un driver sui tuoi nodi.

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Applica nuovamente il manifest DaemonSet di installazione manuale dei driver al cluster. Il 25 gennaio 2023 abbiamo aggiornato il manifest in modo che ignori i nodi che utilizzano l'installazione automatica dei driver.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • Disabilita l'installazione automatica dei driver per il pool di nodi. Il DaemonSet di installazione dei driver esistente dovrebbe funzionare come previsto al termine dell'operazione di aggiornamento.

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

    Sostituisci quanto segue:

    • POOL_NAME: il nome del pool di nodi.
    • GPU_TYPE: il tipo di GPU già utilizzato dal pool di nodi.
    • GPU_COUNT: il numero di GPU già collegate al pool di nodi.
    • CLUSTER_NAME: il nome del cluster GKE che contiene il pool di nodi.
    • LOCATION: la posizione di Compute Engine del cluster.

Errore: "L'immagine container cos-nvidia-installer:fixed non è presente con il criterio pull Mai" o "L'immagine container ubuntu-nvidia-installer:fixed non è presente con il criterio pull Mai".

Questo problema si verifica quando i pod nvidia-driver-installer si trovano nello stato PodInitializing e i pod del dispositivo plug-in GPU o del programma di installazione del driver GPU segnalano il seguente errore. Il messaggio di errore specifico dipende dal sistema operativo in esecuzione sul nodo:

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

Questo problema può verificarsi quando il garbage collector rimuove l'immagine del driver NVIDIA precaricato per liberare spazio su un nodo. Quando il pod del driver viene ricreato o il relativo contenitore viene riavviato, GKE non sarà in grado di individuare l'immagine precaricata.

Per risolvere il problema di Garbage Collection quando esegui COS, esegui l'upgrade dei nodi GKE a una di queste versioni che contengono la correzione:

  • 1.25.15-gke.1040000 e versioni successive
  • 1.26.10-gke.1030000 e versioni successive
  • 1.27.6-gke.1513000 e versioni successive
  • 1.28.3-gke.1061000 e versioni successive

Se i tuoi nodi eseguono Ubuntu, non è ancora disponibile una correzione per questo problema di garbage collection. Per risolvere questo problema su Ubuntu, puoi eseguire un container con privilegi che interagisce con l'host per garantire la corretta configurazione dei driver della GPU NVIDIA. Per farlo, esegui sudo /usr/local/bin/nvidia-container-first-boot dal tuo nodo o applica il seguente manifest:

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

Un'altra potenziale causa del problema è la perdita delle immagini dei driver NVIDIA dopo il riavvio del nodo o la manutenzione dell'host. Ciò può verificarsi su nodi riservati o nodi con GPU che utilizzano lo spazio di archiviazione SSD locale temporaneo. In questa situazione, GKE precarica le immagini container nvidia-installer-driver sui nodi e le sposta dal disco di avvio all'SSD locale al primo avvio.

Per verificare che si sia verificato un evento di manutenzione dell'host, utilizza il seguente filtro log:

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

Per risolvere il problema di manutenzione dell'host, esegui l'upgrade della versione di GKE a una di queste versioni:

  • 1.27.13-gke.1166000 e versioni successive
  • 1.29.3-gke.1227000 e versioni successive
  • 1.28.8-gke.1171000 e versioni successive

Errore: impossibile configurare le directory di installazione del driver GPU: impossibile creare l'overlay lib64: impossibile creare la directory /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

Si verifica questo errore dal container di installazione del driver GPU all'interno del plug-in del dispositivo GPU quando è abilitato NCCL fastsocket:

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

Questo problema si verifica solo su cluster e nodi che eseguono GKE 1.28 e 1.29.

Il problema è causato da una race condition fastsocket NCCL con il programma di installazione del driver GPU.

Per risolvere questo problema, esegui l'upgrade della versione di GKE a una di queste versioni:

  • 1.28.8-gke.1206000 e versioni successive
  • 1.29.3-gke.1344000 e versioni successive

Per saperne di più, leggi le note di rilascio di GPUDirect-TCPXO.

Errore: impossibile ottenere il dispositivo per nvidia0: dispositivo nvidia0 non trovato.

Il seguente errore indica che XID 62 e RmInitAdapter non sono riusciti per la GPU con valore secondario 0:

Failed to get device for nvidia0: device nvidia0 not found.

La versione 525.105.17 del driver NVIDIA presenta un bug che può causare errori di comunicazione (XID) e impedire la corretta inizializzazione della GPU, con conseguente errore di inizializzazione della GPU.

Per risolvere il problema, esegui l'upgrade del driver NVIDIA alla versione 525.110.11 o successiva.

Reimposta le GPU sulle VM A3

Alcuni problemi potrebbero richiedere il ripristino della GPU su una VM A3.

Per ripristinare la GPU, segui questi passaggi:

  1. Rimuovi i pod che richiedono risorse GPU dal nodo in cui devi reimpostare la GPU.

  2. Disattiva il plug-in del dispositivo GPU sul nodo:

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    Sostituisci NODE_NAME con il nome del nodo.

  3. Connettiti alla VM che supporta il nodo.

  4. Nella sessione SSH, reimposta la GPU:

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

  5. Riattiva il plug-in del dispositivo GPU:

    kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers \| awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
    --overwrite

GPU su Confidential GKE Nodes

Le sezioni seguenti mostrano come identificare e risolvere i problemi relativi alle GPU che vengono eseguite sui nodi GKE confidenziali.

I carichi di lavoro GPU non vengono pianificati su Confidential GKE Nodes

I nodi GKE confidenziali richiedono l'installazione manuale di un driver GPU corrispondente al tipo di GPU selezionato e alla versione GKE. Se i tuoi pod GPU non vengono pianificati sui nodi GKE confidenziali e rimangono nello stato Pending, descrivi il DaemonSet di installazione dei driver:

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

Se l'output restituisce un errore NotFound, installa il driver.

Se DaemonSet è in esecuzione, l'output è simile al seguente:

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

In questo output, verifica che il campo nodeAffinity contenga la chiave cloud.google.com/gke-confidential-nodes-instance-type. Se l'output non contiene questa chiave, il DaemonSet di installazione del driver non supporta i nodi GKE confidenziali.

Esegui il deployment del DaemonSet che supporta le GPU sui nodi Confidential GKE Node:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

Dopo aver installato i driver, controlla se i tuoi carichi di lavoro GPU vengono avviati correttamente.

Errore: impossibile allocare il vettore del dispositivo

Il seguente messaggio di errore nei log del container GPU indica che la GPU è stata scollegata dall'istanza VM del nodo:

Failed to allocate device vector A (error code unknown error)!

Questo distacco potrebbe verificarsi a causa di un errore hardware o di un problema con le chiavi di crittografia.

Per risolvere il problema, riavvia l'istanza del nodo. Questa operazione è distruttiva e influisce su tutti i carichi di lavoro sul nodo. Per riavviare l'istanza, segui questi passaggi:

  1. Recupera il nome del nodo che esegue il pod GPU:

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    Sostituisci POD_NAME con il nome del pod non riuscito.

    L'output è simile al seguente:

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. Reimposta l'istanza Compute Engine:

    gcloud compute instances reset NODE_NAME

    Sostituisci NODE_NAME con il nome del nodo dall'output del passaggio precedente.

    gcloud CLI cerca le VM con quel nome nel tuo progetto attivo. Se vedi un prompt per selezionare una zona, specifica Y.

  3. Controlla se i carichi di lavoro della GPU vengono eseguiti senza errori.

Errore: decrittografia non riuscita con errore -74

Il seguente messaggio di errore nei log dei nodi indica che le chiavi di crittografia per la GPU sono state perse:

Decryption failed with error -74

Questo errore si verifica quando il daemon di persistenza NVIDIA, in esecuzione sull'istanza VM del nodo, non funziona. Se visualizzi questo messaggio di errore, reimposta l'istanza:

gcloud compute instances reset NODE_NAME

Sostituisci NODE_NAME con il nome del nodo non funzionante.

gcloud CLI cerca le VM con quel nome nel tuo progetto attivo. Se vedi un prompt per selezionare una zona, specifica Y.

Se il ripristino dell'istanza non risolve il problema, contatta l'assistenza clienti Google Cloud o segnala un bug del prodotto. Per ulteriori informazioni, consulta la pagina Richiedere assistenza.

Ricerca degli errori XID

Il daemonset gpu-device-plugin viene eseguito all'interno dello spazio dei nomi kube-system ed è responsabile di quanto segue:

  • Pianificazione dei carichi di lavoro GPU:allocazione delle risorse GPU ai pod.
  • Controllo dell'integrità della GPU:monitoraggio dell'integrità delle GPU.
  • Raccolta delle metriche GPU: raccolta di metriche correlate alla GPU, come il ciclo di lavoro e l'utilizzo della memoria.

gpu-device-plugin utilizza NVIDIA Management Library (NVML) per rilevare gli errori XID. Quando si verifica un errore XID, il pod gpu-device-plugin in esecuzione sul nodo interessato registra l'errore. Troverai due tipi di log degli errori XID:

  • Errori XID non critici:
    • Formato log: Skip error Xid=%d as it is not Xid Critical
    • Significato: questi errori sono considerati non critici. Possono essere causati da vari problemi software o hardware.
    • Azione: GKE non esegue alcuna azione automatica per gli errori XID non critici.
  • Errori XID critici:
    • Formato log: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Significato: questi errori indicano un problema hardware della GPU.
    • Azione:
      • GKE contrassegna le risorse GPU del nodo come non integre.
      • GKE impedisce la pianificazione dei carichi di lavoro GPU sul nodo.
      • Se la riparazione automatica dei nodi è abilitata, GKE ricrea il nodo.

Problemi con GPUDirect-TCPX(O)

Questa sezione fornisce informazioni per la risoluzione dei problemi relativi a GPUDirect-TCPX(O).

Note di rilascio e istruzioni per l'upgrade

Per i nuovi utenti, la sezione Massimizzare la larghezza di banda di rete della GPU nei cluster in modalità Standard fornisce indicazioni sull'utilizzo di GPUDirect-TCPX(O). Per gli utenti esistenti, leggi le note di rilascio di GPUDirect-TCPXO per informazioni sulla release e istruzioni per l'upgrade, perché vengono rilasciate continuamente nuove versioni.

Eseguire il debug con i log NCCL

Se non riesci a risolvere un problema con NCCL, raccogli i log NCCL con informazioni di debug. Questi log contengono informazioni preziose sulle operazioni NCCL e possono aiutarti a trovare l'origine del problema. Se non riesci a risolvere il problema, raccogli questi log prima di aprire una richiesta con l'assistenza clienti Google Cloud. Questi log possono aiutare l'assistenza clienti Google Cloud a risolvere il problema più rapidamente.

Per generare e raccogliere i log, completa i seguenti passaggi:

  1. Imposta le seguenti variabili di ambiente all'interno del manifest del pod o dell'applicazione:

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    Per ulteriori informazioni su queste variabili di ambiente, leggi Raccogliere i log di debug NCCL.

  2. Per generare dati per i log, esegui un test NCCL. Il modo per eseguire questo test dipende dal tipo di cluster che utilizzi. Per i cluster GKE, puoi eseguire il deployment ed eseguire il test NCCL con la pianificazione basata sulla topologia (TAS). Dopo aver eseguito il test NCCL, NCCL genera automaticamente i log su tutti i nodi partecipanti.

  3. Raccogli i log da tutti i nodi. Verifica di aver raccolto i log NCCL da tutti i nodi controllando che contengano le seguenti informazioni:

    • I nomi host di tutte le VM coinvolte in un workload.
    • I PID di tutti i processi pertinenti sulla VM.
    • I ranghi di tutte le GPU utilizzate dal workload su ogni VM.

    Se non sai dove si trovano i file di log, l'esempio seguente mostra dove NCCL crea i file di log quando la variabile NCCL_DEBUG_FILE è impostata su /tmp/nccl_log.%h.%p. Hai due VM denominate a3plus-vm-1 e a3plus-vm-2 e ogni VM esegue otto processi all'interno del container del workload. In questo scenario, NCCL crea i seguenti file di log nella directory /tmp all'interno del container del workload su ogni VM:

    • Su a3plus-vm-1: otto file di log denominati nccl_log.a3plus-vm-1.PID, dove PID è l'ID processo.
    • Su a3plus-vm-2: otto file di log denominati nccl_log.a3plus-vm-2.PID.

  4. Esamina i log. Le voci di log NCCL hanno il seguente formato:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Queste voci di log contengono i seguenti valori:

    • HOSTNAME: il nome host della VM. Questo valore identifica la VM utilizzata quando NCCL ha generato la voce di log.
    • PID: il PID. Questo valore identifica il processo che ha generato la voce di log.
    • TID: l'ID thread. Questo valore identifica quale thread all'interno del processo è stato utilizzato quando NCCL ha generato la voce di log.
    • RANK: l'ID ranking locale. Questo valore identifica la GPU utilizzata quando NCCL ha generato la voce di log. I ranghi sono numerati da 0 a N, dove N è il numero totale di GPU coinvolte nel processo. Ad esempio, se il tuo workload viene eseguito con otto GPU per VM, ogni VM deve avere otto valori di rango diversi (0-7).
    • NCCL_MESSAGE: un messaggio descrittivo che fornisce maggiori informazioni sull'evento e include il timestamp di quando NCCL ha creato il log.

    Ad esempio:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    Questo esempio ha i seguenti valori:

    • gke-a3plus-mega-np-2-aa33fe53-7wvq: il nome host.
    • 1581: l'ID processo.
    • 1634: l'ID thread.
    • 1: l'ID ranking locale.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: il messaggio che spiega cosa è successo.

  5. Se apri una richiesta di assistenza, comprimi i log raccolti e l'output del test NCCL in un file ZIP. Includi il file zip quando invii una richiesta di assistenza all'assistenza clienti Google Cloud.

  6. Per interrompere la raccolta dei log di debug NCCL, rimuovi le variabili che hai aggiunto nel passaggio 1.

Passaggi successivi