阿里云容器服务差异化 SLO 混部技术实践
发布时间：2022-01-19 点击数：591
作者：佑祎
01
背景介绍
Cloud Native
阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验，目前已达到业界领先水平。所谓“差异化 SLO”，就是将不同类型的工作负载混合运行在同一节点，充分利用工作负载对资源 SLO 需求特征的不同，提升资源整体使用效率。本文将重点介绍相关技术细节和使用方法，让用户可以充分享受差异化 SLO 带来的技术红利。
02
资源模型
Cloud Native
作为通用的计算资源托管框架，Kubernetes 托管了多种类型的业务负载，包括在线服务、大数据、实时计算、AI 等等。从业务对资源质量需求来看，这些业务可以分为“延时敏感型”（Latency Sencitive，简称 LS）和“资源消耗型”（Best Effort，简称 BE）两类。
对于 LS 类型，为了确保资源的稳定性（能够应对突发的业务流量，能够应对机房容灾后带来的流量增长），一个可靠的服务通常会申请较大的资源 request 和 limit，这也是 Kubernetes 集群资源分配率很容易做到 80% 以上但利用率却低于 20% 的主要原因，也是 Kubernetes 引入 BestEffort QoS 类型的原因。
为了充分利用这部分已分配但未使用的资源，我们将上图中的红线定义为 usage，蓝色线到红色先预留部分资源定义为 buffered，绿色覆盖部分定义为 reclaimed，如下图所示：
# Nodestatus: allocatable: # milli-core : 50000 # bytes : 50000 capacity: : 50000 : 100000
低优的 BE 任务在使用 reclaimed 资源时，只需在 Pod 增加“qos”和“reclaimed-resource”的表述即可，其中 qos = LS 对应高优先级，qos = BE 对应低优先级；reclaimed-cpu/memory 为 BE Pod 的具体资源需求量。
# Podmetadata: label: : BE # {BE, LS}spec: containers: resources: limits: : 1000 : 2048 requests: : 1000 : 2048
Cloud Native
1 CPU 资源质量
CPU Burst
Kubernetes 为容器资源管理提供了 Limit（约束）的语义描述，对于 CPU 这类分时复用型的资源，当容器指定了 CPU Limit，操作系统会按照一定的时间周期约束资源使用。例如对于 CPU Limit = 2 的容器，操作系统内核会限制容器在每 100 ms 周期内最多使用 200 ms 的 CPU 时间片。
CPU 拓扑感知调度
随着宿主机硬件性能的提升，单节点的容器部署密度进一步提升，进程间的 CPU 争用，跨 NUMA 访存等问题也逐渐加剧，严重影响了应用性能表现。在多核节点下，进程在运行过程中经常会被迁移到其不同的核心，考虑到有些应用的性能对 CPU 上下文切换比较敏感，kubelet 提供了 static 策略，允许 Guarantee 类型 Pod 独占 CPU 核心。但该策略尚有以下不足之处：
- static policy 只支持 QoS 为 Guarantee 的 Pod，其他 QoS 类型的 Pod 无法使用。
- 策略对节点内所有 Pod 全部生效，而 CPU 绑核并不是”银弹“，需要支持 Pod 粒度的精细化策略。
- 中心调度并不感知节点实际的 CPU 分配情况，无法在集群范围内选择到最优组合。
弹性资源限制（reclaimed-resource）
如资源模型中的描述，节点 reclaimed-resource 的资源总量会跟随高优先级容器实际的资源用量动态变化，在节点侧，为了保障 LS 容器的运行质量，BE 容器实际可用 CPU 数量同样受 LS 容器负载的影响。
内核Group Identity
- 高优先级任务的唤醒延迟最小化。
- 低优先级任务不对高优先级任务造成性能影响。主要体现在：
- 低优先级任务的唤醒不会对高优先级任务造成性能影响。
- 低优先级任务不会通过 SMT 调度器共享硬件 unit（超线程场景）而对高优先级任务造成性能影响。
系统内核在调度包含具有身份标识的任务时，会根据不同的优先级做相应处理。具体说明如下表：
LLC 及 MBA 隔离
在神龙裸金属节点环境，容器可用的 CPU 缓存（Last Level Cache，LLC）及 内存带宽（Memory Bandwidth Allocation，MBA）可以被动态调整。通过对 BE 容器进程的细粒度资源限制，可以进一步避免对 LS 容器产生性能干扰。
2 内存资源质量
全局最低水位线分级
基于上述场景下的问题，Alibaba Cloud Linux 2 新增了 memcg 全局最低水位线分级功能。在 global wmark_min 的基础上，将 BE 的 global wmark_min 上移，使其提前进入直接内存回收。将 LS 的 global wmark_min 下移，使其尽量避免直接内存回收。这样当 BE 任务瞬间申请大量内存的时候，会通过上移的global wmark_min 将其短时间抑制，避免 LS 发生直接内存回收。等待全局 kswapd 回收一定量的内存后，再解除 BE 任务的短时间抑制。
后台异步回收
在全局最低水位线分级后，LS 容器的内存资源不会被全局内存回收影响，但当容器内部紧张时会触发直接内存回收，直接内存回收是发生在内存分配上下文的同步回收，因此会影响当前容器中运行进程的性能。
当容器内存使用超过 memory.wmark_ratio 时，内核将自动启用异步内存回收机制，提前于直接内存回收，改善服务的运行质量。
更多关于容器内存后台异步回收能力的描述，可参见官网文档：https://help.aliyun.com/document_detail/169535.html
CPU 资源满足度
前文介绍了多种针对低优先级离线容器的 CPU 资源压制能力，可以有效保障 LS 类型业务的资源使用。然而在 CPU 被持续压制的情况下，BE 任务自身的性能也会受到影响，将其驱逐重调度到其他空闲节点反而可以使任务更快完成。此外，若 BE 任务在受压制时持有了内核全局锁这类资源，CPU 持续无法满足可能会导致优先级反转，影响 LS 应用的性能。
因此，差异化 SLO 套件提供了基于 CPU 资源满足度的驱逐能力，当 BE 类型容器的资源满足度持续低于一定水位时，使用 reclaimed 资源的容器会按从低到高的优先级被依次驱逐。
内存阈值水位
案例实践
Cloud Native
1 使用 CPU Brust 提升应用性能
对比以上数据可得知：
- 在开启 CPU Burst 能力后，应用的 RT 指标的 p99 分位值得到了明显的优化。
- 对比 CPU Throttled 及利用率指标，可以看到开启 CPU Burst 能力后，CPU Throttled 情况得到了消除，同时 Pod 整体利用率基本保持不变。
我们以“Web服务+大数据”场景为例，选择了 nginx 作为 Web 服务（LS），与 spark benchmark 应用（BE）混部在 ACK 集群的同一节点，介绍 ACK 差异化 SLO 套件在实际场景下的混部效果。
对比非混部场景下的基线，以及差异化 SLO 混部场景下的数据，可以看出 ACK 差异化 SLO 套件可以在保障在线应用服务质量的同时（性能干扰 < 5%），提升集群利用率（30%）
- 对比“nginx 独立运行”与“差异化 SLO 混部”的 nginx 时延数据，RT-p99 只有4.4%左右的性能下降。
- 对比“spark 独立运行”与“差异化 SLO 混部”的 BE 任务运行时长，即便在 BE 任务频繁受到压制的情况下，总运行时间只上升了 11.6%。
相较于延时敏感型的在线服务，大数据类型应用对资源质量的要求并不敏感，“差异化 SLO 混部”可以进一步提升大数据集群的容器部署密度，提高集群资源利用率，缩短作业平均运行时间。我们以 Spark TPC-DS 评测集为例，介绍 ACK 差异化 SLO 套件对集群资源利用率的提升效果。
- “差异化 SLO”功能开启后，通过集群 reclaimed-resource 资源超卖模型，集群内可以运行更多的 Spark 容器。
- 集群 CPU 平均利用率由 49% 提升至 58%；资源的充分利用使得评测集作业的总运行时间下降了 8%。
05
总结
Cloud Native
阿里云容器服务 ACK 支持差异化 SLO 的相关功能将在官网陆续发布，各项功能可独立用于保障应用的服务质量，也可在混部场景下共同使用。实践表明，差异化 SLO 技术可以有效提升应用性能表现。特别是在混部场景下，ACK 差异化 SLO 混部技术可以将集群资源利用率提升至相当可观的水平；同时，针对在线时延敏感型服务，该技术可以将混部引入的性能干扰控制在 5% 以内。