Se i pod Google Kubernetes Engine (GKE) sono bloccati in uno stato Pending durante la richiesta di risorse nvidia.com/gpu o se i nodi non riescono a registrare le GPU disponibili, potresti avere un problema con l'installazione del driver NVIDIA o con la configurazione del pool di nodi. Questi problemi impediscono ai workload di accedere all'hardware GPU di cui hanno bisogno.
Questo documento mostra come diagnosticare e risolvere i problemi comuni che impediscono a GKE di pianificare o eseguire workload con accelerazione GPU. Scopri come verificare l'installazione del driver della GPU, ispezionare i log dei pod e dei nodi per individuare eventuali errori e confermare che le configurazioni siano corrette.
Queste informazioni sono destinate agli amministratori e agli operatori della piattaforma che gestiscono i pool di nodi abilitati per le GPU e devono risolvere i problemi dei driver NVIDIA, nonché agli sviluppatori di applicazioni che devono eseguire il debug dei workload delle GPU bloccati o che non si avviano. 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.
Installazione dei driver GPU
Questa sezione fornisce informazioni sulla 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 con GPU L4, RTX PRO 6000, H100 o H200 collegate, il driver GPU predefinito installato da GKE potrebbe non essere uguale o successivo alla versione richiesta per queste GPU. Di conseguenza, il pod del plug-in del dispositivo GPU rimane bloccato nello stato In attesa e i workload GPU su questi nodi potrebbero riscontrare problemi.
Per risolvere il problema, consulta le istruzioni per la rispettiva GPU:
L4 e H100
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 il driver versione 535 o successive eseguendo il seguente comando:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml
RTX PRO 6000
Per risolvere questo problema per le GPU RTX PRO 6000, esegui l'upgrade a una delle seguenti versioni di GKE. Queste versioni installano la versione 580 del driver GPU come driver predefinito:
- 1.32.8-gke.1170000 e versioni successive
- 1.33.4-gke.1245000 e versioni successive
- 1.34.0-gke.1662000 e versioni successive
Questa soluzione funziona solo per i tipi di macchine G4 con una o più GPU. I tipi di macchina G4 con meno di una GPU non supportano le immagini dei nodi Ubuntu.
H200
Per risolvere questo problema per le GPU H200, devi installare manualmente la versione del driver 550 o successiva 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 dei dispositivi GPU non funzionano e generano errori CrashLoopBackOff
Il seguente problema si verifica se hai utilizzato il metodo di installazione manuale del driver nel tuo pool di nodi prima del 25 gennaio 2023 e in seguito hai eseguito l'upgrade del node pool a una versione di GKE che supporta l'installazione automatica del driver. Entrambi i workload di installazione esistono contemporaneamente e tentano di installare versioni dei driver in conflitto sui nodi.
Il container init del plug-in del dispositivo GPU non riesce con lo stato Init:CrashLoopBackOff. I log del 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, il workload di installazione in conflitto viene eliminato e GKE può installare automaticamente un driver sui tuoi nodi.
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yamlApplica nuovamente al cluster il manifest DaemonSet per l'installazione manuale dei driver. Il 25 gennaio 2023 abbiamo aggiornato il manifest per ignorare 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.yamlDisabilita l'installazione automatica dei driver per il pool di nodi. Il DaemonSet di installazione del 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=LOCATIONSostituisci 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 località di Compute Engine del cluster.
Per ulteriori informazioni sulla mappatura della versione del driver GPU alla versione di GKE, consulta Mappa la versione di GKE e la versione dell'immagine del nodo Container-Optimized OS alla versione del driver GPU.
Errore: "Immagine container cos-nvidia-installer:fixed non è presente con criterio di pull Never." o "Immagine container ubuntu-nvidia-installer:fixed non è presente con criterio di pull Never."
Questo problema si verifica quando i pod nvidia-driver-installer sono nello stato PodInitializing e il pod del dispositivo del plug-in GPU o del programma di installazione del driver GPU segnala 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 precaricata per liberare spazio su un nodo. Quando il pod del driver viene ricreato o il suo container viene riavviato, GKE non sarà in grado di individuare l'immagine precaricata.
Per mitigare il problema della garbage collection durante l'esecuzione di 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
Per ulteriori informazioni sulla mappatura della versione del driver GPU alla versione di GKE, consulta Mappa la versione di GKE e la versione dell'immagine del nodo Container-Optimized OS alla versione del driver GPU.
Se i tuoi nodi eseguono Ubuntu, non è ancora disponibile una correzione per questo problema di garbage collection. Per ridurre questo problema su Ubuntu, puoi eseguire un container con privilegi che interagisce con l'host per garantire la corretta configurazione dei driver GPU NVIDIA. Per farlo, esegui sudo /usr/local/bin/nvidia-container-first-boot dal 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. Questo può verificarsi su nodi riservati o nodi con GPU che utilizzano l'archiviazione SSD locale temporanea. In questo caso, GKE precarica le immagini container nvidia-installer-driver sui nodi e le sposta dal disco di avvio all'SSD locale al primo avvio.
Per confermare che si è verificato un evento di manutenzione dell'host, utilizza il seguente filtro di log:
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")
Per mitigare il problema di manutenzione dell'host, esegui l'upgrade della tua 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: non è una directory.
Questo errore si verifica nel container del programma di installazione dei driver della 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 sui cluster e sui nodi che eseguono GKE 1.28 e 1.29.
Il problema è causato da una race condition di NCCL fastsocket con il programma di installazione del driver GPU.
Per mitigare 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ù, consulta le note di rilascio di GPUDirect-TCPXO.
Errore: impossibile recuperare il dispositivo per nvidia0: dispositivo nvidia0 non trovato.
Il seguente errore indica che XID 62 e RmInitAdapter non sono riusciti per la GPU con minor 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 mancata inizializzazione della GPU.
Per risolvere il problema, esegui l'upgrade del driver NVIDIA alla versione 525.110.11 o successiva.
Problemi di GPUDirect RDMA
Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi a GPUDirect RDMA.
Errore: plug-in gIB di rete non trovato
L'immagine pytorch/pytorch:latest del repository PyTorch non include la suite di protocolli della libreria Netlink (libnl), necessaria per il plug-in gIB.
Il seguente errore indica che il plug-in gIB non è stato caricato perché le librerie libnl non sono presenti nell'immagine:
ncclInvalidUsage: Error: network gIB not found.
Per risolvere il problema, devi utilizzare un'immagine di base PyTorch diversa o aggiungere manualmente le librerie ai container. Il problema non è specifico di un tipo di macchina. Per ulteriori informazioni sull'utilizzo di NCCL/gIB, consulta Ottimizza il networking dei cluster utilizzando NCCL/gIB.
Risolvi il problema utilizzando l'immagine Nvidia PyTorch
Puoi risolvere questo problema utilizzando l'immagine NVIDIA PyTorch. Per trovare l'ultima versione, consulta le note di rilascio di PyTorch.
Risolvi il problema tramite l'installazione manuale
Se non puoi eseguire la migrazione a un'altra base di immagini, puoi anche installare manualmente le librerie libnl nell'immagine container.
apt update -y && apt upgrade -y && apt install -y libnl-3-200 libnl-route-3-200
Per garantire la coerenza della libreria IBVerbs all'interno del container del workload, utilizza il DaemonSet del programma di installazione RDMA NCCL aggiornato per installare le librerie dei plug-in gIB nel percorso del container.
Per scaricare la configurazione del DaemonSet, clona il repository degli acceleratori del motore dei container:
cd
git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.git
Trova la configurazione nella directory tree/master/gpudirect-rdma:
cd container-engine-accelerators/gpudirect-rdma
ls -l nccl-rdma-installer*
-rw-r----- 1 adelab primarygroup 2899 May 6 15:57 nccl-rdma-installer-a4x.yaml
-rw-r----- 1 adelab primarygroup 2743 Apr 30 00:34 nccl-rdma-installer-autopilot.yaml
-rw-r----- 1 adelab primarygroup 2677 May 6 15:57 nccl-rdma-installer.yaml
Scegli una delle seguenti configurazioni del programma di installazione:
| Descrizione | nccl-rdma-installer.yaml |
nccl-rdma-installer-a4x.yaml |
nccl-rdma-installer-autopilot.yaml |
|---|---|---|---|
| Modalità operativa di GKE | GKE Standard | GKE Standard | GKE Autopilot |
| Tipi di macchina | Tipi di macchine A4 e A3 Ultra | Tipo di macchina A4X | Tipi di macchine A4 e A3 Ultra |
| Spazio dei nomi | Esegue il deployment in kube-system. |
Esegue il deployment in kube-system. |
Esegue il deployment in uno spazio dei nomi rdma-system dedicato (perché Autopilot limita le modifiche allo spazio dei nomi kube-system). |
| Classe di priorità | Utilizza system-node-critical per garantire che il programma di installazione venga eseguito con priorità elevata. |
Utilizza system-node-critical. |
Nessuno. (Autopilot limita l'utilizzo delle classi di priorità a livello di sistema). |
| Funzione | Viene eseguito come DaemonSet e installa il plug-in GPUDirect-TCPX (GIB) NCCL (in particolare nccl-plugin-gib:v1.1.1) nelle directory host /home/kubernetes/bin/nvidia/lib64 e /home/kubernetes/bin/gib. Questo approccio consente una comunicazione RDMA ad alte prestazioni per NCCL sui nodi GKE. |
Simile al programma di installazione di base, ma installa la versione compilata per ARM64 del plug-in NCCL GPUDirect-TCPX (GIB) (nccl-plugin-gib-arm64:v1.1.0). Include anche un'affinità dei nodi specifica per nvidia-gb200 e arm64 per garantire che venga eseguito solo su questi nodi GKE specifici. |
Installa il plug-in NCCL GPUDirect-TCPX (GIB) (nccl-plugin-gib:v1.1.1), ma con modifiche che supportano il modello operativo e di sicurezza della modalità Autopilot:
|
Applica il DaemonSet:
kubectl apply -f nccl-rdma-installer.yaml
Mappa la versione di GKE e la versione dell'immagine del nodo Container-Optimized OS alla versione del driver GPU
Per trovare le versioni dei driver GPU mappate alle versioni di GKE e alle versioni delle immagini dei nodi di Container-Optimized OS, segui questi passaggi:- Mappa le versioni delle immagini dei nodi di Container-Optimized OS alle versioni patch di GKE per la versione GKE specifica in cui vuoi trovare la versione del driver GPU. Ad esempio, 1.33.0-gke.1552000 utilizza cos-121-18867-90-4.
- Scegli la milestone della versione dell'immagine del nodo di Container-Optimized OS nelle note di rilascio di Container-Optimized OS. Ad esempio, scegli Milestone 121 per cos-121-18867-90-4.
- Nella pagina delle note di rilascio per la milestone specifica, trova la nota di rilascio corrispondente alla versione specifica dell'immagine del nodo Container-Optimized OS. Ad esempio, in Note di rilascio di Container-Optimized OS: Milestone 121, vedi cos-121-18867-90-4. Nella tabella, nella colonna Driver GPU, fai clic su Visualizza elenco per visualizzare le informazioni sulla versione del driver GPU.
In GKE versione 1.36.0-gke.3302004 e successive, GKE pubblica automaticamente la versione del driver NVIDIA installato come annotazioni sui nodi GPU in esecuzione. Per visualizzare le annotazioni della versione del driver su un nodo GPU, esegui il seguente comando:
kubectl get node GPU_NODE_NAME -o jsonpath='{.metadata.annotations}'
Sostituisci GPU_NODE_NAME con il nome del nodo GPU.
L'output include annotazioni simili alle seguenti:
{
"cloud.google.com/cuda.driver-version.full": "580.126.20",
"cloud.google.com/cuda.driver-version.major": "580",
"cloud.google.com/cuda.driver-version.minor": "126",
"cloud.google.com/cuda.driver-version.revision": "20"
}
Il comando nvidia-smi non va a buon fine
Quando utilizzi VM GPU per eseguire workload in GKE, comandi come nvidia-smi
potrebbero non riuscire all'interno del container con uno dei seguenti errori:
bash: nvidia-smi: command not found- Errori che indicano che non è possibile trovare
libnvidia-ml.soo altre librerie NVIDIA.
GKE monta i driver e gli strumenti NVIDIA necessari dal nodo host nei container, in genere nel percorso /usr/local/nvidia/. Tuttavia, le variabili di ambiente predefinite del container (PATH e LD_LIBRARY_PATH) potrebbero non includere i percorsi di questi file binari e librerie NVIDIA.
Per risolvere questi errori, aggiorna il manifest del pod o del deployment in modo da includere i percorsi NVIDIA necessari nelle variabili di ambiente PATH e LD_LIBRARY_PATH per il container.
Ad esempio, aggiungi il seguente blocco env alla specifica spec.template.spec.containers:
spec:
containers:
- name: gpu-container
image: gpu-image
env:
- name: LD_LIBRARY_PATH
# Prepend NVIDIA lib64 directory to existing LD_LIBRARY_PATH
value: /usr/local/nvidia/lib64
- name: PATH
# Prepend NVIDIA bin directory to existing PATH
value: /usr/local/nvidia/bin:$PATH
# ... other container settings
Riavvio del sistema operativo guest per i cluster standard
Questa sezione mostra come utilizzare GKE per gestire il riavvio del sistema operativo guest in esecuzione sul nodo per i cluster standard.
Un nodo GKE potrebbe richiedere un riavvio se presenta problemi con Xid o altri problemi della GPU. Per esempi di problemi relativi agli Xid, consulta Gestione degli Xid di Compute Engine.
Quando riavvii il sistema operativo guest con questo metodo, si verifica quanto segue:
- Il sistema operativo guest viene reimpostato.
- La GPU viene reimpostata.
- L'istanza sottostante non viene modificata e il disco di avvio viene conservato, ma dopo il riavvio l'ID di avvio è diverso.
L'operazione di riavvio richiede circa cinque minuti. Questo tempo si aggiunge al periodo di tolleranza della cessazione configurato sui pod. Per maggiori dettagli sul ciclo di vita e sul periodo di terminazione dei pod, consulta Terminazione dei pod.
Requisiti
Questo metodo per il riavvio del sistema operativo guest richiede che il cluster esegua GKE versione 1.37.0-gke.3503000 o successiva. Non attivare un reboot del sistema operativo guest nelle versioni precedenti, perché GKE potrebbe non essere in grado di pianificare i workload sui nodi al termine del reboot.
Riavvia il sistema operativo guest su un nodo GKE
Per riavviare il sistema operativo guest su un nodo GKE, segui questi passaggi:
Identifica il nodo da riavviare.
Applica l'etichetta
cloud.google.com/perform-reboot=trueutilizzando il seguente comando:kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=trueSostituisci
NODE_NAMEcon il nome del nodo.Quando viene applicata questa etichetta, GKE riavvia il sistema operativo guest eseguendo i seguenti passaggi:
- Contrassegna il nodo come non pianificabile.
- Espelle i pod, rispettando eventuali budget di distribuzione e il periodo di tolleranza per la terminazione. Per maggiori dettagli su come configurare questi comportamenti di terminazione, consulta Configura GKE per terminare i workload in modo controllato.
- Riavvia il nodo utilizzando
systemd. Il nodo si arresta e si riavvia e l'ID di avvio cambia.
Vai agli eventi del nodo per verificare che il nodo sia stato riavviato correttamente.
Nella console Google Cloud , vai a Kubernetes Engine > Cluster.
Seleziona il cluster che contiene il nodo che stai riavviando.
Fai clic su Nodi e poi seleziona il nodo che stai riavviando.
Fai clic su Eventi per visualizzare la pagina degli eventi del nodo.
Gli eventi dei nodi vengono registrati in questa pagina. Gli eventi di un processo di riavvio riuscito includono:
- Quando il nodo si avvia dopo il riavvio.
- Quando il gestore della manutenzione rimuove l'etichetta del nodo
perform-reboot. - Quando viene rilevata la modifica dell'ID di avvio.
Se hai seguito questi passaggi per un nodo che esegue una versione precedente alla 1.37.0-gke.3503000, il nodo potrebbe conservare sia il taint cloud.google.com/impending-node-termination sia l'etichetta cloud.google.com/perform-reboot=true al termine del riavvio. Il nodo ha lo stato Ready, ma non può eseguire workload. Per risolvere il problema,
esegui l'upgrade a GKE versione 1.37.0-gke.3503000 o successive. Per mitigare questo problema senza eseguire l'upgrade, rimuovi manualmente la contaminazione e l'etichetta dal nodo interessato eseguendo i seguenti comandi:
# Remove the perform-reboot label
kubectl label node NODE_NAME cloud.google.com/perform-reboot-
# Remove the boot ID annotation (might report "not found", which is expected)
kubectl annotate node NODE_NAME node.gke.io/reboot-boot-id-
# Remove the taint (might already be removed automatically, which is expected)
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination:NoSchedule-
Sostituisci NODE_NAME con il nome del nodo bloccato.
Dopo aver rimosso lo stato di blocco, attendi almeno 60 secondi affinché il gestore della manutenzione rilevi le modifiche. Non tentare di riavviare nuovamente il sistema operativo guest, a meno che il tuo cluster non esegua la versione 1.37.0-gke.3503000 o successiva.
Etichetta di riavvio ignorata se riapplicata rapidamente
In tutte le versioni di GKE, se riapplichi l'etichetta cloud.google.com/perform-reboot=true entro 60 secondi dal completamento del riavvio, il gestore della manutenzione potrebbe non agire sulla nuova etichetta a causa di una race condition nel suo stato interno. Il nodo rimane bloccato con l'etichetta perform-reboot e il taint cloud.google.com/impending-node-termination, ma non viene eseguito alcun riavvio.
Per mitigare questo problema, attendi almeno 60 secondi dal completamento del riavvio prima di applicare nuovamente l'etichetta cloud.google.com/perform-reboot=true. Puoi verificare che il riavvio sia stato completato controllando che l'etichetta perform-reboot e l'annotazione reboot-boot-id siano state rimosse dal nodo:
kubectl get node NODE_NAME -o jsonpath='{.metadata.labels.cloud\.google\.com/perform-reboot}'
kubectl get node NODE_NAME -o jsonpath='{.metadata.annotations.node\.gke\.io/reboot-boot-id}'
Sostituisci NODE_NAME con il nome del nodo.
Entrambi i comandi dovrebbero restituire un output vuoto prima di applicare nuovamente l'etichetta.
Se il nodo è già bloccato, rimuovi manualmente i metadati del nodo Kubernetes che causano lo stato di blocco:
Rimuovi l'etichetta del nodo
cloud.google.com/perform-reboot:kubectl label node NODE_NAME \ cloud.google.com/perform-reboot-Sostituisci
NODE_NAMEcon il nome del nodo bloccato.Rimuovi l'annotazione
node.gke.io/reboot-boot-id:kubectl annotate node NODE_NAME \ node.gke.io/reboot-boot-id-Se l'output è
not found, l'annotazione è già stata rimossa.Rimuovi il taint
cloud.google.com/impending-node-termination:NoSchedule:kubectl taint nodes NODE_NAME \ cloud.google.com/impending-node-termination:NoSchedule-Se l'output è
not found, la contaminazione è già stata rimossa.Attendi almeno 60 secondi.
Riapplica l'etichetta
cloud.google.com/perform-reboot:kubectl label node NODE_NAME \ cloud.google.com/perform-reboot=true
Ripristina le GPU sulle VM A3 e A4
Per alcuni problemi potrebbe essere necessario reimpostare la GPU su una VM A3 o A4.
Nota: puoi anche utilizzare gpu-reset-tool per reimpostare tutte le GPU. Questo strumento automatizza il processo di ripristino e richiede solo il nome del nodo di destinazione.
Per reimpostare manualmente la GPU, segui questi passaggi:
Rimuovi i pod che richiedono risorse GPU dal nodo in cui devi reimpostare la GPU.
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=trueSostituisci
NODE_NAMEcon il nome del nodo.Se hai abilitato le metriche DCGM, disattiva temporaneamente l'esportatore DCGM sul nodo modificando l'etichetta della versione del driver:
a. Prendi nota del valore attuale dell'etichetta
cloud.google.com/gke-gpu-driver-versionsul nodo.b. Modifica il valore dell'etichetta in
resetper rimuovere il pod dell'esportatore DCGM:kubectl label node NODE_NAME \ cloud.google.com/gke-gpu-driver-version=reset --overwriteIl pod viene espulso automaticamente perché richiede che l'etichetta sia
defaultolatest.Connettiti alla VM che supporta il nodo.
Nella sessione SSH, reimposta la GPU:
Reimposta tutte le GPU sulla VM
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-resetPer reimpostare una GPU specifica
# Identify the faulty GPU /home/kubernetes/bin/nvidia/bin/nvidia-smi # Reset the specifc GPU using either the GPU index or PCI bus ID from above command output /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset -i <gpu_id>Ripristina le etichette dei nodi per riattivare il plug-in del dispositivo GPU e l'esportatore DCGM:
a. 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 \ --overwriteb. Ripristina il valore originale dell'etichetta
cloud.google.com/gke-gpu-driver-version(ad esempiolatestodefault) per riattivare l'esportatore DCGM:kubectl label node NODE_NAME \ cloud.google.com/gke-gpu-driver-version=ORIGINAL_VALUE --overwrite
GPU su Confidential GKE Node
Le sezioni seguenti mostrano come identificare e risolvere i problemi relativi alle GPU in esecuzione su Confidential GKE Node.
I workload GPU non vengono pianificati su Confidential GKE Node
Confidential GKE Node richiede l'installazione manuale di un driver GPU corrispondente al tipo di GPU selezionato e alla versione di GKE.
Se i pod GPU non vengono pianificati su Confidential GKE Node e rimangono nello stato Pending, descrivi il DaemonSet di installazione del driver:
kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml
Se l'output restituisce un errore NotFound,
installa il driver.
Se il 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 Confidential GKE Node.
Esegui il deployment del DaemonSet che supporta le GPU su 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, verifica se i workload 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 scollegamento 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 è invasiva e influisce su tutti i workload di quel nodo. Per riavviare l'istanza, segui questi passaggi:
Recupera il nome del nodo che esegue il pod GPU:
kubectl get pod POD_NAME -o yaml | grep "nodeName"Sostituisci
POD_NAMEcon il nome del pod in errore.L'output è simile al seguente:
nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3eReimposta l'istanza Compute Engine:
gcloud compute instances reset NODE_NAMESostituisci
NODE_NAMEcon il nome del nodo dall'output del passaggio precedente.gcloud CLI cerca le VM con quel nome nel tuo progetto attivo. Se ti viene chiesto di selezionare una zona, specifica
Y.Controlla se i workload 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 andate 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 in errore.
gcloud CLI cerca le VM con quel nome nel tuo progetto attivo. Se ti viene chiesto di selezionare una zona, specifica Y.
Se la reimpostazione dell'istanza non risolve il problema, contatta l'assistenza clienti Google Cloud o invia un bug del prodotto. Per saperne di più, consulta Richiedi 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 workload GPU: allocazione delle risorse GPU ai pod.
- Controllo di integrità delle GPU: monitoraggio dell'integrità delle GPU.
- Raccolta di metriche della GPU: raccolta di metriche relative alla GPU, come il ciclo di lavoro e la memoria utilizzata.
gpu-device-plugin utilizza la libreria 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 intraprende alcuna azione automatica per gli errori XID non critici.
- Formato log:
- 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 workload GPU sul nodo.
- Se la riparazione automatica dei nodi è abilitata, GKE ricrea il nodo.
- Formato log:
Problemi con GPUDirect-TCPX(O)
Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi a GPUDirect-TCPX(O). Se utilizzi le versioni interessate di GKE 1.34 o 1.35, consulta anche la pagina Problemi noti di GKE.
Nota di rilascio e istruzioni per l'upgrade
Per i nuovi utenti, Massimizza la larghezza di banda di rete delle 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, poiché vengono rilasciate continuamente nuove versioni.
Errore di tcpx-daemon e tcpxo-daemon dopo l'upgrade della versione di GKE
Se i pod tcpx-daemon o tcpxo-daemon non funzionano, potresti riscontrare il seguente errore:
cuda error detected! name: CUDA_ERROR_NO_DEVICE; string: no CUDA-capable device is detected
Inoltre, controlla se i pod device-injector nello spazio dei nomi kube-system sono nello stato CrashLoopBackOff o Error.
Questo problema si verifica se hai eseguito l'upgrade dei node pool GKE a una delle seguenti versioni o versioni successive:
- Per GKE 1.31: 1.31.14-gke.1033000
- Per GKE 1.32: 1.32.9-gke.1575000
- Per GKE 1.33: 1.33.5-gke.1862000
- Per GKE 1.34: 1.34.1-gke.3225000
- Per GKE 1.35 e versioni successive
Il problema è causato dall'utilizzo di una versione precedente del manifest dell'iniettore di dispositivi NRI che include un initContainer denominato enable-nri. In queste versioni di GKE interessate, l'NRI è abilitato per impostazione predefinita nella configurazione del nodo. Il container enable-nri obsoleto tenta di modificare la configurazione e riavviare il runtime del container, il che è in conflitto con i valori predefiniti di sistema e causa l'arresto anomalo dei pod nri-device-injector. Questo errore impedisce l'esposizione dei dispositivi GPU al container tcpx-daemon o tcpxo-daemon.
Per risolvere il problema, aggiorna il DaemonSet nri-device-injector all'ultima versione, che rimuove il initContainer in conflitto.
Elimina il DaemonSet esistente:
kubectl delete daemonset device-injector -n kube-systemApplica il manifest più recente:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yamlRiavvia i pod del workload.
Esegui il debug con i log NCCL
Se non riesci a risolvere un problema con NCCL, raccogli i log NCCL con le 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:
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.%pPer saperne di più su queste variabili di ambiente, consulta Raccogli i log di debug NCCL.
Per generare dati per i log, esegui un test NCCL. Il modo in cui eseguire questo test dipende dal tipo di cluster che utilizzi. Per i cluster GKE, puoi eseguire il deployment e 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.
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 rank 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 denominatea3plus-vm-1ea3plus-vm-2, ciascuna delle quali esegue otto processi all'interno del container del workload. In questo scenario, NCCL crea i seguenti file di log nella directory/tmpall'interno del container del workload su ogni VM:- Su
a3plus-vm-1: otto file di log denominatinccl_log.a3plus-vm-1.PID, dovePIDè l'ID di processo. - Su
a3plus-vm-2: otto file di log denominatinccl_log.a3plus-vm-2.PID.
Esamina i log. Le voci di log NCCL hanno il seguente formato:
HOSTNAME:PID:TID [RANK] NCCL_MESSAGEQueste 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 del thread. Questo valore identifica il thread all'interno del processo utilizzato quando NCCL ha generato la voce di log.RANK: l'ID del rank locale. Questo valore identifica la GPU utilizzata quando NCCL ha generato la voce di log. I rank sono numerati da 0 a N, dove N è il numero totale di GPU coinvolte nel processo. Ad esempio, se il workload viene eseguito con otto GPU per VM, ogni VM deve avere otto valori di ranking diversi (0-7).NCCL_MESSAGE: un messaggio descrittivo che fornisce ulteriori 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 di processo.1634: l'ID del thread.1: l'ID del rank locale.NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: il messaggio che spiega cosa è successo.
Se stai aprendo una richiesta di assistenza, inserisci i log che hai raccolto, insieme all'output del test NCCL, in un file ZIP. Includi il file ZIP quando invii una richiesta di assistenza all'assistenza clienti Google Cloud.
Per interrompere la raccolta dei log di debug NCCL, rimuovi le variabili aggiunte nel passaggio 1.
Passaggi successivi
Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta Richiedi assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:
- Aprire una richiesta di assistenza contattando l'assistenza clienti Google Cloud.
- Ricevere assistenza dalla community facendo domande su StackOverflow e utilizzando il tag
google-kubernetes-engineper cercare problemi simili. Puoi anche unirti al canale Slack#kubernetes-engineper ricevere ulteriore assistenza dalla community. - Apertura di problemi o richieste di funzionalità utilizzando l'Issue Tracker pubblico.