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