News › linux
By The Linux Camp News, October 7, 2026
The default makes remaining cgroup v1 nodes an upgrade concern. A temporary kubelet override exists, but kubeadm also reports a preflight error for cgroup v1 with kubelet v1.35 or later.
Kubernetes v1.35 changes the default startup policy for Linux nodes still using cgroup v1: failCgroupV1 defaults to true, preventing the kubelet from starting. This is not complete removal of cgroup v1 support. Administrators can temporarily set failCgroupV1: false in the kubelet configuration file, but the project says removal will follow its deprecation policy and tracks that work in KEP-5573. 1
The Kubernetes project published Paco Xu's explanation on October 6, 2026; that is the article's publication date, not a stated release date for v1.35. The transition predates the post: cgroup v2 support became stable in Kubernetes v1.25, while cgroup v1 management entered maintenance mode in v1.31. 1
Control groups are the Linux kernel mechanism Kubernetes uses to allocate resources such as CPU and memory to containers. Cgroup v2 provides a unified hierarchy and a more consistent interface for that management. The immediate compatibility break, however, is the kubelet's startup policy, rather than the disappearance of the older kernel interface: the temporary configuration override permits continued use of v1. 1
Kubeadm-managed workflows encounter a separate obstacle before kubelet startup. Its SystemVerification preflight check reports an error during init, join and upgrade when it detects cgroup v1 with kubelet v1.35 or later; with an older kubelet, it remains a warning. The post does not establish that setting the kubelet override also satisfies this check, so it should not be treated as a documented kubeadm bypass. 1
For an upgrade from a release older than v1.35, the project's guidance is to migrate every Linux node to cgroup v2 first, or deliberately plan the temporary override. The reason to check every node is concrete: a remaining v1 node fails kubelet startup under the default configuration. For clusters already on v1.35 or later, verify that each Linux node uses v2 or intentionally retains the override. 1
The post supplies a read-only inventory check: stat -fc %T /sys/fs/cgroup/. It identifies cgroup v2 by the filesystem type cgroup2fs. This checks the node's mounted cgroup filesystem, not whether an entire cluster has completed migration or whether the kubelet override is configured; use it as one node-level check, not a complete upgrade verdict. 1
Migration also does not eliminate every resource-management problem. The kubelet treats active_file memory as non-reclaimable, so a large page cache from I/O-intensive workloads can cause reported memory pressure and Pod eviction. The project explicitly says moving to cgroup v2 does not change that calculation. Operators investigating those evictions should therefore distinguish satisfying the new startup requirement from resolving the workload's memory-pressure behavior. 1