Fehlerbehebung bei GPUs in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit GPUs in Google Kubernetes Engine (GKE) beheben.

GPU-Treiberinstallation

In diesem Abschnitt finden Sie Informationen zur Fehlerbehebung bei der automatischen Installation von NVIDIA-Gerätetreibern in GKE.

Treiberinstallation auf Ubuntu-Knoten schlägt fehl

Wenn Sie Ubuntu-Knoten mit angeschlossenen L4-, H100- oder H200-GPUs verwenden, ist der Standard-GPU-Treiber, den GKE installiert, möglicherweise nicht auf dem Stand der für diese GPUs erforderlichen Version oder höher. Infolgedessen bleibt der GPU-Geräte-Plug-in-Pod im Status „Ausstehend“ hängen und bei Ihren GPU-Arbeitslasten auf diesen Knoten treten möglicherweise Probleme auf.

Um dieses Problem für L4- und H100-GPUs zu beheben, empfehlen wir ein Upgrade auf die folgenden GKE-Versionen, in denen GPU-Treiberversion 535 als Standardtreiber installiert wird:

  • 1.26.15-gke.1483000 und höher
  • 1.27.15-gke.1039000 und höher
  • 1.28.11-gke.1044000 und höher
  • 1.29.6-gke.1073000 und höher
  • 1.30.2-gke.1124000 und höher

Alternativ können Sie die Treiberversion 535 oder höher manuell installieren. Führen Sie dazu den folgenden Befehl aus:

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

Um dieses Problem für H200-GPUs zu beheben, müssen Sie die Treiberversion 550 oder höher manuell installieren. Führen Sie dazu den folgenden Befehl aus:

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

GPU-Geräte-Plug-ins schlagen mit CrashLoopBackOff-Fehlern fehl

Das folgende Problem tritt auf, wenn Sie die manuelle Treiberinstallationsmethode in Ihrem Knotenpool vor dem 25. Januar 2023 verwendet haben und Ihren Knotenpool später auf eine GKE-Version aktualisiert haben, die automatische Treiberinstallation unterstützt. Beide Installationsarbeitslasten sind gleichzeitig vorhanden und versuchen, inkompatible Treiberversionen auf Ihren Knoten zu installieren.

Der Init-Container des GPU-Geräte-Plug-ins schlägt mit dem Status Init:CrashLoopBackOff fehl. Die Logs für den Container sehen in etwa so aus:

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

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Entfernen Sie das DaemonSet für die manuelle Treiberinstallation aus Ihrem Cluster. Dadurch wird die in Konflikt stehende Installationsarbeitslast gelöscht und GKE kann automatisch einen Treiber auf Ihren Knoten installieren.

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

  • Wenden Sie das DaemonSet-Manifest für die manuelle Treiberinstallation noch einmal auf Ihren Cluster an. Am 25. Januar 2023 haben wir das Manifest aktualisiert, damit Knoten mit automatischer Treiberinstallation ignoriert werden.

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

  • Deaktivieren Sie die automatische Treiberinstallation für Ihren Knotenpool. Die vorhandene DaemonSet-Treiberinstallation sollte nach dem Aktualisierungsvorgang wie erwartet funktionieren.

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

    Ersetzen Sie Folgendes:

    • POOL_NAME ist der Name des Knotenpools.
    • GPU_TYPE: der GPU-Typ, den der Knotenpool bereits verwendet.
    • GPU_COUNT: die Anzahl der GPUs, die bereits an den Knotenpool angehängt sind.
    • CLUSTER_NAME: der Name des GKE-Clusters, der den Knotenpool enthält.
    • LOCATION: der Compute Engine-Standort des Clusters.

Fehler: „Container image cos-nvidia-installer:fixed is not present with pull policy of Never.“ oder „Container image ubuntu-nvidia-installer:fixed is not present with pull policy of Never.“

