Mirantis to take over support of Kubernetes dockershim

Adam Parco - December 4, 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.

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)

The idea was that any vendor could create a product that automatically interfaces with Kubernetes, as long as it is compliant with these interfaces.

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.

banner-img
Python for Mere Mortals
Updated for Python 3, download free of charge.
Download Now
Moving to Cloud Native: How to Move Apps from Monolithic to Microservices

Enterprises face the challenge of consistently deploying and managing applications in production, at scale. Fortunately, there are more technologies and tools available today than ever before. However, transitioning from a traditional, monolithic architecture to a cloud native one comes with its own unique challenges. Below, you will find a list of the critical first steps you need to take when …

Moving to Cloud Native: How to Move Apps from Monolithic to Microservices
Mirantis Newsletter - January 2022

Every month, Mirantis sends out a newsletter chronicling top industry and company news. Below you’ll find links to blogs, tutorials, videos, and the latest updates to our enterprise, open source, and training offerings. If you don’t currently receive the newsletter, you can subscribe by clicking the button on the top right. Mirantis Brings Secure Registries to Any Kubernetes Distro Launched earlier this …

Mirantis Newsletter - January 2022
Cloud Native 5 Minutes at a Time: Creating, Observing, and Deleting Containers

One of the biggest challenges for implementing cloud native technologies is learning the fundamentals — especially when you need to fit your learning in a busy schedule. In this series, we’ll break down core cloud native concepts, challenges, and best practices into short, manageable exercises and explainers, so you can learn five minutes at a time. These lessons assume a basic …

Cloud Native 5 Minutes at a Time: Creating, Observing, and Deleting Containers
FREE EBOOK!
Service Mesh for Mere Mortals
A Guide to Istio and How to Use Service Mesh Platforms
DOWNLOAD
Technical training
Learn Kubernetes & OpenStack from Deployment Experts
Prep for certification!
View schedule
Mirantis Webstore
Purchase Kubernetes support
SHOP NOW