Getting your Trinity Audio player ready...
On 2nd December 2020, Kubernetes published an article stating that Kubernetes is deprecating Docker as a container runtime… And this was not a big deal I thought as I usually read articles from the Kubernetes Blog, thought this is just a release update blog. But then I saw Ian Coldwater, the Kubernetes SIG Security co-chair tweeted something which panicked the DevOps realm, quite literally. I, then realized, that the blog post was written as a clarification of this tweet.
Ian Coldwater tweeted,
Docker support is being deprecated in Kubernetes. You need to pay attention to this and plan for it. THIS WILL BREAK YOUR CLUSTERS.
This caused a stir among the DevOps community to a humongous effect to an extent that she had to delete the previous tweet and tweet this.
So, what is it exactly? Is Docker dead or not?
No. Docker is not dead. You can still keep on working with Docker. It is not that big deal, it became. Though for a second, it confused me as well.
Actually, the Kubernetes maintainers explained that they are deprecating Docker as a container runtime after v1.20. What does this mean? Well, Docker has become synonymous with container runtime. If anyone talks about container images, container registry, or even container runtime, they simply think about Docker. Kubernetes wants to change that norm.
Docker was actually introduced before Kubernetes to popularize the Linux container pattern as a whole. This means Docker is not the only container runtime around, there are others like rkt, containerd, and lxd. If you don’t know, a container runtime is a software that executes containers and manages container images on a node. Docker is very popular and the most common container runtime used in production Kubernetes environments.
To summarize this, I came across an incredible tweet by Kelsey Hightower, Staff Developer Advocate, Google Cloud Platform at Google.
But… Was this important? What was the need?
Kubernetes v1.5 had introduced an internal plugin API named Container Runtime Interface (CRI) to provide easy access to different container runtimes. CRI enables Kubernetes to use any of the container runtimes without recompilation. This means Kubernetes could use any container runtime that implements CRI to manage pods, containers and container images.
Docker currently does not support Kubernetes’s CRI so Kubernetes maintainers had written an additional layer to support this which is known as Dockershim. But maintaining dockershim has become a heavy burden on the Kubernetes maintainers.
… your Kubernetes cluster has to use another tool called Dockershim to get at what it really needs, which is containerd. That’s not great, because it gives us another thing that has to be maintained and can possibly break.
They published this in another blog post about the deprecation of Dockershim. Hence, the Kubernetes maintainers are encouraging developers to migrate to container runtimes that are CRI-compliant.
The good news is that if you’re using a managed Kubernetes service like GKE, EKS, or AKS (which defaults to containerd) you will need to make sure your worker nodes are using a supported container runtime before Docker support is removed in a future version of Kubernetes, which is currently planned for v1.22 due in late 2021.
I hope you enjoyed reading this.