“
https://github.com/containerd/containerd/
”
CRI-O
CRI-O 是主要由 Red Hat 员工开发的 CRI 运行时。它的最大区别在于并不依赖于 Docker，而且目前已经在 Red Hat OpenShift 中得到使用。
有趣的是，RHEL 7 同样不官方支持 Docker。相反，其只为容器环境提供 Podman、Buildah 以及 CRI-O。
“
https://github.com/cri-o/cri-o
”
CRI-O 的优势在于其采用极简风格，或者说它的设计本身就是作为“纯 CRI”运行时存在。不同于作为 Docker 组成部分的 containerd，CRI-O 在本质上属于纯 CRI 运行时、因此不包含除 CRI 之外的任何其他内容。
从 Docker 迁移至 CRI-O 往往更为困难，但无论如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常运行。
3、还有一点……
当我们谈论容器运行时时，请注意我们到底是在谈论哪种类型的运行时。运行时分为两种：CRI 运行时与 OCI 运行时。
CRI 运行时
正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器运行时进行通信以创建 / 删除容器化应用程序。
各容器化应用程序作为 kubelet 通过 IPC 在 gRPC 内通信，而且运行时也运行在同一主机之上；CRI 运行时负责从 kubelet 获取请求并执行 OCI 容器运行时以运行容器。稍微有点复杂，接下来我们会用图表来解释。
因此，CRI 运行时将执行以下操作：
从 kubelet 获取 gRPC 请求。
根据规范创建 OCIjson 配置。
OCI 运行时
OCI 运行时负责使用 Linux 内核系统调用（例如 cgroups 与命名空间）生成容器。您可能听说过 runc 或者 gVisor，这就是了。
附录 1：runC 的工作原理
CRI 会通过 Linux 系统调用以执行二进制文件，而后 runC 生成容器。这表明 runC 依赖于 Linux 计算机上运行的内核。
这也意味着，如果您发现 runC 中的漏洞会使您获得主机 root 权限，那么容器化应用程序同样会造成 root 权限外泄。很明显，恶意黑客会抓住机会入侵主机，引发灾难性的后果。正因为如此，大家才需要不断更新 Docker（或者其他容器运行时），而不仅仅是更新容器化应用程序本身。
附录 2：gVisor 工作原理
gVisor 是最初由谷歌员工创建的 OCI 运行时。它实际上运行在承载各类谷歌云服务（包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions）的同一套基础设施之上。
有趣的是，gVisor 中包含一个“访客内核”层，意味着容器化应用程序无法直接接触到主机内核层。即使是应用程序“认为”自己接触到了，实际接触到的也只是 gVisor 的访客内核。
gVisor 的安全模式非常有趣，这里建议大家参阅官方说明文档。
“
https://gvisor.dev/docs/
”
gVisor 与 runC 的显著差别如下：
性能更差
Linux 内核层并非 100% 兼容：参见官方文档中的兼容性部分
不受默认支持
“
https://gvisor.dev/docs/user_guide/compatibility/
”
4、总结
1) Docker 确被弃用，大家应该开始考虑使用 CRI 运行时，例如 containerd 与 CRI-O。
a.containerd 与 Docker 相兼容，二者共享相同的核心组件。
b. 如果您主要使用 Kubernetes 的最低功能选项，CRI-O 可能更为适合。
2) 明确理解 CRI 运行时与 OCI 运行时之间的功能与作用范围差异。
根据您的实际工作负载与业务需求，runC 可能并不总是最好的选择，请酌情做出考量！
译文原文链接：
“
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
”
读者福利
感谢你看到了这里！
我这边整理很多2020最新Java面试题（含答案）和Java学习笔记，如下图
上述的面试题答案小编都整理成文档笔记。 同时也还整理了一些面试资料&最新2020收集的一些大厂的面试真题（都整理成文档，小部分截图）免费分享给大家，有需要的可以 点击进入暗号：CSDN！免费分享~
如果喜欢本篇文章，欢迎转发、点赞。
记得关注我！
