Kubernetes bindet GPU-Jobs erst, wenn alle Pods passen

Ein GPU-Job aus acht Pods, der nur vollständig rechnen kann, blockiert teure GPUs, sobald der Scheduler sieben davon einzeln auf Knoten legt. Kubernetes 1.37 bringt genau diese All-or-nothing-Planung als Beta in den Kern: Der Scheduler bindet die Gruppe erst, wenn jedes Mitglied Platz hat. Kueue und Volcano bleiben für Quota, Fair-Share und Cluster-übergreifende Warteschlangen nötig.

Das Wichtigste in Kürze

Verwandt:DRA-Stabilität zwingt GPU-Workloads zum Umdenken  /  Kubernetes 1.34 und Knative: reif für KI-Workloads?

Was ist Gang-Scheduling? All-or-nothing-Planung: Der Scheduler bindet eine Gruppe von Pods erst, wenn jedes Mitglied einen Platz hat. Fehlt ein Pod, bleibt die Gruppe stehen.

PodGroups starten erst, wenn jedes Mitglied Platz hat

Kubernetes v1.37.0 mit dem Codenamen Garhwal liegt seit dem 26. August 2026 als unterstützte Version vor und enthält 67 Erweiterungen. Für den Betrieb zählt eine kleinere Menge davon, weil sich dort ändert, was mit Jobs passiert, die nur als Gruppe Sinn ergeben.

Trainingsläufe, verteilte Inferenz und parallele Rechenjobs nach dem MPI-Modell teilen sich denselben Fehler. Der Scheduler platziert die ersten Pods auf teuren GPU-Knoten. Der letzte Pod wartet auf Kapazität. Die schon laufenden Instanzen halten Speicher und Karten, ohne eine nutzbare Epoche zu rechnen. Bisher lag die Antwort außerhalb des Kerns. Kueue, Volcano und Coscheduling-Plugins haben diese Gruppen zusammengehalten. Kubernetes 1.37 übernimmt die Grundform dieser Gruppenbindung in den Scheduler.

Die Workload- und PodGroup-APIs stehen in dieser Version als Beta in der Versionslinie v1beta1 bereit, Gang-Scheduling gehört dazu. Eine PodGroup beschreibt, wie viele Pods zusammenstehen müssen, bevor der Scheduler sie bindet. Das ist der Mechanismus, den GPU-Jobs brauchen, ohne dass jedes Team ein eigenes Queueing-Produkt als Pflichtschicht betreibt.

Die Umsetzung geht über eine API-Hülle hinaus, wie das Kubernetes-Projekt am 8. September 2026 im Blog zum workload-bewussten Scheduling beschreibt. Die native PodGroup-Queue stellt nur die oberste Gruppe in die Warteschlange statt jeden Pod der Gruppe einzeln. Die Untergrenze minCount, also wie viele Pods mindestens zusammenstehen müssen, lässt sich nachträglich ändern. Eine elastische Gang kann deshalb wachsen oder schrumpfen, ohne die schon geplanten Pods neu zu starten. Workload-Aware Preemption und geteilte ResourceClaims für PodGroups sind ebenfalls Beta. Dynamic Resource Allocation mit Extended Resources ist in 1.37 sogar GA: Ein Pod kann eine GPU über den klassischen Extended-Resource-Namen anfordern und landet über DRA auf einem Gerät, ohne paralleles Device-Plugin. Das setzt einen installierten DRA-Treiber für die Karten voraus.

Der Scheduler übernimmt damit Gruppenbindung und Geräteanforderungen. Fair-Share über Teams bleibt draußen. Genau deshalb bleibt Kueue im Produktivcluster nötig.

Kueue bleibt, wo der Kern noch Beta ist

Kueue bleibt relevant, obwohl Kubernetes jetzt Pod-Gruppen kennt. Kueue verteilt Quota, Fair-Share und Cluster-übergreifende Warteschlangen, Volcano bringt Batch-Politiken mit, die der Scheduler in 1.37 nicht nachbaut. Gang-Scheduling im Kern entkräftet nur die Begründung, GPU-Jobs starteten ohne Add-on unvollständig. Die Begründung über Quota und Fair-Share gilt unverändert.

