Kubernetes is accelerating its transition away from legacy cgroup v1 resource management, requiring cluster operators to prepare their Linux nodes for cgroup v2. Starting in Kubernetes v1.35, the kubelet setting failCgroupV1 defaults to true, causing the kubelet process to fail during startup on any node running cgroup v1 unless an administrator explicitly sets a temporary override. In addition, kubeadm v1.35 converts cgroup v1 detection into a blocking preflight error during cluster initialization, join operations, and upgrades. Although the manual override remains supported in Kubernetes v1.36, the project plans to completely remove cgroup v1 support in version 1.38.
Enhanced Isolation and Memory Control
Transitioning to cgroup v2 replaces split hierarchies with a single unified structure in the Linux kernel, unlocking advanced resource isolation capabilities. In Kubernetes v1.36, the alpha Memory QoS feature uses cgroup v2 controllers to implement tiered memory protection, applying memory.high for throttling and mapping container requests to memory.min and memory.low for hard and soft protection. On cgroup v2 nodes, the kubelet also defaults singleProcessOOMKill to false, utilizing memory.oom.group to terminate all processes in a container together during Out-of-Memory events rather than leaving partial processes running.
The single hierarchy also provides native support for Pressure Stall Information (PSI) metrics across node, Pod, and container levels, as well as rootless container delegation via systemd. Additionally, accurate aggregate enforcement for in-place Pod resource scaling, which became enabled by default in Kubernetes v1.36, relies directly on cgroup v2 infrastructure.
Prerequisites and Configuration Steps
To run cgroup v2 successfully, cluster nodes require a supported Linux OS with cgroup v2 enabled and kernel version 5.8 or higher, with kernel 5.9 or later recommended when using Memory QoS to avoid known kernel-level reclaim issues. Container runtimes must also support the v2 interface, such as containerd v1.4 or higher and CRI-O v1.20 or later.
Cluster operators must ensure the kubelet and the underlying container runtime use matching cgroup drivers, with systemd recommended for kubeadm-managed clusters. Runtimes supporting the RuntimeConfig CRI RPC, such as containerd v2.0+ or CRI-O v1.28+, enable automatic cgroup driver discovery, allowing the kubelet to dynamically match the runtime driver configuration.
AI-generated editorial illustration; not a documentary photograph.
Source: The Shift to cgroup v2 in Kubernetes: What You Need to Know
SIGNAL TITANS
Leave a Reply