阿里云容器服务差异化 SLO 混部技术实践

简介：阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验，目前已达到业界领先水平。所谓“差异化 SLO”，就是将不同类型的工作负载混合运行在同一节点，充分利用工作负载对资源 SLO 需求特征的不同，提升资源整体使用效率。本文将重点介绍相关技术细节和使用方法，让用户可以充分享受差异化 SLO 带来的技术红利。

作者：佑祎

背景介绍

阿里巴巴在“差异化 SLO 混合部署”上已经有了多年的实践经验，目前已达到业界领先水平。所谓“差异化 SLO”，就是将不同类型的工作负载混合运行在同一节点，充分利用工作负载对资源 SLO 需求特征的不同，提升资源整体使用效率。本文将重点介绍相关技术细节和使用方法，让用户可以充分享受差异化 SLO 带来的技术红利。

资源模型

作为通用的计算资源托管框架，Kubernetes 托管了多种类型的业务负载，包括在线服务、大数据、实时计算、AI 等等。从业务对资源质量需求来看，这些业务可以分为“延时敏感型”（Latency Sensitive，简称 LS）和“资源消耗型”（Best Effort，简称 BE）两类。

对于 LS 类型，为了确保资源的稳定性（能够应对突发的业务流量，能够应对机房容灾后带来的流量增长），一个可靠的服务通常会申请较大的资源 request 和 limit，这也是 Kubernetes 集群资源分配率很容易做到 80% 以上但利用率却低于 20% 的主要原因，也是 Kubernetes 引入 BestEffort QoS 类型的原因。

为了充分利用这部分已分配但未使用的资源，我们将上图中的红线定义为 usage，蓝色线到红色先预留部分资源定义为 buffered，绿色覆盖部分定义为 reclaimed，如下图所示：

这部分资源代表了可动态超卖的资源量，也就是∑reclaimed(Guaranteed/Burstable)。将这部分空闲资源分配给 BE 类型的业务，就可以充分利用工作负载对资源运行质量需求不同的特征，提升集群整体资源利用率。

阿里云容器服务 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，以下简称 ACK）差异化 SLO 扩展套件提供了将这部分超卖资源量化的能力，动态计算当前的reclaimed资源量，并以标准扩展资源的形式实时更新到 Kubernetes 的 Node 元信息中。

# Node
status:allocatable:# milli-corealibabacloud.com/reclaimed-cpu: 50000# bytesalibabacloud.com/reclaimed-memory: 50000capacity:alibabacloud.com/reclaimed-cpu: 50000alibabacloud.com/reclaimed-memory: 100000

低优的 BE 任务在使用 reclaimed 资源时，只需在 Pod 增加“qos”和“reclaimed-resource”的表述即可，其中 qos = LS 对应高优先级，qos = BE 对应低优先级；reclaimed-cpu/memory 为 BE Pod 的具体资源需求量。

# Pod
metadata:label:alibabacloud.com/qos: BE # {BE, LS}
spec:containers:- resources:limits:alibabacloud.com/reclaimed-cpu: 1000alibabacloud.com/reclaimed-memory: 2048 requests:alibabacloud.com/reclaimed-cpu: 1000alibabacloud.com/reclaimed-memory: 2048

技术内幕

CPU 资源质量

CPU Burst
Kubernetes 为容器资源管理提供了 Limit（约束）的语义描述，对于 CPU 这类分时复用型的资源，当容器指定了 CPU Limit，操作系统会按照一定的时间周期约束资源使用。例如对于 CPU Limit = 2 的容器，操作系统内核会限制容器在每 100 ms 周期内最多使用 200 ms 的 CPU 时间片。

下图展示了一台 4 核节点、某 CPU Limit = 2 的 Web 服务类容器，在收到请求（req）后各线程（Thread）的 CPU 资源分配情况。可以看出，即使容器在最近 1s 内整体的 CPU 利用率较低，受 CPU Throttled 机制的影响，Thread 2 仍需要等待下一个周期才能继续将 req 2 处理完成，进而导致请求的响应时延（RT）变大，这通常就是容器 RT 长尾现象严重的原因之一。

