Background

Kubernetes project created the container runtime interface (CRI) to make the runtime layer pluggable. This means you can pick and choose the best runtimes for your needs. For example, some runtimes provide better isolation, whereas others provide better performance.

Kubernetes 1.24 finally removed support for Docker as a runtime as it was bloated and overkill for what Kubernetes needed. Since then, most new Kubernetes clusters ship with containerd as the default runtime.

Fortunately, containerd is a stripped-down version of Docker optimized for Kubernetes, and it fully supports applications containerized by Docker. In fact, Docker, containerd, and Kubernetes all work with images and containers that implement the Open Container Initiative (OCI) standards.

Containerd

containerd is a high-level container runtime, aka container manager. To put it simply, it’s a daemon that manages the complete container lifecycle on a single host: creates, starts, stops containers, pulls and stores images, configures mounts, networking, etc.

containerd is designed to be easily embeddable into larger systems.

Docker uses containerd under the hood to run containers. Kubernetes can use containerd via CRI to manage containers on a single node.

image

image

More details

image

Ref: https://stackoverflow.com/questions/46649592/dockerd-vs-docker-containerd-vs-docker-runc-vs-docker-containerd-ctr-vs-docker-c

image

image

The containerd architecture consists of the following components:

image

Ref: https://collabnix.com/containerd-vs-docker-whats-the-difference/

In Linux environments, container management tools like Docker are built on a more granular set of container tools: runc and containerd. image