Read on Twitter
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 1/15
When the kubernetes project was started, it chose the Docker Engine as runtime (a logical choice, as at the time, the Docker Engine was about the "only" runtime) 2/15
However, the Docker Engine was not designed with orchestration in mind, and not designed to be used as runtime for Kubernetes; the Docker Engine has many features that make sense for local development (build, run) and running non-orchestrated containers, 3/15
but many of those are not of use when deploying on Kubernetes, and actually swapped out for different implementations (networking, logging, volumes) 4/15
The docker-shim was a bit of a "hack", to shoehorn the Docker Engine into a runtime for Kubernetes. When the CRI API specification emerged, there were proposals to implement this API in the Docker Engine.. 5/15
.. but (with the above issues in mind), doing so would be a disservice to the Kubernetes community. The Kubernetes community was looking for a runtime *designed* for Kubernetes, without all the features it didn't need. 6/15
Acknowledging this, Docker started the "containerd 1.0" project
Containerd 1.0 was a full re-bootstrap of containerd 0.x (which was the runtime component extracted from Docker Engine) in which we partnered up with IBM, Google and others to design a runtime from the ground up 7/15
Containerd 1.0 was a full re-bootstrap of containerd 0.x (which was the runtime component extracted from Docker Engine) in which we partnered up with IBM, Google and others to design a runtime from the ground up 7/15
.. reimplement the runtime with knowledge we gathered over the years, removing legacy (or irrelevant) code that the Docker Engine gathered, to create a modern, light-weight, and *modular* runtime with Kubernetes as a first-class consumer, 8/15
... but flexible enough to also act as a runtime for the Docker Engine; or any other product for that matter, as containerd is desinged to be used as a low level "component" in the stack (as boring, but stable as possible). 9/15
Starting with Docker 17.11, Docker Engine has used containerd 1.0 as a runtime, and with the integration of the CRI API (since containerd v1.1.0), containerd was now able to act as a standalone runtime for kubernetes out of the box. 10/15
While containerd was *able* to be used directly as a runtime for Kubernetes, many users still used the Docker Engine as an "intermediate" runtime through the docker-shim. 11/15
Meanwhile, many cloud providers started to use containerd as runtime for their Kubernetes offerings, proving it to be a stable runtime 12/15
Now, the time has come for both the Kubernetes community and Docker to be confident that containerd has matured enough to be used directly, removing the Docker Engine as the intermediate runtime. 13/15
While the docker-shim won't be gone immediately, if you're running Kubernetes, containerd is a great choice to use as runtime... 14/15
For (local) development, building your images, and for non-orchestrated containers, or if you're running a Swarm cluster, Docker Engine will still be there! 15/15
