Docker和rkt快别争了，kubernetes(k8s)才是容器生态的中心

开源项目 CRI-O，其前身为OCID，官方简介是“OCI-based implementation of Kubernetes Container Runtime Interface”。作为接口，它使得Kubernetes 不依赖于传统的容器引擎（比如Docker），也能够管理容器化工作负载。

该项目通过与Kubernetes（或其商业版CoreOS Tectonic）协作，可以帮助DevOps人员来管理容器的整个“生命周期”。

开发人员需要使用容器引擎构建镜像，通常情况下更喜欢用自己的staging 环境做本地测试。但是管理和运营人员会发现，相对于标准容器引擎， Kubernetes技术栈（比如编排系统、CRI和CRI-O）更适合用来管理复杂的生产环境。

该项目将编排工具放在容器技术栈的重要位置，同时降低了容器引擎的重要性。CRI 的一个Contributor说，让Kubernetes支持任意容器引擎，在理念上与Open Container Initiative一脉相承。容器引擎可以是docker或CoreOS的rkt，或OCI 的 runc（它可以做很多如Docker 或 CoreOS  rkt 这类容器可以做的事情，比如从registry拉镜像，但它不会从makefile构建镜像）。

CRI-O 是什么？

「  尽管 Open Container Initiative 类似的部分已经与 CRI-O的职责区别越来越大，两个项目的成员、贡献者和厂商也有很大重合，但CRI-O 仍然是OCI的自然延伸，它为容器引擎和镜像提供了一套标准接口。」，Kubernetes 工程师Kelsey Hightower 在The New Stack 的采访中说道。

CRI-O 项目的设想是用户不应该依赖任何特定的容器引擎去完成工作负载。按照最初的设想，该项目将为 Kubernetes提供一个工具集，使其能够管理容器的整个生命周期，而不需要Docker、rkt、OpenShift、Photon 或任何其他容器引擎。

「 我们对容器引擎的功能要求很少，不管是Docker还是rkt，它们要做的工作都很少 」，Hightower说，「 我们需要的是访问内核的API，不仅仅针对Linux，也可以是Windows。如果这是社区想要去的方向，Kubernetes就要支持这些想法-因为在这一点上它比Docker公司更大 」。

在这一假设之下，是一个新奇的观点：编排才是容器生态的中心，而“引擎”就我们所知，只是一个开发工具。

另一方面，CRI（通用容器接口API和Kubernetes）将给容器引擎厂商一个机会，以便接入Kubernetes系统。运行容器的环境中，只要暴露出适当的连接，不需要容器引擎进行代码重构就可以兼容Kubernetes。

其中一个方式是，在容器引擎和编排工具中间实现一个抽象层，容器厂商如何实现这一层完全取决于他们自己。

容器引擎中间层实现以后，CRI  API（与Kubernetes连接的部分）将把更多的容器生命周期控制权交给kubelet —— pod的管理者。Pod是Kubernetes 特有的概念，但容器生态系统必须采用这个概念。

对于Kubernetes，下一个版本的目标是1.5版本，包括CRI的最终版，允许kubelet 与Docker，rkt、Hyper.sh（中国团队开发）以及CRI-O（RedHat领导开发）进行通信。

“关于如何与Kubernetes 通信，很多不同的容器引擎都非常感兴趣”，Philips说，“与其在kubelet中为每一个容器引擎构建一个接口，我们创造了一个更抽象的接口，允许容器引擎去接入而不用直接参与Kubernetes 的工作。”

谁需要重构，重构什么？

Hightower 将CRI（“CRI”在“CRI-O”之前）描述为一个抽象的概念，代表容器引擎应该支持的基本特性，而Kubernetes可以用来验证这些特性。一旦CRI完成，将重构Kubernetes代码以实现CRI。

如果CRI-O成功，容器引擎厂商不需要对引擎代码库进行修改，就可以简单地与Kubernetes交互。

“现在，如果你想很happy地玩耍Kubernetes，必须构建一堆东西，而且可能修改你目前的做事方式”，Hightower 说，“你查看现有的代码库，看看为Docker做了哪些东西。在某种程度上，你需要付出类似的努力，去修改适合你的运行时引擎，从而与Kubernetes很好的配合。”

就像 CoreOS的Philips 解释的一样，每个容器引擎将利用一个中间层—— 它能够将容器引擎的 API请求，转化成Kubernetes可以处理的形式。

“考虑到CRI的运行机制，你需要一个GRPC daemon 去监听请求”，Philips说，“它能与kubelet 通信；反过来，kubelet 可以通过socket对实现CRI的引擎发送一个远程调用”。

Philips说，“目前对Docker和rkt的支持将被合并到CRI接口”。 CoreOS rkt 对CRI的实现目前已经在Github上开源，项目名称为rktlet。不管是rktlet，还是Docker对CRI的实现（不管将来叫什么名字），他预计都被重构为CRI。

