Fehlerbehebung bei GPUs in GKE

Wenn Ihre Google Kubernetes Engine-Pods (GKE) im Status Pending hängen bleiben, während sie nvidia.com/gpu-Ressourcen anfordern, oder wenn Ihre Knoten ihre verfügbaren GPUs nicht registrieren können, liegt möglicherweise ein Problem mit der NVIDIA-Treiberinstallation oder der Knotenpoolkonfiguration vor. Diese Probleme verhindern, dass Ihre Arbeitslasten auf die erforderliche GPU-Hardware zugreifen können.

In diesem Dokument wird beschrieben, wie Sie häufige Probleme diagnostizieren und beheben, die verhindern, dass GKE GPU-beschleunigte Arbeitslasten plant oder ausführt. Hier erfahren Sie, wie Sie die Installation des GPU-Treibers prüfen, Pod- und Knotenlogs auf Fehler untersuchen und die Richtigkeit Ihrer Konfigurationen bestätigen.

Diese Informationen richten sich an Plattformadministratoren und -operatoren, die GPU-fähige Knotenpools verwalten und NVIDIA-Treiberprobleme beheben müssen, sowie an Anwendungsentwickler, die GPU-Arbeitslasten debuggen müssen, die hängen bleiben oder nicht gestartet werden können. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

GPU-Treiberinstallation

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei der automatischen Installation von NVIDIA-Gerätetreibern in GKE.

Treiberinstallation schlägt auf Ubuntu-Knoten fehl

Wenn Sie Ubuntu-Knoten mit angeschlossenen L4-, RTX PRO 6000-, 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“ hängen und es kann zu Problemen mit Ihren GPU-Arbeitslasten auf diesen Knoten kommen.

Anleitungen zur Behebung dieses Problems finden Sie in den Anleitungen für die jeweilige GPU:

L4 und H100

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

  • 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

RTX PRO 6000

Aktualisieren Sie auf eine der folgenden GKE-Versionen, um dieses Problem für RTX PRO 6000-GPUs zu beheben. In diesen Versionen wird die GPU-Treiberversion 580 als Standardtreiber installiert:

  • 1.32.8-gke.1170000 und höher
  • 1.33.4-gke.1245000 und höher
  • 1.34.0-gke.1662000 und höher

Diese Lösung funktioniert nur für G4-Maschinentypen mit einer oder mehreren GPUs. G4-Maschinentypen mit weniger als einer GPU unterstützen keine Ubuntu-Knoten-Images.

H200

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, 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, um Knoten zu ignorieren, die die automatische Treiberinstallation verwenden.

    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.

Weitere Informationen zum Zuordnen der GPU-Treiberversion zur GKE-Version finden Sie unter GKE-Version und Container-Optimized OS-Knoten-Image-Version der GPU-Treiberversion zuordnen.

Fehler: „Container-Image cos-nvidia-installer:fixed ist mit der Pull-Richtlinie ‚Never‘ nicht vorhanden.“ oder „Container-Image ubuntu-nvidia-installer:fixed ist mit der Pull-Richtlinie ‚Never‘ 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 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 ausführen, können Sie das Problem mit der automatischen Speicherbereinigung beheben, indem Sie Ihre GKE-Knoten auf eine der folgenden Versionen aktualisieren, 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

Weitere Informationen zum Zuordnen der GPU-Treiberversion zur GKE-Version finden Sie unter GKE-Version und Container-Optimized OS-Knoten-Image-Version der GPU-Treiberversion zuordnen.

Wenn auf Ihren Knoten Ubuntu ausgeführt wird, ist für dieses Problem mit der automatischen Speicherbereinigung 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, wenn die NVIDIA-Treiber-Images nach einem Neustart des Knotens oder einer Hostwartung verloren gehen. Dies kann auf Confidential Nodes 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 vom Bootlaufwerk auf die lokale SSD.

Verwenden Sie den folgenden Logfilter, 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 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-Treiber-Installationscontainer im GPU-Geräte-Plug-in 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 mit GKE 1.28 und 1.29 auf.

Das Problem wird durch eine NCCL-Fastsocket-Race-Bedingung 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 konnte nicht abgerufen werden: Gerät nvidia0 nicht gefunden.

Der folgende Fehler weist darauf hin, dass XID 62 und RmInitAdapter für die GPU mit Minor 0 fehlgeschlagen sind:

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

