Dockershim 弃用常见问题解答

更新：本文的 较新版本可用。

本文档介绍了关于 Kubernetes v1.20 版本中宣布的 Dockershim 弃用的一些常见问题。有关 Docker 作为 Kubernetes kubelets 的容器运行时被弃用的更多详细信息，以及这意味着什么，请查看博客文章 不要惊慌：Kubernetes 和 Docker。

此外，您可以阅读 检查 Dockershim 删除是否会影响您 以确认是否会受到影响。

为什么要弃用 dockershim？

维护 dockershim 已成为 Kubernetes 维护人员的沉重负担。创建 CRI 标准是为了减轻这种负担并允许不同容器运行时的平滑互操作性。Docker 本身目前没有实现 CRI，因此产生了问题。

Dockershim 一直被认为是一个临时解决方案（因此得名：shim）。您可以在 Dockershim 删除 Kubernetes 增强提案 中阅读有关社区讨论和计划的更多信息。

此外，诸如 cgroups v2 和用户命名空间等与 dockershim 大多不兼容的功能正在这些较新的 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 已承诺在它从 Kubernetes 中删除后继续维护 dockershim。

我现有的 Docker 镜像仍然可以使用吗？

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

那么私有镜像呢？

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

Docker 和容器是一回事吗？

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

是否有人们今天在生产环境中使用其他运行时的例子？

每个 Kubernetes 项目生成的工件（Kubernetes 二进制文件）都会在每个版本中进行验证。

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

有关其他示例和参考，您可以查看 Cloud Native Computing Foundation (CNCF) 下的两个容器运行时 containerd 和 CRI-O 的采用者。

• containerd
• CRI-O

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

OCI 代表 开放容器倡议，它标准化了容器工具和技术之间的许多接口。它们维护用于打包容器镜像（OCI 镜像规范）和运行容器（OCI 运行时规范）的标准规范。它们还以 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，您可以从其 文档开始，以了解在迁移过程中有哪些配置选项可用。

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

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

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

您还可以查看出色的博客文章等等，Docker 现在在 Kubernetes 中已弃用？，其中更深入地讨论了技术更改。

我可以抱抱吗？

总是并且随时都可以！🤗🤗

• ←上一页
下一页→