永生已死解读2016之容器篇和 (永生已死解读百度云)

也说不上什么时候起，“XXX Is Dead. Long Live XXX”的句式突然成为了技术会议上演讲题目的一个标准套路。然而不管已经被引用的多么烂俗，用这套悖论来总结 2016 年容器技术圈子发生的凡事种种，却实在有种说不出来的恰到好处。

无需多言，稍微回顾一下 2016 年容器技术圈子的时间线，我们很容易就能回想起容器技术如何在这一年迅速登上云计算舞台的中心。这股热潮，从年初 Docker 公司闪电收购 Unikernel Systems 提前扼杀各种“被颠覆”的苗头，蔓延到 Kubernetes，Mesos，Docker 三家项目在年中掀起的“编排”之争，再到年末阿里云一举震撼国内创业市场。“编排”，“fork docker”，“OCI runtime”， “镜像标准”，一个又一个令人目不暇接的关键词带着背后的技术爆点填满了 2016 一整年的时间线。只不过，惊喜不断的同时，嘈杂的容器圈子也难免给我们带来了些许无所适从的挫败感。回顾这一年的容器技术发展历程，相信大家都有这样的疑惑：当这个圈子平复下来之后，我们该如何去理性地思考和解读呢？

在 2016 年，当我们再次说出这个关键词的时候，已经很难用一句话解释清楚我们到底在说的是什么。是 Docker 公司？是 Docker 容器？是 Docker 镜像？还是 Docker 集群？

在创业初期通过一连串极其成功的开源战略迅速蹿红之后，Docker 项目几经重构，最终选择了“大一统”的战略模式，一系列普通认知中应该是独立项目的功能模块都被编译进了 Docker 项目的二进制文件中，这其中最引人注目的，当属 SwarmKit 项目。

2016 年 6 月，Docker 公司宣布将在接下来版本的 Docker 项目中将会提供内置的“编排”功能，这个功能的实现将主要由一个名叫“SwarmKit”的依赖库来负责。此新闻一出立刻成为容器圈子一时的舆论热点，尤其在国内。其中，看涨者不少，有言“生态闭环”、“Docker 正统”，唱衰者也不缺，直呼“公然越界”、“野心昭然”。时至今日，该项目本身也日趋稳定，我们不妨再回头来重新解读一下曾经在风口浪尖上的 SwarmKit。

SwarmKit 的核心功能乃是“编排”，不过它对这个编排的定义还是比较模糊的，在初期主要指的是“多容器副本”和“副本负载均衡”两个核心能力，后面逐渐加入的是更多应用管理功能。说起这个项目发布的初衷，当时国内的诸多讨论之中，曾有一种误区是认为 SwarmKit 是 Docker Swarm 项目的继承、是 Swarm 项目的“内置版”（当然，这也要部分归功于 Docker 公司老辣的命名技巧）。但现在回头来看，这些“编排”能力在 Docker Swarm 项目中，一直都是不存在的，继承自然无从谈起。SwarmKit 唯一跟 Docker Swarm 项目重叠的功能乃是“调度”，但实际上 SwarmKit 的调度也是从头做起，它维护了一个 NodeHeap（堆），然后通过堆算法配合过滤条件来筛选最符合要求的节点来运行任务。这套调度机制在 Swarm 中也是不存在的。而在 API 层面，Docker Swarm 项目提供的是一套简洁的单容器的 API 来让用户操作容器集群（这个能力非常受欢迎），而 SwarmKit 却从一开始就引入了 Service，Task 等一系列面向容器集群的、平台级别的概念，并且从底层实现上就不兼容 Swarm 风格的单容器 API。两者的关系正如同“Java”和“JavaScript”一样风马牛不相及。

那么 Docker 公司内置“编排”能力并且起一个这样的有混淆意味的名字，到底意义何在呢？

答案很简单：“平台（Platform）”。或者说成是“应用 / 容器集群管理”，或者说成是“PaaS”甚至“CaaS”，都可以，一个意思。

这个改变的关键就在于，从今以后 Docker 项目就变成了一个“平台”项目而不再是一个单纯的“容器”项目了。它要站在 Kubernetes，DC/OS，Cloud Foundry 一样的位置上直面云的终端用户，而不是继续做这些平台背后的容器技术（甚至只是容器技术中的一种）。

这种平台级别的能力对于 Docker 公司来说是至关重要。容器的热度终究会冷却，用户很快就不会关心底层的容器技术为何物，他们只会记得 Kubernetes API，Service， Replication Controller，DC/OS，顶多在编写 Dockerfile 的时候，才回忆起 Docker 公司的存在。很多人批评 Docker 公司野心太大，其实对于一家拒绝了微软 40 亿美金收购的后端技术创业公司来说，有怎样的进取心都不为过。Docker 公司的目标是下一个 VMware，下一个 Intel，一个实实在在能盈利能上市的商业公司，在这个巨头如林的云计算行业里，这是令人钦佩的。

