来奉献几分钟提交：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 微信公众号。