前言
前些日子一个阿里高P朋友在不存在的网站推特上问了一句「k8s 也没什么杀手级特性，怎么就干翻了 swarm 和 mesos」，正好看到。虽然简单的跟他说了下，但回想起过去5年容器圈的发展，只能说一个项目的命运，既要靠工程师的努力工作，也需要有一点历史的进程。
缘起
我们把时间退回到 2014 年，在 2013 年有了 docker 这个东西之后，经过一年的尝（chui）试（bi）大部分运维界的 SA 们把它当做一个 sliver bullet 去解决运维自动化的问题，美名其曰 devops。然而现实是残酷的，仅仅只是脚本的包装并不能算是一个杀手级的特性把 SA 们从繁重的工作中解放出来实现真正的自动化。而这时候一小撮原本做云的系统工程师看到无论是容器还是虚拟机，本质上调度和编排才是其拉开对手差距的核心竞争力，由此拉开的调度与编排的 *aaS 的战争大幕。
而 2014 年上半年的时候，放眼望去除了知道 Google 有个叫 Borg 的系统运行了很多年，很强很牛逼，就是 2009 年就已经存在的 Mesos 似乎能做这件事情。是的，在 2015 之前，Borg 的论文并没有公布出来，所有的人只能通过江湖传闻去推测它到底是个怎样的东西。
由此，Mesos 和其上的 Marathon 占据了先机。与此同时，国内亦有基于其他技术的调度和编排系统，如基于 Yarn 的腾讯 Gaia，如阿里若干个调度编排系统，如我当时在芒果TV的团队做的 NBE。算上运维向的 Docker Compose，堪用的调度编排工具就这么几个。
没有人知道这种东西该是怎样的，是 PaaS 还是 IaaS 还是介于两者之间，是纯资源调度还是构建整个开发流闭环，都在摸着石头过河。
Kubernetes 出世
2014 年 6 月，Kubernetes 出世了，打着 Google 的金招牌。虽然野史中 K8s 这个项目本身是 Borg - Omega 体系下失败的竞争者，最早的时候只有 1.5 个全职人力做的项目，但它爹的招牌让它在一出世就吸引了全世界开发者的目光。要注意的是，在 K8s 出来的时候，离 Borg 的论文发布还有 1 年时间。所以无论后世如何把 Kubernetes 往 Borg - Omega 上去（zhao）靠（die），我个人依然认为其最多算整了容的领居家小孩，谈不上正统 Borg 的继承者，所谓第三代调度和编排平台更是无稽之谈。
人们从 K8s 以为窥视到了 Google 基础设施的全部，而实际上可能只是一小块罢了。从 1 年后的 Borg 论文来看，Borg 给出的是一个超大集群管理的策略，单一个中位数的 cell 大小 10K （ Our median cell size is about 10 k machines after excluding test cells; some are much larger） 就已经超过了目前已知的 K8s 单集群极限 2 倍（5K），这种差距下工程难度和细节天壤之别。当然要说论文最后有一页经验和教训提到了如何通过 Borg 来写 K8s，更像是广告吧。
当时它的对手们 Marathon 和 Mesos 的组合受制于 Scala 不温不火，长时间运行的容器我没记错的话很久之后才解决，性能也一直是其痛点。Docker Compose 完全就是运维向，更类似于一个 batch jobs 分发工具。这时候的 Docker Swarm 还需要跟其他工具等配合，算是一个自动化工具集。Hashicorp 的 Nomad 也得还有 1 年才出生。
那时候的系统工程师们为了容器落地和使用方 PK 一个容器一个进程还是一个容器多个进程，为了容器网络焦头烂额，为了资源分配和编排绞尽脑汁。K8s 带出来的 Pod 一下子就解决了 2 个问题，即传统多进程结构的业务如何无痛落地容器以及在这种模型下资源尤其是网络怎么办。
漂亮的一击！
加上 Google 金字招牌，至少 2014 年年底到 2015 年这个所谓的容器元年 K8s 在业内声势浩大，慢慢的盖过了 Mesos 和 Marathon 的风头。
Docker 的反击
首先，Docker.Inc 是一家商业公司，基于此我们才能去讨论它在 2015 和 2016 的一些策略，比如 Swarm 合入 Docker daemon （1.12）。
因为早期 Swarm 的不完善，对竞争对手而言谈不上是个威胁。RedHat 也好，Google 也好，Docker.Inc 也好明面上大家还是在合作做大容器这块蛋糕。但久而久之明眼人都看得出调度和编排才有 to B 变现的可能，仅仅提供一个 daemon 的 docker 更像是富士康那样的血汗工厂，食物链的最底层。旁人不蠢，Docker 公司的人自然也不蠢。于是在 15 到 16 年这段时间内，Docker 开始压宝 Swarm，通过自身当时无与伦比的影响力倾斜了大部分资源在 Swarm 上，势头一时无两。当年选型做调度编排的豆瓣平台组继承者宜信大数据 lain 就是选的 Swarm，可见其当时和市场上其他调度编排方案相比，至少是旗鼓相当的。
再接着，各怀鬼胎的 Redhat，Google 及 Docker 就分道扬镳了，分别在 rkt/docker，cni/cnm，oci 等定义标准的领域斗得你死我活，当然这又是另外一个故事了。至少在当时，Docker 公司坐拥社区声望及事实镜像标准，对抗 Goolge 加红帽明面上不落下风，自家 Swarm 顺风顺水，好不威风。
渐渐有点飘了的 Docker 公司决定打出最后一张牌，彻底吃下调度和编排的事实标准，那就是 Swarm 合入 Docker，没想到成了压垮骆驼的最后一根稻草。天下苦 docker bug 久已！我不知道当时的他们意识到了没在一个不稳定的 docker daemon 上合并进另外一个不稳定的大系统会给使用者的信心带来多大的打击，一时间群情激昂。
既然已经撕破了脸，红帽和 Google 旋即加大了对旗下各组件的支持程度，Docker 的社区大旗，倒了。这个时候 Mesos 和 Marathon 的组合依然不温不火，Swarm 在其人为高光时刻就是其没落的开始，社区的风向第一次完全吹向了 K8s。CNCF 的出现（和 K8s 1.0 同时宣布）宣告着新一代类似于 OpenStack 联盟的形成，而这个联盟和 Docker 关系已经不大了。
尾声
事实上在 2016 年我写下 Docker 的未来的时候容器战争基本可以预见其最终结果了，回想起来至少是 2017 年这个时间节点上讨论容器调度编排的时候几乎等同于讨论 K8s。
水能载舟亦能覆舟，谁能想到因为 Docker 公司壮大得那么迅速，同时也败得那么彻底，而引起这一切的仅仅是因为代码质量和一意孤行的市场策略。无论怎样在当前的时空里面，K8s 已经成为了事实标准。它好么？好是好，但离 Borg 还是有一定差距，甚至就纯资源模型上离 Mesos 都很远。它不好么？看看它的对手们，一个只有一条腿的 Mesos，一个风轻云淡的 nomad，一个声名狼藉的 swarm，靠的全是同行的衬托。
再加上它那个姓谷名歌的二手亲爹，出生的时候躺着就赢了一半了吧。