Kubernetes 1.37 „Garhwal“: Neues GPU-Scheduling für KI-Workloads

YuSMP Group Editorial Team Redaktion, YuSMP Group

Das Wichtigste in Kürze

Was in Kubernetes 1.37 enthalten ist

Kubernetes erscheint etwa alle vier Monate; 1.37 „Garhwal“ (benannt nach der Himalaya-Region in Uttarakhand) kam am 26. August 2026. Die 67 Erweiterungen verteilen sich auf 16 Stable, 23 Beta und 27 Alpha, dazu eine Abkündigung. Kubernetes führt den Reifegrad sehr genau: Stable heißt, die API ist eingefroren und produktionstauglich; Beta heißt, die API kann sich noch geringfügig ändern, ist aber für breite Tests bereit.

Das Leitthema des Releases ist die Effizienz von GPU- und Beschleuniger-Workloads. Beide Kernfunktionen – DRA Device Taints und Gang Scheduling – adressieren Fehlerbilder, die Teams beim Training und bei der Inferenz großer Sprachmodelle immer wieder treffen: ein defekter GPU-Node, der den Job still blockiert, und eine Teilplatzierung von Pods, die das Beschleuniger-Budget verbrennt. Die Community rund um Kubernetes-Engineering behandelt diese Probleme seit der KI-Rechenwelle als erstrangig; mit 1.37 verlassen die Antworten der Control Plane den Alpha-Status.

DRA Device Taints: Defekte GPUs automatisch umgehen

Dynamic Resource Allocation (DRA) ist das Kubernetes-Framework für Beschleuniger und Spezialhardware. In 1.37 erhält DRA Device Taints als Stable – denselben Taint/Toleration-Mechanismus, den Cluster-Betreiber bereits für Scheduling-Vorgaben auf Node-Ebene nutzen, nur direkt auf einzelne GPUs oder Beschleuniger angewendet.

In der Praxis kann ein Device-Plugin (oder der DRA-Treiber) eine bestimmte GPU als NoSchedule oder NoExecute markieren, sobald es Hardwarefehler, ECC-Speicherfehler oder thermisches Throttling erkennt. Der Scheduler platziert dann keine neuen Pods mehr, die dieses Gerät anfordern, und laufende Pods ohne passende Toleration können verdrängt werden. Die defekte GPU wird automatisch umgangen; niemand muss den Node drainen oder manuell cordonen.

Warum zählt das im großen Maßstab? In großen Trainingsclustern – etwa 64 bis 256 Nodes mit H100 oder B200 – kann eine einzige degradierte GPU einen kompletten Multi-Node-Trainingsjob anhalten oder still falsche Ergebnisse liefern. Vor DRA Device Taints mussten Betreiber den GPU-Zustand außerhalb des Clusters überwachen, manuell eingreifen und Jobs neu einreihen. Mit stabilen DRA Device Taints übernimmt das die Control Plane: Das fehlerhafte Gerät wird markiert, neue Arbeit wird umgeleitet, und der Job läuft auf gesunder Hardware weiter. Bei 2–3 US-Dollar pro GPU-Stunde bedeutet diese Automatisierung direkt zurückgewonnenes Rechenbudget.

Gang Scheduling: Pods nach dem Alles-oder-nichts-Prinzip platzieren

Gang Scheduling – oder Workload-aware Preemption – löst das Problem der Teilplatzierung: Ein verteilter Trainingsjob fordert N GPU-Worker-Pods an, aber nur N-2 lassen sich platzieren, weil zwei Nodes belegt sind. Ohne Gang Scheduling starten diese N-2 Worker, belegen ihren GPU-Speicher und warten untätig auf die Nachzügler. Mit Gang Scheduling platziert der Scheduler entweder alle N Pods gleichzeitig oder keinen und reiht den Job ein, bis Kapazität frei ist.

In Kubernetes 1.37 hat Gang Scheduling über Workload-aware Preemption Beta auf scheduling.k8s.io/v1beta1 erreicht. Mit der PodGroup-API lassen sich Pods als logische Einheit kennzeichnen; der Scheduler behandelt ihre Platzierung atomar. Braucht ein Job mit höherer Priorität die Ressourcen, wird die wartende PodGroup als Ganzes verdrängt, statt einzelne Pods über die Eviction-Queue zu verstreuen.

Der betriebliche Nutzen ist erheblich: Trainingsjobs lassen keine GPUs mehr leerlaufen, während sie auf Nachzügler warten, und die Gesamtauslastung der Beschleuniger steigt, weil keine halb platzierten Jobs Ressourcen blockieren. Bisher brauchte man dafür externe Scheduler wie Volcano oder YuniKorn. In 1.37 ist das im Kern verfügbar – also keine zusätzliche Control-Plane-Komponente, die mit dem Cluster versioniert, überwacht und aktualisiert werden muss.

Abkündigungen mit festen Fristen

Kubernetes 1.37 enthält zwei Abkündigungen mit verbindlichem Entfernungstermin – nicht „wird irgendwann entfernt“, sondern konkrete Ziel-Releases.

kube-dns abgekündigt; Entfernung in Kubernetes 1.40. CoreDNS ist seit Kubernetes 1.13 (2019) die Standard-DNS-Implementierung. kube-dns blieb als Option für Cluster, die älter als dieser Wechsel sind. Mit 1.37 kündigt das Projekt es formell ab und legt 1.40 als Entfernungs-Release fest. Für Nutzer von Managed-Kubernetes wie EKS, GKE oder AKS ist das meist kein Thema, diese Dienste nutzen seit Jahren CoreDNS. Selbst betriebene Cluster mit kube-dns-Installationen aus der 1.12-Ära sollten ihr DNS-Deployment vor dem nächsten Upgrade über 1.39 hinaus prüfen.

