GPU in Kubernetes: CDI, Sharing-Techniken und DRA

TL;DR

• CDI (Container Device Interface) ist der moderne Standard, der GPUs in Containern verfügbar macht — und das alte NVIDIA-Docker-Modell ablöst.
• Drei Sharing-Strategien: Time-Slicing (einfach, ohne Memory-Limits), MPS (Memory-Garantien), MIG (Hardware-Mini-GPUs).
• Device-Plugins (nvidia.com/gpu: 2) stoßen an harte Grenzen: keine Multi-GPU-Typen pro Node, keine komplexen Constraints, keine dynamische MIG-Provisionierung.
• DRA ersetzt das Zähl-Modell durch Device-Classes und Resource-Claims — inkl. PCIe-Alignment von GPU und NIC.
• Ab Kubernetes 1.32 deckt DRA fast alle gängigen GPU-Use-Cases ab (Beta-Reife je nach Version prüfen).

Das Kernproblem: Treiber und Container

Früher: GPU kaufen, Treiber installieren, App verlinken. Mit Containern muss der NVIDIA-Treiber (Kernel + User-Space) exakt zur Host-Version passen — schon ein Patch-Unterschied bricht Images.

Die Lösung ist Runtime-Injection der Host-Treiber-Bibliotheken statt Bundling im Image. So bleiben Container über Maschinen mit verschiedenen Treiber-Versionen portabel.

CDI: der moderne Geräte-Standard

CDI (CNCF, mit Intel) standardisiert komplexe Geräte in Containern. Eine Spec beschreibt deklarativ:

• Device-Nodes
• Library-Mounts
• Sockets
• Env-Vars
• Hooks

Vendor (NVIDIA, Intel, …) erzeugen Specs; CDI-fähige Runtimes konsumieren sie. Syntax-Beispiel: nvidia.com/gpu=<name>. Ab Docker 25 direkt nutzbar; nvidia-ctk generiert Specs aus dem Host.

# Konzept: CDI-Spec erzeugen und von der Runtime nutzen
nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
# Runtime mountet Devices laut Spec — ohne Image-seitige Treiber

GPU-Support in Kubernetes: zwei Ebenen

Der GPU Operator erkennt Nodes, installiert den Stack und bewirbt Ressourcen — weniger manuelles Infra-Management. Grundlagen dazu auch im GPU-Workload-Guide.

apiVersion: v1
kind: Pod
metadata:
  name: infer
spec:
  containers:
    - name: app
      image: your-inference:latest
      resources:
        limits:
          nvidia.com/gpu: 1

GPU-Sharing: drei Strategien mit Trade-offs

Wichtig: Bei Time-Slicing kann ein CUDA-Kontext den Speicher monopolisieren. Wenn Isolation zählt, MPS oder MIG wählen.

Grenzen des Device-Plugin-Modells

Das Muster nvidia.com/gpu: N reicht für einfache Fälle — und scheitert bei AI-Velocity:

• kein Multi-GPU-Typ pro Node (nur Node-Selector, homogene GPUs)
• keine komplexen Constraints („mindestens 80 GB")
• keine Kontrolle, wer mit wem oversubscribed
• keine dynamische MIG-Provisionierung (Admin muss vorab konfigurieren)
• kein PCIe-Alignment (GPU + NIC auf demselben Root)

DRA: Dynamic Resource Allocation

DRA ist die neue Art, Ressourcen anzufragen — inspiriert vom Persistent-Volume-API: Device-Class + Resource-Claim statt flachem Zähler. Unter der Haube nutzt es CDI für die Injektion.

Bausteine

• ResourceSlice: Node bewirbt reiche Geräte-Objekte (Typ, Memory, Kapazität).
• DeviceClass: CEL-Ausdruck, welche Geräte aus welchem Driver erlaubt sind.
• ResourceClaim: Anfrage mit optionalen Constraints.
• Scheduler: bindet passende Geräte.

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: big-gpu
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        allocationMode: ExactCount
        count: 1
# Constraints (Memory, PCIe-Root) je nach Driver/API-Version

Was damit möglich wird

• kontrolliertes Sharing (auch über Pods hinweg)
• GPU-Auswahl über Constraints
• mehrere GPU-Typen pro Node
• dynamisches Time-Slicing/MPS per Claim
• PCIe-Alignment: GPU + NIC mit gleichem k8s.io/PCIeRoot — kritisch für verteiltes Training/Inference

Reifegrad (Orientierung)

In Piloten testen, Upgrade-Pfad planen — nicht auf „fertig" warten und nicht blind flächendeckend ausrollen. Siehe auch Kubernetes AI at Scale.

Entscheidungsmatrix für Plattform-Teams

Lessons Learned

1. Time-Slicing ohne Memory-Limits ist riskant.
2. DRA reift versionsweise — Feature-Matrix je Cluster-Version prüfen.
3. CDI-Compatibilität der Runtime testen.
4. GPU in Kubernetes ist Linux-first — Windows nicht einplanen.
5. Sharing-Strategie ist Workload-Entscheidung, keine Cluster-Defaults-Folie.

Fazit

GPU-Management in Kubernetes wandelt sich von statisch und rigide zu dynamisch und constraint-fähig: CDI für Injektion, klare Sharing-Trade-offs, DRA für Rezepte statt Zähler. Wer das versteht, trifft bessere Kosten- und Performance-Entscheidungen — bevor die nächste GPU-Rechnung kommt.

FAQ

Was ist CDI? Container Device Interface — deklarative Specs für Device-Nodes, Mounts, Sockets und Hooks.

Welche Sharing-Strategie ist „beste"? Batch → Time-Slicing; Latenz/Memory → MPS; echte Isolation → MIG.

Was ist DRA? Dynamic Resource Allocation — ResourceClaims statt nvidia.com/gpu: N, mit Constraints und Topologie.

Verwandte Artikel

• GPU Workloads auf Kubernetes
• KubeVirt und Multi-Tenant-GPU-Clouds
• Kubernetes AI at Scale
• Ray auf Kubernetes
• AKS GPU-Kostenrechner