Résoudre les problèmes liés aux GPU dans GKE

Cette page explique comment résoudre les problèmes liés aux TPU dans Google Kubernetes Engine (GKE).

Installation des pilotes de GPU

Cette section fournit des informations de dépannage pour l'installation automatique des pilotes de périphériques NVIDIA dans GKE.

L'installation du pilote échoue dans les nœuds Ubuntu

Si vous utilisez des nœuds Ubuntu auxquels sont associés des GPU L4, H100 ou H200, il est possible que le pilote de GPU par défaut installé par GKE ne soit pas à la version requise pour ces GPU ou à une version ultérieure. Par conséquent, le pod du plug-in d'appareil GPU reste bloqué à l'état "En attente", et vos charges de travail GPU sur ces nœuds peuvent rencontrer des problèmes.

Pour résoudre ce problème avec les GPU L4 et H100, nous vous recommandons de passer aux versions GKE suivantes, qui installent la version 535 du pilote de GPU par défaut :

  • 1.26.15-gke.1483000 et versions ultérieures
  • 1.27.15-gke.1039000 et versions ultérieures
  • 1.28.11-gke.1044000 et versions ultérieures
  • 1.29.6-gke.1073000 et versions ultérieures
  • 1.30.2-gke.1124000 et versions ultérieures

Vous pouvez également installer manuellement la version 535 ou ultérieure du pilote en exécutant la commande suivante :

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

Pour résoudre ce problème avec les GPU H200, vous devez installer manuellement la version 550 ou ultérieure du pilote en exécutant la commande suivante :

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

Les plug-ins d'appareils GPU échouent avec des erreurs CrashLoopBackOff

Le problème suivant se produit si vous avez utilisé la méthode d'installation manuelle du pilote dans votre pool de nœuds avant le 25 janvier 2023, puis que vous avez mis à niveau votre pool de nœuds vers une version de GKE compatible avec l'installation automatique du pilote. Les deux charges de travail d'installation existent en même temps et tentent d'installer des versions de pilote incompatibles sur vos nœuds.

Le conteneur d'initialisation du plug-in d'appareil GPU échoue avec l'état Init:CrashLoopBackOff. Les journaux du conteneur sont semblables à ceux-ci :

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

Essayez les solutions suivantes pour résoudre ce problème :

  • Supprimez le DaemonSet d'installation manuelle du pilote de votre cluster. Cela supprime la charge de travail d'installation en conflit et permet à GKE d'installer automatiquement un pilote sur vos nœuds.

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

  • Réappliquez le fichier manifeste du DaemonSet d'installation manuelle du pilote à votre cluster. Le 25 janvier 2023, nous avons mis à jour le fichier manifeste pour ignorer les nœuds qui utilisent l'installation automatique du pilote.

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

  • Désactivez l'installation automatique des pilotes pour votre pool de nœuds. Le DaemonSet d'installation du pilote existant devrait fonctionner comme prévu une fois l'opération de mise à jour terminée.

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

    Remplacez les éléments suivants :

    • POOL_NAME : nom du pool de nœuds.
    • GPU_TYPE : type de GPU déjà utilisé par le pool de nœuds.
    • GPU_COUNT : nombre de GPU déjà associés au pool de nœuds.
    • CLUSTER_NAME : nom du cluster GKE contenant le pool de nœuds.
    • LOCATION : emplacement Compute Engine du cluster.

Erreur : "L'image de conteneur cos-nvidia-installer:fixed n'est pas présente avec la stratégie d'extraction "Never"." ou "L'image de conteneur ubuntu-nvidia-installer:fixed n'est pas présente avec la stratégie d'extraction "Never"."

Ce problème se produit lorsque les pods nvidia-driver-installer sont à l'état PodInitializing et que les pods du programme d'installation du pilote de GPU ou du plug-in de l'appareil GPU signalent l'erreur suivante. Le message d'erreur spécifique dépend du système d'exploitation exécuté sur votre nœud :

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.

Ce problème peut se produire lorsque le récupérateur de mémoire supprime l'image du pilote NVIDIA préchargée pour libérer de l'espace sur un nœud. Lorsque le pod du pilote est recréé ou que son conteneur est redémarré, GKE ne peut pas localiser l'image préchargée.

Pour atténuer le problème de récupération de mémoire lorsque vous exécutez COS, mettez à niveau vos nœuds GKE vers l'une de ces versions contenant le correctif :

  • 1.25.15-gke.1040000 et versions ultérieures
  • 1.26.10-gke.1030000 et versions ultérieures
  • 1.27.6-gke.1513000 et versions ultérieures
  • 1.28.3-gke.1061000 et versions ultérieures

