来奉献几分钟提交：2020年CNCF中国云原生问卷

问卷链接（https://www.wjx.cn/jq/9714648...）

本文介绍了一些常见的对于在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弃用了吗？》对更改进行更深刻的技术探讨。

我能拥抱一下吗？

只有你违心，随时随地！????????

点击浏览网站原文。

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。