Namespaces and cgroups

## Two orthogonal mechanisms The Linux kernel keeps many resources that are conceptually *global*: the process table, the mount table, the network stack, the hostname, the System V IPC keyspace, the UID space. Namespaces let the kernel keep several independent copies of those global resources and give each process a pointer to the copy it should use. Nothing about that limits how much CPU or memory a process may take. Control groups solve the opposite problem. A cgroup does not hide anything; it groups processes so the kernel can *account* for what they use and *cap* it. A process in a cgroup with `memory.max` set can still enumerate every process on the host and see every mount — it simply cannot allocate past its cap. Both mechanisms are per-process attributes inherited across `fork(2)` and preserved across `execve(2)`, and both are exposed through the filesystem, which is why they get filed together in people's heads. ## What a namespace does The kernel currently offers these types: **mount** (`CLONE_NEWNS`) — a private copy of the mount table; **PID** (`CLONE_NEWPID`) — its own PID numbering, so the first process created inside is PID 1; **network** (`CLONE_NEWNET`) — its own interfaces, routing tables, netfilter rules and socket port space; **UTS** (`CLONE_NEWUTS`) — its own hostname and domain name; **IPC** (`CLONE_NEWIPC`) — its own System V IPC objects and POSIX message queues; **user** (`CLONE_NEWUSER`) — its own UID/GID mapping and capability set; **cgroup** (`CLONE_NEWCGROUP`) — a virtualised view of the cgroup hierarchy root; and **time** (`CLONE_NEWTIME`, Linux 5.6+) — its own boot and monotonic clock offsets. Every namespace a process belongs to is visible as a magic symlink under `/proc/<pid>/ns/`. Two processes are in the same namespace exactly when those symlinks resolve to the same inode number, which is the standard way to compare them: ```bash readlink /proc/self/ns/net /proc/1/ns/net ``` The three ways in are `clone(2)`/`clone3(2)` with `CLONE_NEW*` flags when creating a child, `unshare(2)` to detach the calling process into fresh namespaces, and `setns(2)` to join an existing one through an open file descriptor. ## What a cgroup does On a current distribution the unified hierarchy (cgroup v2) is mounted at `/sys/fs/cgroup`. Each directory is a cgroup; creating a subdirectory creates a child. The processes belonging to a cgroup are listed in its `cgroup.procs` file, and you move a process by writing its PID there. Which controllers a cgroup may use is listed in `cgroup.controllers`, and which of them it hands down to its children is written to `cgroup.subtree_control`. Controllers expose their own knobs: `memory.max` and `memory.high` for memory, `cpu.max` (a quota and a period) and `cpu.weight` for CPU, `io.max` for block I/O, `pids.max` for the number of tasks. Usage is readable back through `memory.current`, `cpu.stat`, `pids.current`. ```bash echo "+cpu +memory +pids" > /sys/fs/cgroup/cgroup.subtree_control mkdir /sys/fs/cgroup/demo echo 100M > /sys/fs/cgroup/demo/memory.max echo "50000 100000" > /sys/fs/cgroup/demo/cpu.max # 50 ms per 100 ms = half a core ``` ## Why the distinction matters in practice The clean way to remember it is *isolation versus limits*. Namespaces are a **security and correctness** feature: they stop a process seeing or touching things that are not its own. Cgroups are a **resource management** feature: they stop a process taking more than its share. Neither substitutes for the other. Put a workload in fresh PID, mount, network and user namespaces but no cgroup, and it can still allocate until the host runs out of memory, spin every core, or spawn processes until the system-wide PID limit is hit — a namespace has no notion of "too much". Conversely, cap a workload with `memory.max` and `pids.max` but give it no namespaces, and it can read `/proc` to enumerate every other process on the box, send signals to them, and see every mounted filesystem. They do meet at the edges. The **cgroup namespace** exists precisely because a process could otherwise read `/proc/self/cgroup` and learn its absolute path in the host's hierarchy; the namespace rebases that view so the process sees its own cgroup as the root. And memory accounting is a cgroup property, not a namespace property — being in a PID namespace does not give a process its own memory budget. ## The stock interview follow-through When an interviewer asks this, they usually want you to land the summary in one line — *namespaces change what you see, cgroups change what you get* — and then show you know the failure mode of each on its own. Saying "they are both how containers work" without separating them is the weak answer.