Linux cgroups: Resource Fences for Processes

WHY IT EXISTS On a multi-tenant Linux server, a single runaway process could consume all available CPU or memory, starving every other process and crashing the system. There was no native way to partition and guarantee resources for specific applications before cgroups were introduced into the Linux kernel.

THE MENTAL MODEL Think of cgroups as resource fences or budgets for a group of processes. You create a 'fence' and put processes inside it. Then you tell the kernel, 'Anything inside this fence can collectively use at most 1 CPU core and 2GB of RAM.' This is the core mechanism that makes container resource isolation possible.

HOW IT WORKS Cgroups are managed through a special virtual filesystem, usually mounted at /sys/fs/cgroup. The kernel exposes a directory structure where each directory represents a control group. To set a limit, you simply write a value to a specific file within that directory. For example, to limit memory, you would write the number of bytes to the 'memory.max' file (in cgroup v2). Container runtimes like containerd read a container's spec and automate this process of writing to the correct cgroup files.

WHEN TO USE IT You use cgroups indirectly almost every time you work with containers. When you specify docker run --memory=2g or define resources.limits in a Kubernetes Pod YAML, you are configuring the container runtime to set up and manage cgroups for your application's processes. It is the foundation of resource management in modern container orchestration.

WHEN NOT TO USE IT Application developers should almost never interact with the cgroup filesystem directly. The abstractions provided by Docker, Kubernetes, or systemd are safer and more portable. Direct manipulation is reserved for those building container runtimes, custom system daemons, or doing very low-level performance debugging on a specific node.

ONE CANONICAL EXAMPLE The most common interaction is through a Kubernetes Pod specification. Defining resources: { limits: { cpu: "500m", memory: "256Mi" } } for a container tells the kubelet on the node to configure the underlying container runtime (like containerd) to place that container's processes into a cgroup with a CPU quota of 50% of one core and a memory limit of 256 Mebibytes. If the container tries to exceed this memory, it will be OOM-killed.