Reading — step 1 of 5
Read
~1 min readContainer Lifecycle
Putting It All Together
You now have every piece of a container runtime:
| Layer | Lesson |
|---|---|
| PID namespace | 1 |
| Mount namespace | 2 |
| Net namespace | 3 |
| Memory cgroup | 4 |
| CPU cgroup | 5 |
| PID cgroup | 6 |
| rootfs | 7 |
| Image layers | 8 |
| Copy-on-write | 9 |
| Container lifecycle | 10 |
| exec & attach | 11 |
What we glossed over:
- OCI spec: the standard container format Docker, Podman, CRI-O all comply with. Defines the runtime interface (config.json + rootfs).
- runc: the reference implementation of the OCI runtime spec. ~5000 lines of Go.
- containerd: a higher-level daemon that manages images, networking, and many runtimes. The thing Docker actually talks to.
- Image registries: how images are stored and shipped (Docker Hub, ECR, GCR). HTTP API + OCI image format.
- Capabilities: instead of root/non-root, Linux has fine-grained capabilities (CAP_NET_ADMIN, CAP_SYS_PTRACE...). Docker drops most by default.
- seccomp / AppArmor / SELinux: kernel sandboxing layers ON TOP of containers. Important for security; required by SOC2/PCI.
- rootless containers: running Docker without root. Uses user namespaces to map container UID 0 to a non-root user on the host. Greatly reduces attack surface.
You now understand what Docker, Podman, runc, containerd, Kubernetes (which uses CRI to talk to a runtime) actually do under the hood. Container "magic" is just clever combinations of namespaces, cgroups, and overlayfs.
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…