文档

在离线混部概述

更新时间:

本文介绍在离线混部的技术架构、混部资源模型和单机QoS保障,帮助您快速了解和使用在离线混部。

背景信息

从集群维度来看,混部是将多种应用在一个集群内部署,通过预测分析应用特性,实现业务对集群资源的充分利用;从节点维度来看,混部是将多个容器部署在同一个节点上,这些容器内的应用既包括在线类型,也包括离线类型。根据应用对资源质量需求的差异,在线应用可以归纳为延时敏感型LS(Latency Sensitive),通常对请求压力(QPS)或访问延迟(RT)等指标有明确的要求,对资源质量较为敏感;离线应用可以归纳为资源消耗型BE(Best Effort),通常是一些计算密集型的任务类应用,有较好的容错重试能力,对资源质量的要求相对较为宽松。

在部署混部的过程中,不同角色的管理人员的侧重点不同:

  • 集群资源的管理员:期望可以简化对集群资源的管理,洞察各类应用的资源容量、分配量和使用量,提升集群资源利用率,达到降低IT成本的目的。

  • 在线类型应用的管理员:更关注容器在混合部署后的干扰问题,因为混部会更容易产生资源竞争,应用的响应时间往往会出现长尾现象(即总有一部分请求的延迟显著地高于平均值,通常表现为响应时间的90或99分位值大幅高于平均值),导致应用服务质量下降。

  • 离线类型应用的管理员:更期望混部系统可以提供分级可靠的资源超卖,满足不同作业类型的差异化资源质量需求。

针对以上问题,ACK在离线混部方案提供了以下机制,可以充分满足不同角色对混部系统的技术需求:

  • 面向混部场景的资源优先级和服务质量模型。

  • 稳定可靠的资源超卖机制。

  • 细粒度的容器资源编排和隔离机制。

  • 增强多种类型工作负载的调度能力。

技术架构

ack-koordinator是ACK支持差异化SLO混部能力的扩展组件,由中心侧Controller和单机侧Agent组成。Controller是标准的K8s扩展,以Deployment形式进行部署;Agent以DaemonSet形式进行部署,在标准kubelet的基础上支持各类混部能力。

 ack-koord-arch

整体架构如上图所示,ACK差异化SLO混部方案定义了一系列协议,例如使用CRD记录各节点的指标数据以及各类QoS策略的配置和执行情况、使用标准的extended-resource记录动态资源超卖容量等,各组件围绕该协议的功能机制如下:

  • SLO Controller:负责感知各节点运行时负载,并根据资源画像完成智能资源超卖与SLO保障。

  • Recommender:提供资源画像功能,预估工作负载的峰值资源需求,简化您的配置容器资源规格的复杂度。

  • Koordlet:负责节点闭环控制回路,运行时负载感知与异常检测,资源动态隔离与干扰抑制。

  • ACK Scheduler:针对差异化SLO混部场景进行额外的优化,例如针对动态超卖资源调度时的打散。

  • Koordinator Descheduler:以Deployment的形式部署的中心组件,提供重调度功能。

新图片

混部资源模型

在K8s的资源管理机制中,应用容器都是按照Request和Limit的形式申请资源,为了确保资源的稳定性,管理员通常会为LS类型的应用申请较大的资源Request和Limit,因此会出现K8s集群资源的分配率(Requested)较高,而实际利用率(Usage)较低的情况。

缺点

如下图所示,将绿色部分的可动态超卖的资源量,分配给BE类型的业务,可以充分利用工作负载对资源运行质量需求不同的特征,提升集群整体资源利用率。

混部资源模型

阿里云容器服务ACK差异化SLO扩展套件提供了将这部分超卖资源量化的能力,动态计算当前的Reclaimed资源量,并以标准扩展资源的形式实时更新到K8s的Node元信息中。

Node YAML示例如下:

status:
  allocatable:
    # milli-core
    kubernetes.io/batch-cpu: 50000
    # bytes
    kubernetes.io/batch-memory: 50000
  capacity:
    kubernetes.io/batch-cpu: 50000
    kubernetes.io/batch-memory: 100000

低优先级的BE任务在使用Reclaimed资源时,只需在Pod YAML中增加qosbatch的字段即可,其中qos: LS表示高优先级,qos: BE表示低优先级;batch-cpubatch-memory表示Pod的具体资源的需求量。更多信息,请参见动态资源超卖

