Kubernetes beschleunigt Umstieg auf cgroup v2 durch erzwungene v1-Abkündigung

Kubernetes treibt die Abkehr von der veralteten Ressourcenverwaltung über cgroup v1 voran und fordert Cluster-Betreiber auf, ihre Linux-Knoten auf cgroup v2 vorzubereiten. Ab Kubernetes v1.35 steht die kubelet-Einstellung failCgroupV1 standardmäßig auf true. Dadurch schlägt der kubelet-Prozess beim Starten auf jedem Knoten fehl, der noch cgroup v1 nutzt, sofern Administratoren nicht explizit eine temporäre Ausnahme festlegen. Zudem wandelt kubeadm v1.35 die Erkennung von cgroup v1 bei der Cluster-Initialisierung, bei Join-Vorgängen und bei Upgrades in einen blockierenden Preflight-Fehler um. Obwohl diese manuelle Übersteuerung in Kubernetes v1.36 weiterhin unterstützt wird, plant das Projekt, die cgroup-v1-Unterstützung in Version 1.38 vollständig zu entfernen.

Verbesserte Isolierung und Speichersteuerung

Der Wechsel zu cgroup v2 ersetzt getrennte Hierarchien durch eine einzige, einheitliche Struktur im Linux-Kernel und schaltet fortschrittliche Funktionen zur Ressourcenisolierung frei. In Kubernetes v1.36 nutzt das Alpha-Feature Memory QoS die cgroup-v2-Controller für den Einsatz einer gestaffelten Speicherabsicherung. Dabei wird memory.high zur Drosselung verwendet, während Container-Requests auf memory.min sowie memory.low für harten und weichen Schutz abgebildet werden. Auf cgroup-v2-Knoten setzt das kubelet singleProcessOOMKill standardmäßig auf false. Unter Verwendung von memory.oom.group werden bei Out-of-Memory-Ereignissen alle Prozesse innerhalb eines Containers gemeinsam beendet, anstatt unvollständig funktionierende Restprozesse zu hinterlassen.

Die einheitliche Hierarchie bietet zudem native Unterstützung für Pressure-Stall-Information-Metriken (PSI) auf Knoten-, Pod- und Container-Ebene sowie für die delegationsbasierte Ausführung von Rootless-Containern über systemd. Überdies basiert die präzise aggregierte Durchsetzung der unterbrechungsfreien Pod-Ressourcenskalierung, die in Kubernetes v1.36 standardmäßig aktiviert wurde, direkt auf der cgroup-v2-Infrastruktur.

Voraussetzungen und Konfigurationsschritte

Für den erfolgreichen Betrieb von cgroup v2 benötigen Cluster-Knoten ein unterstütztes Linux-Betriebssystem mit aktiviertem cgroup v2 sowie einen Kernel der Version 5.8 oder höher. Bei der Verwendung von Memory QoS wird mindestens Kernel 5.9 empfohlen, um bekannte Reclaim-Probleme auf Kernel-Ebene zu vermeiden. Auch die Container-Runtimes müssen die v2-Schnittstelle unterstützen, wie etwa containerd ab Version 1.4 oder CRI-O ab Version 1.20.

Cluster-Betreiber müssen sicherstellen, dass das kubelet und die zugrunde liegende Container-Runtime denselben cgroup-Treiber verwenden; für von kubeadm verwaltete Cluster wird systemd empfohlen. Runtimes, die die RuntimeConfig-CRI-RPC unterstützen – wie containerd v2.0+ oder CRI-O v1.28+ –, ermöglichen die automatische Erkennung des cgroup-Treibers. Dadurch kann das kubelet die Konfiguration des Runtime-Treibers dynamisch übernehmen.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: The Shift to cgroup v2 in Kubernetes: What You Need to Know