Kubernetes 1.37: GPU-Workloads schrittweise auf DRA migrieren

Wenn ein Kubernetes-1.37-Cluster DRA-gestützte Extended Resources bereitstellt, kann ein GPU-Pod weiterhin example.com/gpu anfordern, während ein DRA-Treiber statt des Device Plugins das Gerät zuweist. Der GPU-Request bleibt unverändert. Ein Pilot auf ausgewählten Nodes ist dem gleichzeitigen Wechsel aller GPU-Nodes vorzuziehen: Er hält die Anforderung im Pod konstant und macht Fehler bei der Gerätebereitstellung auf den umgestellten Nodes sichtbar.

Was ändert sich mit DRA in Kubernetes 1.37?

Bisher meldet ein Device Plugin GPUs meist unter einem Extended-Resource-Namen wie example.com/gpu. Der Scheduler berücksichtigt die gemeldete Kapazität; das Device Plugin weist dem Pod anschließend auf dem Node ein Gerät zu. Über DRA kann stattdessen ein DRA-Treiber denselben Ressourcennamen bereitstellen. Ein ausdrücklich definierter ResourceClaim im Pod-Manifest ist für diesen Anforderungsweg nicht nötig.

Die Verbindung zum bisherigen Ressourcennamen steht in spec.extendedResourceName einer DeviceClass. Der gezeigte Wechsel betrifft die Gerätezuweisung, nicht die Eigenschaften der GPU. Eine DeviceClass mit einem Selektor für den Treiber prüft beispielsweise noch keinen Grafikspeicherbedarf. Ob der Wechsel für einen konkreten Workload taugt, hängt deshalb vom installierten GPU-Treiber und den veröffentlichten Geräten ab.

Welche Voraussetzungen braucht die GPU-Migration zu DRA?

Ein Kubernetes-Upgrade installiert keinen DRA-fähigen GPU-Treiber. Vor dem Pilot zeigt kubectl explain deviceclass.spec.extendedResourceName, ob die Cluster-API das benötigte Feld kennt. Der Treiber muss die GPUs als DRA-Geräte veröffentlichen und dem Container nach der Zuweisung zugänglich machen. Mit kubectl get resourceslices -o yaml lassen sich der Treibername und die veröffentlichten Geräte auf den vorgesehenen Nodes prüfen.

Für den Pilot eignen sich Nodes, deren GPU-Jobs sich planbar beenden oder verschieben lassen. Vor dem Treiberwechsel steht fest, wie das Team den DRA-Treiber dort deaktiviert und das bisherige Device Plugin wiederherstellt. Laufende GPU-Jobs bleiben von diesem Wechsel ausgenommen. Kubernetes-Scheduling und Node-Verwaltung gehören auch zum Themenfeld der Cloud-Native-Schulungen. Sind Treiber, Pilot-Nodes und Rückweg geklärt, lässt sich der bisherige Ressourcenname für DRA konfigurieren.

Den vorhandenen GPU-Ressourcennamen per DeviceClass anbieten

example.com/gpu bezeichnet im Beispiel die Ressource, die bestehende Pods bereits anfordern. gpu.example.com steht für den Namen des installierten DRA-Treibers. Beide Platzhalter müssen vor dem Einsatz durch Werte aus dem Cluster ersetzt werden.

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu-pilot
spec:
  extendedResourceName: example.com/gpu
  selectors:
    - cel:
        expression: 'device.driver == "gpu.example.com"'

Der CEL-Selektor berücksichtigt Geräte des angegebenen Treibers, unterscheidet aber keine GPU-Modelle oder Speichergrößen. Braucht der Workload bestimmte Geräteeigenschaften, muss der Treiber sie veröffentlichen und die Auswahl sie berücksichtigen. Die DeviceClass selbst erzeugt weder GPUs noch ResourceSlices.

Device Plugin und DRA parallel betreiben

Während des Pilots kann derselbe Extended-Resource-Name auf verschiedenen Nodes über das Device Plugin beziehungsweise DRA bereitstehen. Auf einem Pilot-Node darf dieselbe physische GPU jedoch nicht über beide Wege als freie Kapazität erscheinen. Das Label migration.example.com/gpu-dra=pilot markiert die Test-Nodes, beschränkt aber weder die DeviceClass noch die Treiberinstallation. Deshalb muss auch die Veröffentlichung der DRA-Geräte auf die Pilot-Nodes begrenzt sein. Danach zeigt ein Test-Pod, welcher Bereitstellungsweg tatsächlich funktioniert.

