Der Countdown läuft: Kubernetes schaltet cgroup v1 ab – eine Migrations-Checkliste für 2026

Der Countdown läuft: Kubernetes schaltet cgroup v1 ab – eine Migration-Checkliste für 2026

Spätestens seit Kubernetes 1.37 im August 2026 ist die Botschaft unmissverständlich: Der kubelet startet auf einem cgroup-v1-Node nicht mehr – es sei denn, ein Administrator setzt explizit das temporäre failCgroupV1: false. Was für viele Teams wie eine Randnotiz in den Release Notes wirkte, wird jetzt zur operativen Realität. Denn Kubernetes 1.34 hat am 27. Oktober 2026 das Ende seines Support-Zyklus erreicht, und mit jedem Upgrade auf 1.35 oder neuer steht die cgroup-v2-Migration an. Wer jetzt nicht handelt, riskiert Nodes, die nach dem nächsten Upgrade schlicht nicht mehr hochkommen.

Warum cgroup v2?

cgroups (Control Groups) sind der Linux-Kernel-Mechanismus, mit dem Kubernetes CPU- und Memory-Limits für Container durchsetzt. cgroup v1 organisierte diese Kontrolle über mehrere separate Hierarchien – eine pro Ressourcen-Controller. Das führte zu inkonsistentem Verhalten zwischen Distributionen und erschwerte Features wie In-Place Pod Resizing oder zuverlässiges Memory QoS.

cgroup v2 ersetzt dieses Modell durch eine einzige, vereinheitlichte Hierarchie. Der Wechsel bringt drei konkrete Verbesserungen für den Betrieb:

Memory QoS mit zweistufigem Modell: cgroup v2 kennt mit memory.high einen weichen Grenzwert, der vor dem OOM-Kill bremst und Reclaim erzwingt. cgroup v1 kannte nur den harten memory.limit_in_bytes – entweder der Container passt ins Limit, oder der OOM-Killer räumt auf. Seit Kubernetes 1.36 kann über das Memory-QoS-Feature (noch Alpha) sogar ein abgestufter Schutz (TieredReservation) aktiviert werden: Guaranteed-Pods erhalten harten Schutz via memory.min, Burstable-Pods weichen Schutz via memory.low.

Container-bewusstes OOM-Handling: Auf cgroup-v2-Nodes setzt der kubelet standardmäßig memory.oom.group pro Container-Cgroup. Ein OOM-Ereignis killt dann alle Prozesse eines Containers gemeinsam, statt einzelne Prozesse – das verhindert teilweise funktionsunfähige Multi-Prozess-Container.

Per-Cgroup-PSI-Metriken: Ab Kubernetes 1.36 sind Pressure-Stall-Indikatoren (PSI) pro Cgroup verfügbar (GA). Statt nur den gesamten Node-Druck zu messen, können Plattformteams jetzt die Auslastung einzelner Mandanten oder Namespaces überwachen – und Alarm auslösen, bevor der OOM-Killer zuschlägt. Diese Fähigkeit hat kein cgroup-v1-Pendant.

Der Zeitplan: Von der Warnung zum Hartstopp

Die Migration läuft seit Jahren – aber 2026 ist das Jahr der Durchsetzung:

Release	Datum	Meilenstein
Kubernetes 1.25	August 2022	cgroup v2 wird stabil (GA)
Kubernetes 1.31	August 2024	cgroup v1 geht in den Wartungsmodus
Kubernetes 1.35	Dezember 2025	`failCgroupV1` defaultet auf `true` (Beta)
Kubernetes 1.37	26. August 2026	Kubelet startet nicht mehr auf cgroup-v1-Nodes
Kubernetes 1.38	vsl. 16. Dezember 2026	Geplante Entfernung des cgroup-v1-Codes

Der offizielle Kubernetes-Blog hat am 6. Oktober 2026 mit “The Shift to cgroup v2” eine umfassende Anleitung veröffentlicht, die den aktuellen Stand zusammenfasst. Die Botschaft: failCgroupV1: false ist ein temporärer Notausstieg, kein dauerhafter Konfigurationsmodus. Wer ihn setzt, erkauft sich Zeit – aber die Richtung ist endgültig.

Welche Nodes sind betroffen?

Die gute Nachricht: Die meisten aktuellen Distributionen liefern cgroup v2 standardmäßig aus – Ubuntu 22.04 und 24.04, Debian 12, Amazon Linux 2023, RHEL 9.4+ und Talos Linux 1.3+. Das Risiko sitzt in älteren Base-Images: Ubuntu 20.04, Debian 10, CentOS 7 und manuell auf v1 zurückgesetzte Nodes.

Die Prüfung ist einfach: stat -fc %T /sys/fs/cgroup/ auf jedem Node liefert cgroup2fs für v2 und tmpfs für v1.

Checkliste für die Migration

Fleet auditieren: Lauf stat -fc %T /sys/fs/cgroup/ auf allen Nodes – notiere die v1-Kandidaten.
Container-Runtime prüfen: Kubernetes 1.37 setzt containerd 2.0 oder neuer voraus. containerd 1.x wird nicht mehr unterstützt.
Legacy-Agenten testen: Monitoring-Tools, Security-Agenten und direkte cgroup-Zugriffe (z. B. --max-old-space-size in Node.js-Apps) müssen cgroup v2 unterstützen.
Base-Image aktualisieren: Nodes auf eine Distribution mit cgroup-v2-Default heben – oder bei selbstverwalteten Images den Kernel-Boot-Parameter systemd.unified_cgroup_hierarchy=1 setzen.
Workload-Verhalten validieren: Nach der Umstellung das CPU-Weight-Mapping (cgroup-v1-Shares → v2-Weight) prüfen – die Umrechnungsformel hat sich geändert.
Memory-QoS evaluieren: Wer die Alpha-Features MemoryQoS und TieredReservation nutzen möchte, braucht cgroup v2 zwingend. Der offizielle Blog empfiehlt, die Konfiguration vorab in einer Nicht-Produktionsumgebung zu testen.

Fazit

Die cgroup-v2-Migration ist keine Option mehr – sie ist der neue Standard. Mit Kubernetes 1.38 am Horizont (voraussichtlich Dezember 2026) und der geplanten Entfernung des cgroup-v1-Codes ist die verbleibende Zeit knapp. Plattformteams, die jetzt ihre Fleet auditieren, Legacy-Agenten aktualisieren und den Umstieg planen, vermeiden den Stress eines erzwungenen Upgrades unter Zeitdruck. Die Mühe lohnt sich: cgroup v2 bringt nicht nur die Einhaltung des Deprecation-Pfads, sondern auch bessere Ressourcen-Isolation, feinere Memory-Steuerung und die PSI-Transparenz, die für den Betrieb von KI-Workloads und Multi-Tenant-Plattformen zunehmend unverzichtbar wird.