Kubernetes增加了一套用于插拔任何pods运行时的API，称为容器运行时接口（Container Runtime Interface，CRI）。我不愿意在我的系统上运行太多的守护进程，但是我们基于此增加了一种。由我们团队中Mrunal Patel领导的小组，在2016年晚些时候开始实现CRI-O守护进程。这是一个用于运行基于OCI应用程序的容器运行时接口守护进程。理论上，未来我们可以将CRI-O代码直接编译如kubelet，以减少一个守护进程。
和其他容器运行时不同的是，CRI-O的唯一目的是满足Kubernetes的需求。回忆一下前面提到的关于Kubernetes运行一个容器所需要的步骤。
Kubernetes向kubelet发送一个消息，通知它需要启动一个nginx服务：
kubelet调用CRI-O告知其运行nginx。
CRI-O响应CRI请求。
CRI-O在镜像仓库中找到对应的OCI镜像。
CRI-O使用containers/image将镜像从仓库拉取到本地。
CRI-O使用containers/storage将镜像解压到本地存储中。
CRI-O使用OCI运行时规范启动容器，通常使用runc。我前面提到过，这和Docker守护进程使用runc来启动容器的方式相同。
如果需要，kubelet也可以使用其他的运行时来启动容器，例如Clear Containers的runv
CRI-O旨在成为运行Kubernetes的稳定平台，我们只会在通过了所有Kubernetes的测试集之后才会发布新的版本。所有提交到https://github.com/Kubernetes-incubator/cri-o上的pull request都需要运行整个Kubernetes测试集。开发者不能提交一个无法通过这些测试的pull request。CRI-O是一个完全开放的项目，目前已经有来自Intel、SUSE、IBM、Google、Hyper.sh等公司的贡献者。只要CRI-O的大多数维护者同意，pull request就会被接受，即使这些补丁功能不是红帽公司需要的。
总结我希望本文的深入探讨能够帮助读者了解Linux容器的演化史。Linux一度处于每个厂商有自己标准的情形。Docker公司专注于建立镜像构建的事实标准，并且简化了容器的相关工具。Open Container Initiative的建立意味着行业正在围绕着核心镜像格式和运行时制定规范，围绕着让工具更有效率、更安全、高可扩展性和可用性进行创新。容器允许我们能够用新颖的方式验证软件安装，无论其是运行在主机上的传统软件还是运行在云端经过编排的微服务。在很多方面，这还仅仅是个开始。
查看英文原文：https://opensource.com/article/17/7/how-linux-containers-evolved