按照发布时间表，稍有延迟的 Kubernetes 1.24 版本预计将于 5 月 3 号正式发布；该版本包含了一个重大转变，即，对 dockershim 的内置支持将被彻底删除。如果你使用 Docker Engine 作为 Kubernetes 集群的容器运行时，则需要准备好在 1.24 中进行迁移。要检查你是否受到影响，可参阅检查 dockershim 弃用是否影响你。
![]()
官方早在 2020 年 12 月就正式宣布了将弃用 dockershim，并预计于 2022 年 4 月 Kubernetes 1.24 发布时正式移除。公告指出，维护 dockershim 已经成为 Kubernetes 维护者的沉重负担。
根据介绍，Docker 是 Kubernetes 使用的第一个容器运行时。但随着 Kubernetes 项目向自己的开放容器倡议（OCI）过渡，它需要一个权宜之计来实现与其他各种容器运行时的移植；这个权宜之计就是 dockershim。从本质上讲，dockershim 最初是作为一个临时解决方案（因此得名为：shim），允许流行的 Docker Engine 容器运行时在 Kubernetes 自己的容器运行时接口（CRI）内将 OCI 调用转换成 Docker 调用。
随着时间的推移，dockershim 在 Kubernetes 部署中变得根深蒂固，但却拖慢了部署速度，给维护者带来了负担；所以被淘汰已成必然。此外，与 dockershim 基本不兼容的功能（如 cgroups v2 和用户命名空间），也正在较新的 CRI 运行系统中实现；取消对 dockershim 的支持将允许在这些领域进一步发展。
“dockershim 成为了 Kubernetes 项目中的一个异常现象。对 Docker 和 dockershim 的依赖已经渗透到 CNCF 生态系统中的各种工具和项目中，导致代码脆弱。”
不使用 CRI-compliant runtime 来取代 dockershim 的开发者有可能破坏他们的集群，不会得到及时的安全补丁更新，同时也会错过新的功能。Kubernetes 团队在一月份发布的一篇博客中表示，目前已有越来越多的集群运营商切换到了其他的容器运行时。“我们相信迁移没有主要障碍。我们为改善迁移体验而采取的步骤将为你指明更清晰的路径......我们相信你（和 Kubernetes）从 dockershim 移除中获得的价值可以弥补你的迁移工作。”
开发人员仍然可以在本地使用 Docker 来开发或测试他们的容器，无论他们为 Kubernetes 集群使用哪个容器运行时。Docker-produced images 将继续在所有 CRI-compliant runtimes 集群中工作，但不会继续得到支持。
