作者：南异

导言

在阿里集团，在离线混部技能从 2014 年开端，经历了七年的双十一检验，内部现已大规模落地推广，每年为阿里集团节约数十亿的资源本钱，全体资源运用率到达 70% 左右，到达业界领先。这两年，咱们开端把集团内的混部技能通过产品化的方法输出给业界，通过插件化的方法无缝安装在规范原生的k8s集群上，配合混部管控和运维才能，提高集群的资源运用率和产品的综合用户体验。

因为混部是一个杂乱的技能及运维体系，包括 K8s 调度、OS 隔离、可观测性等等各种技能，之前的 2 篇文章：

历经 7 年双 11 实战，阿里巴巴是怎么界说云原生混部调度优先级及服务质量的？

怎么在云原生混部场景下运用资源配额高效分配集群资源？

今日咱们要重视的是混部在单机运转时的最后一道防线——单机水位线规划。

为什么需求单机水位线

云原生混部最后一道防线：节点水位线设计

如上图所示，Pod 的运转时的三个生命周期阶段，在通过配额检查和调度后，总算，不同 Qos 等级的 Pod 运转在同一个节点上了，这个时分，高优和中优的 Pod 运用的是节点上的容器分配总量，而低优 Pod，则是根据高中优实践的资源用量，然后被调度器调度到节点上面去运转。从下图能够看到，当一个节点上还有较多的空余资源时，彻底能够提供应低优资源运用，而当高/中优 Pod 实践资源用量高过必定的值之后，资源竞赛十分剧烈时，节点上再跑低优 Pod 只会导致高/中优 Pod 的服务质量受损，所以这个时分，咱们将不再答应低优 Pod 在这个节点上运转。为了标识或许说判别节点资源的竞赛剧烈程度，那么十分顺理成章的一个规划便是，看这个节点上的资源运用率是否过高。 假如超越必定运用率，那么咱们就需求对低优 Pod 做相应的操作。这个判其他临界阈值，便是单机的水位线。

云原生混部最后一道防线：节点水位线设计

这里其他能看到的一点是，水位线仅仅是为低优 Pod 所设置的，高/中优 Pod 并不会感知到水位线，他们能够自由地运用整机的一切资源，一切的体系行为都和没有打开混部是一样的。

水位线的分级

关于一个资源趋向于饱满的节点来说，咱们关于低优 Pod 能够有各种操作的手法，假如仅仅是简略的杀掉低优 Pod 的话，整个混部体系也能够作业，这个动作咱们称为“驱赶”。

但假如在必定时刻后，机器上的资源竞赛又下降的话，那么低优 Pod 被杀死并在其他机器上重新启动，这里会大大延伸低优 Pod 的单个使命的执行时刻，所以在规划单机水位线时，需求尽可能的让低优 Pod 也要在能够答应的时刻范围内能够“降级”运转。所以，咱们有对低优 Pod 的第 2 种操作，便是下降对它的 CPU 供应量，这个操作咱们称为“限制”。

一起，假如一个节点上的资源趋于饱满，其他还比较顺理成章的体系行为便是不让新的低优 Pod 被调度进来。

于是咱们关于节点上低优 Pod 的行为就有 3 种：限制、驱赶和制止调度，由此就有三条水位线，一起，关于 CPU 这类的可紧缩资源和内存这类不行紧缩资源，行为还有区别。

注：可紧缩资源(例如 CPU 循环，disk I/O 带宽)都是速率性的能够被收回的，关于一个 task 能够下降这些资源的量而不去杀掉 task；和不行紧缩资源(例如内存、硬盘空间)这些一般来说不杀掉 task 就没法收回的。来自文章《在 Google 运用 Borg 进行大规模集群的办理 5-6》- 6.2 性能隔离 [ 1]

这些水位线全体列表如下：

云原生混部最后一道防线：节点水位线设计

这些水位线的合理装备值，应该是 驱赶>限制>制止调度。

不过在实践的混部生产中，咱们一般会把制止调度水位线和限制水位线运用同一个装备值，来下降体系运维同学的理解本钱，以及装备作业量。这样合并后就会存在 CPU 的 2 条水位线，内存的一条水位线。

驱赶条件：根据满意度的驱赶形式

云原生混部最后一道防线：节点水位线设计

