cgroup v2 Internals

cgroup v2 unified hierarchy, cpu/memory/io controllers, delegation for rootless containers, and Kubernetes integration.

Overview

cgroups v2 (control groups version 2) is the Linux mechanism for grouping processes and applying resource limits — CPU, memory, I/O, PIDs, and CPU sets. It supersedes cgroups v1 with a unified hierarchy (one tree instead of per-controller trees).

v1 vs v2

Hierarchy — Per-controller (separate trees) — Single unified tree
CPU accounting — cpuacct controller — Built into cpu controller
I/O control — blkio controller — io controller (weight + BPS/IOPS limits)
Memory OOM — Per-cgroup, inconsistent — Unified OOM, memory.oom.group
Delegation — Complex, unsafe — Safe subtree delegation

Key Controllers

cpu — cpu.weight (proportional shares 1-10000), cpu.max (hard limit: quota period)
memory — memory.max (hard limit), memory.high (soft limit that triggers throttling), memory.swap.max
io — io.weight, io.max (BPS and IOPS limits per device)
pids — pids.max (fork bomb protection)
cpuset — pin to specific CPUs and NUMA nodes

Kubernetes and cgroups v2

Kubernetes 1.25+ requires cgroups v2 for memory QoS (guaranteed/burstable distinction via memory.high) and for rootless container support (delegation chain from system cgroup to user session). Containerd and cri-o configure pod cgroups under /sys/fs/cgroup/kubepods/.

Delegation for Rootless Containers

In v2, a parent cgroup can delegate its subtree to a non-root user. The user can create sub-cgroups and apply limits without CAP_SYS_ADMIN on the root cgroup. This is how rootless Docker and Podman work: systemd delegates a user slice, and the container runtime manages sub-cgroups within it.

Key concepts

cpu.max: "quota period" format — e.g., "50000 100000" means 50ms CPU time per 100ms period (50% of one core). "max 100000" means unlimited.
memory.high: Soft memory limit. When exceeded, the kernel throttles memory allocations and triggers reclaim before OOM. Burstable pods use this for QoS.
memory.oom.group: When set to 1, OOM killer kills the entire cgroup as a unit rather than individual processes. Set by container runtimes so the whole container dies, not just one thread.
Delegation: v2 allows a parent to grant a subtree to a non-root user. The user gets write access to cgroup.subtree_control and can manage their sub-hierarchy without root.

When to use it

Explaining how Kubernetes resource requests/limits translate to kernel cgroup settings
Debugging OOMKilled pods and memory.high throttling behavior
Explaining rootless container operation and delegation security model

Interview questions

How does Kubernetes translate a pod resource request/limit into kernel cgroup settings?