Die NVIDIA-Treiberversion 525.105.17 enthält einen Fehler, der zu Kommunikationsfehlern (XID) führen und die ordnungsgemäße Initialisierung der GPU verhindern kann. Dies führt dazu, dass die GPU nicht initialisiert werden kann.

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

GPUDirect RDMA-Probleme

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei GPUDirect RDMA-Problemen.

Fehler: Das Netzwerk-gIB-Plug-in wurde nicht gefunden

Das pytorch/pytorch:latest-Image aus dem PyTorch-Repository enthält nicht die Netlink Library Protocol Suite (libnl), die für das gIB-Plug-in erforderlich ist. Der folgende Fehler weist darauf hin, dass das gIB-Plug-in nicht geladen wurde, weil die libnl-Bibliotheken im Image fehlen:

ncclInvalidUsage: Error: network gIB not found.

Um dieses Problem zu beheben, müssen Sie ein anderes PyTorch-Basis-Image verwenden oder die Bibliotheken manuell zu Ihren Containern hinzufügen. Das Problem ist nicht auf einen bestimmten Maschinentyp beschränkt. Weitere Informationen zur Verwendung von NCCL/gIB finden Sie unter Cluster-Netzwerke mithilfe von NCCL/gIB optimieren.

Problem mit dem Nvidia PyTorch-Image beheben

Sie können dieses Problem beheben, indem Sie das NVIDIA PyTorch-Image verwenden. Die aktuelle Version finden Sie in den PyTorch-Versionshinweisen.

Problem durch manuelle Installation beheben

Wenn Sie nicht zu einer anderen Image-Basis migrieren können, können Sie die libnl-Bibliotheken auch manuell im Container-Image installieren.

apt update -y && apt upgrade -y && apt install -y libnl-3-200 libnl-route-3-200

Um die Konsistenz der IBVerbs-Bibliothek im Arbeitslastcontainer zu gewährleisten, verwenden Sie das aktualisierte NCCL RDMA Installer DaemonSet, um die gIB-Plug-in-Bibliotheken im Containerpfad zu installieren.

Klonen Sie das Repository für Container Engine-Beschleuniger, um die DaemonSet-Konfiguration herunterzuladen:

cd
git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.git

Die Konfiguration finden Sie im Verzeichnis 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

Wählen Sie eine der folgenden Installationskonfigurationen aus:

Beschreibung nccl-rdma-installer.yaml nccl-rdma-installer-a4x.yaml nccl-rdma-installer-autopilot.yaml
GKE-Betriebsmodus GKE Standard GKE Standard GKE Autopilot
Maschinentypen A4- und A3 Ultra-Maschinentypen A4X-Maschinentyp A4- und A3 Ultra-Maschinentypen
Namespace Wird in kube-system bereitgestellt. Wird in kube-system bereitgestellt. Wird in einem dedizierten rdma-system-Namespace bereitgestellt, da Autopilot Änderungen am kube-system-Namespace einschränkt.
Prioritätsklasse Verwendet system-node-critical, damit das Installationsprogramm mit hoher Priorität ausgeführt wird. Verwendet system-node-critical. Keine. (Autopilot schränkt die Verwendung von Prioritätsklassen auf Systemebene ein.)
Funktion Wird als DaemonSet ausgeführt und installiert das GPUDirect-TCPX (GIB) NCCL-Plug-in (insbesondere nccl-plugin-gib:v1.1.1) in den Hostverzeichnissen /home/kubernetes/bin/nvidia/lib64 und /home/kubernetes/bin/gib. Dieser Ansatz ermöglicht eine leistungsstarke RDMA-Kommunikation für NCCL auf GKE-Knoten. Ähnlich wie das Basisinstallationsprogramm, installiert jedoch die ARM64-kompilierte Version des GPUDirect-TCPX (GIB) NCCL-Plug-ins (nccl-plugin-gib-arm64:v1.1.0). Enthält auch eine spezifische Knotenaffinität für nvidia-gb200 und arm64, damit es nur auf diesen spezifischen GKE-Knoten ausgeführt wird. Installiert das GPUDirect-TCPX (GIB) NCCL-Plug-in (nccl-plugin-gib:v1.1.1), jedoch mit Änderungen, die das Sicherheits- und Betriebsmodell des Autopilot-Modus unterstützen:
  • Sie wird im Namespace rdma-system bereitgestellt.
  • Das Installationsskript wird mit dem Flag --install-nccl aufgerufen, das zusätzliche Einrichtungsschritte ausführt, um sicherzustellen, dass NCCL in der Autopilot-Umgebung ordnungsgemäß konfiguriert oder installiert ist. In GKE Autopilot ist die Hostumgebung möglicherweise stärker eingeschränkt oder anders vorkonfiguriert als in GKE Standard.

