NO is the short answer. The Kubernetes are no longer supporting Dockershim as a way to start your container. Apparently, the industry group met and was settled few years ago to remove Dockershim layer from the orchestration engine to start and monitor containers. So, the orchestration providers had ample time to work out the technical details and implementation to remove Dockershim layer and use directly the underlying run-time to manage containers. Therefore, this more of an release announcement of implementation of what has been approved go forward standard.
What is the truth behind the noise?
This change primarily impacts operators and administrators for Kubernetes and doesn’t impact developer work flows. The images Docker builds are compliant with OCI (Open Container Initiative), are fully supported on containerd, and will continue to run great on Kubernetes.
What is the Kubernetes project deprecating?
In 2016, Docker, Google, IBM created the containerd project to transition from docker-shim (and Docker Engine as runtime) to lower level runtime such as containerd and CRI-O. This decision has led to Kubernetes to start implementing the removal of the Dockershim layer and use directly low-level runtime layer to improve performance and stability of orchestration.
What does this mean for Docker Developers?
There is no change for those who are writing Dockerfiles to create container images. There is no impact on how you build your container images.
What does this mean for Kubernetes Admins?
For Admins, you need to keep an eye on your Kubernete version. The Kubernetes are no longer supporting Dockershim as a way to start your container. Apparently, this was settled few years ago to remove Dockershim layer from the orchestration engine to start and monitor containers. So, the orchestration providers had ample time to work out the technical details and implementation to remove Dockershim layer and use directly the underlying run-time to manage containers.
Admins are no longer be able to use Docker CLI commands to troubleshoot. However, the Docker CLI is replaced by industry standard CLI which have commands very similar to what you are used to in Docker.
As a whole, this is a improvement in the containerization standards, implementation that will directly improve the performance and stability of the system.
References:
- Blogs and Articles
- https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/
- https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
- https://www.zdnet.com/article/kubernetes-dropping-docker-is-not-that-big-of-a-deal/
- https://www.openshift.com/blog/kubernetes-is-removing-docker-support-kubernetes-is-not-removing-docker-support
- https://kubernetes.io/blog/2020/12/02/dockershim-faq/
- Helpful Links
- https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/dockershim
- https://opencontainers.org
- https://cri-o.io
- https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
- https://github.com/opencontainers/runc
- https://www.cncf.io
- https://github.com/containerd/cri/blob/master/docs/registry.md
- https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/
- CRL Adapters