CoreOS Fest 系列之第一篇：容器江湖

【编者的话】 这是总结 CoreOS Fest 大会的三篇文章之一，主要介绍了 CoreOS 公司与 Docker 公司之争，新成立的 appc 规范委员会， Tectonic 平台， Kubernetes 项目。

最近在旧金山， Linux 容器已经显得非常有「钱」景，看起来每个人都想从这个有几十亿美金规模的新市场中分得一杯羹。多家创业公司和云主机公司已经或者即将召开有关容器的大会，包括 4 月 17 日召开的 Container Camp 、5 月 5 号和 6 号召开的 CoreOS Fest 以及即将于 6 月底召开的 DockerCon 。暂且不论其中大肆炒作的成分，容器的这股淘金热为用户带来好处的同时，也让用户疲于跟踪快速发展的容器技术。

容器在创业公司中有多流行，看看 CoreOS Fest 就知道了。虽然这次大会准备了有六个月之久，又在旧金山 Tenderloin 的 The Village 召开，会场的设施一般，但 300 张门票很轻松就卖光了。因此，我预感 DockerCon 的参会人数会更多。根据演讲者的提问， CoreOS Fest 的参会人员主要是系统管理员和专门的 DevOps 人员。

从 CoreOS Fest 大会，我们可以了解容器领域的新进展： CoreOS 公司获得新投资，新成立一个应用容器规范委员会， CoreOS 发布 Tectonic 平台， Kubernetes ，有关数据库容器的新工具和技术，集成 systemd ， Calico 项目， Sysdig ，还有很多很多。我们将用三篇文章，详细讨论这些内容。这是第一篇，先聊聊硅谷政治—— CoreOS 公司和 Docker 公司之争。

译者注：原文用 Docker 和 CoreOS 分别代表相应的开源软件项目，用 Docker Inc. 和 CoreOS Inc. 分别代表 Docker 公司和 CoreOS 公司。译文的处理有所不同，用 docker 和 CoreOS 代表相应的开源项目，而在表示相应的公司时，分别使用 「Docker 公司」和 「CoreOS 公司」。

CoreOS 公司和 Docker 公司之争，焦点是容器编排

CoreOS 公司曾经是 Docker 公司的强大伙伴。从 CoreOS Fest 召开之日往前推六个月，两家公司彻底分道扬镳，彼时 CoreOS 公司推出了与 docker 竞争的容器平台 rkt （刚开始叫 rocket ）。围绕两家公司的用户和资本之争也白热化了。先是 4 月 14 号， Docker 公司获得了 D 轮 9,500 万美金投资；就在同一个星期， CoreOS 公司也宣布获得 1,200 万美金投资，投资方中包括著名的 Google Ventures 。

这次大会表明，这两家公司的决裂令人感到奇怪。你看，做主题演讲的会议室里， 80% 的人都是 docker 用户，本次大会上介绍的大部分技术也都同时支持 docker 。然而，几乎没有人在演讲时提到 「docker」 这个词，有位演讲者甚至用 「the D world」指代 「docker」 。

两家公司竞争的焦点集中在容器编排平台上。编排平台提供了一套工具，用来部署和管理大量的容器，把这些容器联网，共同组成一个以容器为基础的软件基础设施。 Linux 容器本身非常适合用作开发平台，如果以容器为基础构建整个软件栈，还需要提供几类编排工具，包括：

• 容器调度器：把容器部署到物理服务器上；
• 集群信息存储：容器数据的共享和协调；
• 软件定义网络：容器联网；
• 资源管理和监控等。

容器领域的所有公司好像都把编排作为自己产品与众不同的关键点，希望凭借这一点建立影响和寻求回报。除了 CoreOS 公司和 Docker 公司， Red Hat 公司的 Project Atomic 、 Ubuntu 的 Snappy Core 、 Joyent 公司的 Triton 和 Apache Mesos 项目 都是容器编排领域强有力的竞争者。尤其值得注意的是， Microsoft 公司宣布： 2016 年， Windows Server 和 .net 用户将可以使用 Windows 容器 。

或许是由于这种竞争的激烈程度， 与以往的 CoreOS Meetup 相比， CoreOS Fest 着重讨论了容器的安全性。去年 12 月， CoreOS 公司与 Docker 公司决裂时，它主要批评了 docker 容器的访问控制比较弱，缺乏其它的安全度量。

新成立的应用容器规范委员会

应用容器（ Application Container, appc ）规范 小组特别重视安全。去年 12 月， appc 规范 0.1 版发布，它描述了应用容器镜像（ Application Container Image, ACI）所需的属性。 CoreOS 公司开发的 rkt 是 appc 规范的一个实现， 这篇文章 有更详细的描述。

