共计 4917 个字符，预计需要花费 13 分钟才能阅读完成。
Google Borg 是资源调度治理和离在线混部畛域的鼻祖，同时也是 Kubernetes 的起源与参照，已成为从业人员首要学习的榜样。本文尝试管中窥豹，简略从《Large-scale cluster management at Google with Borg》一文中分析 Google Borg 的设计理念和性能特点，用以抛砖引玉。
Google Borg 是什么？
Google Borg 是 Google 外部自研的一套资源管理零碎，用于集群资源管控、调配和调度等。在 Borg 中，资源的单位是 Job 和 Task。Job 蕴含一组 Task。Task 是 Borg 治理和调度的最小单元，它对应一组 Linux 过程。相熟 Kubernetes 的读者，能够将 Job 和 Task 大抵对应为 Kubernetes 的 Service 和 Pod。
在架构上，Borg 和 Kubernetes 相似，由 BorgMaster、Scheduler 和 Borglet 组成。
Borg Allocs
Borg Alloc 代表一组可用于运行 Task 的资源 ，如 CPU、内存、IO 和磁盘空间。它实际上是集群对物理资源的形象。Alloc set 相似 Job，是一堆 Alloc 的汇合。当一个 Alloc set 被创立时，一个或多个 Job 就能够运行在下面了。
Priority 和 Quota
每个 Job 都能够设置 Priority。Priority 可用于标识 Job 的重要水平，并影响一些资源分配、调度和 Preemption 策略。 比方在生产中，咱们会将作业分为 Routine Job 和 Batch Job。Routine Job 为生产级的例行作业，优先级最高，它占用对应理论物理资源的 Alloc set。Batch Job 代表一些长期作业，优先级最低。当资源缓和时，集群会优先 Preempt Batch Job，将资源提供给 Routine Job 应用。这时 Preempted Batch Job 会回到调度队列期待从新调度。
Quota 代表资源配额，它束缚 Job 的可用资源，比方 CPU、内存或磁盘 。Quota 个别在调度之前进行查看。Job 若不满足，会立刻在提交时被回绝。生产中，咱们个别根据理论物理资源配置 Routine Job Quota。这种形式能够确保 Routine Job 在 Quota 内肯定有可用的资源。为了充沛晋升集群资源使用率，咱们会将 Batch Job Quota 设置为有限，让它尽量去占用 Routine Job 的闲置资源，从而实现超卖。这方面内容前面会在再次详述。
Schedule
调度是资源管理零碎的外围性能，它间接决定了零碎的“好坏”。 在 Borg 中，Job 被提交后，Borgmaster 会将其放入一个 Pending Queue。Scheduler 异步地扫描队列，将 Task 调度到有短缺资源的机器上。
通常状况下，调度过程分为两个步骤：Filter 和 Score。
- Filter，或是 Feasibility Checking，用于判断机器是否满足 Task 的束缚和限度，比方 Schedule Preference、Affinity 或 Resource Limit。
- Filter 完结后，就须要 Score 符合要求的机器，或称为 Weight。上述两个步骤实现后，Scheduler 就会筛选相应数量的机器调度给 Task 运行。实际上，抉择适合的调度策略尤为重要。
这里能够拿一个咱们生产遇到的调度问题举例。
生产初期，咱们的调度零碎采纳的 Score 策略相似 Borg E-PVM，它的作用是将 Task 尽量平均的调度到整个集群上。从侧面成果上讲，这种策略扩散了 Task 负载，并在肯定水平上放大了故障域。但从背面看，它也引发了资源碎片化的问题。因为咱们底层环境是异构的，机器配置并不对立，并且 Task 配置和物理配置并无对应关系。 这就造成一些配置过大的 Task 无奈运行，由此在肯定水平上升高了资源的分配率和使用率。
为了应酬此类问题，咱们自研了新的 Score 策略，称之为“Best Fillup”。 它的原理是在调度 Task 时抉择可用资源起码的机器，也就是尽量填满。不过这种策略的毛病不言而喻：单台机器的负载会升高，从而减少 Bursty Load 的危险；不利于 Batch Job 运行；故障域会减少。
本篇论文作者采纳了一种被称为 hybrid 的形式，据称比第一种策略减少 3-5% 的效率。
Utilization
资源管理零碎的首要指标是进步资源使用率 ，Borg 亦是如此。不过因为过多的前置条件，诸如 Job 搁置束缚、负载尖峰、多样的机器配置和 Batch Job，导致不能仅抉择“average utilization”作为策略指标。在 Borg 中，应用 Cell Compaction 作为评判基准。简述之就是：能承载给定负载的最小 Cell。
Borg 提供了一些进步 utilization 的思路和实际办法，有些是咱们在生产中曾经采纳的，有些则十分值得咱们学习和借鉴。
Cell Sharing
Borg 发现，将各种优先级的 Task，比方 prod 和 non-prod 运行在共享的 Cell 中能够大幅度的晋升资源利用率。
下面（a）图表明，采纳 Task 隔离的部署形式会减少对机器的需要。图（b）是对额定机器需要的散布函数。图（a）和图（b）都分明的表明了将 prod Job 和 non-prod Job 离开部署会耗费更多的物理资源。Borg 的教训是大概会新增 20-30% 左右。
个中原理也很好了解：prod Job 通常会为应答负载尖峰申请较大资源，实际上这部分资源在少数工夫里是闲置的。Borg 会定时回收这部分资源，并将之调配给 non-prod Job 应用。在 Kubernetes 中，对应的概念是 request limit 和 limit。咱们在生产中，个别设置 Prod Job 的 Request limit 等于 limit，这样它就具备了最高的 Guaranteed Qos。该 QoS 使得 pod 在机器负载高时不至于被驱赶和 OOM。non-prod Job 则不设置 request limit 和 limit，这使得它具备 BestEffort 级别的 QoS。kubelet 会在资源负载高时优先驱赶此类 Pod。这样也达到了和 Borg 相似的成果。
Large cells
Borg 通过试验数据表明，小容量的 cell 通常比大容量的更占用物理资源。
这点对咱们有很重要的指导意义。通常状况下，咱们会在设计集群时对容量问题感到当机立断。
不言而喻，小集群能够带来更高的隔离性、更小的故障域以及潜在危险。但随之带来的则是治理和架构复杂度的减少，以及更多的故障点。
大集群的优缺点正好相同。在资源利用率这个指标上，咱们凭直觉认为是大集群更优，但苦于无松软的理论依据。Borg 的钻研表明，大集群有利于减少资源利用率，这点对咱们的决策很有帮忙。
Fine-grained resource requests
Borg 对资源细粒度调配的办法，目前已是支流，在此就不再赘述。
Resource reclamation
理解 Kubernetes 的读者，应该对 resource request 和 limit，在 Google Borg 中概念相似。Job 在提交时须要指定 resource limit，它能确保外部的 Task 有足够资源能够运行。
有些用户会为 Task 申请过大的资源，以应答可能的申请或计算的突增。但实际上，局部资源在少数工夫内是闲置的。与其资源节约，不如利用起来。这须要零碎有较准确的预测机制，能够评估 Task 对理论资源的需要，并将闲置资源回收以调配给低 priority 的工作，比方 Batch Job。
上述过程在 Borg 中被称为 resource reclamation，对应用资源的评估则被称为 reservation。Borgmaster 会定期从 Borglet 收集 resource consumption，并执行 reservation。在初始阶段，reservation 等于 resource limit。随着 Task 的运行，reservation 就变为了资源的理论使用量，外加 safety margin。
在 Borg 调度时，Scheduler 应用 resource limit 为 prod Task 过滤和抉择主机，这个过程并不依赖 reclaimed resource。从这个角度看，并不反对对 prod Task 的资源超卖。但 non-prod Task 则不同，它是占用已有 Task 的 resource reservation。所以 non-prod Task 会被调度到领有 reclaimed resource 的机器上。
这种做法当然也是有肯定危险的。若资源评估呈现偏差，机器上的可用资源可能会被耗尽。在这种状况下，Borg 会杀死或者降级 non-prod Task，prod Task 则不会受到任何影响。
上图证实了这种策略的有效性。参照 Week 1 和 4 的 baseline，Week 2 和 3 在调整了 estimation algorithm 后，理论资源的 usage 与 reservation 的 gap 在显著放大。在 Borg 的一个 median cell 中，有 20% 的负载是运行在 reclaimed resource 上。
相较于 Borg，Kubernetes 尽管有 resource limit 和 capacity 的概念，但却短少动静 reclaim 机制。这会使得系统对低 priority Task 的资源短少卓有成效的评估机制，从而引发零碎负载问题。这个性能对资源调度和晋升资源使用率影响微小。
Isolation
因为 Google Borg 天生就思考混部场景，所以资源隔离对其尤为重要。在外部场景，Google Borg 多应用 Linux 隔离，比方 chroot、cgroup 等，相似容器隔离机制。私有云侧，Google Borg 则通过 VM 或沙箱技术实现 Task 间的强隔离。
在性能隔离方面，Google Borg 通过辨别利用优先级的形式保障服务质量。latency-sensitive（LS）高优工作领有高的资源保障，Batch 低优工作占用资源则会依据须要被克制。
在集群资源方面，Google Borg 将之分为可压缩和不可压缩资源。与流速相干的资源，诸如 CPU、磁盘 IO 等，被定义为可压缩资源。这部分资源若被耗尽，Borglet 会首先降级解决低优工作，而不是间接杀死。这种做法能最大水平保障低优工作服务质量。不可压缩资源，包含内存、磁盘空间等，在资源缓和时，工作会被依照优先级从低到高杀死，直到缓和状况缓解。
在内核层面，Google Borg 同样有策略保障资源隔离与复用。比方 LS 工作可独享物理 CPU 外围，其余 LS 工作不可复用。Batch 工作能共用这部分 CPU，通过设置低 cpus_share 的形式与 LS 工作隔离。Borget 也会周期性的调整 LS 工作，以防止 Batch 工作被饿死。为了反对高敏工作，Google Borg 对 CFS 做了加强，使之可依据 cgroup 负载预测提前抢占 Batch 工作，从而升高 CFS 调度提早。
总结
离在线混合部署是一套简单的零碎和技术，须要从方法论、业务、利用、资源调度零碎、操作系统等多个层面的实现和配合，并且也须要长期的实战和教训积攒。Google Borg 作为 Google 外部的教训结晶，零碎的论述了混部应有的根本状态，很有启发意义。 目前咱们在腾讯外部也开发和上线了一套基于 Kubernetes 的离在线混合部署零碎，反对动静资源预测、资源回收和内核级隔离。 后续会继续分享混部相干的实践和实战经验。
参考资料
- Large-scale cluster management at Google with Borg：https://iwiki.oa.tencent.com/…
- evolution of cluster scheduler architecture：http://www.firmament.io/blog/…
- poseidon：https://github.com/kubernetes…
- design：https://docs.google.com/docum…
- firemament：https://github.com/camsas/fir…
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
