Namespaces — what you can see
Each namespace type isolates one global resource view:
| Namespace | Isolates | Container effect |
|---|---|---|
| PID | Process IDs | PID 1 inside, host PID elsewhere |
| Mount | Filesystem mount table | Container root at / |
| Network | Interfaces, routes, iptables | Own eth0, own loopback |
| UTS | Hostname | hostname in container |
| IPC | SysV IPC, POSIX mq | Separate shm segments |
| User | UID/GID mapping | Root in container ≠ root on host |
| Cgroup | cgroup hierarchy view | Nested cgroup delegation |
unshare(2) and clone(2) flags create them; Docker/containerd compose the full set at run.
cgroups v2 — what you can use
Control groups limit and account resources:
| Controller | Key knobs | Production symptom |
|---|---|---|
cpu.max | CPU bandwidth cap | Throttling, high nr_throttled |
memory.max | Hard memory ceiling | OOM kill inside cgroup |
memory.high | Soft throttle point | Reclaim pressure before OOM |
io.max | Disk bandwidth | Slow writes under neighbor load |
pids.max | Process count | Fork bomb containment |
Files live under /sys/fs/cgroup/ — Kubernetes, systemd, and Docker write them when starting a workload.
How they compose
A "container" = process tree in namespaces + cgroup membership. From the host: ps aux shows container processes. From inside: only namespace-visible PIDs exist. docker inspect cgroup path → correlate with memory.current at OOM time.
User namespaces
Map container UID 0 → unprivileged host UID (e.g., 100000). Root in container can't mount host / or load kernel modules. Not a silver bullet — kernel bugs and misconfigured capabilities (CAP_SYS_ADMIN) still bite.
Senior-level signal
Kubernetes resources.limits.memory maps to memory.max — hitting it kills the container, not the node. limits without requests causes scheduling on crowded nodes. OOM score inside cgroup ignores node-level free memory. Debug with kubectl describe pod OOMKilled reason and host dmesg cgroup OOM lines.
Where this goes next
You've reached the end of the OS reference roadmap — revisit CPU virtualization and memory topics when debugging scheduler latency, cgroup throttling, or container OOM in production.
Further Reading
- man 7 namespaces — the seven namespace types and what each isolatesReference20m
- man 7 cgroup_namespaces + kernel cgroup v2 docs — memory.max, cpu.max, and OOM behavior inside cgroupsReference25m
- LWN.net — Namespaces and containers (historical but clear overview of how namespaces compose into containers)Article25m
Hands-On Tasks (Optional)
Low-setup exercises on your local machine. No autograding — the goal is to build intuition, not pass a test.
- Inspect a container's cgroup limits20m
Run a container with a memory limit: `docker run -d --memory=128m nginx`. Find its cgroup path: `docker inspect <id> --format '{{.HostConfig.Memory}}'` and on Linux browse `/sys/fs/cgroup/...` for memory.max. Understand why the container gets OOM-killed at 128MB.