本文介绍在离线混部的技术架构、混部资源模型和单机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差异化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中增加qos和batch的字段即可，其中qos: LS表示高优先级，qos: BE表示低优先级；batch-cpu和batch-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 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长尾现象严重的原因之一。
CPU Burst机制可以有效解决延迟敏感性应用的RT长尾问题，允许容器在空闲时积累一些CPU时间片，用于满足突发时的资源需求，提升容器性能。目前ACK已经完成了对CPU Burst机制的全面支持。对于尚未支持CPU Burst策略的内核版本，ACK也会通过类似的原理，监测容器CPU Throttle状态，并动态调节容器的CPU Limit，实现与内核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.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快速搭建一套在离线混部环境。关于在离线混部功能的更多信息，请参见：