Wenden Sie das DaemonSet an:

kubectl apply -f nccl-rdma-installer.yaml

GKE-Version und Container-Optimized OS-Knoten-Image-Version der GPU-Treiberversion zuordnen

So finden Sie die GPU-Treiberversionen, die den GKE-Versionen und den Container-Optimized OS-Knoten-Image-Versionen zugeordnet sind:
  1. Ordnen Sie Container-Optimized OS-Knoten-Image-Versionen GKE-Patchversionen zu, um die GPU-Treiberversion für die gewünschte GKE-Version zu finden. Beispiel: 1.33.0-gke.1552000 verwendet cos-121-18867-90-4.
  2. Wählen Sie den Meilenstein der Container-Optimized OS-Knoten-Image-Version in den Versionshinweisen zu Container-Optimized OS aus. Wählen Sie beispielsweise Milestone 121 für cos-121-18867-90-4 aus.
  3. Suchen Sie auf der Seite mit den Versionshinweisen für den jeweiligen Meilenstein nach den Versionshinweisen für die jeweilige Container-Optimized OS-Knoten-Image-Version. Beispiel: cos-121-18867-90-4 in den Versionshinweisen zu Container-Optimized OS: Meilenstein 121. Klicken Sie in der Tabelle in der Spalte GPU-Treiber auf Liste ansehen, um die Informationen zur GPU-Treiberversion aufzurufen.

In GKE-Version 1.36.0-gke.3302004 und höher veröffentlicht GKE die installierte NVIDIA-Treiberversion automatisch als Annotationen auf laufenden GPU-Knoten. Führen Sie den folgenden Befehl aus, um die Annotationen der Treiberversion auf einem GPU-Knoten aufzurufen:

kubectl get node GPU_NODE_NAME -o jsonpath='{.metadata.annotations}'

Ersetzen Sie GPU_NODE_NAME durch den Namen Ihres GPU-Knotens.

Die Ausgabe enthält Annotationen ähnlich der folgenden:

{
  "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"
}

Der Befehl nvidia-smi schlägt fehl

Wenn Sie GPU-VMs zum Ausführen von Arbeitslasten in GKE verwenden, können Befehle wie nvidia-smi im Container mit einem der folgenden Fehler fehlschlagen:

  • bash: nvidia-smi: command not found
  • Fehler, die darauf hinweisen, dass libnvidia-ml.so oder andere NVIDIA-Bibliotheken nicht gefunden werden können.

Die GKE stellt die erforderlichen NVIDIA-Treiber und -Tools vom Hostknoten in Ihren Containern bereit, in der Regel unter dem Pfad /usr/local/nvidia/. Die Standardumgebungsvariablen des Containers (PATH und LD_LIBRARY_PATH) enthalten jedoch möglicherweise nicht die Pfade zu diesen NVIDIA-Binärdateien und -Bibliotheken.

Aktualisieren Sie zur Behebung dieser Fehler Ihr Pod- oder Deployment-Manifest, um die erforderlichen NVIDIA-Pfade in den Umgebungsvariablen PATH und LD_LIBRARY_PATH für den Container einzufügen.

Fügen Sie Ihrer spec.template.spec.containers-Spezifikation beispielsweise den folgenden env-Block hinzu:

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

Neustart des Gastbetriebssystems für Standardcluster

In diesem Abschnitt wird gezeigt, wie Sie mit der GKE den Neustart des Gastbetriebssystems verwalten, das auf dem Knoten für Standardcluster ausgeführt wird.

Ein GKE-Knoten muss möglicherweise neu gestartet werden, wenn Xid- oder andere GPU-Probleme auftreten. Beispiele für Xid-Probleme finden Sie unter Compute Engine-Xid-Verarbeitung.

Wenn Sie das Gastbetriebssystem mit dieser Methode neu starten, geschieht Folgendes:

  • Das Gastbetriebssystem wird zurückgesetzt.
  • Die GPU wird zurückgesetzt.
  • Die zugrunde liegende Instanz wird nicht geändert und das Bootlaufwerk bleibt erhalten. Nach dem Neustart ist die Boot-ID jedoch anders.