Dieses Problem tritt auf, wenn sich die nvidia-driver-installer-Pods im Status PodInitializing befinden und die GPU-Plug-in-Geräte- oder GPU-Treiberinstallations-Pods den folgenden Fehler melden. Die genaue Fehlermeldung hängt vom Betriebssystem ab, das auf Ihrem Knoten ausgeführt wird:

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.

Dieses Problem kann auftreten, wenn die automatische Speicherbereinigung das vorab geladene NVIDIA-Treiber-Image entfernt, um Speicherplatz auf einem Knoten freizugeben. Wenn der Treiber-Pod neu erstellt oder sein Container neu gestartet wird, kann GKE das vorab geladene Image nicht finden.

Wenn Sie COS verwenden, aktualisieren Sie Ihre GKE-Knoten auf eine der folgenden Versionen, die die Korrektur enthalten, um das Problem mit der Garbage Collection zu beheben:

  • 1.25.15-gke.1040000 und höher
  • 1.26.10-gke.1030000 und höher
  • 1.27.6-gke.1513000 und höher
  • 1.28.3-gke.1061000 und höher

Wenn auf Ihren Knoten Ubuntu ausgeführt wird, ist für dieses Problem mit der Garbage Collection noch keine Lösung verfügbar. Um dieses Problem unter Ubuntu zu beheben, können Sie einen privilegierten Container ausführen, der mit dem Host interagiert, um die korrekte Einrichtung der NVIDIA-GPU-Treiber zu gewährleisten. Führen Sie dazu sudo /usr/local/bin/nvidia-container-first-boot auf Ihrem Knoten aus oder wenden Sie das folgende Manifest an:

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

Eine weitere mögliche Ursache für das Problem ist, dass die NVIDIA-Treiber-Images nach einem Knoten-Neustart oder einer Hostwartung verloren gehen. Dies kann auf vertraulichen Knoten oder Knoten mit GPUs auftreten, die sitzungsspezifischen lokalen SSD-Speicher verwenden. In diesem Fall lädt GKE die nvidia-installer-driver-Container-Images auf Knoten vor und verschiebt sie beim ersten Start von der Bootdisk auf die lokale SSD.

Verwenden Sie den folgenden Logfilter, um zu prüfen, ob ein Host-Wartungsereignis stattgefunden hat:

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

Aktualisieren Sie Ihre GKE-Version auf eine der folgenden Versionen, um das Problem mit der Hostwartung zu beheben:

  • 1.27.13-gke.1166000 und höher
  • 1.29.3-gke.1227000 und höher
  • 1.28.8-gke.1171000 und höher

Fehler: Konfiguration der Installationsverzeichnisse für GPU-Treiber fehlgeschlagen: lib64-Overlay konnte nicht erstellt werden: Verzeichnis konnte nicht erstellt werden /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: kein Verzeichnis.

Dieser Fehler tritt im GPU-Treiberinstallationscontainer innerhalb des GPU-Geräte-Plug-ins auf, wenn NCCL-Fastsocket aktiviert ist:

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.

Dieses Problem tritt nur bei Clustern und Knoten auf, auf denen GKE 1.28 und 1.29 ausgeführt wird.

Das Problem wird durch eine Race Condition von NCCL Fast Socket mit dem GPU-Treiber-Installer verursacht.

Aktualisieren Sie Ihre GKE-Version auf eine der folgenden Versionen, um dieses Problem zu beheben:

  • 1.28.8-gke.1206000 und höher
  • 1.29.3-gke.1344000 und höher

Weitere Informationen finden Sie in den Versionshinweisen zu GPUDirect-TCPXO.

Fehler: Gerät für nvidia0 konnte nicht abgerufen werden: Gerät nvidia0 nicht gefunden.

Der folgende Fehler gibt an, dass XID 62 und RmInitAdapter für die GPU mit der untergeordneten Nummer 0 fehlgeschlagen sind:

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

In der NVIDIA-Treiberversion 525.105.17 gibt es einen Fehler, der Kommunikationsfehler (XID) verursachen und die ordnungsgemäße Initialisierung der GPU verhindern kann.

