Operating Systems Reference/Containers & Virtualization

Linux Namespaces & cgroups

PID, mount, network, UTS, IPC, user namespaces for isolation; cgroups v2 for CPU, memory, and I/O limits — the actual syscalls and files Docker and Kubernetes configure.

4/5Overview: 35m

Namespaces — what you can see

Each namespace type isolates one global resource view:

NamespaceIsolatesContainer effect
PIDProcess IDsPID 1 inside, host PID elsewhere
MountFilesystem mount tableContainer root at /
NetworkInterfaces, routes, iptablesOwn eth0, own loopback
UTSHostnamehostname in container
IPCSysV IPC, POSIX mqSeparate shm segments
UserUID/GID mappingRoot in container ≠ root on host
Cgroupcgroup hierarchy viewNested 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:

ControllerKey knobsProduction symptom
cpu.maxCPU bandwidth capThrottling, high nr_throttled
memory.maxHard memory ceilingOOM kill inside cgroup
memory.highSoft throttle pointReclaim pressure before OOM
io.maxDisk bandwidthSlow writes under neighbor load
pids.maxProcess countFork 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

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 limits

    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.

    20m