CPU Burst 机制可以有效解决延迟敏感性应用的 RT 长尾问题，允许容器在空闲时积累一些 CPU 时间片，用于满足突发时的资源需求，提升容器性能表现，目前阿里云容器服务 ACK 已经完成了对 CPU Burst 机制的全面支持。对于尚未支持 CPU Burst 策略的内核版本，ACK 也会通过类似的原理，监测容器 CPU Throttle 状态，并动态调节容器的 CPU Limit，实现与内核 CPU Burst 策略类似的效果。

CPU 拓扑感知调度

随着宿主机硬件性能的提升，单节点的容器部署密度进一步提升，进程间的 CPU 争用，跨 NUMA 访存等问题也逐渐加剧，严重影响了应用性能表现。在多核节点下，进程在运行过程中经常会被迁移到其不同的核心，考虑到有些应用的性能对 CPU 上下文切换比较敏感，kubelet 提供了 static 策略，允许 Guarantee 类型 Pod 独占 CPU 核心。但该策略尚有以下不足之处：

static policy 只支持 QoS 为 Guarantee 的 Pod，其他 QoS 类型的 Pod 无法使用。
策略对节点内所有 Pod 全部生效，而 CPU 绑核并不是”银弹“，需要支持 Pod 粒度的精细化策略。
中心调度并不感知节点实际的 CPU 分配情况，无法在集群范围内选择到最优组合。

阿里云容器服务 ACK 基于 Scheduling framework 实现了拓扑感知调度以及灵活的绑核策略，针对 CPU 敏感型的工作负载可以提供更好的性能。ACK 拓扑感知调度可以适配所有 QoS 类型，并支持在 Pod 维度按需开启，同时可以在全集群范围内选择节点和 CPU 拓扑的最优组合。

弹性资源限制（reclaimed-resource）

如资源模型中的描述，节点 reclaimed-resource 的资源总量会跟随高优先级容器实际的资源用量动态变化，在节点侧，为了保障 LS 容器的运行质量，BE 容器实际可用 CPU 数量同样受 LS 容器负载的影响。

如上图所示，当 LS 容器资源用量上涨时，受负载水位红线的限制，BE 容器可用的 CPU 数量相应减少，在系统层面会体现在容器 cgroup 分组的 CPU 绑定范围，以及 CPU 时间片的分配限制。

内核Group Identity

Alibaba Cloud Linux 2 从内核版本 kernel-4.19.91-24.al7 开始支持 Group Identity 功能，通过为容器设置不同的身份标识，可以区分容器中进程任务的优先级。内核在调度不同优先级的任务时有以下特点：

高优先级任务的唤醒延迟最小化。
低优先级任务不对高优先级任务造成性能影响。主要体现在：
低优先级任务的唤醒不会对高优先级任务造成性能影响。
低优先级任务不会通过 SMT 调度器共享硬件 unit（超线程场景）而对高优先级任务造成性能影响。

Group Identity 功能可以对每一个容器设置身份标识，以区分容器中的任务优先级。Group Identity 核心是双红黑树设计，在 CFS（Completely Fair Scheduler）调度队列的单红黑树基础上，新增了一颗低优先级的红黑树，用于存放低优先级任务。

系统内核在调度包含具有身份标识的任务时，会根据不同的优先级做相应处理。具体说明如下表：

LLC 及 MBA 隔离

在神龙裸金属节点环境，容器可用的 CPU 缓存（Last Level Cache，LLC）及内存带宽（Memory Bandwidth Allocation，MBA）可以被动态调整。通过对 BE 容器进程的细粒度资源限制，可以进一步避免对 LS 容器产生性能干扰。

内存资源质量

全局最低水位线分级

在 Linux 内核中，全局内存回收对系统性能影响很大。特别是时延敏感型业务（LS）和资源消耗型（BE）任务共同部署时，资源消耗型任务时常会瞬间申请大量的内存，使得系统的空闲内存触及全局最低水位线（global wmark_min），引发系统所有任务进入直接内存回收的慢速路径，进而导致延敏感型业务的性能抖动。在此场景下，无论是全局 kswapd 后台回收还是 memcg 后台回收，都将无法处理该问题。

