6.1How Containers Work

Chapter 2.05 covered virtual machines. A container is an even lighter form of virtualization: multiple applications share one host kernel while each appears to run as its own isolated set of processes. No special hardware is involved—just isolation and limiting features built into the Linux kernel.

6.1.1Physical machines, VMs, and containers

• Physical machine = one OS on one piece of hardware. Resources are fully dedicated, but cost scales with the number of machines.
• Virtual machine = a hypervisor virtualizes hardware, and each guest runs its own kernel. Isolation is strong, but each guest OS adds overhead (boot time, memory, disk).
• Container = shares the host kernel and isolates at the process level. With no guest OS, startup takes well under a second and memory use is low, so a single host can run many containers. The trade-off: it cannot run a guest needing a different kernel (e.g., a different OS family).

6.1.2Kernel features behind isolation

• Namespaces partition what a process can see: PID (process ID space), net (networking), mnt (mount points), UTS (hostname), and more. A process inside a container sees only its own private world.
• cgroups (control groups) limit and account for resource usage—CPU, memory, and more—for a group of processes. They stop one container from starving the resources of another.
• The two play different roles: namespaces isolate what is visible, while cgroups limit how much can be used. A container is the lightweight isolation that results from combining both.

The relationship between the container filesystem and its image is another exam focus. An image stacks multiple read-only layers (each Dockerfile instruction, covered later, typically becomes one layer), and a union filesystem presents the stack as if it were a single filesystem. When a container starts, a thin writable layer (the container layer) is added on top of those read-only layers. Any file change or addition inside the container is recorded only in that writable layer; the underlying image layers are never modified. This design lets any number of containers start from the same image, each holding only its own diff, keeping disk usage and startup light. Also note: deleting a container normally discards that writable layer—i.e., the container-specific changes. From the namespace angle, running ps inside a container shows only that container's own processes, with PIDs numbered independently starting from 1 (the host sees different PIDs for the same processes). From the cgroups angle, capping a container's CPU or memory means a runaway container is far less likely to affect the host or other containers.

6.1.3Section summary

• Containers share the host kernel (VMs have independent kernels). Isolation comes from namespaces (visibility) + cgroups (resource limits)
• Images stack read-only layers; a container adds one writable layer and keeps only its own diff