Kubernetes 1.37 Garhwal: HPA Scale-to-Zero, Gang Scheduling und 18 entfernte Kubelet-Flags

📷 "Cloud Computing - Abstract 2" by perspec_photo88 is licensed under CC BY-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.0/.

Seit dem 26. August 2026 ist Kubernetes 1.37 “Garhwal” verfügbar – mit 67 Enhancements, von denen 16 den Stable-Status erreicht haben. Das Release trägt den Namen der Garhwal-Region im indischen Himalaja und setzt vor allem auf Konsolidierung: Eine API, die seit neun Jahren in Beta stand, wird endlich stabil; der HorizontalPodAutoscaler kann Workloads auf null Replikas herunterskalieren; und Gang Scheduling für KI/ML-Jobs erreicht den Beta-Status. Wer einen Cluster betreibt, sollte sich auf einige Breaking Changes einstellen.

HPA Scale-to-Zero: Workloads schlafen, wenn sie nicht gebraucht werden

Die vielleicht wichtigste Neuerung für den Betrieb ist der skalierte HorizontalPodAutoscaler (HPA). Ab Kubernetes 1.37 kann ein HPA Workloads auf null Replikas herunterskalieren – Beta-Status, standardmäßig aktiviert. Voraussetzung ist die Verwendung von Object- oder External-Metriken, da CPU- und Memory-Metriken auf laufende Pods angewiesen sind. Der Trick: Eine Queue-Länge existiert unabhängig von den Workern, die sie abarbeiten. Der HPA kann diesen Wert auch bei null Pods weiterlesen und bei Bedarf neue Replikas starten.

Der Anwendungsfall ist klar: Queue-Consumer, Batch-Jobs und GPU-Workloads, die zwischen Bursts untätig sind, verbrauchen dann schlicht keine Ressourcen mehr. Ein ScaledToZero-Status am HPA-Objekt unterscheidet dabei zuverlässig zwischen “vom Controller herunterskaliert” und “manuell auf null gesetzt”.

Gang Scheduling: KI/ML-Jobs als Einheit planen

Distribuierte Trainingsjobs scheitern oft daran, dass ein Teil der Pods platziert wird, der Rest aber in der Warteschleife hängt – der Job kommt nicht voran, blockiert aber Ressourcen. Gang Scheduling (KEP-4671) löst dieses Problem durch das PodGroup-Konzept: Die Scheduler erhält die Information, dass acht Pods gemeinsam gestartet werden müssen, und wartet, bis für alle genug Kapazität da ist.

Neu hinzugekommen ist zudem workload-aware Preemption (KEP-5710), das verhindert, dass sich konkurrierende Workloads gegenseitig endlos verdrängen. Für Plattform-Teams, die Ray, JobSet oder LWS betreiben, ist dies der nächste Schritt zu einer produktionsreifen KI-Plattform auf Kubernetes.

Metrics API wird nach neun Jahren stabil

Die metrics.k8s.io-API war seit Kubernetes 1.8 in Beta – das sind knapp neun Jahre. Mit 1.37 ist sie als v1 stabil. Das API-Surface ändert sich nicht, es ist eine reine Versions-Graduierung, aber sie sendet ein klares Signal: Die Ressourcen-Metrik-Infrastruktur von Kubernetes ist produktionsreif. kubectl top nutzt bereits bevorzugt die v1-Version mit Fallback auf v1beta1.

Breaking Changes: 18 Kubelet-Flags fallen weg

Das Upgrade auf 1.37 erfordert Vorbereitung. Die Migration des eingebetteten cAdvisors zu einem schlanken cadvisor/lib-Modul (PR #139870) entfernt 18 Kubelet-Flags – darunter --containerd, --containerd-namespace, --boot-id-file und --enable-load-reader. Ein Kubelet, das eines dieser Flags übergibt, startet mit unknown flag gar nicht erst. Nodes, die aus der Verwaltung per kubeadm-flags.env oder systemd-drop-in konfiguriert sind, müssen vor dem Upgrade bereinigt werden.

Ebenfalls entfernt: Die alte IPVS-Unterstützung in kube-proxy weicht endgültig nftables, und failCgroupV1 ist weiterhin standardmäßig aktiv. Container-Runtimes müssen containerd 2.x verwenden – containerd 1.x wird nicht mehr unterstützt.

DRA und Spezial-Hardware werden erwachsen

Dynamic Resource Allocation (DRA) erhält vier Stable-Graduierungen in einem Release – das zeigt, dass GPUs, Beschleuniger und spezielle Netzwerkadapter nun First-Class-Citizens im Kubernetes-Ressourcenmodell sind. Der standardisierte DRA-Attribut resource.kubernetes.io/numaNode erlaubt eine konsistente NUMA-Topologie-abhängige Platzierung. Neu im Alpha-Status ist zudem die ulimits-Konfiguration pro Container über das Container.SecurityContext-Feld – ein lang erwartetes Feature für Datenbanken und hochkonkurrierende Workloads.

Sicherheit: Pod-Zertifikate und SELinux beim Mount

Pod-Zertifikate (PodCertificateRequest) sind mit 1.37 stabil. Statt langlebige Secrets zu mounten, kann der Kubelet kurzlebige X.509-Zertifikate anfordern und regelmäßig rotieren – ein natives Workload-Identity-System. Ebenfalls stabil: SELinuxMount. Statt vor jedem Pod-Start das gesamte Volume rekursiv umzulabeln, setzt Kubernetes das Linux-Kernel-native -o context-Flag und weist das korrekte SELinux-Label direkt beim Mount zu. Das beschleunigt Pod-Starts mit großen Datensätzen massiv.

Fazit

Kubernetes 1.37 ist kein spektakuläres Release, aber ein notwendiges. Es räumt neun Jahre alte Beta-API auf, entfernt Ballast aus der Kubelet-Konfiguration und gibt Platform Engineers echte Werkzeuge für KI-Workloads und Kostenkontrolle an die Hand. Wer GPU-Cluster oder queue-basierte Verarbeitung betreibt, profitiert direkt. Vor dem Upgrade sollte jeder Betreiber seine Kubelet-Flags inventarisieren, auf containerd 2.x wechseln und cgroup v2 sowie nftables vorbereiten. Kubernetes 1.38 ist für Dezember 2026 angekündigt – die Richtung ist klar: KI-gerechte Ressourcenverwaltung bei gleichzeitiger Vereinfachung des Node-Stacks.