Why Kubernetes Dropped Dockershim and Adopted containerd: Impact, Workflow, and Migration Guide

Kubernetes 1.24 announced the deprecation of Dockershim and the shift to containerd as the default container runtime. The change follows the Container Runtime Interface (CRI) standard, which allows Kubernetes to use alternative runtimes such as containerd, CRI‑O, and CRI‑Dockerd.

Why did Kubernetes drop Dockershim? Docker originally lacked a CRI implementation, so Dockershim was introduced as a compatibility layer. As the container ecosystem standardized around CRI, Kubernetes removed the hard‑coded Docker dependency, making the runtime more modular, performant, and extensible.

What is containerd? containerd is an open‑source container runtime that originated as a Docker component. It manages the full container lifecycle, image pull/push, storage, and invokes runc for container execution. In Kubernetes, containerd handles pod lifecycle operations and offers better performance and scalability than Dockershim.

Relationship of underlying components

Docker Client ↔ Docker Daemon – the client sends commands to the daemon, which manages images, containers, networks, and volumes.

Docker images are read‑only templates; Docker containers are runnable instances created from those images.

CRI (Container Runtime Interface) – the standard Kubernetes interface that any compliant runtime (containerd, CRI‑O, etc.) can implement.

OCI (Open Container Initiative) – defines image and runtime specifications; runc is the reference OCI runtime.

Evolution of containerd in Kubernetes

Before Kubernetes 1.24, the control plane invoked Docker commands to create containers; Docker internally used containerd for low‑level operations. After 1.24, containerd is called directly via CRI, eliminating the Docker shim and shortening the call chain, which improves efficiency and stability.

containerd workflow in Kubernetes

Kubelet calls the CRI runtime service API to request pod creation.

CRI creates a pause sandbox container and places it in the pod’s cgroups and namespaces.

CRI configures the pod’s network namespace using CNI.

Kubelet pulls the required container images via the CRI image service; if the image is missing, CRI uses containerd to fetch it.

Kubelet instructs the CRI to create and start the application containers inside the pod.

CRI finalizes container placement in cgroups and namespaces and starts the containers.

After these steps, the pod and its containers are running.

Impact of deprecating Dockershim

OCI‑compliant images continue to work unchanged, and Docker‑based image builds remain valid. End‑users see little functional difference, but APIs tied to Dockershim are removed, so custom CRDs may need updates.

Operations teams must replace Docker CLI commands with containerd equivalents when managing nodes, and ensure the node runtime is switched before upgrading.

How users should respond

Follow the official Kubernetes migration guide: upgrade the cluster version, adjust pod specifications, replace Docker‑specific tooling, and re‑configure monitoring and logging. Test the new environment for stability and performance, and consult documentation or support if issues arise.

After migration, consider optimizations such as refined pod configurations, efficient CNI networking, and improved observability to leverage containerd’s benefits.

Conclusion and outlook

The shift from Dockershim to containerd signals a clear trend toward a more modular, cloud‑native container ecosystem. Kubernetes users should understand the impact, adopt the recommended migration path, and stay informed about future developments that will further integrate Kubernetes and containerd.

Reference documents:

https://kubernetes.io/zh-cn/blog/2022/02/17/dockershim-faq/

https://kubernetes.io/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/