Umstellung auf selbstverwaltete NVIDIA GPU-Treiber für Kubernetes 1.36

Ab der Version Kubernetes 1.36 installiert IBM Cloud Kubernetes Service nicht mehr automatisch NVIDIA GPU-Treiber auf GPU-Worker-Nodes. Sie müssen GPU-Treiber selbst installieren und verwalten, um GPU-Workloads auszuführen.

Was ändert sich?

Version 1.36 und höher
GPU-Treiber sind auf neuen oder ausgetauschten GPU-Worker-Nodes nicht vorinstalliert. Sie müssen die folgenden Komponenten installieren und pflegen:
  • NVIDIA Kernel-Treiber
  • Container-Laufzeitkomponenten (z. B. nvidia-container-toolkit)
  • Kubernetes Geräte-Plugin
Versionen 1.35 und frühere Versionen
GPU-Treiber werden automatisch von IBM auf allen GPU-Worker-Nodes installiert und verwaltet.

Was ist die Auswirkung?

Pods, die GPU-Ressourcen anfordern, bleiben im Zustand Pending, bis Sie die erforderlichen GPU-Treiber auf dem Arbeitsknoten installieren. Nach der Installation der Treiber gehen die anhängigen Pods automatisch in den Zustand Running über.

Verstehen des Migrationsprozesses

Die Migration auf selbstverwaltete GPU-Treiber erfolgt in einer bestimmten Reihenfolge, um sicherzustellen, dass Ihre GPU-Workloads während des Upgrades weiterlaufen:

  1. Vor-Installationsphase: Sie installieren den NVIDIA GPU Operator auf Ihrem Cluster, während dieser noch mit der Version 1.35 oder früher läuft. Während der Installation kennzeichnen Sie die vorhandenen GPU-Knoten, um zu verhindern, dass der Betreiber Treiberressourcen einsetzt, die mit den vorinstallierten Treibern in Konflikt geraten würden.

  2. Upgrade der Steuerebene: Sie aktualisieren die Clusterkontrollebene auf die Version 1.36.

  3. Upgrade der Arbeitsknoten: Ersetzen Sie die einzelnen Arbeitsknoten, um sie auf die Version 1.36 zu aktualisieren. Wenn Sie dies tun, werden die Etiketten, die die Treiberbereitstellung verhindert haben, automatisch entfernt. Dies ermöglicht es dem NVIDIA GPU Operator, seinen Treiberstack auf den neuen Knoten einzusetzen.

  4. Automatische Workload-Wiederherstellung: Sobald der Bediener die Treiber auf einem ausgetauschten Knoten installiert, gehen alle anhängigen GPU-Workloads automatisch in den Zustand Running über.

Vorbereitung auf die Migration, bevor die Version 1.36 verfügbar ist

Sie können die Schritte vor der Installation durchführen, bevor die Version 1.36 veröffentlicht wird, um Ihren Cluster für eine reibungslose Migration vorzubereiten:

  1. Kennzeichnen Sie Ihre vorhandenen GPU-Worker-Nodes, um zu verhindern, dass der Betreiber Ressourcen bereitstellt, die mit vorinstallierten Treibern in Konflikt geraten würden.

    kubectl label node/<node_name> nvidia.com/gpu.deploy.operands=false
    kubectl label node/<node_name> nvidia.com/gpu.deploy.driver=false
    
  2. Installieren Sie den NVIDIA GPU Operator gemäß der Installationsanleitung NVIDIA GPU Operator.

  3. Vergewissern Sie sich, dass der Operator installiert ist, aber keine Treiberressourcen auf Ihren gekennzeichneten Knoten bereitstellt.

    kubectl get pods -n gpu-operator -o wide
    

Durch die frühzeitige Durchführung dieser Vorbereitungsschritte reduzieren Sie den Arbeitsaufwand während des eigentlichen Upgrades auf die Version 1.36. Wenn die Version 1.36 verfügbar ist, müssen Sie nur die Steuerungsebene aktualisieren und die Arbeitsknoten ersetzen.

Vorbereitende Schritte

  • Lesen Sie die Dokumentation NVIDIA GPU Operator.
  • Stellen Sie sicher, dass Sie über Cluster-Administrator-Zugang verfügen.
  • Planen Sie Ihre Upgrade-Strategie auf der Grundlage Ihrer Clusterkonfiguration (einzelner GPU-Knoten vs. mehrere GPU-Knoten).

Beispiele für Migration

Die folgenden Beispiele zeigen, wie Sie Ihren Cluster auf der Grundlage der Anzahl der GPU-Knoten migrieren können.

Beispiel 1: Einzelner GPU-Knoten im Cluster

