容器编排之争：Kubernetes如何在技术大战中胜出

容器编排之争：Kubernetes如何在技术大战中胜出

容器编排技术的发展历程是一部充满竞争与创新的史诗。从Cloud Foundry到Docker，再到Kubernetes的崛起，这场技术之争不仅改变了软件开发和部署的方式，也重塑了云计算的格局。本文将带你回顾这段激动人心的技术发展史，深入理解Kubernetes为何能在众多竞争者中脱颖而出，成为容器编排领域的主导者。

1. 从Cloud Foundry开始

在IaaS时代，云计算厂商和开发者一直在思考如何更高效地利用资源和改善软件交付方式。这个问题的答案在云计算进入PaaS时代后逐渐清晰。最早出现在开发者视野中的PaaS开源项目是VMware创立的Cloud Foundry。Cloud Foundry号称是业界第一个开源PaaS云平台，支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内完成应用程序的部署和扩展，无需关心任何基础架构的问题。

Cloud Foundry的典型使用方法是用户在云端部署好Cloud Foundry之后，本地应用只需要一条命令就能进行推送和安装：

cf push hello-world

Cloud Foundry为应用定义了一种打包方式，push则将本应用以及启动脚本进行压缩传到Cloud Foundry服务器之中，随后Cloud Foundry开启调度器找到合适的虚拟机，下载压缩包，解压并运行，最终成为一个对外提供服务。在这个过程中，由于虚拟机会启动不同的应用，Cloud Foundry利用cgroups和namespace机制为每个应用创建了一个“沙盒”环境。这样，在同一个虚拟机中的应用互相隔离，彼此不受影响。

此外，Cloud Foundry平台对这些应用项目提供分发、灾备、监控、重启等服务。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用，而这也就是PaaS的“初心”——平台即服务。

2. Cloud Foundry的软肋

历史上有太多的前辈想要解决环境不一致的问题。前有Java的“write once run anywhere”，后有Cloud Foundry的“cf-push”。PaaS当时的火热就在于应用的打包和部署功能。但就是这个打包功能，成了Cloud Foundry的软肋，一直为用户所诟病。

Cloud Foundry为每一种主流的语言都定义了一套打包的方式，开发者不得不为每一种语言、每一种框架、甚至是每个版本应用维护一个打好的包。除此，这种方式还有可能出现本机运行成功，打了个包上传之后就无法运行的情况。本来是为赋能开发者而生的技术，却对开发者极不友好，当开发者的抱怨积累到一定程度，想要在PaaS浪潮中央站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就顺理成章。

3. Docker的制胜法宝

最初，Docker还是一个叫dotCloud的公司，dotCloud最初阶段也是选择LXC来快速部署软件，使用LXC虽然可以解决应用隔离的问题，但不能解决应用可移植性问题，为此dotCloud开发了一套内部管理工具，方便创建和管理容器，这个工具就是后来的Docker。

Docker刚开源的时候，Cloud Foundry的产品经理就在社区做了一次详细的对比，告诉用户Docker和Cloud Foundry一样，都是使用了Namespace和Cgroups技术的沙箱而已，无需值得关注。事实上，Docker也确实就和他所说的一样，采用了这个“传统”的技术方案，但是Docker与Cloud Foundry相比，创新性地提出了Docker镜像。

比起Cloud Foundry那种执行文件+启动脚本的打包方式，Docker镜像完美解决了两个问题：本地环境和服务器环境的差异、同一份镜像可以让所有的机器进行复用。

图：Docker的愿景：Build, Ship, and Run Any App, Anywhere

正是Docker镜像这个“微不足道的创新”，让Docker席卷整个PaaS领域。

4. Kubernetes入场

Docker项目利用自己创新的Docker Image瞬间爆红，众多厂商也从中发现商机，开始围绕容器编排做一些思考和布局，这其中就包括云计算概念的最早提出者Google公司。

虽然Google公司名声显赫，有强大的技术实力和资金实力，但在当时提到云计算，人们首先想到的却是AWS，Google也一直想法设法扭转局面，随着Docker的成功，他们从大火的容器市场看到了新的机会。Google对容器知根知底，2007年提交了cgroup到Linux内核，如今已经演变成容器运行时的基础。2008年PaaS平台GAE就已经采用了LXC，并且开发了一套进行容器编排和调度的内部工具，也就是Kubernetes的前身——Borg。

图：Kubernetes前身Omega系统在Google内部中的地位

凭借多年运行GCP（Google Cloud Platform，Google云端平台）和Borg的经验，使得Google非常认可容器技术，也深知目前Docker在规模化使用场景下的不足。如果Google率先做好这件事不仅能让自己在云计算市场扳回一局，而且也能抓住一些新的商业机会。比如，在AWS上运行的应用有可能自由地移植到GCP上运行，这对于Google的云计算业务无疑极其有利。

2013年夏天，Kubernetes联合创始人Craig McLuckie、Joe Beda和Brendan Burns开始讨论借鉴Borg的经验进行容器编排系统的开发。Kubernetes项目获批后，Google在2014年6月的DockerCon大会上正式宣布将其开源。

云计算市场中失去先机的IT界领导者和创新者王者归来，容器编排的竞赛正式拉开帷幕。

5. Docker Swarm入场

当然，并不是只有Google看到了容器市场的机会。DockerCon 2014大会上，就有多家公司推出了自己的容器编排系统，而Google的进场让竞争变得更加激烈。

随着DockerCon 2014大会的落幕，Docker公司也意识到自己仅仅是云计算技术栈中的幕后英雄，容器平台化能力才是致胜的关键，单纯解决应用打包并没有价值，只能当做平台最终部署应用的载体，企业真正需要解决的是应用部署问题。于是迅速调整了战略方向，再度向PaaS进军。

