2013

背景

后端技术没有令人兴奋的新技术产生，云计算技术具象化成了实实在在的虚拟机的账单。

亮点

• 开源项目CloudFoundry，开启以开源PaaS为核心构建平台层服务能力的变革。

• dotCloud公司开源自己的容器项目Docker，提出docker镜像概念

    PaaS项目广泛接纳的一个重要原因，是他提供了一种“应用托管的能力”。当时虚拟机是普遍技术，部署过程中会遇到云端虚拟机和用户本地环境不同的问题，所以当时云计算服务比的就是谁能更好的模拟服务器本地环境。而PaaS开源项目就是解决这个问题的最佳方案之一。

    Cloud Foundary项目核心是应用的打包和分发机制。用户通过cf push，将应用的可执行文件和启动脚本打的这个包，上传到Cloud Foundary的存储中，然后Cloud Foundary通过调度器选择一个可用的虚拟机，通知该虚拟机agent下载这个包，并启动应用。

    为了在一个vm上运行同时运行多个应用，Cloud Foundary调用操作系统的Namespace和  Cgroups  机制为每个应用创造一个单独的隔离环境“沙盒”来在其中运行应用，这个“沙盒”就叫做容器。

传统PaaS项目的不足

    PaaS 之所以能够帮助用户大规模部署应用到集群里，是因为它提供了一套应用打包的功能。但，一旦用上PaaS，就要为每种语言，每个框架去维护一个包。而且，因为本地环境和PaaS环境的差异性，这个在本地环境调试没问题的包很可能需要做很多修改才能在PaaS里运行起来，因此，虽然cf push能够一键部署，但是维护这个包的成本太高了。

    docker镜像却通过将应用的运行的整个操作系统直接打包，来保证远端PaaS和本地环境的完全一致性，从而从根本上解决上述问题。

    因此，docker的核心就是通过打包整个操作系统，保证应用运行的本地环境和远端环境的高度一致性，从而解决了包的在PaaS项目中的繁琐的配置问题。缺点：没办法代替PaaS大规模应用部署的职责。

针对这一缺点：

2013-2014

• Docker容器集群管理的开源项目密集出现：Deis和Flynn。

• Docker公司发布自己容器集群管理项目：Swarm

> Docker公司为什么返回去做PaaS场景（如何让开发者把应用部署到Docker上）？

    因为用户最终要部署的，还是他们的网站，服务数据库甚至是云计算业务。这就意味着，要想消费者买单，就必须提供平台层的能力给消费者，而Docker项目只是一个用来启停容器的小工具，是不足以满足平台层的能力的，缺少了提供部署的能力。

• Docker公司的老对手，CoreOS。

    这是一家基础设施领域的公司。产品是一个操作系统，用户可以按照分布式集群的方式，管理所有安装了这个操作系统的节点。从而使用户在集群中部署和管理应用就像使用单机一样方便了。Docker容器发布以后，CoreOS将这一技术无缝集成到自己的操作系统的使用中，提供更高层次的PaaS能力。

蜜月期结束，分道扬镳。

    当Docker公司将自己的Docker容器进一步向PaaS演进，提供更多的平台层功能的时候，这跟CoreOS他们家那套操作系统的核心利益冲突了，于是各做各的了。CoreOS 2014高调宣布与Docker公司决裂，推出自家的Rocket容器，同时Docker公司也在2014年的DockCon上发布了上面提到的Swarm提供PaaS能力。

Swarm与CoreOS产品对比

2014-2015 构建Docker生态

在这一两年里，围绕着Docker进行的各个层次的继承和创新项目层出不穷。Docker公司开始通过并购完善自己的平台层能力，比较出名的就是收购了Fig项目。

Fig项目受欢迎的原因

 面向开发者第一次提出了容器编排的概念(Container Orchestration)的概念。

编排

• 云计算领域：指用户如何通过某些工具或者配置来完成一组VM以及相关资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些配置好的规则，来执行逻辑的过程。

• 容器领域：对Docker领域的一些列定义配置和创建动作的管理。

Fig做了什么

