Trending:

Kubernetes shifts to cgroup v2: deprecation of v1 and a roadmap for migration

Kubernetes cluster nodes with cgroup v2 enabled
TechStaged-owned

Summary

  • Kubernetes supports v2 cgroup management, with v1 cgroup management moved to maintenance mode starting with v1.31 and v2 management being stable since v1.25.
  • Kubernetes has deprecated cgroup v1.
  • Starting with Kubernetes v1.35, failCgroupV1 defaults to true, so the kubelet does not start on a cgroup v1 node by default.

Kubernetes now emphasizes cgroup v2 management as the standard path, with support for v1 cgroup management moving into maintenance mode since v1.31 and stable v2 management since v1.25.

Kubernetes has deprecated cgroup v1, and the project has set a timeline that includes removal of v1 support in a future release. Starting with Kubernetes v1.35, failCgroupV1 defaults to true, meaning the kubelet will not start on a cgroup v1 node by default. Administrators can temporarily set failCgroupV1: false in the kubelet configuration file, but removal will follow the deprecation policy.

WHAT CGROUP V2 CHANGES FOR KUBERNETES

Compared with cgroup v1, cgroup v2 provides a single unified hierarchy, a more consistent interface, and a stronger foundation for resource isolation and modern resource-management features. TechStaged has also covered Kubernetes v1.37 Beta: KubeletInUserNamespace (Rootless) Graduates to Beta.

Memory QoS and tiered memory protection rely on the cgroup v2 memory controller, with memory.high used for throttling and memory.min / memory.low for hard/soft protection when tiered reservation is enabled.

In-place Pod vertical scaling, introduced in Kubernetes v1.35 and graduated to stable in v1.35, requires cgroup v2 for accurate enforcement by Kubernetes v1.36. The project also notes broader migration benefits and the need to migrate to v2 before relying on these features.

MIGRATION GUIDANCE AND POLICY FOR ADMINS

If you are running a Kubernetes release older than v1.35, migrate every Linux node to cgroup v2 before upgrading, or plan to use the temporary failCgroupV1: false override.

If you are on v1.35 or later, you should confirm that every Linux node runs cgroup v2 or that you intentionally keep the override. Under the default configuration, a remaining cgroup v1 node can cause kubelet startup failure.

For kubeadm-managed clusters, Kubernetes v1.35 introduces an earlier, stricter SystemVerification preflight check that errors on cgroup v1 with kubelet v1.35 or later during kubeadm init, join, or upgrade; older kubelets may see a warning instead.

MEMORY QOS: CAPABILITIES AND KERNEL REQUIREMENTS

Memory QoS was introduced as an alpha feature in Kubernetes v1.22 and updated in v1.27; it remains alpha in v1.36 but adds tiered memory protection via cgroup v2.

The cgroup v2 memory controller enables memory.high throttling and memory.min / memory.low protections when tiered reservation is enabled; devices and behavior are aligned with Linux kernel capabilities.

Memory QoS requirements include Linux kernel 5.9 or later for the livelock fix and that memory QoS is available only on nodes using cgroup v2.

WHAT YOU NEED TO DEPLOY AND MANAGE CGROUP V2

To use cgroup v2 with Kubernetes, you need a Kubernetes version that supports v2 management (stable since v1.25) and at least one Linux node with cgroup v2 enabled.

The kernel should be 5.8 or later (5.9+ recommended for Memory QoS), and the container runtime should support cgroup v2 (e.g., containerd v1.4+; CRI-O v1.28+). The kubelet and the container runtime must be configured to use the correct cgroup driver, with systemd as the recommended driver when feasible.

Automatic runtime cgroup-driver discovery relies on the RuntimeConfig CRI RPC (e.g., containerd v2.0+ or CRI-O v1.28+). If automatic detection is unavailable, manual overrides may be needed.

HOW TO VERIFY AND PLAN NEXT STEPS

Migration guidance notes that you can opt back to cgroup v1 in Kubernetes 1.36 as a fallback, but removal of v1 is planned for a future release (1.38).

Documentation suggests verification steps such as checking the active cgroup version with tools like stat -fc %T /sys/fs/cgroup/ (which should report cgroup2fs when v2 is active).

Administrators should ensure compatibility between the kubelet, container runtime, and systemd when deploying cgroup v2 in a production environment.

Reporting by Owen Blackridge; editing by TechStaged editors

Editorial disclosure: This article was prepared with AI assistance from a source-limited research package and passed TechStaged's automated factual, originality, licensing, and publication checks.

Our Standards: The TechStaged Editorial Principles.

f in

Owen Blackridge

Owen Blackridge

Technology Editor

Owen covers platform shifts, AI launches, and the practical impact of emerging technology on small teams.