关于阿里云:阿里云容器服务差异化-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-core
    alibabacloud.com/reclaimed-cpu: 50000
    # bytes
    alibabacloud.com/reclaimed-memory: 50000
  capacity:
    alibabacloud.com/reclaimed-cpu: 50000
    alibabacloud.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: 1000
        alibabacloud.com/reclaimed-memory: 2048 
      requests:
        alibabacloud.com/reclaimed-cpu: 1000
        alibabacloud.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）调度队列的单红黑树根底上，新增了一颗低优先级的红黑树，用于寄存低优先级工作。

零碎内核在调度蕴含具备身份标识的工作时，会依据不同的优先级做相应解决。具体阐明如下表：

更多对于内核 Group Identity 能力的详细描述，可参见官网文档：
https://help.aliyun.com/document_detail/338407.html

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 工作的短时间克制。

更多对于内核全局内存最低水位线分级能力的详细描述，可参见官网文档：
https://help.aliyun.com/document_detail/169537.htm

后盾异步回收

在全局最低水位线分级后，LS 容器的内存资源不会被全局内存回收影响，但当容器外部缓和时会触发间接内存回收，间接内存回收是产生在内存调配上下文的同步回收，因而会影响以后容器中运行过程的性能。

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

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

更多对于容器内存后盾异步回收能力的形容，可参见官网文档：
https://help.aliyun.com/document_detail/169535.html

基于单机资源水位的驱赶

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% 以内。

点击此处，即可查看阿里云容器服务 ACK 反对差异化 SLO 各项性能的具体介绍！