Kubernetes 1.36 gibt KI- und Batch-Jobs ein gemeinsames Scheduling-Modell

Für Leser ohne tiefen Kubernetes-Kontext: Der Kubernetes-Scheduler entscheidet, auf welchem Node ein Pod laufen soll. Für klassische Web- oder API-Workloads funktioniert dieses Pod-für-Pod-Denken oft gut. Bei eng gekoppelten Paralleljobs, etwa AI-Training, Batch-Verarbeitung oder verteilten Simulationen, reicht das aber häufig nicht aus, weil mehrere Pods gleichzeitig, mit passender Topologie und gemeinsam reservierten Ressourcen starten müssen.

Genau hier setzt Kubernetes v1.36 an. Das Release vom 13. Mai 2026 führt die nächste Stufe des workload-aware scheduling ein. Statt nur einzelne Pods nacheinander zu bewerten, kann der Scheduler Gruppen zusammenhängender Arbeit gezielter betrachten. Für Plattformteams ist das keine kleine API-Kosmetik, sondern ein Signal, dass Kubernetes bei AI-, Batch- und anderen eng gekoppelten Jobs endlich ein belastbareres Betriebsmodell vorbereitet.

Warum klassisches Pod-für-Pod-Scheduling bei Paralleljobs an Grenzen stößt

Die Schwäche des alten Musters zeigt sich immer dann, wenn ein Job nicht sinnvoll halb anlaufen kann. Ein verteiltes Training mit mehreren Worker-Pods gewinnt wenig, wenn nur ein Teil der Pods freie Nodes findet, der Rest aber in der Queue bleibt. Dann sind Ressourcen bereits belegt, aber die eigentliche Arbeit kommt nicht voran. Ähnliche Reibungen entstehen bei stark parallelisierten Batch-Läufen, Render-Jobs oder verteilten Testumgebungen, in denen Pods gemeinsam starten, miteinander sprechen oder auf dieselbe Hardwareklasse zugreifen müssen.

Bislang mussten Teams solche Situationen oft über Zusatzlogik, externe Scheduler-Erweiterungen oder viel eigenes Controller-Verhalten entschärfen. Das konnte funktionieren, blieb aber operativ mühsam: mehr Spezialwissen, mehr Debugging-Fläche und mehr Risiko, dass Scheduler, Controller und Workload-Logik nicht sauber zusammenpassen. Kubernetes versucht mit v1.36 deshalb nicht bloß, einzelne Filter oder Scores zu verfeinern, sondern führt ein Modell ein, in dem der Scheduler den Zusammenhang zwischen mehreren Pods besser versteht.

Was sich in Kubernetes 1.36 konkret ändert

Die wichtigste Änderung ist die Trennung zwischen Workload und PodGroup. Laut offiziellem Kubernetes-Blog wird die Workload-API in scheduling.k8s.io/v1alpha2 nun als statische Vorlage genutzt, während die PodGroup den Laufzeitzustand und die konkrete Scheduling-Policy trägt. Das klingt technisch, ist aber architektonisch wichtig: Der Scheduler muss nicht mehr indirekt über ein einziges, gemischtes Objekt arbeiten, sondern kann direkt mit dem Runtime-Objekt operieren, das alle relevanten Informationen für die Gruppe enthält.

Dazu kommt ein eigener PodGroup-Scheduling-Zyklus. Wenn ein Mitglied einer solchen Gruppe aus der Scheduling-Queue gezogen wird, kann der Scheduler die übrigen zugehörigen Pods gemeinsam betrachten, einen einheitlichen Snapshot des Clusterzustands verwenden und die Entscheidung atomar für die ganze Gruppe anwenden. Genau dieser Punkt ist für eng gekoppelte Workloads entscheidend. Er reduziert die Gefahr, dass einzelne Pods verteilt werden, obwohl der Gesamtjob in dieser Form noch gar nicht sinnvoll lauffähig ist.