IPVS-Backend von kube-proxy abgekündigt; Entfernung in Kubernetes 1.43. IPVS war bei großen Clustern die leistungsstarke Alternative zu iptables. Das nftables-Backend, seit Kubernetes 1.33 stabil, ist jetzt der empfohlene Nachfolger. nftables setzt Linux 5.13 oder neuer voraus; prüfen Sie die Kernel-Version vor der Migration. Der Termin 1.43 lässt mehrere Release-Zyklen Zeit, aber die Umstellung erfordert einen kube-proxy-Neustart auf jedem Node – planen Sie sie, statt sich überraschen zu lassen.

Was das für Software-Teams in den USA und der EU bedeutet

Für Teams, die KI/ML-Produkte auf Cloud-Infrastruktur bauen, kommen die GPU-Verbesserungen genau zur richtigen Zeit. Die Ausgaben für Kubernetes-basierte Inferenz- und Trainingsinfrastruktur sind 2026 stark gestiegen, und der Engpass hat sich von der Modellqualität zur Betriebseffizienz verlagert: Wie hält man teure GPUs ausgelastet, wie fängt man Hardwareausfälle ohne Handarbeit ab, wie minimiert man Leerlauf in Trainingswarteschlangen?

DRA Device Taints und Gang Scheduling schließen gemeinsam zwei der häufigsten Ursachen für GPU-Verschwendung. Das eine automatisiert die Reaktion auf Ausfälle (Gerät markiert, Workload umgeleitet), das andere beseitigt die Fragmentierung, durch die halb platzierte Jobs leerlaufen. Teams mit verteiltem Training in Produktion spüren beides, ohne neuen Infrastruktur-Code zu schreiben: Cluster upgraden, den DRA-Treiber Taints melden lassen und PodGroups für Batch-Trainings definieren.

Die Abkündigungen sind eher eine Frage der Betriebshygiene als ein Notfall. Ein Cluster mit kube-dns hat noch zwei Release-Zyklen bis 1.40; richtig ist, die Migration in den nächsten Infrastruktur-Sprint aufzunehmen. Die nftables-Migration für IPVS-Nutzer liegt noch weiter entfernt (1.43), doch wegen der Kernel-Anforderung (Linux 5.13+) brauchen manche ältere VMs oder Bare-Metal-Hosts zuerst ein OS-Upgrade – prüfen Sie diese Abhängigkeit jetzt.

Was bedeutet das für den DACH-Markt?

Im DACH-Raum ist GPU-Kapazität knapp und teuer, und viele Unternehmen betreiben KI-Workloads aus Gründen der Datensouveränität und der DSGVO nicht bei US-Hyperscalern, sondern auf eigener Hardware oder bei europäischen Anbietern wie STACKIT, IONOS oder der Open Telekom Cloud. Gerade dort zahlt sich das neue In-Core-Scheduling aus: Wer jede GPU-Stunde selbst finanziert, verliert durch defekte Karten und halb platzierte Trainingsjobs bares Geld – und muss ohne Managed-Dienst auch kube-dns und IPVS selbst ablösen. Fragen Sie bei Managed-Angeboten europäischer Provider ausdrücklich nach, ab wann 1.37 verfügbar ist und welche GPU-Treiber dahinterstehen.

Für Banken und Versicherer gilt seit Januar 2025 der EU Digital Operational Resilience Act (DORA), der ein dokumentiertes IKT-Änderungsmanagement verlangt; viele Betreiber orientieren sich zusätzlich am IT-Grundschutz des BSI. Ein Upgrade, das DNS und Netzwerk-Backends berührt, sollte dort als geplante Änderung mit Testnachweis aus einer Vorstufe, Rollback-Plan und Freigabe laufen. 1.37 lässt genug Vorlauf, um die Migrationen von kube-dns und IPVS sauber durch diesen Prozess zu bringen.

Drei Aufgaben vor 1.38

1. DNS-Stack prüfen. kubectl get pods -n kube-system -l k8s-app=kube-dns ausführen. Erscheinen kube-dns-Pods, die Migration auf CoreDNS vor dem nächsten Upgrade über 1.39 hinaus einplanen. Die Anleitung in der Kubernetes-Dokumentation ist für die meisten Cluster unkompliziert; riskant sind Cluster mit eigenen Stub-Zonen, die portiert werden müssen.
2. DRA Device Taints in den GPU-Node-Pools aktivieren. Prüfen, ob die Version Ihres NVIDIA-, AMD- oder Google-Device-Plugins DRA-Taints melden kann. Der NVIDIA GPU Operator unterstützt ab 24.x die stabile DRA-API. Das Device-Plugin vor dem Upgrade auf 1.37 aktualisieren, damit Taints vom ersten Tag an gemeldet werden.
3. Gang Scheduling für die größten Trainingsjobs testen. Einen Staging-Cluster auf 1.37 aufsetzen und Multi-Worker-Trainingsjobs mit scheduling.k8s.io/pod-group annotieren. GPU-Auslastung vor und nach der Aktivierung messen – die Leerlaufreduktion ist meist schon im ersten vollständigen Jobzyklus sichtbar.

Häufige Fragen

Quellen

Kubernetes Project — Kubernetes v1.37 Release, 26 August 2026 (primary source)
The Register — Kubernetes cleans house, bins legacy kube-dns, IPVS and cgroup v1, 26 August 2026
Cloud Native Now — Kubernetes v1.37 Enhances Dynamic Resource Allocation, 2026