google borg(k8s 亲爹) 论文读后感

borg 论文于 2015 年发布，展示了 borg 从 2005 年开始的一系列工作和成果.后才有参考 google 参考 borg 开源出 Kubernetes. borg 和 Kubernetes 相同点是，都是大规模集群管理系统，区别是 borg 在 google 管理了所有的机器，包括在线和离线。而目前 Kubernetes 大多数管理的还是在线场景，离线场景还是 hadoop 系的天下。学习 borg 可以更深入了解 google 的大规模集群管理经验。

特性

• 透明化资源管理和故障处理，使业务能够更专心(注：这一点就类似当今的 docker，以及未来的 serverless)

• 自身的高可用，运行在上面的应用也能达成高可用(注：和第一个特性其实很类似，都是通过平台蹭提供更多能力，让业务低成本实现高可用)

• 可以将负载轻松得分散到成千上万的节点中(注：开源的 k8s 想要扩展到这么多节点还是挺麻烦的，要考虑主从同步下，主节点的负载问题。同样的问题会出现在所有的主从模式集群下)

job 分类

• prod : prodcution job . 生产性任务,短时且延迟敏感的请求（从几微秒到几百毫秒不等）.(注:k8s 中的 pod 概念，似乎就来源于此)。高优先级。比如 gmail web 就是 prod。属于 prod 的任务：google search ,gmail web ,youtube ,google docs.

• non-prod : non-prodcution job . 非生产性任务,运行时间从分钟到天,堆短期的波动不敏感. 低优先级。比如某些批处理任务就是 non-prod,资源紧张时，会被 kill 让出资源给 prod job。

优先级

优先级分为(从高到低)： 监控（monitoring），生产（production），批处理（batch），尽力而为（best effort）（测试或免费程序）

上面的分类中，prod 对应的就是监控和生产。

配额

• 在低优先级任务上启用超卖，以提升资源利用率

• 尽管鼓励用户"按需"购买配额，但是用户依然会忍不住超量购买(注：所有资源都是这样，公司内的资源，以及每个人的手机，如果不加硬性的限制，那么就一定会被消耗光)

• 没有提到类似 k8s 使用的 cfs 调度器

调度

调度就是一堆机器中，选出来一个"合适"的机器，部署相应的 job

• 异步调度，job 被加入调度器的队列中

• 通过调度器异步扫描队列，如果有足够的资源并且满足 job 的约束(比如非亲和性)，就将 job 的 task 部署到相应的机器上。

• 两种调度算法

• 最优匹配 : 尽可能填满机器，分配时从小到大分配。。（分配过程类似 jvm cms 的 free-list）

• 最差匹配 : 最小化部署任务的成本，避免负载突刺。可能会造成资源碎片。(注，比如机器上剩下了 0.5core cpu,50m 内存，类似 jvm mark-sweep 中的内存碎片)

• 实际是混合算法（根据实践，调度中会有非常多的约束,导致调度时间比想象上久。比如常见的约束：追求高可用的服务：一个服务在同一个宿主机上最多部署 n 个节点、追求高性能的服务：服务上下游部署在一个苏主机上；带来的问题：弹性伸缩过程中，必须考虑调度的时间消耗）

从节点状态同步

每个从节点上部署一个 borglet 服务(kubelet 的亲爹啊),master 定时几秒轮询 borglet 获取状态(注:pull 模式，对客户端和服务端都非常友好)。

master 可以自发控制频率，避免 borglet 在 master 压力高时，继续 push 数据到 master 从而压垮 master(注:背压的常见解决方案)。

扩展性

主从结构总是会出现瓶颈，borg 做了以下方面的扩展以避免出现性能问题

• 拆分调度器和 master,增加并行度

• 缓存

• 副本

• 增加线程以改善响应性能

• 分片

• 评分缓存

• 等效评分：按照约束条件做 group，而不是针对每一个 task 单独做评分

• 宽松随机化 ： 严格模式下，需要抓取所有机器的状态来做评分，毕竟抓取间隔需要尽量短，这会导致状态同步和计算成本高。改进为随机抓取节点（注:这是一种类似 p2c 负载均衡的方式,能大小减少负载的同时，有尽量高的准确率）

可用性

• 如果 borglet 异常退出，对应机器上的 task 会继续执行，因为 borglet 已经挂了，所以 task 不会被 kill，而不会被转移。反而能保证 task 的可用性

• cell 独立隔离部署，减小爆炸半径，降低误操作的和故障传播几率

• 多副本防止单点故障

资源利用率

borg 的终极目标就是提升 google 全球机房的资源率，borg 给 google 节约了 30%的机器,每年几百万美元(注:2005 年的几百万美元)

评估方法

• 方法简单粗暴：不断移除 cell 中的机器，直到出现问题。

• 使用线上数据来进行仿真

cell 共享

• non-prod 和 prod 共同运行在一个 cell 中

• 必须共享才能实现资源利用率提升，如果隔离开，需要多 30%-50%的机器。prod 通常会预留资源，但大多数机器不需要那么多机器。这些空闲的资源可以被 non-prod 有效利用

大型 cell

• 专门为大型任务和减少资源碎片提供的 cell。（注:这就是 G1GC 和 ZGC 中的 humongous region，条条大路通罗马）

隔离

• 使用 cgroup 来隔离资源。内存带宽或者 cpu l3 cache 污染都会导致 rt 出现问题。通过设置优先级，延迟敏感型任务可以挂起其他任务。

• 资源分为可压缩资源(cpu,iops;基于速率)和不可压缩资源(mem,network,disk)。