▸ saaro:~/blog ▊ Notizen & Artikel
← zurück

📷 "Breaking a Nvidia GeForce 4 Ti : Sawing the thing! 2/3" by qubodup is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/.

GPU-Scheduling auf Kubernetes: Kueue, Volcano und KAI Scheduler im Vergleich 2026

09. September 2026 · 4 min · Martin Jochum #Kubernetes#GPU-Scheduling#Kueue#Volcano#KAI Scheduler#KI#DevOps#GPU

GPUs sind die teuerste Ressource in modernen Kubernetes-Clustern – und gleichzeitig die am schlechtesten verwaltete. Ein H100-Beschleuniger kostet pro Stunde mehr als ein ganzer Mid-Range-Server, doch der Standard-Scheduler von Kubernetes behandelt GPUs wie CPUs: Pod für Pod, ohne Konzept für Job-Atomarität, Quoten oder tatsächliche Auslastung. Das Ergebnis sind Cluster, in denen teure Hardware reserviert, aber nicht genutzt wird, während andere Teams auf freigegebene Kapazitäten warten.

Seit KubeCon Europe 2026 in Amsterdam ist klar: GPU-Scheduling ist das dominierende Thema im Cloud-Native-Ökosystem. Die Frage ist nicht mehr, ob man KI-Workloads auf Kubernetes betreibt, sondern wie man die knappen GPU-Ressourcen fair und effizient verteilt. Drei Open-Source-Projekte haben sich dabei als die relevanten Lösungen herauskristallisiert: Kueue, Volcano und der NVIDIA KAI Scheduler.

Kueue: Die schlanke Adminschicht

Kueue ist ein SIG-Scheduling-Projekt von Kubernetes selbst und befindet sich im September 2026 bei Version 0.19. Der Ansatz ist bewusst nicht-invasiv: Kueue ersetzt den Scheduler nicht, sondern setzt eine Adminschicht davor. Ein Job wird im suspendierten Zustand angelegt und erst von Kueue freigegeben, wenn das definierte Kontingent in der ClusterQueue verfügbar ist. Die Pod-Platzierung übernimmt weiterhin der kube-scheduler.

Das Modell ist einfach: Plattformteams definieren ClusterQueues mit nominalen Quoten und optionalen BorrowingLimits. Mehrere Queues können in einem Cohort zusammengefasst werden, um ungenutzte Kapazitäten untereinander zu teilen. Teams bekommen über LocalQueues in ihrem Namespace Sichtbarkeit, ohne Clusterrechte zu benötigen.

Kueues Stärke ist die geringe Betriebskomplexität. Für Managed-Kubernetes-Angebote wie EKS, AKS oder GKE ist es die erste Wahl, da keine Änderungen am Scheduler nötig sind. Die aktuelle Version unterstützt nativ Jobs, JobSets, Kubeflow-Training und Ray-Workloads. Mit MultiKueue können Jobs sogar über Cluster-Grenzen hinweg dispatched werden.

Volcano: Der Batch-Scheduler aus der HPC-Welt

Volcano ist ein CNCF-Incubating-Projekt (v1.15 seit Mai 2026) und verfolgt einen grundlegend anderen Ansatz. Statt einer Adminschicht ersetzt es den Scheduler vollständig für Pods, die schedulerName: volcano setzen. Das ermöglicht Gang Scheduling auf Platzierungsebene – der kritische Unterschied zu Kueue.

Bei verteiltem Training mit 64 parallelen Workern bringt ein einzelner ausstehender Pod den gesamten Job zum Stillstand. Volcano stellt sicher, dass alle Pods eines Jobs gleichzeitig gestartet werden, und kann bei Bedarf auch präemptieren. Dazu kommen GPU-Sharing-Mechanismen wie softwarebasiertes vGPU, dynamische MIG-Partitionierung und die Integration mit HAMi für hart isolierte Bruchteile einer GPU.

Für dedizierte Trainingscluster mit großen, kommunikationsintensiven Jobs ist Volcano die reifste Lösung. Die Netzwerk-Topologie-Awareness reduziert Switch-übergreifenden Traffic bei parallelem Training – ein Vorteil, den Kueue nicht bietet.

KAI Scheduler: GPU-zentriert aus der NVIDIA-Schmiede

Der KAI Scheduler (v0.17, September 2026) stammt aus demselben Codebase wie NVIDIAs kommerzielle Run:ai-Plattform und wurde als Open-Source-Projekt veröffentlicht. Seit Dezember 2025 ist er CNCF-Sandbox-Projekt.

KAI läuft als optionaler Zweitscheduler neben kube-scheduler und übernimmt nur Pods, die explizit schedulerName: kai-scheduler setzen. Seine spezifischen Stärken liegen in der GPU-Belegung: Fraktionale GPUs erlauben mehrere Inference-Workloads auf einer Karte, hierarchische Queues mit fairem Teilen und Rückholmechanismen erben die jahrelange Produktionserfahrung von Run:ai, und die NVLink-Domain-Awareness platziert Multi-GPU-Jobs innerhalb desselben Fabric-Islands.

Gerade für gemischte Cluster mit Trainings- und Inferenz-Workloads ist KAI ein starkes Argument. Die fein abgestuften Fair-Share-Mechanismen mit zeitbasierter Neugewichtung sind für GPU-Cluster das ausgereifteste Multi-Tenancy-Modell der drei Projekte.

Entscheidungsmatrix für die Praxis

Die Wahl hängt vom Clustertyp ab:

Szenario Empfehlung
Managed Cloud (EKS, AKS, GKE), gemischte Workloads Kueue
Dedizierter Trainingscluster mit großen, verteilten Jobs Volcano
GPU-dichter Cluster, hohe Auslastung als Ziel KAI Scheduler
Große Multi-Team-Plattform Kueue + Volcano (Kueue steuert Aufnahme, Volcano platziert)

Die Kombination von Kueue und Volcano ist dabei kein Widerspruch: Kueue entscheidet über die Zulassung in die Warteschlange, Volcano übernimmt die tatsächliche Pod-Platzierung – ein dokumentiertes Enterprise-Muster, das die Stärken beider Projekte vereint.

Fazit

GPU-Scheduling auf Kubernetes ist 2026 kein Randthema mehr, sondern eine operative Notwendigkeit. Kueue, Volcano und KAI Scheduler adressieren unterschiedliche Ebenen des Problems: Kueue die Quotenverwaltung und Job-Aufnahme, Volcano die Batch-optimierte Platzierung und KAI die GPU-zentrierte Fairness. Wer heute einen KI-gestützten Kubernetes-Cluster betreibt, sollte sich mindestens für eines der drei Projekte entscheiden – die Zeit des „einfach nvidia.com/gpu setzen und hoffen" ist vorbei. Die Hardware ist zu teuer, und die Teams sind zu viele.

Quellen

🤖 Dieser Beitrag wurde KI-gestützt erstellt und redaktionell geprüft.