How Containers Work
Not tiny VMs — just isolated processes wearing a costume.
A container feels like a lightweight virtual machine, but there's no second operating system inside. It's an ordinary Linux process that the kernel has walled off so it thinks it's alone.
AYour app + libs
BContainer image layers
CNamespaces (isolation)
Dcgroups (limits)
EShared host kernel
Legend — how to read this diagram
A–EComponentsthe parts involved, labelled in the diagram
1 2 3Walkthroughnumbered steps below run in order
The kernel features that make it work
- Namespaces. Give the process its own view of PIDs, network, mounts, and hostname.
- cgroups. Cap how much CPU, memory, and I/O it can use.
- Union filesystems. Stack read-only image layers with a thin writable layer on top.
- Capabilities. Drop privileges so a container can't touch the host it shouldn't.
Containers vs VMs
Shared kernel. Containers skip a guest OS, so they start in milliseconds and pack densely.
Weaker isolation. Sharing a kernel means a kernel exploit is a bigger deal than with a VM.
Immutable images. Ship the same layered image everywhere; the writable layer is disposable.
One-line mental model:
A container isn't a machine — it's a process the kernel has convinced it's the only one in the room.
No comments:
Post a Comment