Kubernetes zieht bei cgroups die nächste klare Grenze: cgroup v1 ist technisch überholt, cgroup v2 ist der neue Standard. Für Betreiber ist das mehr als ein Kernel-Detail. Die Umstellung betrifft die Art, wie Ressourcen kontrolliert, Workloads isoliert und Cluster langfristig betrieben werden.
Seit Kubernetes 1.25 gilt cgroup v2 als stabil. Mit Kubernetes 1.35 wurde cgroup v1 offiziell deprecated; der kubelet startet auf einem cgroup-v1-Node standardmäßig nicht mehr. Wer alte Linux-Distributionen, ältere Runtime-Konfigurationen oder historisch gewachsene Node-Images betreibt, muss deshalb handeln.
Warum cgroup v2 für Kubernetes relevant ist
Control Groups sind die Linux-Grundlage dafür, CPU, Arbeitsspeicher und weitere Ressourcen auf Prozesse und damit auf Container zu verteilen. Kubernetes nutzt diese Mechanismen, um Requests und Limits technisch durchzusetzen.
cgroup v1 ist über Jahre organisch gewachsen. Unterschiedliche Controller konnten in getrennten Hierarchien liegen, Schnittstellen waren nicht durchgehend konsistent und Delegation war fehleranfälliger.
cgroup v2 vereinheitlicht dieses Modell. Es gibt eine gemeinsame Hierarchie, konsistentere Semantik und eine sauberere Basis für moderne Ressourcensteuerung. Funktionen wie Pressure Stall Information und Memory QoS profitieren direkt davon.
Auswirkungen auf das Clustermanagement
Für Clusterbetreiber bedeutet die Migration zunächst: Der Node-Unterbau wird wieder sichtbar.
Ein Kubernetes-Upgrade reicht nicht aus, wenn das Betriebssystem darunter weiterhin cgroup v1 verwendet. Entscheidend sind mehrere Ebenen gleichzeitig:
- die Linux-Distribution und ihr Kernel,
- die aktivierte cgroup-Version,
- die Container Runtime,
- der verwendete cgroup-Treiber,
- Monitoring- und Security-Agenten,
- Anwendungen, die direkt auf das cgroup-Dateisystem zugreifen.
Genau hier entsteht in heterogenen Flotten das größte Risiko. Wenn Cluster aus unterschiedlichen Betriebssystemständen, Images und Runtime-Versionen bestehen, wird aus einem vermeintlich kleinen Plattform-Upgrade schnell ein Infrastrukturprojekt.
Ein konsistentes Node-Baseline-Management wird deshalb wichtiger. Cluster sollten nicht nur auf Kubernetes-Versionen standardisiert werden, sondern auf klar definierte Kombinationen aus Distribution, Kernel, Runtime und kubelet-Konfiguration.
Bessere Ressourcenisolierung ist kein Nebeneffekt
Der Wechsel auf cgroup v2 verbessert nicht nur die Wartbarkeit. Er stärkt auch die technische Grundlage für Ressourcenisolierung.
Die vereinheitlichte Hierarchie reduziert Sonderfälle zwischen unterschiedlichen Ressourcencontrollern. Speicherverbrauch lässt sich konsistenter erfassen, Delegation wird sauberer und moderne Kubernetes-Funktionen können gezielter auf die vorhandenen Kernel-Mechanismen zugreifen.
Für produktive Plattformen ist das relevant, weil Ressourcenisolierung unmittelbar mit Stabilität zusammenhängt. Wenn einzelne Workloads unter Last CPU oder Speicher aggressiv beanspruchen, entscheidet die Qualität der zugrunde liegenden Kontrolle darüber, wie stark andere Workloads betroffen sind.
cgroup v2 schafft dafür die deutlich bessere Ausgangslage.
Migration heißt testen, nicht nur umschalten
Die eigentliche Umstellung ist technisch beherrschbar, sollte aber nicht blind erfolgen.
Besondere Aufmerksamkeit verdienen Komponenten, die cgroup-Informationen direkt auslesen. Dazu gehören unter anderem Monitoring-Agenten, Security-Tools und einzelne Laufzeitumgebungen. Auch Anwendungen, deren Speichererkennung von älteren Runtime-Versionen abhängt, können unter cgroup v2 ein anderes Verhalten zeigen.
Ein sinnvoller Migrationspfad sieht deshalb so aus:
- Node-Flotte inventarisieren und cgroup-Version erfassen.
- Betriebssysteme, Kernel und Container Runtimes auf cgroup-v2-Kompatibilität prüfen.
- Monitoring-, Security- und Observability-Komponenten validieren.
- Repräsentative Workloads in einer Testumgebung auf cgroup v2 betreiben.
- Node-Pools schrittweise migrieren.
- Erst danach Kubernetes-Versionen anheben, bei denen cgroup v1 zum harten Hindernis wird.
Der wichtigste Punkt dabei: cgroup v2 sollte Teil einer reproduzierbaren Plattform-Baseline sein und nicht als einmalige Sondermigration behandelt werden.
Europa braucht konsistente Infrastrukturstandards
Der technische Wechsel zeigt ein größeres Problem: Europas digitale Infrastruktur wird nur dann resilient und souverän, wenn zentrale Plattformbausteine nicht in tausenden individuellen Sonderkonfigurationen betrieben werden.
Kubernetes ist längst kritische Infrastruktur für Unternehmen, Behörden und Plattformanbieter. Trotzdem unterscheiden sich Cluster häufig massiv bei Kernel-Versionen, Runtime-Konfigurationen, Node-Images und Betriebsprozessen.
Das erschwert nicht nur Upgrades. Es erschwert auch Sicherheitsbewertungen, Audits, Incident Response und die Portierbarkeit von Workloads.
Europäische Cloud- und Plattformangebote sollten deshalb stärker auf gemeinsame, nachvollziehbare Baselines setzen: unterstützte Kernelstände, definierte Runtime-Versionen, konsistente cgroup-v2-Konfiguration, standardisierte Upgradepfade und transparente Betriebsmodelle.
Standardisierung bedeutet dabei nicht Zentralisierung. Im Gegenteil: Gemeinsame technische Standards erleichtern den Wechsel zwischen Anbietern, reduzieren proprietäre Abhängigkeiten und stärken Interoperabilität.
Fazit
Die Migration von cgroup v1 zu cgroup v2 ist ein technischer Schritt mit strategischer Wirkung.
Für Kubernetes verbessert sie Ressourcenmanagement und Isolation und schafft die Grundlage für moderne Plattformfunktionen. Für Betreiber zwingt sie gleichzeitig zu einer ehrlichen Bestandsaufnahme der eigenen Node- und Runtime-Landschaft.
Wer Cluster langfristig zuverlässig betreiben will, sollte cgroup v2 deshalb nicht als lästige Kompatibilitätsaufgabe betrachten, sondern als Anlass, Infrastruktur zu vereinheitlichen.
Gerade in Europa ist das entscheidend: Digitale Souveränität entsteht nicht allein durch den Standort eines Rechenzentrums. Sie entsteht durch offene Standards, reproduzierbare Plattformen und Infrastruktur, die sich konsistent betreiben und zwischen Anbietern bewegen lässt.