Der Neustart dauert etwa fünf Minuten. Diese Zeit wird zusätzlich zum Kulanzzeitraum für die Beendigung, der für die Pods konfiguriert ist, hinzugefügt. Weitere Informationen zum Pod-Lebenszyklus und zum Beendigungszeitraum finden Sie unter Beendigung von Pods.

Voraussetzungen

Für diese Methode zum Neustart des Gastbetriebssystems muss auf dem Cluster die GKE-Version 1.37.0-gke.3503000 oder höher ausgeführt werden. Lösen Sie bei früheren Versionen keinen Neustart des Gastbetriebssystems aus, da GKE nach dem Neustart möglicherweise keine Arbeitslasten auf Ihren Knoten planen kann.

Gastbetriebssystem auf einem GKE-Knoten neu starten

So starten Sie das Gastbetriebssystem auf einem GKE-Knoten neu:

  1. Identifizieren Sie den Knoten, der neu gestartet werden soll.

  2. Wenden Sie das Label cloud.google.com/perform-reboot=true mit dem folgenden Befehl an:

    kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true

    Ersetzen Sie NODE_NAME durch den Namen des Knotens.

    Wenn dieses Label angewendet wird, startet GKE das Gastbetriebssystem neu. Dazu werden die folgenden Schritte ausgeführt:

    1. Sperren Sie den Knoten.
    2. Entfernt Pods unter Berücksichtigung aller Verteilungsbudgets und des Kulanzzeitraums für die Beendigung. Weitere Informationen zum Konfigurieren dieses Beendigungsverhaltens finden Sie unter GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden.
    3. Startet den Knoten mit systemd neu. Der Knoten wird heruntergefahren und neu gestartet und die Boot-ID ändert sich.

  3. Rufen Sie die Knotenereignisse auf, um zu prüfen, ob der Knoten erfolgreich neu gestartet wurde.

    1. Rufen Sie in der Google Cloud -Console Kubernetes Engine > Cluster auf.

      Zu den Clustern

    2. Wählen Sie den Cluster aus, der den Knoten enthält, den Sie neu starten.

    3. Klicken Sie auf Knoten und wählen Sie den Knoten aus, den Sie neu starten möchten.

    4. Klicken Sie auf Ereignisse, um die Seite mit den Knotenereignissen aufzurufen.

      Auf dieser Seite werden Knotenereignisse aufgezeichnet. Ereignisse eines erfolgreichen Neustarts sind:

      • Wenn der Knoten nach dem Neustart hochfährt.
      • Wenn der Wartungshandler das Knotenlabel perform-reboot entfernt.
      • Wenn die Änderung der Boot-ID erkannt wird.

Wenn Sie diese Schritte für einen Knoten ausgeführt haben, auf dem eine Version vor 1.37.0-gke.3503000 ausgeführt wird, behält der Knoten nach dem Neustart möglicherweise sowohl die Markierung cloud.google.com/impending-node-termination als auch das Label cloud.google.com/perform-reboot=true bei. Der Knoten hat den Status Ready, kann aber keine Arbeitslasten ausführen. Führen Sie zur Behebung dieses Problems ein Upgrade auf die GKE-Version 1.37.0-gke.3503000 oder höher durch. Wenn Sie dieses Problem ohne Upgrade beheben möchten, entfernen Sie die Markierung und das Label manuell vom betroffenen Knoten. Führen Sie dazu die folgenden Befehle aus:

# 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-

Ersetzen Sie NODE_NAME durch den Namen des hängenden Knotens.

Warten Sie nach dem Entfernen des Status „Hängt“ mindestens 60 Sekunden, bis der Wartungshandler die Änderungen erkennt. Versuchen Sie nicht, das Gastbetriebssystem noch einmal neu zu starten, es sei denn, auf Ihrem Cluster wird Version 1.37.0-gke.3503000 oder höher ausgeführt.

Neustart-Label wird ignoriert, wenn es schnell wieder angewendet wird

Wenn Sie in allen GKE-Versionen das Label cloud.google.com/perform-reboot=true innerhalb von 60 Sekunden nach einem abgeschlossenen Neustart noch einmal anwenden, reagiert der Wartungs-Handler aufgrund einer Race-Bedingung in seinem internen Zustand möglicherweise nicht auf das neue Label. Der Knoten bleibt mit dem Label perform-reboot und der Markierung cloud.google.com/impending-node-termination hängen, es erfolgt jedoch kein Neustart.

