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

Docker 的商业化

上篇中，我们讲到了 Docker 项目利用自己创新的 Docker Image 瞬间爆红，于是许多商家也从中发现商机，纷纷推出自己的容器产品，也想在市场中分一杯羹。

在这时 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 项目热度堪比 Docker，因此在 2015 年 Docker 将其收购，并且改名为 Docker Compose，作为 Docker 容器的编排工具，并且使用至今。

1. Docker Swarm：Swarm 是 Docker 的集群管理项目，其主要的逻辑就和上一节讲过的 Cloud Foundry 类似，可以以类似于 docker run 我的镜像的命令行方式，以 docker run -H 我的 Swarm 集群 API 地址 我的镜像这样将 Docker 运行成一个集群并且进行管理，Swarm 的出现将 Docker 项目从一个普通的容器升级成为 PaaS 平台。

2. Docker Machine：Machine 应该是 Docker 三件套里最不出名的，它的功能是将虚拟机运行成容器，并且可以以管理 Docker 容器的方式管理虚拟机。

OCI 的“不作为”到 CNCF 出现

在发展之路上，Docker 在 Docker 开源项目的发展上始终保持着绝对的权威和发言权，并且在多个场合用实际行动挑战到了其他玩家的利益；另一方面，Docker 的商业化路径严重侵害了曾经的合作公司 RedHat 的切身利益；再加之，Docker 在 2015 年间的高速迭代表中现出了各种不稳定的 breaking change 开始让用户叫苦不迭。

人红是非多，更何况 Docker 还抢了大家的蛋糕。于是，容器领域的其他几位玩家开始商讨“切割”Docker 项目的话语权。最终，Docker 公司迫于压力，于 2015 年 6 月 22 日，牵头了几家公司，共同成立了一个中立的基金会，并将自己的容器运行时 LibContainer 捐出，改名为 RunC，基金会依据 RunC 共同制定了一套容器和镜像的标准和规范——OCI （ Open Container Initiative ）。

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

但是，在当时的大环境下，Docker 自己的实现，已经就是业界统一的标准了。

由于 OCI 基金会发展十分缓慢，因此一些基础设施领域的头部玩家打出了手中的王牌，共同牵头成了一个名叫 CNCF （ Cloud Native Computing Foundation ）的基金会（这也是云原生这个概念第一次出现在大众视野内）。CNCF 基金会成立的思想基础是，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的按照独立基金会方式运营的平台级社区，来对抗以 Docker 为核心的容器商业生态。也正是这个基金会的成立，我们第二节的主人公 Kubernetes 也开始崭露头角。

Kubernetes 的出现与发展

Kubernetes 是早在 2014 年就发布开源的一个容器基础设施编排框架，和其他拍脑袋想出来的技术不同，Kubernetes 的技术是有理论依据的，即：Borg 。

开源 vs 闭源

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

在这场对抗之初，由于 Kubernetes 开发灵感和设计思想来源于 Borg，Kubernetes 项目在刚发布时就被称为曲高和寡。太过超前的思想让开发者无法理解，同时由于 Kubernetes 项目一直由自家工程师自行维护，所以在发布之初并没有获得太多的关注和成长。

然而，CNCF 的成立改变了这一切，现在有成熟的社区管理体系，并且也有足够多的工程能力，这使得 Kubernetes 项目在交由社区维护开始迅速发展，并且逐渐开始和 Docker 对抗。并且和 Docker 不同，Kubernetes 反其道而行之主打开源，每一个重要功能都给用户提供了可定制化的接口，并且普通用户也可以无权限拉取修改 Kubernetes 的代码，社区有专门的 reviewer 以及 approver，只要你写的代码通过 PR 通过了代码审核和批准，就会成为 Kubernetes 的主干代码，这也大大的增加了 Kubernetes 的活力。并且，依托于开放接口，基于 Kubernetes 的开源项目比比皆是，并且依托于优秀的架构设计，微服务等新兴的技术理念也迅速落地，最终形成了一个稳定庞大的生态。

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

总结起来：

面对 Kubernetes 社区的崛起和壮大，Docker 公司不得不承认自己的豪赌以失败告终，从 2017 年开始，Docker 将 Docker 项目的容器运行时部分 Containerd 捐赠给了 CNCF 社区，并且在当年 10 月宣布将在自己的 Docker 企业版中内置 Kubernetes 项目，这也标志着持续了近两年的容器编排之战落下帷幕。2018 年 3 月，这一切纷争的始作俑者 Docker 的 CTO 宣布辞职。至此，纷扰的容器技术圈尘埃落定，天下归一。

总结

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