Kubernetes als KI-Rückgrat 2026: GPU-Orchestrierung mit DRA, Kueue und KubeRay

Die Frage, ob Kubernetes der richtige Ort für KI-Workloads ist, hat sich 2026 endgültig erledigt. Was vor zwei Jahren noch als experimentell galt, ist heute Produktionsrealität: Immer mehr Unternehmen setzen auf Kubernetes als einheitliche Orchestrierungsebene für Training und Inference von Large Language Models (LLMs) und anderen KI-Modellen. Der Grund dafür ist ein massiv gereifter Ökosystem-Stapel aus CNCF-Projekten und NVIDIA-Open-Source-Initiativen, der die jahrelangen Schwachstellen der GPU-Verwaltung endlich adressiert. Dieser Artikel gibt einen Überblick über die wichtigsten Komponenten und Entwicklungen.

DRA: Das Ende der undurchsichtigen GPU-Zählung

Der größte Durchbruch des Jahres 2026 ist die Dynamic Resource Allocation (DRA). Auf der KubeCon Europe 2026 hat NVIDIA seinen DRA-Treiber an die CNCF übergeben – ein Schritt, der die GPU-Verwaltung in Kubernetes grundlegend verändert. Bisher arbeitete Kubernetes mit dem Device-Plugin-Ansatz aus dem Jahr 2017: Ein Pod requestiert nvidia.com/gpu: 1 und bekommt eine GPU – ohne Wissen über Speichergröße, Compute Capability, NVLink-Topologie oder MIG-Partitionierung. Teams kompensierten das mit manuellen Node-Labels, Tolerations und Affinitätsregeln, die die Clusterkonfiguration in eine unübersichtliche YAML-Sammlung verwandelten.

DRA ersetzt dieses Modell durch strukturierte Ressourcenparameter. Drei neue Ressourcentypen definieren das Modell: DeviceClass (eine Hardware-Kategorie, z. B. „NVIDIA GPU"), ResourceClaimTemplate (eine pod-level Vorlage) und ResourceClaim (der tatsächliche Allokationsanforderung). Der Scheduler kann nun GPU-Typen, VRAM-Größen und Topologie-Anforderungen beim Scheduling berücksichtigen. NVIDIA hat seinen DRA-Treiber auf der KubeCon EU 2026 als Open Source an die CNCF gespendet, sodass die Community künftig gemeinsam an der Weiterentwicklung arbeitet.

DRA ist in Kubernetes 1.26 als Alpha eingeführt, in 1.32 als Beta promotet und in 1.33 auf die v1beta2-API aktualisiert worden – der Weg zur General Availability ist klar abgesteckt.

Kueue: Fair-Share und Gang Scheduling für GPU-Cluster

Parallel dazu hat sich Kueue als Standard für GPU-Job-Queueing etabliert. Das CNCF-graduierte Projekt adressiert drei zentrale Probleme, die Teams mit geteilten GPU-Clustern seit Jahren plagen:

• Fair-Share-Scheduling: GPU-Kontingente werden auf Team-Ebene über ClusterQueue und LocalQueue verwaltet, nicht über manuelle Node-Labels.
• Gang Scheduling: Ein Distributed-Training-Job startet erst, wenn alle benötigten Pods gleichzeitig Ressourcen haben – keine verschwendeten GPUs mehr durch 7 von 8 laufenden Pods.
• Preemption: Niedrigpriore Batch-Jobs geben GPUs bei Bedarf an hochpriore Inferenz-Workloads ab.

Kueue integriert sich nativ mit MIG (Multi-Instance GPU) und Time-Slicing, sodass auch Fraktionen einer GPU effizient genutzt werden können. In Kombination mit DRA entsteht ein vollständig API-gesteuertes GPU-Scheduling, das ohne manuelle Eingriffe auskommt.

KubeRay: Verteiltes Training auf Kubernetes

Für verteiltes Training großer Modelle ist KubeRay der führende Kubernetes-Operator. Er orchestriert Ray-Worker-Pods auf Kubernetes und ermöglicht Data-Parallelism, Tensor-Parallelism und Pipeline-Parallelism über mehrere GPU-Knoten hinweg. Unternehmen wie Roblox und Airbnb setzen KubeRay in Produktion für Batch-Inference und Fine-Tuning ein. Die Integration mit Kueue ermöglicht dabei Gang Scheduling für Ray-Jobs – ein entscheidender Faktor für die Auslastung teurer GPU-Cluster. KubeRay integriert sich zudem mit Prometheus und Grafana für Observability sowie mit Volcano und Apache YuniKorn für erweiterte Queueing-Mechanismen.

Inferenz: vLLM, KServe und der vollständige Stack

Für die Modell-Inferenz hat sich vLLM als Standard-Inference-Engine etabliert. PagedAttention für effizientes KV-Cache-Management und Continuous Batching sorgen für hohen Durchsatz. Die OpenAI-kompatible API macht den Wechsel von Cloud-Anbietern einfach. KServe (CNCF-graduiert) wrappt vLLM mit Kubernetes-nativen Features: Autoscaling bis Scale-to-Zero, Canary-Deployments, Traffic-Splitting und Multi-Model-Endpoints. Für Modelle, die zu groß für einen einzelnen Node sind (z. B. Llama 4 405B mit über 400 Mrd. Parametern), kommt llm-d zum Einsatz – ein verteiltes Inferenz-Framework, das Prefill und Decode entkoppelt und KV-Cache zwischen Nodes auslagern kann.

Komplettiert wird der Stack durch den NVIDIA GPU Operator für Treiber- und Toolkit-Verwaltung, Karpenter für node-level Kosteneffizienz und MLflow für Experiment-Tracking. Die Portabilität des Stacks über AWS EKS, Azure AKS, GCP GKE, On-Premises und Sovereign Clouds hinweg ist ein entscheidender Vorteil gegenüber Managed-ML-Plattformen.

Fazit

Der Kubernetes-KI-Stack ist 2026 produktionsreif. DRA, Kueue, KubeRay und vLLM bilden ein zusammenhängendes Ökosystem, das GPU-Ressourcen von der Scheduling-Ebene bis zur Inferenz effizient verwaltet. Die Spende des NVIDIA DRA-Treibers an die CNCF unterstreicht den Trend: KI auf Kubernetes ist kein Nischenthema mehr, sondern der neue Standard. Unternehmen, die ihre GPU-Cluster noch mit manuellen Labels und Device-Plugins verwalten, sollten den Umstieg auf DRA und Kueue jetzt planen.

Quellen

• CloudOptimo: Kubernetes AI Infrastructure in 2026 — GPU Scheduling & Production Realities — Umfassende Analyse der Referenzarchitektur für KI auf Kubernetes 2026
• Spheron: Kubernetes GPU Orchestration in 2026 — DRA, KAI Scheduler, and Grove Setup Guide — Technischer Leitfaden zu DRA, KAI Scheduler und GPU-Orchestrierung
• Rafay: Advancing GPU Scheduling and Isolation in Kubernetes — NVIDIAs Open-Source-Beiträge auf der KubeCon EU 2026
• KubernetesGuru: AI/ML on Kubernetes 2026 — Production Stack Guide — Produktionsstack-Übersicht mit vLLM, Kueue, KServe, Ray