Docker Donates containerd to the Cloud Native Computing Foundation

containerd — the core container runtime functionality underneath Docker — was accepted by the CNCF’s Technical Oversight Committee as an incubating project on March 29, 2017, after Docker spun it out as a standalone open-source project in December 2016 with the explicit intention of donating it to a neutral foundation.

What containerd actually is

containerd handles image transfer and storage, container execution and supervision, low-level storage, and lifecycle operations. It delegates low-level execution to OCI runtimes such as runc; higher-level systems supply orchestration and commonly configure pod networking through their own layers. That boundary is important: containerd is not a complete developer platform or Kubernetes replacement.

Why Docker split it out at all

By 2016, Docker’s own platform had grown well beyond just running containers — orchestration, networking, image building, a CLI, and more were all bundled into one project. Extracting containerd isolated the specific, reusable runtime piece other tools and orchestrators could depend on directly, without needing all of Docker’s other components along with it.

The path to graduation

containerd reached general availability at version 1.0 in December 2017, and the CNCF announced its graduation — the foundation’s highest maturity tier — in February 2019, alongside Kubernetes and Prometheus among the small set of projects that had reached that status at the time.

Graduation did not mean the software was finished. It indicated evidence of adoption, governance, maintainers, security practices, and project maturity under the CNCF process at that time. containerd continued to evolve its plugin architecture, CRI integration, image handling, and release lines afterward.

How Kubernetes consumes containerd

Kubernetes does not ask containerd to behave like the Docker CLI. Kubelet communicates through the Container Runtime Interface, and containerd’s CRI plugin translates those operations into runtime tasks, images, snapshots, and sandboxes. The chain typically continues to an OCI runtime for the low-level container process. This layered design lets Kubernetes depend on stable interfaces while implementations evolve independently.

That distinction later became visible during dockershim removal. Kubernetes dropping its built-in Docker Engine adapter did not mean container images built with Docker stopped working: OCI-compatible images remained portable, and containerd continued to run them directly through CRI. The change removed an adapter, not the image ecosystem.

Neutral governance changed the dependency calculus

A foundational runtime is a sensitive dependency. Moving containerd to a vendor-neutral foundation reduced the perception that adopting it meant adopting every Docker product decision. It also gave cloud providers, Kubernetes distributors, runtime vendors, and end users a shared governance venue for issues that affected them all.

Neutrality alone does not guarantee compatibility or security. Operators still need supported release versions, verified artifacts, vulnerability response, runtime configuration, and upgrade testing. The donation mattered because it aligned governance with the runtime’s increasingly shared role, while the project’s later graduation supplied evidence that the community could sustain that role.

Why this mattered for the broader container ecosystem

Donating containerd to a neutral foundation, rather than keeping it as a Docker-controlled dependency, meant other projects — including Kubernetes itself, which eventually adopted containerd directly as a supported container runtime — could depend on it without being tied to Docker’s own product roadmap or governance. It’s a clear example of the same standards-and-neutrality dynamic behind the Open Container Initiative, applied to an actual runtime implementation rather than just a specification.

Related:

Sources: