Containers

Why an app in a Docker container thinks it has the machine to itself

A container is an ordinary process wrapped in two Linux kernel features. Namespaces control what it can see: its own process IDs, files, network and hostname. Control groups (cgroups) cap what it can use: CPU, memory, disk.

Take a web server started with Docker. It sees only its own processes and its image's files (the packaged app and libraries). There's no second operating system: one shared kernel just draws walls around it.

Containers

Run `docker run` and your app becomes process number 1

Run `ps` inside a container and your app shows up as PID 1 (process ID 1), with a root folder holding only the image's files. On the host, that same process might be PID 4213 among hundreds of others.

Kubernetes, which runs fleets of containers, uses cgroups for its limits. Give a container a 512 MB memory limit and let it grow past that, and the kernel kills it; Kubernetes reports it as `OOMKilled`, exit code 137.

Containers

The kernel gives each app its own name lists and a spending cap

Docker starts the app with system calls like `clone()` and flags such as `CLONE_NEWPID`. Now when the app names a PID, mount or network card, the kernel looks it up only in the app's namespace, so nothing else exists for it.

Limits are files under `/sys/fs/cgroup`. Writing `50000 100000` to `cpu.max` lets the group run 50 ms of CPU per 100 ms window; going past `memory.max` makes the kernel reclaim memory, then kill a process in the group.

No guest OS boots, so a container starts in well under a second. The price: all containers share one kernel, so a kernel bug can break the walls, which a virtual machine's separate kernel guards against.