Aktualisieren Sie den NVIDIA-Treiber auf die Treiberversion 525.110.11 oder höher, um dieses Problem zu beheben.

GPUs auf A3-VMs zurücksetzen

Bei einigen Problemen müssen Sie möglicherweise die GPU auf einer A3-VM zurücksetzen.

So setzen Sie die GPU zurück:

  1. Entfernen Sie Pods, die GPU-Ressourcen anfordern, von dem Knoten, auf dem Sie die GPU zurücksetzen müssen.

  2. Deaktivieren Sie das GPU-Geräte-Plug-in auf dem Knoten:

    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

    Ersetzen Sie NODE_NAME durch den Namen des Knotens.

  3. Stellen Sie eine Verbindung zur VM her, die den Knoten unterstützt.

  4. Setzen Sie die GPU in der SSH-Sitzung zurück:

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

  5. Aktivieren Sie das GPU-Geräte-Plug-in wieder:

    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

GPUs auf Confidential GKE Nodes

In den folgenden Abschnitten wird beschrieben, wie Sie Probleme mit GPUs, die auf Confidential GKE Nodes ausgeführt werden, erkennen und beheben.

GPU-Arbeitslasten werden nicht auf Confidential GKE Nodes geplant

Für Confidential GKE Nodes müssen Sie manuell einen GPU-Treiber installieren, der dem ausgewählten GPU-Typ und Ihrer GKE-Version entspricht. Wenn Ihre GPU-Pods nicht auf Confidential GKE-Knoten geplant werden und im Status Pending verbleiben, beschreiben Sie das DaemonSet für die Treiberinstallation:

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

Wenn in der Ausgabe ein NotFound-Fehler zurückgegeben wird, installieren Sie den Treiber.

Wenn das DaemonSet ausgeführt wird, sieht die Ausgabe in etwa so aus:

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

Prüfen Sie in dieser Ausgabe, ob das Feld nodeAffinity den Schlüssel cloud.google.com/gke-confidential-nodes-instance-type enthält. Wenn die Ausgabe diesen Schlüssel nicht enthält, unterstützt das DaemonSet für die Treiberinstallation keine vertraulichen GKE-Knoten.

Stellen Sie das DaemonSet bereit, das GPUs auf Confidential GKE Nodes unterstützt:

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

Prüfen Sie nach der Installation der Treiber, ob Ihre GPU-Arbeitslasten erfolgreich gestartet werden.

Fehler: Gerätevektor konnte nicht zugewiesen werden

Die folgende Fehlermeldung in Ihren GPU-Containerlogs weist darauf hin, dass die GPU von der Knoten-VM-Instanz getrennt wurde:

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

Das kann an einem Hardwarefehler oder an einem Problem mit den Verschlüsselungsschlüsseln liegen.

Starten Sie die Knoteninstanz neu, um dieses Problem zu beheben. Dieser Vorgang ist störend und wirkt sich auf alle Arbeitslasten auf diesem Knoten aus. So starten Sie die Instanz neu:

  1. Rufen Sie den Namen des Knotens ab, auf dem der GPU-Pod ausgeführt wird:

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

    Ersetzen Sie POD_NAME durch den Namen des fehlerhaften Pods.

    Die Ausgabe sieht etwa so aus:

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

  2. Setzen Sie die Compute Engine-Instanz zurück:

    gcloud compute instances reset NODE_NAME

    Ersetzen Sie NODE_NAME durch den Knotennamen aus der Ausgabe des vorherigen Schritts.

    Die gcloud CLI sucht in Ihrem aktiven Projekt nach VMs mit diesem Namen. Wenn Sie aufgefordert werden, eine Zone auszuwählen, geben Sie Y an.

  3. Prüfen Sie, ob Ihre GPU-Arbeitslasten fehlerfrei ausgeführt werden.

Fehler: Entschlüsselung fehlgeschlagen mit Fehler -74

Die folgende Fehlermeldung in Ihren Knotenlogs weist darauf hin, dass die Verschlüsselungsschlüssel für die GPU verloren gegangen sind:

Decryption failed with error -74

