docker与kubernetes的兴起-4008云顶国际网站

背景

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

亮点

• 开源项目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大规模应用部署的职责。

针对这一缺点：

• 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产品对比

在这一两年里，围绕着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年，google发布kubernetes项目。挽救了coreos和redhat，并再次改变了整个容器市场的格局。

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

容器领域的其他几位玩家成立了一个中立基金会，切割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三足鼎立

因为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公司败了。因此，在拒绝了微软的早先的天价收购，没有什么回旋余地之后，选择了逐步放弃开源社区专注于自己的商业化转型。

• docker公司将docker项目的运行时部分container捐赠给cncf社区，标志着docker项目全面升级成一个paas平台

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

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

redhat宣布斥资2.5美元收购coreos

docker公司cto，这一切纷争的始作俑者，solomon hykes宣布辞职。

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