2014年7月，Docker收购了OrchardLabs，正式涉足容器编排领域。Orchard Labs的容器编排工具fig当时很有名，而这个fig就是DockerCompose的前身。Docker Compose虽然能编排多个容器，但是只能对单个服务器上的容器进行操作，不能实现在多个机器上进行容器的创建和管理。于是Docker在2014年底又发布了Swarm项目，并且不断招兵买马，充实着自己的平台化能力。

Docker Swarm可以在多个服务器上创建容器集群服务，而且依然保持着Docker的友好命令风格，几个命令就可以完成多机集群部署，在容器规模较小的场景下，所以许多用户更喜欢使用Docker Swarm。

图：swarm架构

如果说Docker Compose和Kubernetes还算不上正面竞争的话，那么Docker Swarm的发布，则是正式向Kubernetes宣战。

6. 搅局者Marathon

当集群规模很大，管理的资源很多时，很多人就不愿意再使用Docker Swarm，也没有选择Kubernetes，而是选择了Marathon和Mesos。

Mesos是什么

举一个例子说明。假定某公司需要频繁进行大数据计算，该任务运行时需要N多个CPU和内存，为了满足资源需求，有两种方案：

1. 使用一个大型服务器，为任务提供足够的资源。
2. 采用分布计算，即提供一批普通配置的机器，组成集群，将计算任务拆分到各个机器上计算，然后汇总结果。

Mesos就是实现这类分布式计算的框架。

Mesos最初是加州伯克利大学RAD实验室2009年启动的一个学术研究项目，初衷是为Spark做集群管理，可以将不同的物理资源整合在一个逻辑资源层面上。Mesos也在火热的容器技术中看到意识到了新的机会，在Docker问世后通过与Docker的整合焕发了第二春。

Mesos解决问题的核心是围绕物理资源层，它上面跑什么，怎么跑其时并不关注（想要跑什么任务，开发Scheduler和Executor实现Mesos Framework即可）。Mesos的架构图如下所示，如果忽略图中与Hadoop、MPI框架的相关模块，我们会发现架构会变得非常简单，它仅由Zookeeper集群、Mesos主节点和工作节点组成。

master根据调度策略（比如公平调度和优先级方式），来决定将slave节点上的空闲资源（比如：CPU、内存或磁盘等）的提供给framwork（例如Hadoop、MPI、Hypertable、Spark、Docker等）使用

图：Mesos架构

Mesos的标杆客户是Twitter，2010年，Twitter正值基础架构混乱不堪的时刻，他们看到了Mesos这个项目，随后马上应用，管理着Twitter超过30万台服务器上的应用部署，成为Twitter自定义PaaS的实现基础。Benjamin Hindman（Mesos项目负责人）当时也加入了Twitter，负责开发和部署Mesos，Twitter的这套基于Mesos的PaaS解决方案就是后来的Apache Aurora。

Mesos在Twitter的成功应用后，也吸引了全世界其他知名公司的采纳，比如Airbnb、eBay和Netflix等等，甚至2015年Apple的Siri就是运行在Mesos上，Mesos也因此曾经火极一时。至于微软，他不仅投资了Mesosphere（Benjamin Hindman离开Twitter后成立的mesos的商业化公司），还让它的Azure平台率先支持了Mesos。

7. Kubernetes扭转局势

面对Kubernetes的出现，一场Docker和Kubernetes之间的容器之战就此打响。

2015年7月Google、RedHat等企业共同发起成立了CNCF（Cloud Native Computing Foundation）的基金会，希望以Kubernetes项目为基础，建立一个按照开源基金会方式运营的开源社区。

与Apache基金会截然不同，CNCF并不会把自身的组织架构和管理模式强加在其成员项目上，而是让其成员项目如Kubernetes更加自治化地自我管理，并提供如下维度的帮助：

• 生态绑定：将紧密围绕Kubernetes的插件项目（如linkerd、fluentd、prometheus）放在同一个CNCF生态下，形成有机的绑定。
• 法律保护：保障Kubernetes的商标、Logo、License、专利、版权等被合理使用和消费。
• 市场推广：通过meetups、K8sPort、Kubecon、Blog、Twitter、新闻媒体等线下、线上活动对Kubernetes等技术进行推广。
• 培训认证：制定规范、流程、课程来对Kubernetes等技术进行普及和相应的盈利。
• 最后，协调不同厂商之间的关系和竞争。

依托于开放性接口和优秀的架构设计，基于Kubernetes的开源项目和插件比比皆是，到现在，CNCF已经形成了一个百花齐放的稳定庞大的生态。

8. Kubernetes最终胜出

经过设计理念、架构、标准、生态等多方面的较量之后，Docker在与Kubernetes的竞争中逐渐落败，Mesos因其侧重在传统的资源管理，导致它在应对多云和集群管理时面临很多挑战，标杆客户Twitter最后也放弃了Mesos改用Kubernetes。

• 2017年10月的DockerCon欧洲大会上，Docker宣布在自己的主打产品Docker企业版中内置Kubernetes，并将Docker项目的容器运行时部分Containerd捐赠给了CNCF社区。
• 2017年11月29日，AWS宣布了他们的Kubernetes弹性容器服务(EKS)。在Amazon宣布之前，Mesosphere、Pivotal和Docker也宣布了对Kubernetes的原生支持。
• 2019年8月5号，Mesosphere宣布改名为D2iQ，开启了围绕Kubernetes生命周期管理、混合云、多云的重生之旅。
• 2019年11月，Mirantis收购了Docker的企业部门。

至此，纷扰的容器技术圈尘埃落定，天下归一。