Mirantis Commits to Providing Ongoing Support for Dockershim
Mirantis announced today it will update the Mirantis Container Runtime to include built-in support for the dockershim mechanism that will enable legacy Docker containers to run, even after version 1.23 of Kubernetes appears this fall.
The technical oversight committee (TOC) for Kubernetes announced last year it would deprecate dockershim later this year in favor of a container runtime interface (CRI) that enables multiple types of containers to run on Kubernetes. The dockershim mechanism was created to enable Docker Engine to be compatible with CRI.
The TOC has decided it no longer wants to devote resources to maintaining dockershim, which has since become a separate open source project being maintained by Mirantis and Docker, Inc. Mirantis, in 2019, acquired the enterprise assets of Docker, Inc., which included a container platform known as Docker Enterprise that made use of dockershim. Now known as Mirantis Kubernetes Engine, the company is committing to seamlessly maintain support for dockershim for organizations that are not yet ready to upgrade to a version of Kubernetes that employs a runtime, such as containrd, instead of Docker Engine.
Mirantis is committing to making that capability an integrated feature of Mirantis Container Runtime, rather than requiring IT teams to patch future versions of Kubernetes themselves to add support for dockershim.
There is also an ongoing development effort to move workflows out of dockershim directly into a cri-dockerd process, based on a wrapper that enables dockershim to run as a separate daemon that both reduces resource requirements and lowers overall maintenance. That capability will be integrated into Mirantis Container Runtime.
Adam Parco, vice president of engineering for Mirantis, says the effort to maintain support for dockershim is part of an ongoing commitment by a provider of a distribution of Kubernetes to shield end customers from the vagaries of open source projects, such as Kubernetes that, over time, will continue to evolve in ways that may not always be convenient.
The shift to CRI is required to drive future innovation within the larger container community. However, in this instance, there are a significant number of IT organizations running applications that might break if Docker Engine is replace by another container runtime.
It’s not clear how many organizations are actually impacted by the deprecation of dockershim. Any container image that complies with the Open Container Initiative (OCI) specification should continue to run, regardless of the underlying runtime. However, there will be configuration changes required to continue to employ dockershim. Most recently, the TOC released version 1.21 of Kubernetes. However, many organizations, by now, are running multiple versions of Kubernetes because they are concerned that upgrading from one release to another might break an application programming interface (API) that is no longer supported.
By now, most organizations are relying on a curated distribution of Kubernetes to minimize disruptions versus employing the code made available by the TOC – much the same way they consume Linux. The issue now becomes determining which of the hundreds of distributions of Kubernetes to employ.
