共计 4404 个字符，预计需要花费 12 分钟才能阅读完成。
这篇文章主要为大家展示了“Borg 和 Kubernetes 有什么区别”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“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 这边也会做一些相应的工作，包括多租户支持，包括容器持久化、集群规模的提升、利用率和网络方面的等等。
以上是“Borg 和 Kubernetes 有什么区别”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
