cri-o_CRI-O：Kubernetes的所有运行时需求

cri-o

在过去几年中，随着容器技术的使用大量增加，我们也看到了Docker的类似增长。 因为Docker使容器的创建比以前的解决方案更加容易，所以它Swift成为运行容器的最受欢迎的工具。 但是，Docker仅解决了部分问题很快就显而易见了。 尽管Docker非常适合在一台机器上本地运行容器，但对于在集群上大规模运行软件却效果不佳。 相反，需要一个编排系统，该系统可以帮助轻松地跨多台机器调度容器并添加缺少的部分，例如服务，部署和入口。 包括Mesos，Docker Swarm和Kubernetes在内的新老项目都介入解决了这个问题，但是Kubernetes成为了在生产中部署容器的最常用解决方案。

容器运行时接口（CRI）

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

使用gRPC API从容器运行时中获取kubelet （负责在本地系统上运行一组Pod的Kubernetes组件）。 只要任何人都实现所有方法，就可以实现CRI。

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

什么是CRI-O？

CRI-O项目的开始是为了创建专用于Kubernetes的最小可维护运行时。 它源于Red Hat工程师在与容器相关的各种工具上的工作，例如skopeo （用于从容器注册表中提取图像）和container / storage （用于为支持不同文件系统驱动程序的容器创建根文件系统）。 红帽还通过开放容器倡议 （OCI）参与了容器标准化的维护工作。

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

CRI-O是一个社区驱动的开源项目，由Red Hat，Intel，SUSE，Hyper，IBM等公司的维护者和贡献者开发。

基本上，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配置。

存储

容器/存储库用于管理层和为容器中的容器创建根文件系统。 实现了OverlayFS ， 设备映射器 ， aufs和Btrfs ，其中Overlay是默认驱动程序。 正在支持基于网络的文件系统映像（例如NFS，Gluster，Cefs）。

图片

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

联网

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

监控方式

CRI-O的conmon实用程序用于监视容器，处理容器过程中的日志记录，为连接的客户端提供服务以及检测内存不足（OOM）情况。

安全

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

吊舱架构

CRI-O提供以下设置：

架构组件细分如下：

• 豆荚生活在cgroups切片中； 它们拥有共享的IPC，net和PID 名称空间 。
• 当调用CRI CreateContainer / RunPodSandbox API时，容器/存储库将生成容器的根文件系统。
• 每个容器都有一个监视进程（通用），该进程接收主伪终端（pty），在主/从pty对之间复制数据，处理容器的日志记录并记录容器进程的退出代码。
• 使用容器/图像库实现CRI图像API。
• 通过CNI设置Pod的网络，因此任何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。 使用此剧本尝试一下。

你怎么能贡献？

CRI-O是在GitHub上开发的，有很多方法可以为该项目做出贡献。

• 查看问题并提出拉动请求以贡献修补程序和功能。
• 测试和打开任何bug的问题将非常有帮助，例如，遵循README并使用CRI-O作为运行时来测试Kubernetes的各种功能。
• Kubernetes的教程是测试Kubernetes各种功能的良好起点。
• 该项目正在引入一个命令行界面，以允许用户播放/调试CRI-O的后端，并且需要大量的帮助来构建它。 任何想要进行golang编程的人都欢迎参加。
• 始终需要包装和文档方面的帮助。

通信在IRC（freenode）上的＃cri-o以及GitHub问题和拉取请求上进行。 我们希望看到你在那里。

在将于12月6日至8日在德克萨斯州奥斯汀举行的KubeCon + CloudNativeCon上 ，在Mrunal Patel的演讲“ CRI-O：所有运行时Kubernetes的需求”和“无所不包”中了解更多信息。

翻译自: https://opensource.com/article/17/12/cri-o-all-runtime-kubernetes-needs

cri-o