Borg和Kubernetes有什么不一样？将来的云须要什么？

你们好，我是来自于华为PaaS部门的钟成，目前正在作相关的一些产品研发。我想分享的主题是从Borg到Kubernetes，其实Borg就是Kubernetes的前身。我今天主要会谈三个方面，第一个是Borg的介绍，第二是Kubernetes基于Borg作了哪些改变，以及它的发展方向，第三个话题想谈一下将来的云可能须要一个怎么样的产品或者是怎么样的形态。

Borg是什么？它解决了什么问题？

咱们先看第一个话题，就是Borg是什么？它解决了什么问题？

咱们看一下这张图，这张图来自于一部电影叫作《星际迷航》相信你们大部分人都看过。Borg是里面的一种外星人，反派，他作什么事情呢？他和其余的文明接触，把你这个文明抢占下来，而后它会和你同化，会把你进行改造，把你改形成一个半人半机器的怪物，你就变成他们这个文明当中的一部分，而后他在这个宇宙当中不断的扩张下去。我以为这是一个很是酷的种族。而Borg就以这个名字来命名其大规模分布式的集成管理系统。他但愿他们的系统也能够把不一样的机器同化掉，变成他们本身的机器，而后运行他们本身的程序。

对谷歌来讲，Borg是一个比较顶层的集成管理系统。在它上面跑了谷歌大部分的应用程序和框架包括Gmail、Google Docs、Web Search这样直接面对客户的一些应用程序。它同时也包括一些底层的框架，（MR），包括它的一些GFS这些分布式的存储系统。也就是说你能够认为全部的应用程序都须要经过它来管理底层的这些物理机。Borg在谷歌已经成功的应用的十多年。

你们能够看一下Borg的总体的架构。它也是一个典型的分布式平台的架构，就是一个逻辑上的master，而后下面有不少的节点，每个节点上有一些它的代理程序。这里就能够看一下，做为谷歌内部的一个工程师怎么样用这个系统呢？他们使用Borgcfg（命令行）或者Web UI提交须要跑的应用（Task） 到系统，Task能够是任何一种东西，好比说他是一个应用程序，或者是一个批处理任务，或者是一个（MR）的任务。他把这个任务经过Borgcfg提交到BorgMaster，而后BorgMaster会接受这个请求，把请求放到队列里面去，并由Scheduler来扫描这个队列，查看这个应用的资源需求，并在集群中寻找匹配的机器。你其实提交的这个任务，它须要多少的资源，你须要怎么样的机器，大概要跑多少时候，他会作一个匹配，就会看到底层有哪些机器是空闲的。而后就把这个任务发配到这个机器上面去，而后开始运行。

这个就是整体的一个Borg的框架。一个典型的启动时间，从用户提交应用到应用启动是25秒。其中80%的时间是每一个节点上下载这个应用包的时间。你们能够看到这个时间是很快的，它的调度时间还不到5秒，其中20秒是耗在传输这一层上。

关于BorgMaster的调度原理

我后面主要想探讨一下，我今天想说的一个重点就是关于BorgMaster，它这里有不少应用，它怎么样调动这个应用的优先级呢？或者说到底哪台机器应该跑什么应用呢？Borg的作法就是对单个Task作了一个资源上的估量，你们能够看到这里有好几条线，其中一个机器上面最外面的那条虚线就是用户提交的一个资源的一个配额，就是Task再怎么运行也不能超过它的限制，这是一个硬性的限制，若是说超过这个限制，就会限制它，不让它跑。这只是用户提交的数字，你们知道用户提交的数字不少时候是不许确的，你没法预估到底你的程序在你的系统上须要耗多少CPU，占多少内存。Borg是怎么去评估这个资源呢？他在Task启动300秒以后，就进行一个资源回收的工做。你们能够看到中间有一个黄色的区域，黄色的区域就是这个应用程序实际上所消耗的资源。而后它会从外面，慢慢把它推动去，推到绿区的地方，推到绿区的地方划一条线，这条线就是所谓的保留资源，就是Borg这个系统认为你这个应用是长期稳定运行的所须要的资源。

这里就有一个问题，为何Borg要这么作呢？缘由是为了把剩下的区域的资源给空出来，若是说我知道这个应用实际上就用了这么多的资源。而后我给它划了必定的安全线以后，剩下的这些资源我就能够调度出来，也就是说能够给到其它的应用程序用。

