The countdown is on: Kubernetes disables cgroup v1 – a migration checklist for 2026

The countdown is on: Kubernetes shuts down cgroup v1 – a migration checklist for 2026

Since Kubernetes 1.37 in August 2026 at the latest, the message is unmistakable: the kubelet no longer starts on a cgroup v1 node – unless an administrator explicitly sets the temporary failCgroupV1: false. What many teams saw as a side note in the release notes is now becoming operational reality. Kubernetes 1.34 reached the end of its support cycle on October 27, 2026, and with every upgrade to 1.35 or newer, the cgroup v2 migration is on the table. Those who do not act now risk nodes that simply fail to come up after the next upgrade.

Why cgroup v2?

cgroups (Control Groups) are the Linux kernel mechanism that Kubernetes uses to enforce CPU and memory limits for containers. cgroup v1 organised this control over several separate hierarchies – one per resource controller. This led to inconsistent behaviour across distributions and made features like In-Place Pod Resizing or reliable Memory QoS difficult.

cgroup v2 replaces this model with a single, unified hierarchy. The switch brings three concrete operational improvements:

Memory QoS with a two-tiered model: cgroup v2 introduces a soft limit with memory.high, which throttles and triggers reclaim before the OOM killer. cgroup v1 only knew the hard memory.limit_in_bytes – either the container fits within the limit, or the OOM killer cleans up. Starting with Kubernetes 1.36, the Memory QoS feature (still Alpha) can even enable graduated protection (TieredReservation): Guaranteed pods receive hard protection via memory.min, Burstable pods receive soft protection via memory.low.

Container-aware OOM handling: On cgroup v2 nodes, the kubelet sets memory.oom.group per container cgroup by default. An OOM event then kills all processes of a container together, rather than individual processes – this prevents partially malfunctioning multi-process containers.

Per-cgroup PSI metrics: Starting with Kubernetes 1.36, Pressure Stall Indicators (PSI) per cgroup are available (GA). Instead of only measuring overall node pressure, platform teams can now monitor the load of individual tenants or namespaces – and trigger alerts before the OOM killer strikes. This capability has no cgroup v1 counterpart.

The timeline: From warning to hard stop

The migration has been underway for years – but 2026 is the year of enforcement:

The official Kubernetes blog published a comprehensive guide on October 6, 2026, titled “The Shift to cgroup v2”, summarising the current state. The message: failCgroupV1: false is a temporary escape hatch, not a permanent configuration mode. Those who set it buy time – but the direction is final.

Which nodes are affected?

The good news: most current distributions ship cgroup v2 by default – Ubuntu 22.04 and 24.04, Debian 12, Amazon Linux 2023, RHEL 9.4+, and Talos Linux 1.3+. The risk lies in older base images: Ubuntu 20.04, Debian 10, CentOS 7, and nodes manually reverted to v1.

The check is simple: stat -fc %T /sys/fs/cgroup/ on each node returns cgroup2fs for v2 and tmpfs for v1.

Migration checklist

1. Audit your fleet: Run stat -fc %T /sys/fs/cgroup/ on all nodes – note the v1 candidates.
2. Check the container runtime: Kubernetes 1.37 requires containerd 2.0 or newer. containerd 1.x is no longer supported.
3. Test legacy agents: Monitoring tools, security agents, and direct cgroup accesses (e.g., --max-old-space-size in Node.js apps) must support cgroup v2.
4. Update the base image: Upgrade nodes to a distribution with cgroup v2 default – or for self-managed images, set the kernel boot parameter systemd.unified_cgroup_hierarchy=1.
5. Validate workload behaviour: After the switch, check the CPU weight mapping (cgroup v1 shares → v2 weight) – the conversion formula has changed.
6. Evaluate Memory QoS: Those who want to use the Alpha features MemoryQoS and TieredReservation need cgroup v2. The official blog recommends testing the configuration in a non-production environment beforehand.

Conclusion

The cgroup v2 migration is no longer optional – it is the new standard. With Kubernetes 1.38 on the horizon (expected December 2026) and the planned removal of cgroup v1 code, the remaining time is tight. Platform teams that audit their fleet now, update legacy agents, and plan the switch will avoid the stress of a forced upgrade under time pressure. The effort pays off: cgroup v2 brings not only compliance with the deprecation path but also better resource isolation, finer-grained memory control, and the PSI transparency that is becoming increasingly essential for operating AI workloads and multi-tenant platforms.

Sources

• Kubernetes Blog: The Shift to cgroup v2 in Kubernetes (6. Oktober 2026)
• bex.co: cgroup v1 Is About to Break Your Kubernetes Nodes (28. Juli 2026)
• Tech Insider AU: Kubernetes 1.35 Hits GKE, cgroup v1 Axed (22. September 2026)