Kernel Isolation & Runtimes

Namespaces are a kernel feature that gives a process its own view of a global resource. Separate namespaces exist for process IDs, network stacks, mounts, hostname, IPC, users and cgroups. A container is just a process placed in a fresh set of them.

image-spec defines the image format on disk and on the wire: layers, an image config, a manifest, and an index, all addressed by digest. distribution-spec defines the registry HTTP API used to push and pull those blobs. runtime-spec defines the unpacked bundle — a rootfs directory plus config.json — that a runtime such as runc executes.

The docker CLI is a thin HTTP client. It sends a request over the Unix socket /var/run/docker.sock to the long-running daemon dockerd, which does all the real work — pulling images, creating containers, managing networks — and streams results back. Containers are children of the daemon's stack, not of your shell.

A virtual machine virtualizes hardware: the hypervisor gives each guest its own kernel and virtual devices. A container virtualizes the operating system: processes share the host kernel and are isolated by kernel features. A container is a process, not a machine.

--cpus is a hard quota per scheduling period (cpu.max), --cpu-shares is a relative weight that only matters under contention (cpu.weight), and --cpuset-cpus pins the container to specific cores. A container that burns its quota early is throttled until the next period, so latency spikes while average utilization looks modest.

cgroups are the kernel feature that limits and accounts resources for a group of processes. The runtime creates a cgroup per container and writes the flags into its control files: on cgroup v2, memory.max becomes 536870912 and cpu.max becomes '150000 100000' (150 ms of CPU per 100 ms period).

PID 1 is special: default signal handlers are ignored, so it will not die from SIGTERM unless it handles it, and it inherits orphaned children and must reap them. An app that does neither ignores graceful shutdown and accumulates zombie processes.

An image is a graph of digest-named blobs. The manifest lists a config descriptor and ordered layer descriptors. The config JSON holds runtime defaults (Entrypoint, Cmd, Env, User), build history and rootfs.diff_ids. Each layer blob is a tar of filesystem changes. The image's own ID is the digest of its config.

dockerd takes the API request and handles images, networks and volumes, then asks containerd to run the container. containerd manages the snapshot and metadata and starts a containerd-shim per container. The shim invokes runc, which creates namespaces and cgroups and execs the entrypoint. runc then exits; the shim stays as the container's parent.

The shim is the container's real parent. It keeps the stdio/TTY open, waits on the process so the exit code is never lost, and holds the container alive independently of the daemon. Because the daemon is not in the process tree, containerd or dockerd can restart or upgrade while containers keep running, then re-attach through the shims.

A VM must emulate firmware, boot a kernel, probe devices and run an init system, and its guest kernel plus OS services permanently occupy RAM. A container skips all of that: the runtime sets up isolation and execs your process against the already-running host kernel.

137 means the process died from SIGKILL (128+9), which can be a cgroup OOM kill or an external kill such as a stop timeout. Confirm with docker inspect .State.OOMKilled, the kernel log line 'Memory cgroup out of memory', and the cgroup's memory.events oom_kill counter, then compare peak usage against memory.max.

In a container the kernel is the isolation boundary, so a kernel privilege-escalation bug means host compromise and every co-tenant container with it. In a VM the attacker owns only that guest and must also break the hypervisor. Shrink it by cutting syscall and capability reach.

crictl replaces it. The docker CLI talks to dockerd, which is not the runtime on such a node. crictl speaks the CRI gRPC API instead and is sandbox-aware: crictl pods lists pod sandboxes, crictl ps lists the containers inside them.

The container gets its own network namespace — a private stack with its own interfaces, routes, iptables rules and full port range. Docker creates a veth pair, puts one end inside as eth0 and attaches the other to the docker0 bridge, then NATs outbound traffic via the host.

The tag points at an OCI image index (manifest list) instead of a single manifest. The index lists one manifest per platform, each annotated with os and architecture. The client fetches the index, matches its own platform, then pulls only that manifest's config and layers.

It receives a filesystem bundle: a directory containing an already-unpacked rootfs and a config.json. config.json declares the process (argv, env, user, capabilities), the root filesystem path, mounts, and a Linux section listing namespaces, cgroup resource limits, seccomp, LSM labels and masked paths. The runtime just applies it.

v1 had a separate hierarchy per controller with inconsistent interfaces; v2 has one unified hierarchy, one consistent API (memory.max, cpu.max, io.max), pressure metrics, and coordinated memory-plus-I/O accounting so buffered writes are attributed correctly. Some v1-only options, such as disabling the OOM killer, no longer exist.

cri-dockerd is the out-of-tree adapter that implements the CRI services and forwards them to the Docker Engine API - dockershim's code as a standalone daemon. It costs an extra hop, another component to patch and version-match, and cgroup-driver alignment.

Namespace membership is per type, so containers can share some and not others: --network container:<name>, --pid container:<name>, --ipc container:<name>, or host for the host's own. From the host, nsenter -t <pid> -n -p -m joins a running container's namespaces via /proc/<pid>/ns/.

On its own, containerd handles image pull and storage, snapshots/rootfs preparation, container and task lifecycle via shims, and low-level networking hooks — exposed over a gRPC API on a Unix socket. CRI is a standard gRPC API (image and runtime services) that containerd implements as a plugin, so a node agent can drive it without Docker Engine.

They add a second isolation boundary under the container. Firecracker and Kata run each workload in a stripped-down VM with its own kernel and a tiny device model; gVisor keeps one host kernel but services most syscalls in a user-space kernel. Cost: some start-up, memory and feature loss.

Treat the two asymmetrically. Memory is a cliff: size it from observed peak plus headroom and cap the runtime below it so failures are diagnosable. CPU is a slope: quota only delays work, so set it above burst demand, size thread pools to it, and watch throttling counters instead of shaving it to average usage.

Decide from the threat model, not preference: untrusted code needs a boundary below the shared kernel, so micro-VMs are the default; plain containers only for trusted code; full VMs when you need coarse, long-lived, compliance-visible separation. Then add tenant-separated nodes, network egress control and hard resource caps.

Everything above the runtime is unchanged: same images, same registry, same manager, same config.json. What changes is how the container is isolated and executed — crun is a faster C reimplementation using the same kernel primitives, runsc intercepts syscalls in a user-space kernel, Kata boots a lightweight VM. Isolation strength and compatibility/performance trade off.

Containers are parented by per-container shim processes, not by the daemon, so they keep running when it hangs. Inspect them one layer down with ctr -n moby containers ls / tasks ls, or from the OS with ps --forest, nsenter into the namespaces and the cgroup tree. Fix or restart the daemon; with live-restore it re-attaches without stopping anything.