Kubernetes 1.37 Garhwal: Drei Breaking Changes, die Cluster-Betreiber jetzt kennen müssen

📷 "Docker HQ, San Francisco, California" by willbuckner is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Kubernetes 1.37 „Garhwal“ ist da — und mit ihr drei Breaking Changes, die Cluster-Betreiber nicht ignorieren sollten. Am 26. August 2026 hat das Kubernetes-Projekt die 37. Minor-Version freigegeben, benannt nach der Garhwal-Himalaya-Region in Uttarakhand, Indien. 67 Enhancements sind in diesem Release enthalten: 16 erreichen Stable, 23 sind auf Beta gewachsen, 27 starten als Alpha und eine Deprecation ist formalisiert. Für die meisten Cluster ist das Upgrade eine Routineangelegenheit. Drei Änderungen jedoch können einen reibungslosen Update-Pfad massiv stören — oder den Kubelet komplett am Starten hindern.

cgroup v1: Der harte Stopp

Die operationell folgenreichste Änderung betrifft den Linux-Kernel-Mechanismus cgroup v1. Seit Kubernetes 1.35 ist das Feature-Gate failCgroupV1 standardmäßig auf true gesetzt. Das bedeutet: Der Kubelet startet ab 1.37 schlichtweg nicht mehr auf Knoten, die noch cgroup v1 verwenden, es sei denn, der Admin setzt explizit das Override --fail-on-cgroup-v1=false. Dieses Override wird aber nur temporär existieren — die vollständige Entfernung von cgroup v1 im Kubelet ist bereits geplant.

Die gute Nachricht: Cgroup v2 ist auf allen modernen Linux-Distributionen längst Standard. Ubuntu 22.04+, Debian 12, Fedora 31+ und RHEL 9 booten standardmäßig mit v2. Das Risiko tragen Cluster mit älteren Basis-Images — Ubuntu 20.04, Debian 11, RHEL 8 oder selbstgebaute Images, die noch auf der alten cgroup-API hängen.

Jeder Admin sollte vor dem Control-Plane-Upgrade jeden Knoten prüfen:

stat -fc %T /sys/fs/cgroup/
# „cgroup2fs" = cgroup v2 (sicher)
# „tmpfs" = cgroup v1 (Handlungsbedarf)

Der Kubernetes-Release-Blog empfiehlt für betroffene Nodes ein OS-Upgrade auf eine Distribution mit cgroup-v2-Standard. Das temporäre Override ist nur als Migrationshilfe gedacht.

IPVS kube-proxy-Modus: Der Countdown läuft

Kube-proxy in IPVS-Modus ist in 1.37 formal als deprecated markiert. Seit Kubernetes 1.11 im Jahr 2017 als leistungsfähigere Alternative zu iptables eingeführt, wird IPVS nun zugunsten des neueren nftables-Backends zurückgestellt. Nftables setzt auf set-basierte Lookups, die ohne das Kernel-Modul ip_vs und die Userspace-Tools ipvsadm auskommen. Die tatsächliche Entfernung ist für Kubernetes 1.39 (voraussichtlich Mitte 2027) geplant.

Zur Prüfung des aktuellen Proxy-Modus:

kubectl -n kube-system get configmap kube-proxy -o yaml | grep mode
# oder
ps aux | grep kube-proxy | grep -o '\-\-proxy-mode=[a-z]*'

Wer noch mode: ipvs sieht, sollte die Migration zu mode: nftables (bevorzugt ab Kernel 5.13) oder zurück zu mode: iptables planen. Die Migration erfolgt über ein ConfigMap-Update und einen Rolling-Restart des kube-proxy-DaemonSets – ein überschaubarer Aufwand, der aber nicht aufgeschoben werden sollte.

Static Pods: Keine Secrets mehr

Die vermutlich tückischste Änderung: Static Pods, die der Kubelet direkt aus Manifest-Dateien im Verzeichnis /etc/kubernetes/manifests/ verwaltet, dürfen ab 1.37 keine Secret- oder ConfigMap-Referenzen mehr enthalten. Der Feature-Gate PreventStaticPodAPIReferences, der diese Einschränkung zuerst optional machte, wurde entfernt. Das Verhalten ist nun nicht mehr konfigurierbar, sondern zwingend.

Der Grund ist nachvollziehbar: Static Pods starten unter anderem die Control-Plane-Komponenten (etcd, API-Server, Controller-Manager), bevor das Cluster vollständig bootstrapped ist. Ein Bootstrap-Pfad, der für die eigenen Secrets das Secret API benötigt, ist ein Huhn-Ei-Problem. Wer bisher etcd-Zertifikate oder Admission-Webhook-Credentials per secretRef in Static-Pod-Manifeste eingebunden hat, muss diese als Dateien direkt auf den Node legen oder den Workload in ein reguläres Deployment umziehen.

SELinuxMount GA: Standardmäßig aktiv

Eine Änderung, die keine Deprecation ist, aber ähnliche Aufmerksamkeit verdient: SELinuxMount erreicht Stable und ist ab 1.37 standardmäßig aktiv. CSI-getriebene Volumes werden nicht mehr rekursiv umgelabelt, sondern mit der Option -o context=<label> gemountet. Das ist ein Performancesprung bei großen Volumes. Die Kehrseite: Teilen sich zwei Pods mit unterschiedlichen SELinux-Kontexten dasselbe Volume auf einem Node – was unter dem alten, rekursiven Verhalten funktioniert hat –, kann dies nach dem Upgrade scheitern. Workarounds per seLinuxChangePolicy: Recursive pro Pod sind möglich. Auf Clustern ohne SELinux-Enforcement hat die Änderung keine Auswirkungen.

Was noch wichtig ist

Neben den Breaking Changes bringt 1.37 einige nennenswerte Neuerungen. Der metrics.k8s.io-API erreicht Stable – nach fast neun Jahren im Beta-Stadium. Der HorizontalPodAutoscaler kann jetzt auf null Replicas skalieren (Beta, standardmäßig aktiv) – ein echter Hebel für Kosteneinsparungen bei Batch- und Queue-Workern. Der Kubelet im User Namespace (Rootless Mode) geht in Beta, ein wichtiger Schritt zur Reduzierung der Node-Angriffsfläche. Neu in Alpha sind unter anderem die CompositePodGroup-API für das Gruppieren von Pods und eine topologiebewusste Volume-Snapshot-Funktion.

Fazit

Kubernetes 1.37 ist ein Release mit hohem Signal-Rausch-Verhältnis. Wer die cgroup-v1-Auditierung, die IPVS-Migration und den Static-Pod-Check vor dem Upgrade durchführt, wird von den neuen Features profitieren, ohne böse Überraschungen zu erleben. Die drei Breaking Changes sind keine Überraschungen – sie wurden lange angekündigt –, aber sie erfordern jetzt konkretes Handeln. Die Upgrade-Checkliste ist kurz und überprüfbar: Überprüfe cgroup v2 auf allen Nodes, stelle auf nftables um und scanne Static-Pod-Manifeste auf Secret-Referenzen. Wer das erledigt hat, kann 1.37 entspannt in Produktion bringen.