Kubernetes 1.31: Moving cgroup v1 Support into Maintenance Mode

By Harshal Patil |Wednesday, August 14, 2024

As Kubernetes continues to evolve and adapt to the changing landscape ofcontainer orchestration, the community has decided to move cgroup v1 supportinto maintenance mode in v1.31.This shift aligns with the broader industry’s move towards cgroup v2, offeringimproved functionalities: including scalability and a more consistent interface.Before we dive into the consequences for Kubernetes, let’s take a step back tounderstand what cgroups are and their significance in Linux.

Understanding cgroups

Control groups, orcgroups, are a Linux kernel feature that allows the allocation, prioritization,denial, and management of system resources (such as CPU, memory, disk I/O,and network bandwidth) among processes. This functionality is crucial formaintaining system performance and ensuring that no single process canmonopolize system resources, which is especially important in multi-tenantenvironments.

There are two versions of cgroups:v1 andv2. While cgroup v1provided sufficient capabilities for resource management, it had limitationsthat led to the development of cgroup v2. Cgroup v2 offers a more unified andconsistent interface, on top of better resource control features.

Cgroups in Kubernetes

For Linux nodes, Kubernetes relies heavily on cgroups to manage and isolate theresources consumed by containers running in pods. Each container in Kubernetesis placed in its own cgroup, which allows Kubernetes to enforce resource limits,monitor usage, and ensure fair resource distribution among all containers.

How Kubernetes uses cgroups

Resource Allocation

Ensures that containers do not exceed their allocated CPU and memory limits.

Isolation

Isolates containers from each other to prevent resource contention.

Monitoring

Tracks resource usage for each container to provide insights and metrics.

Transitioning to Cgroup v2

The Linux community has been focusing on cgroup v2 for new features andimprovements. Major Linux distributions and projects likesystemd aretransitioning towards cgroup v2.Using cgroup v2 provides several benefits over cgroupv1, such as Unified Hierarchy,Improved Interface, Better Resource Control,cgroup aware OOM killer,rootless support etc.

Given these advantages, Kubernetes is also making the move to embrace cgroupv2 more fully. However, this transition needs to be handled carefully to avoiddisrupting existing workloads and to provide a smooth migration path for users.

Moving cgroup v1 support into maintenance mode

What does maintenance mode mean?

When cgroup v1 is placed into maintenance mode in Kubernetes, it means that:

1. Feature Freeze: No new features will be added to cgroup v1 support.
2. Security Fixes: Critical security fixes will still be provided.
3. Best-Effort Bug Fixes: Major bugs may be fixed if feasible, but someissues might remain unresolved.

Why move to maintenance mode?

The move to maintenance mode is driven by the need to stay in line with thebroader ecosystem and to encourage the adoption of cgroup v2, which offersbetter performance, security, and usability. By transitioning cgroup v1 tomaintenance mode, Kubernetes can focus on enhancing support for cgroup v2and ensure it meets the needs of modern workloads. It’s important to notethat maintenance mode does not mean deprecation; cgroup v1 will continue toreceive critical security fixes and major bug fixes as needed.

What this means for cluster administrators

Users currently relying on cgroup v1 are highly encouraged to plan for thetransition to cgroup v2. This transition involves:

1. Upgrading Systems: Ensuring that the underlying operating systems andcontainer runtimes support cgroup v2.
2. Testing Workloads: Verifying that workloads and applications functioncorrectly with cgroup v2.

Further reading