- Since Kubernetes v1.35, a node still on cgroup v1 fails during kubelet startup by default, according to the Kubernetes project.
- The v1 fallback is scheduled for removal in v1.38, so an override only buys time.
- Inventory every Linux node before the upgrade window, and test monitoring tools on cgroup v2 first.
The node nobody remembers
An old setting can go unnoticed through several releases while a default covers for it. The dates here show how long that cover lasted. Cgroup v1 went into maintenance mode in v1.31. The default flipped in v1.35. The fallback is scheduled to go in v1.38.
Since v1.35, a node that still uses the older cgroup v1 resource system will not start its kubelet by default. The kubelet is the agent that runs on every node. The lesson is that a deprecation becomes a business problem on the day a default changes. That day can fall inside an ordinary upgrade.
What the Kubernetes project said
The Kubernetes project published its guidance on October 6, 2026. Cgroups, short for control groups, are a Linux kernel feature. Kubernetes uses them to give each container a share of CPU and memory. That keeps one workload from crowding out another.
Cgroup v2 has been stable in Kubernetes since v1.25. Cgroup v1 entered maintenance mode in v1.31. From v1.35, a setting called failCgroupV1 defaults to true. With that default, a node on v1 fails while the kubelet starts.
A stopgap exists. An administrator can switch failCgroupV1 to false in the kubelet's configuration file. The blog says v1 remains a supported fallback in v1.36, the current release. It also says that fallback is scheduled for removal in v1.38.
How the change reaches your clusters
Cgroup v1 gave each resource type its own separate hierarchy. Cgroup v2 uses one unified hierarchy with a more consistent interface. The project calls it a stronger base for isolation and newer features.
Teams that build clusters with kubeadm meet the change sooner. A preflight check now reports cgroup v1 as an error when the kubelet is v1.35 or newer. It covers kubeadm init, join and upgrade. With an older kubelet, the check gives only a warning.
Behaviour that changes after migrating
Moving to v2 is more than a switch. The blog lists differences that can show up in production.
First, memory exhaustion. On v2 nodes, a container that runs out of memory now has all its processes stopped together. The setting is singleProcessOOMKill, and it defaults to false. On v1, the kernel might stop one process and leave a half-working container. Setting the option to true brings back the v1-style result.
Second, CPU priority. The two versions use different units, called shares on v1 and weight on v2. Container runtimes translate between them. Newer runtimes, not Kubernetes itself, carry a changed conversion curve. It starts in crun v1.23 and runc v1.3.2. It is not a straight-line scale. It keeps the default priority where it was and gives small CPU requests more distinct steps. After a runtime upgrade, tools that predict exact weight values may need updating.
Third, software that reads cgroup files directly. The project's migration guidance names cAdvisor v0.43.0 as the minimum. It also gives version advice for Java, Node.js and automaxprocs.
One known issue stays after migration. The kubelet does not count a kind of cached file memory, called active_file, as memory it can free. Heavy disk workloads can fill that cache. The kubelet may then report memory pressure and evict Pods. The blog says v2 does not change this by itself. For containers that do intensive disk work, the documented fix is to measure a suitable amount first. Teams then give requests and limits the same memory value.
What v2 unlocks
The blog ties several newer features to v2. Pressure Stall Information reports CPU, memory and I/O contention, and it needs v2. Memory QoS protects memory for important Pods, and it needs v2 too. Memory QoS is still alpha in v1.36. The project advises against alpha features in production.
In-place resizing of Pod-level resources needs v2 for accurate enforcement. The blog also says v2 officially supports handing controllers to less privileged containers. Version 1 does not.
Questions for your platform team
Start with inventory. Ask which Linux nodes still run cgroup v1, including old images and rarely touched pools. On a node, the command stat -fc %T /sys/fs/cgroup/ returns cgroup2fs when v2 is on.
Then ask four more questions.
Which Kubernetes version do we run, and does our next upgrade cross v1.35?
If we use the failCgroupV1: false override, who removes it before v1.38?
Do our runtime and kernel meet the stated minimums, such as kernel 5.8?
Do our monitoring and policy tools read cgroup files directly, and have we tested them on v2?
A deprecation notice costs little to read. A node that refuses to start mid-upgrade costs far more. The cheapest time to find your last cgroup v1 node is before the upgrade window opens.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Kubernetes.
