几年前， Docker使容器流行。随着Kubernetes容器编排的兴起 ， Cloud Native Computing Foundation(CNCF) 新采用的开源 容器运行时界面-Orchestrator (CRI-O) 运行时– CRI-O可能会成为容器部署的最高水平。

这是因为要大规模运行容器，您需要一个编排程序。到2017年底，Kubernetes已成为最受欢迎的容器协调器。

您当然可以使用Docker用户在Kubernetes下运行容器。实际上，Docker仍然是Kubernetes的默认容器运行时。但是轻量级的CRI-O运行时可以与Kubernetes一起使用API​​手套。

CRI-O具有以下功能：

存储： github.com/containers/storage库用于管理层并为Pod中的容器创建根文件系统：实现了OverlayFS，devicemapper，AUFS和btrfs，其中OverlayFS作为默认驱动程序。

容器图像： github.com/containers/image库用于从注册表中提取图像。当前，它支持Docker模式2 /版本1和模式2 /版本2。它还通过了所有Docker和Kubernetes测试。

网络：容器网络接口(CNI)用于为Pod设置网络。各种CNI插件(例如Flannel，Weave，Cilium和OpenShift-SDN)均已通过CRI-O进行了测试，并且可以按预期运行。

监视： github.com/containers/conmon是CRI-O中的一个实用程序，用于监视容器，处理容器过程中的日志记录，服务附加客户端以及检测和报告内存不足(OOM)情况。

安全性：容器安全性分离策略由一系列工具提供，包括SELinux，Capabilities，seccomp和OCI规范中指定的其他安全性分离策略。

CRI最初是一个API，用于定义对容器运行时的调用。这使人们可以制作对Kubernetes友好的轻量级容器运行时程序。CRI-O是第一个Kubernetes兼容CRI的容器运行时。它是由Google和Red Hat在英特尔，SUSE和IBM的帮助下创建的。CRI-O已变得非常流行。

Kubernetes联合创始人布伦丹·伯恩斯(Brendan Burns)表示，这在一定程度上是因为“ CRI-O的创始负责人不是在“重新发明轮子”，而是使用共享组件并完善在生产以及现有的经过战斗测试的代码中测试的方法。 O是专门为Kubernetes量身定制的，它针对性能，稳定性，兼容性和对标准的遵守程度进行了调整，尤其是Kubernetes一致性测试.CRI-O是任何Kubernetes集群的构建基块，并可以根据需要简化容器的生命周期Kubernetes CRI。”

那么这是否意味着CRI-O将取代Docker?好，是的，不是。

正如红帽高级工程师兼CRI-O维护者Antonio Murdaca所解释的那样：“ CRI-O是否将取代Docker?不是，或者，这意味着它是Kubernetes重点的运行时，因此它在Kubernetes的背景下取代了Docker。它不会取代Docker成为我们都习惯的开发人员工具。CRI-O没有实现Docker Engine API或Docker CLI，这意味着您无法使用Docker CLI与CRI-O守护进程进行对话。您必须通过Kubernetes。”

尽管如此，它将给Docker带来竞争。正如CNCF CTO Chris Aniszczyk写道：“ CNCF托管各种容器运行时，我们很高兴CRI-O作为孵化级别项目加入其中。选择和竞争使最终用户受益。”