> 用户需要的多个容器（应用容器，数据库容器，负载均衡容器）之间的关联关系，允许用户放到同一个配置文件当中。然后通过以下命令，即根据用户定义的关于这些容器的配置用Docker的 API进行访问和创建配置，容器起来之后，他们的关联关系也会通过Link功能写入hosts文件进行配置。

$  fig up

集群管理和编排

既然容器集群管理工具Swarm和容器编排工具Compose都在Docker麾下，那么这两种工具在概念上的区别是什么？

• 集群管理工具：需要处理的是集群的节点管理（增、删），HA等方面。

•  容器编排工具：通过配置文件，支持对多个容器进行配置关联满足应用服务。

Fig被收购后被命名为Compose

其他大事记

• 专门处理容器网络的SocketPlane项目被Docker公司收购

• 处理容器存储的Floker项目被EMC收购

• 做Docker图形化管理页面并对外提供云服务的Tutum项目被Docker公司收购

另一套集群管理系统--Mesos

Docker为代表的势力之外，还有一个势力--老牌集群管理项目，Mesos（背后的公司为Mesosphere）。

Mesos优势

• 具备超大规模集群的管理经验。

• 天生的两侧调度机制，能够让他从原有的大数据领域抽身出来，支持受众更加广泛的PaaS业务。

因此，Mesosphere公司发布了Marathon项目，实现了应用托管和负载均衡等PaaS功能，形成了一个高度成熟的PaaS项目，同时也能够很好的支持大数据业务。

至此，两大巨头Mesosphere和Docker两家公司占据鳌头，CoreOS的rkt容器打不开局面，ReadHat也也只剩下OpenShift这个跟CloudFoundary同时代的经典PaaS能力。但是，峰回路转。

2014年6月

同样是2014年，Google发布Kubernetes项目。挽救了CoreOS和RedHat，并再次改变了整个容器市场的格局。

    Docker公司在繁荣的背后，也因为在Docker开源项目的发展上，始终保持着绝对的地位和发言权，并在多个场合挑战到了其他公司（CoreOS、甚至Google）的利益。同时，在拒绝了Google公司合作开发一个中立的容器运行时库作为Docker项目的核心依赖后(防止威胁自家地位），自家推出了一个不稳定、频繁变更、后来被社区长期诟病的一个容器运行时库Libcontainer。

2015年

容器领域的其他几位玩家成立了一个中立基金会，切割Docker项目的话语权。

2015年6月22日

Docker公司牵头，CoreOS、Google、RedHat等公司共同宣布，Docker公司捐出LibContainer，改名为RunC项目，并交给中立基金会，大家共同制定一套容器和镜像的标准和规范--OCI (Open Cotainer Initiative)

• OCI目的是把容器运行时和镜像的实现从Docker项目中完全剥离出来。

 OCI的结果

• OCI 只是这些玩家为了自身利益协商的妥协结果，尽管Docker公司是OCI的发起人，但是它却没有很积极的推进OCI的规则制定和技术发展，导致迄今为止OCI组织效率低下。

• 所以，OCI并没有改变Docker公司一家独大的事实。

第二把武器

虽然Docker项目是容器生态的标准事实，但是仍然有另一个既定事实，Docker公司他们家的PaaS层的能力是比不上Google和RedHat这些公司的，技术积累不够。

于是，Google和RedHat，牵头发起CNCF（Cloud Native Computing Foundation)基金会。期望以Kubernetes项目为基础，建立一个有开源基础设施领域厂商主导的，按照独立基金会运营的平台及社区，对抗以Docker公司为核心的容器商业生态。

对抗Docker公司的Kubernetes

要保证至少两件事：

• Kubernetes项目必须能够在容器编排领域取得竞争优势（Swarm重在无缝集成Docker，Mesos重在大规模集群的调度和管理）

• CNCF社区必须以Kubernetes为核心覆盖足够多的场景

Kubernetes选择