Dieses Beispiel zeigt die Migration eines Clusters mit einem einzelnen GPU-Knoten. Da der einzige GPU-Knoten während des Upgrades nicht verfügbar sein wird, fügen Sie vorübergehend einen zweiten GPU-Worker hinzu, um die Kapazität aufrechtzuerhalten.

Schritt 1: Ermittlung des anfänglichen Clusterzustands

  1. Überprüfen Sie die Version der Clusterkontrollebene.

    ibmcloud ks cluster get -c CLUSTER_NAME
    

    Beispiel für die Ausgabe der Version 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Überprüfen Sie die Version des Arbeitsknotens.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispiel für die Ausgabe eines einzelnen GPU-Knotens:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    

Schritt 2: Installieren Sie den NVIDIA GPU Operator

Wenn Sie die Schritte unter Vorbereitung auf die Migration, bevor die Version 1.36 verfügbar ist befolgt haben, haben Sie diesen Schritt möglicherweise bereits abgeschlossen.

  1. Kennzeichnen Sie den vorhandenen GPU-Arbeitsknoten, um zu verhindern, dass der Betreiber Ressourcen bereitstellt, die mit vorinstallierten Treibern in Konflikt geraten würden.

    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.driver=false
    
  2. Fügen Sie das Repository NVIDIA Helm hinzu und installieren Sie den GPU-Operator.

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
    helm repo update
    helm install --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
    
  3. Stellen Sie sicher, dass die GPU-Operator-Pods ausgeführt werden. Beachten Sie, dass das Treiberinstallationsprogramm, das Geräte-Plugin, das Container-Toolkit und der DCGM-Exporter NICHT auf dem gekennzeichneten Knoten ausgeführt werden sollten.

    kubectl get pods -n gpu-operator -o wide
    

    Beispielausgabe:

    NAME                                                              READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-operator-1778819096-node-feature-discovery-gc-84d98bd6nqw2z   1/1     Running   0          2m21s   172.17.64.94    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-master-6b6cpnm9w   1/1     Running   0          2m21s   172.17.64.93    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-hm7ft       1/1     Running   0          2m21s   172.17.64.91    10.240.0.64   <none>           <none>
    gpu-operator-76c686b9df-kn4dw                                     1/1     Running   0          2m21s   172.17.64.92    10.240.0.64   <none>           <none>
    

Schritt 3: Upgrade der Clusterkontrollebene

  1. Aktualisieren Sie die Clusterkontrollebene auf die Version 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Überprüfen Sie das Upgrade der Steuerungsebene.

    ibmcloud ks cluster get -c <cluster_name>
    

    Beispielausgabe:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.36.0_1506
    

Schritt 4: Hinzufügen eines temporären GPU-Arbeitsknotens

  1. Fügen Sie dem Cluster einen temporären zweiten GPU-Arbeiter mit Kubernetes Version 1.36 hinzu.

    ibmcloud ks worker-pool create vpc-gen2 --name temp-gpu-pool --cluster <cluster_name> --flavor gx3.16x80.l4 --size-per-zone 1 --zone us-south-1
    
  2. Überprüfen Sie, ob der temporäre Knoten bereit ist.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispiel für eine Ausgabe, die sowohl den ursprünglichen als auch den temporären Knoten zeigt:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-tempgpupool-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Überprüfen Sie, ob GPU-Operator-Pods auf dem neuen temporären Knoten ausgeführt werden.

    kubectl get pods -n gpu-operator -o wide
    

    Beispiel für eine Ausgabe, die zeigt, dass Treiber und Geräte-Plugin auf dem temporären Knoten laufen:

    NAME                                                              READY   STATUS      RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-feature-discovery-mw5km                                       1/1     Running     0          4m36s   172.17.116.201   10.240.0.72   <none>           <none>
    nvidia-container-toolkit-daemonset-ns6p8                          1/1     Running     0          4m36s   172.17.116.199   10.240.0.72   <none>           <none>
    nvidia-cuda-validator-vgj45                                       0/1     Completed   0          96s     172.17.116.203   10.240.0.72   <none>           <none>
    nvidia-dcgm-exporter-52cwh                                        1/1     Running     0          4m36s   172.17.116.204   10.240.0.72   <none>           <none>
    nvidia-device-plugin-daemonset-2ql7x                              1/1     Running     0          4m36s   172.17.116.202   10.240.0.72   <none>           <none>
    nvidia-driver-daemonset-zql6m                                     1/1     Running     0          5m29s   172.17.116.197   10.240.0.72   <none>           <none>
    nvidia-operator-validator-44xtz                                   1/1     Running     0          4m36s   172.17.116.200   10.240.0.72   <none>           <none>
    
  4. Überprüfen Sie die GPU-Bereitschaft auf dem temporären Knoten.

    kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable}'
    

