目标
- 了解容器诞生的背景
- 了解Docker容器生态圈的崛起和没落
- 了解kubernetes的诞生背景和Docker的区别
初出茅庐
Docker 镜像解决了PaaS项目中一直备受诟病的打包问题，因此展露了自己的“才能”，在当时大红大紫的Cloud Foundry由于对Docker的轻视，被打得屁滚尿流，直接退出历史舞台。
PaaS开源项目
在2013年，流行的云计算领域中，以Cloud Foundry为代表的开源PaaS项目，成为了当时云计算领域的一股清流。
PaaS开源项目的出现就是为了解决在云端虚拟机部署和本地环境部署应用时的环境不一致的问题。
比如，当虚拟机创建好之后，运维人员只需要在这些机器上部署一个Cloud Foundry项目，然后开发者只要执行一条命令，就可以把本地应用部署到云上，十分方便。
还是以这个例子，当执行cf push 应用命令,就会把应用的可执行文件和启动脚本打包，然后上传到云上Cloud Foundry的存储中，然后Cloud Foundry会通过调度器选择一个可以运行这个应用的虚拟机，然后通知这个机器上的Agent下载应用压缩包并启动。
由于一个虚拟机上需要启动多个来自不同用户的应用，Cloud Foundry会调用系统的Cgroups和NameSpace机制为每一个应用单独创建一个 “沙盒” 。这个沙盒，就是所谓的“容器”
容器和Docker镜像
所以，即便Docker项目刚开源时，也依然不温不热，无人关注。因为Docker项目实际上跟Cloud Foundry的容器并没有太大不同，“容器”的概念并不是什么新的黑科技，更何况Cloud Foundry项目中，容器也只是其最底层，最无人问津的那部分。
但是，Docker在短短几个月，就迅速崛起，打的老前辈Cloud Foundry一个措手不及，仅因为Docker项目中的一个小小的创新—docker镜像。
PaaS之所以可以帮助用户大规模的部署应用到集群里，是因为它提供了一套应用打包的功能，但是PaaS用户必须为每种语言、每种框架甚至每个版本的应用维护一个打好的包，这个打包过程没有任何章法可循。而且在本地运行得好好的应用，却需要做很多修改和配置工作才能在PaaS中运行起来。而且这些修改和配置工作没有任何经验可以借鉴，需要不断试错，直到摸清。
而Docker镜像恰好解决了上述中PaaS项目的打包问题。大多数的Docker镜像实际上就是由完整操作系统的所有文件目录打包而成的，所以这个docker镜像里的内容跟你本地开发和测试环境用的操作系统完全一致。换句话说：Docker镜像，只要一经打包，就可以在任何地方创建一个“沙盒”，然后在“沙盒”环境解压这个镜像，就可以运行你的应用了。
崭露头角
Docker以憨态可掬的姿态迎接开发者，拉近了docker项目和开发者之间的距离。Docker猛然走红，正所谓得开发者的天下！
得开发者得天下
Docker项目的走红的原因有许多，其中主要原因在于，Docker公司的战略目标之一就是，坚持把开发者群体放在至高无上的位置
Docker镜像通过技术后端解决了PaaS的根本性问题，另一方面是因为它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了广大的开发者群体手里。
Docker的崛起并非偶然，Docker的推广策略从一开始就是把每一位后端开发者作为主要推广目标。
简洁的UI，有趣的demo，这种同开发者之间与生俱来的亲近感，也是让Docker成功的因素。
改名Docker
Docker项目成为了最亮的星，但是就在这是其目公司dotCloud突然改名为“Docker”。这也就意味着，任何人在商业活动中使用Docker这个单词以及Docker鲸的logo，都会可能受到法律警告。
相对于这件事，Docker公司在2014年年底发布的swarm项目显得更加“爆炸”。
Docker公司意识到了，docker项目虽然备受追捧，但是用户最终要部署的是他们的网站、数据库甚至是云计算业务。这就意味着，只有那些能够为用户提供平台层能力的工具才会真正成为开发者关心和愿意付费的产品。而Docker项目这样一个只能用来创建和和启停容器的小工具，最终只能充当这些平台项目的“幕后英雄”。
小小的docker镜像功能为什么可以击败当时大红大紫的Cloud Foundry呢？
- Docker镜像通过技术后端解决了PaaS的根本性问题
- 2013年~14年，以Cloud Foundry为代表的PaaS项目逐渐完成了教育用户和开拓市场的艰巨任务，这个过程中，也将相关的概念落地。而Docker的出现时机也是恰到好处，这也是Docker迅速崛起的主要原因之一。
- Docker对开发者十分友好。与开发者之间有着与生俱来的密切关系。
群雄并起
Swarm和Fig组合拳为Docker公司在容器生态圈中站稳了脚，对着Google和red hat等想要进入容器圈子分杯羹的“第三者”更是拳打脚踢。
Mesos的超大规模集群管理，因为深受大型企业喜欢，所以在生态圈中也获得了三分地。此后，容器圈子二分天下！
Swarm的诞生
Docker公司为什么发布Swarm项目，Swarm项目的定位是什么? 这些不得不提起，当时Docker的老朋友和老对手CoreOS公司了
CoreOS公司的核心产品是一个定制化的操作系统。用户可以按照分布式集群的方式管理所有安装的这个操作系统的节点，如此以来，用户在集群里部署和管理应用就像使用单机一样方便了。
自然而然，CoreOS公司和Docker公司成为了好基友，两者结合，为用户提供了更高层次的PaaS能力。
然而，好景不长。2014年年底，CoreOS公司以强烈的措辞宣布与docker公司停止合作，并直接推出了自己研制的rocket容器。
这次决裂的根本原因是docker公司野心已经不满足现状，早在14年就规划好了平台化的发展方向，docker公司不满足docker项目的定位，想将docker项目打造出具备平台层能力的PaaS项目。这显然与CoreOS公司的核心产品和战略发生了冲突。
Docker生态的发展
CoreOS是依托于一系列开源项目一层层搭建起来的平台产品。而Swarm项目则是以一个整体来对外提供集群管理功能。而它最大的亮点是完全使用docker项目原本的容器管理API来完成集群管理的。
在部署了Swarm的多机环境中，用户只需要使用原先的docker指令创建一个容器，Swarm就会拦截这个请求并处理，然后通过具体的调度算法找到一个合适的docker Daemon运行起来。
也就是说Swarm的学习成本特别低，只要了解过docker命令的用户就很容易掌握。相比之下，CoreOS的解决方案就显得非常另类。
docker公司在14年~15年这段时期迅速走红，催生了一个非常繁荣的docker生态。并且在这个时期通过并购来完善自己的平台层能力，其中最成功的案例莫过于收购fig项目。
fig项目他首次提出了容器编排的概念。其实"编排"在云计算行业不算是新词.
在容器时代,编排就是对Docker容器的一系列定义配置和创建动作的管理。
容器编排的任务实际上非常简单，假如现在用户需要部署的是应用容器A，数据库容器B，负载均衡容器C，那么就允许用户把A,B,C这三个容器定义在一个配置文件中，并且可以指定他们之间的关联关系。比如，应用容器A可以访问数据库容器B
Fig的"容器编排"加上Swarm的集群管理能力，一个活脱脱的PaaS就呼之欲出了。 （Docker公司的组合拳）
在当时的容器生态里，还有很多令人眼前一亮的开源项目或公司。比如专门负责处理容器网络的SocketPlane项目,专门负责处理容器存储的Flocker项目。专门给Docker集群做图形化管理界面和对外提供云服务的Tutum项目等
异军突起
Mesosphere公司发布了一个名为marathon的项目和这个项目很快就成为了docker swarm的有力竞争对手。它虽然不能提供像swarm那样的原生Docker api 但是Mesosphere公司的Mesos社区拥有丰富的超大规模集群的管理经验。
早在几年前，Mesosphere公司就已经通过了万台节点的验证。在这波容器化浪潮中，Mesosphere公司不失时机的提出了一个名为“DC/OS”(数据中心操作系统)的口号和产品，旨在让用户能够像管理一台机器那样管理一个上万级别的物理机集群，并且使用docker容器在这个集群里自由的部署应用。而这对于许多大型企业来说非常具备吸引力。
比如Airbnb（空中食宿网）、eBay（电子港湾）和Netflix。Mesos管理着Twitter超过30,0000台服务器上的应用部署。
面对Mesos的异军突起，容器生态圈成了二分天下的态势。
尘埃落定
kubernetes的诞生带着血雨腥风，docker的没落也因为其傲慢的姿态和闭关锁国的商业模式
傲慢的Docker
docker项目此时已经成为了Docker公司一个商业产品，而开源只是Docker公司吸引开发者群体的一个重要手段。
在此时期，docker公司用实际行动挑战了其他玩家的切身利益。即便当时互联网资深老前辈谷歌公司向Docker公司表示了合作的愿望，与其共同推进一个中立的容器运行时库作为docker项目的核心依赖。但是却遭到了拒绝，不仅如此docker自己还推出了一个容器运行时库libcontainer。
Docker强硬的态度以及docker项目在高速迭代中表现出来的不稳定和频繁变更的问题，开始让社区叫苦不迭. 于是容器领域另外几个玩家开始商议推出一套容器和镜像的标准和规范(OCI) ，试图切割docker在容器领域的话语权.但是丝毫没影响到docker公司在容器领域一家独大的现状。
kubernetes降临
愤愤不平的谷歌，red hat等开源基础设施领域玩家共同牵头成立了一个CNCF基金会。
这个基金会的目的其实很简单：以kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的按照独立基金会运方式运营的平台及社区来对抗以docker公司为核心的容器商业生态。
kubernetes项目的核心竞争力就是来自于谷歌内部的基础服务设施的一部分: borg
最开始用户很难理解这种“超前的”设计思想。但是红帽有着非常成熟的社区管理体系 ，这使得kubernetes项目在交由社区维护后得到了快速发展。
kubernetes项目不以docker为核心依赖，其耳目一新的设计理念和号召力，很快构建出了一个与众不同的容器编排和管理生态。
就这样kubernetes项目将docker swarm项目远远的甩在了身后。
在这个基础之上，CNCF社区开始推出了fluentd，openTracing，CNI等一系列容器生态的知名工具和项目。
越来越多的用户被CNCF社区吸引过来，大量的公司和创业团队也针对CNCF社区制定了推广策略。
Docker闭关锁国
而docker公司意识到了swarm项目目前唯一的竞争优势就是跟docker项目的无缝集成。那么如何让这种优势最大化呢？就是把swarm内置的docker项目中。
相反kubernetes项目的应对策略则是反其道而行之，开始在整个社区推行“民主化”架构，即从API到容器运行时的每一层，kubernetes项目都为开发者暴露了可以扩展的插件机制，鼓励用户通过代码的方式介入项目的每一个阶段。
在这种鼓励创新的整体氛围中，kubernetes社区在2016年之后得到了空前的发展。
2017年10月，docker公司出人意料的宣布在docker企业版中内置kubernetes项目。
在2018年3月，docker公司的CTO宣布辞职，曾经纷纷扰扰的容器技术圈子至此尘埃落定。
