混部与调度Colo组件介绍

Colo组件管理

1. 登录容器服务控制台。

2. 点击集群名称，进入集群详情，请确保您要安装Colo组件的KCE集群Kubenetes版本为：v1.21及以上且v1.25及以下。

3. 集群控制台左侧菜单栏选择组件管理，进入组件管理列表页。

4. 组件列表页中点击Colo组件，进入Colo组件安装界面，进行Colo组件的安装。

新建Colo实例

勾选Colo的组件配置与功能特性新建Colo实例。

组件管理

• 管理模块colo-manager：默认开启，2个副本。负责node节点cololet agent配置同步，例如BE内存&CPU分配比例、开启压制开关以及Node resource计算工作等。

• 调度模块colo-scheduler：默认开启，3个副本。负责在线和离线应用调度。

• 重调度模块colo-descheduler：可选开启，默认1个副本。负责定期检测集群状态，对不符合预期的情况进行动态调整，使集群始终处于健康状态，主要应用于实时运行过程中Pod的二次调度。

功能特性

• 离线任务CPU压制（BECPUSuppress）：当负载增高时，对BE离线任务CPU使用量进行限制，优先保证LS在线应用能竞争到更多的CPU资源。

• 离线任务CPU驱逐（BECPUEvict）：开启离线任务CPU压制后，当在线应用CPU使用量激增时，会导致该节点上的离线任务被压制在少量的CPU上，使离线任务运行质量受损。因此离线任务CPU驱逐可以将该节点上的离线任务Pod驱逐到负载较低的节点上去，避免使离线任务运行质量受损。

• 离线任务内存回收（MemoryRecovery）：利用memory cgroup子系统，在节点内存资源紧张时，通过调整离线任务cgroup中的参数来释放部分内存/缓存，以保证在线应用的内存资源需求。

• 离线任务内存驱逐（BEMemoryEvict）：当节点内存利用率较高时，为防止在执行OOM流程中只考虑内存优先级，导致在线应用的进程可能被kill掉的情况发生，colo提供了内存驱逐功能，支持配置节点级别的内存安全水位线，当节点内存资源高于安全水位线时，会优先驱逐离线任务的pod，保障在线应用的服务质量。

• 离线任务Cgroup调谐（BECgroupReconcile）：离线任务Cgroup调谐与离线任务内存回收特性，两者只能选择其一开启。开启离线任务Cgroup调谐后，可以使用YARN感知调度。

• Cgroup调谐（CgroupReconcile）：适用于欧拉内核和龙蜥内核，开启Cgroup调谐后，可以使用内存优先级与CPU优先级等功能。

• 离线网络压制（NetSuppress）：在高优先级的pod的网络带宽负载过高时，能压制低优先级的pod的网络带宽。支持给离线任务设置网络带宽区间，避免网络带宽资源利用太多，离线任务占用太多整个节点的网络带宽资源。

• 离线任务Blkio压制（BlkioAllocator）：Blkio磁盘压制是为了减少进程之间同时读写磁盘时相互干扰的问题，开启后可以根据pod annotation中的数据来修改离线任务pod的blkio cgroup。

节点cololet的部署

cololet可以选择具体的节点部署，部署完cololet的节点可以使用在离线混部调度。节点部署cololet的步骤为：

1. 集群控制台左侧菜单栏点击节点管理，选择节点进入节点列表页。

2. 点击标签和污点，进入标签界面，选择需要混部的节点，为其打上colocation=on 的标签。

更新Colo实例

Colo组件部署完成后，可随时通过组件管理->Colo组件实例->操作中的更新按钮，随时更新Colo安装的组件模块与功能特性。

升级Colo版本

当Colo有新版本发布时，通过组件管理->Colo组件实例->操作中的升级按钮，可进行Colo组件的版本升级。

Colo使用方式

调度优先级

Colo将Priority（调度优先级）分为colo-prod/colo-mid/colo-batch/colo-free四个等级，优先级依次递减，Pod Yaml中指定申请的资源优先级，colo-scheduler会基于设置的优先级做调度，优先级越高，在调度队列中，越容易得到调度。具体如下：

服务质量

Colo将 QoS（服务质量） 整体分为 System（系统级服务），Latency Sensitive（延迟敏感型的在线服务），Best Effort（资源消耗型的离线任务）三类，根据应用性能敏感程度的差异，Latency Sensitive 又细分为 LSE，LSR 和 LS。具体如下:

