2.2.1 Containerd Role

The containerd role is to manage the full lifecycle of containers and images at a layer below the Docker daemon, handling image transfer, storage, and container supervision, while delegating the actual low-level process isolation to runc.

containerd as a Standalone Container Runtime

containerd was extracted from Docker's internals and is maintained as an independent, graduated Cloud Native Computing Foundation project, usable on its own or as the runtime underneath higher-level tools like the Docker Engine or Kubernetes.

ctr namespaces list

containerd organizes containers into namespaces of its own (distinct from Linux kernel namespaces), which is how it keeps Docker-managed containers separate from containers managed by other systems using the same containerd instance.

Responsibilities containerd Handles

containerd manages pulling and storing image layers, creating the filesystem snapshot a container will use, and starting, stopping, and supervising the resulting container process via runc.

ctr images pull docker.io/library/nginx:latest
ctr run docker.io/library/nginx:latest myapp

These commands perform, at the containerd level, much of what docker pull and docker run accomplish at a higher level through the Docker daemon.

Plugin-Based Architecture

containerd is built around a plugin system, allowing different snapshot drivers (for managing image layers), different runtimes, and different network configurations to be used depending on the environment it is deployed in.

ctr plugins list

containerd's Relationship to the Docker Daemon

The Docker daemon (dockerd) uses containerd as a library and a separate running process, communicating with it over a local API, meaning many of the daemon's higher-level operations are, underneath, requests forwarded to containerd.

ps aux | grep containerd

This typically shows containerd running as its own process alongside dockerd, confirming the layered relationship rather than a single monolithic process handling everything.

Why containerd's Role Matters

Understanding that containerd exists as a distinct, reusable component explains why container runtimes across different platforms (Docker, Kubernetes, various CI systems) can interoperate at the image and runtime level — they are frequently built on the same underlying containerd foundation rather than each reimplementing container management independently.