containerd is the container runtime that actually runs containers - the layer beneath the tools people interact with. Docker uses it internally, and Kubernetes uses it directly as the default runtime through the Container Runtime Interface (CRI). It pulls images, manages their storage, and supervises container lifecycles, while leaving higher-level concerns (build, orchestration) to other tools.

Where it sits in the stack

There's a clear division of labor. An orchestrator (Kubernetes) decides what to run and where; containerd executes it on a node; and the lowest level, runc, creates the actual Linux container using namespaces and cgroups. containerd is the middle manager: it handles image pull, snapshot storage, and the container lifecycle, then hands the run to runc.

Why it matters to know about

Kubernetes removed the "dockershim" in version 1.24, so clusters talk to containerd (or CRI-O) directly rather than through Docker. This worried teams unnecessarily - images built with Docker still run, because they follow the OCI standard that containerd implements. The practical effect is operational: on a node you debug containers with crictl (the CRI tool) rather than the docker CLI, and the runtime footprint is smaller.

# Inspect containers on a Kubernetes node (containerd runtime)
crictl ps                 # running containers
crictl images             # local images
crictl logs <container>   # logs for one container

containerd vs CRI-O vs Docker

Both containerd and CRI-O are lightweight CRI runtimes for Kubernetes; containerd is the more widely deployed default (used by most managed Kubernetes services), while CRI-O is Kubernetes-specific and favored in the OpenShift world. Docker is a full developer platform that builds images and includes containerd underneath; you build with Docker and run with containerd in production.

Where it fits

You rarely install or configure containerd directly - it comes with your Kubernetes nodes or Docker installation. It's worth understanding because it explains how Kubernetes runs containers without Docker, why Docker-built images still work, and which tool (crictl) to reach for when debugging a node. For most data engineers it's background knowledge rather than something to operate.