Um dieses Problem zu beheben, warten Sie nach einem Neustart mindestens 60 Sekunden, bevor Sie das Label cloud.google.com/perform-reboot=true noch einmal anwenden. Sie können prüfen, ob der Neustart abgeschlossen wurde, indem Sie prüfen, ob das Label perform-reboot und die Annotation reboot-boot-id vom Knoten entfernt wurden:

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}'

Ersetzen Sie NODE_NAME durch den Namen des Knotens.

Beide Befehle sollten eine leere Ausgabe zurückgeben, bevor Sie das Label neu anwenden.

Wenn der Knoten bereits hängen geblieben ist, entfernen Sie die Kubernetes-Knotenmetadaten, die den hängenden Zustand verursachen, manuell:

  1. Entfernen Sie das Knotenlabel cloud.google.com/perform-reboot:

    kubectl label node NODE_NAME \
    cloud.google.com/perform-reboot-

    Ersetzen Sie NODE_NAME durch den Namen des hängenden Knotens.

  2. Entfernen Sie die Annotation node.gke.io/reboot-boot-id:

    kubectl annotate node NODE_NAME \
    node.gke.io/reboot-boot-id-

    Wenn die Ausgabe not found lautet, wurde die Annotation bereits entfernt.

  3. Entfernen Sie die Markierung cloud.google.com/impending-node-termination:NoSchedule:

    kubectl taint nodes NODE_NAME \
    cloud.google.com/impending-node-termination:NoSchedule-

    Wenn die Ausgabe not found lautet, wurde die Markierung bereits entfernt.

  4. Warte mindestens 60 Sekunden.

  5. Wenden Sie das Label cloud.google.com/perform-reboot noch einmal an:

    kubectl label node NODE_NAME \
    cloud.google.com/perform-reboot=true

GPUs auf A3- und A4-VMs zurücksetzen

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

Hinweis: Sie können auch das gpu-reset-tool verwenden, um alle GPUs zurückzusetzen. Dieses Tool automatisiert den Zurücksetzungsvorgang und erfordert nur den Namen des Zielknotens.

So setzen Sie die GPU manuell 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. Wenn Sie DCGM-Messwerte aktiviert haben, deaktivieren Sie den DCGM-Exporter auf dem Knoten vorübergehend, indem Sie das Treiberversionslabel ändern:

    a. Notieren Sie sich den aktuellen Wert des Labels cloud.google.com/gke-gpu-driver-version auf dem Knoten.

    b. Ändern Sie den Labelwert in reset, um den DCGM-Exporter-Pod zu entfernen:

      kubectl label node NODE_NAME \
      cloud.google.com/gke-gpu-driver-version=reset --overwrite

    Der Pod wird automatisch entfernt, da das Label default oder latest sein muss.

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

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

    Alle GPUs auf der VM zurücksetzen

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

    So setzen Sie eine bestimmte GPU zurück:

    # 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>

  6. Stellen Sie die Knotenlabels wieder her, um das GPU-Geräte-Plug-in und den DCGM-Exporter wieder zu aktivieren:

    a. 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

    b. Stellen Sie den ursprünglichen Wert des Labels cloud.google.com/gke-gpu-driver-version wieder her (z. B. latest oder default), um den DCGM-Exporter wieder zu aktivieren:

      kubectl label node NODE_NAME \
      cloud.google.com/gke-gpu-driver-version=ORIGINAL_VALUE --overwrite

GPUs auf Confidential GKE Nodes

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

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 der GKE-Version entspricht. Wenn Ihre GPU-Pods nicht auf Confidential GKE Nodes 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 die Ausgabe einen NotFound-Fehler zurückgibt, 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 Confidential GKE Nodes.

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)!

Dies kann aufgrund eines Hardwarefehlers oder eines Problems mit den Verschlüsselungsschlüsseln passieren.

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-Persistenz-Daemon, 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 melden Sie einen Produktfehler. Weitere Informationen finden Sie unter Support erhalten.

XID-Fehler finden

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

  • GPU-Arbeitslastplanung: GPU-Ressourcen werden Pods zugewiesen.
  • GPU-Systemdiagnose: Überwachung des Zustands 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 vom gpu-device-plugin-Pod, der auf dem betroffenen Knoten ausgeführt wird, protokolliert. Es gibt zwei Arten von XID-Fehlerlogs:

  • 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: GKE führt keine automatisierten Aktionen für nicht kritische XID-Fehler aus.
  • Kritische XID-Fehler:
    • Logformat: XidCriticalError: Xid=%d, All devices will go unhealthy
    • Bedeutung: Diese Fehler weisen auf ein GPU-Hardwareproblem hin.
    • Aktion:
      • Die 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.