上图： appc 规范小组成员（从左到右）： Aylward, Robertson, Hockin, Boulle, Batts 和 Philips

在讨论新特性之前， CoreOS 公司 CEO Alex Polvi 提醒观众注意： appc 规范的安全部分仍在制定当中。他说：「要把这些事情做对，有时候就得花些时间」。随后，他介绍了 appc 规范小组的成员： Red Hat 的 Vincent Batts ， Google 的 Tim Hockin ， Twitter 的 Charles Aylward ， CoreOS 公司的 Brandon Philips 和 Jonathan Boulle ， 以及 Apcera 的 Ken Robertson 。除了 Ken Robertson 之外，其他成员同时也是 appc 规范委员会的成员，委员会负责管理 appc 规范的社区。

这是那天早上宣布的两个重磅消息之一： CoreOS 制定了 appc 规范的治理和贡献策略 ，把 appc 规范项目移交给由 维护者 组成的委员会。虽然委员会不是基金会或者其它形式的法人团体，鉴于大部分委员会成员并不是 CoreOS 公司的员工，这种移交体现了保证 appc 规范真正独立性的决心。Polvi说：「应用容器规范应该像 HTML5 那样。共享的标准，辅之以竞争，能创造出更好的产品」。

规范小组的每个成员代表各自的公司，发表了对 appc 的看法。

当 appc 项目问世之际， Apcera 正在开发自己的闭源的容器技术。随后， Apcera 迅速跟进，使得自己的容器技术符合应用容器规范草案。 Robertson 说：「当我们看到 rkt 发布了，心想：糟糕，必须得构建一层抽象了」。他还宣布发布 Kuerma ， 这是一种可引导的容器基础设施，完全兼容符合 appc 规范的容器。

Aylward 说， Twitter 已经有很多基础设施，不适合直接应用 docker 。而 rkt 和 appc 更方便与企业已有基础设施集成。 Hockin 指出， Google 希望构建它的大规模私有容器平台的开源版本。为此， Google 与 CoreOS 公司建立紧密的联系。 Hockin 说：「作为 Google 的一员，我感兴趣的是构建大教堂，但是在此之前，你必须打好地基」。

译者注：这里的大教堂指的是开源软件开发模式，详情请参考著名的文章： 大教堂与市集 。

Batts 的表述更中立，他说 Red Hat 之所以对 appc 规范感兴趣是为了标准化和保证用户的选择权。鉴于 Red Hat 的 Project Atomic 项目与 docker 的紧密联系，很容易理解 Red Hat 所持的中立立场。这种立场就是「找出共识，缩小分歧」。

一旦远离了企业之间的斗争，小组成员们开始讨论 appc 规范的现状，首先的议题是主要挑战和请求的新特性，例如，加密服务发现；更好的 ACI 校验器；为了加强容器的安全性，限制更多的容器内部的系统调用等。不过，最大的挑战是 appc 0.5 的描述仍然流于空泛， rkt 团队经常不得不停下实现的工作，因为需要反复争论规范的内容，以求达成一致。

「不提供实现，你也能编写一个规范，但是这样你就搞不清楚这个规范能否构建成功。所以，规范和实现必须齐头并进」， Aylward 如是说。

委员会一致同意 appc 规范项目的主要目标是： 成为容器镜像的参考格式。开发者首先构建 appc 格式的容器镜像，然后再用这些镜像创建所需的各种软件包。委员会成员之间也存在分歧。例如， CoreOS 公司用 systemd 启动和初始化容器，而 Google 不使用 systemd 。规范中应该包含多大程度的容器隔离， Hockin 与其他成员对此的的看法相左。他认为，通过区分 通用规范 和 与具体操作系统相关的规范 ， appc 最终会包含一个完整的应用程序二进制接口（ Application Binary Interface, ABI ），这能为容器运行时提供完全的隔离。 Hockin 说：「众所周知，容器并不是一种安全屏障。需要由内而外逐步发展，才能够提高安全性」。

Tectonic

另一个重磅消息是发布了 Tectonic 平台 ，集成 CoreOS 公司自身的产品和 Google 公司的 Kubernetes 项目（参见下一小节，以下简称为 K8S ）。其中， CoreOS 公司的产品包括 CoreOS Linux ， 容器部署工具 fleet ，集群化数据存储 etcd ，虚拟联网系统 flannel ，镜像存储库 Quay.io 。 Tectonic 提供了一个对用户友好的集成平台，支持大规模容器的编排。 Polvi 称之为「人人都可以拥有 Google 那样的基础设施」（ Google's infrastructure for everyone else, or GIFEE ）。