基于上述场景下的问题，Alibaba Cloud Linux 2 新增了 memcg 全局最低水位线分级功能。在 global wmark_min 的基础上，将 BE 的 global wmark_min 上移，使其提前进入直接内存回收。将 LS 的 global wmark_min 下移，使其尽量避免直接内存回收。这样当 BE 任务瞬间申请大量内存的时候，会通过上移的global wmark_min 将其短时间抑制，避免 LS 发生直接内存回收。等待全局 kswapd 回收一定量的内存后，再解除 BE 任务的短时间抑制。

后台异步回收

在全局最低水位线分级后，LS 容器的内存资源不会被全局内存回收影响，但当容器内部紧张时会触发直接内存回收，直接内存回收是发生在内存分配上下文的同步回收，因此会影响当前容器中运行进程的性能。

为了解决这个问题，Alibaba Cloud Linux 2 增加了容器粒度的后台异步回收功能。该功能的实现不同于全局 kswapd 内核线程的实现，并没有创建对应的 memcg kswapd 内核线程，而是采用了 workqueue 机制来实现，并在 cgroup v1 和 cgroup v2 两个接口中，均新增了控制接口（memory.wmark_ratio）。

当容器内存使用超过 memory.wmark_ratio 时，内核将自动启用异步内存回收机制，提前于直接内存回收，改善服务的运行质量。

基于单机资源水位的驱逐

CPU 资源满足度

前文介绍了多种针对低优先级离线容器的 CPU 资源压制能力，可以有效保障 LS 类型业务的资源使用。然而在 CPU 被持续压制的情况下，BE 任务自身的性能也会受到影响，将其驱逐重调度到其他空闲节点反而可以使任务更快完成。此外，若 BE 任务在受压制时持有了内核全局锁这类资源，CPU 持续无法满足可能会导致优先级反转，影响 LS 应用的性能。

因此，差异化 SLO 套件提供了基于 CPU 资源满足度的驱逐能力，当 BE 类型容器的资源满足度持续低于一定水位时，使用 reclaimed 资源的容器会按从低到高的优先级被依次驱逐。

内存阈值水位

对于混部场景的内存资源，即便可以通过多种手段促使内核提前回收 page cache，优先保障 LS 容器的资源需求。但在内存资源超卖情况下，依然存在整机 RSS 内存用满导致 OOM 的风险。ACK 差异化 SLO 套件提供了基于内存阈值的驱逐能力，当整机 Memory 使用率水位超过阈值时，按优先级依次对容器进行 kill 驱逐，避免触发整机 OOM，影响高优容器的正常运行。

案例实践

使用 CPU Brust 提升应用性能

我们使用 Apache HTTP Server 作为延迟敏感型在线应用，通过模拟请求流量，评估 CPU Burst 能力对响应时间（RT）的提升效果。以下数据分别展示了 Alibaba Cloud Linux 2、CentOS 7 在 CPU Burst 策略开启前后的表现情况：

对比以上数据可得知：

在开启 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”功能在开启前后，各项数据指标的对比情况：

“差异化 SLO”功能开启后，通过集群 reclaimed-resource 资源超卖模型，集群内可以运行更多的 Spark 容器。
集群 CPU 平均利用率由 49% 提升至 58%；资源的充分利用使得评测集作业的总运行时间下降了 8%。

总结

阿里云容器服务 ACK 支持差异化 SLO 的相关功能将在官网陆续发布，各项功能可独立用于保障应用的服务质量，也可在混部场景下共同使用。实践表明，差异化 SLO 技术可以有效提升应用性能表现。特别是在混部场景下，ACK 差异化 SLO 混部技术可以将集群资源利用率提升至相当可观的水平；同时，针对在线时延敏感型服务，该技术可以将混部引入的性能干扰控制在 5% 以内。

原文链接

本文为阿里云原创内容，未经允许不得转载。