Priority与QoS关系描述

使用Colo调度系统进行离在线业务混部时，根据不同业务场景可通过配置Priority与QoS的关键字段colo.sh/qosClass与priorityClassName字段进行匹配部署。

典型场景：

• colo-prod & LS：适用于典型的在线服务，通常对应用的延迟、资源质量要求较高，运行时间较长，也需要保证一定的资源弹性能力。

• colo-batch & BE：适用于混部场景中的低优离线任务，通常表现为对资源质量有相当的忍耐度，对延迟不敏感，运行时间相对较短，例如批处理类型的Spark/MR任务、AI训练任务等。

典型场景的增强：

• colo-prod & LSR/LSE：适用于比较敏感的在线服务，可以接受牺牲资源弹性而换取更好的确定性（如CPU邦核），对应用时延要求极高。

• colo-mid/colo-free & BE：Colo-mid&BE适用于对资源要求较高的离线任务，例如流式计算、近线计算等场景；colo-free&BE更适用于更低优先级的离线任务，例如研发人员的测试场景。

应用示例

离线任务（Batch + BE）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-be
  labels:
    app: batch-be
spec:
  replicas: 1
  selector:
    matchLabels:
      app: batch-be
      colo.sh/offline: "true"colo.sh/qosClass: "BE"
      priorityClassName: colo-batch
  template:
    metadata:
      labels:
        app: batch-be
        colo.sh/offline: "true"
        colo.sh/qosClass: "BE" 
        priorityClassName: colo-batch 
        #coloPriority: 5000
      annotations:
        colo.sh/be-resource-policy: "true"  // 适合yarn 感知调度场景，非此场景请删除该annotaion
    spec:
      schedulerName: colo-scheduler
      containers:
        - name: nginx
          image: nginx
          resources:
            limits:
              colo.sh/batch-cpu: "100"
              colo.sh/batch-memory: 300Mi
            requests:
              colo.sh/batch-cpu: "100"
              colo.sh/batch-memory: 300Mi

在线应用（LS）

# Qos of K8s is Burstable
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ls-burstable
  labels:
    app: ls-burstable
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ls-burstable
      colo.sh/qosClass: "LS"
  template:
    metadata:
      labels:
        colo.sh/qosClass: "LS"
        app: ls-burstable
    spec:
      schedulerName: colo-scheduler
      containers:
        - name: stress
          image: hub.kce.ksyun.com/yimenghua/stress:1.0.4
          imagePullPolicy: IfNotPresent
          command: [ "stress" ]
          args: [ "-c" ,"1" ]
          resources:
            limits:
              cpu: "1"
              memory: 300Mi
            requests:
              cpu: "1"
              memory: 200Mi

在线应用yaml（Garanteed & 绑核）：

// Qos of K8s is Garanteed
……
          resources:
            limits:
              cpu: "4"
              memory: 300Mi
            requests:
              cpu: "4"
              memory: 300Mi

在线应用yaml（Garanteed & 不绑核）：

// Qos of K8s is Garanteed
……
          resources:
            limits:
              cpu: "350m"
              memory: 300Mi
            requests:
              cpu: "350m"
              memory: 300Mi

功能介绍

CPU 压制

在负载变高时，进程之间会竞争cpu资源，为了确保在负载提高时，在线pod能竞争到更多的cpu资源，需要对类别为Best Effort 的 Pod 的cpu使用量进行限制。cololet支持两种压制策略，cpuset和cfsquota。

cpuSuppress中，定义所有BE可用资源 suppress（BE）为：

suppress(BE) = node.total * cpuSuppressThresholdPercent - pod(LS).Used - system.Used

CPU驱逐

cololet提供了cpu压制功能，若LS 类型的pod cpu使用量激增，cololet将会压制所有Best Effort类型的pod，导致该节点上的BE Pod被压制在少量CPU上，若开启压制措施的是cfsquota，cpu的使用量会被压制，该节点上的be pod的运行质量受损，所以我们需要将该节点上的be pod驱逐到负载较低的node中。

Memory回收

colo提供内存回收功能，利用memory cgroup子系统，在节点内存资源紧张时，通过调整离线任务cgroup中的参数来释放部分内存/缓存，以保证在线任务的资源需求。colo支持多种内存策略，针对不同场景（如操作系统内核的不同）使用不同的内存分配方案：

• none：不设置任何策略，不会对内存进行调整。

