Kubernetes DRA für NVIDIA-GPUs: ResourceClaims, MIG-Instanzen und der GPU Operator 26.7

Was DRA für GPU-Pods ändert

Dynamic Resource Allocation (DRA) ersetzt die gezählte Ressource nvidia.com/gpu durch Claims: Ein Pod fordert ein Gerät einer DeviceClass an, gefiltert nach dessen Attributen, und der Scheduler wählt aus dem, was jeder Knoten veröffentlicht, eine passende GPU oder MIG-Instanz. NVIDIAs DRA Driver for GPUs stellt diese Geräte bereit, und seit Release v26.7.0 installiert und verwaltet der GPU Operator ihn. Ganze GPUs und bereits angelegte MIG-Instanzen sind allgemein verfügbar; die meisten anderen Funktionen sind noch Alpha, für ein Plattformteam zählt also, welche Workloads sie heute brauchen.

Mit dem Device Plugin fordert ein Pod „eine GPU“ an und erhält die Karte, die der Knoten anbietet. Ein Claim kann „eine GPU mit mehr als 100 GiB Speicher“, „eine MIG-Instanz 1g.24gb“ oder „zwei Instanzen auf derselben physischen Karte“ verlangen, und der Scheduler prüft das, bevor er den Pod platziert. Das ist in Clustern mit gemischter Hardware wichtig, etwa mit Knoten mit RTX PRO 6000 Server Edition für Inferenz neben Knoten mit H200 NVL für Fine-Tuning.

NVIDIA GPU Operator 26.7, Dokumentation „DRA Driver for NVIDIA GPUs“, zuletzt aktualisiert am 14. Oktober 2026, gelesen am 24. Oktober 2026; Status je Feature Gate des Treibers v0.5.1.

ComputeDomains dienen Grace-Blackwell-Racks mit NVLink über mehrere Knoten, etwa GB200 NVL72; ein PCIe-Server mit RTX-PRO- oder H200-NVL-Karten nutzt sie nicht. Unser Leitfaden zum GPU-Sharing in Kubernetes erklärt MIG, Time-Slicing und MPS mit dem Device Plugin; dieser Artikel behandelt dieselben Karten unter DRA.

Voraussetzungen vor dem Umstieg

NVIDIAs Voraussetzungen für die GPU-Zuweisung über DRA, für Treiber v0.5.1 und GPU Operator 26.7.2, sind kurz, aber streng.

NVIDIA, Voraussetzungen des DRA-Treibers (v0.5.1, geändert am 23. Juli 2026) und DRA-Seite des GPU Operator 26.7 (14. Oktober 2026), gelesen am 24. Oktober 2026.

Bei der Kubernetes-Version lohnt ein zweiter Blick. Kubernetes 1.34 hat am 27. Oktober 2026 sein Lebensende, danach pflegt das Projekt 1.35 bis 1.37, wie unser Artikel zur privaten LLM-Plattform auf Kubernetes festhält; die Plattformseite des GPU Operators nennt 1.33 bis 1.37. Mehrere DRA-Funktionen werden außerdem ab 1.36 einfacher: Laut NVIDIA sind die Gates DRAExtendedResource, DRAConsumableCapacity und DRAPartitionableDevices ab v1.36 standardmäßig an, während sie unter 1.34 und 1.35 von Hand zu aktivieren sind. Nach unserer Lesart beginnt ein neuer DRA-Cluster Ende 2026 mit 1.36 oder 1.37.

Beim Treiber kommen beide Produktiv-Branches in Frage: R580 mit Support bis Juni 2028 und R595 bis März 2027, wie unser Leitfaden zu NVIDIA-Treiber-Branches und CUDA-Versionen erklärt. Für die RTX PRO 6000 Server Edition verlangt die Support-Liste des Operators ohnehin 575.57.08 oder neuer.

Den DRA-Treiber mit dem GPU Operator installieren

Unter dem Operator hat DRA eine eigene Ressource. GPUCluster ersetzt die ClusterPolicy, und der Treiber kommt entweder aus einer NVIDIADriver-Ressource, die der Operator verwaltet, oder vom Host. NVIDIA beschreibt zwei Helm-Installationen des Charts v26.7.2 im Namespace gpu-operator, beide mit clusterPolicy.deployCR=false und gpuCluster.deployCR=true: mit einem vom Operator verwalteten Treiber zusätzlich driver.nvidiaDriverCRD.enabled=true, mit einem bereits installierten Treiber driver.enabled=false. NVIDIA warnt davor, daneben ein eigenes Helm-Release dra-driver-nvidia-gpu zu installieren.

