目录
2013年
Docker项目开源
2013年，以AWS及OpenStack，以Cloud Foundry为代表的开源Pass项目，成了云计算领域的一股清流，pass提供了一种“应用托管”的能力。
当时的虚假机和云计算已经是比较普遍的技术了，主流用法就是租一批AWS或者OpenStack的虚拟机，然后用脚本或者手工的方式在机器上部署应用
Cloud Foudry这样的Pass项目，核心组件就是一套打包和分发机制，会调用操作系统的Cgroups和Namespace机制 为每个应用单独创建“沙盒”的隔离环境，然后在“沙盒”中运行这些进程，实现了多用户、批量、隔离运行的目的。
这个“沙盒”，就是所谓的容器。
这一年还叫dotCloud的Docker公司，也是Pass热潮中的一员。只不过，比起Heroku、Pivotal、Red Hat等大佬，dotCloud公司显得太微不足道，主打产品跟主流的CloudFoundry社区脱节，眼看就要阵亡的时候，dotCloud公司决定开源自己的容器项目Docker
“容器”其实不是什么新鲜的东西，不是Docker发明的，当时最热的Pass项目Cloud Foundry中，容器也只是最底层、最不受关注的一部分。
短短几个月，Docker就迅速崛起了，然后Cloud Foundry等所有Pass社区还没来得及成为对手，就已经被淘汰了。
Docker项目大部分和Cloud Foundry容器大部分功能和实现原理是一样的，但是不一样的“Docker镜像”，解决了环境打包的问题，直接打包了应用运行所需要的整个操作系统，赋予了本地环境和云端环境调度一致的能力，避免了用户通过“试错”来匹配不同环境之间差异的痛苦过程， 这也是Docker的精髓。
Pass的定义变成了一套以Docker容器为技术核心，以Docker镜像为打包标准的“容器化”思路
2013年年底，dotClound公司正式改名为Docker公司
2014年
Docker发布Docker Swarm
Docker发布Docker Swarn，以一个完整的整体来对外提供集群管理功能，最大的亮点就是完全使用Docker项目原来的容器管理API来完成集群管理。
docker run "容器"
只需要变成
docker run -H "swarm集群API地址" "容器"
用户只需要使用原先的docker指令创建一个容器，这个请求就会被swarm拦截处理，通过具体的调度算法找到一个适合的Docker Daemon。
这种方式对已经熟悉docker命令行的开发者们非常的友好。
Docker收购Fig，并改名Compose
Docker公司收购了Fig项目，后改名为（Compose）。
Fig项目在开发者面前第一次提出了“容器编排”（Container Orchestration）
在云计算领域，“编排”主要指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程
而容器时代，“编排”就是对Docker容器的一系列定义、配置和创建动作的管理。
Docker和Mesosphere公司的竞争
除了Docker生态外，Mesos和背后的创建公司Mesosphere也是一个非常大的热力，Mesos是大数据最受欢迎的资源管理项目，跟Yarn项目竞争的实力派对手。
大数据关注的计算密集型离线业务，其实不像Web服务那样适合用容器进行托管和扩容，也没有应用打包的强烈需要，所以Hadoop、Spark等项目现在也没在容器技术投入很大的精力，但是Mesos作为大数据套件之一，天生的两层调度机制让它非常容易从大数据领域独立出来去支持更广泛的Pass业务，所以Mesos公司发布了Marathon项目，成为了Docker Swarm的一个强有力的竞争对手。
虽然不能提供像Swarm那样的Docker API，但是Mesos社区拥有一个非常大的竞争力：超大规模集群管理经验
Mesos+Marathon组合进化成了一个调度成熟的Pass项目，同时能支持大数据业务，
Docker和CoreOS
CoreOS是一个基础设施领域创业公司，核心产品是一个定制化的操作系统，用户可以按照分布式集群的方式，管理所有安装了这个系统的节点，使用用户在集群里部署应用像使用单机一样方便
Docker项目发布后，Corecd很快认识到可以把容器的概念无逢集成到自己的这套方案中，从而为用户提供更高层次的Pass能力，所以CoreOS很早就成了Docker项目的贡献者，然而在2014年结束了合作，推出了自己的容器Rocket（rkt），然而这个rkt容器完全被Docker公司压制了。
OCI标准制定
由CoreOS、Google、RatHat等公司共同宣布，Docker公司将Libcontainer（容器运行时库）捐出，并改名为RunC项目，交由一个完全中立的基金会管理，以RunC为依据共同制定一套容器和镜像的标准规范
，叫OCI（Open Container Initiative），意在将容器运行时和镜像的实现从Docker项目中完全剥离出来，以此来压制Docker公司一家独大的现状，同时也为不依赖Docker项目构建平台层能力提供了可能。
不过并没有改变Docker在容器领域一家独大的现状
Kubernetes诞生
2014年6月，基础设施领域的领先者Google发，正式宣告了Kubernetes项目的诞生（Borg的开源版本），如同Docker横空出世一样，再一次改变了容器市场的格局。
微软、RedHat、IBM、Docker加入Kubernetes社区
2015年
CNCF基金会成立
为了在容器编排地位取得绝对的优势，同Swarm和Mesos竞争，Google、RedHat等开源基础设施公司，共同发起了一个名为CNCF的基金会：希望以Kubernetes为基础，建立一个由开源基础设施领域厂商主导、按照独立基础会方式运营的平台社区，来对抗以Docker公司为核心的容器商业生态。简单的说就是打造一个围绕Kubernetes项目的“护城河”。
Docker擅长Docker生态的无缝集成，Mesos擅长大规模集群的调度与管理，Kubernetest选择了Pod、Sidecar等功能和模式作为切入点（大多来自Borg和Omega系统的内部特性）。
Kubernetes的团队规模很少，投入的工程能力有限，RedHat在这时候和Google联盟，正式开户了容器编排“三国鼎立”的书面。
Kubernetes来自Google公司在容器化基础设施领域多年来实践经验的沉淀和升华，在Github上的各项指标一路飙升，将Swarm项目远远地甩在了后边。
同年，Kubernetes发布Helm软件包管理系统、kubeam安装工具、发布Mikibube等一列更新操作
CNCF社区迅速增加了Prometheus、Fluentd、OpenTracing、CNI等一系列容器生态的知名工具和项目
大量的公司和创建团队将注意力投向CNCF社区而不再是Docker公司
2016年
Docker公司放弃现有的Swarm项目，将容器编排和集群管理功能内置到Docker中
面对CNCF的竞争优势，Docker公司宣布放弃现有的Swarm项目，将容器编排和集群管理功能内转到Docker项目当中。
然而这种改变带来的技术复杂度和维护难度，给Docker项目造成了非常不利的书面
Kuberntes支持OpenApi，给开发人员定制化提供更大的灵活性
不同于Docker公司，Kubernetes推进“民主化”架构：从API到容器运行的每一层，都给开发者暴露出了可扩展的插件机制，鼓励用户通过代码的方式介入每一个阶段。
Kubernetes项目的这个变革非常有效，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新产品：
- 热度极高的Istio微服务治理工具
- 应用部署框架Operator
- Rook开源创业项目，把Ceph重量级产品封装成了简单易用的容器存储插件
Docker公司在Kubernetes社区的崛起和壮大后，败下阵来。
2017年
Docker将Containerd捐献给CNCF社区
Docker公司将容器运行时部分Containerd捐献给CNCF社区，标志着Docker项目你下面升级成为了一个Pass平台，Docker公司宣布将Docker项目改名为Moby，交给社区自行维护，而Docker公司的商业产品还占有Docker这个注册商标。
同年10月，Docker宣布将在自己主打产品Docker企业版中内置Kubernetes项目，持续了两年的容器编排之争终于落下帷幕
