Dynamic Resource Allocation (DRA) in Kubernetes 2026: GPU-Scheduling neu definiert

📷 "Tesla NVIDIA GPU cluster" by ChrisDag is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Dynamic Resource Allocation (DRA) ist seit Kubernetes 1.34/1.35 stable – und löst ein Problem, das Betreiber von GPU-Clustern seit Jahren umtreibt: Die alte Device-Plugin-Architektur behandelt GPUs als zählbare Blackboxen, ohne Eigenschaften wie Modell, Speicher oder MIG-Profil zu berücksichtigen. Mit DRA ändert sich das grundlegend. Der folgende Artikel zeigt, wie die neue API funktioniert, warum sie gerade für KI-Workloads relevant ist und wie die ersten Produktionseinsätze aussehen.

Was DRA anders macht

Das alte Device-Plugin-Framework erlaubt nur nvidia.com/gpu: 1 – eine simple Zahl. Welcher GPU-Typ, mit welchem Speicher oder welcher Rechenarchitektur tatsächlich zum Pod gelangt, bleibt dem Scheduler verborgen. Teams umgehen das mit nodeSelector, Taints und Tolerations, was schnell zu unwartbaren Konfigurationen führt.

DRA führt dagegen ein vollwertiges API-Modell ein, das an das PersistentVolume-System erinnert. Vier neue Objekte bilden das Rückgrat:

DeviceClass – definiert eine Kategorie von Geräten (z. B. gpu.nvidia.com oder mig.nvidia.com).
ResourceSlice – listet alle verfügbaren Geräte auf einem Node mit ihren Attributen.
ResourceClaim – ein „Ticket" für ein konkretes Gerät, das ein Pod referenziert.
ResourceClaimTemplate – eine Vorlage, die automatisch pro Pod einen eigenen Claim erzeugt.

Der entscheidende Fortschritt: Der Scheduler selbst wertet jetzt CEL-Ausdrücke (Common Expression Language) gegen die Attribute in den ResourceSlices aus. Ein Pod kann sagen: „Ich brauche eine MIG-Instanz mit Profil 1g.5gb" – und Kubernetes findet den passenden Node, ohne dass der Entwickler Node-Labels kennen muss.

Warum DRA gerade jetzt relevant ist

Die API ist mit Kubernetes v1.34 in den Stable-Status erhoben worden und ab v1.35 standardmäßig aktiviert. Red Hat hat DRA mit OpenShift 4.21 (Kubernetes 1.34) auf GA gehoben und hebt hervor, dass die neue Architektur die Beschränkungen des Device-Plugin-Modells „fundamental" überwindet. NVIDIA hat den Treiber dra-driver-nvidia-gpu in die Kubernetes SIGs überführt – ein klares Zeichen, dass der Standard industrieweit trägt.

Die CNCF-Umfrage vom Januar 2026 zeigt, dass 66 % der Organisationen generative KI-Modelle auf Kubernetes betreiben. GPU-Kapazität ist zum Engpass geworden: Durchschnittlich werden nur 5 % der GPU-Ressourcen in Produktionsclustern tatsächlich genutzt, wie die Cast AI-Studie zur Kubernetes-Optimierung 2026 ermittelte. DRA adressiert genau diese Ineffizienz, indem es feingranulare Zuweisung und Sharing-Mechanismen ermöglicht.

Konkrete Einsatzszenarien

1. Attributbasierte GPU-Auswahl

Statt einen Node mit der richtigen GPU per labelSelector zu erraten, spezifiziert der Entwickler direkt die benötigten Geräteattribute. Ein ResourceClaim für eine bestimmte MIG-Instanz sieht in der Praxis so aus:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: mig-1g5gb-claim
spec:
  spec:
    devices:
      requests:
        - name: mig
          exactly:
            deviceClassName: mig.nvidia.com
            selectors:
              - cel:
                  expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'"

Der Scheduler weist den Pod automatisch einem Node zu, der eine passende MIG-Partition bereitstellt – ohne nodeSelector, ohne Tolerations.

2. Device-Sharing zwischen Containern

Zwei Container im selben Pod können dasselbe ResourceClaim referenzieren und teilen sich dann ein GPU-Gerät. Das war mit dem alten Device-Plugin nicht möglich. Besonders für Sidecar-Muster in Inferenz-Workloads ist das ein Gewinn.

3. Time Slicing auf GPU-Ebene

DRA ermöglicht GPU Time Slicing direkt über die API, ohne manuelle Konfiguration der Anzahl der Slices. Der NVIDIA DRA Driver übernimmt die Aufteilung transparent.

Was das für den Cluster-Alltag bedeutet

DRA beseitigt die Fragmentierung, die bisher unvermeidbar war: GPUs unterschiedlicher Generationen (z. B. A100 und H100) im selben Cluster sind jetzt sauber über Attribute adressierbar. Gemischte Hardware wird zum Vorteil statt zum Problem.

Seit Kubernetes v1.36 kommt zudem Device-Health-Reporting hinzu. Fällt eine GPU aus, sieht der Administrator in der ResourceSlice, ob der Fehler vom Gerät oder von der Anwendung stammt – ohne manuelle Node-Inspektion. Das spart in größeren Clustern erheblich Zeit bei der Fehlersuche.

Ein weiterer Vorteil: Die DRA-Architektur ist mit dem Cluster Autoscaler kompatibel. In Zukunft könnten GPU-Node-Pools automatisch erweitert werden, wenn die Nachfrage nach bestimmten DeviceClasses steigt.

Fazit

Dynamic Resource Allocation ist mehr als eine neue API – sie korrigiert einen der ältesten Blindflüge in Kubernetes. Wo früher nodeSelector-Ketten und individuelle Webhooks für jede GPU-Konfiguration nötig waren, reicht heute ein CEL-Ausdruck im ResourceClaim. Für Teams, die KI-Workloads auf Kubernetes betreiben oder planen, ist DRA der entscheidende Schritt zu einer effizienten, wartbaren GPU-Infrastruktur.

Die ersten Produktionserfahrungen mit OpenShift 4.21 und den NVIDIA DRA-Treibern zeigen: Die Technologie ist reif für den Einsatz. Wer jetzt migriert, spart sich später den Umstieg von einem abgekündigten Device-Plugin-Modell.