• dynlevel：动态分级调整策略，基于内核cgroup的多级别控制。通过监测节点内存压力，多级别动态调整离线业务的memory cgroup，尽可能地保障在线业务服务质量。

• fssr：快压制慢恢复策略，基于内核cgroup的动态水位线控制，colo动态检测内存压力，动态调整离线应用的memory.high上限，实现对离线业务的内存压制，保障在线业务的服务质量。

开启MemoryRecovery特性，以dynlevel为例：

// 配置memory回收配置功能的开关,修改cololet 启动参数，这里以dynlevel策略为例
--memory-recovery-strategy=dynlevel

MEM驱逐

为了提升混部系统中资源的利用率，colo提供了资源超卖功能，支持将节点中空闲资源动态超卖给BE pod，然而节点实际的内存利用率时刻在变化，内存属于不可压缩类型的资源，对于不可压缩类型的资源，当节点利用率较高时，会触发OOM，在执行oom流程中，只考虑内存优先级，导致在线任务的进程可能被kill掉，为防止这一情况发生，colo提供了mem驱逐功能，支持配置节点级别的内存安全水位线，当节点内存资源高于安全水位线时，会优先驱逐BE 类型的pod，保障在线任务的服务质量。

支持动态ebpf指标动态采集

使用ebpf来采集指标，判断业务的服务质量，通过二次开发ebpf exporter，识别metricsprograms对象的字段，获取ebpf code 和 prometheus label，将采集的数据，暴露在metrics下。

Blkio压制

Blkio磁盘压制是为了减少进程之间同时读写磁盘时相互干扰的问题，默认开启。在 blkio cgroup 中，主要有以下四个参数来限制磁盘 I/O：

blkio.throttle.write_bps_device:  # 针对具体的设备设置每秒写磁盘的带宽上限。
blkio.throttle.read_bps_device:   # 针对具体的设备设置每秒读磁盘的带宽上限。
blkio.throttle.read_iops_device:  # 针对具体的设备设置每秒读磁盘的次数上限。
blkio.throttle.write_iops_device: # 针对具体的设备设置每秒写磁盘的次数上限。

网络带宽压制

在高优先级的pod的网络带宽负载过高时，能压制低优先级的pod的网络带宽。支持给离线任务设置网络带宽区间，避免网络带宽资源利用太多，离线任务占用太多整个节点的网络带宽资源。

Yarn感知调度

大数据场景中，NodeManager作为Yarn的单个节点的代理，它管理Hadoop集群中单个计算节点，其需要与应用程序的ApplicationMaster和集群资源管理器RM交互，组件需要本节点可用的cpu和memory资源，拉起离线任务在NodeManager中。Yarn感知调度，使得nodemanager与node.status 的数据保持一致。

NUMA感知调度

非统一内存访问架构（numa）是一种共享内存架构，NUMA感知调度使得CPU访问内存效率最大化。

负载感知调度

colo通过超卖机制超卖一些资源，可以提升资源的利用率，但是BE类型的工作负载也会干扰延迟敏感的应用程序，尤其是当节点负载水位较高时，在线离线业务同时竞争资源，这种干扰带来的影响会放大，不仅可能导致延迟敏感型应用的服务质量，也可能导致离线类型的工作负载本身也不能很快的完成任务，因此colo提供了负载感知调度，支持根据节点实际负载来调度，以控制集群的资源利用率，将资源利用率控制在安全阈值内。根据实际资源负载，将集群的pod调度到到可用资源较多的Node上，避免Node负载过高，在线离线争抢资源，也避免了Node负载过低，资源被闲置而未使用。

重调度

重调度是对pod进行驱逐以进行二次调度，pod迁移是一个复杂的过程,涉及审计、资源分配(资源的抢占和预分配)和应用启动等步骤,资源的调度和使用涉及到整个混部系统。

loadaware扩展了balance扩展点，负责感知负载水位完成热点打散重调度的工作，Loadaware根据节点真实利用率的情况决策重调度。loadaware插件有两个最重要的参数:

highThresholds表示负载水位的目标安全阈值，超过该阈值的节点上的 Pod 将参与重调度。

lowThresholds表示负载水位的空闲安全水位。低于该阈值的节点上的 Pod 不会被重调度。

• 当节点所有资源使用率都低于lowThresholds被称为空闲节点。

• 当节点存在资源的使用率高于highThresholds，该节点就属于热点节点。

• 介于空闲节点和热点节点之间的成为正常节点。