本文已发布超过一年。较旧文章可能包含过时内容。请检查页面信息自发布以来是否发生变化。
Kubernetes 正式告别 Dockershim：承诺与后续步骤
Kubernetes 即将在 v1.24 版本中移除 dockershim。我们很高兴通过支持开源容器运行时、启用更小的 kubelet 以及提高使用 Kubernetes 团队的工程速度来重申我们的社区价值观。如果您在 Kubernetes 集群中使用 Docker Engine 作为容器运行时，请准备在 1.24 版本中进行迁移！要检查您是否受影响，请参阅检查 dockershim 移除是否影响您。
我们为何要移除 dockershim
Docker 是 Kubernetes 使用的第一个容器运行时。这是许多 Kubernetes 用户和爱好者如此熟悉 Docker 的原因之一。对 Docker 的支持被硬编码到 Kubernetes 中——项目将此组件称为 dockershim。随着容器化成为行业标准，Kubernetes 项目增加了对其他运行时的支持。这最终促成了容器运行时接口 (CRI) 的实现，它允许系统组件（如 kubelet）以标准化的方式与容器运行时通信。因此，dockershim 在 Kubernetes 项目中成为了一个异类。对 Docker 和 dockershim 的依赖已经渗透到 CNCF 生态系统的各种工具和项目中，导致代码脆弱。
通过移除 dockershim CRI，我们正在践行 CNCF 的第一个价值观：“快优于慢”。请关注未来关于此主题的进一步沟通！
弃用时间表
我们于 2020 年 12 月正式宣布了 dockershim 的弃用。完全移除的目标是 Kubernetes 1.24 版本，计划于 2022 年 4 月。这个时间表与我们的弃用策略一致，该策略规定弃用行为必须在其宣布弃用后至少一年内保持功能。
Kubernetes 项目将继续支持包含 dockershim 的 Kubernetes 1.23 版本一年。对于托管 Kubernetes 提供商，厂商支持可能会持续更长时间，但这取决于各公司本身。无论如何，我们相信所有集群运维都有时间进行迁移。如果您对移除 dockershim 有更多疑问，请查阅Dockershim 弃用常见问题。
我们在此次调查中询问您是否已准备好从 dockershim 迁移：您准备好移除 Dockershim 了吗。我们收到了 600 多份回复。感谢所有花时间填写调查问卷的人。
结果表明，我们仍然需要做很多工作来帮助您顺利迁移。其他容器运行时已经存在，并得到了广泛推广。然而，许多用户告诉我们他们仍然依赖 dockershim，并且有时存在需要返工的依赖关系。其中一些依赖关系不在您的控制范围内。根据您的反馈，以下是我们正在采取的一些帮助措施。
我们的下一步行动
根据您提供的反馈
- CNCF 和 1.24 发布团队致力于及时提供 1.24 版本所需的文档。这包括像本文这样提供更多信息的博文、更新现有的代码示例、教程和任务，以及为集群运维人员编写迁移指南。
- 我们正在联系 CNCF 社区的其他成员，帮助他们为这一变更做好准备。
如果您所在的某个项目依赖于 dockershim，或者您有兴趣帮助进行迁移工作，请加入我们！我们始终欢迎更多贡献者，无论是贡献于我们的过渡工具还是文档。要开始贡献，请在 Kubernetes Slack 的 #sig-node 频道打个招呼！
最后的想法
作为一个项目，我们已经看到集群运维人员在 2021 年越来越多地采用其他容器运行时。我们相信迁移没有重大阻碍。我们正在采取的改善迁移体验的步骤将为您更清晰地照亮前路。
我们理解从 dockershim 迁移是您可能需要进行的另一项操作，以保持您的 Kubernetes 基础设施最新。对大多数人来说，这一步将是直接和透明的。在某些情况下，您可能会遇到小问题或困难。社区已经详细讨论了推迟移除 dockershim 是否会有帮助。例如，我们最近在11 月 11 日的 SIG Node 讨论以及12 月 6 日的 Kubernetes 指导委员会会议中讨论过。我们已经在 2021 年推迟过一次，因为其他运行时的采用率低于我们预期，这也为我们提供了更多时间来识别潜在的阻碍性问题。
此时，我们认为移除 dockershim 给您（和 Kubernetes）带来的价值足以弥补您将付出的迁移努力。现在就开始规划，避免意外发生。在 Kubernetes 1.24 发布之前，我们将提供更多更新和指南。