Don’t Panic: containerd

containerd is machinery beneath machinery. It manages a container lifecycle on one host, which is less theatrical than managing a cluster and much closer to the floorboards. It turns image material into a filesystem and a process, while cluster scheduling belongs elsewhere.

A platform that wanted containers once had to assemble image transfer, storage, filesystems, metadata, execution, and supervision itself. containerd puts those jobs behind services and a gRPC API. Kubernetes reaches it through CRI, the Container Runtime Interface between kubelet and a runtime implementation. Other platforms can call it directly. Neither route asks containerd where a workload should go. That committee meets somewhere else.

Keep one sequence: resolve, store, unpack, configure, create a task, run. Image manifests, configuration, and layers arrive as immutable blobs in the content store, where a digest identifies the bytes. They are not a root filesystem yet, regardless of the confident name image. A snapshotter applies the layers and prepares the writable filesystem.

Then comes the vocabulary trap. A container is stored metadata and configuration. A task is the live process created from it. A container can exist with no running process, which feels mildly impolite until it solves a diagnostic puzzle. If the record exists but the process does not, inspect task creation, the shim, and the runtime path instead of pulling the image again.

A runtime shim connects containerd to an OCI runtime such as runc. Plugins provide content, snapshots, runtimes, CRI, and gRPC services. Their health is not decorative. A failed plugin can remove a capability before an application gets a chance to complain.

Namespaces separate names and metadata for different consumers, while content may remain shared by digest. They are not security boundaries. A client can select a namespace, so authorization and host access controls still do the serious work.

Read the introduction for the architecture and limits. The slides make the request path visible. The cheatsheet holds object names, client choices, configuration anchors, and failure boundaries. Use the practice reference for a harmless lifecycle inspection, then the exercise to make the container and task distinction stick.