Si vos nœuds exécutent Ubuntu, aucune solution n'est encore disponible pour ce problème de collecte des déchets. Pour atténuer ce problème sur Ubuntu, vous pouvez exécuter un conteneur privilégié qui interagit avec l'hôte pour assurer la configuration correcte des pilotes de GPU NVIDIA. Pour ce faire, exécutez sudo /usr/local/bin/nvidia-container-first-boot à partir de votre nœud ou appliquez le fichier manifeste suivant :

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

Une autre cause potentielle du problème est la perte des images de pilote NVIDIA après le redémarrage du nœud ou la maintenance de l'hôte. Cela peut se produire sur des nœuds confidentiels ou des nœuds avec GPU qui utilisent un stockage SSD local éphémère. Dans ce cas, GKE précharge les images de conteneur nvidia-installer-driver sur les nœuds et les déplace du disque de démarrage vers le SSD local au premier démarrage.

Pour confirmer qu'un événement de maintenance de l'hôte s'est produit, utilisez le filtre de journal suivant :

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

Pour résoudre le problème de maintenance de l'hôte, mettez à niveau votre version de GKE vers l'une des versions suivantes :

  • 1.27.13-gke.1166000 et versions ultérieures
  • 1.29.3-gke.1227000 et versions ultérieures
  • 1.28.8-gke.1171000 et versions ultérieures

Erreur : Échec de la configuration des répertoires d'installation du pilote GPU : Échec de la création de la superposition lib64 : Échec de la création du répertoire /usr/local/nvidia/lib64 : mkdir /usr/local/nvidia/lib64 ne correspond à aucun répertoire.

Vous rencontrez cette erreur à partir du conteneur d'installation du pilote de GPU dans le plug-in de l'appareil GPU lorsque NCCL fastsocket est activé :

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.

Ce problème ne se produit que sur les clusters et les nœuds exécutant GKE 1.28 et 1.29.

Le problème est dû à une condition de concurrence NCCL fastsocket avec le programme d'installation du pilote de GPU.

Pour résoudre ce problème, mettez à niveau votre version de GKE vers l'une des versions suivantes :

  • 1.28.8-gke.1206000 et versions ultérieures
  • 1.29.3-gke.1344000 et versions ultérieures

Pour en savoir plus, consultez les notes de version de GPUDirect-TCPXO.

Erreur : Impossible d'obtenir l'appareil nvidia0 : l'appareil nvidia0 n'a pas été trouvé.

L'erreur suivante indique que XID 62 et RmInitAdapter ont échoué pour le GPU avec la version mineure 0 :

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

La version 525.105.17 du pilote NVIDIA présente un bug qui peut entraîner des erreurs de communication (XID) et empêcher l'initialisation correcte du GPU, ce qui entraîne l'échec de l'initialisation du GPU.

Pour résoudre ce problème, mettez à niveau le pilote NVIDIA vers la version 525.110.11 ou ultérieure.

Réinitialiser les GPU sur les VM A3

Certains problèmes peuvent vous obliger à réinitialiser le GPU sur une VM A3.

Pour réinitialiser le GPU, procédez comme suit :

  1. Supprimez les pods qui demandent des ressources GPU du nœud sur lequel vous devez réinitialiser le GPU.

  2. Désactivez le plug-in d'appareil GPU sur le nœud :

    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

    Remplacez NODE_NAME par le nom du nœud.

  3. Connectez-vous à la VM qui sous-tend le nœud.

  4. Dans la session SSH, réinitialisez le GPU :

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

  5. Réactivez le plug-in de l'appareil 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 sur les nœuds Confidential GKE Node

Les sections suivantes vous expliquent comment identifier et résoudre les problèmes liés aux GPU exécutés sur des nœuds GKE confidentiels.

Les charges de travail GPU ne sont pas planifiées sur les nœuds Confidential GKE Node

Les nœuds Confidential GKE Node nécessitent que vous installiez manuellement un pilote de GPU correspondant au type de GPU sélectionné et à votre version de GKE. Si vos pods GPU ne sont pas planifiés sur les nœuds GKE confidentiels et restent à l'état Pending, décrivez le DaemonSet d'installation du pilote :

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

Si la sortie renvoie une erreur NotFound, installez le pilote.

