containerd
By the containerd project (CNCF)
containerd is an industry-standard container runtime that manages the complete container lifecycle on a host, including image transfer and storage, container execution, and low-level storage and network attachments. It is a graduated Cloud…
Definition
containerd is an industry-standard container runtime that manages the complete container lifecycle on a host, including image transfer and storage, container execution, and low-level storage and network attachments. It is a graduated Cloud Native Computing Foundation project and serves as the default runtime underneath both Docker and Kubernetes in most modern deployments. It is a graduated Cloud Native Computing Foundation project and serves as the default runtime underneath both Docker and Kubernetes in most modern deployments, exposing a gRPC API that higher-level tools like the Docker Engine and Kubernetes' kubelet call into rather than being used directly by end users.
Overview
containerd was extracted from Docker's internal architecture as Docker split its monolithic engine into more modular components, with containerd taking over the core responsibility of actually running containers while higher-level tools like the Docker CLI and API handled user-facing features such as build and networking configuration. This separation reflected a broader industry push toward standardized, interchangeable container runtime components rather than a single vendor's integrated stack. Mechanically, containerd handles pulling and unpacking container images, managing their storage on disk as content-addressable snapshots, and creating and supervising running containers using lower-level tools such as runc, which implements the actual OCI runtime specification for creating isolated processes with namespaces and cgroups. containerd exposes a gRPC API that higher-level tools consume, meaning end users rarely interact with containerd directly; instead, Docker, Kubernetes' CRI (Container Runtime Interface), and other orchestrators call into it programmatically. Among container runtimes, containerd differs from CRI-O in origin and scope: containerd began as a general-purpose runtime extracted from Docker and later added a CRI plugin for Kubernetes, while CRI-O was purpose-built for Kubernetes from the start with a narrower feature set. Kubernetes adopted containerd as one of its primary supported runtimes after deprecating direct Docker Engine support, communicating with it through the CRI plugin built into containerd itself. In practice, most modern Docker installations run containerd underneath the Docker Engine without the operator ever invoking it directly, and most managed and self-hosted Kubernetes clusters use containerd as their node-level runtime, configured once during cluster setup and then left alone. Its role is largely invisible to most developers, who interact with Docker or `kubectl` instead, but its position underneath both major container tools makes it one of the most widely deployed pieces of container infrastructure. Because containerd operates at a lower level than Docker's full toolset, it does not include Docker's build tooling, CLI, or Compose functionality; it is purely a runtime component meant to be consumed by other tools rather than used standalone by an end user. It is a Cloud Native Computing Foundation graduated project, reflecting its status as a shared, vendor-neutral piece of infrastructure rather than a Docker-specific tool. Operators troubleshooting container startup issues on a Kubernetes node will often find themselves inspecting containerd's own logs and state directly, even though their day-to-day interaction happens entirely through kubectl, since containerd is the layer actually responsible for pulling images and launching the underlying processes. This indirect visibility is typical of infrastructure components designed to be consumed by other tools rather than operated directly by end users.
Key Features
- Complete container lifecycle management: image pull, storage, execution
- gRPC API consumed by higher-level tools rather than end users directly
- Built-in Kubernetes CRI plugin for orchestrator integration
- Uses runc to implement the OCI runtime specification
- Default runtime underneath modern Docker Engine installations
- Cloud Native Computing Foundation graduated project
- Image and snapshot storage management on the host
- Widely deployed across managed and self-hosted Kubernetes clusters