Schritt 5: Migration von Arbeitslasten und Upgrade des ursprünglichen Knotens

  1. Migrieren Sie Ihre GPU-Workloads auf den temporären Arbeiterknoten 1.36. Sie können Knotenselektoren, Taints oder das manuelle Löschen von Pods verwenden, um Workloads zu verschieben.

  2. Ersetzen Sie den ursprünglichen GPU-Knoten.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  3. Überprüfen Sie das Knoten-Upgrade.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispiel einer Ausgabe, die zeigt, dass beide Knoten jetzt auf Version 1.36:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-00000485   10.240.0.68   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-tempgpupool-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  4. Überprüfen Sie, ob GPU-Operator-Pods auf dem aktualisierten Originalknoten ausgeführt werden.

    kubectl get pods -n gpu-operator -o wide
    
  5. Überprüfen Sie, ob alle GPU-Workloads ausgeführt werden.

    kubectl get pods -o wide
    

    Beispielausgabe:

    NAME             READY   STATUS    RESTARTS   AGE    IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          6m8s   172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          44m    172.17.121.28    10.240.0.68   <none>           <none>
    

Schritt 6: Entfernen Sie den temporären Knoten (optional)

Wenn der ursprüngliche Knoten gesund ist und die Arbeitslasten stabil sind, können Sie den temporären GPU-Knoten optional entfernen.

  1. Löschen Sie den temporären Arbeitsvorrat.

    ibmcloud ks worker-pool rm --cluster <cluster_name> --worker-pool temp-gpu-pool
    
  2. Überprüfen Sie, dass nur der ursprüngliche Knoten übrig bleibt.

    ibmcloud ks worker ls -c <cluster_name>
    

Beispiel 2: Mehrere GPU-Knoten im Cluster

Dieses Beispiel zeigt die Migration eines Clusters mit zwei GPU-Knoten von Kubernetes Version 1.35 auf 1.36. Bei mehreren Knoten können Sie einen Knoten nach dem anderen aufrüsten und dabei die GPU-Kapazität beibehalten.

Schritt 1: Ermittlung des anfänglichen Clusterzustands

  1. Überprüfen Sie die Version der Clusterkontrollebene.

    ibmcloud ks cluster get -c <cluster_name>
    

    Beispiel für die Ausgabe der Version 1.35:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.35.4_1528
    
  2. Überprüfen Sie die Versionen der Arbeitsknoten.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispiel für die Ausgabe von zwei GPU-Knoten:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-000001e4   10.240.0.64   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-0000024b   10.240.0.66   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    

Schritt 2: Installieren Sie den NVIDIA GPU Operator

Wenn Sie die Schritte unter Vorbereitung auf die Migration, bevor die Version 1.36 verfügbar ist befolgt haben, haben Sie diesen Schritt möglicherweise bereits abgeschlossen.

  1. Kennzeichnen Sie die vorhandenen GPU-Arbeitsknoten, um zu verhindern, dass der Betreiber Ressourcen einsetzt, die mit den vorinstallierten Treibern in Konflikt geraten würden.

    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.64 nvidia.com/gpu.deploy.driver=false
    kubectl label node/10.240.0.66 nvidia.com/gpu.deploy.operands=false
    kubectl label node/10.240.0.66 nvidia.com/gpu.deploy.driver=false
    
  2. Fügen Sie das Repository NVIDIA Helm hinzu und installieren Sie den GPU-Operator.

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
    helm repo update
    helm install --wait --generate-name -n gpu-operator --create-namespace nvidia/gpu-operator
    
  3. Stellen Sie sicher, dass die GPU-Operator-Pods ausgeführt werden. Beachten Sie, dass das Treiberinstallationsprogramm, das Geräte-Plugin, das Container-Toolkit und der DCGM-Exporter NICHT auf den gekennzeichneten Knoten ausgeführt werden sollten.

    kubectl get pods -n gpu-operator -o wide
    

    Beispielausgabe:

    NAME                                                              READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-operator-1778819096-node-feature-discovery-gc-84d98bd6nqw2z   1/1     Running   0          2m21s   172.17.64.94    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-master-6b6cpnm9w   1/1     Running   0          2m21s   172.17.64.93    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-hm7ft       1/1     Running   0          2m21s   172.17.64.91    10.240.0.64   <none>           <none>
    gpu-operator-1778819096-node-feature-discovery-worker-xh4qz       1/1     Running   0          2m21s   172.17.121.29   10.240.0.66   <none>           <none>
    gpu-operator-76c686b9df-kn4dw                                     1/1     Running   0          2m21s   172.17.64.92    10.240.0.64   <none>           <none>
    

Schritt 3: Upgrade der Clusterkontrollebene

  1. Aktualisieren Sie die Clusterkontrollebene auf die Version 1.36.

    ibmcloud ks cluster master update --cluster <cluster_name> --version 1.36.0
    
  2. Überprüfen Sie das Upgrade der Steuerungsebene.

    ibmcloud ks cluster get -c <cluster_name>
    

    Beispielausgabe:

    Master
    Status:     Ready
    State:      deployed
    Health:     normal
    Version:    1.36.0_1506
    