绿色的这一块是黄色的块加上一些安全区组成的，每过几秒从新计算一遍应用程序耗费了多少资源。这其实是一个动态的过程，它并非说划走了以后就不再能变了。绿色的方块是能够一直拓展到外面的虚线的范围以内。这就是对单个Task作的一个策略。而后经过他对系统上跑的应用作了一个区分。就是说，他先想了一下，到底有哪些应用，这些应用有什么样的特性。其中有一类应用就是所谓的生产型的应用，就是prod task，其特征就是永远都是不中止的，他是一个长进程，它永远是面向用户的，好比说Gmail或者是Web Search，它中间不可能断的，它的响应时间是几微秒到几百毫秒。而后这种任务就是说，你必需要优先保证它的运行，它的短时间性能波动是比较敏感的。

还有一类任务就是所谓的non-prod task，他是一个批处理任务，相似像Map Reduce，它不是直接面向用户的，对性能不是很是的敏感，跑完了就完了，下一个再跑就是下一个任务了，不是一个长进程。

为何要区分任务？

当prod task的资源任务消耗比较大的时候，好比说不少人忽然都来上一个网站，这个网站的服务器内存CPU就会很是高。这个时候，在这台机器上应用资源不足的时候，他就会把Non-prod task杀掉，杀掉以后让它去其余的机器上去运行。可是在空闲的时候，就可让任务继续回来。这样的话，我就能够充分利用这台机器上的全部时间点上的资源，能够把这些东西塞的比较满。最后谷歌的测试结果是，大概20%的工做负载能够跑在回收资源上。这个数据实际上是很是大的。对谷歌有那么多台的机器，你能够省下20%的资源，对它来讲就是很是很是多的钱。

Borg的价值

我这里稍微总结一下，Borg这套系统给谷歌提供了什么样的价值。它主要是提供了三个方面。第一个是隐藏的资源管理和故障处理的细节，让用户能够专一于应用开发。用户不用操心底层的系统是怎么操做的，就算我挂了他也会帮我启起来。第二个是自己提供高可靠性和高可用性的操做，并支持应用程序作到高可靠高可用。第三个是在数以万计的机器上高资源利用率运行。

对于Borg具体怎么作到这三个方面，google有一篇很长的论文《在Google使用Borg进行大规模集群的管理》，里面有不少细节，今天就不展开说了。

Kubernetes架构

自从谷歌把Borg这个系统推出以后，对内部来讲是很是成功，可是在外面的社区，其实你们都不知道这个东西究竟是怎么作的，也不知道他内部是怎么实现的。后来作Borg的那批人他们就作了另一个软件，这个软件就是Kubernetes，Kubernetes整体而言你能够认为是Borg的一个开源的版本，可是Kubernetes和Borg有一些不同，我后面会大体的讲一下。这是Kubernetes的架构，你们其实能够看到，它的这个架构和Borg的架构基本上是相似的，包括用户怎么用的也是相似的。用户经过用kubectl这么一个命令行工具，把任务提交上来。

Kubernetes与Borg的区别

Borg在谷歌已经运行了十年，并且机器的规模量很是大，他一个集群就是一万台，甚至更多。而Kubernetes是2014年才出来的，我我的认为这是针对亚马逊，亚马逊的公有云很是的成功，谷歌也想进入这个领域，他的方式就是把Kubernetes这个系统开源推出来，在业界产生必定的影响力，让你们都去用。这样的话，后面就能够和亚马逊竞争一下，这是我我的推测他们的一个想法。

Borg底层用的是lxc的容器，而Kubernetes是用的Docker容器。Borg是用C++编写的，Kubernetes是用Go语言编写的。Borg在集群调度的性能上作了不少的优化，Kubernetes尚未作很是多的优化，目前他在这方面仍是比较土的，后面还有不少工做须要作。Borg的单集群可以调度的机器有上万台，而按Kubernetes目前只能支持几百台，这是目前的数据。

而后咱们再看一下，对于这两个系统的用户来讲它们有什么区别。Borg的用户其实就是谷歌的一批工程师，你们也知道谷歌工程师都是世界比较顶尖的工程师，他们在写这个程序的时候就考虑过程序会跑在云上，他知道这个程序是分布式的。他在写这个应用的时候，就会针对这个系统作很是多的优化，在设计的时候就知道我应该作一个分布式的系统。可是Kubernetes他想作的事情更多一些，就是除了运行这些分布式的系统以外，他还想就是说可以支持一些，他首先是支持Docker的这些容器，可是他还但愿支持一些比较传统的，比较菜的，技术水平通常的人写的这些应用程序。他在这方面作了一些工做。一个是用了Docker容器，这样的话就支持不少东西了。还有内他还能够挂载外部的持久层，就是你能够把一些分布层面的系统挂在那个系统上面。个人容器就去读取外部的分布式的存储。这样的话，我这个容器就算是挂了，我这个数据也能够比较安全的保存。另外他就提供了一些监控还有一些日志的功能。可是这些功能是否是够呢，这仍是有必定的疑问的。后期若是说我想用Kubernetes来跑一些传统的应用，那我确定还会对这些应用和系统作必定程度的改造，但至少没有困难到没法完成。

