本文讲的是CRI-O将如何把Kubernetes推上容器生态系统的中心位置【编者的话】CRI-O是什么？它将给容器世界带来哪些改变？
开源项目 CRI-O ，即之前的OCID，旨在不依赖传统容器引擎的前提下，使开源 Kubernetes 调度框架可以管理和启动容器化的工作负载。
使用Google发起、Kubernetes工程师开发的容器运行时接口（CRI），通过与Kubernetes或Kubernetes的商业实例（如 CoreOS Tectonic ）进行交互，该软件可以帮助DevOps专家管理整个“容器生命周期”。
开发者需要容器引擎来创建和构建容器镜像，也可以使用自己的模拟环境。在管理更复杂的生产环境时，管理和运营团队会发现使用Kubernetes stack——即调度框架、CRI和CRI-O——会比将调度框架和标准容器引擎配对更加方便。
该项目将容器调度工具，而非容器引擎，推上了容器栈组件的当家位置。CRI的贡献者告诉我们，CRI允许Kubernetes使用任何容器引擎，只要该引擎符合 开放容器倡议 的规范，包括OCI自己的 runc 引擎，它可以做到品牌容器引擎如Docker和CoreOS的 rkt 的许多功能，包括从registry中pull镜像的功能，但不能从makefile构建镜像。
CRI-O项目最重要的主张是，用户不应该对创建工作负载并用以stage的容器产生依赖。按照最初的设想，该项目将对Kubernetes提供工具，使其不需要Docker、 rkt 、OpenShift、Photon等任何的品牌容器，就可以管理容器的全生命周期。
Hightower 表示，“我们从容器运行时中需要得到的东西并不多——无论是Docker还是 rkt ，它们要做的都很少，主要是把内核的API给我们。所以这并不仅仅是关于Linux的，我们也可以用在Windows系统上。如果这是社区想要发展的方向，我们需要Kubernetes去支持这些想法——因为这比Docker Inc.更重要，这才是重点。”
此主张的潜在假设是，调度框架位于容器生态系统的中心位置，而我们必须认识到“引擎”其实只是一个开发工具。
另一方面，CRI（通过Kubernetes开发，也是为了Kubernetes而开发的API）向容器引擎制造商们提供了一个机会，即实现Kubernetes的开放接口，这样一来，拥有容器引擎的环境便可以合理连接。据一位谷歌核心工程师表示，这些连接可以在没有容器引擎提供商“重构”引擎的情况下实现Kubernetes的兼容性。
相反，一个叫做shim的抽象层可以被插入容器引擎和调度框架之间。容器供应商们如何实现shim抽象层就取决于他们了。
完成之后，CRI API（和Kubernetes连接的部分）可以将更多的容器生命周期控制交给Kubelet——即Kubernetes专属的容器管理器，它将被容器生态系统所采用。
Kubernetesd的下一个版本，即1.5版本的目标是，包含一个定型的CRI用来使kubelet和Docker、rkt、 中国的容器供应平台Hyper.sh ，以及由红帽领导开发的CRI-O进行交互。
Philips表示，“许多不同的容器运行时都想和Kubernetes进行交互，所以我们没有在kubelet中为每一个容器进行时构建单独的接口，而是创建一个更加抽象的接口，让其他人不需与Kubernetes上游工作直接相关也可以接入。
如果CRI-O成功了，他解释说，所有容器引擎生产者都不必再更改引擎的代码库，只要和Kubernetes交互操作就行了。
Hightower承认，“目前，想要玩好Kubernetes，需要构建一堆东西，而且可能改变目前使用的一些方式，你必须自己查看代码库搞清楚一些东西，这就是我们为Docker做的，如何为你的运行时引擎调整到适合你的方式，同时也适用与Kubernetes。”
CoreOS的Philips解释道，每一个容器引擎会利用shim组件，它可以将容器本地词汇的API请求翻译为Kubernetes可以理解的形式。
Philips 说，“由于CRI的工作方式的原因，你需要一个 GRPC 守护进程 ，它会监听这些请求，并和kubelet进行交流。”反过来，kubelet会通过套接字向实现了CRI的引擎发送远程调用反馈。
“当前的Docker和 rkt 支持正被拉进CRI接口，”philis解释道。CoreOS的 rkt 对CRI的实现目前 在Gtihub上，名为rktlet 。他希望不管是rktlet还是Docker的实现，最终都能重构进CRI中。
Docker已经要求实现和Kubernetes之间的shim了，谷歌的Hightower告诉我们，这个shim是Kubernetes而不是Docker的工程师生产的。Philips说，不管谁来实现CRI shim，Docker都会被重制以适应和其他人的合作。
同时，Docker继续增强其容器引擎，将特征联系起来，比如其Swarm 调度框架和服务发现。
“我觉得一切都好，”他说，“当然可能有人不喜欢，但没关系，每个人都可以有自己的意见。Kubernetes——我们也提供一堆东西。但我们更相信我们是在做一些商品之上的东西”
假设真的实现了一个能理解当前容器化语言的接口，能够抽象出面向pod、基于kubelet的逻辑，而相同的API可以和Kubernetes之外的东西对接时，可以以不同的方式抽象出自己的逻辑。
我们和Mesosphere的创始人 Ben Hindman 探讨了这种可能性。
“我觉得行业真正在探寻的东西，是可以被灵活操作的部件，” Hindman 向 The New Stack解释道，“我认为，以Kubernetes为例，这非常关键。Kubernetes以往是依赖于Docker去做容器管理的，他们也曾尝试去构建调度。Docker并入了Swarm之后，他们就有了一个可以用来做调度的容器管理器。所以单从构架和工程师的角度，我会说‘我们要是有一个做容器管理的组件就好了……这样可能有成倍的人来使用’”。
Hindman相信Docker是很想把 runc 作为开放标准的。但调度需要的不仅仅是和运行时进行交互操作。
这是否意味着Mesosphere支持CRI-O，其目标——正如Kelsey Hightower所说——和Hindman之前所说的完全一致。
尽管Hindman并不代表OCI，但必须注意到Mesosphere是OCI的创始成员之一。正如Hindman回应的，OCI的初衷是发展一种常规运行时模式，并使 runc 可以将其作为一个容器来打开。容器化社区也十分关心镜像格式问题，其中包括容器rest状态时的文件系统和元数据。OCI也十分认同上文中的目标， Hindman表示，“其实，这比运行时格式更吸引我们。”
式。
至于Mesosphere为什么着手去做所谓的“ 万能容器 ”，Hindman继续说道，“是为了生产面向所有开放格式的容器，包括OCI。”
Hindman说，但在这最佳的构架下，可能并没有标准化的调度工作负载的方式，因为调度任务特征的差异性太大。因此，之前为了实现任何调度器都可以部署和打开，而去寻找单一配置文件、元数据文件或者描述工作负载的努力，也随着Hindman所谓“最低共同标准规范”而终止，该“规范”拥有功能集更为广泛的调度器。
而决定通用的镜像格式，相比之下就简单多了。它归结于Linux是否支持该格式。“如果Linux支持，我们就公开该标准。我认为大家不会在镜像格式的问题上有太多争议，因此，把它当做标准是完全没问题的。”
Mesosphere将继续支持OCI（ 或者叫“OCID” ），Hindman总结说，也会根据支持OCI的程度继续支持CRI-O。但是Mesosphere的“通用容器运行时”会以不同的方式进行这项支持。
市场将会变得更具竞争力，彼时市场的主角将会是调度框架，而不是被调度的内容。
开源项目 CRI-O ，即之前的OCID，旨在不依赖传统容器引擎的前提下，使开源 Kubernetes 调度框架可以管理和启动容器化的工作负载。
使用Google发起、Kubernetes工程师开发的容器运行时接口（CRI），通过与Kubernetes或Kubernetes的商业实例（如 CoreOS Tectonic ）进行交互，该软件可以帮助DevOps专家管理整个“容器生命周期”。
开发者需要容器引擎来创建和构建容器镜像，也可以使用自己的模拟环境。在管理更复杂的生产环境时，管理和运营团队会发现使用Kubernetes stack——即调度框架、CRI和CRI-O——会比将调度框架和标准容器引擎配对更加方便。
该项目将容器调度工具，而非容器引擎，推上了容器栈组件的当家位置。CRI的贡献者告诉我们，CRI允许Kubernetes使用任何容器引擎，只要该引擎符合 开放容器倡议 的规范，包括OCI自己的 runc 引擎，它可以做到品牌容器引擎如Docker和CoreOS的 rkt 的许多功能，包括从registry中pull镜像的功能，但不能从makefile构建镜像。
CRI-O是什么
谷歌开发工程师， Kubernetes引擎的倡导者和领导者， Kelsey Hightower ，在接受The New Stack采访时谈到，尽管开放容器倡议已经减轻了它对CRI-O的责任（但其成员和贡献者还是相同的供应商和相同的人），但该项目是“OCI的自然进程”，是在发展容器运行时和镜像的标准接口。CRI-O项目最重要的主张是，用户不应该对创建工作负载并用以stage的容器产生依赖。按照最初的设想，该项目将对Kubernetes提供工具，使其不需要Docker、 rkt 、OpenShift、Photon等任何的品牌容器，就可以管理容器的全生命周期。
Hightower 表示，“我们从容器运行时中需要得到的东西并不多——无论是Docker还是 rkt ，它们要做的都很少，主要是把内核的API给我们。所以这并不仅仅是关于Linux的，我们也可以用在Windows系统上。如果这是社区想要发展的方向，我们需要Kubernetes去支持这些想法——因为这比Docker Inc.更重要，这才是重点。”
此主张的潜在假设是，调度框架位于容器生态系统的中心位置，而我们必须认识到“引擎”其实只是一个开发工具。
另一方面，CRI（通过Kubernetes开发，也是为了Kubernetes而开发的API）向容器引擎制造商们提供了一个机会，即实现Kubernetes的开放接口，这样一来，拥有容器引擎的环境便可以合理连接。据一位谷歌核心工程师表示，这些连接可以在没有容器引擎提供商“重构”引擎的情况下实现Kubernetes的兼容性。
相反，一个叫做shim的抽象层可以被插入容器引擎和调度框架之间。容器供应商们如何实现shim抽象层就取决于他们了。
完成之后，CRI API（和Kubernetes连接的部分）可以将更多的容器生命周期控制交给Kubelet——即Kubernetes专属的容器管理器，它将被容器生态系统所采用。
Kubernetesd的下一个版本，即1.5版本的目标是，包含一个定型的CRI用来使kubelet和Docker、rkt、 中国的容器供应平台Hyper.sh ，以及由红帽领导开发的CRI-O进行交互。
Philips表示，“许多不同的容器运行时都想和Kubernetes进行交互，所以我们没有在kubelet中为每一个容器进行时构建单独的接口，而是创建一个更加抽象的接口，让其他人不需与Kubernetes上游工作直接相关也可以接入。
谁重构谁
Hightower描述容器运行时接口（CRI-O中的CRI）为容器引擎应该支持的基本特性的抽象。一旦CRI被完成，Kubernetes计划重构自己的代码库以实现CRI。如果CRI-O成功了，他解释说，所有容器引擎生产者都不必再更改引擎的代码库，只要和Kubernetes交互操作就行了。
Hightower承认，“目前，想要玩好Kubernetes，需要构建一堆东西，而且可能改变目前使用的一些方式，你必须自己查看代码库搞清楚一些东西，这就是我们为Docker做的，如何为你的运行时引擎调整到适合你的方式，同时也适用与Kubernetes。”
CoreOS的Philips解释道，每一个容器引擎会利用shim组件，它可以将容器本地词汇的API请求翻译为Kubernetes可以理解的形式。
Philips 说，“由于CRI的工作方式的原因，你需要一个 GRPC 守护进程 ，它会监听这些请求，并和kubelet进行交流。”反过来，kubelet会通过套接字向实现了CRI的引擎发送远程调用反馈。
“当前的Docker和 rkt 支持正被拉进CRI接口，”philis解释道。CoreOS的 rkt 对CRI的实现目前 在Gtihub上，名为rktlet 。他希望不管是rktlet还是Docker的实现，最终都能重构进CRI中。
Docker已经要求实现和Kubernetes之间的shim了，谷歌的Hightower告诉我们，这个shim是Kubernetes而不是Docker的工程师生产的。Philips说，不管谁来实现CRI shim，Docker都会被重制以适应和其他人的合作。
“为了和CRI结合，Docker容器和rkt容器都在发生改变。” –Brandon Philips，CoreOSOCI镜像格式的最终标准还未敲定，尽管OCI的一位发言人曾告知《The New Stack》，在发布OCI镜像格式的1.0版本之前还保留两个候选版本。
同时，Docker继续增强其容器引擎，将特征联系起来，比如其Swarm 调度框架和服务发现。
“我觉得一切都好，”他说，“当然可能有人不喜欢，但没关系，每个人都可以有自己的意见。Kubernetes——我们也提供一堆东西。但我们更相信我们是在做一些商品之上的东西”
Kubernetes 及展望
“要正确实现我们所说的pod，需要了解很多事情，” Hightower解释道，“把负担分解到每个容器运行时的做法对这些容器运行时来说是不公平的，想要玩一玩Kubernetes还必须实现那么多代码。这样想吧：他们还要为了Mesos、Swarm等等分别再做一些不同的事。为了简化，我们将把Kubernetes特有的逻辑保存在kubelet内部，而在外部，我们只会用到本地容器运行时已有的东西。”假设真的实现了一个能理解当前容器化语言的接口，能够抽象出面向pod、基于kubelet的逻辑，而相同的API可以和Kubernetes之外的东西对接时，可以以不同的方式抽象出自己的逻辑。
我们和Mesosphere的创始人 Ben Hindman 探讨了这种可能性。
“我觉得行业真正在探寻的东西，是可以被灵活操作的部件，” Hindman 向 The New Stack解释道，“我认为，以Kubernetes为例，这非常关键。Kubernetes以往是依赖于Docker去做容器管理的，他们也曾尝试去构建调度。Docker并入了Swarm之后，他们就有了一个可以用来做调度的容器管理器。所以单从构架和工程师的角度，我会说‘我们要是有一个做容器管理的组件就好了……这样可能有成倍的人来使用’”。
Hindman相信Docker是很想把 runc 作为开放标准的。但调度需要的不仅仅是和运行时进行交互操作。
“还有更多的相关的东西。下载镜像、打开镜像——要做的还有很多。我认为行业中曾被广泛探讨的是，这些东西是不是应该被分解和模块化？怎么做才能在构架层面上更有意义，而不是针对一次fork。” -Ben Hindman，MesosphereHindman解释说，Mesosphere的DC/OS 环境中也有这种组件，它们已经能够脱离对 runc 和Docker组件的依赖。这如他所说，容器社区真正要追求的目标，是确定组件之间的架构界限，并在其中建立良好的接口。
这是否意味着Mesosphere支持CRI-O，其目标——正如Kelsey Hightower所说——和Hindman之前所说的完全一致。
尽管Hindman并不代表OCI，但必须注意到Mesosphere是OCI的创始成员之一。正如Hindman回应的，OCI的初衷是发展一种常规运行时模式，并使 runc 可以将其作为一个容器来打开。容器化社区也十分关心镜像格式问题，其中包括容器rest状态时的文件系统和元数据。OCI也十分认同上文中的目标， Hindman表示，“其实，这比运行时格式更吸引我们。”
式。
至于Mesosphere为什么着手去做所谓的“ 万能容器 ”，Hindman继续说道，“是为了生产面向所有开放格式的容器，包括OCI。”
Hindman说，但在这最佳的构架下，可能并没有标准化的调度工作负载的方式，因为调度任务特征的差异性太大。因此，之前为了实现任何调度器都可以部署和打开，而去寻找单一配置文件、元数据文件或者描述工作负载的努力，也随着Hindman所谓“最低共同标准规范”而终止，该“规范”拥有功能集更为广泛的调度器。
而决定通用的镜像格式，相比之下就简单多了。它归结于Linux是否支持该格式。“如果Linux支持，我们就公开该标准。我认为大家不会在镜像格式的问题上有太多争议，因此，把它当做标准是完全没问题的。”
Mesosphere将继续支持OCI（ 或者叫“OCID” ），Hindman总结说，也会根据支持OCI的程度继续支持CRI-O。但是Mesosphere的“通用容器运行时”会以不同的方式进行这项支持。
市场将会变得更具竞争力，彼时市场的主角将会是调度框架，而不是被调度的内容。
原文链接：How CRI-O Would Put Kubernetes at the Center of the Container Ecosystem
（翻译：马远征）
原文发布时间为：2016-10-22
本文作者：马远征
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：CRI-O将如何把Kubernetes推上容器生态系统的中心位置
