本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 正在告别 Dockershim：承诺和后续步骤
Kubernetes 将在即将发布的 v1.24 版本中移除 dockershim。我们很高兴通过支持开源容器运行时、实现更小的 kubelet 以及提高使用 Kubernetes 团队的工程速度来重申我们的社区价值观。如果您使用 Docker Engine 作为 Kubernetes 集群的容器运行时，请准备在 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 项目中再支持 Kubernetes 1.23 版本一年，其中包括 dockershim。对于托管的 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 发布之前，我们将提供更多更新和指南。