If you're keeping an eye on the DevOps and developer forums you may have noticed a buzz around the news that Kubernetes v1.20 is warning about deprecated support for Docker.
On the surface this seems like quite confusing news given that Kubernetes was originally built on Docker.
The situation is a little more nuanced than it appears. Docker does a whole lot more than just build Open Container Initiative (OCI) compliant container images.
Kubernetes reads and understands OCI compliant images so you will still be able to build container images in Docker and Kubernetes will still run the containers within Kubernetes Clusters irrespective of how they are run and managed.
The root of the change is to reinforce that you don't need to install Docker which is a whole application stack that includes tools for container image building, an API, and a command line interface, none of which Kubernetes requires in order to run a container image.
Inside your Kubernetes cluster you need a container runtime that's responsible for pulling and running your container images. Docker is synonymous with the whole container concept and was instrumental in the widespread adoption of containerised infrastructure, so for many it has been the go-to runtime. However Docker was never designed to be embedded inside Kubernetes as it is an entire tech stack and not just the runtime component that Kubernetes requires.
However, without Docker you will need a lightweight container runtime like Containerd or CRI-O that is purpose built for running containers and is also free from complex container build components and bloated CLI interfaces.
The maintainers of Kubernetes have cited the desire to drop support for Dockershim as the reason for the change, preferring a separate process the kubelet can talk to via grpc, that in turn talks to the runtime.
Maintaining Dockershim has become a heavy burden on the Kubernetes maintainers. Since Docker doesn't implement the CRI standard developed to allow smooth interoperability between Kubernetes runtimes, the decision to deprecate Docker was taken.
Dockershim may be removed from Kubelet as early as V1.22 which will remove the ability to use Docker as your container runtime and will inevitably break things if you haven't moved to an alternative runtime like Containerd or Cri-o.
What does this mean for developers?
The Docker installation you are using in your development environment is not related to the runtime inside your Kubernetes cluster. Which means you can still enjoy all the benefits and familiarity of building Docker images the way you always have. This is because the images produced by Docker aren't Docker specific, but are OCI compliant. Any OCI compliant image looks the same to Kubernetes irrespective of the tool you used to build it and can still be deployed.
Docker images are referred to as containers, a bit like internet search is referred to a Googling or photocopying is referred to as Xeroxing, so maybe this move is intended to reinforce the fact that Kubernetes is independent of any single container image building technology as more and more cloud native platforms embrace Kubernetes and jostle for market share.
If you're an end user of Kubernetes, we doubt you'll notice any change, and if you're using Docker in your development pipeline there's no reason you can't or shouldn't continue to do so, as your Docker Build images can still run in your Kubernetes Clusters.
If you are using managed Kubernetes services like GKE, EKS or AKS you should make sure your worker nodes are using a supported container runtime prior to the impending removal of Docker runtime support.
Kubernetes v1.20 will start warning about Docker deprecation. The planned release of v1.22 in late 2021 will see the removal of the Docker runtime and you will need to switch to a supported runtime in order for your containers to be pulled and run by your Kubernetes cluster.
One thing to note, when selecting your replacement runtime, you'll need to ensure it supports any Docker Daemon configurations you are using (like logging for instance).
There's plenty of time to implement the necessary changes, so adjust your roadmaps, to-do lists or new year's resolutions to avoid any disasters.
One additional question to ask when building cloud infrastructure is: Are you monitoring everything?