In einem Cluster aus PCIe-GPU-Servern lässt draDriver.computeDomains.enabled=false die ComputeDomain-Teile weg, die nur Grace-Blackwell-Systeme mit NVLink über mehrere Knoten nutzen. Nach der Installation sollte kubectl get gpucluster gpu-cluster den Zustand ready melden, laut NVIDIA typischerweise nach rund drei Minuten, und kubectl get deviceclass zeigt, was der Treiber anbietet:

• gpu.nvidia.com für ganze GPUs;
• mig.nvidia.com für MIG-Instanzen;
• vfio.gpu.nvidia.com für Passthrough an virtuelle Maschinen, Alpha;
• zwei ComputeDomain-Klassen, nur wenn diese Unterstützung an ist.

kubectl get resourceslice zeigt dann je Knoten einen Eintrag pro Gerät. Der Treiber selbst ist inzwischen ein Kubernetes-Projekt: Release v0.5.1 vom 12. Oktober 2026, ein Patch-Release mit Korrekturen für ComputeDomains und das Anlegen von MIG-Profilen, liefert sein Image aus registry.k8s.io, die Dokumentation liegt auf einer sigs.k8s.io-Seite.

Unsere KI-Server kommen auf Wunsch mit Betriebssystem, Treibern, CUDA und einer Container-Laufzeit, ein neuer DRA-Cluster kann also mit Knoten auf dem Treiber-Branch Ihrer Wahl beginnen. Nennen Sie uns Ihre Kubernetes-Version und Ihren Treiber-Branch, und wir bereiten die Knoten passend vor.

Ein Claim für eine RTX PRO 6000 Server Edition

Im üblichen Fall schreibt ein Pod keinen ResourceClaim selbst. Er nennt ein ResourceClaimTemplate, Kubernetes legt beim Scheduling je Pod einen Claim an und löscht ihn mit dem Pod. NVIDIAs Beispiele nutzen die API resource.k8s.io/v1. Eine Vorlage für eine ganze GPU enthält vier Dinge.

NVIDIA, Anleitung des DRA-Treibers „Request full GPUs“ (geändert am 23. Juli 2026), gelesen am 24. Oktober 2026.

In der Pod-Spezifikation verbindet resourceClaims einen Namen mit der Vorlage, und jeder Container führt diesen Namen unter resources.claims. Zwei Container mit demselben Claim teilen sich eine GPU; zwei Claims aus derselben Vorlage ergeben zwei GPUs. Für zwei GPUs, die gemeinsam zugewiesen werden müssen, kann eine Anforderung eine Anzahl tragen.

In den Selektoren liegt der eigentliche Nutzen von DRA. Jede GPU in einem ResourceSlice trägt Attribute wie productName, architecture, uuid, cudaComputeCapability, driverVersion und die PCI-Bus-ID sowie eine Kapazität namens memory. In CEL stehen die Attribute unter device.attributes['gpu.nvidia.com'], der Speicher unter device.capacity['gpu.nvidia.com'].memory. Diese Selektoren trennen die Karten, die wir liefern:

Selektorformen aus NVIDIAs DRA-Anleitung und der Referenz der ResourceSlice-Attribute, gelesen am 24. Oktober 2026. Die Schwellen sind unsere: Die RTX PRO 6000 meldet dem Treiber 95,6 GiB, die H200 NVL 140,4 GiB. Die genauen Werte für productName und memory zeigt kubectl get resourceslice -o yaml.

NVIDIAs Attributreferenz bezeichnet ihre Beispielwerte als illustrativ; einen Selektor auf productName schreiben Sie daher gegen den Namen, den Ihre eigenen ResourceSlices zeigen. Eine Speicherschwelle mit deutlichem Abstand zu beiden Karten, wie oben, übersteht kleine Unterschiede bei der Rundung der Kapazität.

MIG-Instanzen als Claims: 1g.24gb auf der RTX PRO 6000

