Kubernetes即将移除Dockershim：承诺和下一步

作者：Sergey Kanzhelev（谷歌）、Jim Angel（谷歌）、Davanum Srinivas（VMware）、Shannon Kularathna（谷歌）、Chris Short（AWS）、Dawn Chen（谷歌）

Kubernetes 将在即将发布的 v1.24 版本中移除 dockershim。我们很高兴能够通过支持开源容器运行时、支持更小的 kubelet 以及为使用 Kubernetes 的团队提高工程速度来重申我们的社区价值观。如果你使用 Docker Engine 作为 Kubernetes 集群的容器运行时^[1]，准备好迁移到 1.24！要检查你是否受到影响，请参考检查弃用 dockershim 是否影响你^[2]。

为什么我们要移除 dockershim

Docker 是 Kubernetes 使用的第一个容器运行时。这就是为什么 Docker 为许多 Kubernetes 用户和爱好者所熟知的原因之一。随着容器化成为行业标准，Kubernetes 项目增加了对额外运行时的支持。最终实现了容器运行时接口（CRI），让系统组件（如 kubelet）以标准化的方式与容器运行时通信。因此，对 Docker 的硬编码支持——这个项目称之为 dockershim 的组件——成为 Kubernetes 项目的一个异常。对 Docker 和 dockershim 的依赖已经渗透到 CNCF 生态系统中的各种工具和项目中，导致了脆弱的代码。

通过移除 dockershim CRI，我们拥抱了 CNCF 的第一价值观：“快比慢好^[3]”。请继续关注未来关于这个话题的交流！

弃用时间

我们在 2020 年 12 月正式宣布弃用 dockershim。目标是在 2022 年 4 月，Kubernetes 1.24 完全移除。这个时间线与我们的弃用策略一致，即弃用的特性必须在宣布弃用后至少运行 1 年。

我们将支持 Kubernetes 1.23 版本，其中包括 dockershim，在 Kubernetes 项目中再支持一年。托管 Kubernetes 供应商，供应商支持可能会持续更长时间，但这取决于公司本身。无论如何，我们相信所有集群操作都有时间进行迁移。如果你有更多关于 dockershim 移除的问题，请参考dockershim 弃用 FAQ^[4]。

在这个你是否为 dockershim 的迁移做好了准备^[5]的调查中，我们问你是否为 dockershim 的迁移做好了准备。我们收到了 600 多个回复。感谢所有花时间填写调查问卷的人。

结果表明，我们还有很多地方需要涵盖，以帮助你顺利迁移。其他容器运行时也存在，并且得到了广泛的推广。然而，许多用户告诉我们，他们仍然依赖 dockershim，有时需要重新处理依赖项。其中一些依赖关系超出了控制范围。根据从那里收到的反馈，我们采取了一些措施提供帮助。

我们的下一个步骤

根据提供的反馈：

• CNCF 和 1.24 发布团队承诺在 1.24 发布之前及时交付文档。这包括更多信息丰富的博客文章，如本文，更新现有的代码示例、教程和任务，并为集群操作人员生成迁移指南。
• 我们正在向 CNCF 社区的其他成员伸出援手，帮助他们为这一变化做好准备。

如果你是依赖 dockershim 的项目的一部分，或者如果你有兴趣帮助进行迁移工作，请加入我们！总是有更多贡献者的空间，无论是我们的迁移工具还是我们的文档。要开始，请在Kuberentes Slack^[6]上的#sig-node^[7]频道 say 个 hello！

总结

作为一个项目，我们已经看到集群操作人员在 2021 年之前越来越多地采用其他容器运行时。我们相信迁移没有重大障碍。我们正在采取的改善迁移体验的步骤将为你照亮更清楚的道路。

我们理解，从 dockershim 迁移是另一个你可能需要做的操作，以保持你的 Kubernetes 基础设施的最新。对你们中的大多数人来说，这一步将是直接和透明的。在某些情况下，你会遇到问题。社区已经详细讨论了推迟删除 dockershim 是否会有帮助。例如，我们最近在 11 月 11 日的 SIG Node 讨论和 12 月 6 日的 Kubernetes 指导委员会会议上谈到了它。去年我们已经推迟了一次，因为其他运行时的采用率低于我们的预期，这也给了我们更多的时间来识别潜在的阻塞问题。

在这一点上，我们相信你（和 Kubernetes）从移除 dockershim 中获得的价值可以弥补你的迁移工作。现在就开始计划，以避免意外。在 Kubernetes 1.24 发布之前，我们会有更多的更新和指南。

参考资料