这张图展示了单机上实践的体系运转比如

  • 在 t1 时刻，总资源运用率到达限制水位线的时分，对低优先级的使命进行限制，保证全体资源运用率在限制水位线之下，此时低优使命不会再被调度进来
  • 在 t3 时刻，总资源运用率开端进一步上升，到达驱赶水位线时，会对低优使命进行删去和驱赶的处理，保证高/中优的资源运用

一个容易考虑到的规划是，驱赶低优使命前去设定一个延迟时刻，这样能够让低优 Pod 有更多的机会等到体系有足够的资源，继续运转，然而这个规划，会造成几个问题：

  1. 内存的驱赶有必要是实时的，因为节点上内存缺乏，会导致高/中优使命内存缺乏而 OOM
  2. 这个延迟时刻并不好装备，配的短了没有作用，配了长了反而会引起低优 Pod 长期“饥饿”而造成低优 Pod 运转时刻更长
  3. 假如在一个节点上，有多个低优 Pod 都在运转，是否要驱赶一切的低优 Pod？是否可能尽量的少驱赶 Pod？

因而，咱们发明晰根据满意度的低优 Pod 的 CPU 资源驱赶方法，界说了以下几个概念：

  • 窗口期：获取 CPU 运用率的时刻窗口（例如 5 分钟），在窗口时刻的均匀 CPU 运用率超越驱赶水位线，则开端驱赶，能够避免抖动
  • 低优 Pod 资源满意率：= 低优 Pod 实践资源运用量/低优 Pod Request 资源量
  • 低优 Pod 满意率下限：一个百分比值，低于这个值的以为低优 Pod 的资源供应缺乏

这样，低优 Pod 的驱赶条件就变为了：

  1. 窗口期内：均匀低优 Pod 资源满意率 < 低优 Pod 满意率下限
  2. 窗口期内：低优 Pod 均匀 CPU 运用率接近 100%（如 90% 或许 80%）
  3. 当时时刻：均匀低优 Pod 资源满意率 < 低优 Pod 满意率下限
  4. 最近时刻：BE CPU 运用率接近100%（如 90% 或许 80%）

而驱赶低优 Pod 的排序为：

  • 优先驱赶调度优先级 Priority 低的 Pod（是的，即使是低优 Pod，咱们仍是能够依照数值来细分不同的调度优先级）
  • 假如 2 个 Pod 调度优先级一致，则核算驱赶哪一个 Pod 带来的资源开释更多，优先驱赶能开释更多资源的

内存的驱赶方法和 CPU 根本类似，但没有满意率，到了驱赶水位线依照优先级和内存大小来进行驱赶。

注：低优 Pod 的在其他节点上重建，仍是依赖于低优 Pod 的管控体系（例如，离线核算的结构 Spark/Flink 等），这个重建进程往往涉及到暂时缓存的文件或许数据的迁移和一致性的校验，这个重建操作并不适合在 K8s 层自动的去做操作，而是交给上层管控体系或许 operator 愈加适宜。

展望：是否有更好的规划？

在本文的开端，提到了衡量体系资源的竞赛剧烈程度，最简略和直观的便是看资源运用率。当然，在实践的大规模集群运转进程中，咱们也看到了资源运用率高和资源竞赛剧烈并不是彻底的一一对应联系，甚至有些使用在 CPU 运用率十分高的情况下，仍然安稳运转，而其他一些使用，在一个低的 CPU 运用情况下，就会十分的“卡”。

这就意味着假如咱们有新的、更好的目标来衡量体系的运用率，那么咱们对相应的 Workload 就能有更“微操”的操作，在保证使用 SLO 的一起，提高集群的资源运用率。

相关解决方案介绍

进入了 2022 年，混部在阿里内部现已成为了一个十分老练的技能，为阿里每年节约数十亿的本钱，是阿里数据中心的根本才能。而阿里云也把这些老练的技能通过两年的时刻，沉淀成为混部产品，开端服务于各行各业。云原生混部相关才能现已申请了多项独立的知识产权。

在阿里云的产品族里面，咱们会把混部的才能通过 ACK 灵敏版，以及 CNStack(CloudNative Stack)产品宗族，对外进行透出，并结合龙蜥操作体系（OpenAnolis），构成完好的云原生数据中心混部的一体化解决方案，输出给咱们的客户。

参考文档：

[1]《在Google运用Borg进行大规模集群的办理 5-6》： my.oschina.net/HardySimpso…

点击此处，马上访问云原生混部全体解决方案 ACK 灵敏版！