Dev News Daily ENDE

Kubernetes: since v1.35 the kubelet refuses to start on cgroup v1 nodes by default

The Kubernetes project published a guide to the move from cgroup v1 to cgroup v2 on 6 October. Support for cgroup v2 has been stable since v1.25; cgroup v1 is deprecated, and removal work is tracked in KEP-5573.

What fails now. Starting with v1.35, failCgroupV1 defaults to true, so the kubelet does not start on a cgroup v1 node by default. Administrators can temporarily set failCgroupV1: false. For kubeadm clusters the check is earlier and stricter: 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 stays a warning.

Kubernetes: since v1.35 the kubelet refuses to start on cgroup v1 nodes by default
Kubernetes: since v1.35 the kubelet refuses to start on cgroup v1 nodes by default — Dev News Daily

What the post tells operators to do.

  • Below v1.35: migrate every Linux node to cgroup v2 before upgrading, or plan the temporary override.
  • On v1.35 or later: confirm that every Linux node runs cgroup v2, or that the override is intentional. Under the default configuration a remaining cgroup v1 node fails at kubelet startup.

Known issues it lists.

  • The kubelet treats active_file memory as not reclaimable, so a large page cache in I/O-heavy workloads can trigger memory pressure and evictions. cgroup v2 does not change that calculation; the documented workaround is equal memory requests and limits for such containers.
  • On cgroup v2 nodes the kubelet defaults singleProcessOOMKill to false and sets memory.oom.group, so an OOM event kills all processes in the container's cgroup.

What only cgroup v2 enables. Memory QoS, still alpha in v1.36, now separates throttling from reservation. memory.high throttles Burstable containers, with a threshold derived from request, limit and memoryThrottlingFactor (default 0.9). With memoryReservationPolicy: TieredReservation, Guaranteed pods' requests map to memory.min (hard protection) and Burstable pods' to memory.low (soft); BestEffort pods get neither. Kernel 5.9 or later is recommended, because memory.high reclaim can livelock on older kernels. The project repeats its general advice not to enable alpha features in production.