Tectonic 是私有的商业化软件， CoreOS 准备把它卖给愿意购买容器编排完整解决方案（包括出色的图形界面）的客户。在 Tectonic 的组件中，除了图形界面，其它所有工具都是开源的。尽管如此，由于这些工具都比较新，相互之间的交互也很复杂，想要自己使用这些工具实现容器编排，仍然相当困难。

看起来， CoreOS 公司的 fleet 和 flannel 工具与 K8S 存在重复甚至相互冲突的功能。但是在 Tectonic 中，这些软件是互为补充的。 CoreOS 公司的 Kelsey Hightower 说，在 Tectonic 中， fleet 用于启动和监控 K8S 。如果不用 fleet ，这个过程需要很多手工配置。 flannel 建立了覆盖（ overlay ）网络系统，能够支撑 K8S 的服务发现功能。

在产品演示环节， Intel 、Supermicro 和数据中心供应商 Redapt 共同宣布了一种 预先配置好的 Tectonic 软硬件解决方案 。在本次大会上，这几家公司展示了一种立等可用、即插即用的容器基础设施方案：用占 1/4 机架的服务器运行 Tectonic 测试版。此外，也可以在 AWS EC2 上运行 Tectonic 测试版。

Kubernetes

在 CoreOS 大会上，除了 CoreOS 公司的标志， K8S 项目的舵轮标志也随处可见。 Google 员工 Brendan Burns 是 K8S 项目 负责人的，他解释了什么是 K8S ， K8S 的工作原理，以及 K8S 与 CoreOS 和容器的关系。

演讲伊始，他把运维分为四层：应用程序运维、集群运维、内核运维和硬件运维。 K8S 位于集群运维层，它把多台服务器同步成为「一台统一的计算机」，实现了应用需求和硬件的解耦。实际上，公有云的主要作用也是实现了这种解耦。

开发者通过 K8S 的 API 服务器与之交互，包括命令行接口和基于 JavaScript 的 web API 。K8S 的所有数据都保存在 etcd 中。 用户只需指定 K8S 系统的状态， K8S 就能让系统的实际状态变成与用户期望一致的状态。这种使用方法叫做声明式使用方法，配置管理系统 puppet 也是这么用的。例如，用户要求「运行不多不少 3 个 Redis 服务器」， K8S 会关掉多余的服务器或者启动新的服务器，使得系统中正在运行的 Redis 服务器恰好只有 3 个。

在 K8S 中，调度是指把容器部署在服务器上，提供满足用户请求的服务。调度的原子单元是 「pod」 ，由容器、网络和数据卷组成。为什么要引入 pod 的概念呢？有的服务包含多个组件，如果不把这些组件部署在同一台物理服务器上，这项服务将无法正常运行，数据库服务及其文件存储就是一个例子。 K8S 把这些组件封装为一个 pod ，作为一个部署单元，这就能保证服务的正常运行。

服务发现是 K8S 的另外一项重大功能。应用程序开发者通过服务代理访问所需的服务，无需知道提供服务的那些容器具体位于网络何处。这怎么实现的呢？为每个 pod 和容器添加「标签」，每个标签表示该容器提供的一种服务。具有相同标签的多个 pod ，相互可以替代—— K8S 把负载平均分到这些 pod 上，从而实现了负载均衡。

根据我公司的简单试用，与其它编排框架相比，感觉 K8S 的功能更全面、整体上更成熟。我们比较的框架包括 CoreOS 公司的 fleet ， Apache Mesos 以及 Docker 公司的 Swarm 和 Machine 。考虑到 K8S 是 Google 运行在生产环境中的编排软件的移植，有上面的比较结果也不出奇。

K8S 真正需要的唯一一个 CoreOS 软件是 etcd ，当然， flannel 的虚拟联网功能也可以用于支撑 K8S 的服务发现。无论是 docker 容器还是 rkt 容器，都可以用 etcd 共享元数据。然而，鉴于 Google 公司和 CoreOS 公司的紧密联系， K8S 很有可能集成更多的 CoreOS 工具。

后续内容简介

在 Linux 容器领域，新工具、新公司、新技术和新实践层出不穷，只有通过参加像 CoreOS Fest 这样的大会，我才能跟得上潮流。容器领域的公司和开源项目之间分分合合，变化之频繁，我们只在移动 Linux 的早期发展阶段看到过。

在第二篇文章中，我们会讨论 systemd 和 CoreOS ， go 语言成为编写容器工具的标准语言，新项目 Calico ， Sysdig 等。最后一篇文章的内容是保存持久数据到容器基础设施遇到的问题和解决方案，包括 PostgreSQL Governor, CockroachDB, etcd, 和 RAFT 共识算法。

原文链接： CoreOS Fest and the world of containers, part 1 （翻译：柳泉波 校对：xxx）