Kubernetes deprecated docker!

Kubernetes is deprecating Docker as a container runtime after v1.20.

It’s as per the official communication made by Kubernetes.io.

Docker does not support Kubernetes Runtime API called CRI(Container Runtime Interface) and Kubernetes people have been using a bridge service called “dockershim”. It converts Docker API and CRI, but it will no longer be provided from Kubernetes side within a few minor releases.

If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster.

What does this change mean for developers

The Docker installation you’re using in development is unrelated to the Docker runtime inside your Kubernetes cluster.

As a developer, Docker is still useful to you in all the ways it was before this change was announced. The image that Docker produces isn’t really a Docker-specific image — it’s an OCI (Open Container Initiative) image.

Any OCI-compliant image, regardless of the tool you use to build it, will look the same to Kubernetes. Both containerd and CRI-O know how to pull those images and run them. This is why we have a standard for what containers should look like.

So, this change is coming. It’s going to cause issues for some, but it isn’t catastrophic, and generally it’s a good thing. Depending on how you interact with Kubernetes, this could mean nothing to you, or it could mean a bit of work. In the long run, it’s going to make things easier.

What about the K8S admins?

Docker is now deprecated in Kubernetes, so being a K8s admin, you should start thinking to adopt other CRI runtime such as containerd and CRI-O.

1. containerd is Docker compatible where the core components are the same.
2. CRI-O can be a strong option where you want more minimal functionality for Kubernetes.

I would like to help you understand this in some more detail ..

1. From Kubernetes v1.20, you will receive a deprecation warning for Docker. After that, you will need to use a different container runtime. Yes, this will break your clusters. You might think that Docker == Kubernetes. Not so!

2. The thing we call Docker is actually an entire tech stack, which includes a thing called containerd as well as some other stuff, like some fancy UX changes that make it easier for humans to interact with. Containerd is a high-level container runtime by itself.

3. Kubernetes doesn’t need all of that fancy UX stuff, though. It just needs the container runtime. Using Docker, the whole stack, as your container runtime means Kubernetes has to use something called dockershim to interact with the parts it actually needs.

4. This is because Docker isn’t CRI (Container Runtime Interface) compliant. Dockershim allows us to get around that, but it also means we have an entirely separate thing to maintain just so we can use Docker as our runtime.

5. This kind of sucks. It’s inconvenient. The solution is to cut out the abstraction and just use containerd as our container runtime in Kubernetes. Because, again, Kubernetes isn’t a human — it doesn’t need the UX enhancements.

6. So, you don’t need to panic. Docker isn’t dead (yet), and it still has its uses. You just can’t use it as your container runtime in Kubernetes anymore. After the next version, you need to switch to containerd.

7. Yes, you COULD just stay on an old version of Kubernetes. No, you absolutely should not, or else hackers will haunt your clusters.

So as Kubernetes.io mentions
You do not need to panic. It’s not as dramatic as it sounds.

How to check what runtime is currently being used in a cluster?

Here is the command -
It’s docker in my case.

root@kmaster-rj:~# kubectl get node -o wide
NAME          STATUS   ROLES    AGE    VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
kmaster-rj    Ready    master   123d   v1.18.8   172.42.42.200   <none>        Ubuntu 18.04.5 LTS   4.15.0-101-generic   docker://19.3.6
kworker-rj1   Ready    <none>   123d   v1.18.8   172.42.42.201   <none>        Ubuntu 18.04.4 LTS   4.15.0-101-generic   docker://19.3.6
kworker-rj2   Ready    <none>   123d   v1.18.8   172.42.42.202   <none>        Ubuntu 18.04.5 LTS   4.15.0-101-generic   docker://19.3.6

And btw before I finish writing here one more thing I need to point out here -

Docker != Containers
There are container images. Docker can build them. There are container registries. Docker can push and pull from them. There are container runtimes. Docker is one of them. There are container processes. Docker can create them but Linux is still the boss.

A container is a way of executing processes with isolation provided by 3 Linux technologies — chroot, namespaces, and cgroups.

chroot changes the file system root (/) that a process can see. This allows a process to use any directory as if it were a file system root instead of the actual file system root.

namespaces group resources together (like network and process IDs) so that only processes within a namespace can see the resources of that namespace.

cgroups set CPU and memory limits for processes.

Thank you!

Will keep you updated with more details on this development.

Ref — https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation
https://twitter.com/kelseyhightower/status/1334531052488904707
https://twitter.com/Dixie3Flatline/status/1334188913724850177
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m