Exercises — Containers — namespaces, cgroups, difference from VMs

The rule: SEE = namespace, USE = cgroup. (Re-read the SEE-vs-USE figure above if unsure which column each item lands in.)

• (a) namespace (PID namespace — you see a fresh numbering starting at 1).
• (b) cgroup (memory controller — a quantity limit).
• (c) namespace (UTS namespace isolates the hostname you see).
• (d) cgroup (cpu controller — a quantity limit).
• (e) namespace (network namespace — a private view of interfaces).

Score = number correct out of 5.

• clone → (ii) create a child with fresh namespaces (via CLONE_NEW* flags). See Processes and the clone/fork syscall.
• unshare → (i) move the current process into new namespaces.
• setns → (iii) join an existing namespace — this is how docker exec steps into a running container. See Linux Kernel — syscalls.

The formula (from the parent note): $\text{CPU share}=\frac{\text{quota}}{\text{period}}\text{cores}$ WHAT the two numbers mean, seen on the bucket figure above: the kernel scheduler (see Scheduling — CFS and CPU shares) drops quota microseconds of runtime into the bucket, and refills it every period microseconds. Plug in: $\frac{50000}{100000}=0.5$ cores $=50\%$ of one core. Milliseconds: $50000\mu s=50\text{ms}$ of CPU per $100$ ms window (the mint stretch in the figure). After spending 50 ms, the group is frozen (slate stretch) until the next window refills the bucket.

We invert the formula. We want $\frac{\text{quota}}{\text{period}}=1.5$ with $\text{period}=100000\mu s$. $\text{quota}=1.5\times 100000=150000\mu s$ So write: cpu.max = "150000 100000". WHY this is legal to exceed 1.0: on a multi-core machine a group can use more than one full core, because in a single 100 ms window it may accumulate runtime across several CPUs simultaneously — the bucket now holds more tokens than one CPU could spend alone.

"MiB" (mebibyte) uses powers of two, not ten: $256\text{MiB}=256\times 1024\times 1024=268435456\text{bytes}$ So: echo 268435456 > /sys/fs/cgroup/myapp/memory.max. WHY exact bytes: the kernel counts a process's resident memory (RSS) in bytes; when the running total crosses this threshold the memory controller triggers the OOM-killer inside that group only.

The picture — see the figure below. The kernel normally keeps one global PID table (left ledger). A PID namespace gives your process group its own private copy of that table (right ledger). Crucially, the mint bar underneath shows the same single kernel still running every real process — nothing is deleted.

Reading the figure:

• The 400 host processes still exist and still consume CPU/RAM — the kernel (mint bar) still runs them. They fill the left ledger.
• But ps reads /proc, which --mount-proc remounted to reflect your PID namespace — so it reads the right ledger. That ledger only has entries you created, renumbered from 1.
• Your shell is PID 1 because a fresh table starts counting at 1 (top of the right ledger).

The key idea: isolation here is bookkeeping, not deletion. The two ledgers describe the same running processes; you were simply handed a different ledger to read. This is exactly the "lied to about what you can SEE" from the parent note.

uname -r asks the running kernel for its version.

• Container = host: identical strings prove there is exactly one kernel. The container is a process on the host kernel; when it asks "what kernel am I on?", it gets the host's answer because that is its kernel. Isolation was namespaces + cgroups (software bookkeeping), not a second kernel.
• VM ≠ host: a different version proves the VM booted its own separate guest kernel on virtual hardware provided by a hypervisor (see Virtualization and Hypervisors (Type 1 vs Type 2)).

One-line rule proved: same kernel version ⇒ container; different kernel version ⇒ VM.

• Present: the pids cgroup controller. It caps the number of processes at 100, so a fork bomb cannot explode past that count. That is a USE limit.
• Missing: the PID namespace. Without it, the service shares the host's one global PID table — so it can SEE the database's PID and name it as a target.
• Why the kill succeeded: kill needs (1) the target's PID to be visible, and (2) sufficient privilege. The cgroup limited quantity but did nothing about visibility, so condition (1) held. The kill went through.

Lesson: cgroups ≠ isolation. You needed a PID namespace to make host PIDs invisible (and a user namespace to drop privilege).

Build it feature by feature — each requirement maps to exactly one mechanism:

The synthesis idea: clone() with exactly the flags the requirements demand — CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWUSER — privatises every global table these five requirements name; the cgroup meters what it consumes. Together = isolation (SEE) + limits (USE). That is a container. (Note: we did not add CLONE_NEWUTS, because no requirement asks to isolate the hostname — only add the namespace flags a requirement actually needs.) The root filesystem itself would typically be an overlayfs image.

