The new Kubernetes release v1.20 is deprecating its current underlying runtime docker. What does it mean for you? Could this impact your current workloads? Why this decision?
Docker is one of the most popular container runtimes. It has a huge open source developer community supporting this project. It was one of the reasons why Microservices and Containers are popular today which led to the birth of orchestration tools such as Kubernetes. So, why is Kubernetes deprecating it?
Kubernetes mainly depends on container runtime provided by docker to manage containers within the cluster. Docker is not an individual component. It is a stack of tools which has huge UX augmentations such as API, Volumes, Network & CLI etc. which eases the developer work. This tool stack is not required by kubernetes to run containers within the cluster.
“Dockershim” is used by kubelet to communicate with the runtime Containerd through docker. In order to do so Kubernetes had to manage all the other components which are basically not necessary and was leading to management of unwanted resources and absolute overhead due to errors & breakage. Docker as well is not CRI(Container Runtime Interface) complaint. So, what is the alternative and what about current workloads?
Ok, let’s start with the good news. You can still use docker as a development platform. Seems puzzled? Let me explain. The images which are developed using “docker build” can still be run in your cluster as long as the image that you provide is OCI(Open Container- Initiative) compliant. But how?
Containerd is the core component of Docker deamon which is the runtime of docker. From past few years docker was trying to make the containerd as a standalone component for this transistion as a goal (Docker Senior director of product management – Dieu Cao mentioned). Last year this project was officially graduated as an individual project by CNCF foundation which also manages Kubernetes(K8s) project. So, Docker is managing to build containers using its runtime Containerd which is also supported by kubernetes after this transistion.
All the major cloud providers such as AWS, Google & Azure has their own kubernetes managed services EKS, GKE & AKS accordingly. These providers are already using containerd as their runtime. If you are working with those providers then please contact their respective support team for updates on the worker node management.
Kubernetes will also further support container runtime “CRI-O” which is already used by openshift. If you have your own cluster and you are not using any cloud managed kubernetes services then you are free to choose between “containerd” and “CRI-O”.
So, end of the story. The docker environment that you are working for building containers is different from what is getting deprecated in the K8s v1.20. It’s called container runtime which is responsible for pulling and running the container images within the cluster. As long as your images are OCI compliant both the container runtimes containerd and CRI-O know how to manage them. All you have to do is change your current container runtime from docker to Containerd or CRI-O.
This migration is happening is v1.23 which would be in late 2021. In v1.20 all you get is a warning about this deprecation. So, Relax and Breathe. You have enough time to have coffee☕️🫖, play foos ball and do the migration.
For more information, Please read “Don’t panic: Kubernetes and Docker” post by Kubernetes developers.
Leave a Reply