Dockershim：历史背景

自 Kubernetes v1.24 起，Dockershim 已被移除，这对项目来说是一个积极的举措。然而，理解任何事物（无论是社会上的还是软件开发中的）都需要背景，因此有必要进行更深入的审查。随着 Kubernetes v1.24 中 Dockershim 的移除，我们看到社区中出现了一些困惑（有时甚至达到恐慌的程度）和对这一决定的不满，这主要是由于缺乏对移除背景的了解。弃用并最终从 Kubernetes 中移除 Dockershim 的决定并非仓促或轻率地做出。事实上，这项工作已经进行了很长时间，以至于现在的许多用户比这个决定要新得多，当然也比最初导致 Dockershim 成为必要的选择要新得多。

那么，什么是 Dockershim，它为什么要被移除？

在 Kubernetes 的早期，我们只支持一种容器运行时。该运行时是 Docker Engine。当时，实际上没有太多其他选择，而 Docker 是用于处理容器的主要工具，因此这不是一个有争议的选择。最终，我们开始添加更多的容器运行时，例如 rkt 和 hypernetes，并且很明显，Kubernetes 用户希望选择最适合他们的运行时。因此，Kubernetes 需要一种方式，允许集群操作员灵活地使用他们选择的任何运行时。

容器运行时接口 (CRI) 的发布是为了允许这种灵活性。CRI 的引入对项目和用户都非常有利，但它确实引入了一个问题：Docker Engine 作为容器运行时的使用早于 CRI，并且 Docker Engine 与 CRI 不兼容。为了解决这个问题，引入了一个小的软件垫片（dockershim）作为 kubelet 组件的一部分，专门用于填补 Docker Engine 和 CRI 之间的差距，允许集群操作员在很大程度上不受干扰地继续使用 Docker Engine 作为其容器运行时。

然而，这个小的软件垫片从未打算成为一个永久的解决方案。多年来，它的存在给 kubelet 本身带来了许多不必要的复杂性。由于这个垫片，Docker 的某些集成实现不一致，从而增加了维护人员的负担，并且维护特定于供应商的代码不符合我们的开源理念。为了减少维护负担并朝着更加协作的社区发展以支持开放标准，引入了 KEP-2221，提议移除 dockershim。随着 Kubernetes v1.20 的发布，弃用正式生效。

我们在这方面的沟通做得不好，不幸的是，弃用公告导致社区内出现了一些恐慌。对于 Docker 作为一家公司意味着什么、Docker 构建的容器镜像是否仍将运行以及 Docker Engine 实际上是什么的困惑导致了社交媒体上的混乱。这是我们的错；我们当时应该更清楚地沟通正在发生的事情以及原因。为了解决这个问题，我们发布了一篇博客和随附的常见问题解答，以消除社区的担忧，并纠正一些关于 Docker 是什么以及容器如何在 Kubernetes 中工作的误解。由于社区的担忧，Docker 和 Mirantis 共同同意以cri-dockerd的形式继续支持 dockershim 代码，允许您在需要时继续使用 Docker Engine 作为容器运行时。为了让想要尝试其他运行时（如 containerd 或 cri-o）的用户感兴趣，我们编写了迁移文档。

后来，我们调查了社区，并且发现仍有许多用户存在疑问和担忧。作为回应，Kubernetes 维护人员和 CNCF 承诺通过扩展文档和其他程序来解决这些担忧。实际上，这篇博文是此计划的一部分。随着许多最终用户成功迁移到其他运行时，以及文档的改进，我们相信现在每个人都有一条通往迁移的铺平道路。

Docker 不会消失，无论是作为工具还是作为一家公司。它是云原生社区和 Kubernetes 项目历史的重要组成部分。没有他们，我们就不会走到今天这一步。也就是说，从 kubelet 中移除 dockershim 最终对社区、生态系统、项目和整个开源都有好处。这是一个让我们所有人团结起来支持开放标准的机会，我们很高兴在 Docker 和社区的帮助下做到这一点。

• ←上一篇
下一篇→