容器的战争
Red Hat和谷歌联合：让Kubernetes无需Docker即可运行容器。
2015年，旨在为容器制定行业标准的开放容器计划（OCI）成立，该组织使用Docker的容器运行时环境和镜像格式作为基础。而现在，许多公司在开展一个项目，要将把OCI堆栈的重心由Docker改为Kubernetes，后者是谷歌的开源容器编排引擎。
这个新项目面向Kubernetes。它将直接与Kubernetes容器仓（pod）进行联系。它将让Kubernetes、而不是Docker能够启动并管理大规模容器。
丹·沃尔什（Dan Walsh）长期以来是SELinux的项目主管，也是Red Hat的咨询工程师。他在接受The New Stack采访时说：“我们想要的是一种可以被Kubernetes使用的守护进程（daemon），用来运行存储在Docker注册中心上的容器镜像。”Red Hat和谷歌的开发人员积极领导这个项目，该项目现在名为OCID（OCI守护进程）。沃尔什继续说：“为此，我们想构建一系列库，以便能够方便运行这些容器镜像。”
该项目的维护人员坚称，OCID不是“Docker分支”，不过这个项目俨然证明了容器生态系统出现了分裂，尤其是由于Kubernetes在容器市场继续受到追捧。
今年早些时候，Docker公司将自家的业务编排引擎Docker Swarm作为Docker引擎的一部分，而Docker引擎本身又是Docker版本1.12的一部分。因而，Docker引擎现在让用户无需额外软件，就可以管理复杂的容器化应用程序。Docker编排功能是选择加入的功能，它们必须由用户来激活，不过许多人担心：不选择加入可能导致将来出现向后兼容性问题。
Docker将Swarm添加到Docker引擎，这一举措给原本存在分歧的社区增添了摩擦。8月下旬，厂商和用户饶有兴趣地谈论Docker会不会出现分支。开发人员公开抨击了Docker激进的发布时间表、以及这如何让第三方系统提供商与各自的客户群产生分歧。
目前，Red Hat的工程师在OCID项目方面身先士卒，这个项目于今年6月正式启动。它是作为Kubernetes孵化器计划的一部分开发的，该计划支持反过来支持Kubernetes的项目。首席维护者是谷歌的维什奴·卡纳安（Vishnu Kannan）和Red Hat的姆鲁纳尔·帕特尔（Mrunal Patel）。
谷歌专职的开发者大使凯尔西·海托华（Kelsey Hightower）说：“我们其实不需要从任何容器运行时环境得到太多，无论这种运行时环境是Docker还是CoreOS的rkt――它们只需要做很少的事情，主要是给我们连接内核的API。所以这不仅仅涉及Linux。我们有可能在Windows系统上......如果那是社区想要前进的方向，就要支持这些想法。因为目前它比Docker公司来得庞大。问题是，你如何运行容器化的应用程序？”
首当其冲
正如一些人认为的那样，如果OCID确实成为容器引擎的参考实现，它将提供一种免费开源的选择，用于运行大规模OCI容器。它将包括runc，这是基于libcontainer的容器运行时环境――Docker将libcontainer捐赠给了OCI，用作一种免费标准。它还包括将镜像推送到容器注册中心托管的资源库，并从中提取镜像所必要的代码。它将支持由CoreOS开发的容器网络接口，该网络接口可用于独立于托管容器的引擎来构建插件。
不过，名为oci-runtime的组件是OCID存在的理由。正如GitHub上的项目页面描述的那样：“这是Kubernetes容器运行时环境接口（CRI）的实现，让Kubernetes可以直接启动和管理开放容器计划（OCI）容器。”
凯尔西·海托华解释，OCI不仅需要指定如何运行容器，还要指定如何下载和联网容器，为人们提供可以实际使用的东西。
在Kubernetes环境下，有一个名为kubelet的组件专门用来管理容器仓――容器仓是通常组成应用程序的容器集群。kubelet能够充当独立的守护进程，对容器仓中的容器来说这是一种本地监管程序。作为OCID的关键项目，oci-runtime 将在kubelet和kubernetes之间实施一类新的接口，让编排器能够有效地管理容器的整个生命周期。
谷歌的海托华说：“我们现在想要做的是重构kubelet代码库，那样我们与Docker、rkt以及现在的OCID整合起来的方式整洁得多、一致得多。我们想要提供一种定义明确的接口，为了容器运行时环境引擎符合Kubernetes，我们就要有容器运行时环境接口（CRI）。CRI将是通过API抽取容器运行时环境需要支持的内容的一种机制，以便我们将它视作可以在Kubernetes下运行的对象。”
填补空白
OCID听起来像是一种全新的、功能齐全的容器引擎，实则不然。尽管到目前为止它已被描述了有怎样的特点，但有一个非常重要的方面被遗漏了。
Red Hat的沃尔什说：“眼下，实现的OCID并不能构建OCI镜像。你压根儿无法构建镜像......你仍需要Docker之类的工具用于构建OCI镜像――这基本上就是Docker镜像。”
乔·费尔南德斯（Joe Fernandes）是Red Hat的OpenShift产品管理高级主管，OpenShift是Red Hat的商用编排引擎，基于Kubernetes。他说：“我们的目标――我认为，整个业界的目标――是，拥有容器运行时环境的标准实现，以及用于构建容器镜像的一种标准格式，那样不同厂商可以在上面构建不同的解决方案，生态系统就能不断壮大。”
费尔南德斯解释，Docker镜像格式为开发生态系统确立了共同基础。他认为发布作为标准的这种格式是OCI工作的一部分。
他说：“一旦你有了这种格式，之后问题归结为运行时环境。一些人认为，Docker贡献libcontainer（后来成为runc）后，它就是运行时环境。它是运行时环境的一部分，是最低层的部分。但是其他这些模块也构成运行时环境。所以，我们在这方面做的就是为这些模块构建标准实现。”
去年12月，这似乎确实是真实的，因为早前的演示幻灯片似乎坚定地表明：OCI的重点将仅限于容器运行时环境（runc）和容器镜像格式。
但是Red Hat的开发人员在谷歌开发人员的帮助下，可能在扩展“容器运行时环境”的定义。费尔南德斯解释，这是一种广泛得多的实现的基础层。正如海托华解释的那样，根据定义，它包括编排器组件的接口（眼下是Kubernetes），但从理论上来说并不仅限于Kubernetes，假设其他任何编排器想要获得同一个API、与它一起运行。
海托华解释：“OCID其实是OCI的自然进化。其目的是指定Docker当初方面的一些标准；其想法是，我们拿来应用程序后，包装成镜像格式，然后放到资源库上，并与大家共享。而一旦它们被共享，就可以很一致地获取、提取和运行镜像。”
海托华解释，为了做到这一点，OCI不仅需要指定如何运行容器，还要指定如何下载和联网容器，为人们提供可以实际使用的东西。
他继续说：“如果它们要成为一堆文档和库，不妨为人们提供我认为许多方面可与Docker本身相当的东西，完全专注于我刚才提到的那些部分。那样一来，这可以少点OCI的神秘色彩；现在你将有一种全面指定、整合的东西，实际上可以应用于其中一些项目。”
OCID的主要组件之一是skopeo，这种工具用于验证和获取来自Docker资源库的容器镜像，如今它是Red Hat为Docker本身贡献的重要技术之一。
沃尔什解释，skopeo最初是作为一种工具而开发的，它可以检查容器镜像，生成的JSON文件可以用作清单文件（manifest）。这个工具后来被用于从Docker注册中心拉取和推送镜像。后来，Red Hat将它作为Project Atomic的一部分，基于GO库的衍生版现在作为容器/镜像出现在GitHub上。
沃尔什表示，除了skopeo外，OCID项目包括一种写时拷贝（copy-on-write）文件系统，该文件系统基于名为图形驱动程序（graph driver）的Docker组件。
他告诉我们：“我们在几个月前开始致力于拆分写时拷贝文件系统，那样除了Docker外的其他工具可以共享它。我们实际上发现很难继续在Docker底下工作、获得这个独立的模块，于是我们决定把它取出来，致力于让模块完全正确。但愿在某个时候，我们会提出合并请求，让这个部分回到Docker里面。”
他表示，在此期间，当前形式的库还作为容器/存储出现在GitHub上。沃尔什指出，虽然Docker确实有自己的写时拷贝文件系统，但它完全在自己的专属内存中运行。
“我们使用的共享式库与OCID使用的一样。我们很乐意看到其中一些库进入到rkt的未来版本，我们其实想看到它们回到Docker……我们对于存储想做的事情是，把文件系统存储的锁改为文件锁，那样多个应用程序可以同时共享存储。我们很想在某个时候让这回到Docker守护进程中。”
动机
作为一个发展中的项目，OCID如今的某些组件在将来不复存在，反过来现在不存在的组件将来会出现。让人奇怪的是，OCID至少今天没有的一个组件就是专门运行OCI容器的机制。帕特尔表示，OCID也不会属于OCI项目的范围之内，用于证明容器符合OCI。帕特尔和卡纳安共同撰写的说明文档（https://github.com/mrunalp/kubernetes/blob/dce95c8a7564a973d5699fc7386c39dc417bfd8d/docs/proposals/kubelet-oci-runtime.md）明确呼吁灵活地支持容器格式，包括随着OCI的发展，继续支持Docker，还要支持日常的TAR文件。
正如乔·费尔南德斯提醒我们，Docker最初是一种完整的容器系统，在前几个月（它仍然是非常新兴的产品），变得更加模块化――runc是那些模块之一。虽然runc的前身旨在被拉入到Docker引擎中，但如今runc可以同样轻松地被拉入到CoreOS的rkt中。
费尔南德斯解释：“你可以同样来看待OCID。这里还有其他模块是我们想要构建、让它们成为标准的……我们想与Docker社区合作，该社区可以把这些拉回进来，因为它们是标准接口――而不是有一种整体式架构，把一切都结合起来。那是UNIX的整个理念，即“把一件事做好”。我们设立OCID项目是为了开展这项工作――测试这些想法，并提供标准实现，可以推回到OCI中，然后最终被拉入到不同的实现中，而Docker是那种明显的实现。”
正如费尔南德斯和沃尔什所说，忽略为OCID构建容器镜像的“引擎”组件是有意为之。他们一致认为，正是在引擎方面，Red Hat、Docker、CoreOS和VMware等厂商可以致力于各自的“增值服务”，并与对方在价值和服务方面展开竞争。
然而写这篇文章时，GitHub上的开源说明文档中仍有两个措辞非常奇怪的部分。
首先，kubelet接口的项目页面上出现了这段描述：“就第一个版本而言，oci-runtime将继续使用Docker引擎来管理镜像。镜像管理功能将与运行时功能分离开来，那样各自可以有不同的实现，因而最终可以切换。一旦迎来v1.0，最好为镜像支持OCI镜像规范。”
这番说明可以解读为表明：运行时环境组件将依靠Docker代码来支持，至少在最初几轮是这样，但是它也为OCID使用其他引擎创造了条件，因为减弱了对Docker引擎本身的依赖。
第二段同样好奇的内容是OCID说明文档中将OCID连接到谷歌的钩子（hook）：具体来说，其明确的自我声明作为Kubernetes环境的一部分。OCID直接声明目的就是，为Kubernetes的容器仓中的成员提供管理――而这种声明优先于容器管理。
谷歌的海托华认为，Kubernetes已在容器社区赢得一席之地：也许可以称之为公平的仲裁者。
他说：“这主要是为了确保竞争环境公平。眼下，Docker是得到最有力支持的容器运行时环境，因为我们谷歌和社区已做了大部分工作，让Docker成为一流的运行时环境。但由于我们看到大家想要选择，支持多种容器运行时环境是我们的愿景，开发这种容器运行时环境接口是往这方面迈出的一步。作为其中的一部分，我们会重构当前的代码库来实现[CRI]。”
独一性
然而，CRI要像海托华解释的那样工作，就需要某一种组件，这种组件直指围绕Docker爆发的第一个争论的核心：具体来说，能够启动自己的系统容器。这种组件实际上又让systemd浮出了水面，systemd是Linux如今偏爱的应用程序初始化机制。
Red Hat的沃尔什解释：“我们希望以容器这种形式来交付一切，所以需要一种不使用编排的容器运行时环境，因为编排需要它。所以，我们面临先有鸡还是先有蛋的情形。通过使用系统容器，我们能够使用容器/镜像库来拉取镜像，能够把它存储在容器/存储上，然后我们会执行runc，但是在这种情况下，我们将它把作为systemd的一部分来运行。”
沃尔什认为，这是容器化的环境可以在生产环境中启动自己、反过来启动Kubernetes的一种方式。
毫无疑问，在投入运作的头一年，OCI的范围已有所扩大。一开始有人谈论：一旦容器格式规范发布，OCI的工作就算完成。现在，我们看到两个最抢眼的成员在推崇一种开放的写时拷贝文件系统系统、一种开放的注册中心维护库、一种网络方案，以及依赖Docker更宁愿废弃的一种架构特性的引导机制。容器安全库会远远落在后面吗？
重要的组件（容器引擎本身）将是留给每个数据中心要为自己解决的事情。在这方面，Docker可能拥有早期优势，毕竟它开辟了这个市场。但是它可能发现自己在与Red Hat帮助开发的OpenShift正面竞争。
“我要说，OCID会被Kubernetes使用。我们的目标是，在OpenShift环境中，让Kubernetes使用OCID，作为其容器运行时环境。然后，OpenShift将使用Kubernetes，那样我们就会得到OCID的优势。”
所以，如果你在将来要使用Kubernetes，就需要有OCID，这是为你做出的决策。
云头条编译｜未经授权谢绝转载
相关阅读：
微软聘请谷歌的首席Kubernetes工程师，加强Azure中对容器编排的支持
OpenStack和Docker不能，Kubernetes和Mesos也不能，ServerLess能决定云计算胜负吗？
为什么说Kubernetes对亚马逊构成的威胁可能比谷歌云还要大？｜「云头条」
OpenStack的未来：Docker工作负载在Kubernetes上运行
