docker与kubernetes的兴起-凯发k8国际娱乐官网入口

发表于 2019/12/16 20:05:48 2019/12/16
【摘要】 2013背景后端技术没有令人兴奋的新技术产生,云计算技术具象化成了实实在在的虚拟机的账单。亮点开源项目cloudfoundry,开启以开源paas为核心构建平台层服务能力的变革。dotcloud公司开源自己的容器项目docker,提出docker镜像概念 paas项目广泛接纳的一个重要原因,是他提供了一种“应用托管的能力”。当时虚拟机是普遍技术,部署过程中会遇到云端虚拟机和用户本地环境...

背景

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

亮点

  • 开源项目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产品对比

coreos产品swarm
依托开源项目,如container linux os, fleet作业调度工具,sysemd进程管理和rkt容器,一层层搭建起来的项目

完全使用docker项目原本的容器管理api来完成集群管理,无缝集成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年,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宣布辞职。


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


【凯发k8国际娱乐官网入口的版权声明】本文为华为云社区用户翻译文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。