更新：移除 Dockershim 的常见问题

本文是针对 2020 年末发布的弃用 Dockershim 的常见问题的博客更新。 本文包括 Kubernetes v1.24 版本的更新。

---

本文介绍了一些关于从 Kubernetes 中移除 dockershim 的常见问题。 该移除最初是作为 Kubernetes v1.20 版本的一部分宣布的。 Kubernetes 在 v1.24 版移除了 dockershim。

关于细节请参考博文 别慌: Kubernetes 和 Docker。

要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅： 检查弃用 Dockershim 对你的影响 这篇文章。

在 Kubernetes 1.24 发布之前的几个月和几天里，Kubernetes 贡献者努力试图让这个过渡顺利进行。

• 一篇详细说明承诺和后续操作的博文。
• 检查是否存在迁移到其他 容器运行时 的主要障碍。
• 添加 从 dockershim 迁移的指南。
• 创建了一个有关 dockershim 移除和使用 CRI 兼容运行时的列表。 该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。

为什么会从 Kubernetes 中移除 dockershim ？

Kubernetes 的早期版本仅适用于特定的容器运行时：Docker Engine。 后来，Kubernetes 增加了对使用其他容器运行时的支持。创建 CRI 标准是为了实现编排器（如 Kubernetes）和许多不同的容器运行时之间交互操作。 Docker Engine 没有实现（CRI）接口，因此 Kubernetes 项目创建了特殊代码来帮助过渡， 并使 dockershim 代码成为 Kubernetes 的一部分。

dockershim 代码一直是一个临时解决方案（因此得名：shim）。 你可以阅读 Kubernetes 移除 Dockershim 增强方案 以了解相关的社区讨论和计划。 事实上，维护 dockershim 已经成为 Kubernetes 维护者的沉重负担。

此外，在较新的 CRI 运行时中实现了与 dockershim 不兼容的功能，例如 cgroups v2 和用户命名空间。 从 Kubernetes 中移除 dockershim 允许在这些领域进行进一步的开发。

Docker 和容器一样吗？

Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用，但是 Linux 中的容器已经存在了很长时间，容器生态系统已经发展到比 Docker 广泛得多。 OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大，其中一些替代了 Docker 的某些方面，而另一些则增强了现有功能。

我现有的容器镜像是否仍然有效？

是的，从 docker build 生成的镜像将适用于所有 CRI 实现， 现有的所有镜像仍将完全相同。

私有镜像呢？

当然可以，所有 CRI 运行时都支持在 Kubernetes 中使用的相同的 pull secrets 配置，无论是通过 PodSpec 还是 ServiceAccount。

在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？

可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine， 在 kubelet 启动时会打印一个警告日志。 你将在 1.23 版本及以前版本看到此警告，dockershim 已在 Kubernetes 1.24 版本中移除 。

如果你运行的是 Kubernetes v1.24 或更高版本，请参阅 我仍然可以使用 Docker Engine 作为我的容器运行时吗？ （如果你使用任何支持 dockershim 的版本，可以随时切换离开；从版本 v1.24 开始，因为 Kubernetes 不再包含 dockershim，你必须切换）。

我应该用哪个 CRI 实现？

这是一个复杂的问题，依赖于许多因素。 如果你正在使用 Docker Engine，迁移到 containerd 应该是一个相对容易地转换，并将获得更好的性能和更少的开销。 然而，我们鼓励你探索 CNCF landscape 提供的所有选项，做出更适合你的选择。

我还可以使用 Docker Engine 作为我的容器运行时吗？

首先，如果你在自己的电脑上使用 Docker 用来做开发或测试容器：它将与之前没有任何变化。 无论你为 Kubernetes 集群使用什么容器运行时，你都可以在本地使用 Docker。容器使这种交互成为可能。

Mirantis 和 Docker 已承诺 为 Docker Engine 维护一个替代适配器， 并在 dockershim 从 Kubernetes 移除后维护该适配器。 替代适配器名为 cri-dockerd。

