Dockershim弃用常见问题解答

本文讨论了有关Kubernetes v1.20版本中宣布的Dockershim弃用的一些常见问题，具体资料请参考文末文档。

为什么不赞成使用Dockershim？

维护Dockershim已成为Kubernetes维护人员的沉重负担。创建CRI标准是为了减轻这种负担，并允许不同容器运行时之间的兼容性。目前Docker本身尚未实现CRI，因此问题比较多。

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

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

仍然可以在Kubernetes 1.20中使用Docker吗？

是的， 如果使用Docker作为运行时，则在1.20中唯一更改的是在kubelet启动时打印的单个警告日志。

Dockershim何时会被删除？

鉴于此更改的影响，我们延长了弃用时间表。它不会在Kubernetes 1.22之前被删除，这意味着在没有Dockershim的最早版本将在2021年末发布1.23。我们将与供应商和其他生态系统组织紧密合作，以确保平稳过渡，并将根据情况的发展情况进行评估。

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

是的，由docker build产生的镜像将与所有CRI实现一起使用。您现有的镜像仍将完全相同。

私有镜像仓库呢？

所有CRI运行时都可以通过PodSpec或ServiceAccount支持在Kubernetes中使用跟Docker一样密钥配置。

Docker和容器是一回事吗？

Docker普及了Linux容器模式，并在开发基础技术方面发挥了重要作用，但是Linux中的容器已经存在了很长时间。容器生态系统已经发展到不仅限于Docker。OCI和CRI之类的标准已帮助许多工具在我们的生态系统中发展壮大，其中一些取代了Docker，而另一些则增强了现有功能。

有没有在生产中使用其他运行时的示例？

每个版本都验证了所有Kubernetes项目产生的工件（Kubernetes二进制文件）。

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

对于其他示例和参考，您可以查看Cloud Native Computing Foundation（CNCF）下两个容器运行时容器化和cri-o的采用者。

• containerd
• CRI-O

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

OCI代表开放容器计划，该计划标准化了容器工具与技术之间的许多接口。它们用于包装容器镜像（OCI镜像规范）和运行时容器（OCI运行时规范）的标准规范。它们还以runc的形式维护运行时规范实际实现，这是containerd和CRI-O的基础默认运行时 。CRI建立在这些低级规范的基础上，以提供用于管理容器的端到端的标准。

我应该使用哪个CRI实现？

这是一个复杂的问题，它取决于许多因素。如果Docker为您工作，那么迁移到容器化应该是一个相对容易的交换，并且具有严格更好的性能和更少的开销。但是，我们鼓励您探索CNCF领域中的所有选项，以防其他选择更适合您的环境。

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

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

• 记录配置
• 运行时资源限制
• 调用docker或通过其控制套接字使用docker的节点配置脚本
• 需要Docker CLI或控制套接字的Kubectl插件
• 需要直接访问Docker的Kubernetes工具（例如kube-imagepuller）
• 配置功能，例如registry-mirrors和不安全的注册表
• 期望docker可用并且在Kubernetes之外运行的其他支持脚本或守护程序（例如，监控或安全代理）
• GPU或特殊硬件以及它们如何与运行时、Kubernetes集成

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

需要注意的另一件事是，所有内嵌或者依赖docker的项目将不在工作。对于前者，您可以使用crictl工具作为嵌入式替代（请参阅从docker cli到crictl的映射），对于后者，您可以使用较新的容器构建选项，例如img、buildah、kaniko或buildkit-cli-for-kubectl而不需要Docker。

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

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

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

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

参考文档

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim

https://github.com/containerd/containerd/blob/master/ADOPTERS.md

https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md

https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category

https://github.com/containerd/cri/blob/master/docs/registry.md

https://github.com/kubernetes-sigs/cri-tools

https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl

https://github.com/vmware-tanzu/buildkit-cli-for-kubectl