Loadable modules, runtime tuning, and the namespace and cgroup primitives that turn one kernel into many isolated worlds.
5 topics
Everything above this chapter ran on top of the kernel without looking inside it. Here you open the box: how the kernel loads code at runtime through modules, how hundreds of tunable parameters change its behavior without a reboot, and how the same kernel isolates one set of processes from another.
Namespaces and cgroups are the two primitives every container runtime is built from. Once you have seen them directly, a container stops being magic and becomes a process tree with restricted views and capped resources. The chapter ends with eBPF, the in-kernel virtual machine that lets you observe and extend the kernel safely without writing a module.
What a container actually is
Namespaces
Isolate what a process can see — its own PIDs, mounts, network, and hostname. This is the visibility half of a container, and the kernel feature behind "it thinks it is alone."
cgroups
Limit what a process can use — CPU, memory, and I/O, accounted and capped. This is the resource half; without a memory limit one container can OOM the whole host.
Image
A stack of read-only layers plus a writable top layer, supplying the filesystem. A container is a process started from an image, constrained by namespaces and cgroups — not a lightweight VM.