Test-Pod starten und die Gerätezuweisung prüfen

Der Test-Pod fordert wie der bisherige Workload eine Einheit example.com/gpu an. Sein Node-Selector beschränkt den Versuch auf die markierten Nodes. Vor dem Start muss der Namespace mit kubectl create namespace gpu-pilot angelegt sein. Das Image im YAML ist ein Platzhalter und muss durch ein vorhandenes Image ersetzt werden, dessen Testprogramm eine GPU-Operation ausführt und die Gerätekennung ausgibt.

apiVersion: v1
kind: Pod
metadata:
  name: gpu-smoke
  namespace: gpu-pilot
spec:
  restartPolicy: Never
  nodeSelector:
    migration.example.com/gpu-dra: pilot
  containers:
    - name: test
      image: registry.example.com/gpu-test:stable
      resources:
        requests:
          example.com/gpu: "1"
        limits:
          example.com/gpu: "1"

kubectl get pod gpu-smoke -n gpu-pilot -o wide zeigt den zugewiesenen Node. Scheduling- und Bereitstellungsereignisse stehen unter kubectl describe pod gpu-smoke -n gpu-pilot. Ein laufender Pod beweist allerdings noch nicht, dass der DRA-Treiber eine nutzbare GPU bereitgestellt hat. Der Treiber muss eine Zuweisung für den Test-Pod protokollieren; kubectl logs gpu-smoke -n gpu-pilot liefert die Ausgabe des Testprogramms.

• Der Pod läuft auf einem markierten Node ohne Scheduling-Fehler
• Der DRA-Treiber protokolliert eine Gerätezuweisung für den Pod
• Das Testprogramm erkennt die zugewiesene GPU anhand ihrer Kennung
• Das Testprogramm führt eine GPU-Operation aus

Bei einem geeigneten NVIDIA-Test-Image lässt sich die sichtbare Gerätekennung beispielsweise mit nvidia-smi -L ausgeben; andere Treiber benötigen ihr jeweiliges Diagnoseprogramm. Erst wenn die Anwendung das zugewiesene Gerät tatsächlich nutzt, lohnt sich die Entscheidung über weitere Nodes.

Wann wird der Pilot erweitert oder zurückgerollt?

Für eine Erweiterung müssen der erwartete Node, die Zuweisung im Treiberprotokoll und das Ergebnis des GPU-Tests zusammenpassen. Startet der Pod ohne Zugriff auf das Gerät, ist der Test fehlgeschlagen. Eine Gerätekennung, die von der protokollierten Zuweisung abweicht, muss vor der Erweiterung untersucht werden. Auf weiteren Nodes folgt derselbe Ablauf: laufende Jobs beenden oder verschieben, die Device-Plugin-Bereitstellung für die betroffenen GPUs beenden, DRA aktivieren und den Gerätetest wiederholen.

Bei einem Fehlschlag verhindert kubectl cordon <pilot-node> zunächst neue Pod-Zuweisungen auf dem betroffenen Node. Nach dem Ende oder der geregelten Verschiebung laufender Jobs deaktiviert das Team dort den DRA-Treiber und stellt das Device Plugin wieder her. Erst nach der Freigabe des Nodes bestätigt ein Test-Pod den bisherigen Bereitstellungsweg. Die DeviceClass wird nicht vorschnell clusterweit gelöscht, falls andere Nodes sie bereits nutzen. Die Ergebnisse dieses Tests entscheiden über den nächsten Pilot-Schritt.

Fazit: Erst die Zuweisung belegen, dann skalieren

Ein unveränderter GPU-Request sagt wenig über den Erfolg der Migration aus. Entscheidend ist, ob der DRA-Treiber dem Pod auf dem vorgesehenen Node eine nutzbare GPU zuweist; GPU-Sharing oder eine höhere Auslastung folgen daraus nicht automatisch. Halte für den ersten Pilot die protokollierte Zuweisung, das Ergebnis der GPU-Operation und den getesteten Rückweg zum Device Plugin fest, bevor weitere Nodes folgen.