Don't Panic: Linux Namespaces and Control Groups

Linux namespaces and cgroups are two ways to stop an ordinary Linux process from behaving as though it owns the whole machine. They are not a tiny replacement computer. They are arrangements made by the same host kernel that was already there, which is less magical than it sounds and more useful than it first appears.

A namespace changes a process's view. Give it a mount namespace and it gets a different mount table. Give it a network namespace and it gets its own devices, routes, firewall rules, and port space. Give it a PID namespace and it gets its own process-ID view, including a PID 1 that must reap children. The kernel has not gone anywhere; the process has been issued a carefully edited map.

A cgroup answers the question the map cannot: how much CPU, memory, I/O, or process creation may this group of processes use? Cgroup v2 puts groups in one hierarchy. Controllers attach rules to that tree. A maximum is a boundary, while a weight is only a share when siblings compete. Confusing those two produces the traditional result: a configuration that looks disciplined until the workload becomes busy.

The surprising bit is that these controls are independent. Two processes can see the same network and live in different cgroups. They can share a cgroup while seeing different process lists. A cgroup namespace can hide a host-side path prefix without moving anything or granting authority over controllers. The label on a container is therefore not an explanation. Membership and placement are.

Container runtimes assemble the parts: namespaces, mounts, networking, user-ID mappings, capabilities, system-call filtering, then cgroup placement. User namespaces are especially good at puncturing the phrase root: user identifier zero inside a namespace can map to an unprivileged identifier outside it. That is reduced host privilege, not a private kernel in a convincing hat.

When something fails, begin with the symptom. A missing process suggests the PID namespace. A missing route suggests the network namespace. Periodic pauses suggest cpu.max; memory events and Pressure Stall Information expose pressure before or during a harder failure. The Cheatsheet maps those signals to the relevant files. The Slides compress the relationships. The Intro explains why delegation, capabilities, seccomp, and mandatory access control must accompany these mechanisms when the boundary matters.

Keep one sentence available for emergencies: namespaces partition views; cgroups organize and govern resource use. It is not the whole story, but it keeps you from asking a resource limit to hide a process, or a namespace to prevent a fork storm. The kernel appreciates precise questions, largely because it has no alternative.

Don't Panic: Linux Namespaces and Control Groups

Relevant careers