MIG-Instanzen haben eine eigene DeviceClass, mig.nvidia.com, und eigene Attribute: profile, parentUUID, den geerbten productName sowie Kapazitäten für Speicher und Multiprozessoren. Eine Vorlage für ein Viertel einer RTX PRO 6000 nutzt den Selektor profile == '1g.24gb'; die kleinste Instanz der H200 NVL ist 1g.18gb. Zwei Anforderungen in einem Claim mit einer matchAttribute-Bedingung auf gpu.nvidia.com/parentUUID legen zwei Instanzen auf dieselbe physische Karte, etwa ein Embedding-Modell und einen Reranker, die sich eine Karte teilen sollen.

Profile aus NVIDIAs MIG User Guide (13. Oktober 2026), wie in unseren MIG-Leitfäden; Anzahl je Server unsere Multiplikation.

Statisches MIG ist der allgemein verfügbare Weg: Die Instanzen werden auf dem Knoten angelegt, bevor der DRA-Treiber startet, und später hinzugefügte Instanzen erkennt er erst nach einem Neustart des GPU-Kubelet-Plugins. Mit welchem Werkzeug sie angelegt werden, sagt die DRA-Anleitung nicht; unser MIG-Runbook für RTX PRO Blackwell zeigt die Schritte mit nvidia-smi. Dynamisches MIG, das Alpha-Gate DynamicMIG, legt für jeden Claim eine Instanz an. NVIDIA warnt jedoch, dass der Treiber dann beim Start des Plugins MIG-Instanzen löscht, die er nicht selbst angelegt hat, dass nvidia-smi mig und mig-parted nicht parallel laufen dürfen und dass es in vGPU-Gästen nicht funktioniert. Unter 1.34 und 1.35 braucht es außerdem DRAPartitionableDevices auf API-Server und Scheduler.

Zwei Grenzen bringt MIG selbst mit. NCCL wird mit MIG nicht unterstützt, ein über mehrere GPUs verteiltes Modell braucht also ganze Karten. Und NVIDIAs DRA-Voraussetzungen nennen MIG-fähige Rechenzentrums-GPUs ab der Ampere-Architektur; die Beispiele nutzen die A100. Die RTX PRO 6000 Server Edition steht auf der Support-Liste des GPU Operators und im MIG-Guide von NVIDIA, ein DRA-Beispiel für sie haben wir aber nicht gefunden. Testen Sie einen Claim daher auf einem Knoten, bevor ein ganzer Cluster davon abhängt. Unsere Seite zu den MIG-Profilen der RTX PRO 6000 zeigt, was in jede Instanz passt.

Teilen ohne MIG: Time-Slicing, Shares und MPS

Unter DRA ist Time-Slicing eine Einstellung am Claim. Der config-Abschnitt des Claims übergibt dem Treiber Parameter: apiVersion resource.nvidia.com/v1beta1, kind GpuConfig, Sharing-Strategie TimeSlicing und ein Intervall Default, Short, Medium oder Long. Container eines Pods, die dieselbe Anforderung nennen, teilen sich dann die Karte. Ein anderes Intervall als Default braucht das Alpha-Gate TimeSlicingSettings. NVIDIAs Einschränkungen entsprechen denen des Device Plugins: „All containers sharing a GPU access the same GPU memory“, und das Teilen ist nicht garantiert (Best Effort): Einen festen Anteil am Durchsatz gibt es nicht. Auf MIG-Instanzen hat Time-Slicing keine Wirkung.

Consumable Shares, das Alpha-Gate ConsumableShares, lassen den Scheduler Anteile einer GPU oder MIG-Instanz verbuchen, nach Speicher oder als feste Anzahl; unter 1.34 und 1.35 brauchen sie DRAConsumableCapacity. MPS ist ebenfalls Alpha, lässt sich nicht mit Consumable Shares oder dynamischem MIG kombinieren und läuft nicht gleichzeitig mit Time-Slicing auf derselben GPU, weil beide unterschiedliche Compute-Modi brauchen. Für produktive Endpunkte auf den Karten, die wir liefern, bleiben ganze GPUs oder statisches MIG die Konfigurationen, die NVIDIA als allgemein verfügbar führt.

Umstieg vom Device Plugin

