The slightly delayed Kubernetes 1.24 release is expected to be released on May 3 according to the release schedule; it contains a major shift, namely, built-in support for dockershim will be removed completely. If you use Docker Engine as Kubernetes cluster container runtime, then you need to be ready to migrate in 1.24. To check if you are affected, see Check if dockershim deprecation affects you.
Officially, dockershim was officially announced as early as December 2020, and is expected to be deprecated in April 2022 Kubernetes 1.24 will be officially removed. The announcement noted that maintaining dockershim has become a heavy burden for Kubernetes maintainers.
According to introduction, Docker is the first container used by Kubernetes runtime. But as the Kubernetes project transitioned to its own Open Container Initiative (OCI), it needed a stopgap solution to enable porting to various other container runtimes; that stopgap was dockershim. essentially, dockershim started as an interim solution (hence the name: shim) that allowed the popular Docker Engine container runtime to convert OCI calls to Docker calls within Kubernetes’ own Container Runtime Interface (CRI).
Over time, dockershim became entrenched in Kubernetes deployments, but slowed down deployments and placed a burden on maintainers; so its elimination was inevitable. In addition, features that are largely incompatible with dockershim (such as cgroups v2 and user namespaces) are being implemented in the newer CRI runtime systems; removing support for dockershim will allow further development in these areas.
“dockershim has become an anomaly in the Kubernetes project. Reliance on Docker and dockershim has permeated various tools and projects in the CNCF ecosystem, leading to fragile code.”
Developers who do not use the CRI-compliant runtime instead of dockershim risk breaking their clusters, not getting timely security patch updates, and also missing out on new features. in a blog post published in January, the Kubernetes team stated, more and more cluster operators have already switched to other container runtimes. “We believe there are no major barriers to migration. The steps we are taking to improve the migration experience will show you a clearer path …… We believe the value you (and Kubernetes) gain from dockershim removal can make up for your migration efforts.”
Developers can still use Docker locally to develop or test their containers, regardless of which container runtimes they use for their Kubernetes clusters. docker-produced images will continue to work in all CRI-compliant runtimes clusters, but will not continue to be supported.