In this section, thought to clear some doubts around Docker getting dropped from Kubernetes and whats the way forward now? Couple of days back Kubernetes announced this in their blog.
Hence, what are the steps henceforth, We will try to understand in this blog. In this blog, we will try to understand below points
- Why this happened?
- Whats next?
- Any impact for managed and self-managed K8s.
As we already know, that K8s, support multiple runtimes where in one of them being Docker. Docker engine comes with three components. They are:
We have docker server, then we have API, which interacts with server. We also have command line interface, which we can execute against the docker. Now, docker server itself has couple of components like
- Container Runtime:- For starting and stopping containers, basically complete container management.
- Volumes:- For persisting data in docker.
- Network:- Network interface for docker containers.
Apart from that, we can also build images with docker container.
What K8s Needs?
The only part which K8s needs inside in order to run the containers inside the cluster is the container runtime. So, in a nutshell K8s doesn’t need CLI, API, Server, Volumes, Network, building images. Reason being, because K8s has its own features natively baked in to support above said requirements. K8s has following features:
It doesn’t have build images feature, because K8s doesn’t do that, it only run images. And, to K8s, to directly use and run this container runtime component, it needs to talk to docker. And for this interaction, DockerShim comes into picture. Dockershim, has been part of K8s code. And this dockershim, which talks to docker is actually what K8s is deprecating. As we discusses above in the features list, since K8s is already having these features baked in natively, hence keeping the same with dockershim will be a kind of overhead and extra code unnecessary. Hence, in a nutshell, they tried to make K8s more sleek and performant by offloading extra piece of code.
Container runtime, which docker uses is Containerd. From the definition of Containerd, “containerd is available as a daemon for Linux and Windows. It manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.” Historically, containerd has always been part of docker daemon process which docker extracted as separate component. This is done for a reason, because it needs to be deployed as container runtime in K8s cluster. Containerd, is one of the graduated projects of the cncf. as shown below in the picture.
Containerd is now 2nd most popular alternative to use docker as runtime after docker. And Containerd is already used by major cloud platforms in K8s cluster. Below, ecosystem explains the same.
What this change means?
- If you are already running K8s cluster, let’s say managed K8s cluster on any of the above shown cloud platforms, then there won’t be any change for you as cloud providers will take care of master node where in container runtime will get substituted.
- In case of self managed clusters like if you have installed K8s in your on premise system step by step using kube admin, then there are couple of steps you need to follow. In case, if you were using docker, then you can substitute the container runtime using Containerd or Cri-o. But for some reason, if you would like to use docker itself, then you need to install dockershim. Going forward Merantis, will be taking over dockershim and supporting the same. Hence, dockershim will be available as standalone component.
- For now, you will just see warning that docker support deprecated and basically, its deprecated since K8s version 1.20.
- Therefore, for developers, this change hardly means anything as they are barely going to notice this as this is not going to impact anything on their usual development activity.
- If you are running locally K8s cluster locally on your machine via Docker Desktop or Minikube, you are not going to be impacted as these tools will make the decision internally for container runtime.
- That also means that you can continue learning docker and its concepts, because for building images, you are going to need that and push the same in any registry.
- This also means, your CI/CD pipeline will still be relevant and there is no change required there.
- One thing to also note here that every docker image will be compatible with any container runtime, because all container runtime follows Open container Initiative aka OCI.
That said, no need to worry about docker getting dropped from kubernetes, you are still going to need docker. In case, if you guys are new to Docker, you guys can refer my course on udemy.
With this, I would like to wrap this session here, I hope you guys would have enjoyed this discussion. Wish you a very happy Christmas and Happy New Year in advance.