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

在本系列前几篇文章中，咱们介绍了从 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 三件套的内容：

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

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

2. Docker Swarm：Swarm 是 Docker 的集群治理我的项目，其次要的逻辑就和上一节讲过的 Cloud Foundry 相似，能够以相似于 docker run 我的镜像的命令行形式，以 docker run -H 我的 Swarm 集群 API 地址 我的镜像这样将 Docker 运行成一个集群并且进行治理，Swarm 的呈现将 Docker 我的项目从一个一般的容器降级成为 PaaS 平台。
3. 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 公司的，敬请期待。