Container Runtime Interface (CRI): Kubernetes introduced the CRI to allow it to work with various container runtimes (like containerd, CRI-O) in a standardized way. This meant that Kubernetes components didn't need to be tightly coupled to a specific runtime.
Dockershim's Role: Before CRI became the standard, Kubernetes directly integrated with Docker. Dockershim was a component within kubelet that acted as an adapter, translating CRI calls into Docker-specific calls. It essentially made Docker appear to be CRI-compliant.
Why Deprecate? Maintaining Dockershim added complexity to the Kubernetes codebase. By deprecating it, Kubernetes moved towards a cleaner architecture where kubelet communicates directly with CRI-compliant runtimes like containerd (which is what Docker itself uses under the hood) and CRI-O. This simplified maintenance, improved stability, and encouraged broader adoption of the CRI standard.
*****
A) Dockershim wasn't about running Docker on non-Linux nodes. Kubernetes has other mechanisms for supporting Windows containers, but Dockershim itself was Linux-focused.
C) Dockershim didn't use the Docker CLI directly. It interacted with the Docker daemon through its API.
D) While security is always a concern, the primary reason for deprecation was not performance trade-offs related to security, but rather simplification and standardization.