Kubernetes recently announced that it’s deprecating Docker as a container runtime after v1.20,in favor of runtimes that use the Container Runtime Interface(CRI) created for Kubernetes.
Why ?
Docker isn’t compliant with CRI, the Container Runtime Interface.It was not designed to be embedded inside Kubernetes, and that causes a problem and blocking the evolution of kubernetes.
However, this does not mean Docker’s death, and it does not mean that you should also abandon your favorite containerization tool. As a matter of fact, not a whole lot will be changing for you, as an end-user of Kubernetes; you will still be able to build your containers using docker and the images produced by running docker build will still run in your Kubernetes cluster. what changes is the use of Docker as an execution engine in your Kubernetes cluster.
A brief explanation
Inside of your Kubernetes cluster, there’s a thing called a container runtime that’s responsible for pulling and running your container images. Docker is a popular choice for that runtime (other common options include containerd and CRI-O).
The most important thing for Kubernetes is the container runtime, and Docker is incompatible with the Container Runtime Interface (CRI). This is why it always needed the dockershim layer. Kubernetes has to use another tool called Dockershim to get at what it really needs, which is containerd. Kubernetes is deprecating Docker is to actually drop the support for dokershim. The dockershim was basically the bridge between the Docker API and the Kubernetes CRI. Now that the dockershim support is no longer here, Containerd has come up as a technically better solution.
For more information see the explanations on the kubernetes blog.
Timeframe
Starting at v1.20, kubelet will give a deprecation warning for Docker. Docker runtime support is planned to be removed in Kubernetes v1.22 release (late 2021). This means that Kubernetes clusters will have to be configured to one of the other compliant container runtimes like containerd or CRI-O. By using CAST AI managed Kubernetes clusters, you won’t need to worry about any of this maintenance under the hood.
Remember that the image that Docker produces isn’t a Docker-specific image. It’s an OCI (Open Container Initiative) image. Both containerd and CRI-O know how to pull those images and run them. This means that none of your current development flows that include building Docker images for running on Kubernetes need to change.
One thing to note: If you rely on the underlying docker socket (/var/run/docker.sock) as part of a workflow within your cluster today, moving to a different runtime is going to break your ability to use it. This is often called Docker in Docker. Fortunately, there are lots of options out there for this specific use case, including kaniko, and buildah.
Next step
In a future article we will see how to deploy a kubernetes cluster with terraform using CRI-O as runtime instead of Docker
Conclusion
Long story short, no reason to worry here. Kubernetes will continue running with the current Docker containers. Dockershim is retiring, but Docker is not dead at all.
Resources :
Kubernetes Blog
Kubernetes Documentation CRI-O
Kubernetes GitHub the release note