你可以安装 cri-dockerd 并使用它将 kubelet 连接到 Docker Engine。 阅读将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd 以了解更多信息。

现在是否有在生产系统中使用其他运行时的例子？

Kubernetes 所有项目在所有版本中出产的工件（Kubernetes 二进制文件）都经过了验证。

此外，kind 项目使用 containerd 已经有一段时间了，并且提高了其用例的稳定性。 Kind 和 containerd 每天都会被多次使用来验证对 Kubernetes 代码库的任何更改。 其他相关项目也遵循同样的模式，从而展示了其他容器运行时的稳定性和可用性。 例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 CRI-O 运行时。

至于其他示例和参考资料，你可以查看 containerd 和 CRI-O 的使用者列表， 这两个容器运行时是云原生基金会（CNCF）下的项目。

• containerd
• CRI-O

人们总在谈论 OCI，它是什么？

OCI 是 Open Container Initiative 的缩写， 它标准化了容器工具和底层实现之间的大量接口。 它们维护了打包容器镜像（OCI image）和运行时（OCI runtime）的标准规范。 它们还以 runc 的形式维护了一个 runtime-spec 的真实实现， 这也是 containerd 和 CRI-O 依赖的默认运行时。 CRI 建立在这些底层规范之上，为管理容器提供端到端的标准。

当切换 CRI 实现时，应该注意什么？

虽然 Docker 和大多数 CRI（包括 containerd）之间的底层容器化代码是相同的， 但其周边部分却存在差异。迁移时要考虑如下常见事项：

• 日志配置
• 运行时的资源限制
• 调用 docker 或通过其控制套接字使用 Docker Engine 的节点配置脚本
• 需要 docker 命令或 Docker Engine 控制套接字的 kubectl 插件
• 需要直接访问 Docker Engine 的 Kubernetes 工具（例如：已弃用的 'kube-imagepuller' 工具）
• 配置 registry-mirrors 和不安全的镜像仓库等功能
• 保障 Docker Engine 可用、且运行在 Kubernetes 之外的脚本或守护进程（例如：监视或安全代理）
• GPU 或特殊硬件，以及它们如何与你的运行时和 Kubernetes 集成

如果你只是用了 Kubernetes 资源请求/限制或基于文件的日志收集 DaemonSet，它们将继续稳定工作， 但是如果你用了自定义了 dockerd 配置，则可能需要为新的容器运行时做一些适配工作。

另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 对于前者，可以用 crictl 工具作为临时替代方案 (参阅从 docker cli 到 crictl 的映射)。 对于后者，可以用新的容器创建选项，例如 img、 buildah、 kaniko 或 buildkit-cli-for-kubectl， 他们都不需要 Docker。

对于 containerd，你可查阅有关它的文档， 获取迁移时可用的配置选项。

有关如何在 Kubernetes 中使用 containerd 和 CRI-O 的说明， 请参阅 Kubernetes 相关文档。

我还有其他问题怎么办？

如果你使用了供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。 对于最终用户的问题，请把问题发到我们的最终用户社区的论坛。

你可以通过专用 GitHub 问题 讨论删除 dockershim 的决定。

你也可以看看这篇优秀的博客文章：等等，Docker 被 Kubernetes 弃用了? 对这些变化进行更深入的技术讨论。

是否有任何工具可以帮助我找到正在使用的 dockershim？

是的！ Docker Socket 检测器 (DDS) 是一个 kubectl 插件， 你可以安装它用于检查你的集群。 DDS 可以检测运行中的 Kubernetes 工作负载是否将 Docker Engine 套接字 (docker.sock) 作为卷挂载。 在 DDS 项目的 README 中查找更多详细信息和使用方法。

我可以加入吗？

当然，只要你愿意，随时随地欢迎。🤗🤗🤗

• ←上一页
下一页→