kubernetes removing docker support - my compiled journey here !!

I have been reading many articles or blogs so this is what I have customised from my learning to help reader to get summary and fast idea on what is going on.

Kubernetes is deprecating Docker as a container runtime after v1.20. At v1.20, you will get a deprecation warning for Docker. When Docker runtime support is removed in a future release (currently planned for the 1.22 release in late 2021) of Kubernetes it will no longer be supported and you will need to switch to one of the other compliant container runtimes, like containerd or CRI-O.Just make sure that the runtime you choose supports the docker daemon configurations you currently use (e.g. logging).

What’s actually happening here is that Dockershim is being removed from Kubelet as early as v1.23 release, which removes support for Docker as a container runtime as a result.

Eventhough docker has a thing called containerd already but docker itself is not compliant with CRI, the Container Runtime Interface. As a result kubernetes had to use dockershim( Kubernetes only talks in CRI and talking to Docker requires a bridge service refer here — dockershim.) thing to convert calls between docker api and CRI.

From Docker architecture — kubernetes only needed containerd(area marked in red in figure)

Kubernetes only need containerd as cri runtime but Docker Network and Volume are not used in Kubernetes because kubernetes has its own implementation for those. Thats why CRI runtime — containerd/cri-o do this task already.

There are majorly two CRI runtimes

1. containerd — https://github.com/containerd/containerd/. ( more suitable if you are migrating from docker but we need to see logging is supported while moving from dockershim to containerd)
2. cri-o — https://github.com/cri-o/cri-o

But again two types of runtime :

CRI AND OCI

1. CRI RUNTIME

CRI is an API that Kubernetes provides to talk to a container runtime in order to create/delete containerised applications.

So what a CRI runtime does is the following

1. Get the gRPC request from kubelet
2. Create OCI json config following the spec

2. OCI RUNTIME

OCI runtimes are responsible for spawning a container using Linux kernel system calls such as cgroups and namespace. You might have heard about runc or gVisor

runC spawns containers after CRI executes the binary by calling Linux system calls. That indicates runC relies on the kernel that is running on your Linux machine.

It also implies that if you ever discover runC’s vulnerability that makes you take the root privilege of your host, a containerized application can also do so. A bad hacker could take your host machine’s root and boom! Things surely will get bad. This is one of the reasons why you should keep updating your Docker(or any other container runtimes) too, not just your containerized application

there are some other oci runtime may be faster then runc I have not explored much but those are podman and crun . podman can launch rootless container too as added security which docker has also introduced.

useful links: —

Dockershim Deprecation FAQ

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

kubernetes/kubernetes

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called “dockershim” which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.