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 fehlgeschlagen

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. Daher bleibt der Pod des GPU-Geräte-Plug-ins im Status „Ausstehend“ und es kann zu Problemen mit Ihren GPU-Arbeitslasten auf diesen Knoten kommen.

Um dieses Problem für L4- und H100-GPUs zu beheben, empfehlen wir ein Upgrade auf die folgenden GKE-Versionen, bei denen die 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 Installationslasten sind gleichzeitig vorhanden und versuchen, in Konflikt stehende 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 ist mit der Pull-Richtlinie ‚Nie‘ nicht vorhanden“ oder „Container-Image ubuntu-nvidia-installer:fixed ist mit der Pull-Richtlinie ‚Nie‘ nicht vorhanden“

Dieses Problem tritt auf, wenn sich die nvidia-driver-installer-Pods im Status PodInitializing befinden und das GPU-Plug-in-Gerät oder die 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 der Garbage Collector 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.

Um das Problem mit der Garbage Collection bei der Ausführung von COS zu beheben, aktualisieren Sie Ihre GKE-Knoten auf eine der folgenden Versionen, die die Korrektur enthalten:

  • 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 vermeiden, 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 dem Neustart des Knotens oder der Hostwartung verloren gehen. Dies kann bei 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 die Knoten vor und verschiebt sie beim ersten Start vom Bootlaufwerk auf die lokale SSD.

Verwenden Sie den folgenden Protokollfilter, um zu prüfen, ob ein Hostwartungsereignis aufgetreten ist:

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 bei 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 wird vom Container des GPU-Treiberinstallationsprogramms im GPU-Geräte-Plug-in ausgegeben, 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-Bedingung von NCCL Fast Socket mit dem GPU-Treiber-Installationsprogramm 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 nicht gefunden: Gerät nvidia0 nicht gefunden.

Der folgende Fehler gibt an, dass XID 62 und RmInitAdapter für die GPU mit Minor 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 zu Kommunikationsfehlern (XID) führen und die ordnungsgemäße Initialisierung der GPU verhindern kann.

Aktualisieren Sie den NVIDIA-Treiber auf Version 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, vom 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 in der SSH-Sitzung die GPU 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 erfahren Sie, wie Sie Probleme mit GPUs identifizieren und beheben, die auf vertraulichen GKE-Knoten ausgeführt werden.

GPU-Arbeitslasten werden nicht auf Confidential GKE Nodes geplant

Für Confidential GKE Nodes müssen Sie einen GPU-Treiber manuell installieren, der dem ausgewählten GPU-Typ und der GKE-Version entspricht. Wenn Ihre GPU-Pods nicht auf vertraulichen GKE-Knoten geplant werden und im Status Pending bleiben, 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 ausgegeben 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.

Binden Sie das DaemonSet ein, 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 gestartet werden.

Fehler: Gerätevektor konnte nicht zugewiesen werden

Die folgende Fehlermeldung in Ihren GPU-Container-Protokollen weist darauf hin, dass die GPU von der VM-Instanz des Knotens getrennt wurde:

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

Dies kann auf einen Hardwarefehler oder ein Problem mit den Verschlüsselungsschlüsseln zurückzuführen sein.

Starten Sie die Knoteninstanz neu, um das 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. So 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 ein.

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

Fehler: Entschlüsselung fehlgeschlagen mit Fehler -74

Die folgende Fehlermeldung in Ihren Knotenprotokollen gibt an, dass die Verschlüsselungsschlüssel für die GPU verloren gegangen sind:

Decryption failed with error -74

Dieser Fehler tritt auf, wenn der NVIDIA-Persistenz-Daemon, der auf der VM-Instanz des Knotens 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 ein.

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

XID-Fehler finden

Der gpu-device-plugin-Daemon-Set wird im Namespace kube-system ausgeführt und ist für Folgendes verantwortlich:

  • GPU-Arbeitslastplanung: Zuweisung von GPU-Ressourcen zu Pods.
  • GPU-Statusprüfung:Überwachung des Zustands Ihrer GPUs.
  • Erfassen von GPU-Messwerten:Erfassen 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 er vom 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.
    • Aktion: Bei nicht kritischen XID-Fehlern ergreift GKE keine automatischen Maßnahmen.
  • Kritische XID-Fehler:
    • Logformat: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Bedeutung: Diese Fehler weisen auf ein GPU-Hardwareproblem 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 GPUDirect-TCPX(O)-Problemen.

Versionshinweise und Upgradeanleitung

Für neue Nutzer finden Sie unter GPU-Netzwerkbandbreite in Clustern im Standardmodus maximieren eine Anleitung zur Verwendung von GPUDirect-TCPX(O). Bestehende Nutzer finden in den GPUDirect-TCPXO-Release Notes Informationen zur Version und eine Anleitung zum Upgrade, da ständig neue Versionen veröffentlicht werden.

Mit NCCL-Protokollen debuggen

Wenn Sie ein Problem mit NCCL nicht beheben können, erfassen Sie NCCL-Protokolle mit Informationen zur Fehlerbehebung. Diese Protokolle enthalten wertvolle Informationen zu NCCL-Vorgängen und können Ihnen helfen, die Ursache des Problems zu finden. Wenn Sie das Problem nicht beheben können, erfassen Sie diese Protokolle bevor Sie eine Anfrage beim Cloud Customer Care stellen. Anhand dieser Logs kann der Cloud Customer Care Ihr Problem schneller lösen.

So generieren und erfassen Sie die Protokolle:

  1. Legen Sie die folgenden Umgebungsvariablen im 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-Protokolle erfassen.

  2. Führen Sie einen NCCL-Test aus, um Daten für Ihre Protokolle 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. Nach dem Ausführen des NCCL-Tests generiert NCCL automatisch die Protokolle auf allen teilnehmenden Knoten.

  3. Erfassen Sie die Protokolle von allen Knoten. Prüfen Sie, ob Sie NCCL-Protokolle von allen Knoten erfasst haben. Die Protokolle müssen 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 Protokolldateien befinden, sehen Sie sich das folgende Beispiel an. Dort wird gezeigt, wo NCCL die Protokolldateien erstellt, wenn die Variable NCCL_DEBUG_FILE auf /tmp/nccl_log.%h.%p festgelegt ist. Sie haben zwei VMs mit den Namen a3plus-vm-1 und a3plus-vm-2. Auf jeder VM werden acht Prozesse innerhalb des Arbeitslastcontainers ausgeführt. In diesem Szenario erstellt NCCL die folgenden Protokolldateien 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 Protokolle. NCCL-Logeinträge haben folgendes 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 innerhalb des Prozesses verwendet wurde, als NCCL den Logeintrag generierte.
    • RANK: die ID des lokalen Rankings. 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 am 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 Nachricht mit weiteren Informationen zum Ereignis, einschließlich des Zeitstempels, zu dem NCCL das Protokoll 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: den Hostnamen.
    • 1581: die Prozess-ID.
    • 1634: die Thread-ID.
    • 1: die ID des lokalen Rankings.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: die Nachricht, in der erklärt wird, was passiert ist.

  5. Wenn Sie einen Supportfall eröffnen, verpacken Sie die erfassten Protokolle zusammen mit der Ausgabe des NCCL-Tests in einer ZIP-Datei. Fügen Sie die ZIP-Datei hinzu, wenn Sie eine Supportanfrage an Cloud Customer Care senden.

  6. Wenn Sie das Erfassen von NCCL-Fehlerbehebungsprotokollen 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 Hilfeartikel Support anfordern. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen: