Kubernetes is dropping Docker support
TLDR> No, this is not the end of the world. Engineers running workloads on top of Kubernetes are unlikely to notice any difference. This is a sensible move towards standardisation and does not prevent engineers from using Docker to develop solutions.
On November 18th at 03:08 GMT Kubernetes quietly released version 1.20.0-beta.2. Within the release notes was a brief point warning that “Docker support in the kubelet is now deprecated and will be removed in a future release”, in essence, this means that Kubernetes has deprecated support for Docker as a container runtime. This single change has provoked widespread concern within the computing industry. However, much of the fear surrounding the removal of Docker support is unfounded. In this article, I am going to outline the change, why it is happening, and the impact it might have on WorldRemit.
First, let’s explain what is being changed: Kubernetes is removing support for a component used in the kubelet (the agent that runs on each node in the cluster, responsible for ensuring scheduled containers are running) called dockershim. The kubelet uses dockershim to talk to the Docker engine and schedule containers.
A “shim” is a component which maps API calls or fills in missing features which might be required by either party (API or consumer). The kubelet requires a container runtime conforms to the Container Runtime Interface (CRI), and the problem is; Docker does not conform to CRI (thus a shim is needed).
Removing support for dockershim is a sensible decision and one that has not been rushed. The Kubernetes project is trying to move towards producing a stable product based on components that conform to simple, well-designed APIs. Moving users to a CRI compliant container runtime is just one step in this journey.
So, when running a Kubernetes cluster what are your options for a CRI compliant container runtime? At the moment the two main contenders are containerd and CRI-O. Under the hood, both of these use the runc library that is also at the core of Docker. To confuse things even further, Docker actually created containerd in 2016 with this scenario in mind.
When understanding this change, it is important to remember that what we call Docker is not just one tool, but a whole product suite created by a company Docker Inc. Docker consists of the Docker Engine (runtime), Docker Client (CLI), Docker Registry, Docker Compose, Docker Desktop and many other smaller element. Kubernetes only utilises the Docker runtime, and within this dockershim only talks to a fraction of the APIs available (leading to lots of redundant functionality and increased bloat/attack surface).
However, Docker will still be useful to developers. Docker build creates containers that are OCI compliant, which can run on any compliant runtime (which containerd and CRI-O are). So although Kubernetes may not be using Docker to run containers, the likelihood is you will still be using Docker to develop and build containers.
Most users of Kubernetes are unlikely to notice any difference when changing container runtimes. Engineers will still be using Dockerfiles to specify their containers, Docker desktop and CLI to build and test locally, and the Docker docs.
Before the end of 2021, infrastructure teams will have some decisions to make. Currently, many managed Kubernetes solutions, are running versions around 1.18.9 with Docker 19.3.6. Infrastructure engineers will have to decide which runtime to use and switch. If you use Google Cloud, GKE defaults to containerd with Kubernetes version 1.19. For AWS users EKS native Linux OS “Bottlerocket” supports containerd and a whole host of other attractive features.
From a DevOps perspective, you might see some small changes to CI pipelines if DinD (Docker in Docker) is used to run workloads. DinD uses a connection to the Docker socket to work and this may be disrupted.
The bottom line is that Docker is not going away or dying. This move is good for Kubernetes and probably also good for Docker. Most engineers will still be using Docker every day to build and test containerised code.