Si le DaemonSet est en cours d'exécution, le résultat est semblable à ce qui suit :

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

Dans ce résultat, vérifiez que le champ nodeAffinity contient la clé cloud.google.com/gke-confidential-nodes-instance-type. Si la sortie ne contient pas cette clé, le DaemonSet d'installation du pilote ne prend pas en charge les nœuds GKE confidentiels.

Déployez le DaemonSet compatible avec les GPU sur les nœuds Confidential GKE Node :

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

Une fois les pilotes installés, vérifiez si vos charges de travail GPU démarrent correctement.

Erreur : Échec de l'allocation du vecteur de l'appareil

Le message d'erreur suivant dans les journaux de votre conteneur GPU indique que le GPU a été détaché de l'instance de VM du nœud :

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

Ce détachement peut être dû à une erreur matérielle ou à un problème avec les clés de chiffrement.

Pour résoudre ce problème, redémarrez l'instance de nœud. Cette opération est perturbatrice et affecte toutes les charges de travail sur ce nœud. Pour redémarrer l'instance, procédez comme suit :

  1. Obtenez le nom du nœud qui exécute le pod GPU :

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

    Remplacez POD_NAME par le nom du pod défaillant.

    Le résultat ressemble à ce qui suit :

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

  2. Réinitialisez l'instance Compute Engine :

    gcloud compute instances reset NODE_NAME

    Remplacez NODE_NAME par le nom du nœud issu du résultat de l'étape précédente.

    Gcloud CLI recherche les VM portant ce nom dans votre projet actif. Si vous êtes invité à sélectionner une zone, spécifiez Y.

  3. Vérifiez que vos charges de travail de GPU s'exécutent sans erreur.

Erreur : Échec du déchiffrement avec l'erreur -74

Le message d'erreur suivant dans les journaux de nœuds indique que les clés de chiffrement du GPU ont été perdues :

Decryption failed with error -74

Cette erreur se produit lorsque le démon de persistance NVIDIA, qui s'exécute sur l'instance de VM du nœud, échoue. Si ce message d'erreur s'affiche, réinitialisez l'instance :

gcloud compute instances reset NODE_NAME

Remplacez NODE_NAME par le nom du nœud défaillant.

Gcloud CLI recherche les VM portant ce nom dans votre projet actif. Si vous êtes invité à sélectionner une zone, spécifiez Y.

Si la réinitialisation de l'instance ne résout pas le problème, contactez l'assistance Cloud Customer Care ou signalez un bug produit. Pour en savoir plus, consultez Obtenir de l'aide.

Identifier les erreurs XID

Le DaemonSet gpu-device-plugin s'exécute dans l'espace de noms kube-system et est responsable des éléments suivants :

  • Planification des charges de travail GPU : allocation des ressources GPU aux pods.
  • Vérification de l'état des GPU : surveille l'état de vos GPU.
  • Collecte des métriques GPU : collecte des métriques liées au GPU, telles que le cycle d'utilisation et l'utilisation de la mémoire.

gpu-device-plugin utilise la bibliothèque de gestion NVIDIA (NVML) pour détecter les erreurs XID. Lorsqu'une erreur XID se produit, le pod gpu-device-plugin s'exécutant sur le nœud concerné enregistre l'erreur. Vous trouverez deux types de journaux d'erreurs XID :

  • Erreurs XID non critiques :
    • Format du journal : Skip error Xid=%d as it is not Xid Critical
    • Signification : ces erreurs sont considérées comme non critiques. Elles peuvent être causées par divers problèmes logiciels ou matériels.
    • Action : GKE n'effectue aucune action automatisée pour les erreurs XID non critiques.
  • Erreurs XID critiques :
    • Format du journal : XidCriticalError: Xid=%d, All devices will go unhealthy
    • Signification : ces erreurs indiquent un problème matériel lié au GPU.
    • Action :
      • GKE marque les ressources GPU du nœud comme défaillantes.
      • GKE empêche la planification des charges de travail GPU sur le nœud.
      • Si la réparation automatique des nœuds est activée, GKE recréera le nœud.

Problèmes liés à GPUDirect-TCPX(O)

Cette section fournit des informations de dépannage pour les problèmes liés à GPUDirect-TCPX(O).

Notes de version et instructions de mise à niveau

