Kubernetes v1.35 erzwingt die Migration zu cgroup v2 für Linux-Knoten

Das Kubernetes-Projekt hat die Unterstützung für cgroup v1 in den Wartungsmodus versetzt und signalisiert damit einen endgültigen Wechsel zur einheitlichen Schnittstelle für das Ressourcenmanagement von cgroup v2. Ab Kubernetes v1.35 wird sich das kubelet weigern, auf Knoten zu starten, die noch cgroup v1 verwenden, es sei denn, Administratoren setzen dieses Verhalten explizit außer Kraft. Diese Änderung betrifft alle Linux-basierten Cluster und erfordert von Operatoren, dass sie ihre Kernel-Versionen, Container-Runtimes und Knotenkonfigurationen vor dem Upgrade überprüfen.

Was passiert ist

Control Groups (cgroups) sind eine Funktion des Linux-Kernels, die es dem Betriebssystem ermöglicht, Ressourcen wie CPU und Speicher bestimmten Prozessen zuzuweisen. Kubernetes verlässt sich auf diesen Mechanismus, um sicherzustellen, dass Container nicht miteinander interferieren. Während cgroup v2 seit Version 1.25 stabil in Kubernetes unterstützt wird, wird die Unterstützung für die ältere v1-Schnittstelle nun schrittweise eingestellt. In Kubernetes v1.35 ist der Konfigurationsparameter failCgroupV1 standardmäßig auf true gesetzt. Das bedeutet, dass der kubelet-Prozess beim Start fehlschlägt, wenn ein Knoten cgroup v1 verwendet, wodurch der Knoten effektiv offline geht.

Administratoren, die noch nicht bereit für eine Migration sind, können failCgroupV1: false temporär in ihrer kubelet-Konfigurationsdatei einstellen. Dies ist jedoch nur eine Übergangslösung. Die Deprecation-Policy von Kubernetes deutet an, dass die vollständige Entfernung der cgroup-v1-Unterstützung bevorsteht, verfolgt unter KEP-5573. Für Cluster, die mit kubeadm verwaltet werden, ist die Durchsetzung noch strenger. Der SystemVerification-Preflight-Check, Teil des Tools k8s.io/system-validators, gibt jetzt einen Fehler während der Initialisierung, des Beitritts oder des Upgrades zurück, wenn er cgroup v1 auf einem Knoten erkennt, der kubelet v1.35 oder neuer ausführt. Zuvor war dies lediglich eine Warnung.

Dieser Übergang dient nicht nur der Compliance; er erschließt moderne Funktionen für das Ressourcenmanagement. Cgroup v2 bietet eine einzelne, vereinheitlichte Hierarchie, die die Schnittstelle im Vergleich zu den mehreren Hierarchien von v1 vereinfacht. Sie gewährleistet eine stärkere Isolation und unterstützt neue Funktionen wie Pressure Stall Information (PSI) und verbesserte Memory Quality of Service (QoS). Cluster, die bei v1 bleiben, verpassen diese Optimierungen und stehen vor zunehmenden Kompatibilitätsproblemen mit neueren Container-Runtimes und Monitoring-Tools.

Wie es funktioniert

Cgroup v2 ersetzt die komplexe, mehrstufige Hierarchiestruktur von v1 durch einen einzelnen Baum, an dem alle Controller (CPU, Speicher, E/A) angehängt sind. Diese Vereinheitlichung ermöglicht eine konsistentere Ressourcenabrechnung und verhindert Szenarien, in denen ein Prozess durch einen Controller begrenzt wird, aber nicht durch einen anderen aufgrund von Hierarchieinkonsistenzen. In Kubernetes interagiert das kubelet mit diesen Controllern, um die in Pod-Spezifikationen definierten Limits durchzusetzen. Mit v2 kann das kubelet Funktionen wie memory.high zum Drosseln und memory.min zum harten Schutz nutzen, was in v1 nicht möglich oder zuverlässig war.

Die Migration ändert auch die Handhabung von Out-of-Memory-(OOM)-Ereignissen. In cgroup v2 setzt das kubelet memory.oom.group für jeden Container-Cgroup. Wenn ein OOM-Ereignis auftritt, beendet der Kernel alle Prozesse innerhalb dieses Containers gleichzeitig, anstatt sie nacheinander abzuschalten. Dies verhindert, dass teilweise funktionierende Container in einem defekten Zustand verweilen. Darüber hinaus ermöglicht cgroup v2 Delegation, sodass rootless Container ihre eigenen cgroups sicher über systemd verwalten können – eine Fähigkeit, die in v1 riskant oder unmöglich war.

