From Kubernetes 1.35 the kubelet will not start on cgroup v1: what to check before you upgrade

cgroup v2 support has been stable in Kubernetes since v1.25, and v1 support moved into maintenance mode in v1.31 [1]. The change that turns this from background reading into an outage is in v1.35.

What changed in 1.35

• failCgroupV1 defaults to true, so the kubelet does not start on a cgroup v1 node by default [1].
• On kubeadm-managed clusters, the SystemVerification preflight check returns an error during kubeadm init, join and upgrade when it detects cgroup v1 with kubelet v1.35 or later; with an older kubelet it remains a warning [1].
• Administrators can temporarily set failCgroupV1: false, but removal will follow the Kubernetes deprecation policy and is tracked in KEP-5573 [1].

What cgroup v2 changes once you are there

• OOM kills become container-wide. On cgroup v2 nodes the kubelet defaults singleProcessOOMKill to false and sets memory.oom.group, so an OOM kills every process in the container together rather than leaving a partially working multi-process container [1].
• Pressure Stall Information — CPU, memory and I/O contention at node, Pod and container level — requires cgroup v2 [1].
• Memory QoS works only on cgroup v2 nodes; it remains alpha in v1.36 [1].
• Software that reads the cgroup filesystem directly needs updating; the migration guidance recommends cAdvisor v0.43.0 or later and lists compatible Java, Node.js and automaxprocs versions [1].

One thing it does not fix: the kubelet treats active_file page cache as not reclaimable, so I/O-heavy workloads can still trigger memory-pressure evictions after migration [1].

What we ask

We ask platform engineers how they would find every cgroup v1 node in a fleet before an upgrade, and what in their stack reads cgroup files directly. The useful answer covers node images, the monitoring agent and the language runtimes — not just the kubelet.