Docker（1）Docker与Kubernetes的兴起史

Ref: 《Docker与Kubernetes的兴起》

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

CoreOS产品	Swarm
依托开源项目，如Container Linux OS, Fleet作业调度工具，sysemd进程管理和rkt容器，一层层搭建起来的项目	完全使用Docker项目原本的容器管理API来完成集群管理，无缝集成Docker。

2014-2015 构建Docker生态

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

Fig项目受欢迎的原因

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

编排

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

Fig做了什么

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

$  fig up

集群管理和编排

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

• 集群管理工具：需要处理的是集群的节点管理（增、删），HA等方面。
• 容器编排工具：通过配置文件，支持对多个容器进行配置关联满足应用服务。

遗留问题

• 集群管理工具和容器编排工具的联系是什么？
• Kubernetes是集群管理工具还是容器编排工具？

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。OCI目的是把容器运行时和镜像的实现从Docker项目中完全剥离出来。

遗留问题

什么是容器运行时？

OCI的结果

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

第二把武器

虽然Docker项目是容器生态的标准事实，但是仍然有另一个既定事实，Docker公司他们家的PaaS层的能力是比不上Google和RedHat这些公司的，技术积累不够。
于是，Google和RedHat，牵头发起CNCF（Cloud Native Computing Foundation)基金会。期望以Kubernetes项目为基础，建立一个有开源基础设施领域厂商主导的，按照独立基金会运营的平台及社区，对抗以Docker公司为核心的容器商业生态。

遗留问题

Kubernetes和Docker公司对立的姿态，会不会导致技术上，Kubernetes和下面的Docker容器在架构上使用的不和谐？（虽然感觉并不会，k8s现在这么火热，深入挖Docker和Kubnetes之后回来看这个问题吧）

对抗Docker公司的Kubernetes

要保证至少两件事：

• Kubernetes项目必须能够在容器编排领域取得竞争优势（Swarm重在无缝集成Docker，Mesos重在大规模集群的调度和管理）
• CNCF社区必须以Kubernetes为核心覆盖足够多的场景

Kubernetes选择

• Kubernetes设计思想来源于Borg（Borg: Google内部的大型集群管理系统）和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宣布辞职。

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

遗留问题

• 集群管理工具和容器编排工具的联系是什么？
• Kubernetes是集群管理工具还是容器编排工具？
• Kubernetes和Docker公司对立的姿态，会不会导致技术上，Kubernetes和下面的Docker容器在架构上使用的不和谐？（虽然感觉并不会，k8s现在这么火热，深入挖Docker和Kubnetes之后回来看这个问题吧）
• “Kubernetes设计思想来源于Borg（Borg: Google内部的大型集群管理系统）和Omega的内部特性，这些特性落到Kubernentes上，就是pod和SideCar等功能和设计模式。” 其中的Borg， Omega， Pod和SideCar这些功能和设计模式具体内容是什么？
  -----------在学习完《深入剖析Kubernetes》之后，小刘会再回来看这些问题的。

小广告

本篇博文是参考极客时间《深入剖析Kubernetes》系列课程的预习篇梳理出来的，用作作者对Docker和Kubernetes项目开始聚焦研究之前的背景了解。有兴趣学习这个方向的，可以把张磊学长的《深入剖析Kubernetes》系列课程作为一个入门课程。师傅领进门，修行在个人。