Docker 公司在 2016 年在集群领域所做的努力离不开“平台”二字，不过国内曾经一度涌现出来的过分解读着实让这个项目背负了太多的压力。其实打开 SwarmKit 项目的代码看看，从编排到调度，模块设计，代码实现，跟其他项目并无二异，ipvs 也是普通的 NAT 模式，Master 节点一样维护着 Apiserver, Scheduler, Orchestrator，同宿主机上的 Agent 通过 gRPC 交互，就连 Agent 也跟其他“第三方”项目一样也要通过 client 去调用 Docker Engine 的 API。所谓的各种“颠覆性”、“大道至简”、“容器 OS 化”、“从下往上改变容器云形态”等观点，实在无从谈起。

还有一种可能性是 Docker 公司依靠 Docker Swarm 这样一个独立的、以单容器操作 API 为核心的项目来完成 PaaS 的使命（业界基于 Swarm 构建 PaaS 的用户不在少数）。但现实是，几乎同时发布的 Google Kubernetes 项目却出人意料地狙击了 Swarm 的发展势头。下图是自发布起，Swarm 项目和 Kubernetes 项目 GitHub Star 数目的变化统计。

事实上，Docker Swarm 项目“使用单容器 API 来操作集群”的理念是相当有吸引力的。但是这个能力在接下来 Docker 公司想要重点发展的企业私有云市场却陷入了窘境：单容器 API 纵然简单友好，但企业级用户却没办法直接用它来实现哪怕一个最简单的“容器集群负载均衡”的需求。所以很多企业私有云用户更倾向于把 Docker Swarm 项目作为容器云的一个环节，然后自己来实现各种平台级别功能（往往还要参考 Kubernetes 的各种理念和设计）。照这个趋势发展，如果不推翻重来提供类似的面向集群的 API，Docker 公司的平台之梦恐怕就很难实现了。这也正是为什么我们前面简单一对比就不难发现，SwarmKit 相比 Swarm 项目其实是翻天覆地的自我革命，而非继承或者内置，所谓向后兼容的问题自然也无从谈起。

其实，很多人可能已经忘记了早在 Docker Swarm 项目发布之前，Docker 公司已经发布过一个集群管理的项目叫“libswarm”（访问该项目地址有彩蛋：）。这个项目的初衷非常单纯，就如同 Docker 项目最开始发布时一样“冰雪通透”：

“… … libswarm 项目的初衷是提供一套不依赖与现有分布式系统的集群管理 API ，… … ，并使得其他项目可以使用它来方便的构建容器集群 … … ”

彼时的 Docker 公司，还希望 Mesos，Fleet 们使用 libswarm 来管理 Docker 容器云呢。

所谓：“Swarm 已死，Swarm 永生”，Docker 项目又何尝不是呢。

在经历了 OCI 成立、贡献出了核心组件 libcontainer 之后，Docker 公司坚定地走向了独立发展的道路。在巨头们的围剿之中，这是一家创业公司从默默无闻到炙手可热，再到痛定思痛之后的必然选择，SwarmKit，以及其他所有外界看来“野心太大”的项目和举措，都只是这个信念的间接产物而已。在未来，Docker 公司依然会不遗余力的构建自己的平台世界，网络，存储，Infra Layer，CI/CD，一个全功能平台级项目所欠缺的版块都会被一一补全，各种各样内置于 Docker Daemon 中的 Kit 库和收购还会层出不穷，Docker 公司还会以此为基础重点推广可以盈利的 Docker Cloud 和 Docker>Kubernetes

尽管 Docker 公司整整一年都在““平台”领域发力，Kubernetes 依然是这个领域最瞩目的项目。这并非意外，在开源的世界里，一旦在某个领域树立了标杆，就很容易跟竞争对手拉开质的差距。Kubernetes 幸运的成为了“容器集群管理“领域的开创者，其他的后进项目，无论是 Marathon 还是 SwarmKit，都只能主动或者被动地 follow 开创者的提出的理念。这正如同如果让 Google 再做一个容器，它也会十有八九 follow Docker 一样。

“如果大家只是再造一个 Kubernetes，那有什么理由会比 Kubernetes 团队做的更好？”

当然，含着“千呼万唤始出来”的 Borg 论文出生，又是 Google 公司在 Big>Mesos 生态

当今容器圈子，除了以 Docker 为主角的容器运行时和以 Kubernetes 为主角的容器集群管理，还有一方“势力”绝不能被忽视，这就是 Mesos 生态。众所周知，Mesos 本身是一个“老”项目，它诞生于伯克利，崛起于 Big>国内外创业生态圈

如果说 2016 年的容器圈子仍然十分热闹，那必然少不了 startup 的繁荣。围绕容器运行时、编排、网络、存储、镜像管理、CI/CD、PaaS 方案等的一系列生态环节所创立的 startup，是推动这个大环境蓬勃发展的直接动力。

除了本身就是创业公司的 Docker，容器圈的另一个主角当然是 CoreOS。虽然创新能力十足，但 CoreOS 公司的 rkt 容器仍然没能在 Docker 的强势下占据容器市场的主流。由于单点突破受阻，2016 年的 CoreOS 公司也做出了跟 Docker 公司类似的转型，开始向一个涵盖范围更广的“容器云”公司靠拢。除了一系列改名、扩展 rkt 的职能之外，还有一个重要的手段是：抛弃 Fleet，拥抱 Kubernetes。

