共计 3018 个字符，预计需要花费 8 分钟才能阅读完成。
作者：南异
引言
在阿里团体，在离线混部技术从 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 有更多的机会等到零碎有足够的资源，持续运行，然而这个设计，会造成几个问题：
- 内存的驱赶必须是实时的，因为节点上内存不足，会导致高 / 中优工作内存不足而 OOM
- 这个延迟时间并不好配置，配的短了没有成果，配了长了反而会引起低优 Pod 长期“饥饿”而造成低优 Pod 运行工夫更长
- 如果在一个节点上，有多个低优 Pod 都在运行，是否要驱赶所有的低优 Pod？是否可能尽量的少驱赶 Pod？
因而，咱们创造了基于满足度的低优 Pod 的 CPU 资源驱赶形式，定义了以下几个概念：
- 窗口期：获取 CPU 利用率的工夫窗口（例如 5 分钟），在窗口工夫的均匀 CPU 利用率超过驱赶水位线，则开始驱赶，能够防止抖动
- 低优 Pod 资源满足率：= 低优 Pod 理论资源使用量 / 低优 Pod Request 资源量
- 低优 Pod 满足率上限：一个百分比值，低于这个值的认为低优 Pod 的资源供应有余
这样，低优 Pod 的驱赶条件就变为了：
- 窗口期内：均匀低优 Pod 资源满足率 < 低优 Pod 满足率上限
- 窗口期内：低优 Pod 均匀 CPU 利用率靠近 100%（如 90% 或者 80%）
- 以后工夫：均匀低优 Pod 资源满足率 < 低优 Pod 满足率上限
- 最近工夫：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》： https://my.oschina.net/HardyS…
点击此处，立即拜访云原生混部整体解决方案 ACK 麻利版！
