本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Dockershim 弃用常见问题解答

更新：此文章有新版本可用。

本文档回答了关于作为 Kubernetes v1.20 版本发布的一部分而宣布的 Dockershim 弃用的一些常见问题。有关将 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 增强提案。我们将与供应商和其他生态系统团体紧密合作，以确保平稳过渡，并将根据情况的变化进行评估。

Dockershim 从 Kubernetes 中移除后，我还能继续使用它吗？

更新：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 资源请求/限制或基于文件的日志收集 DaemonSet，它们将继续以相同的方式工作，但是如果您自定义了 dockerd 配置，则需要尽可能地将其适配到新的容器运行时。

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

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

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

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

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

您还可以查看这篇优秀的博客文章等等，Docker 在 Kubernetes 中被弃用了？现在我该怎么办？，其中对这些更改进行了更深入的技术讨论。

我能得到一个拥抱吗？

随时随地都可以！🤗🤗