2.2 Container Runtime Architecture
A focused guide to Container Runtime Architecture, connecting core concepts with practical Docker and container operations.
Container runtime architecture describes the layered set of components beneath the Docker daemon that actually create and supervise isolated processes — containerd and runc — separating the high-level concerns of image and lifecycle management from the low-level mechanics of namespace and cgroup manipulation.
Why the Runtime Is Layered
Docker did not originally implement container creation as a single monolithic piece of software; over time, the lower-level functionality was extracted into standalone components, containerd and runc, which can be used independently of Docker itself, and which Docker now relies on internally.
docker info --format '{{.Driver}}'
ctr version
The ctr command interacts with containerd directly, beneath the level most users interact with through the Docker CLI.
containerd's Position in the Stack
containerd manages the container lifecycle at a level below the Docker daemon: pulling images, managing storage, and supervising running containers, while delegating the actual creation of isolated processes to runc.
docker CLI -> dockerd -> containerd -> runc -> Linux kernel (namespaces, cgroups)
runc and the OCI Specification
runc is a lightweight, standalone tool that creates a container according to the Open Container Initiative (OCI) runtime specification — a configuration format describing exactly what namespaces, cgroups, and filesystem mounts a container should have.
runc spec
This generates a default OCI runtime configuration file, the same kind of specification containerd generates and passes to runc when starting a container on Docker's behalf.
Why This Layering Matters
Because containerd and runc are independent, standards-based components, other systems — including Kubernetes — can use them directly without going through Docker at all, which is why a container image built with Docker can be run by an entirely different toolchain that also implements the OCI specification.
crictl ps
This command, used by Kubernetes' container runtime interface, inspects containers managed through containerd without involving the Docker daemon.
Why Understanding the Layers Helps Troubleshooting
When something fails specifically at the level of process isolation rather than image management, looking at containerd or runc logs directly, rather than only the Docker daemon's logs, can reveal problems that originate below the layer the Docker CLI normally exposes.