The Shift to cgroup v2 in Kubernetes: What You Need to Know

If you’ve been running Kubernetes for a while, you’ve probably never thought much about cgroups. They work quietly in the background, making sure your containers get their fair share of CPU and memory without stepping on each other’s toes. But with Kubernetes v1.31, the landscape is shifting. The older cgroup v1 implementation is moving into maintenance mode, and cgroup v2 is becoming the standard. If you’re managing clusters—whether on AWS EKS or elsewhere—it’s worth understanding what’s changing and why it matters for your infrastructure.

Let’s start with the basics. Cgroups (control groups) are a Linux kernel feature that allows the operating system to limit and allocate resources to processes. Kubernetes relies on cgroups to enforce resource requests and limits that you define in your pod specs. When you set a container to use a maximum of 512MB of memory, for example, the kernel uses cgroups to enforce that boundary. Cgroup v1, which has been around since 2008, organizes these controls into separate hierarchies for different resource types like CPU, memory, and I/O. This works, but it’s fragmented—your CPU limits live in one place, memory limits in another, creating complexity in how they interact. Cgroup v2, released in 2016 and now considered stable, consolidates all resource controls into a single unified hierarchy. This makes resource management more consistent and predictable, especially in complex scenarios where you’re balancing multiple resource types across many containers.

The technical shift under the hood is significant. With cgroup v2, the kernel tracks resources using a simpler, more cohesive model. Instead of the kernel trying to apply CPU limits in one subsystem and memory limits in another (potentially with conflicting logic), everything flows through one control plane. For practical Kubernetes deployments, this means more accurate resource enforcement, better handling of CPU throttling, and improved memory pressure detection. If you’re running a multi-tenant cluster on EKS or managing workloads that need precise resource isolation, cgroup v2 reduces the edge cases where containers could exceed their limits or where unpredictable behavior emerges from subsystem interactions. Real-world examples include data science teams running resource-intensive training jobs alongside lightweight API services—cgroup v2 provides tighter guarantees that a runaway training job won’t starve the API, and monitoring tools can more reliably track actual resource usage.

So what do you need to do? First, check your node Linux kernel versions. Cgroup v2 is available in most modern Linux distributions (Ubuntu 21.10+, RHEL 9+, Amazon Linux 2023+), but older systems may still run cgroup v1. For EKS specifically, AWS has been rolling out cgroup v2 support gradually, so verify which version your nodes are using by checking the kubelet configuration. If you’re not on v1.31 yet, you’re not forced to migrate immediately—Kubernetes will support both versions for a transition period. But start planning now. Test your workloads on cgroup v2 in a non-production environment, especially if you have tight resource limits or performance-critical applications. The good news is that for most users, the migration is transparent; containers that work on v1 will work on v2 without code changes. The shift is happening because cgroup v2 is simply better engineered for modern, containerized infrastructure, and eventually, the industry will standardize on it completely.