CompositePodGroup ist in 1.37 Alpha. Hierarchische Gruppen, die eine Training-Gang einer größeren Batch-Gruppe unterordnen, sind damit Absicht und noch kein Lieferstand, für solche Hierarchien bleibt ein Add-on nötig. Alpha-Tester aus der Vorgängerlinie treffen außerdem auf einen Bruch: Mit 1.37 ersetzt PodGroup v1alpha3 die Fassung v1alpha2. disruptionMode (das Verhalten bei einer Störung der Gruppe) kennt jetzt die Werte all (ganze Gruppe) und single (einzelnes Mitglied). Cluster, die die Alpha-APIs schon produktiv genutzt haben, müssen diese Umbenennung nachziehen.

Die Beta-API ist breit genug für Tests in einem eigenen Pool, mit Feature-Gates und mit der Erwartung, dass sich Felder vor der allgemeinen Verfügbarkeit noch verschieben. Sie ersetzt Kueue nicht als Ort der Team-Quota. Der Job-Controller spricht Workloads über das Feature-Gate WorkloadWithJob auf kube-apiserver und kube-controller-manager an, der Einstieg über Jobs läuft also in einem Testpool und nicht auf dem Produktiv-Scheduler aller Namespaces.

Auch die Node-Lifecycle-Conditions sind in 1.37 noch unfertig. Kubernetes reserviert dafür fünf Bedingungen mit Namen wie DrainInProgress (Entleerung läuft) und MaintenancePlanned (Wartung geplant). Das Feature-Gate ist Alpha, deshalb liest noch kein Kern-Controller diese Bedingungen. Ein Drain-Werkzeug schreibt damit vorerst nur Metadaten für spätere Releases.

Idle GPUs gehen nur mit der richtigen Metrik auf null

Neben der Planung bestimmt die Skalierung auf null die GPU-Kosten. Der HorizontalPodAutoscaler darf in 1.37 Workloads auf null Replikas skalieren. Die Funktion ist laut Kubernetes-Blog vom 2. September 2026 Beta und in kube-apiserver sowie kube-controller-manager standardmäßig aktiv, minReplicas 0 ist damit kein Alpha-Schalter mehr. Der API-Server akzeptiert den Wert. Sobald die Metrik unter die Schwelle fällt, fährt der Controller den Workload herunter. Steigt sie wieder, holt er ihn zurück.

CPU und Speicher reichen für den Weg auf null nicht, weil der API-Server ein HPA ablehnt, das nur Resource-Metriken enthält. Objekt-Metriken oder External-Metriken sind die Bedingung, etwa eine Queue-Länge, eine eigene Metrik aus dem Inference-Serving oder eine externe Lastkennzahl. Ohne diese Quelle bleibt der letzte Pod stehen und die GPU bleibt belegt.

Das Downscale-Fenster bis auf null liegt im HPA-Standard bei fünf Minuten. Bei einem kurz leeren Batch bleiben die GPUs also noch belegt. Bei Inference-Spitzen im Minutentakt geht dieses Fenster direkt in die Kostenrechnung ein. Die Statusbedingung ScaledToZero (auf null skaliert) unterscheidet den automatischen Rückzug von einem manuellen Pause-Zustand. Das ist der Unterschied zwischen „der Controller hat abgeschaltet“ und „jemand hat den Replica-Stand auf null gedrückt“.

Native Histograms für Kubernetes-Metriken sind in 1.37 ebenfalls Beta und standardmäßig aktiv. Feinere Latenzverteilungen ändern, wie Autoscaler und Dashboards Last sehen, sie ersetzen aber die Queue-Metrik nicht, die HPA für den Weg auf null braucht.

Der nächste Patch 1.37.1 folgt nach dem Patch-Kalender des Projekts in den ersten Wochen nach dem Release. Bis dahin bleibt der Testpool der Ort für Gang-Scheduling und für HPA auf null.

Häufige Fragen

Bildquelle: KI-generiert (September 2026)