全部文档
当前文档

暂无内容

如果没有找到您期望的内容,请尝试其他搜索词

文档中心

混部与调度Colo组件介绍

最近更新时间:2024-09-10 16:07:52

Colo组件管理

  1. 登录容器服务控制台

  2. 点击集群名称,进入集群详情,请确保您要安装Colo组件的KCE集群Kubernetes版本为: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会基于设置的优先级做调度,优先级越高,在调度队列中,越容易得到调度。具体如下:

PriorityClass

区间定

描述

colo-prod

[9000, 9999]

典型的在线应用,特征是对响应时间较为敏感。

colo-mid

[7000, 7999]

流式计算,近线计算(为推荐系统提供的实时计算能力),AI类型任务

colo-batch

[5000, 5999]

离线批处理任务,例如大数据作业,OLAP类查询

colo-free

[3000, 3999]

低优先级的离线任务,常用于研发人员的测试场景。

服务质量

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

Colo QoS

描述

Kubernetes QoS

System

系统级服务

-

LSE(Latency Sensitive Exclusive)

敏感程度极高,要求独占CPU资源,不与其他任何Pod共享CPU核心。

Guaranteed

LSR(Latency Sensitive Reserved)

敏感程度介于LSE和LS之间,轻易不与其他任何应用共享CPU核心。与LS类型相比,LSR对CPU的确定性要求更高;与LSE类型相比,在自身资源空闲的前提下,LSR允许BE类型Pod临时使用。

Guaranteed

LS (Latency Sensitive)

延迟敏感型应用,与其他LS类型应用共享CPU资源,弹性较好,对于突发的资源需求可以比较灵活的得到满足。

Guaranteed/Burstable

BE(Best Effort)

敏感程度较低的资源消耗型Pod,在与以上类型应用混部时可以接受压制甚至驱逐,以避免对敏感型应用产生干扰。

BestEffort

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,该节点就属于热点节点。

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

文档导读
纯净模式常规模式

纯净模式

点击可全屏预览文档内容
文档反馈