BE Pod的YAML示例如下:

metadata:
  labels:
    koordinator.sh/qosClass: "BE" # 可配置为BE或LS。
spec:
  containers:
  - resources:
      limits:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048
      requests:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048

单机QoS保障

CPU QoS

为了提高LS应用使用CPU资源的稳定性,降低BE应用的干扰,ack-koordinator基于Alibaba Cloud Linux,提供了容器CPU QoS功能。ack-koordinator通过Group Identity提供的Linux调度优先级,差异化保障不同优先级应用的CPU调度,将LS应用标识为高优先级,BE应用标识为低优先级,在混合部署场景中可以有效改善LS应用的服务质量。

通过启用容器CPU QoS功能,您可以获得以下功能特性:

  • LS应用的任务唤醒延迟最小化。

  • BE应用的任务唤醒不会对LS容器造成性能影响。

  • BE应用的任务不会通过同时多线程SMT(Simultaneous Multithreading)调度器共享物理核,对LS应用造成性能影响。

弹性资源限制(CPU Suppress)

在混部资源模型中,超卖的混部资源总量会根据高优先级LS(Latency Sensitive)类型Pod的实际资源用量而动态变化,这部分资源可以供低优先级BE(BestEffort)类型Pod使用。为了确保BE类型Pod的CPU资源使用在安全范围内,避免LS类型应用的运行质量受到干扰,ack-koordinator在节点侧提供了弹性资源限制功能。弹性资源限制功能可以帮您在整机资源用量安全水位下,控制BE类型Pod可使用的CPU资源量,保障节点内容器稳定运行。

如下图所示,在整机安全水位下(CPU Threshold),随着LS类型Pod资源使用量的变化(Pod(LS).Usage),BE类型Pod可用的CPU资源被限制在合理的范围内(CPU Restriction for BE)。通过这种方式可以使BE类型Pod充分使用空闲资源,提升离线任务的吞吐,并且当在线负载增加时,避免对BE类型Pod占用过多的资源,影响在线应用的服务质量。

CPU Suppress

CPU Burst

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

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

RT长尾

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

CPU Burst

Memory QoS

容器在使用内存时主要存在以下两个方面的约束:

  • 自身内存限制:当容器自身的内存(含Page Cache)接近容器上限时,会触发内核的内存回收子系统,这个过程会影响容器内应用的内存申请和释放的性能。

  • 节点内存限制:当容器内存超卖(Memory Limit > Request)导致整机内存不足,会触发内核的全局内存回收,这个过程对性能影响较大,特别是对于在离线混部场景,性能影响更大。

为了提高应用运行时性能和节点的稳定性,ack-koordinator结合Alibaba Cloud Linux提供了容器内存QoS保障的能力,根据Pod参数自动配置内存子系统(Memcg),为容器开启Memcg QoS、内存后台回收和全局最低水位线分级特性,可以保障容器的内存资源QoS和公平性。

容器内存QoS提供以下功能特性:

  • Pod内存使用接近Limit限制时,优先在后台异步回收一部分内存,缓解直接内存回收带来的性能影响。

  • Pod之间实施更公平的内存回收,整机内存资源不足时,优先从内存超用(Memory Usage > Request)的Pod中回收内存,避免个别Pod造成整机内存资源质量下降。

  • 优先保障LS类型Pod的内存QoS,延缓LS Pod触发整机内存回收的时机。如下图所示:Memory QoS

    • memory.limit_in_bytes:内存使用上限。

    • memory.high:内存限流阈值。

    • memory.wmark_high:内存后台回收阈值。

    • memory.min:内存使用锁定阈值。

L3 Cache及内存带宽隔离

不同类型的应用容器在节点运行时会共享宿主机的三级缓存L3 Cache(Last Level Cache)和内存带宽MBA(Memory Bandwidth Allocation)。神龙裸金属节点提供了动态调整容器可用的CPU缓存LLC(Last Level Cache)和内存带宽MBA(Memory Bandwidth Allocation)的能力,ack-koordinator通过对BE容器进程的细粒度资源限制,避免干扰LS容器的性能。

后续操作

您可以参考快速入门,使用ack-koordinator快速搭建一套在离线混部环境。关于在离线混部功能的更多信息,请参见:

  • 本页导读 (1)
文档反馈