• Kubernetes设计思想来源于Borg（[Borg: Google内部的大型集群管理系统](https://zhuanlan.zhihu.com/p/30355957)）和Omega的内部特性，这些特性落到Kubernentes上，就是pod和SideCar等功能和设计模式。

• Google 牵手RedHat成立联盟，将这些先进思想落地Kubernetes项目

上图是Borg整体架构的概览，我们可以看到的是

• 
  

  • 每个集群叫一个cell，会有一个对应的BorgMaster。

         这里BorgMaster画了好多层是刻意的，为了high availability每个cell有5个BorgMaster，但是不是这5个BorgMaster里面只有一个是真正的leader。这五个BorgMaster有一个基于Paxos的储存。

        BorgMaster这类软件一般不会有太多的外部的依赖，文章中讲到选完BorgMaster的leader之后会去Chubby拿个所告诉大家哪个是leader，但是Borg本身并不非常依赖于Chubby或者其它任何的Google内部服务。这很重要，因为对于Borg来说最重要的一个特性之一就是availability。

• 每个机器上面会有一个Borglet，BorgMaster定期会跟Borglet沟通你现在需要在这个机器上面做什么，开什么新的软件啊之类的

• 这里有一个设计是Borglet不跟BorgMaster主动沟通，因为如果出现突然断电这类意外，会有大量的Borglet同时想要跟BorgMaster沟通，这时候反而有可能因为访问太多把BorgMaster搞倒了。

• BorgMaster跟Borglet沟通的桥梁中间加了一层link shard，很大一个作用是只把Borglet的变化传给BorgMaster，这样可以减少沟通的成本和BorgMaster处理的成本。

至此，Mesos Kubernetes Swarm三足鼎立

沙场PK

因为Mesos始终借的是容器技术的势，并不是容器领域的指导者和真正参与者，同时，他所属的Apache社区的固有封闭性，导致他在容器编排领域鲜有创新。

因此，角逐沙场的主角就放在了Docker和Kubernetes两个项目上了。

• Kubernetes通过其先进的设计理念和号召力，并没有被Docker公司“Docker Native”说辞击败，反而很快构建出一套与众不同的容器编排和管理的生态。并在Github上各项指标一骑绝尘，远超Swarm项目。

• CNCF社区迅速在成员项目中添加了Prometheus（容器监控事实标准）项目后，相机添加了Fluentd，OpenTracing，CNI等一系列致命容器生态工具和项目。Kubernetes被大量公司和创业团队支持和推广。

• Docker公司面对这样的态势，2016年宣布放弃现有Swarm项目，将容器编排和集群管理功能全部内置到Docker项目当中。这也是Swarm项目的唯一优势----和Docker项目的无缝集成可以实现优势最大化的方式。

  内置容器编排，集群管理和负载均衡能力，固然可以使Docker项目的边界直接扩大成一个完整的PaaS项目的范畴，但是同时引入的技术复杂度和维护难度，从长远看是不利的。

• 针对Docker公司打出的这张牌，Kubernetes反其道行之，开始在整个社区推行“民主化”架构。并因此，Kubernetes在2016年得到了空前发展。

  民主化架构，从API到容器运行的每一层，Kubernetes项目都为开发者暴露出可以拓展的插件机制，鼓励用户通过代码的方式接入到Kubernetes项目的每个阶段。

      这个变革，立即在容器社区催生出了到大量的基于Kubernetes API和拓展API的二次创新

• 
  

  • 微服务治理项目Istio

  • 有状态应用部署架构Operator

  • Rook: 通过Kubernetes的扩展接口，把Ceph这样的重量级产品封装成了简单易用的容器存储插件。

至少，在开源领域的竞争，Docker公司败了。因此，在拒绝了微软的早先的天价收购，没有什么回旋余地之后，选择了逐步放弃开源社区专注于自己的商业化转型。

2017年

• Docker公司将Docker项目的运行时部分Container捐赠给CNCF社区，标志着Docker项目全面升级成一个PaaS平台

• Docker公司宣布将Docker项目改名为Moby，交给社区自行维护，但Docker公司的商业产品将继续占有Docker这个注册商标。

2017年10月

Docker宣布在自己的主打产品Docker企业版中内置Kubernetes项目

2018年1月30日

RedHat宣布斥资2.5美元收购CoreOS

2018年3月28日

Docker公司CTO，这一切纷争的始作俑者，Solomon Hykes宣布辞职。

至此，容器技术圈子尘埃落定。