Kubernetes is drawing a clear line around control groups: cgroup v1 is legacy, and cgroup v2 is the new standard. For operators, this is more than a kernel detail. The transition affects how resources are controlled, workloads are isolated, and clusters are operated over the long term.
cgroup v2 has been stable in Kubernetes since version 1.25. With Kubernetes 1.35, cgroup v1 was officially deprecated, and the kubelet no longer starts on a cgroup v1 node by default. Organizations still relying on older Linux distributions, legacy runtime configurations, or long-lived node images therefore need to act.
Why cgroup v2 matters for Kubernetes
Control Groups are the Linux mechanism used to allocate CPU, memory, and other resources to processes and therefore to containers. Kubernetes relies on them to enforce requests and limits.
cgroup v1 evolved organically over many years. Different controllers could live in separate hierarchies, interfaces were not consistently designed, and delegation was more error-prone.
cgroup v2 unifies that model. It provides a single hierarchy, more consistent semantics, and a cleaner foundation for modern resource management. Capabilities such as Pressure Stall Information and Memory QoS benefit directly from it.
Impact on cluster management
For cluster operators, the migration makes one thing obvious again: the node layer matters.
A Kubernetes upgrade alone is not enough if the operating system underneath still uses cgroup v1. Several layers need to align:
- the Linux distribution and kernel,
- the active cgroup version,
- the container runtime,
- the cgroup driver,
- monitoring and security agents,
- applications that directly access the cgroup filesystem.
This is where heterogeneous fleets create the greatest operational risk. When clusters are built from different operating system releases, images, and runtime versions, what looks like a small platform change can quickly become an infrastructure project.
Consistent node baseline management therefore becomes more important. Clusters should be standardized not only on Kubernetes versions, but also on defined combinations of distribution, kernel, runtime, and kubelet configuration.
Better resource isolation is not a side effect
The move to cgroup v2 does more than improve maintainability. It strengthens the technical foundation for resource isolation.
The unified hierarchy reduces special cases between controllers. Memory accounting becomes more consistent, delegation is cleaner, and modern Kubernetes features can make better use of kernel-level resource controls.
For production platforms, this matters because resource isolation is directly tied to stability. When individual workloads consume CPU or memory aggressively, the quality of the underlying controls determines how strongly neighboring workloads are affected.
cgroup v2 provides a much better foundation for that.
Migration means testing, not just switching
The transition is manageable, but it should not be performed blindly.
Components that read cgroup information directly deserve particular attention. These can include monitoring agents, security tooling, and individual language runtimes. Applications whose memory detection depends on older runtime versions may also behave differently under cgroup v2.
A sensible migration path looks like this:
- Inventory the node fleet and identify the cgroup version in use.
- Verify operating system, kernel, and container runtime compatibility.
- Validate monitoring, security, and observability components.
- Run representative workloads in a cgroup v2 test environment.
- Migrate node pools gradually.
- Only then upgrade to Kubernetes versions where cgroup v1 becomes a hard blocker.
The key point is that cgroup v2 should become part of a reproducible platform baseline rather than a one-off migration exception.
Europe needs consistent infrastructure standards
The technical transition highlights a broader issue: Europe can only build resilient and sovereign digital infrastructure if core platform components are not operated through thousands of incompatible custom configurations.
Kubernetes has become critical infrastructure for enterprises, public-sector organizations, and platform providers. Yet clusters often differ significantly in kernel versions, runtime configuration, node images, and operating procedures.
That makes upgrades harder. It also complicates security assessments, audits, incident response, and workload portability.
European cloud and platform offerings should therefore move toward common, transparent baselines: supported kernel versions, defined runtime versions, consistent cgroup v2 configuration, standardized upgrade paths, and clear operating models.
Standardization does not mean centralization. Quite the opposite: common technical standards make it easier to move between providers, reduce proprietary dependencies, and improve interoperability.
Conclusion
The migration from cgroup v1 to cgroup v2 is a technical change with strategic consequences.
For Kubernetes, it improves resource management and isolation and creates the foundation for modern platform capabilities. For operators, it forces an honest assessment of the node and runtime landscape underneath their clusters.
Organizations that want to run Kubernetes reliably over the long term should not treat cgroup v2 as an inconvenient compatibility task. It is an opportunity to standardize infrastructure.
This is especially relevant in Europe: digital sovereignty is not created by data center geography alone. It depends on open standards, reproducible platforms, and infrastructure that can be operated consistently and moved between providers.