Kubernetes v1.36 erweitert das Modell außerdem um erste workload-aware Preemption-Mechanismen, topology-aware scheduling und ResourceClaim-Support für Dynamic Resource Allocation. Praktisch heißt das: Das Projekt denkt Gruppenarbeit nicht nur als Startlogik, sondern auch mit Blick auf Hardwareplatzierung, Unterbrechungen und spezialisierte Ressourcen weiter. Für Teams mit GPU-, Accelerator- oder High-Performance-Workloads ist das ein Hinweis, dass Kubernetes hier nicht mehr nur generische Container-Orchestrierung liefern will.

Warum die Job-Controller-Integration wichtiger ist als die API selbst

Die vielleicht praktischste Neuerung liegt in der ersten Integration mit dem Job-Controller. Wenn das Feature Gate WorkloadWithJob aktiviert ist, kann der Controller für passende Jobs die Workload- und PodGroup-Objekte selbst erzeugen und die Pods direkt mit der neuen Scheduling-Gruppe verknüpfen. Für Plattformteams ist das entscheidend, weil damit ein Teil der neuen Logik aus der Bastelzone herauskommt. Wer eng gekoppelte parallele Jobs betreibt, muss nicht jede Referenz und jedes Gruppenobjekt manuell zusammensetzen, sondern kann mit Bordmitteln experimentieren.

Allerdings setzt Kubernetes dafür aktuell klare Grenzen. Der erste Integrationsschritt greift nur bei Jobs mit fester Form: mehr als ein paralleler Pod, Indexed Completion Mode und identische Werte für parallelism und completions. Das zeigt zweierlei. Erstens meint es das Projekt ernst mit realer Controller-Integration. Zweitens ist das Ganze noch kein Allzweckwerkzeug für jede dynamische Workload. Elastic Jobs und komplexere Controller stehen laut Blog erst auf der Folgeliste für kommende Releases.

Was Teams daraus jetzt operativ ableiten sollten

Der größte Fehler wäre, die Neuerung nur als spannende Zukunftsmusik für AI-Plattformen abzulegen. Auch klassische Plattform- und Cloud-Ops-Teams sollten prüfen, welche Jobs im eigenen Umfeld heute faktisch gruppenabhängig sind, aber vom Cluster noch wie lose Einzelpods behandelt werden. Dazu gehören nicht nur Trainingsläufe, sondern oft auch Build- oder Testfarmen, Batch-Simulationen, Datenverarbeitung und andere Paralleljobs mit starker Synchronisationslogik.

Genauso wichtig ist aber die Einordnung des Reifegrads. Die Funktionen sind in v1.36 ausdrücklich Alpha und erfordern Feature Gates auf mehreren Komponenten, darunter kube-apiserver, kube-scheduler und je nach Teilfunktion weitere Kontrollpfade. Wer das sofort als Produktionsstandard liest, überzieht. Der sinnvolle Schritt ist ein Testcluster oder ein klar begrenzter Plattformpfad, in dem Scheduling-Verhalten, Ressourcenauslastung und Fehlermuster gezielt beobachtet werden. Denn ein besseres Scheduling-Modell nützt nur dann, wenn Teams auch verstehen, welche Jobs dafür geeignet sind und wie ihre Controller, Policies und Monitoring-Sichten darauf reagieren.

Unterm Strich ist Kubernetes 1.36 deshalb vor allem eine strategische Richtungsentscheidung. Das Projekt bewegt sich weg von der stillen Annahme, dass jede Arbeit sinnvoll in isolierten Pod-Entscheidungen aufgeht. Für moderne Cluster ist das überfällig. Wer heute Plattformen für AI, Batch oder andere eng gekoppelte Parallelverarbeitung baut, sollte workload-aware scheduling nicht als Randfeature lesen, sondern als frühen Bauplan für ein Kubernetes, das zusammengehörige Arbeit endlich auch als zusammengehörige Arbeit behandelt.