这个是它Kubernetes设计上的一些特点，Kubernetes的网络架构是每个Pod都有一个单独的IP，这样的应用更加友好一些。写应用程序的人就不用考虑冲突这种状况。还有就是它分组的模式，就是我这些容器如何分组。Borg是一个比较专家的系统，他有230多个参数，可是Kubernetes是很是简单的大概就是三四个描述文件就完了。

Borg和Kubernetes的形象化总结

这里就是我对Borg和Kubernetes的一个形象化的总结。Borg就是一个喷气式飞机的驾驶系统，很是的专业和高大上，他适用于谷歌这样的大公司，它有几百万的机器。Kubernetes是一个它的简化版，它是一辆设计优良的轿车，它适合中小型公司，用它来对本身的集群进行调度。

将来Kubernetes这边也会作一些相应的工做，包括多租户支持，包括容器持久化、集群规模的提高、利用率和网络方面的等等。

将来的云须要什么？

最后能够说是我我的的一些思考。咱们将来的云到底须要什么样的东西。你们能够看到，自从计算机风靡以来，有不少的系统，不少的软件，一波又一波的起来，有一部分的系统或者说软件是比较成功的，能够长久存在下去，好比说像Java、或者是C，或者是像Windows这样，还有一些系统很是不幸，像Cobol或者是DOS或者是Minix这些系统，它们慢慢的被人所遗弃，慢慢被人所遗忘，最后变成废弃的停车场。

我这里想考虑一下，若是说再过十年，咱们如今在用的一些技术，像Kubernetes或者是Borg这样的技术，是会进入到左边这个行列仍是右边这个行列呢？我我的是但愿进入左边的行列，毕竟咱们仍是但愿他能够成为一款经典的产品。至少对这些系统来讲，咱们会很是自豪，咱们作了一款比较经典的产品，能够长久的被人们所使用下去。

若是说想作到这一点，就得面对咱们如今这个时代，整个计算机系统所面临的一个困境，或者说咱们集群管理系统所面对的一个困境。这个困境是什么呢？就是这里所展现的Babel塔的困境。在以色列那个地方，这是一个圣经的故事，人们想形成通常座通天之塔，他们想挑战上帝的权威。上帝一看大家这批凡人，就以为大家这批鸟人竟然敢挑战个人权威，他就发明了各类语言，一块儿作巴别塔工做的人就各自使用不一样的语言，他们就没法交流，最后这个塔就造不下去了。

其实在计算机的世界也是如此，你们使用各自的语言，各自的框架，最后使咱们合做起来很是的复杂。包括咱们的集群管理系统也好，包括其余的系统也好，其实都是帮助咱们跨越这个鸿沟，帮助咱们你们能够比较好的进行合做。可是目前来讲，尚未一个很是好的方案可让你们很是好的进行合做，我以为这个是咱们作这个系统须要作的一个事情。我这里引一句老子的话，你们能够看一下。

三十幅共一毂，当其无，有车之用。
埏埴觉得器，当其无，有器之用。
凿户牖觉得室，当其无，有室之用。
故有之觉得利，无之觉得用。

我在想，是什么因素决定了一个系统或者是一个软件，它是否能够长期生存下去呢？我以为很是重要的一点，他要明确本身要作什么。其实就是前面讲的端水的端水，扫地的扫地，就是说你不但要明确本身这个软件要作什么，还得明确本身不要作什么。你什么东西是无以之为用，就是这个领域我是不进去的，我是不去作的。若是说你什么东西都作，最后就会比较弱，很容易就会颠覆，或者是被人取代。若是说你单单把一件事情作好，那你从此在这个领域，至少你是无可替代的，能够长期生存下去。我记得前一段时间有人问Linus，怎么看Docker容器。而后他说我才不关心这什么狗屁容器，我就关心个人内核，你不要来问我这个问题。我以为他这个就是一个很是好的一个态度，他把他本身内核这一个模块作好，他把他系统这一块作好，那么对他而言，他这个工做就能够长期延续下去。

那么对于咱们来讲，比较详细一点，就是说在咱们软件开发当中碰到的状况是这样的。从咱们的软件设计到开发到测试、生产都通过很是多，很是反复的过程。同时在大部分的集群系统当中，咱们也很是难以调度它。那么我以为对于咱们来讲，就是后面要解决几个方面的问题。我以为这是咱们一个大的方向。

咱们之后的产品是否是能够减小语言、程序、框架不一样带来的复杂性，能不能把流程进行简化，把语言进行简化，把网络和服务依赖进行简化，这是我提的另外一个问题。