Mirantis will support deprecated Kubernetes dockershim
It was only a few days ago in the forthcoming Kubernetes 1.20 release notes, Kubernetes, everyone's favorite container orchestrator, that Kubernetes developers announced: "Docker support in the kubelet is now deprecated and will be removed in a future release." Old-school Docker developers were not happy. But, at a closer look, dockershim removal from Kubernetes really wasn't that bad. But now Mirantis, which owns Docker Enterprise Platform, along with Docker, will continue to support dockershim as a Kubernetes-compatible Container Runtime Interface (CRI) for Docker Engine.
What does all that mean for programmers? Adam Parco, Mirantis's VP of engineering, explained: "For Mirantis customers, that means that Docker Engine's commercially supported version, Mirantis Container Runtime (MCR), will be CRI compliant."
But don't worry if you're not a Mirantis customer and you don't want to switch to a more modern CRI such as the runc-based containerd and CRI-O. Mirantis and Docker, starting with Davanum Srinivas's open-source cri-dockerd project, will continue to make it available as an open-source project, Mirantis cri-dockerd. This means that you can continue to build Kubernetes based on the Docker Engine just like always. You'll just need to switch from Kubernetes's built-in dockershim to the external one.
It should be as easy as one minor code change in your Docker-based containers on Kubernetes. Parco explained, "We will work together on making sure it continues to work as well as before and that it passes all the conformance tests and continues to work just like the built-in version did. Mirantis will be using this in Mirantis Kubernetes Engine, and Docker will continue to ship this shim in Docker Desktop."
The reason for all this fuss is that people still think Docker means containers and containers means Docker. It was never that simple.
Containers date back to at least the year 2000 and FreeBSD Jails. Oracle Solaris also has a similar concept, called Zones, while companies such as Parallels, Google, and Docker have been working in such open-source projects as OpenVZ and LXC (Linux Containers) to make containers work well and securely. Long before many of you'd ever heard of Docker or containers, you were using them every time you visited Google, with its lmctfy (Let Me Contain That For You).
Docker containers, which are built on top of LXC.
All containers have their own file system, storage, CPU, RAM, and so on. The key difference between containers and virtual machines (VM)s is, while the VM hypervisor abstracts an entire device, containers just abstract the operating system kernel.
What Docker did, and why many of you when you think Docker when you think container, is it made it easy to use containers. In fact, when Kubernetes was launched, Docker Engine was the first and originally the only supported runtime. "But," as Parco pointed out, "that was never the Kubernetes community's long-term plan."
In the long run, the Kubernetes community wanted to support many different containers. To make that possible, Kubernetes created CRI as a Kubernetes communication standard for container engines. All your container had to do was support CRI and it would work with Kubernetes. Indeed, the first CRI-compliant container engine, containerd, was based on Docker's own runc and donated as an open standard to the Cloud Native Computing Foundation (CNCF).
But -- and this is why years later, we're in this situation -- Docker itself was never CRI-compliant.
As Kubernetes developers explained in their "Don't Panic: Kubernetes and Docker" blog: "You see, the thing we call 'Docker' isn't actually one thing -- it's an entire tech stack, and one part of it is a thing called 'containerd.'" Kubernetes doesn't need Docker's human-friendly interface. Your Kubernetes cluster just needs containerd, and it must use another tool, dockershim, to get it. Kubernetes team hasn't been thrilled with that because "it gives us another thing that has to be maintained and can possibly break."
Docker developers, on the other hand, feared that getting rid of dockershim was throwing out the Docker baby with the shim bathwater. That wasn't true, but it got people really upset and worried. If you're one of those folks, Parco wants you to know that "for most people, the deprecation of dockershim is a non-issue, because even though they're not aware of it, they're not actually using Docker per se; they're using containerd."
But, if you are using dockershim, no problem. If you're a Mirantis customer, dockershim support will be wrapped up in the Mirantis Container Runtime, making it CRI-compliant. If you're not and you're using the open-source Docker Engine, the dockershim project will be available and you can continue to use it with Kubernetes. "It will just require a small configuration change, which we [Mirantis] will document," Parco said.
Some people, such as Tariq Islam, a Google Team Leader, may not be happy with dockershim's new lease on life. Islam sees Docker in Kubernetes as having moved from a "necessity to technical debt." That may be true, but it's a debt Mirantis and Docker are willing to keep paying to keep their programmers and users happy.