Containers Are Processes With the Kernel’s View Narrowed

A hardware virtual machine runs a whole operating system — its own kernel, its own device drivers, its own page tables under a hypervisor’s page tables. A container runs no kernel of its own. docker run nginx starts a process on the host, scheduled by the host’s The Scheduling Problem, with its memory managed by the host’s Why Virtual Memory?, making system calls to the host kernel (System Calls). Run ps aux on the host and you will see the nginx workers as plain processes with plain PIDs. Everything that makes it feel like a separate machine is the kernel *lying selectively* to that process about what exists.

The lies are implemented by three Linux mechanisms that predate Docker: namespaces (what the process can *see*), control groups (what the process can *use*) and a layered filesystem (what the process sees as /). A container runtime — runc, crun, containerd, Podman — is a program that assembles those three around a process. Docker is a client, a daemon and an image format on top.

This is Linux-first, and the lesson says so. macOS and Windows have no namespaces or cgroups of this shape; Docker Desktop on both runs a Linux virtual machine (Apple’s Virtualization framework or WSL 2 / Hyper-V) and your containers are Linux processes *inside that VM*. Windows also has native Windows containers using its own isolation primitives (server silos, Hyper-V isolation); they run Windows images and are a different technology with the same vocabulary. When you docker run on a laptop, you are almost always talking to a Linux kernel in a VM.

Each namespace type wraps one global kernel resource and gives the process a private copy of the *table*. clone() or unshare() with the right flags creates them; setns() joins an existing one, which is what docker exec and nsenter do. The kernel object is unchanged — the same scheduler, the same TCP stack — but its indexes are partitioned.

A namespace is not a security boundary by itself; it is a *visibility* boundary. A process in its own pid namespace cannot name a host process, so it cannot kill it — but a process with CAP_SYS_ADMIN and no seccomp filter can create new namespaces, mount filesystems and, through the shared kernel, reach almost anything. Isolation comes from stacking all of the namespaces *and* dropping capabilities *and* filtering syscalls; each mechanism closes one class of reach. A runtime that skips one (--pid=host, --net=host) has not made a slightly weaker container; it has removed that boundary entirely.

Namespaces do nothing to stop a container from consuming all of the host’s CPU and RAM. cgroups (v2 on any modern distribution) do: every process belongs to a node in a hierarchy under /sys/fs/cgroup, and each node carries limits. cpu.max sets a quota per period (200000 100000 = two cores’ worth); memory.max sets a hard byte limit; memory.high a soft one that throttles first; pids.max caps the number of processes; io.max caps disk bandwidth. docker run --cpus 2 --memory 512m writes exactly these files.

What happens at the memory limit is the thing to understand precisely. When the cgroup’s charged memory hits memory.max and reclaim cannot free enough (Memory Pressure, Swap and the OOM Killer), the kernel’s OOM killer runs scoped to that cgroup: it picks the largest process *inside the container* and sends it SIGKILL. The host is unaffected; the container’s main process exits with status 137; Docker reports OOMKilled: true; Kubernetes shows Reason: OOMKilled and restarts the pod. The line in dmesg names the cgroup. This is not the host running out of memory — it is the container hitting a ceiling you set, and the fix is a larger limit or a smaller working set, never “add RAM to the host”.

CPU limits behave differently: hitting cpu.max does not kill anything, it throttles — the scheduler stops running the cgroup’s threads until the next period. A service with a 1-core quota and 8 threads that all wake at once burns the quota in the first 12 ms of each 100 ms period and then sleeps for 88 ms, which shows up as p99 latency spikes with average CPU at 60%. cpu.stat’s nr_throttled and throttled_usec are the numbers to look at.

A container image is an ordered list of read-only layers — each a tarball of files added or changed by one Dockerfile step. At run time the runtime stacks them with overlayfs: the image layers are lowerdirs, a fresh empty directory is the upperdir, and the union is mounted as the container’s / inside its mount namespace. A read walks the stack top-down and returns the first match; a write to a file from a lower layer triggers copy-up — the whole file is copied into upperdir and modified there — which is the Copy-on-Write idea at file granularity. Deleting a lower-layer file creates a whiteout entry in the upper layer.

The consequences are practical. Fifty containers from one image share one copy of the image’s files in the page cache, which is where the density comes from. Anything written inside the container lives in upperdir and is deleted with the container — hence volumes for data that must survive. And the first write to a large file that lives in a lower layer pays for a full copy: appending one line to a 2 GB lower-layer file copies 2 GB. Databases and logs belong on volumes or bind mounts, which are ordinary directories mounted *over* the overlay and bypass it entirely.

Namespaces and cgroups narrow what a process sees and uses; they do not by themselves reduce what it may *ask the kernel to do*. Two more mechanisms do. Capabilities split root’s power into ~40 flags — CAP_NET_BIND_SERVICE to bind ports below 1024, CAP_SYS_ADMIN for mounting and much else, CAP_NET_RAW for raw sockets — and Docker starts containers with a small default set, dropping the dangerous ones. seccomp filters system calls by number and arguments: Docker’s default profile blocks around 40 syscalls (mount, reboot, kexec_load, ptrace variants…) so that even a root process in the container cannot reach the kernel surface that matters most for escapes. --privileged disables both and gives back a process that is root on the host with a different view of the filesystem — which is to say, not isolated.

Now the classic surprise: run top, nproc or free inside a 1-CPU, 512 MB container and they report the host’s 64 cores and 256 GB. Nothing in the namespace list above virtualises /proc/cpuinfo, /proc/meminfo or sysconf(_SC_NPROCESSORS_ONLN) — those describe the *kernel*, and there is one kernel. The container’s real limits are in /sys/fs/cgroup/cpu.max and memory.max, and only software that reads those (the JVM, Go, .NET, lxcfs for the rest) sizes itself correctly. A Node process that spawns os.cpus().length workers inside a 2-core cgroup starts 64 workers that share 2 cores’ worth of quota and throttle constantly.