Docker
25 min
Day 33: Namespaces & cgroups
How isolation is actually implemented
A container isn't a VM — it's an ordinary Linux process, made to *look* isolated using two kernel features: namespaces (what a process can see) and cgroups (what a process can use).
- PID namespace — the container sees its own process tree, starting at PID 1
- Network namespace — its own network interfaces, routing table, ports
- Mount namespace — its own filesystem view
- UTS namespace — its own hostname
- cgroups — hard limits on CPU, memory, I/O a group of processes may consume
Namespaces = what you see, cgroups = what you get
A process in a PID namespace genuinely cannot see other containers' processes — not hidden, structurally invisible. cgroups is the other half: even if it could see more, cgroups enforces a hard ceiling on the CPU/memory it can actually consume — exactly the CFS-enforced mechanism from Phase 0, Day 4.
Seeing this yourself
# Inside a container, PID 1 is your app, not systemd
docker run alpine ps aux
# The cgroup limits Docker sets under the hood
docker run --memory=256m --cpus=0.5 alpine cat /sys/fs/cgroup/memory.maxKey terms
- Namespace
- A kernel mechanism that gives a process an isolated view of some global resource (PIDs, network, mounts, hostname).
- cgroup
- A kernel mechanism that limits and accounts for the resources (CPU, memory, I/O) a group of processes may use.
A container is limited to 256MB of memory. Which kernel mechanism enforces that limit?