Pour les nouveaux utilisateurs, Maximiser la bande passante réseau des GPU dans les clusters en mode Standard fournit des conseils sur l'utilisation de GPUDirect-TCPX(O). Pour les utilisateurs existants, consultez les notes de version de GPUDirect-TCPXO pour obtenir des informations sur les versions et des instructions de mise à niveau, car de nouvelles versions sont publiées en continu.

Déboguer avec les journaux NCCL

Si vous ne parvenez pas à résoudre un problème lié à NCCL, collectez les journaux NCCL avec des informations de débogage. Ces journaux contiennent des informations utiles sur les opérations NCCL et peuvent vous aider à identifier la source de votre problème. Si vous ne parvenez pas à résoudre le problème, collectez ces journaux avant d'ouvrir une demande auprès de Cloud Customer Care. Ces journaux peuvent aider le Cloud Customer Care à résoudre votre problème plus rapidement.

Pour générer et collecter les journaux, procédez comme suit :

  1. Définissez les variables d'environnement suivantes dans le fichier manifeste de votre pod ou de votre application :

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

    Pour en savoir plus sur ces variables d'environnement, consultez Collecter les journaux de débogage NCCL.

  2. Pour générer des données pour vos journaux, exécutez un test NCCL. La façon d'exécuter ce test dépend du type de cluster que vous utilisez. Pour les clusters GKE, vous pouvez déployer et exécuter le test NCCL avec la planification tenant compte de la topologie (TAS, Topology Aware Scheduling). Une fois le test NCCL exécuté, NCCL génère automatiquement les journaux sur tous les nœuds participants.

  3. Collectez les journaux de tous les nœuds. Vérifiez que vous avez collecté les journaux NCCL de tous les nœuds en vous assurant qu'ils contiennent les informations suivantes :

    • Noms d'hôte de toutes les VM impliquées dans une charge de travail.
    • PID de tous les processus concernés sur la VM.
    • Rangs de tous les GPU utilisés par la charge de travail sur chaque VM.

    Si vous ne savez pas où se trouvent les fichiers journaux, l'exemple suivant vous montre où NCCL crée les fichiers journaux lorsque la variable NCCL_DEBUG_FILE est définie sur /tmp/nccl_log.%h.%p. Vous disposez de deux VM nommées a3plus-vm-1 et a3plus-vm-2, et chacune d'elles exécute huit processus dans le conteneur de charge de travail. Dans ce scénario, NCCL crée les fichiers journaux suivants dans le répertoire /tmp du conteneur de charge de travail sur chaque VM :

    • Sur a3plus-vm-1 : huit fichiers journaux nommés nccl_log.a3plus-vm-1.PID, où PID est l'ID du processus.
    • Sur a3plus-vm-2 : huit fichiers journaux nommés nccl_log.a3plus-vm-2.PID.

  4. Examinez les journaux. Les entrées de journal NCCL ont le format suivant :

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Ces entrées de journal contiennent les valeurs suivantes :

    • HOSTNAME : nom d'hôte de la VM. Cette valeur identifie la VM utilisée lorsque NCCL a généré l'entrée de journal.
    • PID : PID. Cette valeur identifie le processus qui a généré l'entrée de journal.
    • TID : ID du thread. Cette valeur identifie le thread du processus qui était utilisé lorsque NCCL a généré l'entrée de journal.
    • RANK : ID du classement local. Cette valeur identifie le GPU utilisé lorsque NCCL a généré l'entrée de journal. Les rangs sont numérotés de 0 à N, où N correspond au nombre total de GPU impliqués dans le processus. Par exemple, si votre charge de travail s'exécute avec huit GPU par VM, chaque VM doit avoir huit valeurs de rang différentes (de 0 à 7).
    • NCCL_MESSAGE : message descriptif qui fournit plus d'informations sur l'événement et inclut le code temporel de la création du journal par NCCL.

    Exemple :

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

    Cet exemple présente les valeurs suivantes :

    • gke-a3plus-mega-np-2-aa33fe53-7wvq : nom d'hôte.
    • 1581 : ID du processus.
    • 1634 : ID du thread.
    • 1 : ID du classement local.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized. : message expliquant ce qui s'est passé.

  5. Si vous ouvrez une demande d'assistance, regroupez les journaux que vous avez collectés, ainsi que le résultat du test NCCL, dans un fichier ZIP. Incluez le fichier ZIP lorsque vous envoyez une demande d'assistance à Cloud Customer Care.

  6. Pour arrêter la collecte des journaux de débogage NCCL, supprimez les variables que vous avez ajoutées à l'étape 1.

Étapes suivantes