Kubernetes Removes Dockershim in Version 1.24
Deprecated in December 2020 and fully removed in the April 2022 release of Kubernetes 1.24, dockershim's removal ended direct Docker Engine support in kubelet — a roughly 16-month migration window the project deliberately built in.
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.
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.
Sources: Updated: Dockershim Removal FAQ — Kubernetes, Kubernetes Removals and Deprecations In 1.24 — Kubernetes, Dockershim Deprecation FAQ — Kubernetes