根据张磊老师《深入剖析Kubernetes》课程内容整理，详细介绍Docker项目的起源、进化、生态等
1 初出茅庐
把时间拨回到九年前，曾经被人们寄予厚望的云计算技术，也已经从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和账单，以 Cloud Foundry 为代表的开源 PaaS 项目（业界第一个开源PaaS云平台）， 成为了当时云计算技术中的一股清流，吸引了包 括百度、京东、华为、IBM 等一大批国内外技术厂商，开启了以开源 PaaS 为核心构建平 台层服务能力的变革。
当时还名叫 dotCloud 的 Docker 公司，也是这股 PaaS 热潮中的一份子，只不过相比于Pivotal、Red Hat等 PaaS 弄潮儿们，dotCloud 公司实在是太微不足道了，眼看 就要被如火如荼的 PaaS 风潮抛弃，dotCloud 公司却做出了这样一个决定：开源自己的容器项目 Docker（这个决定在当时根本没人在乎）。
“容器”这个概念从来就不是什么新鲜的东西，也不是 Docker 公司发明的。即使在当时最 热门的 PaaS 项目 Cloud Foundry 中，容器也只是其最底层、最没人关注的那一部分。
PaaS 项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。 在当时，虚拟机和云计算已经是比较普遍的技术和服务了，那时主流用户的普遍用法，就是租一批 AWS 或者 OpenStack 的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。 当时的云计算服务，比的就是谁能更好地模拟本地服务器环境，能带来更好的“上云”体验，项目的出现，就是当时解决这个问题的一个最佳方案。 像 Cloud Foundry 这样的 PaaS 项目，最核心的组件就是一套应用的打包和分发机制。Cloud Foundry 为每种主流编程语言都定义了一种打包格式，而“cf push”的 作用，基本上等同于用户把应用的可执行文件和启动脚本打进一个压缩包内。
由于需要在一个虚拟机上启动很多个来自不同用户的应用，Cloud Foundry 会调用操作系统的 Cgroups 和 Namespace 机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程。这样，就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的（PaaS 项目最核心的能力）
而 Docker 项目，实际上跟 Cloud Foundry 的容器并没有太大不同，所以在它发布后不久，Cloud Foundry 的首席产品经理 James Bayer 就在社区里做了一次详细对比，告诉用户 Docker 实际上只是一个同样使用 Cgroups 和 Namespace 实现的“沙盒”而已，没有什么特别的黑科技，也不需要特别关注。
短短几个月，Docker 项目就迅速崛起了。它的崛起速度如此之快，以至于 Cloud Foundry 以及所有的 PaaS 社区还没来得及成为它的竞争对手，就直接被宣告出局了。事实上，Docker 项目确实与 Cloud Foundry 的容器在大部分功能和实现原理上都是一样的，可偏偏就是这剩下的一小部分不一样的功能，成了 Docker 项目接下来“呼风唤雨”的 不二法宝。 这个功能，就是 Docker 镜像。
Solomon Hykes 自己当时都没想到，这个小小的创新，在短短几年内就如此迅速地改变了整个云计算领域的发展历程，前面提到PaaS 之所以能够帮助用户大规模部署应用到集群里，是因为它提供了 一套应用打包的功能。可偏偏就是这个打包功能，却成了 PaaS 日后不断遭到用户诟病的一个“软肋”。出现这个问题的根本原因是，一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至 每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在 PaaS 里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端 PaaS 匹配的“脾气”才能够搞定 （Docker 镜像解决的，恰恰就是打包这个根本性的问题：本地环境和云端环境的高度一致）
所以，Docker 项目给 PaaS 世界带来的“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。 而对于开发者们来说，在终于体验到了生产力解放所带来的痛快之后，他们自然选择了用脚投票，直接宣告了 PaaS 时代的结束。 不过，Docker 项目固然解决了应用打包的难题，但正如前面所介绍的那样，它并不能代替 PaaS 完成大规模部署应用的职责（新的问题）。
而在 2014 年底的 DockerCon 上，Docker 公司雄心勃勃地对外发布了自家研发的“Docker 原生”容器集群管理项目 Swarm，不仅将这波“CaaS”热推向了一个前所未有的高潮，更是寄托了整个 Docker 公司重新定义 PaaS 的宏伟愿望。
2 崭露头角
这个以“鲸鱼”为注册商标的技术创业公司，最重要的战略之一就是：坚持把“开发者”群体放在至高无上的位置。相比于其他正在企业级市场里厮杀得头破血流的经典 PaaS 项目们，Docker 项目的推广策 略从一开始就呈现出一副“憨态可掬”的亲人姿态，把每一位后端技术人员（而不是他们的老板）作为主要的传播对象。 简洁的 UI，有趣的 demo：
- “1 分钟部署一个 WordPress 网站”
- “3 分钟部署一个Nginx 集群” …. 这种同开发者之间与生俱来的亲近关系，使 Docker 项目迅速成为了全世界 Meetup 上最受欢迎的一颗新星。
在过去的很长一段时间里，相较于前端和互联网技术社区，服务器端技术社区一直是一个相对沉闷而小众的圈子。而 Docker 项目，给后端开发者提供了走向聚光灯的机会。就比如 Cgroups 和 Namespace 这种已经存在多年却很少被人们关心的特性，在 2014 年和 2015 年竟然频繁入选各大技术会议的分享议题，就因为听众们想要知道 Docker 这个东西到底是怎么一回事儿。
解决了应用打包这个根本性的问题，同开发者与生俱来的的亲密关系，再加上 PaaS 概念已经深入人心的完美契机，成为 Docker 这个技术上看似平淡无奇的项目一举走红的重要原因。虽然通过“容器”这个概念完成了对经典 PaaS 项目的“降维打击”，但是 Docker 项目和 Docker 公司，兜兜转转了一年多，却还是回到了 PaaS 项目原本深耕了多年的那个战场： 如何让开发者把应用部署在我的项目上
3 群雄并起
而谈到 Docker 项目的定位问题，就不得不说说 Docker 公司的老朋友和老对手CoreOS了。 CoreOS 是一个基础设施领域创业公司。 它的核心产品是一个定制化的操作系统，用户可以按照分布式集群的方式，管理所有安装了这个操作系统的节点。从而，用户在集群里部署和管理应用就像使用单机一样方便了。
Docker 项目发布后，CoreOS 公司很快就认识到可以把“容器”的概念无缝集成到自己的这套方案中，从而为用户提供更高层次的 PaaS 能力。所以，CoreOS 很早就成了 Docker项目的贡献者，并在短时间内成为了 Docker 项目中第二重要的力量。
然而，这段短暂的蜜月期到 2014 年底就草草结束了。CoreOS 公司以强烈的措辞宣布与Docker 公司停止合作，并直接推出了自己研制的 Rocket（后来叫 rkt）容器。
这次决裂的根本原因，正是源于 Docker 公司对 Docker 项目定位的不满足。Docker 公司解决这种不满足的方法就是，让 Docker 项目提供更多的平台层能力，即向 PaaS 项目进化。而这，显然与 CoreOS 公司的核心产品和战略发生了严重冲突。
也就是说，Docker 公司在 2014 年就已经定好了平台化的发展方向，并且绝对不会跟CoreOS 在平台层面开展任何合作。这样看来，Docker 公司在 2014 年 12 月的DockerCon 上发布 Swarm 的举动，也就一点都不突然了。
Swarm 的最大亮点，则是它完全使用Docker 项目原本的容器管理 API 来完成集群管理，比如： docker run -H “ 我的 Swarm 集群 API 地址 “ “ 我的容器 “ 在部署了 Swarm 的多机环境下，用户只需要使用原先的 Docker 指令创建一个容器，这个请求就会被 Swarm 拦截下来处理，然后通过具体的调度算法找到一个合适的 Docker Daemon 运行起来。
而此时已经大红大紫到“不差钱”的Docker 公司，开始及时地借助这波浪潮通过并购来完善自己的平台层能力。其中一个最成功的案例，莫过于对 Fig 项目的收购。Fig 项目基本上只是靠两个人全职开发和维护的，可它却是当时 GitHub 上热度堪比 Docker 项目的明星。
Fig 项目之所以受欢迎，在于它在开发者面前第一次提出了“容器编排”（Container Orchestration）的概念。
Fig 的工作实际上非常简单：假如现在用户需要部署的是应用容器 A、数据库容器 B、负载均衡容器 C，那么 Fig 就允许用户把 A、B、C 三个容器定义在一个配置文件中，并且可以指定它们之间的关联关系，比如容器 A 需要访问数据库容器 B。
Fig 就会把这些容器的定义和配置交给 Docker API 按照访问逻辑依次创建，你的一系列容器就都启动了；而容器 A 与 B 之间的关联关系，也会交给 Docker 的 Link 功能通过写入hosts 文件的方式进行配置。更重要的是，你还可以在 Fig 的配置文件里定义各种容器的副本个数等编排参数，再加上 Swarm 的集群管理能力，一个活脱脱的 PaaS 呼之欲出。
Fig 项目被收购后改名为 Compose，它成了 Docker 公司到目前为止第二大受欢迎的项目，一直到今天也依然被很多人使用。
而除了这个异常繁荣的、围绕着 Docker 项目和公司的生态之外，还有一个势力在当时也是风头无两，这就是老牌集群管理项目 Mesos 和它背后的创业公司 Mesosphere。 Mesos 作为 Berkeley 主导的大数据套件之一，是大数据火热时最受欢迎的资源管理项目，也是跟 Yarn 项目杀得难舍难分的实力派选手。 虽然不能提供像 Swarm 那样的原生 Docker API，Mesos 社区却拥有一个独特的竞争力：超大规模集群的管理经验。
这时，如果你再去审视当时的容器技术生态，就不难发现 CoreOS 公司竟然显得有些尴尬了。它的 rkt 容器完全打不开局面，Fleet 集群管理项目更是少有人问津，CoreOS 完全被Docker 公司压制了。 而处境同样不容乐观的似乎还有 RedHat，作为 Docker 项目早期的重要贡献者，RedHat也是因为对 Docker 公司平台化战略不满而愤愤退出。但此时，它竟只剩下 OpenShift 这个跟 Cloud Foundry 同时代的经典 PaaS 一张牌可以打，跟 Docker Swarm 和转型后的Mesos 完全不在同一个“竞技水平”之上。
那么，事实果真如此吗？
2014 年注定是一个神奇的年份。就在这一年的 6 月，基础设施领域的翘楚 Google 公司突然发力，正式宣告了一个名叫 Kubernetes 项目的诞生。而这个项目，不仅挽救了当时的CoreOS 和 RedHat，还如同当年 Docker 项目的横空出世一样，再一次改变了整个容器市场的格局。
4 尘埃落定
在 2014~2015 年间，整个容器社区可谓热闹非凡，这令人兴奋的繁荣背后，却浮现出了更多的担忧。Docker 项目此时已经成为 Docker 公司一个商业产品。而开源，只是 Docker 公司吸引开发者群体的一个重要手段。 而真正令大多数人不满意的是，Docker 公司在 Docker 开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微软）的切身利益。
相信很多容器领域的老玩家们都听说过，Docker 项目刚刚兴起时，Google 也开源了一个在内部使用多年、经历过生产环境验证的 Linux 容器：lmctfy（Let Me Container That For You）。 然而，面对 Docker 项目的强势崛起，这个对用户没那么友好的 Google 容器项目根本没有招架之力。所以，知难而退的 Google 公司，向 Docker 公司表示了合作的愿望：关停这个项目，和 Docker 公司共同推进一个中立的容器运行时（container runtime）库作为Docker 项目的核心依赖。
不过，Docker 公司并没有认同这个明显会削弱自己地位的提议，还在不久后，自己发布了一个容器运行时库 Libcontainer。这次匆忙的、由一家主导的、并带有战略性考量的重构，成了 Libcontainer 被社区长期诟病代码可读性差、可维护性不强的一个重要原因。
2015年容器领域的其他几位玩家开始商议“切割”Docker 项目的话语权。而“切割”的手段也非常经典，那就是成立一个中立的基金会。于是，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范。
这套标准和规范，就是 OCI（ Open Container Initiative ）。OCI 的提出，意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。这样做，一方面可以改善 Docker 公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于 Docker 项目构建各自的平台层能力提供了可能。
不过，不难看出，OCI 的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果。所以，尽管 Docker 是 OCI 的发起者和创始成员，它却很少在 OCI 的技术推进和标准制定等事务上扮演关键角色，也没有动力去积极地推进这些所谓的标准。
Docker 之所以不担心 OCI 的威胁，原因就在于它的 Docker 项目是容器生态的事实标准，而它所维护的 Docker 社区也足够庞大。可是，一旦这场斗争被转移到容器之上的平台层，或者说 PaaS 层，Docker 公司的竞争优势便立刻捉襟见肘了。
在这个领域里，像 Google 和 RedHat 这样的成熟公司，都拥有着深厚的技术积累；而像CoreOS 这样的创业公司，也拥有像 Etcd 这样被广泛使用的开源基础设施项目。可是 Docker 公司呢？它却只有一个 Swarm。
所以这次，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以 Docker 公司为核心的容器商业生态。
而为了打造出这样一个围绕 Kubernetes 项目的“护城河”，CNCF 社区就需要至少确保两件事情：
- Kubernetes 项目必须能够在容器编排领域取得足够大的竞争优势
- CNCF 社区必须以 Kubernetes 项目为核心，覆盖足够多的场景
在容器编排领域，Kubernetes 项目需要面对来自 Docker 公司和 Mesos 社区两个方向的压力。不难看出，Swarm 和 Mesos 实际上分别从两个不同的方向讲出了自己最擅长的故事：Swarm 擅长的是跟 Docker 生态的无缝集成，而 Mesos 擅长的则是大规模集群的调度与管理。
这两个方向，也是大多数人做容器集群管理项目时最容易想到的两个出发点。也正因为如此，Kubernetes 项目如果继续在这两个方向上做文章恐怕就不太明智了。
所以这一次，Kubernetes 选择的应对方式是：Borg。 如果你看过 Kubernetes 项目早期的 GitHub Issue 和 Feature 的话，就会发现它们大多来自于 Borg 和 Omega 系统的内部特性，这些特性落到 Kubernetes 项目上，就是 Pod、 Sidecar 等功能和设计模式。 这就解释了，为什么 Kubernetes 发布后，很多人“抱怨”其设计思想过于“超前”的原因：Kubernetes 项目的基础特性，并不是几个工程师突然“拍脑袋”想出来的东西，而是 Google 公司在容器化基础设施领域多年来实践经验的沉淀与升华。这正是 Kubernetes 项目能够从一开始就避免同 Swarm 和 Mesos 社区同质化的重要手段。
于是，CNCF 接下来的任务就是，如何把这些先进的思想通过技术手段在开源社区落地，并培育出一个认同这些理念的生态？这时，RedHat 就发挥了重要作用。 当时，Kubernetes 团队规模很小，能够投入的工程能力也十分紧张，而这恰恰是 RedHat的长处。更难得的是，RedHat 是世界上为数不多的、能真正理解开源社区运作和项目研发真谛的合作伙伴。 所以，RedHat 与 Google 联盟的成立，不仅保证了 RedHat 在 Kubernetes 项目上的影响力，也正式开启了容器编排领域“三国鼎立”的局面。
这时，我们再重新审视容器生态的格局，就不难发现 Kubernetes 项目、Docker 公司和Mesos 社区这三大玩家的关系已经发生了微妙的变化。其中，Mesos 社区与容器技术的关系，更像是“借势”，而不是这个领域真正的参与者和领导者。这个事实，加上它所属的 Apache 社区固有的封闭性，导致了 Mesos 社区虽然技术最为成熟，却在容器编排领域鲜有创新。
Docker 公司对 Mesos 社区也是类似的看法。所以从一开始，Docker 公司就把应对 Kubernetes 项目的竞争摆在了首要位置：一方面，不断强调“Docker Native”的“重要性”，另一方面，与 Kubernetes 项目在多个场合进行了直接的碰撞Kubernetes 项目并没有跟 Swarm 项目展开同质化的竞争，所以“Docker Native”的说 辞并没有太大的杀伤力。相反地，Kubernetes 项目让人耳目一新的设计理念和号召力，很 快就构建出了一个与众不同的容器编排与管理的生态。 就这样，Kubernetes 项目在 GitHub 上的各项指标开始一骑绝尘，将 Swarm 项目远远地甩在了身后。
而Kubernetes 的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构，即：从 API 到容器运行时的每一层，Kubernetes 项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes 项目的每一个阶段。Kubernetes 项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于 Kubernetes API 和扩展接口的二次创新工作，比如：
- 目前热度极高的微服务治理项目 Istio；
- 被广泛采用的有状态应用部署框架 Operator；
就这样，在这种鼓励二次创新的整体氛围当中，Kubernetes 社区在 2016 年之后得到了空前的发展。更重要的是，不同于之前局限于“打包、发布”这样的 PaaS 化路线，这一次容器社区的繁荣，是一次完全以 Kubernetes 项目为核心的“百家争鸣”。
面对 Kubernetes 社区的崛起和壮大，Docker 公司也不得不面对自己豪赌失败的现实。但在早前拒绝了微软的天价收购之后，Docker 公司实际上已经没有什么回旋余地，只能选择逐步放弃开源社区而专注于自己的商业化转型。 所以，从 2017 年开始，Docker 公司先是将 Docker 项目的容器运行时部分 Containerd捐赠给 CNCF 社区，标志着 Docker 项目已经全面升级成为一个 PaaS 平台；紧接着，Docker 公司宣布将 Docker 项目改名为 Moby，然后交给社区自行维护，而 Docker 公司的商业产品将占有 Docker 这个注册商标。 Docker 公司这些举措背后的含义非常明确：它将全面放弃在开源社区同 Kubernetes 生态的竞争，转而专注于自己的商业业务，并且通过将 Docker 项目改名为 Moby 的举动，将原本属于 Docker 社区的用户转化成了自己的客户
- 2017 年 10 月，Docker 公司出人意料地宣布，将在自己的主打产品 Docker 企业版中内置Kubernetes 项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。
- 2018 年 1 月 30 日，RedHat 宣布斥资 2.5 亿美元收购 CoreOS。
- 2018 年 3 月 28 日，这一切纷争的始作俑者，Docker 公司的 CTO Solomon Hykes 宣布辞职，曾经纷纷扰扰的容器技术圈子，到此尘埃落定