In this lesson, you will learn how to navigate the architectural differences between Cgroup v1 and v2, specifically focusing on the transition challenges regarding resource accounting and hierarchical structure.
The Architectural Divide
Cgroup v1 was designed with a "multi-hierarchy" model, where each resource controller (like cpu, memory, or blkio) could be mounted in its own independent tree. This led to complex fragmentation, where a process might belong to different control groups for different resources, making unified accounting impossible.
Cgroup v2 simplifies this into a "unified hierarchy." In this model, all enabled controllers are bound to a single tree. This change forces a shift in how you manage resource lifecycle:
The Migration Constraint
The primary friction point during migration is the "No Internal Processes" rule. In v1, it was common for a cgroup to hold both child cgroups and active processes. In v2, a non-root cgroup can only contain processes if it has no child cgroups. This strict enforcement ensures that resource delegation remains unambiguous.
When migrating services, you cannot simply copy the v1 structure; you must restructure your process organization so that only leaf nodes contain application processes. Furthermore, accounting in v2 is more granular but also more restrictive. Consider this transition:
# v1: Controllers operate independently
mount -t cgroup -o cpu,memory /sys/fs/cgroup/cpu_and_mem
# v2: Unified hierarchy (the controller is enabled via cgroup.subtree_control)
echo "+memory" > /sys/fs/cgroup/user.slice/cgroup.subtree_control
Compatibility Modes
To bridge this gap, Linux provides the cgroup_no_v1 kernel parameter, which disables legacy controllers, and the "hybrid" mode, where v1 controllers exist alongside the v2 hierarchy. However, relying on hybrid mode is discouraged for production containerization, as it creates a split-brain state where accounting is inconsistent across the system.
When you move from v1 to v2, you are not just changing syntax; you are moving from a state of fragmented resource management to one of centralized, hierarchical control where the kernel enforces strict boundaries to prevent accounting leaks between process groups.
Key Takeaway: Moving from Cgroup v1 to v2 requires moving from independent resource trees to a unified hierarchy, enforcing a strict separation where processes and child cgroups cannot coexist within the same node.