作者Joe Brockmeier是Red Hat公司的Linux容器高级宣传官
Red Hat正式发布CRI-O 1.0
去年，Kubernetes项目推出了容器运行时接口（CRI），这个插件接口让kubelet（一种用来创建pod、启动容器的集群节点代理）能够使用不同的符合OCI的容器运行时环境，不需要重新编译Kubernetes。在此工作的基础上，CRI-O项目（http://cri-o.io/，原先名为OCID）准备为Kubernetes提供一种轻量级运行时环境。
那么，此举到底意味着什么呢？
CRI-O让你可以直接从Kubernetes来运行容器，无需任何不必要的代码或工具。只要容器符合OCI，CRI-O就可以运行它，摈弃了非必要的工具，让容器一心处理它最擅长的方面：运行下一代云原生应用程序。
在CRI发布之前， Kubernetes通过“一种不稳定的内部接口”（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的运行时环境。它可以从任何容器注册中心获取镜像，使用容器网络接口（CNI）来处理网络，那样任何与CNI兼容的网络插件有可能与该项目协同运行。
Kubernetes需要运行容器时，它与CRI-O对话，CRI-O守护程序与runc（或另一种符合OCI的运行时环境）协同运行、启动容器。Kubernetes需要停止容器时，CRI-O处理这项任务。没有什么好激动人心的，CRI-O就在幕后工作，管理Linux容器，那样用户就不需要为容器编排的这个关键部分而操心。
CRI-O概况图
CRI-O不是什么？
有必要花点时间说说CRI-O不是什么。CRI-O的职责范围就是与Kubernetes协同运行，管理和运行OCI容器。它倒不是想成为一种面向开发人员的工具，不过该项目确实有一些面向用户的工具用来排查故障。
比如说，构建镜像在CRI-O的职责范围之外，这项任务交给了像Docker的build命令、Buildah或OpenShift的Source-to-Image（S2I）这些工具。一旦镜像构建完毕，CRI-O就会轻松使用它，但镜像的构建交给其他工具去完成。
虽然CRI-O确实包括一个命令行接口（CLI），但它主要是为测试CRI-O而提供的，其实并不是作为管理生产环境中容器的一种方法。
下几步
CRI-O 1.0现已发布，我们希望看到它作为一项稳定功能添加到Kubernetes的下一个版本中。1.0版本可与Kubernetes 1.7.x系列兼容，面向Kubernetes 1.8.x的CRI-O 1.8-rc1版本很快就会发布。
