containerd is a container runtime that manages the complete container lifecycle on a host — image transfer and storage, container execution and supervision, and low-level storage and network attachments. It’s the default runtime behind most managed Kubernetes offerings, and behind Docker itself.

How it works

containerd runs as a daemon on each node and exposes a gRPC API that higher-level systems — Kubernetes’ kubelet, via the Container Runtime Interface (CRI), or the Docker Engine — use to pull images and start containers. It delegates actual process execution to a lower-level runtime (typically runc), keeping containerd focused on lifecycle management rather than the mechanics of namespaces and cgroups.

Core concepts

• Image — an immutable, layered filesystem bundle pulled from a registry.
• Snapshot — the copy-on-write filesystem containerd builds for a running container from an image’s layers.
• Task — a running instance of a container, backed by an OS-level process.
• Namespace (containerd’s own, distinct from Kubernetes namespaces) — isolates containers and resources belonging to different clients on the same host.

Why teams rely on containerd

• Minimal and focused. It does one job — container lifecycle management — well, rather than bundling a CLI, build tooling, and orchestration.
• CRI-native. It implements the Kubernetes Container Runtime Interface directly, so kubelet talks to it with no extra shim layer.
• Battle-tested. It’s the runtime under the hood of the large majority of production Kubernetes clusters.
• Graduated CNCF project. Governance and security practices are vetted by the same foundation that hosts Kubernetes itself.

Getting started

On most managed Kubernetes platforms, containerd is already the configured runtime — there’s nothing to install. Where you do need to configure it directly (a self-managed cluster, a bare-metal node, or local development with nerdctl), the guides below cover the common setups.