绿色的这一块是黄色的块加上一些安全区组成的，每过几秒重新计算一遍应用程序耗费了多少资源。这实际上是一个动态的过程，它并不是说划走了之后就再也不能变了。绿色的方块是可以一直拓展到外面的虚线的范围之内。这就是对单个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来跑一些传统的应用，那我肯定还会对这些应用和系统做一定程度的改造，但至少没有困难到无法完成。