Starting with v1.20, Kubernetes is dropping Docker as a containerruntime.
But don't panic. Not everything is as bad as it seems at first glance.
TL; DR. Kubernetes is ditching Docker in favor of Container Runtime Interface (CRI) runtimes designed specifically for Kubernetes. Docker images will continue to work as usual in all runtimes.
For Kubernetes end users, little will change. All of this does not mean that Docker will "die" or that it should / should not be used for development anymore. Docker will continue to be a great tool for building containers, and images built with it
docker build
will continue to run on the K8s cluster.
If you are using managed Kubernetes services like GKE or EKS, you should make sure your workers are using a supported version of the runtime and do so before Docker support is removed in a future release of K8s. If your nodes have specific configurations, you will most likely need to upgrade to meet the appropriate environment and runtime requirements. We recommend that you contact your service provider and discuss all testing and upgrade planning issues.
If you roll out the clusters yourself, you will also have to make the appropriate changes to avoid problems. When upgrading to v1.20, you will receive a Docker deprecation warning. Developers plan to completely abandon Docker in version 1.23, the release of which is scheduled for the end of 2021. With its release, you will have to switch to one of the compatible executable environments - for example, containerd or CRI-O. Just make sure the environment you choose supports the Docker daemon configurations you are using (for example, logging).
What is all this confusion about and why is everyone so worried?
In fact, we are talking about two completely different environments, and this creates confusion. Inside the Kubernetes cluster there is a so-called container runtime , which is responsible for loading and running container images. And Docker is quite popular as a tool for organizing this environment (containerd and CRI-O are also widely known). However, Docker was not designed to be embedded in Kubernetes, and this poses a number of problems.
"Docker" is not a separate tool, but a whole technology stack, and one of its components is called "containerd" (we wrote about it in more detail here - approx. Transl.)and acts as a high-level runtime for containers. Docker is popular and convenient due to the huge number of add-ons for users that greatly simplify the process of interacting with this tool during development. However, all these UX enhancements are not needed by Kubernetes, because he is not human.
Because of this user-friendly level of abstraction, the Kubernetes cluster is forced to use another tool, Dockershim, to “reach out” to what it really needs: containerd. And this is bad, since such an additional layer has to be serviced and it can also "break". In reality, it turns out the following: in Kubernetes v1.23, Dockershim will be removed from Kubelet - accordingly, Docker will lose support as a container runtime. The question arises: if containerd is already included in the Docker stack, why does Kubernetes need Dockershim?
The point is that Docker is not compatible with the Container Runtime Interface.(CRI). If it was compatible, we wouldn't need an extra layer and everything would be great. However, this is not the end of the world and not a reason for panic. Just replace the Docker runtime with one that is supported.
Please note that if you are using Docker's socket (
/var/run/docker.sock
) as part of a normal workflow, then after switching to another environment you will no longer be able to work with it. This pattern is often referred to as "Docker in Docker". There are many different tools to work around this problem, including kaniko , img, and buildah .
How will this change affect the developers? Will we still write Dockerfiles? Shall we build images using Docker?
This controversial change is about a completely different environment from the one most people use to interact with Docker. Installing Docker for development has nothing to do with the runtime inside the Kubernetes cluster. Yes, this is confusing, I know ...
Even after the innovation, Docker will remain the same useful tool for developers. Docker-generated images can work with more than just Docker. These are full OCI images. Any OCI-compliant image will look the same on Kubernetes regardless of the tool it was built with. containerd and CRI-O are great at fetching these images and running them. This is why the container standard was created.
So, changes are coming. Some people will, of course, run into certain problems. But there is nothing to regret or worry about, because progress is a cool thing. Depending on how you use Kubernetes, this can mean either complete inaction or a minimum of effort for you. In the long term, such an innovation will only make things easier.
If the upcoming changes are still confusing you, then you're fine. There are many moving parts in Kubernetes, and no one is 100% expert at it. Please feel free to ask any questions, regardless of experience level or difficulty! Our goal is to prepare everyone as much as possible for the upcoming changes. <3 We hope this post has answered most of your questions and dispelled all concerns and concerns!
Need more answers? Check out the Dockershim deprecation FAQ .
PS from translator
You can also find a detailed answer from Tim Hockin , one of the Kubernetes developers, in the discussion on this topic on Reddit .
Read also on our blog: