Kubernetes Removes Dockershim in Version 1.24
Kubernetes 1.24 removed dockershim after a long deprecation, moving nodes to CRI-native runtimes without invalidating Docker-built OCI images.
Kubernetes formally deprecated dockershim — the compatibility shim letting kubelet talk to Docker Engine directly — in version 1.20 (December 2020), and completed its removal in version 1.24, released in April 2022.
Why dockershim existed in the first place
Kubernetes’ kubelet communicates with container runtimes through the Container Runtime Interface (CRI), a standard Kubernetes itself defined. Docker Engine predated CRI and never implemented it directly, so Kubernetes maintained dockershim as an internal adapter translating between CRI calls and Docker’s own API — extra maintenance burden for a runtime that wasn’t natively speaking Kubernetes’ own standard interface.
A deliberately long deprecation window
The 1.20 release added only a startup warning — no functional change — specifically to give the ecosystem time to migrate before anything broke. That roughly 16-month gap between the deprecation warning and actual removal reflected Kubernetes’ own stated policy that deprecated behaviors must remain functional for at least a year after being announced.
What replaced it
Runtimes implementing CRI natively — containerd and CRI-O chief among them — needed no shim at all, and became the standard, directly-supported path. For workflows still specifically wanting a Docker-compatible interface, Mirantis and Docker jointly committed to maintaining cri-dockerd, an externally-maintained adapter serving the same purpose dockershim had, just outside the core Kubernetes project.
The migration was a node-runtime operation, not an application rewrite. Teams needed to inventory runtime dependencies, validate registry credentials, logging, monitoring, security agents, cgroup configuration, and any automation that mounted Docker’s socket or parsed Docker-specific state. Managed Kubernetes providers published their own timelines and node-image procedures.
What did not change
Docker remained useful for building and testing images. Images conforming to OCI and registry standards could still be pulled and run by containerd or CRI-O. Pods, Deployments, Services, and most application manifests did not need a special conversion merely because the node runtime changed.
The most exposed workloads were those depending on Docker-specific implementation details rather than Kubernetes abstractions: agents reading /var/run/docker.sock, scripts invoking docker ps on nodes, or log collectors expecting Docker-specific formats and paths. The official FAQ explicitly encouraged testing those integrations, which is why a runtime inventory mattered more than searching application YAML for the word Docker.
The operational lesson from the removal
Deprecation warnings are migration budgets. The project announced dockershim’s future removal in 1.20, documented impact, and retained functionality until 1.24. Organizations that tracked deprecations could test new node pools, move representative workloads, observe them, and then rotate the fleet. Those that treated warnings as harmless accumulated a deadline-driven infrastructure change.
A safe runtime migration validates image pulls, pod networking, DNS, volumes, exec and logs, resource isolation, node metrics, security controls, upgrades, drains, and rollback to the prior node pool. It also confirms image architecture and digest identity. The technical removal was complete in core Kubernetes, but cluster owners remained responsible for proving every provider-specific integration around the runtime.
Why this mattered beyond a technical cleanup
This removal illustrates a recurring pattern in Kubernetes’ evolution: standardizing on its own defined interfaces (CRI, and similarly CNI for networking) and retiring special-cased support for whatever didn’t implement them, in favor of a smaller, more maintainable core. It’s the same underlying philosophy — open standards over vendor-specific integration — that motivated the Open Container Initiative in the first place, applied here to Kubernetes’ own runtime abstraction rather than image/runtime specs.
Related:
- The Open Container Initiative Launches, Standardizing Container Formats
- Container Runtime Internals: containerd, CRI-O, and the OCI Spec
Sources: