CRI-O 1.0 简介
去年，Kubernetes 项目推出了容器运行时接口（CRI）：这是一个插件接口，它让 kubelet 有使用不同的兼容 OCI 的容器运行时的能力，而不需要重新编译 Kubernetes。在这项工作的基础上，CRI-O 项目（原名 OCID）准备为 Kubernetes 提供轻量级的运行时。
容器 Kubernetes CRI
去年，Kubernetes 项目推出了容器运行时接口（CRI）：这是一个插件接口，它让 kubelet 有使用不同的兼容 OCI 的容器运行时的能力，而不需要重新编译 Kubernetes。在这项工作的基础上，CRI-O 项目（原名 OCID）准备为 Kubernetes 提供轻量级的运行时。
![](/data/attachment/album/201710/31/234936q6dom9robz9poc9f.jpg)


去年，Kubernetes 项目推出了<ruby> <a href="https://github.com/kubernetes/kubernetes/blob/242a97307b34076d5d8f5bbeb154fa4d97c9ef1d/docs/devel/container-runtime-interface.md">  容器运行时接口 </a> <rt>  Container Runtime Interface </rt></ruby>（CRI）：这是一个插件接口，它让 kubelet（用于创建 pod 和启动容器的集群节点代理）有使用不同的兼容 OCI 的容器运行时的能力，而不需要重新编译 Kubernetes。在这项工作的基础上，[CRI-O](http://cri-o.io/) 项目（[原名 OCID](https://www.redhat.com/en/blog/running-production-applications-containers-introducing-ocid)）准备为 Kubernetes 提供轻量级的运行时。


那么这个**真正的**是什么意思？


CRI-O 允许你直接从 Kubernetes 运行容器，而不需要任何不必要的代码或工具。只要容器符合 OCI 标准，CRI-O 就可以运行它，去除外来的工具，并让容器做其擅长的事情：加速你的新一代原生云程序。


在引入 CRI 之前，Kubernetes 通过“[一个内部的](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)[易失性](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)[接口](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)”与特定的容器运行时相关联。这导致了上游 Kubernetes 社区以及在编排平台之上构建解决方案的供应商的大量维护开销。


使用 CRI，Kubernetes 可以与容器运行时无关。容器运行时的提供者不需要实现 Kubernetes 已经提供的功能。这是社区的胜利，因为它让项目独立进行，同时仍然可以共同工作。


在大多数情况下，我们不认为 Kubernetes 的用户（或 Kubernetes 的发行版，如 OpenShift）真的关心容器运行时。他们希望它工作，但他们不希望考虑太多。就像你（通常）不关心机器上是否有 GNU Bash、Korn、Zsh 或其它符合 POSIX 标准 shell。你只是要一个标准的方式来运行你的脚本或程序而已。


### CRI-O：Kubernetes 的轻量级容器运行时


这就是 CRI-O 提供的。该名称来自 CRI 和开放容器计划（OCI），因为 CRI-O 严格关注兼容 OCI 的运行时和容器镜像。


现在，CRI-O 支持 runc 和 Clear Container 运行时，尽管它应该支持任何遵循 OCI 的运行时。它可以从任何容器仓库中拉取镜像，并使用<ruby> <a href="https://github.com/containernetworking/cni">  容器网络接口 </a> <rt>  Container Network Interface </rt></ruby>（CNI）处理网络，以便任何兼容 CNI 的网络插件可与该项目一起使用。


当 Kubernetes 需要运行容器时，它会与 CRI-O 进行通信，CRI-O 守护程序与 runc（或另一个符合 OCI 标准的运行时）一起启动容器。当 Kubernetes 需要停止容器时，CRI-O 会来处理。这没什么令人兴奋的，它只是在幕后管理 Linux 容器，以便用户不需要担心这个关键的容器编排。


![CRI-O Overview](/data/attachment/album/201710/31/234945ee5euzn7hu0cnu4u.png "CRI-O Overview")


### CRI-O 不是什么


值得花一点时间了解下 CRI-O *不是*什么。CRI-O 的范围是与 Kubernetes 一起工作来管理和运行 OCI 容器。这不是一个面向开发人员的工具，尽管该项目确实有一些面向用户的工具进行故障排除。


例如，构建镜像超出了 CRI-O 的范围，这些留给像 Docker 的构建命令、 [Buildah](https://github.com/projectatomic/buildah) 或 [OpenShift 的 Source-to-Image](https://github.com/openshift/source-to-image)（S2I）这样的工具。一旦构建完镜像，CRI-O 将乐意运行它，但构建镜像留给其他工具。


虽然 CRI-O 包含命令行界面 （CLI），但它主要用于测试 CRI-O，而不是真正用于在生产环境中管理容器的方法。


### 下一步


现在 CRI-O 1.0 发布了，我们希望看到它作为一个稳定功能在下一个 Kubernetes 版本中发布。1.0 版本将与 Kubernetes 1.7.x 系列一起使用，即将发布的 CRI-O 1.8-rc1 适合 Kubernetes 1.8.x。


我们邀请您加入我们，以促进开源 CRI-O 项目的开发，并感谢我们目前的贡献者为达成这一里程碑而提供的帮助。如果你想贡献或者关注开发，就去 [CRI-O 项目的 GitHub 仓库](https://github.com/kubernetes-incubator/cri-o)，然后关注 [CRI-O 博客](https://medium.com/cri-o)。




---


via: <https://www.redhat.com/en/blog/introducing-cri-o-10>


作者：[Joe Brockmeier](https://www.redhat.com/en/blog/authors/joe-brockmeier) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

