本文已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已变得不准确。

Dockershim 弃用 FAQ

更新：本文有一个更新版本可用。

本文回顾了一些关于 Dockershim 弃用的常见问题，该弃用是作为 Kubernetes v1.20 版本的一部分宣布的。要了解更多关于将 Docker 作为 Kubernetes kubelet 容器运行时弃用以及这意味着什么的信息，请查看博客文章 不要惊慌：Kubernetes 和 Docker。

此外，你可以阅读检查 Dockershim 移除是否会影响你，以查看它是否会影响你。

为何要弃用 dockershim？

维护 dockershim 已成为 Kubernetes 维护者沉重的负担。创建 CRI 标准就是为了减轻这一负担，并允许不同容器运行时之间的平滑互操作。Docker 本身目前并未实现 CRI，因此存在这个问题。

Dockershim 始终被视为临时解决方案（因此得名：shim）。你可以在Dockershim 移除 Kubernetes 增强提案中阅读更多关于社区讨论和计划的信息。

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

在 Kubernetes 1.20 中还能使用 Docker 吗？

是的，1.20 中唯一的变化是如果在启动时使用 Docker 作为运行时，kubelet 会打印一条警告日志。

dockershim 何时会被移除？

考虑到此变更的影响，我们采用了延长的弃用时间表。它不会在 Kubernetes 1.22 之前被移除，这意味着没有 dockershim 的最早版本将是 2021 年末的 1.23。更新：dockershim 的移除计划在 Kubernetes v1.24 进行，详见Dockershim 移除 Kubernetes 增强提案。我们将与供应商和其他生态系统团体密切合作，以确保平稳过渡，并根据情况变化进行评估。

从 Kubernetes 中移除 dockershim 后，我还能使用它吗？

更新：Mirantis 和 Docker 已承诺在 dockershim 从 Kubernetes 中移除后继续维护它。

我现有的 Docker 镜像还能工作吗？

是的，通过 docker build 生成的镜像将适用于所有 CRI 实现。你所有的现有镜像将完全一样地工作。

私有镜像呢？

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

Docker 和容器是同一回事吗？

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

目前有人在生产环境中使用其他运行时吗？

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）的标准规范。他们还维护着 runtime-spec 的实际实现，即 runc，它是 containerd 和 CRI-O 的底层默认运行时。CRI 在这些低层规范的基础上构建，提供了端到端管理容器的标准。

我应该使用哪种 CRI 实现？

这是一个复杂的问题，取决于许多因素。如果 Docker 对你来说运行良好，迁移到 containerd 应该是一个相对简单的替换，并且将拥有更好的性能和更少的开销。然而，我们鼓励你探索CNCF 全景图中的所有选项，以防其他选项更适合你的环境。

更换 CRI 实现时需要注意什么？

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

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

如果你使用 Kubernetes 资源请求/限制或基于文件的日志收集 DaemonSets，它们将继续以相同方式工作，但如果你自定义了 dockerd 配置，则需要尽可能地将其适配到新的容器运行时。

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

对于 containerd，你可以从他们的文档开始，了解迁移时有哪些配置选项可用。

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

如果我有更多问题怎么办？

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

你还可以查看这篇精彩的博客文章 等等，Docker 现在在 Kubernetes 中被弃用了？，其中对这些变更进行了更深入的技术讨论。

可以抱抱吗？

随时随地，只要你想！ 🤗🤗