Mirantis to take over support of Kubernetes dockershim
- December 04, 2020
The rumors of dockershim's demise have been greatly exaggerated. If you follow the Kubernetes ecosystem, you may have been caught up in the consternation excitement over the announcement that starting with the soon-to-be-released Kubernetes 1.20, users will receive a warning that dockershim is being deprecated, and will be removed in a future release. For many people this has sparked a moment of panic, but take a deep breath, everything is going to be OK.
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 the Docker Engine API. For Mirantis customers, that means that Docker Engine's commercially supported version, Mirantis Container Runtime (MCR), will be CRI compliant. We will start with the great initial prototype from Dims at https://github.com/dims/cri-dockerd and continue to make it available as an open source project, https://github.com/Mirantis/cri-dockerd. This means that you can continue to build Kubernetes based on the Docker Engine as before, just switching from the built in dockershim to the external one. 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.
But that was never the Kubernetes community's long term plan.
Long term, the community wanted the ability to run many different types of containers (remember rkt?) and as such, created the Container Runtime Interface (CRI), a standard way for container engines to communicate with Kubernetes. If a container engine is CRI compliant, it can run in Kubernetes with no extra effort.
The first CRI-compliant container engine was containerd, which was derived from the guts of ... wait for it... Docker. You see, Docker is more than just a container runtime; it includes other pieces that are meant for human consumption, such as the user interface. So Docker pulled out the pieces that were actually relevant as containerd, and it became the first CRI-compliant runtime. It then donated containerd to the Cloud Native Computing Foundation (CNCF). The cri-containerd component is runtime agnostic and supports multiple Linux operations systems, as well as Windows.
However, that left one problem. Docker itself still wasn't CRI-compliant.
That doesn't mean that non-compliant components can't be used with Kubernetes; Kubernetes can do anything with the right components. It just means that non-compliant components need a "shim", which translates between the component and the relevant Kubernetes interface. For example, dockershim takes CRI commands and translates them into something Docker Engine understands, and vice versa. But with the drive to take third-party components like this out of the Kubernetes core, dockershim had to be removed.
As dramatic as this sounds, however, it's less of an issue than you think; the images you build with docker build are compliant with the underlying standard CRI uses, so they are still going to work with Kubernetes.
Some people, however, including many Mirantis customers, are running workloads that are dependent on dockershim in order to work seamlessly with Kubernetes.
Because it's still a necessary real-world component for many companies, Mirantis and Docker have agreed to continue supporting and developing dockershim, and to continue its status as a standalone open source component.
So what does this mean in actuality?
If you're using containerd directly, you don't have to worry about this at all; containerd will work with the CRI. If you're a Mirantis customer, you also won't have to worry about this; dockershim support will be included with the Mirantis Container Runtime, making it CRI-compliant.
Otherwise, if you're using the open source Docker Engine, the dockershim project will be available as an open source component, and you will be able to continue to use it with Kubernetes; it will just require a small configuration change, which we will document.
So even though this came as a shock to many people, nobody is being left out in the cold.
If you're looking for more information, the community has put out an FAQ and blog post giving more detailed information.
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 the Docker Engine API. For Mirantis customers, that means that Docker Engine's commercially supported version, Mirantis Container Runtime (MCR), will be CRI compliant. We will start with the great initial prototype from Dims at https://github.com/dims/cri-dockerd and continue to make it available as an open source project, https://github.com/Mirantis/cri-dockerd. This means that you can continue to build Kubernetes based on the Docker Engine as before, just switching from the built in dockershim to the external one. 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.
In the beginning...
If you work with Kubernetes, you know that it orchestrates containers. For many people, "container" means "Docker", but that's not strictly true. Docker revolutionized containers and brought them into common usage, and as such, the Docker Engine was the first (and originally the only) container runtime to be supported by Kubernetes.But that was never the Kubernetes community's long term plan.
Long term, the community wanted the ability to run many different types of containers (remember rkt?) and as such, created the Container Runtime Interface (CRI), a standard way for container engines to communicate with Kubernetes. If a container engine is CRI compliant, it can run in Kubernetes with no extra effort.
The first CRI-compliant container engine was containerd, which was derived from the guts of ... wait for it... Docker. You see, Docker is more than just a container runtime; it includes other pieces that are meant for human consumption, such as the user interface. So Docker pulled out the pieces that were actually relevant as containerd, and it became the first CRI-compliant runtime. It then donated containerd to the Cloud Native Computing Foundation (CNCF). The cri-containerd component is runtime agnostic and supports multiple Linux operations systems, as well as Windows.
However, that left one problem. Docker itself still wasn't CRI-compliant.
What is dockershim?
Just as Kubernetes started out with built-in support for Docker Engine, it also included built-in support for various storage volume solutions, network solutions, and even cloud providers. But maintaining these things on an ongoing basis became too cumbersome, so the community decided to strip all third party solutions out of the core, creating the relevant interfaces, such as:- Container Runtime Interface (CRI)
- Container Network Interface (CNI)
- Container Storage Interface (CSI)
That doesn't mean that non-compliant components can't be used with Kubernetes; Kubernetes can do anything with the right components. It just means that non-compliant components need a "shim", which translates between the component and the relevant Kubernetes interface. For example, dockershim takes CRI commands and translates them into something Docker Engine understands, and vice versa. But with the drive to take third-party components like this out of the Kubernetes core, dockershim had to be removed.
As dramatic as this sounds, however, it's less of an issue than you think; the images you build with docker build are compliant with the underlying standard CRI uses, so they are still going to work with Kubernetes.
What happens now that built in dockershim support is deprecated in Kubernetes?
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, which is CRI compliant. For those people nothing will change.Some people, however, including many Mirantis customers, are running workloads that are dependent on dockershim in order to work seamlessly with Kubernetes.
Because it's still a necessary real-world component for many companies, Mirantis and Docker have agreed to continue supporting and developing dockershim, and to continue its status as a standalone open source component.
So what does this mean in actuality?
If you're using containerd directly, you don't have to worry about this at all; containerd will work with the CRI. If you're a Mirantis customer, you also won't have to worry about this; dockershim support will be included with the Mirantis Container Runtime, making it CRI-compliant.
Otherwise, if you're using the open source Docker Engine, the dockershim project will be available as an open source component, and you will be able to continue to use it with Kubernetes; it will just require a small configuration change, which we will document.
So even though this came as a shock to many people, nobody is being left out in the cold.
If you're looking for more information, the community has put out an FAQ and blog post giving more detailed information.
