问卷链接（https://www.wjx.cn/jq/97146486.aspx）
本文介绍了一些常见的关于在Kubernetes v1.20版本中宣布的Dockershim弃用的问题。关于弃用Docker作为Kubernetes kubelets的容器运行时的更多细节，以及这意味着什么，请查看博客文章《不要惊慌：Kubernetes和Docker》。
为什么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。我们将与供应商和其他生态系统组织密切合作，以确保平稳过渡，并将根据情况的演变进行评估。
我现有的Docker镜像还能工作吗？
可以，从docker build产生的镜像将与所有CRI实现一起工作。你所有的现有镜像将仍然完全相同的工作。
那么私有映像呢？
也可以。所有CRI运行时都支持Kubernetes中使用的相同的pull secrets配置，无论是通过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代表Open Container Initiative（开放容器倡议），它标准化了容器工具和技术之间的许多接口。它们维护了包装容器映像（OCI映像规范）和运行容器（OCI运行时规范）的标准规范。它们还以runc的形式维护运行时规范的实际实现，它是containerd和CRI-O的底层默认运行时。CRI构建在这些低层规范之上，为管理容器提供端到端标准。
我应该使用哪个CRI实现？
这是一个复杂的问题，它取决于很多因素。如果Docker为你工作得很好，迁移到containerd应该是一个相对容易的交换，并且具有更好的性能和更少的开销。但是，我们鼓励你探索CNCF互动景观的所有选项，以防其他选项更适合你的环境。
更改CRI实现时应该注意什么？
虽然Docker和大多数CRI（包括containerd）之间的底层容器化代码是相同的，但在边缘有一些不同之处。迁移时要考虑的一些常见的事情是：
-
日志配置
-
运行时资源限制
-
节点配置脚本，调用docker或使用docker通过它的控制socket
-
需要docker CLI或控制socket的Kubectl插件
-
需要直接访问Docker的Kubernetes工具（例如kube-imagepuller）
-
配置注册镜像和不安全注册表等功能
-
假设docker可用并在Kubernetes之外运行的其他支持脚本或守护进程（例如监视或安全代理）
-
GPU或特殊硬件以及它们如何与运行时和Kubernetes集成
如果你使用Kubernetes资源请求/限制（request/limit）或基于文件的日志收集DaemonSet，那么它们将继续以相同的方式工作，但是如果你已经定制了dockerd配置，则需要在可能的情况下为新的容器运行时进行调整。
另一件需要注意的事情是，在构建镜像时，任何希望运行用于系统维护或嵌套在容器内的东西都将不再工作。对于前者，你可以使用crictl工具作为替换，对于后者，你可以使用较新的容器构建选项，如img、buildah或kaniko，它们不需要Docker。
对于containerd，你可以从它们的文档开始，看看在迁移时有哪些配置选项可用。
有关如何将containerd和CRI-O与Kubernetes一起使用的说明，请参阅Kubernetes关于容器运行时的文档
如果我还有问题怎么办？
如果你使用供应商支持的Kubernetes发行版，你可以询问他们关于其产品的升级计划。对于最终用户的问题，请发送到我们的最终用户社区论坛。
你也可以看看这篇优秀的博客文章：《等等，Docker已经被Kubernetes弃用了吗？》对更改进行更深入的技术讨论。
我能拥抱一下吗？
只要你愿意，随时随地！