containerd

containerd is an industry-standard container runtime built with an emphasis on simplicity, robustness, and portability. Running as a daemon on Linux and Windows, it handles the complete container lifecycle on its host system: image transfer and storage, container execution and supervision, and low-level storage and network attachments. It was designed from the start to be embedded into a larger system rather than used directly by end-users, which is why it powers Docker Engine and is the default container runtime for most managed Kubernetes distributions via its built-in CRI (Container Runtime Interface) plugin.

As a CNCF graduated project, containerd exposes a gRPC API and a Go client library (the client package) so higher-level systems can drive it programmatically, while also shipping CLI tooling (ctr) for direct debugging and operational use. Its plugin-based architecture lets operators swap in different snapshotters, runtimes, and content stores without touching the core, making it the shared foundation underneath much of the modern container ecosystem.

What You Get

• A daemon (containerd) that manages the full container lifecycle: image transfer, storage, execution, and supervision
• A built-in CRI plugin that lets Kubernetes use containerd directly as its node-level container runtime
• A Go client library (client package) with a typed, gRPC-backed API for containers, images, tasks, snapshots, and leases
• The ctr CLI for low-level, debugging-oriented interaction with a running containerd instance
• Pluggable snapshotters (overlayfs, btrfs, zfs, and more) and pluggable runtime shims (runc, Kata, gVisor, etc.)
• Checkpoint/restore support via CRIU for live container migration and state snapshotting

Common Use Cases

• Running containerd as the underlying container runtime for a Kubernetes node via CRI
• Embedding containerd as the execution engine inside a higher-level platform like Docker Engine
• Building custom container orchestration tooling against the Go client library instead of shelling out to a CLI
• Managing image distribution and OCI-compliant registries for internal container platforms
• Operating hybrid Windows/Linux container fleets from a single runtime

Under The Hood

Architecture containerd runs as a long-lived daemon (cmd/containerd) exposing a gRPC API consumed either directly or through the Go client package (client/client.go), which wraps namespaced service proxies for containers, images, content, snapshots, leases, events, and tasks (see core/containers, core/content, core/snapshots, core/events, each paired with a /proxy subpackage that turns local interfaces into gRPC clients). Actual container execution is delegated to per-runtime shim processes (cmd/containerd-shim-runc-v2) that speak a ttrpc protocol back to the daemon, isolating the core daemon from runtime crashes. Cross-cutting subsystems (CRI, GC, NRI, transfer, sandbox) are implemented as first-class plugins under plugins/, registered through github.com/containerd/plugin, so a change to one subsystem’s abstraction (e.g. the snapshotter or the content store interface) has a contained blast radius rather than rippling through the whole daemon.

Tech Stack The project is written in Go (targeting a recent Go toolchain per go.mod) and communicates over gRPC (google.golang.org/grpc) for its public API and ttrpc (github.com/containerd/ttrpc) for the lower-latency shim protocol. It depends on OCI specifications (opencontainers/image-spec, opencontainers/runtime-spec) for image and runtime compliance, runc as its default low-level runtime, CNI plugins for networking, and CRIU for checkpoint/restore. Build tooling is a hand-written Makefile family split by OS (Makefile.linux, Makefile.windows, Makefile.darwin), with protobuf/ttrpc code generation via dedicated protoc-gen-go-fieldpath tooling, and releases are published as prebuilt binaries alongside official container images.

Code Quality The repository carries an extensive test suite (hundreds of _test.go files across core/, client/, pkg/, and integration/), broad use of testify for assertions, and a typed error-handling convention centered on github.com/containerd/errdefs rather than ad hoc string matching. Linting is enforced via a detailed .golangci.yml, and CI runs a large GitHub Actions matrix (unit tests, CRI validation, node e2e, fuzzing via fuzz.yml, CodeQL scanning, and OpenSSF Scorecard checks), reflecting the project’s CNCF graduated maturity bar.

What Makes It Unique Unlike a typical library, containerd is a system-level daemon explicitly designed to be embedded rather than consumed directly by application developers — its API surface is a stable contract for platforms like Docker and Kubernetes to build on top of, not a convenience wrapper for end-user scripts. Its shim-per-runtime execution model and pluggable snapshotter/runtime architecture let operators substitute isolation technologies (runc, Kata Containers, gVisor) and storage backends without forking the daemon, a separation of concerns few container runtimes expose as cleanly.