Kubernetes: Seit v1.35 startet das Kubelet standardmäßig nicht mehr auf cgroup-v1-Knoten

Serguey Asael Shinder07 October 2026, 07:331 Min. Lesezeit

Das Kubernetes-Projekt hat am 6. Oktober einen Leitfaden zum Wechsel von cgroup v1 zu cgroup v2 veröffentlicht. cgroup v2 wird seit v1.25 stabil unterstützt; cgroup v1 ist abgekündigt, die Entfernung wird in KEP-5573 verfolgt.

Was jetzt scheitert. Ab v1.35 ist failCgroupV1 standardmäßig true; das Kubelet startet auf einem cgroup-v1-Knoten also nicht. Administratoren können vorübergehend failCgroupV1: false setzen. Bei kubeadm-Clustern greift die Prüfung früher und strenger: Der Preflight-Check SystemVerification meldet bei kubeadm init, join und upgrade einen Fehler, wenn er cgroup v1 mit Kubelet ab v1.35 erkennt; mit älterem Kubelet bleibt es eine Warnung.

Was der Beitrag Betreibern rät.

• Unter v1.35: alle Linux-Knoten vor dem Upgrade auf cgroup v2 umstellen oder die vorübergehende Ausnahme einplanen.
• Ab v1.35: prüfen, dass jeder Linux-Knoten cgroup v2 nutzt oder die Ausnahme bewusst gesetzt ist. In der Standardkonfiguration scheitert ein verbliebener cgroup-v1-Knoten beim Start des Kubelets.

Genannte bekannte Probleme.

• Das Kubelet wertet active_file-Speicher als nicht rückgewinnbar; ein großer Page Cache bei I/O-lastigen Workloads kann daher Speicherdruck und Evictions auslösen. cgroup v2 ändert diese Rechnung nicht; die dokumentierte Abhilfe sind gleiche Speicher-Requests und -Limits für solche Container.
• Auf cgroup-v2-Knoten setzt das Kubelet singleProcessOOMKill standardmäßig auf false und aktiviert memory.oom.group; ein OOM-Ereignis beendet damit alle Prozesse in der cgroup des Containers.

Was nur cgroup v2 ermöglicht. Memory QoS, in v1.36 weiterhin Alpha, trennt jetzt Drosselung und Reservierung. memory.high drosselt Burstable-Container mit einem Schwellenwert aus Request, Limit und memoryThrottlingFactor (Standard 0,9). Mit memoryReservationPolicy: TieredReservation werden Requests von Guaranteed-Pods auf memory.min (harter Schutz) und von Burstable-Pods auf memory.low (weicher Schutz) abgebildet; BestEffort-Pods erhalten keinen. Empfohlen wird Kernel 5.9 oder neuer, weil die Rückgewinnung über memory.high auf älteren Kerneln in einen Livelock geraten kann. Das Projekt wiederholt seinen allgemeinen Rat, Alpha-Features nicht in Produktion zu aktivieren.