Dockershim：历史背景

自 Kubernetes v1.24 起，Dockershim 已被移除，这对项目而言是一个积极的进展。然而，无论是在社会层面还是软件开发中，理解一件事情的完整背景非常重要，因此这一移除值得更深入地审视。随着 Dockershim 在 Kubernetes v1.24 中的移除，社区出现了一些困惑（有时甚至恐慌）和不满，这很大程度上是由于缺乏关于此移除的背景信息。弃用并最终从 Kubernetes 中移除 Dockershim 的决定并非仓促或轻率做出。它已经酝酿了很长时间，以至于很多现有的用户比这个决定出现得更晚，当然也比最初导致需要 Dockershim 的那些选择出现得更晚。

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

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

容器运行时接口 (CRI) 被发布，以实现这种灵活性。引入 CRI 对项目和用户都有好处，但它也带来了一个问题：Docker Engine 作为容器运行时的使用早于 CRI，并且 Docker Engine 不兼容 CRI。为了解决这个问题，作为 kubelet 组件的一部分，引入了一个小的软件垫片 (Dockershim)，专门用于弥补 Docker Engine 和 CRI 之间的差距，允许集群运维人员在很大程度上不受影响地继续使用 Docker Engine 作为容器运行时。

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

我们在沟通方面做得不够好，不幸的是，弃用公告在社区内引发了一些恐慌。关于这对 Docker 公司意味着什么、Docker 构建的容器镜像是否还能运行以及 Docker Engine 到底是什么等困惑，导致了社交媒体上的激烈讨论。这是我们的错；我们当时应该更清楚地沟通发生了什么以及原因。为了解决这个问题，我们发布了一篇博客和配套的常见问题解答 (FAQ)，以缓解社区的担忧，并纠正一些关于 Docker 是什么以及容器如何在 Kubernetes 中工作概念上的误解。由于社区的关注，Docker 和 Mirantis 共同同意以 cri-dockerd 的形式继续支持 Dockershim 代码，从而允许你在需要时继续使用 Docker Engine 作为你的容器运行时。对于希望尝试其他运行时（如 containerd 或 cri-o）的用户，我们编写了迁移文档。

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

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

• ←上一篇
• 下一篇→