转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。

在本系列前几篇文章中，咱们介绍了从Cloud Foundry到Docker等PaaS平台的倒退迭代过程。明天咱们持续来为大家介绍Docker走向落寞的起因以及大航海时代的开启。

Docker的商业化

上篇中，咱们讲到了Docker我的项目利用本人翻新的Docker Image霎时爆红，于是许多商家也从中发现商机，纷纷推出本人的容器产品，也想在市场中分一杯羹。
CoreOS推出了Rocket（rkt）容器，Google也开源了本人的容器我的项目lmctfy（Let Me Container That For You）等，然而面对Docker我的项目的强势，就算是Google这种大佬也毫无招架之力。因而Google打算和Docker公司发展单干，关停本人的容器我的项目，并且和Docker公司一起保护开源的容器运行，然而Docker公司方面很强势的回绝了这个显著会减弱本人位置的单干。

在这时Docker公司也意识到了，本人仅仅是云计算技术栈中的幕后英雄，只能当做平台最终部署利用的载体。然而，要想成为这个畛域的外围，就应该有本人的PaaS生态。在Docker爆火，有了短缺的资金之后，Docker公司开始了疯狂的买买买来裁减本人的实力，其中最闻名的就署名Fig。Fig是闻名的Docker Compose我的项目的前身。通过这些并购与本身研发迭代，Docker公司最终推出了以本人为外围的PaaS三件套：Docker Compose、Docker Swarm以及Docker Machine。
上面简略为大家介绍一下Docker三件套的内容：

Docker Compose：Compose的前身，是一个仅有两个人保护的Docker容器编排的开源我的项目Fig，它的性能是：如果当初用户须要部署一个利用A和一个数据库B以及负载平衡C，那么Fig就容许用户把ABC三个容器定义在一个配置文件中，并且指定它们的关联关系。最初只须要一条命令fig up即可间接应用。

在Docker大火的时候，Fig我的项目在Github上的热度堪比Docker，因而在2015年Docker公司将其收买，并且改名为Docker Compose，作为Docker容器的编排工具，并且应用至今。

Docker Swarm：Swarm是Docker的集群治理我的项目，其次要的逻辑就和上一节讲过的Cloud Foundry相似，能够以相似于docker run 我的镜像的命令行形式，以docker run -H 我的Swarm集群API地址我的镜像这样将Docker运行成一个集群并且进行治理，Swarm的呈现将Docker我的项目从一个一般的容器降级成为PaaS平台。
Docker Machine：Machine应该是Docker三件套里最不闻名的，它的性能是将虚拟机运行成容器，并且能够以治理Docker容器的形式治理虚拟机。

OCI的“不作为”到CNCF呈现

在倒退之路上，Docker公司在Docker开源我的项目的倒退上始终保持着相对的权威和发言权，并且在多个场合用实际行动挑战到了其余玩家的利益；另一方面，Docker公司的商业化门路重大侵害了已经的单干公司RedHat的切身利益；再加之，Docker在2015年间的高速迭代表中现出了各种不稳固的breaking change开始让社区叫苦不迭。

人红是非多，更何况Docker还抢了大家的蛋糕。于是，容器畛域的其余几位玩家开始切磋“切割”Docker我的项目的话语权。最终，Docker公司迫于压力，于2015年6月22日，牵头了CoreOS、Google、RedHat等公司，独特成立了一个中立的基金会，并将本人的容器运行时LibContainer捐出，改名为RunC，基金会根据RunC独特制订了一套容器和镜像的规范和标准——OCI（Open Container Initiative）。

OCI的成立，意味着容器运行时和镜像的实现与Docker我的项目齐全剥离，让其余玩家不依赖Docker实现本人的Docker运行时成为可能。

然而，因为成立基金会只是Docker公司对这些大公司的斗争，并且其过后的确保护着数量足够宏大的社区，因而Docker公司对基金会的成立有恃无恐，并且对规范的制订并不关怀。因为在过后的大环境下，Docker本人的实现，曾经就是业界对立的规范了。

因为OCI基金会倒退非常迟缓，因而Google、RedHat等基础设施畛域的头部玩家打出了手中的王牌，独特牵头成了一个名叫CNCF（Cloud Native Computing Foundation）的基金会（这也是云原生这个概念第一次呈现在公众视线内）。CNCF基金会成立的思维根底是，以Kubernetes我的项目为根底，建设一个由开源基础设施畛域厂商主导的依照独立基金会形式经营的平台级社区，来反抗以Docker为外围的容器商业生态。也正是这个基金会的成立，咱们第二节的主人公Kubernetes也开始锋芒毕露。

Kubernetes的呈现与倒退

Kubernetes是Google公司早在2014年就公布开源的一个容器基础设施编排框架，和其余拍脑袋想进去的技术不同，Kubernetes的技术是有理论依据的，即：Borg。Borg是Google公司整个基础设施体系中的一部分，Borg是Google公司整个基础设施体系中的一部分，Google也公布了多篇对于Borg的论文作为其实践反对。其上承载了比方MapReduce、BigTable等诸多业界的头部技术。因而Borg零碎始终以来都被誉为Google公司外部最弱小的“秘密武器”，也是Google公司最不可能开源的我的项目，而Kubernetes就是在这样的实践根底上开发的。下图是Google Omega论文所形容的Google已公开的基础设施栈。

开源vs闭源

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

在这场反抗之初，因为Kubernetes开发灵感和设计思维来源于Borg，Kubernetes我的项目在刚公布时就被称为曲高和寡。太过超前的思维让开发者无奈了解，同时因为Kubernetes我的项目始终由Google的工程师自行保护，所以在公布之初并没有取得太多的关注和成长。

然而，CNCF的成立扭转了这所有，RedHat的短处就是有着成熟的社区管理体系，并且也有足够多的工程能力，这使得Kubernetes我的项目在交由社区保护开始迅速倒退，并且逐步开始和Docker分庭抗礼。并且和Docker的关闭商业模式不同，Kubernetes反其道而行之主打开源和民主化，每一个重要性能都给用户提供了可定制化的接口，并且普通用户也能够无权限拉取批改Kubernetes的代码，社区有专门的reviewer以及approver，只有你写的代码通过PR通过了代码审核和批准，就会成为Kubernetes的骨干代码，这也大大的减少了Kubernetes的生机。并且，依靠于开放性接口，基于Kubernetes的开源我的项目和插件亘古未有，并且依靠于优良的架构设计，微服务等新兴的技术理念也迅速落地，最终造成了一个百花齐放的稳固宏大的生态。

而Docker只能通过本人的工程师批改，在这一点上与Kubernetes相比就与远落下风。

总结起来：

面对Kubernetes社区的崛起和壮大，Docker公司不得不抵赖本人的豪赌以失败告终，从2017年开始，Docker将Docker我的项目的容器运行时局部Containerd捐献给了CNCF社区，并且在当年10月发表将在本人的Docker企业版中内置Kubernetes我的项目，这也标记着继续了近两年的容器编排之战落下帷幕。2018年1月，RedHat公司发表斥资2.5亿美元收买CoreOS，2018年3月，这所有纷争的始作俑者Docker公司的CTO Solomon Hykes发表辞职，至此，纷扰的容器技术圈尘埃落定，天下归一。

总结

本文为大家介绍了Docker是如何在PaaS平台中成为焦点，又如何一步步被Kubernetes代替。下一节咱们将持续为大家介绍Kubernetes除了社区之外，在自身的容器编排技术上是如何降维打击Docker公司的，敬请期待。