Schritt 4: Upgrade des ersten Arbeitsknotens

  1. Ersetze den ersten Worker-Knoten.

    ibmcloud ks worker replace -w test-d8397vk20kb65iocenn0-btspstggput-default-000001e4 -c <cluster_name> --update
    
  2. Überprüfen Sie das Knoten-Upgrade.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispielausgabe:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-0000024b   10.240.0.66   gx3.16x80.l4   normal   Ready    us-south-1   1.35.4_1528   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Überprüfen Sie den GPU-Auslastungsstatus. Die auf dem neuen Knoten geplante GPU-Arbeitslast befindet sich im Status Pending, bis der Treiber installiert ist.

    kubectl get pods -o wide
    

    Beispielausgabe:

    NAME             READY   STATUS    RESTARTS   AGE   IP              NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   0/1     Pending   0          18s   <none>          <none>        <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          38m   172.17.121.28   10.240.0.66   <none>           <none>
    
  4. Überprüfen Sie, ob GPU-Operator-Pods auf dem neuen Knoten ausgeführt werden.

    kubectl get pods -n gpu-operator -o wide
    

    Beispielhafte Ausgabe, die zeigt, dass Treiber und Geräte-Plugin auf dem neuen Knoten laufen:

    NAME                                                              READY   STATUS      RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-feature-discovery-mw5km                                       1/1     Running     0          4m36s   172.17.116.201   10.240.0.72   <none>           <none>
    nvidia-container-toolkit-daemonset-ns6p8                          1/1     Running     0          4m36s   172.17.116.199   10.240.0.72   <none>           <none>
    nvidia-cuda-validator-vgj45                                       0/1     Completed   0          96s     172.17.116.203   10.240.0.72   <none>           <none>
    nvidia-dcgm-exporter-52cwh                                        1/1     Running     0          4m36s   172.17.116.204   10.240.0.72   <none>           <none>
    nvidia-device-plugin-daemonset-2ql7x                              1/1     Running     0          4m36s   172.17.116.202   10.240.0.72   <none>           <none>
    nvidia-driver-daemonset-zql6m                                     1/1     Running     0          5m29s   172.17.116.197   10.240.0.72   <none>           <none>
    nvidia-operator-validator-44xtz                                   1/1     Running     0          4m36s   172.17.116.200   10.240.0.72   <none>           <none>
    
  5. Überprüfen Sie die auf dem neuen Knoten geplante GPU-Arbeitslast.

    kubectl get pods -o wide
    

    Beispielausgabe:

    NAME             READY   STATUS    RESTARTS   AGE    IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          6m8s   172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-z6xnh   1/1     Running   0          44m    172.17.121.28    10.240.0.66   <none>           <none>
    

Schritt 5: Upgrade der übrigen Knoten

  1. Wiederholen Sie Schritt 4 für jeden verbleibenden GPU-Knoten und aktualisieren Sie einen Knoten nach dem anderen.

  2. Nachdem alle Knoten aktualisiert wurden, stellen Sie sicher, dass auf allen Arbeitsknoten die Version 1.36 läuft.

    ibmcloud ks worker ls -c <cluster_name>
    

    Beispielausgabe:

    ID                                                       Primary IP    Flavor         State    Status   Zone         Version       Operating System
    test-d8397vk20kb65iocenn0-btspstggput-default-00000371   10.240.0.72   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    test-d8397vk20kb65iocenn0-btspstggput-default-0000048c   10.240.0.73   gx3.16x80.l4   normal   Ready    us-south-1   1.36.0_1507   UBUNTU_24_64
    
  3. Überprüfen Sie, ob alle GPU-Operator-Pods laufen.

    kubectl get pods -n gpu-operator -o wide
    
  4. Überprüfen Sie, ob alle GPU-Workloads ausgeführt werden.

    kubectl get pods -o wide
    

    Beispielausgabe:

    NAME             READY   STATUS    RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
    gpu-burn-46pml   1/1     Running   0          18m     172.17.116.205   10.240.0.72   <none>           <none>
    gpu-burn-ttcbt   1/1     Running   0          6m46s   172.17.75.77     10.240.0.73   <none>           <none>
    

Nächste Schritte

  • Überwachen Sie Ihre GPU-Workloads, um sicherzustellen, dass sie korrekt ausgeführt werden.
  • Lesen Sie die Dokumentation NVIDIA GPU Operator für erweiterte Konfigurationsoptionen.
  • Richten Sie die Überwachung für GPU-Metriken mithilfe des NVIDIA DCGM-Exporters ein.