Wichtige Details

• Standardmäßige Durchsetzung: In Kubernetes v1.35 ist failCgroupV1 standardmäßig auf true gesetzt, was zu einem Startfehler des kubelet auf cgroup-v1-Knoten führt.
• Kernel-Anforderungen: Eine Linux-Kernel-Version 5.8 oder neuer ist für die cgroup-v2-Unterstützung erforderlich, wobei 5.9+ für die Stabilität der Memory QoS empfohlen wird.
• Runtime-Unterstützung: Containerd v1.4+ und CRI-O v1.20+ unterstützen cgroup v2; die automatische Treibererkennung erfordert containerd v2.0+ oder CRI-O v1.28+.
• Memory QoS: Die Alpha-Funktion Memory QoS, die memory.high und memory.low nutzt, ist ausschließlich auf cgroup-v2-Knoten verfügbar.
• Tooling-Updates: Monitoring-Tools müssen aktualisiert werden; cAdvisor v0.43.0+ wird empfohlen, zusammen mit kompatiblen Versionen von Java- und Node.js-Bibliotheken.
• CPU-Gewichtskonvertierung: Neuere OCI-Runtimes wie crun v1.23 und runc v1.3.2 verwenden eine nichtlineare Konvertierung von v1 cpu.shares zu v2 cpu.weight, was die Granularität für kleine CPU-Anfragen verbessert.

Warum das wichtig ist

Für Software-Ingenieure und Plattformteams bedeutet dieser Wandel, dass Legacy-Infrastrukturkonfigurationen nicht mehr tragfähig sind. Wenn Sie Ihre Control Plane auf v1.35 upgraden, ohne Ihre Worker-Knoten zu migrieren, wird Ihr Cluster brechen. Knoten werden nicht beitreten können, und bestehende Knoten schlagen möglicherweise nach einem Neustart fehl. Dies schafft eine harte Abhängigkeit von Betriebssystemupdates, da viele ältere Linux-Distributionen standardmäßig cgroup v1 verwenden. Teams müssen nun Kernel-Upgrades über ihre gesamte Flotte koordinieren, was in großen, heterogenen Umgebungen eine erhebliche operative Hürde darstellen kann.

Über die unmittelbaren Migrationsprobleme hinaus bietet die Nutzung von v2 eine bessere Ressourceneffizienz. Funktionen wie PSI bieten Echtzeit-Einblicke in Ressourcenkonflikte, was genauere Entscheidungen für das Autoscaling ermöglicht. Die verbesserte OOM-Handhabung stellt sicher, dass Anwendungsfehler sauberer und leichter zu debuggen sind. Außerdem ist cgroup v2 erforderlich für eine genaue aggregierte Durchsetzung, sobald In-Place-Vertical-Scaling stabil wird. Die Ignorierung dieses Migrationspfads wird dazu führen, dass Cluster diese Leistungs- und Zuverlässigkeitsverbesserungen letztlich nicht adoptieren können.

Was Sie tun können

• Aktuellen Status prüfen: Führen Sie stat -fc %T /sys/fs/cgroup/ auf Ihren Knoten aus. Wenn cgroup2fs zurückgegeben wird, nutzen Sie bereits v2.
• Kernel-Version überprüfen: Stellen Sie sicher, dass alle Linux-Knoten Kernel 5.8 oder neuer ausführen. Aktualisieren Sie das Betriebssystem bei Bedarf vor dem Versuch des Kubernetes-Upgrades.
• Container-Runtime aktualisieren: Bestätigen Sie, dass Sie containerd v1.4+ oder CRI-O v1.20+ verwenden. Idealerweise wechseln Sie zu containerd v2.0+, um die automatische cgroup-Treibererkennung zu nutzen.
• Kubelet konfigurieren: Wenn Sie nicht sofort migrieren können, setzen Sie failCgroupV1: false in Ihrer kubelet-Konfiguration, planen Sie aber, diese Überschreibung bald zu entfernen. Passen Sie den cgroup-Treiber an Ihre Runtime an, bevorzugt unter Verwendung von systemd.
• Monitoring-Stack aktualisieren: Upgraden Sie cAdvisor auf v0.43.0 oder neuer und verifizieren Sie, dass Ihre Prometheus-Scrapers und andere Monitoring-Tools cgroup-v2-Metriken unterstützen.
• Memory QoS testen: Wenn Sie erweitertes Ressourcenmanagement nutzen, testen Sie die Alpha-Funktionen der Memory QoS in einer Testumgebung, um zu verstehen, wie sich das Drosseln via memory.high auf Ihre Workloads auswirkt.