GPUDirect-TCPX(O)-Probleme

Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei GPUDirect-TCPX(O)-Problemen. Wenn Sie betroffene Versionen von GKE Version 1.34 oder 1.35 verwenden, lesen Sie auch die Seite Bekannte Probleme in GKE.

Versionshinweise und Upgradeanleitung

Neue Nutzer finden unter GPU-Netzwerkbandbreite in Clustern im Standardmodus maximieren eine Anleitung zur Verwendung von GPUDirect-TCPX(O). Wenn Sie bereits Nutzer sind, lesen Sie die Versionshinweise zu GPUDirect-TCPXO, um Informationen zu Releases und Upgradeanleitungen zu erhalten, da kontinuierlich neue Versionen veröffentlicht werden.

tcpx-daemon- und tcpxo-daemon-Fehler nach GKE-Versionsupgrade

Der folgende Fehler kann auftreten, wenn Ihre tcpx-daemon- oder tcpxo-daemon-Pods fehlschlagen:

cuda error detected! name: CUDA_ERROR_NO_DEVICE; string: no CUDA-capable device is detected

Prüfen Sie außerdem, ob die device-injector-Pods im Namespace kube-system den Status CrashLoopBackOff oder Error haben.

Dieses Problem tritt auf, wenn Sie Ihre GKE-Knotenpools auf eine der folgenden Versionen oder höher aktualisiert haben:

  • Für GKE 1.31: 1.31.14-gke.1033000
  • Für GKE 1.32: 1.32.9-gke.1575000
  • Für GKE 1.33: 1.33.5-gke.1862000
  • Für GKE 1.34: 1.34.1-gke.3225000
  • Für GKE 1.35 und höher

Das Problem wird durch die Verwendung einer älteren Version des NRI-Geräte-Injectors-Manifests verursacht, das eine initContainer mit dem Namen enable-nri enthält. In diesen betroffenen GKE-Versionen ist NRI standardmäßig in der Knotenkonfiguration aktiviert. Der veraltete enable-nri-Container versucht, die Konfiguration zu ändern und die Containerlaufzeit neu zu starten. Dies steht im Konflikt mit den System-Standardeinstellungen und führt dazu, dass die nri-device-injector-Pods abstürzen. Dieser Fehler verhindert, dass GPU-Geräte für den Container tcpx-daemon oder tcpxo-daemon freigegeben werden.

Aktualisieren Sie das DaemonSet nri-device-injector auf die aktuelle Version, um dieses Problem zu beheben. Dadurch wird die in Konflikt stehende initContainer entfernt.

  1. Löschen Sie das vorhandene DaemonSet:

    kubectl delete daemonset device-injector -n kube-system

  2. Wenden Sie das aktuelle Manifest an:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yaml

  3. Starten Sie Ihre Arbeitslast-Pods neu.

Mit NCCL-Logs debuggen

Wenn Sie ein Problem mit NCCL nicht beheben können, erfassen Sie NCCL-Logs mit Debugging-Informationen. Diese Logs 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. Diese Logs können Cloud Customer Care dabei 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. Für GKE-Cluster können Sie NCCL-Tests mit Topology Aware Scheduling (TAS) bereitstellen und ausführen. Nachdem Sie den NCCL-Test ausgeführt haben, generiert NCCL automatisch die Logs auf allen teilnehmenden Knoten.

  3. Erfassen Sie die Logs von allen Knoten. Prüfen Sie, ob Sie NCCL-Logs von allen Knoten erfasst haben. Die Logs 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 Logdateien befinden, zeigt das folgende Beispiel, 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. 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.
    • Unter 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 innerhalb des Prozesses verwendet wurde, als NCCL den Logeintrag generiert hat.
    • RANK: die lokale Rang-ID. 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 am Prozess beteiligten GPUs ist. 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 und dem Zeitstempel, zu dem 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 lokale Rang-ID.
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: die Nachricht, in der erklärt wird, was passiert ist.

  5. Wenn Sie eine Supportanfrage stellen, packen Sie die erfassten 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 keine NCCL-Debugging-Logs mehr erfassen möchten, entfernen Sie die Variablen, die Sie in Schritt 1 hinzugefügt haben.

Nächste Schritte