更新：移除 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 添加了对其他容器运行时的支持。为了实现协调器（如 Kubernetes）和许多不同容器运行时之间的互操作性，创建 了 CRI 标准。Docker Engine 没有实现该接口 (CRI)，因此 Kubernetes 项目创建了特殊代码来帮助过渡，并将该 dockershim 代码作为 Kubernetes 本身的一部分。

dockershim 代码一直被设计为一个临时解决方案（因此得名 shim）。您可以在 Dockershim Removal Kubernetes Enhancement Proposal 中阅读更多关于社区讨论和规划的内容。事实上，维护 dockershim 已经成为 Kubernetes 维护者们沉重的负担。

此外，这些较新的 CRI 运行时正在实现与 dockershim 基本不兼容的功能，例如 cgroups v2 和 user namespace。从 Kubernetes 中移除 dockershim 可以促进在这些领域的进一步开发。

Docker 和容器是同一件事吗？

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

我现有的容器镜像还能用吗？

是的，通过 docker build 生成的镜像将适用于所有 CRI 实现。您所有现有的镜像仍将完全相同地工作。

私有镜像呢？

是的。所有 CRI 运行时都支持 Kubernetes 中使用的相同 pull secret 配置，无论是通过 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 生态系统 中的所有选项，以防其他选项更适合您的环境。

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

首先，如果您在自己的 PC 上使用 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）旗下的两个容器运行时。

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

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

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

尽管 Docker 和大多数 CRI（包括 containerd）底层的容器化代码是相同的，但在边缘部分仍有一些差异。迁移时需要考虑的一些常见事项是：

  • 日志配置
  • 运行时资源限制
  • 调用 docker 或通过 Docker Engine 控制套接字使用 Docker Engine 的节点配置脚本
  • 需要 docker CLI 或 Docker Engine 控制套接字的 kubectl 插件
  • 需要直接访问 Docker Engine 的 Kubernetes 项目工具（例如：已弃用的 kube-imagepuller 工具）
  • registry-mirrors 和不安全注册表等功能的配置
  • 其他期望 Docker Engine 可用并在 Kubernetes 外部运行的支持脚本或守护进程（例如，监控或安全代理）
  • GPU 或专用硬件及其与您的运行时和 Kubernetes 的集成方式

如果您使用 Kubernetes 的资源请求/限制或基于文件的日志收集 DaemonSet，它们将继续正常工作，但如果您自定义了 dockerd 配置，则需要尽可能将其适应新的容器运行时。

另一个需要注意的事项是，任何期望用于系统维护或在构建镜像时嵌套在容器内运行的东西将不再工作。对于前者，您可以使用 crictl 工具作为替代品（参见 docker cli 到 crictl 的映射），对于后者，您可以使用不需要 Docker 的较新容器构建选项，如 img、buildah、kaniko 或 buildkit-cli-for-kubectl。

对于 containerd，您可以从其 文档 开始，查看迁移过程中可用的配置选项。

有关如何在 Kubernetes 中使用 containerd 和 CRI-O 的说明，请参阅 Kubernetes 文档中关于 容器运行时 的部分。

如果我还有其他问题怎么办？

如果您使用供应商支持的 Kubernetes 发行版，可以向他们咨询产品的升级计划。对于终端用户问题，请将其发布到我们的终端用户社区论坛：https://discuss.kubernetes.io/。

您可以通过一个专门的 GitHub Issue 讨论移除 dockershim 的决定。

您还可以查看优秀的博文 等等，Docker 现在在 Kubernetes 中被弃用了？，其中对这些变化有更深入的技术讨论。

有没有什么工具可以帮助我查找正在使用 dockershim 的地方？

是的！Docker Socket 检测器 (DDS) 是一个 kubectl 插件，您可以安装并用于检查您的集群。DDS 可以检测活跃的 Kubernetes 工作负载是否将 Docker Engine 套接字（docker.sock）作为卷挂载。在 DDS 项目的 README 中查找更多详情和用法模式。

我可以抱抱吗？

是的，我们仍然会按请求提供拥抱。🤗🤗🤗