Byte check for (d): $512\times 1024\times 1024=536870912$ bytes; cpu.max "100000 100000" = $100000/100000=1.0$ core.

The core fact: a container is just processes on the host kernel, and those processes make syscalls to that kernel. A Linux binary issues Linux syscall numbers (e.g. clone, openat). The Windows NT kernel implements a different syscall interface, so those numbers mean nothing to it — the binary would crash immediately. So the chain is:

1. Docker Desktop quietly boots a lightweight VM (via a hypervisor) that runs a real Linux kernel.
2. Your "Linux container" is a set of namespaced+cgrouped processes inside that Linux VM, on the Linux kernel.
3. From your Windows desktop it looks seamless, but there are two layers: a VM (to get a Linux kernel) and a container (inside it).

Conclusion: the rule "you cannot run a foreign OS kernel in a container" is not broken — Docker smuggled in a real Linux kernel via a VM first. One kernel per container, and it must be the right kernel.

Apply $\text{share}=\text{quota}/\text{period}$ at the boundaries (picture the refill bucket from Level 2 — now the bucket is either empty or bottomless).

• "0 100000": $\text{quota}=0$, so $0/100000=0$ cores. The scheduler refills a bucket of zero runtime each window → the group gets no CPU at all and is permanently frozen (starved). This is a degenerate input: a valid-looking string that halts the container. Rarely what you want.
• "max 100000": the literal token max means no limit. $\text{quota}=\infty$ effectively, so the group can use as many cores as the machine has — unthrottled.

Mastery point: the same file spans the whole range from "totally frozen" (0) to "unlimited" (max). Always sanity-check the edges, not just a mid value like 50000.

$1.5+1.5=3.0$ cores requested, but only $2.0$ exist. cpu.max is a ceiling, not a reservation — it caps how much each may take, but cannot manufacture cores that don't exist.

• Since neither individually asks for more than 2 cores, each tries to burst to 1.5. But total demand (3.0) exceeds supply (2.0), so the CFS scheduler (see Scheduling — CFS and CPU shares) fairly time-slices the 2 available cores between the two groups.
• What actually happens: with equal CPU weight and both fully CPU-bound, CFS splits the 2 cores evenly, so each container converges to about $2.0/2=1.0$ core — below its 1.5 ceiling. Neither container's cpu.max ceiling ever bites, because the hardware limit (2 cores total) bites first. If one container's load dropped, the other could rise toward its 1.5 ceiling, since spare cores would become available.
• What enforces it: two layers act in order — first CFS fairly shares the scarce real cores; the per-group cpu.max throttle would only kick in if a group tried to exceed its own 1.5-core ceiling, which never happens here.

Mastery point: distinguish limit (cpu.max — an upper bound) from weight/share (cpu.weight — proportional split when contended). Ceilings prevent hogging; weights decide who wins under contention. Neither creates extra cores.

• What the app thinks: /proc/meminfo shows the host's 32 GiB (no mount/PID namespace means it reads the real host /proc). So the app happily sizes its cache to, say, 8 GiB, thinking it has room.
• What the kernel does: the memory cgroup counts this group's RSS. The moment the group crosses 256 MiB, the OOM-killer fires inside the group and kills the app — long before 1 GiB.
• Why it's classic: visibility (/proc) and limits (cgroup) are separate. Without a namespace to make /proc reflect the cgroup, the app sees host numbers and mis-plans, then dies. This is the real-world "container reports host RAM" bug (JVMs and Node used to size heaps from host /proc/meminfo).

Fix in practice: run inside proper namespaces and have the runtime read cgroup limits (memory.max) instead of /proc/meminfo. Once more: SEE (namespace) and USE (cgroup) are independent — set both, and make the app trust the cgroup.

Rule that decides container vs VM in one command ::: uname -r — same version = container (one kernel), different = VM (own kernel) Two independent legs every container stands on ::: namespaces (isolate what you SEE) + cgroups (limit what you USE) cpu.max "0 100000" does what ::: quota 0 → 0 cores → process permanently starved/frozen Why "256 MB" ≠ "256 MiB" for memory.max ::: MB = 256×10^6 = 256000000; MiB = 256×2^20 = 268435456 bytes Why Docker-for-Windows can run Linux containers ::: it boots a hidden lightweight Linux-kernel VM; the containers run inside that