What developers need to know about Docker, Docker Engine, and Kubernetes v1.20

The latest version of Kubernetes Kubernetes v1.20.0-rc.0 is now available. The Kubernetes project plans to deprecate Docker Engine support in the kubelet and support for dockershim will be removed in a future release, probably late next year. The net/net is support for your container images built with Docker tools is not being deprecated and will still work as before.

Even better news however, is that Mirantis and Docker have agreed to partner to maintain the shim code standalone outside Kubernetes, as a conformant CRI interface for Docker Engine. We will start with the great initial prototype from Dims, at https://github.com/dims/cri-dockerd and continuing to make it available as an open source project, at https://github.com/Mirantis/cri-dockerd. This means that you can continue to build Kubernetes based on Docker Engine as before, just switching from the built in dockershim to the external one. Docker and Mirantis will work together on making sure it continues to work as well as before and that it passes all the conformance tests and works just like the built in version did. Docker will continue to ship this shim in Docker Desktop as this gives a great developer experience, and Mirantis will be using this in Mirantis Kubernetes Engine. 

What does this mean for you if you use Docker and Kubernetes?

First of all, don’t panic 🙂 Developers can still use the Docker platform to build, share, and run containers on Kubernetes! This change primarily impacts operators and administrators for Kubernetes and doesn’t impact developer work flows. The images Docker builds are compliant with OCI (Open Container Initiative), are fully supported on containerd, and will continue to run great on Kubernetes.

If you’re using Docker, you’re already using containerd. We build Docker’s runtime upon containerd while providing a great developer experience around it. For production environments that benefit from a minimal container runtime, such as Kubernetes, and may have no need for Docker’s great developer experience, it’s reasonable to directly use lightweight runtimes like containerd.

Docker set up in 2015 the Open Container Initiative (OCI) in order to support fully interoperable container standards, and make sure that every container can run in any environment. This has been a huge success in promoting innovation while maintaining interoperability.

Docker created the containerd project, along with Google and IBM, in 2016, with the goal of this transition in mind. The deprecation of docker-shim (and Docker Engine as runtime) marks the completion of a long-term commitment to provide a modern runtime for Kubernetes. Containerd was created as a core low-level, extensible runtime for both Docker and Kubernetes to each use in the most appropriate way.

Containerd was donated to the CNCF in 2017, and has grown to incorporate the containerd CRI project to interface with Kubernetes, as well as seeing a host of innovation and investment from across the industry, including from Amazon, Google, Microsoft and IBM.

In 2019 it became a graduated CNCF project, the highest project level, showing its maturity and it remains the only container runtime with this status. Over the last few years the leading Kubernetes service providers such as AWS and Google have migrated to Containerd as their Kubernetes runtime. This process of depreciation now reflects the great success of this work, and of the thriving community around containerd.

Support for your container images built with Docker tools is not being deprecated.

Container images you build using Docker tools will continue to run on Kubernetes. Buildkit, our next generation build infrastructure, has a flexible architecture so that while it can be used as the builder with Docker, it can also talk directly to containerd or runc instead for use in infrastructure where Docker might not be available.

Docker is committed to containerd development: we will continue to further invest, along with the growing buildkit community, in helping you use Docker builds wherever and however your infrastructure is hosted.

You can continue to build and run Docker images locally and in your Kubernetes cluster as this deprecation will not impact that experience.

What is the Kubernetes project deprecating then?

Kubernetes is deprecating dockershim, which is a component in Kubernetes’ kubelet implementation, communicating with Docker Engine. Arnaud Porterie had some great thoughts on this that he shared here.

The Kubernetes project has also published this FAQ.  Kat Cosgrove did a great job explaining the changes very simply here.

What does this mean for Developers and Admins?

Today, and in Kubernetes v1.20, Kubernetes administrators can continue to use docker commands and kubectl commands to manage their Kubernetes clusters.

Kubernetes administrators will be able to use dockershim in future. Keep an eye on the Mirantis and Docker blogs for updated information about the future of dockershim and how to install the standalone shim..

In a future release of Kubernetes, a few minor releases from now, when support for the internal dockershim is eventually removed from Kubernetes’ kubelet, Kubernetes administrators will need to make some changes to ensure docker commands to inspect Kubernetes clusters will continue to work. Developers can continue to use Docker tools to docker build, docker push and docker run containers and container images on Kubernetes. 

Further Background

KEP-1985: Kubernetes Enhancement Proposal to remove dockershim from Kubelet

Questions? Feedback?

Please reach out on Docker’s slack if you have questions or other feedback.