更新：Dockershim 删除常见问题解答

本文取代了最初于 2020 年末发布的Dockershim 弃用常见问题解答文章。本文包含来自 Kubernetes v1.24 版本的更新。

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

要了解更多信息，请查看博客文章 不要恐慌：Kubernetes 和 Docker。

要确定删除 dockershim 对您或您的组织的影响，您可以阅读 检查 dockershim 删除是否会影响您。

在 Kubernetes 1.24 版本发布之前的几个月和几天里，Kubernetes 贡献者们努力工作，力求使过渡平稳。

为什么从 Kubernetes 中删除了 dockershim？

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

dockershim 代码始终被认为是临时解决方案（因此得名：shim）。您可以在Dockershim 删除 Kubernetes 增强提案中阅读更多关于社区讨论和规划的信息。事实上，维护 dockershim 已成为 Kubernetes 维护者的沉重负担。

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

Docker 和容器是同一回事吗？

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

我现有的容器镜像仍然可以工作吗？

是的，从 docker build 生成的镜像将与所有 CRI 实现一起使用。您所有现有的镜像仍然可以完全相同地工作。

私有镜像呢？

是的。所有 CRI 运行时都支持 Kubernetes 中使用的相同拉取密钥配置，无论是通过 PodSpec 还是 ServiceAccount。

我仍然可以在 Kubernetes 1.23 中使用 Docker Engine 吗？

是的，1.20 中唯一更改的是，如果使用 Docker Engine 作为运行时，则在 kubelet 启动时打印一条警告日志。您将在 1.23 之前的所有版本中看到此警告。 dockershim 的删除发生在 Kubernetes 1.24 中。

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

我应该使用哪个 CRI 实现？

这是一个复杂的问题，它取决于很多因素。如果 Docker Engine 对您有效，那么迁移到 containerd 应该是一个相对容易的替换，并且性能会更好，开销更少。但是，我们鼓励您浏览 CNCF landscape 中的所有选项，以防其他选项更适合您的环境。

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

首先，如果您在自己的 PC 上使用 Docker 来开发或测试容器：一切都不会改变。无论您为 Kubernetes 集群使用什么容器运行时，您仍然可以在本地使用 Docker。容器使这种互操作性成为可能。

Mirantis 和 Docker 已承诺维护 Docker Engine 的替代适配器，并且即使在 Kubernetes 中删除树内 dockershim 后，也会维护该适配器。替代适配器名为 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)。

人们一直在引用 OCI，那是什么？

OCI 代表开放容器倡议，它标准化了容器工具和技术之间的许多接口。他们维护用于打包容器镜像的标准规范（OCI image-spec）和运行容器（OCI runtime-spec）。他们还以 runc 的形式维护运行时规范的实际实现，它是 containerd 和 CRI-O 的底层默认运行时。 CRI 基于这些低级规范构建，以提供用于管理容器的端到端标准。

更改 CRI 实现时，我应该注意什么？

虽然 Docker 和大多数 CRI（包括 containerd）之间的底层容器化代码是相同的，但在边缘上存在一些差异。迁移时需要考虑的一些常见事项是

  • 日志记录配置
  • 运行时资源限制
  • 调用 docker 或通过其控制套接字使用 Docker Engine 的节点配置脚本
  • 需要 docker CLI 或 Docker Engine 控制套接字的 kubectl 插件
  • 来自 Kubernetes 项目的需要直接访问 Docker Engine 的工具（例如：已弃用的 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 发行版，您可以向他们询问其产品的升级计划。对于最终用户的问题，请将其发布到我们的最终用户社区论坛：https://discuss.kubernetes.io/。

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

您还可以查看优秀的博客文章等等，Docker 在 Kubernetes 中已弃用？，对更改进行更深入的技术讨论。

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

是的！ Docker Socket (DDS) 检测器是一个 kubectl 插件，您可以安装该插件，然后使用它来检查您的集群。 DDS 可以检测活动 Kubernetes 工作负载是否将 Docker Engine 套接字 (docker.sock) 作为卷挂载。 在 DDS 项目的 自述文件中查找更多详细信息和使用模式。

我可以拥抱一下吗？

是的，我们仍然按照要求给予拥抱。 🤗🤗🤗