Dieser Fehler tritt auf, wenn der NVIDIA-Daemon für die Persistenz, der auf der Knoten-VM-Instanz ausgeführt wird, fehlschlägt. Wenn diese Fehlermeldung angezeigt wird, setzen Sie die Instanz zurück:

gcloud compute instances reset NODE_NAME

Ersetzen Sie NODE_NAME durch den Namen des fehlerhaften Knotens.

Die gcloud CLI sucht in Ihrem aktiven Projekt nach VMs mit diesem Namen. Wenn Sie aufgefordert werden, eine Zone auszuwählen, geben Sie Y an.

Wenn das Problem durch das Zurücksetzen der Instanz nicht behoben wird, wenden Sie sich an Cloud Customer Care oder reichen Sie einen Produktfehler ein. Weitere Informationen

XID-Fehler finden

Das gpu-device-plugin-DaemonSet wird im Namespace kube-system ausgeführt und ist für Folgendes verantwortlich:

  • Planung von GPU-Arbeitslasten:Zuweisen von GPU-Ressourcen zu Pods.
  • GPU-Systemdiagnose:Überwachen Sie den Zustand Ihrer GPUs.
  • Erfassung von GPU-Messwerten:Erfassung von GPU-bezogenen Messwerten wie Arbeitszyklus und Speichernutzung.

Der gpu-device-plugin verwendet die NVIDIA Management Library (NVML), um XID-Fehler zu erkennen. Wenn ein XID-Fehler auftritt, wird der Fehler im gpu-device-plugin-Pod protokolliert, der auf dem betroffenen Knoten ausgeführt wird. Es gibt zwei Arten von XID-Fehlerprotokollen:

  • Nicht kritische XID-Fehler:
    • Logformat: Skip error Xid=%d as it is not Xid Critical
    • Bedeutung: Diese Fehler werden als nicht kritisch eingestuft. Sie können durch verschiedene Software- oder Hardwareprobleme verursacht werden.
    • Maßnahme: Bei nicht kritischen XID-Fehlern werden in GKE keine automatischen Maßnahmen ergriffen.
  • Kritische XID-Fehler:
    • Logformat: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Bedeutung: Diese Fehler weisen auf ein Problem mit der GPU-Hardware hin.
    • Aktion:
      • GKE markiert die GPU-Ressourcen des Knotens als fehlerhaft.
      • GKE verhindert, dass GPU-Arbeitslasten auf dem Knoten geplant werden.
      • Wenn die automatische Knotenreparatur aktiviert ist, erstellt GKE den Knoten neu.

Probleme mit GPUDirect-TCPX(O)

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei Problemen mit GPUDirect-TCPX(O).

Versionshinweise und Upgradeanleitung

Neue Nutzer finden unter GPU-Netzwerkbandbreite in Standardclustern maximieren eine Anleitung zur Verwendung von GPUDirect-TCPX(O). Bestehende Nutzer finden Versionsinformationen und Upgrade-Anleitungen in den GPUDirect-TCPXO-Versionshinweisen, da kontinuierlich neue Versionen veröffentlicht werden.

Fehlerbehebung mit NCCL-Logs

Wenn Sie ein Problem mit NCCL nicht beheben können, erfassen Sie NCCL-Logs mit Fehlerbehebungsinformationen. Diese Logs enthalten wertvolle Informationen zu NCCL-Vorgängen und können Ihnen helfen, die Ursache Ihres Problems zu finden. Wenn Sie das Problem nicht beheben können, sammeln Sie diese Protokolle bevor Sie einen Fall beim Cloud Customer Care eröffnen. Diese Logs können Cloud Customer Care helfen, Ihr Problem schneller zu beheben.

