Credit: Dreamstime
The upcoming version 1.24 of Kubernetes, which is set for a delayed release on May 3, marks a significant departure for the popular open source container orchestration system, as built-in support for dockershim will be removed once and for all.
Docker was the first container runtime used by Kubernetes. But as the Kubernetes project transitioned toward its own Open Container Initiative (OCI), it needed a stopgap to enable portability with various other container runtimes. That stopgap was dockershim.
Essentially, dockershim was originally intended as a temporary solution to allow the popular Docker Engine container runtime to convert OCI calls to Docker calls inside Kubernetes’ own Container Runtime Interface (CRI). Over time dockershim became firmly entrenched across Kubernetes deployments but slowed down deployments and placed a burden on the maintainers. It had to go.
How to prepare for dockershim deprecation
The Kubernetes v1.24 release, now expected May 3, will require users who want to be on the latest version of the software to migrate away from dockershim to another runtime that’s compatible with Kubernetes’ own, or use dockershim’s external replacement developed by Mirantis, known as cri-dockerd.
While Kubernetes nodes will no longer default to the Docker runtime, many developers and administrators will have already switched to other CRI-compliant runtimes, such as containerd — which Docker itself donated to the CNCF in 2017 — and the native CRI-O. This typically involves ensuring that the kubelet agent that runs on each node in a cluster is configured to call either containerd or CRI-O sockets.
Various managed Kubernetes vendors have already moved on, such as Red Hat OpenShift, which adopted CRI-O in 2019.
Amazon’s Elastic Kubernetes Service (EKS), Microsoft’s Azure Kubernetes Service (AKS), and Google’s Kubernetes Engine (GKE) already default to containerd. Microsoft also adopted containerd for Azure Kubernetes Linux node pools created with Kubernetes version 1.19 or later.
Switch to a CRI-compliant runtime or bust
Developers who do not replace dockershim with a CRI-compliant runtime risk breaking their clusters and falling behind on security patches, while also missing out on new features.
“At this point, we believe that the value that you (and Kubernetes) gain from dockershim removal makes up for the migration effort you’ll have,” the Kubernetes maintainers wrote in a January blog post.
Developers can still use Docker locally to develop or test their containers, no matter which container runtime they use for Kubernetes clusters. Docker-produced images will continue to work in clusters with all CRI-compliant runtimes, but won’t continue to be supported.