NVIDIAs Dokumentation ist eindeutig: Ein Umstieg von ClusterPolicy auf GPUCluster im laufenden Cluster wird nicht unterstützt, das Verfahren setzt einen neuen Cluster voraus. Dasselbe gilt für ein eigenständiges DRA-Treiber-Release, das unter den Operator wechseln soll. Ein Umstieg sieht daher wie ein Neuaufbau aus:

1. Einen neuen Cluster mit Kubernetes 1.36 oder 1.37 aufbauen, die GPU-Knoten auf dem Treiber-Branch des alten Clusters.
2. GPU Operator v26.7.2 oder neuer mit GPUCluster installieren, ComputeDomains auf PCIe-Servern aus.
3. Die MIG-Aufteilung auf den Knoten anlegen, die sie brauchen, bevor das DRA-Plugin startet.
4. Jede GPU-Anforderung in ein ResourceClaimTemplate übersetzen, zunächst mit gpu.nvidia.com ohne Selektoren.
5. Workloads Dienst für Dienst umziehen und danach Selektoren ergänzen, wo die Hardware sich unterscheidet.

Für Workloads, die sich nicht sofort umschreiben lassen, kann Kubernetes eine Extended Resource auf eine DeviceClass abbilden. Mit dem Gate DRAExtendedResource, ab v1.36 standardmäßig an, behält ein Pod sein Ressourcenlimit und fordert den Ressourcennamen deviceclass.resource.kubernetes.io/gpu.nvidia.com an. Die verwaltete DeviceClass setzt den alten Namen nvidia.com/gpu nicht; wer ihn behalten will, braucht laut NVIDIA eine eigene DeviceClass mit spec.extendedResourceName.

Prüfen Sie die Serving-Schicht, bevor Sie sich festlegen. KServe 0.21.0 hat resourceClaims für DRA in der ServingRuntime ergänzt (Pull Request 5828). NVIDIAs NIM Operator 3.1.2 dokumentiert DRA für NIMService als Technology Preview, „not suitable for deployment in production“. NVIDIA weist außerdem darauf hin, dass Kubernetes für DRA-Ressourcen keine Preemption unterstützt; ein Prioritätsschema, das GPU-Pods niedriger Priorität für wichtigere verdrängt, lässt sich also nicht übernehmen.

Wann das Device Plugin die bessere Wahl bleibt

Bleiben Sie beim Device Plugin oder betreiben Sie einen Device-Plugin-Cluster neben dem neuen in drei Fällen: Der Cluster gibt wenigen Diensten ganze Karten und braucht nichts, was ein Selektor hinzufügt; die Teilung, auf die Sie sich stützen, MPS oder Time-Slicing mit festem Intervall, ist unter DRA Alpha; oder die Plattform darüber erwartet eine ClusterPolicy, wie Red Hats Anleitung für OpenShift AI beim Aktivieren von NVIDIA-GPUs, beschrieben in unserem Leitfaden OpenShift AI auf GPU-Servern.

Wechseln Sie zu DRA, wenn der Cluster Kartentypen oder MIG-Aufteilungen mischt und Pods per Attribut auf der richtigen landen sollen, wenn mehrere Instanzen von derselben Karte kommen müssen oder wenn Sie ohnehin einen neuen Cluster aufbauen. Claims auf ganze GPUs in Knoten mit RTX PRO 6000 Server Edition und H200 NVL sowie statische MIG-Instanzen für kleine Modelle nutzen heute nur allgemein verfügbare Funktionen.

Was wir liefern

Wir bauen KI-Server nach Auftrag als Kubernetes-GPU-Knoten: einen Einstiegsserver mit zwei RTX PRO 6000 Server Edition, einen Inferenzknoten mit vier und einen Trainingsknoten mit acht H200 NVL, jeweils mit zwei AMD-EPYC-Prozessoren, vor der Lieferung montiert und getestet und EU-weit mit einem Vertrag und einer Rechnung geliefert. Auf Wunsch kommen sie mit Betriebssystem, dem Treiber-Branch Ihres Clusters, CUDA und einer Container-Laufzeit mit CDI. Schicken Sie uns die Zahl der Knoten und die geplanten MIG-Aufteilungen, und unser Team antwortet innerhalb eines Werktages mit einer Konfiguration. Zur Wahl des Betriebssystems lesen Sie unseren Vergleich Linux für GPU-Server.

FAQ