Fleet 曾经是 CoreOS 体系中重要的容器编排和调度项目，也曾同 Mesos 等项目一样在容器云领域占有一席之地。但现实证明，它并不足以让 CoreOS 在“云”的市场上争取到竞争优势。凭借 Etcd 在 Kubernetes 中的重要作用，CoreOS 的工程师从性能调优作切入口进入了 Kubernetes 生态，并做出了显著的成绩，rkt 也在 CRI 发布之前就成为了 Kubernetes 的可选容器运行时之一，kubelet 则被内置到 CoreOS Linux 中作为默认的编排和调度框架。2016 年，CoreOS 又围绕 Kubernetes 发布了一系列工具如 Operator 来完善生态中的“有状态应用管理”，“存储管理”等能力，已经可以说是最成功的结合 Kubernetes 来创业的 startup。

与 CoreOS 不同，国内的创业公司的发力点主要集中于提供容器服务的 PaaS 产品（也有人称之为 CaaS 以突出自己的容器特性）。相比于创业初期主要集中于容器管理平台的建设，2016 年的国内容器创业公司则主要在围绕自己的平台构建生态类产品，涵盖了监控、存储、镜像监管、客服等一系列工具，其产品能力明显强于同类型的国外 startup。另一个显著的变化是，2016 年国内创业公司开始更多关注和宣传线下企业私有云市场的生意，创业初期着重推广的公有云服务的更新和维护力度明显降低。毕竟，在国内 startup 公有云盈利困难是一个不争的事实。

产品能力的异常强劲，侧面反衬出了国内 startup 在上游社区层面的影响力的弱势，在社区中推动和提出项目特性的能力依然欠缺。当然，创业维艰，尤其是国内大环境下，恐怕也只有华为能够在一边维护和推进 runC 等 OCI 项目的同时，一边在 Kubernetes 上开展完整的“联邦集群”特性（甚至将 Google 的负责人招致麾下）。还有 Hyper，这只团队已经是 Kubernetes CRI 的重要维护者之一（CRI 中很大部分代码正出自他们之手），同时也是 runC 运行时 cri-o 项目的维护者，已经在 Kubernetes 容器管理部分争取到了一席之地。而其本身维护的虚拟化容器 HyperContainer 项目和以此为基础的 hyper.sh 容器托管服务，则创下了占据 HackerNews 首页长达 24 小时的惊人记录。不过放眼全球市场，这些工作只能说是 Hyper 的本职，并不能掩盖国内团体在整个容器开源社区里弱势的现状。而这个现状的改变，以目前国内大多数 startup 的运营方式和核心能力点来看，恐怕还尚需时日。

2016 年国内另一件新闻则是阿里云同 Docker 公司的牵手。这并非临时起意，早在 2015 年在国内容器创业氛围正值巅峰时，阿里云并没有直接进场，“而是在谨慎考察国内环境对容器的接纳程度”（此信息来自阿里云官方）。时至 2016 年，容器技术已经在国内红透半边天，作为后来者，体量又如阿里云这般的巨头要想再进场，必须要拿出最强势的姿态来踏出这第一步。同 Docker 公司展开官方合作，可以说是最佳选择。而对于 Docker 公司来说，Google 和 AWS 已经成为直接竞争对手，放眼全球，阿里云即是拿得出手的一线厂商，又对 Docker 公司无毒无害，这次合作可谓一拍即合。只是从此国内其他公司再想拿“Docker 官方”、“Docker Native”来做宣传，在这个排他性的合作面前，恐怕就需三思而后行了。

总结

2016 年，容器技术圈子依然热闹非凡，容器社区里的弄潮儿们在“is dead”和“long live”的悖论里不断地自我否定和进化已成为这个社区所独有的常态。Docker 公司“萌萌哒”的鲸鱼背后，一只野心勃勃的海洋霸主正蓄势待发；而作为容器编排管理领域的领导者，纵使有 Google、Redhat 等巨头的撑腰，Kubernetes 恐怕也不会放慢脚步，通过 CRI 联合 CNCF、OCI 两大开源社区举措也在情理之中。容器技术的圈子里容不得懈怠，Mesos 生态已经开始励精图治，意在凭借独有的能力拿回昔日的地位。我们不难发现，在 Docker 公司向平台领域发展的同时，Kubernetes、Mesos 也同样渗透进了容器运行时的范畴。实际上，正如同那些支付宝与微信之争，几个大佬原生的核心能力恐怕才是它们取得今天成绩的关键所在。作为终端用户，理清自身真实需求之后，做出适合自己的选择其实并不太难。

容器技术圈子的繁荣，得益于现代开源软件社区的成功。Docker 自不必说，Kubernetes、Tensorflow 亦如是。连 Google、Microsoft 这样的巨头都一改对开发者傲慢的态度和轻视开源社区运营的作风而扎堆到 GitHub 上施展浑身解数，有幸同处一个时代而成为参与者和亲历者的我们又有何理由作壁上观呢。