Google 的Hightower 说：“尽管Docker已经要求与Kubernetes 一起实现中间层，最终仍然是Google 的工程师去实现，而不是Docker的。Philips也表示，不管谁去实现中间层，Docker和其它容器引擎厂商遵循同样的规则，都不能搞特权。

“为了与CRI集成，Docker Engine和 rkt Engine都处在不断变化中”，Brandon Philips如是说。

OCI镜像格式的最终标准还没有确定，OCI发言人也表明OCI镜像格式1.0 发布之前还有两个迭代版本。

同时，Docker 在不断增强其容器引擎的特性，并且捆绑了Swarm 编排工具和服务发现。

“我认为这一切进展都不错，”Philips说，“人们可能不喜欢这样——这很正常，每个人都可以有自己的观点。对于Kubernetes ，我们仍然会提供一包东西。但我们在创造和改进它时，不认为它仅仅是一件商品（还有情怀）。

超越Kubernetes

“前面我们谈到Pod，为了正确地实现它，你还需要了解很多东西”，Hightower 说，“把负担推给容器引擎，让它们去写一拖代码才能与kubernetes愉快地玩耍，这一点对于每个容器引擎都很不公平。想想看：他们还要为Mesos和Swarm去实现类似功能的代码，想想都可怕。为了简化这部分功能，我们将把Kubernetes专属的逻辑放到kubelet中；对于外部而言，通过一种友好的方式使用容器引擎本来就具备的特性。

假设这已经是事实，现有容器引擎特性被隐藏在一个接口后面，该接口能够将pod为中心基于kubelet 的逻辑从kubernetes 隔离出来，与Kubernetes之外但有同样API的编排工具交互，这个编排工具对API可能有一套完全不同的实现方式（饼越来越大）。

我们和Mesosphere 创始人Ben Hindman 也探讨了这种可能性。

“我认为这个行业需要的是可拼凑的组件”，Hindman 对The New Stack 解释说。“在Kubernetes 案例中，我认为这很关键。Kubernetes依靠Docker做容器管理，并且他们尝试构建编排。当Docker整合Swarm时，他们不仅有一个容器管理器，也在做编排。仅仅从架构的角度来看，这是非常合理的。我想说的是：如果我们只做一个容器管理的组件，让很多人可以利用，岂不是很更好？”

对于 Docker公司有意向将runc作为开放标准，Hindman非常认同，但他也不忘吐槽：完整的编排不仅仅是与与容器引擎交互。

“还有很多，比如下载镜像、镜像打包、镜像解包 —— 还有更多的事情必须去做。

对我来说，我认为行业中还在就一个问题争论：这些东西应不应该被分解和模块化？它不仅仅是 fork the repo 那么简单，还需要在架构上解释得通。”[ Ben Hindman ]，

Mesosphere 的 DC/OS环境中也有这些组件做铺垫，Hindman 解释说，已经无需依赖 runc 或任何Docker 组件。容器社区的真正目标，正如他所说的，是在组件之间指定架构层面上的边界，并建立它们之间建立适当的接口。

这是否意味着Mesosphere支持 CRI-O，CRI-O的目标也如Kelsey Hightower向我们解释的一样，与Hindman 预计的完全兼容吗？

然而Hindman并不是为 OCI呐喊，需要注意的是，Mesosphere 是OCI的创始成员之一。 OCI的最初的目的是开发一种通用的运行时格式，让runc 能够以容器的方式启动它。容器社区也关心镜像格式，包括容器在非运行状态下的文件系统和元数据。所以OCI也接受这套理念。

“对于我们而言，镜像格式比运行时格式更有趣，也有意义” ，Hindman 说，“Mesosphere 之所以拥抱 universal containerizer，原因是希望支持所有开放格式的容器，包括OCI。”

但在这样一个最佳架构中，可能没有方法去规范工作负载的调度器。不同调度器的特性可能千差万别。因此，如果以这种方式，努力通过一个文件描述工作负载（可能是配置文件、元数据文件或manifest文件），并且试图对所有调度器通用，最终制定出来的标准可能满足不了任何调度器的需求，进而妨碍调度器本身特性的扩展。

但是，确定一个通用镜像格式则简单很多，最终取决于 Linux 是否支持该格式。“如果支持它，我们可以公开它。在镜像格式上，我认为没有太大的争论，因此，把它作为一个标准就OK。”

Hindman 总结说，Mesosphere 将继续支持OCI，将来会以同样的粒度支持CRI-O。但跟CRI-O相比，Mesosphere 的“universal container runtime”将以不同的方式被支持。

未来在编排领域，我们会看到一个激烈竞争的市场，而不是容器引擎领域。