CRI-O：Kubernetes 所需的全部运行时

在过去几年中，随着容器技术使用的巨大增长，我们也看到了 Docker 的类似增长。因为 Docker 比以前的解决方案更容易创建容器，所以它迅速成为运行容器最流行的工具；然而，Docker 只解决了问题的一部分很快就变得明显。虽然 Docker 非常适合在单台机器上本地运行容器，但它在集群上大规模运行软件时效果不佳。相反，需要一个编排系统，它可以轻松地跨多台机器调度容器，并添加缺失的部分，例如服务、部署和入口。包括 Mesos、Docker Swarm 和 Kubernetes 在内的新旧项目都介入来解决这个问题，但 Kubernetes 成为生产环境中部署容器最常用的解决方案。

容器运行时接口 (CRI)

最初，Kubernetes 构建在 Docker 之上作为容器运行时。不久之后，CoreOS 宣布了 rkt 容器运行时，并希望 Kubernetes 也支持它。因此，Kubernetes 最终支持了 Docker 和 rkt，尽管这种模型在添加新功能或支持新的容器运行时方面不是很可扩展。

引入容器运行时接口 (CRI) 是为了解决这个问题。CRI 由镜像服务和运行时服务组成。CRI 背后的想法是将 kubelet（Kubernetes 组件，负责在本地系统上运行一组 pod）与容器运行时解耦，使用 gRPC API。这使任何人都可以实现 CRI，只要他们实现所有方法。

此外，在尝试更新 Docker 版本以与 Kubernetes 配合使用时也存在问题。Docker 的范围不断扩大，并添加了功能来支持其他项目，例如 Swarm，这些功能对于 Kubernetes 来说不是必需的，并且导致 Docker 更新不稳定。

什么是 CRI-O？

CRI-O 项目启动的目的是创建一个专门用于 Kubernetes 的最小可维护运行时。它源于 Red Hat 工程师在各种与容器相关的工具上的工作，例如 skopeo，它用于从容器注册中心拉取镜像；以及 containers/storage，它用于为支持不同文件系统驱动程序的容器创建根文件系统。Red Hat 也通过 开放容器倡议 (OCI) 参与了容器标准化的维护工作。

CRI-O 是一个社区驱动的开源项目，由来自 Red Hat、Intel、SUSE、Hyper、IBM 等公司的维护者和贡献者开发。它的名字来源于 CRI 和 OCI，因为该项目的目标是使用基于 OCI 标准的组件来实现 Kubernetes CRI。

基本上，CRI-O 是 Kubernetes CRI 的一个实现，它允许 Kubernetes 使用任何符合 OCI 标准的运行时作为运行 pod 的容器运行时。它目前支持 runc 和 Clear Containers，但原则上任何符合 OCI 标准的运行时都可以插入。

CRI-O 支持 OCI 容器镜像，并且可以从任何兼容的容器注册中心拉取。它是使用 Docker 作为 Kubernetes 运行时的轻量级替代方案。

该项目的范围与 CRI 相关联。目前 CRI-O 唯一支持的用户是 Kubernetes。鉴于此，项目维护者努力通过提供严格而全面的测试套件来确保 CRI-O 始终与 Kubernetes 协同工作。这些端到端测试在每个拉取请求上运行，以确保它不会破坏 Kubernetes，并且测试也在不断发展以跟上 Kubernetes 的变化。

组件

CRI-O 由几个组件组成，这些组件位于不同的 GitHub 仓库中。

OCI 兼容的运行时

CRI-O 支持任何 OCI 兼容的运行时，包括 runc 和 Clear Containers，它们使用 OCI 运行时工具库进行测试，该库为这些运行时生成 OCI 配置。

存储

containers/storage 库用于管理层，并为 pod 中的容器创建根文件系统。已实现 OverlayFS、device mapper、aufs 和 Btrfs，默认驱动程序为 Overlay。对基于网络的的文件系统镜像（例如，NFS、Gluster、Cefs）的支持正在进行中。

镜像

containers/image 库用于从注册中心拉取镜像。它支持 Docker 版本 2 schema 1 和 schema 2。它还通过了所有 Docker 和 Kubernetes 测试。

网络

容器网络接口 (CNI) 为 pod 设置网络。各种 CNI 插件，例如 Flannel、Weave 和 OpenShift-SDN，已经过 CRI-O 测试，并且运行正常。

监控

CRI-O 的 conmon 实用程序用于监控容器、处理来自容器进程的日志、为连接的客户端提供服务以及检测内存不足 (OOM) 情况。

安全

容器安全隔离策略由一系列工具提供，包括 SELinux、Linux capabilities、seccomp 以及 OCI 规范中描述的其他安全隔离策略。

Pod 架构

CRI-O 提供以下设置

图片来源：

opensource.com

架构组件分解如下

• Pod 存在于 cgroups 切片中；它们持有共享的 IPC、net 和 PID 命名空间。
• 当调用 CRI CreateContainer/RunPodSandbox API 时，容器的根文件系统由 containers/storage 库生成。
• 每个容器都有一个监控进程 (conmon)，它接收主伪终端 (pty)、在主/从 pty 对之间复制数据、处理容器的日志并记录容器进程的退出代码。
• CRI 镜像 API 是使用 containers/image 库实现的。
• pod 的网络是通过 CNI 设置的，因此任何 CNI 插件都可以与 CRI-O 一起使用。

状态

CRI-O 版本 1.0.0 和 1.8.0 已经发布；1.0.0 版本与 Kubernetes 1.7.x 兼容。1.0 之后的版本与主要的 Kubernetes 版本版本匹配，因此很容易看出 CRI-O 1.8.x 支持 Kubernetes 1.8.x，1.9.x 将支持 Kubernetes 1.9.x，依此类推。

亲自尝试

• Minikube 支持 CRI-O。
• 使用 CRI-O README 中的说明，可以轻松设置 Kubernetes 本地集群。
• 可以使用 kubeadm 设置 CRI-O；尝试使用这个 playbook。

如何贡献？

CRI-O 在 GitHub 上开发，在那里有很多方式可以为项目做出贡献。

• 查看 issue 并提交 pull request 以贡献修复和功能。
• 测试并为任何错误打开 issue 将非常有帮助，例如通过遵循 README 并使用 CRI-O 作为运行时来测试各种 Kubernetes 功能。
• Kubernetes 的 教程 是测试各种 Kubernetes 功能的良好起点。
• 该项目正在引入一个命令行界面，以允许用户玩/调试 CRI-O 的后端，并且需要大量帮助来构建它。欢迎任何想做一些 golang 编程的人尝试一下。
• 始终需要包装和文档方面的帮助。

沟通在 IRC (freenode) 上的 #cri-o 频道以及 GitHub issue 和 pull request 中进行。我们希望在那里见到你。

在 Mrunal Patel 的演讲 CRI-O：Kubernetes 所需的全部运行时，以及更多 中了解更多信息，该演讲将在 KubeCon + CloudNativeCon 上进行，将于 12 月 6 日至 8 日在德克萨斯州奥斯汀举行。