A few days ago, Kubernetes developers announced that Kubernetes V1.20: would deprecate Docker as a runtime and be removed in a future release. Most of you who have been using Kubernetes would have already heard the news.
Docker is an entire tech stack, and one part of it is the “containerd,” which is a high-level container runtime by itself. The other components include Docker image, CLI, API and other UX enhancements that make it easy for us to interact—supporting all these features required an integration layer called dockershim that required additional efforts to maintain it. It was unnecessary because Kubernetes does not need all of that fancy UX stuff and other extra features. It just needs the container runtime.
Deprecating this feature will reduce the Kubernetes maintainers’ workload, and they can focus and move faster on the new container runtime-related enhancements.
Now Docker will be more of a development tool to create images which are OCI compliant. Any OCI-compliant image, regardless of the means you use to build it, will look the same to Kubernetes. Both containerd and CRI-O know how to pull those images and run them.
Suppose you are already using Docker as runtime and not using it in Docker (/var/run/docker.sock) within your cluster moving to Containerd. In that case, it should be relatively easy and have strictly better performance and less overhead. But if you are going to explore other CRI implementation for your environment, you must consider a few standard things like Logging, Resource Limitation, Kubectl Plugins etc. You can refer Kubernetes Dockershim Deprecation FAQ on what will work, what won’t, what you should be looking to do, and so on.
Mirantis has announced that dockershim support will be included with the Mirantis Container Runtime, making it CRI-compliant. Mirantis is also planning an open-source runtime called Mirantis CRI-Dockerd based on the ongoing CRI-Dockerd project. It means if you’re using the open-source Docker Engine, the dockershim project will be available as an open-source component, and you will be able to continue to use it with Kubernetes by doing a small configuration change.
Changing your container runtime

• Install your new container runtime.
• Add following parameters to KUBELET_ARGS
--container-runtime=remote – Use remote runtime with provided socket.
  --container-runtime-endpoint=unix:///run/containerd/containerd.sock
  (or unix:///var/run/crio/crio.sock if you’re using CRI-O).
• Drain the node to reschedule all the Kubernetes workloads to other nodes.
• Restart the kubelet service and Uncordon the node to allow Kubernetes Scheduler to schedule workloads back on the updated node.

For more detailed and specific steps, refer Running CRI-O on kubernetes cluster or the Kubernetes Container runtimes documentation.
Though changing the runtime might look like a simple process, updating an entire Kubernetes cluster can be more complicated as it requires some planning. Ashnik with years of experience and expertise on Kubernetes can help you with this migration without any hassle.