Die Kurzfassung
Kubernetes v1.37 „Garhwal“ (26. August 2026) bringt drei Breaking Changes, die eine sofortige Prüfung der Infrastruktur erfordern: (1) Nodes mit cgroup v1 starten das Kubelet nicht mehr – eine harte Sperre, keine Warnung; (2) kube-dns wird ausgemustert, Migrationsfrist ist v1.40; (3) für IPVS in kube-proxy läuft die Abkündigung bis zur Entfernung in v1.43. Positiv: Die metrics.k8s.io-API, auf der HorizontalPodAutoscaler und kubectl top aufbauen, wechselt nach neun Jahren Produktivbetrieb von Beta auf Stable (v1). Wer verwaltetes Cloud-Kubernetes mit aktuellen Node-Images nutzt, ist kaum betroffen. Selbst betriebene Cluster auf älteren Images sollten das Upgrade als Modernisierungsprojekt planen, nicht als Routine-Update.
67 Erweiterungen: was ausgeliefert wurde
Der Release-Zyklus von v1.37 dauerte 15 Wochen – vom 18. Mai bis 26. August 2026 – mit Beiträgen von 1.754 Personen aus 212 Unternehmen. Bilanz: 67 Erweiterungen, davon 16 auf Stable, 23 auf Beta, 27 neu im Alpha-Status und eine Abkündigung bzw. Entfernung. Benannt ist das Release nach „Garhwal“, einer Himalaya-Region im indischen Uttarakhand; das Logo zeigt schneebedeckte Gipfel und einen gewundenen Fluss – als Bild dafür, wie „jede Ebene, jede Route und jeder Beitrag verbunden“ ist.
Unter den weiteren Stable-Graduierungen sind für den Betrieb vor allem die KYAML-Ausgabe für kubectl, Ressourcendefinitionen auf Pod-Ebene sowie Taints und Tolerations auf Geräteebene für Dynamic Resource Allocation (DRA) relevant. Letzteres zählt besonders für Teams mit GPU- oder Beschleuniger-Workloads: DRA wird zum Grundmechanismus für heterogenes Hardware-Scheduling in KI/ML-Pipelines. Für Teams, die Kubernetes-Cluster produktiv betreiben, hängt die Upgrade-Entscheidung allerdings meist an den Breaking Changes, nicht an neuen Features – und davon gibt es diesmal drei.
Aus für cgroup v1: die harte Sperre
Seit Kubernetes v1.35 erzeugen Nodes mit cgroup v1 beim Start Warnungen. In v1.37 wird daraus Ernst: Erkennt das Kubelet beim Start cgroup v1, wird der Node nicht initialisiert. Einen sanften Übergang gibt es nicht – wer einen betroffenen Cluster aktualisiert, legt diese Nodes sofort lahm.
Zur Prüfung auf jedem Node stat -fc %T /sys/fs/cgroup/ ausführen. Ausgabe tmpfs bedeutet cgroup v1, cgroup2fs bedeutet cgroup v2 – der Node ist sicher. Standardmäßig auf cgroup v1 laufen CentOS 7, RHEL 7 (EL7-Kernel 3.10) und Ubuntu 18.04. Die meisten verwalteten Node-Images bei EKS, GKE und AKS sind zwischen 2022 und 2023 auf cgroup v2 umgestiegen; Teams mit aktuellen, vom Cloud-Anbieter verwalteten Node-Pools sind daher in der Regel nicht betroffen.
Das Feld failCgroupV1: false in der KubeletConfiguration hebt die Sperre auf. Das Kubernetes-Projekt nennt das ausdrücklich gefährlich: Der Node verliert Memory-QoS, Pressure-Stall-Information-(PSI-)Metriken und Swap-Konfigurationen, die cgroup v2 voraussetzen, und das Feld verschwindet in einem künftigen Release. Es ist eine Absicherung für die Migration, keine Dauerlösung.
Der praktikable Weg: zuerst das Node-Image aktualisieren, dann die Kubernetes-Version. On-premises-Teams wechseln auf RHEL 8+, Rocky Linux, AlmaLinux 8+ oder Ubuntu 20.04+, Cloud-Teams mit selbst verwalteten Node-Gruppen aktualisieren AMI bzw. VM-Image. Der Aufwand für Cloud- und DevOps-Engineering ist real, aber gut eingrenzbar: cgroup v2 ist seit Jahren stabil, der Migrationspfad gut dokumentiert.
Zeitplan für kube-dns und IPVS
kube-dns wird in v1.37 ausgemustert. CoreDNS, seit Kubernetes 1.13 (2018) Standard, ersetzt es vollständig. Cluster mit kube-dns haben bis Kubernetes 1.40 Zeit – danach funktioniert das Cluster-DNS nicht mehr. Die Migration ersetzt das kube-dns-Deployment durch CoreDNS und überführt die ConfigMaps in Corefile-Syntax. Die meisten Managed-Kubernetes-Dienste haben das längst automatisiert. Sehen Sie kube-dns-Pods in kube-system, planen Sie die Migration für dieses Quartal ein.
Für IPVS in kube-proxy beginnt mit v1.37 die formale Abkündigung; die Entfernung ist für v1.43 geplant. Nachfolger ist nftables mit besserer Performance, ausdrucksstärkeren Regeln und aktiver Pflege upstream. Hat Ihr Netzwerkteam Monitoring, Alerting oder eigene Tools rund um IPVS-Zähler gebaut, planen Sie den Umstieg auf nftables vor v1.43 – rund vier Release-Zyklen bzw. etwa 12–18 Monate beim aktuellen Takt.
Metrics-API wird stabil
Die metrics.k8s.io-API, die CPU- und Speicherverbrauch von Pods und Nodes liefert, wechselt in v1.37 von Beta auf Stable (v1). Release Lead Dipesh Rawat benennt die Ironie direkt: Trotz Beta-Label werde die API seit Jahren breit produktiv eingesetzt. Auf ihr beruhen kubectl top nodes, kubectl top pods, der HorizontalPodAutoscaler (HPA) und der VerticalPodAutoscaler (VPA).
Praktisch heißt das: Die v1-Schnittstelle fällt jetzt unter die Kompatibilitätsgarantie von Kubernetes und ändert sich auf absehbare Zeit nicht inkompatibel. Der Hinweis im Runbook, dass der HPA an einer Beta-API hängt, kann entfallen.
Was das für Softwareteams in den USA und der EU bedeutet
Das Aus für cgroup v1 ist der dringendste Punkt dieses Releases. Anders als die meisten Breaking Changes, die API-Versionen oder Manifest-Schemas betreffen, trifft dieser die Node-Infrastruktur. Plattformteam und die Verantwortlichen für Node-Images – Cloud-Infrastruktur, On-prem-Betrieb oder wer immer VM-Images bereitstellt – müssen sich abstimmen. Engineering-Leads sollten den stat-Check noch diese Woche über alle Nodes laufen lassen und die Ergebnisse vor dem nächsten Upgrade-Fenster einordnen.
On-premises- und Hybrid-Cluster tragen das höchste Risiko. Wer Kubernetes auf älteren Enterprise-Distributionen betreibt, insbesondere auf Infrastruktur aus der RHEL-7-Ära, steht womöglich vor einer doppelten Migration: Betriebssystem und Kubernetes zugleich. In regulierten Branchen (FinTech, HealthTech, Versicherungen, öffentlicher Sektor) brauchen Major-Upgrades des Betriebssystems meist die Freigabe der Security, saubere Schwachstellenscans und teils ein Change Advisory Board. Diese Vorlaufzeit gehört jetzt in die Planung.
Die Fristen für kube-dns und IPVS sind weicher, aber nicht unbegrenzt. v1.40 bzw. v1.43 lassen einige Release-Zyklen Luft; die Punkte gehören dennoch in diesen Planungszyklus. Der Release-Takt von Kubernetes hat zugelegt – der Abstand zwischen komfortabler Reserve und harter Deadline schrumpft schneller als früher.
Was bedeutet das für Unternehmen im DACH-Raum?
Im DACH-Raum trifft das Release vor allem die eigenen Rechenzentren. Viele Mittelständler, Banken, Versicherer und Behörden betreiben Kubernetes on-premises oder bei regionalen Hostern – aus Gründen der Datensouveränität und der DSGVO oft bewusst ohne Hyperscaler. Genau dort laufen noch Nodes auf Images aus der CentOS-7- und RHEL-7-Zeit, deren regulärer Herstellersupport bereits im Juni 2024 ausgelaufen ist. Für diese Cluster ist 1.37 kein Kubernetes-Update, sondern ein Betriebssystem-Projekt.
Regulatorisch passt die Migration ohnehin ins Pflichtenheft. Finanzunternehmen unterliegen seit Januar 2025 DORA, Einrichtungen im Geltungsbereich von NIS2 müssen Schwachstellen- und Patch-Management nachweisen, und der IT-Grundschutz des BSI setzt auf Systeme mit Herstellersupport. Wer den Umstieg auf cgroup v2 mit der ohnehin fälligen OS-Modernisierung bündelt und im Change- und Risikomanagement dokumentiert, erledigt Kubernetes-Upgrade und Audit-Nachweis in einem Zug.
Kubernetes-Upgrade oder Migration der Nodes auf cgroup v2 geplant?
Unsere Engineers planen und begleiten Kubernetes-Cluster-Upgrades, Node-Migrationen auf cgroup v2 und den Umstieg auf CoreDNS für Produktteams in den USA und der EU – auch in regulierten Branchen, in denen OS-Upgrades eine Compliance-Freigabe brauchen. Wir identifizieren die für Ihre Cluster-Konfiguration relevanten Breaking Changes, bevor ein Node angefasst wird.
Mit einem Engineer sprechenWas Engineering-Leads jetzt tun sollten
| Maßnahme | Zeitrahmen | Hinweise |
|---|---|---|
stat -fc %T /sys/fs/cgroup/ auf allen Cluster-Nodes ausführen | Diese Woche | Ausgabe tmpfs = cgroup v1; das Kubelet startet nach dem Upgrade nicht. Vor jedem Upgrade-Versuch auf v1.37 prüfen. |
| Node-Images der cgroup-v1-Nodes vor dem Kubernetes-Upgrade aktualisieren | Vor dem nächsten Upgrade-Fenster | Ziel: RHEL 8+, Rocky Linux 8+, AlmaLinux 8+, Ubuntu 20.04+ oder aktuelles Cloud-Image. cgroup v2 muss im OS aktiv sein, bevor das Kubelet aktualisiert wird. |
| DNS prüfen: läuft CoreDNS statt kube-dns? | Dieser Sprint | kubectl get pods -n kube-system | grep dns ausführen. kube-dns muss vor v1.40 migriert sein, sonst fällt das Cluster-DNS aus. |
| kube-proxy-Konfiguration auf IPVS-Modus prüfen | Dieser Sprint | kubectl get configmap kube-proxy -n kube-system -o yaml auf mode: ipvs prüfen. Falls gesetzt, Umstieg auf nftables vor v1.43 planen. |
| OS-Migration im Change- und Risikomanagement dokumentieren (DORA/NIS2) | Dieser Planungszyklus | Für regulierte Unternehmen: Upgrade-Plan, Freigaben und Rollback-Szenario als Nachweis für Audit und Aufsicht ablegen. |
| DRA-Alpha-Features bei GPU- oder Beschleuniger-Workloads prüfen | Dieser Planungszyklus | Taints und Tolerations auf Geräteebene sind Stable. DRA-Alpha-Erweiterungen auf weniger eigenes Scheduling in KI/ML-Pipelines prüfen. |
| HPA-Runbooks an den stabilen Status der Metrics-API anpassen | Nächster Planungszyklus | Beta-Vorbehalte streichen. Die metrics.k8s.io-v1-API fällt unter die Kompatibilitätsgarantie von Kubernetes. |
Sources: Kubernetes v1.37: Garhwal — Official release blog (kubernetes.io, August 26, 2026); Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (The Register, August 26, 2026).
FAQ
Was ist cgroup v1 und warum entfernt Kubernetes 1.37 die Unterstützung?
cgroup v1 ist der ursprüngliche Linux-Mechanismus (Control Groups), mit dem Kubernetes CPU-, Speicher- und I/O-Ressourcen von Containern gruppiert und begrenzt. Seit v1.35 warnt Kubernetes beim Start von Nodes mit cgroup v1. In v1.37 wird daraus eine harte Sperre: Erkennt das Kubelet beim Start cgroup v1, wird der Node nicht initialisiert. cgroup v2 – seit Linux-Kernel 4.5 verfügbar und in den meisten modernen Distributionen seit 2021 Standard – bietet eine einheitliche Hierarchie, besseres Memory-QoS, PSI-Metriken und effizienteres Swap-Management.
Wie prüfe ich, ob meine Nodes cgroup v1 nutzen?
Führen Sie auf jedem Node stat -fc %T /sys/fs/cgroup/ aus. Die Ausgabe tmpfs bedeutet cgroup v1, cgroup2fs bedeutet cgroup v2 – der Node kann aktualisiert werden. Standardmäßig auf cgroup v1 laufen unter anderem CentOS 7, RHEL 7 und Ubuntu 18.04. Die meisten verwalteten Node-Images bei EKS, GKE und AKS sind zwischen 2022 und 2023 auf cgroup v2 umgestiegen.
Was ist der Workaround failCgroupV1 und sollte ich ihn nutzen?
Die KubeletConfiguration enthält das Feld failCgroupV1, das auf false gesetzt die harte Startsperre aufhebt. Das Kubernetes-Projekt stuft das ausdrücklich als gefährlich ein: Der Node verliert Memory-QoS, PSI-Metriken und Swap-Konfigurationen, die cgroup v2 voraussetzen, und das Feld wird in einem künftigen Release entfernt. Nur als kurzfristige Absicherung während der Migration verwenden.
Was passiert mit kube-dns und IPVS in Kubernetes 1.37?
kube-dns wird in v1.37 zugunsten von CoreDNS ausgemustert, das seit Kubernetes 1.13 (2018) Standard ist. Cluster mit kube-dns müssen vor Kubernetes 1.40 migrieren, sonst funktioniert das Cluster-DNS nicht mehr. IPVS in kube-proxy ist ab v1.37 abgekündigt und wird in v1.43 entfernt; Nachfolger ist nftables.
Was bedeutet die stabile metrics.k8s.io-API für den HPA?
Die metrics.k8s.io-API, auf der kubectl top, der HorizontalPodAutoscaler (HPA) und der VerticalPodAutoscaler (VPA) aufbauen, wechselt in Kubernetes 1.37 nach neun Jahren von Beta auf Stable (v1). Damit fällt die API unter die Kompatibilitätsgarantie von Kubernetes und ändert sich nicht mehr inkompatibel.
Was bedeutet das Upgrade für Unternehmen im DACH-Raum?
Im DACH-Raum laufen viele Kubernetes-Cluster on-premises oder bei regionalen Hostern, oft auf älteren Enterprise-Linux-Images. Dort ist das Upgrade auf 1.37 faktisch ein Betriebssystem-Projekt. Für Finanzunternehmen unter DORA und Einrichtungen im Geltungsbereich von NIS2 gehören ein Betriebssystem mit Herstellersupport und ein dokumentiertes Patch-Management ohnehin zu den Pflichten – die cgroup-v2-Migration sollte deshalb mit dem Change- und Risikomanagement abgestimmt werden.