control groups
/ SEE-groups /
Control groups, almost always shortened to cgroups, are the kernel feature that limits and accounts for how much of the machine's resources a group of processes is allowed to use. If namespaces answer what can a container see, control groups answer how much can it use. Think of giving each team in a shared kitchen a metered allowance: this team may use at most two burners and a fixed amount of gas per hour, no matter how hungry they get — so one greedy team can never leave the others with a cold stove.
Concretely, you place a set of processes into a control group and then attach limits to that group through resource controllers. A CPU controller caps how much processor time the group gets, or weights it against other groups. A memory controller sets a hard ceiling on how much RAM the group may use, and can kill or throttle it if it tries to exceed that. There are controllers for block-device I/O bandwidth, for the number of processes, and more. The kernel both enforces these caps and measures actual usage, so cgroups are also how a system tracks exactly how much CPU and memory each container is consuming.
Control groups matter because they are the resource-limiting half of containers: namespaces isolate the view, cgroups isolate the consumption, and together they let many containers safely share one host without any one of them hogging the machine. They are also used outside containers — for instance, to keep a background job from starving an interactive desktop. The honest note is that cgroups bound resource use, not security: they stop a container from exhausting CPU or memory, but they do not by themselves stop a container from seeing or attacking what it should not — that is the job of namespaces and the kernel's protection mechanisms.
A host runs ten containers and caps each one's cgroup at 10% of the CPU and 512 MB of memory. One container hits an infinite loop and tries to consume everything — but its cgroup throttles it to its 10% slice, so the other nine containers and the host stay responsive.
A cgroup caps a runaway container so it cannot starve its neighbours.
Control groups limit resource consumption, not access: they stop a container exhausting CPU, memory, or I/O, but they are not a security boundary. Isolation of what a process can see and touch comes from namespaces and the kernel's protection, not from cgroups.