Führen Sie die folgenden Schritte aus, um die Logs zu generieren und zu erfassen:

  1. Legen Sie die folgenden Umgebungsvariablen in Ihrem Pod- oder Anwendungsmanifest fest:

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

    Weitere Informationen zu diesen Umgebungsvariablen finden Sie unter NCCL-Debugging-Logs erfassen.

  2. Führen Sie einen NCCL-Test aus, um Daten für Ihre Logs zu generieren. Die Ausführung dieses Tests hängt vom verwendeten Clustertyp ab. Bei GKE-Clustern können Sie NCCL-Tests mit Topology Aware Scheduling (TAS) bereitstellen und ausführen. Nachdem Sie den NCCL-Test ausgeführt haben, werden die Logs automatisch auf allen beteiligten Knoten generiert.

  3. Erfassen Sie die Logs von allen Knoten. Prüfen Sie, ob Sie NCCL-Logs von allen Knoten erfasst haben, indem Sie prüfen, ob die Logs die folgenden Informationen enthalten:

    • Die Hostnamen aller VMs, die an einer Arbeitslast beteiligt sind.
    • Die PIDs aller relevanten Prozesse auf der VM.
    • Die Ränge aller GPUs, die von der Arbeitslast auf jeder VM verwendet werden.

    Wenn Sie nicht sicher sind, wo sich die Logdateien befinden, sehen Sie sich das folgende Beispiel an. Dort wird gezeigt, wo NCCL die Logdateien erstellt, wenn die Variable NCCL_DEBUG_FILE auf /tmp/nccl_log.%h.%p gesetzt ist. Sie haben zwei VMs mit den Namen a3plus-vm-1 und a3plus-vm-2 und auf jeder VM werden acht Prozesse im Arbeitslastcontainer ausgeführt. In diesem Szenario erstellt NCCL die folgenden Logdateien im Verzeichnis /tmp im Arbeitslastcontainer auf jeder VM:

    • Auf a3plus-vm-1: acht Logdateien mit dem Namen nccl_log.a3plus-vm-1.PID, wobei PID die Prozess-ID ist.
    • Auf a3plus-vm-2: acht Logdateien mit dem Namen nccl_log.a3plus-vm-2.PID.

  4. Prüfen Sie die Logs. NCCL-Logeinträge haben das folgende Format:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    Diese Logeinträge enthalten die folgenden Werte:

    • HOSTNAME: der Hostname der VM. Dieser Wert gibt an, welche VM verwendet wurde, als NCCL den Logeintrag generiert hat.
    • PID: die PID. Dieser Wert gibt an, welcher Prozess den Logeintrag generiert hat.
    • TID: die Thread-ID. Dieser Wert gibt an, welcher Thread im Prozess verwendet wurde, als NCCL den Logeintrag generiert hat.
    • RANK: die ID des lokalen Rangs. Dieser Wert gibt an, welche GPU verwendet wurde, als NCCL den Logeintrag generiert hat. Die Ränge sind von 0 bis N nummeriert, wobei N die Gesamtzahl der GPUs ist, die an dem Prozess beteiligt sind. Wenn Ihre Arbeitslast beispielsweise mit acht GPUs pro VM ausgeführt wird, sollte jede VM acht verschiedene Rangwerte (0–7) haben.
    • NCCL_MESSAGE: Eine beschreibende Meldung, die weitere Informationen zum Ereignis enthält, einschließlich des Zeitstempels, wann NCCL das Log erstellt hat.

    Beispiel:

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

    In diesem Beispiel werden die folgenden Werte verwendet:

    • gke-a3plus-mega-np-2-aa33fe53-7wvq: der Hostname.
    • 1581: die Prozess-ID.
    • 1634: die Thread-ID.
    • 1: die ID des lokalen Rangs.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: Die Meldung, in der erklärt wird, was passiert ist.

  5. Wenn Sie einen Supportfall eröffnen, packen Sie die gesammelten Logs zusammen mit der Ausgabe des NCCL-Tests in eine ZIP-Datei. Fügen Sie die ZIP-Datei ein, wenn Sie eine Supportanfrage an Cloud Customer Care senden.

  6. Wenn Sie die Erfassung von NCCL-Debugging-Logs beenden möchten, entfernen Sie die Variablen, die Sie in Schritt 1 hinzugefügt haben.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen: