“Docker support is being deprecated in Kubernetes. You need to pay attention to this and plan for it. THIS WILL BREAK YOUR CLUSTERS,” said CNCF Ambassador Ian Coldwater on Twitter.
This caused consternation among developers but it is admins who need to take note – Kubernetes will still run Docker containers.
Coldwater’s tweet was intended to attract attention, and it did. Docker containers are everywhere and embedded in modern application development and deployment. What is going on?
The problem is that “Docker” means different things in different contexts. The release notes for the forthcoming Kubernetes 1.20 state:
CRI stands for Container Runtime Interface, an API to the runtime that (among other things) starts and stops containers. Docker is a container runtime but it does not implement CRI, hence the need for the shim mentioned in the release notes. It is better to use alternative runtimes such as containerd or CRI-O. Docker itself uses containerd, wrapped with additional features useful in development but generally not required by Kubernetes.
“Developers can still use Docker to build images, no change there,” a Docker spokesperson told us. “This primarily impacts ops/admins using Docker Engine for runtime as Kubernetes will just use containerd to run them instead. They will need to transition to using containerd as the container runtime for their Kubernetes clusters. Docker Engine is containerd with some extra stuff like UX that developers don’t really need for Kubernetes anyway. This streamlining is good news as containerd now becomes a core for both Docker and for Kubernetes.”
Note also that Kubernetes 1.20 still supports Docker. A hasty FAQ on the subject says that “the only thing changing in 1.20 is a single warning log printed at kubelet startup if using Docker as the runtime.” The earliest release without dockershim “would be 1.23 in late 2021,” said the team.
That said, there are some issues with changing from Docker to a different runtime. The above FAQ has a list, including logging configuration, node provisioning scripts, Kubectl (command-line tool for Kubernetes) plugins that may require Docker, and integration with GPUs or other special hardware.
It is not mentioned in the FAQ, but there is also an issue with Windows containers. Up until Kubernetes 1.18, Docker was “the only supported container runtime for Windows,” as explained in this post. In 1.18, containerd support was added but is alpha quality, so not intended for production use. As of now, “Docker EE-basic 19.03+ is the recommended container runtime for all Windows Server versions. This works with the dockershim code included in the kubelet,” state the docs, though “ContainerD 1.4.0-beta.2+ can also be used as the container runtime for Windows Kubernetes nodes.” ContainerD Windows support has a “stable release target” for Kubernetes 1.20 or later. The message for those using Windows containers is not to be hasty about switching.
“Fascinating how this docker/docker-shim deprecation has created mass confusion,” said VMware’s Joe Beda, a co-founder of Kubernetes; while Coldwater reflected: “I’m sorry I caused panic this morning. I wanted to call attention to the deprecation of Docker support in advance so people could make a plan for it, because for some it will be a major breaking change that will take time to fix. It, uh, worked? But it also stressed people out.” ®