Namespaces & cgroups
What Makes a Container
A very common misconception when first meeting Docker or similar tools is thinking of a container as a tiny virtual machine. It isn't - a container is just an ordinary Linux process, exactly like the ones you inspected with ps back in the Process Management module, made to look isolated using two kernel features that have nothing to do with virtualization hardware at all.
| Feature | Provides |
|---|---|
| Namespaces | Isolation - each container sees its own PIDs, network, mounts, hostname, users |
| cgroups | Limits - cap CPU, memory, I/O, PIDs per group of processes |
Namespaces solve the visibility problem: a namespace wraps a process so it perceives its own private view of some kernel resource - its own PID numbering starting fresh at 1, its own network interfaces and routing table, its own filesystem mount points - while the real, unwrapped host still sees everything as it actually is. A process inside a PID namespace might genuinely believe it's PID 1 on the whole machine, while the host correctly tracks it as, say, PID 48213 among hundreds of others.
cgroups (control groups) solve the separate limits problem: even a perfectly isolated-looking process can still be governed by hard caps on how much CPU time, memory, or disk I/O it's allowed to consume, enforced directly by the kernel - the same underlying mechanism used to cap resources for the very ShellGenius lab container this course runs inside.
Analogy: Namespaces are like giving someone their own hotel room with its own door number and their own view out the window - they experience a private space, even though it's really one floor of a shared building. cgroups are the building's utility meters, capping how much water or electricity each room can draw regardless of how private the room feels. A container gets both: it looks like its own isolated machine (namespaces), and it's bounded in how many host resources it can actually consume (cgroups).
| Isolation vs | VM | Container |
|---|---|---|
| Kernel | Own kernel | Shares host kernel |
| Boot time | Seconds-minutes | Milliseconds |
| Overhead | High (full OS) | Low |
| Isolation strength | Strong (hardware) | Weaker (kernel) |
That last row explains the real security trade-off: a VM's isolation is enforced by the CPU's own hardware virtualization features, one layer below the OS entirely. A container's isolation is enforced by the same kernel every container on that host shares - strong enough for most workloads, but a kernel-level bug can in principle let one container see or affect another (or the host) in a way a proper VM boundary would prevent.
Tip: If an exam or interview asks "how do containers isolate processes without a hypervisor," the expected answer is exactly these two mechanisms working together: the seven Linux namespace types (PID, NET, MNT, UTS, IPC, USER, CGROUP) providing the illusion of isolation, and cgroups providing the actual resource limits underneath it.