Kubernetes 1.24 released in May 2022 and completed the deprecation process for dockershim that began in Kubernetes 1.20. The removal caused significant concern in the community, most of which turned out to be unwarranted.
What dockershim was
Dockershim was a compatibility layer in the Kubernetes kubelet that allowed Docker to be used as the container runtime. Docker predates the Container Runtime Interface (CRI) standardisation. dockershim translated between Kubernetes' CRI API and Docker's API. When CRI matured and containerd (the container runtime embedded in Docker) became directly CRI-compatible, the translation layer became unnecessary.
The panic that was not
The announcement of dockershim removal produced significant concern from teams that believed their containerised applications would stop running. The confusion was between the container runtime (what runs containers on the node) and the container image format (what the containers are built as). Docker images are OCI-compatible: they run on containerd, CRI-O, or any OCI-compliant runtime without modification. Applications did not need to be rebuilt.
What did require changes
The changes required for dockershim removal: updating the container runtime on Kubernetes nodes from Docker to containerd or CRI-O, and updating any tooling that relied on the Docker socket on nodes (monitoring agents, log collectors, some CI/CD integrations). For managed Kubernetes services (EKS, AKS, GKE), the migration was handled by the cloud provider. For self-managed clusters, it required a node upgrade process.
Containerd as the default
containerd, the container runtime now used by default in EKS, AKS, and GKE, is the same code that Docker uses internally. The practical effect of the migration was zero for application workloads. The operational effect was that node-level troubleshooting uses `crictl` instead of `docker` commands. The tooling change is a minor adjustment that most platform teams absorbed with minimal disruption.