Kubernetes v1.31 deprecates cgroup v1; v1.35 defaults to cgroup v2 only

Kubernetes Shifts to cgroup v2

Kubernetes has deprecated cgroup v1, a Linux kernel feature for managing system resources. Support for cgroup v1 moved into maintenance mode with Kubernetes v1.31, while cgroup v2 has been stable since Kubernetes v1.25. This change impacts how Kubernetes allocates CPU and memory to containers.

Benefits of cgroup v2

cgroup v2 offers a single unified hierarchy, a more consistent interface, and a stronger foundation for resource isolation. It also provides modern resource-management features compared to cgroup v1.

Migration Requirements for Kubernetes v1.35+

Starting with Kubernetes v1.35, the `failCgroupV1` setting defaults to `true`, preventing the kubelet from starting on cgroup v1 nodes. Administrators can temporarily set `failCgroupV1: false` in the kubelet configuration, but this is a temporary override before full removal. Users on releases older than v1.35 must migrate all Linux nodes to cgroup v2 before upgrading.

For kubeadm-managed clusters, Kubernetes v1.35 introduces a stricter `SystemVerification` preflight check. This check will return an error during `kubeadm init`, `kubeadm join`, and `kubeadm upgrade` if cgroup v1 is detected with kubelet v1.35 or later.

Known Issues and Workarounds

A known issue involves the kubelet treating `active_file` memory as non-reclaimable, which can lead to memory pressure and Pod eviction for I/O-intensive workloads. This behavior is not changed by migrating to cgroup v2. A documented workaround is to set equal memory requests and limits for containers performing intensive I/O.