本文介绍如何使用ack-koordinator快速搭建一套在离线混部环境,并将应用切换为混部模式运行。
前提条件
仅适用于ACK Pro版集群。具体操作,请参见创建ACK Pro版集群。
已安装ack-koordinator组件(原ack-slo-manager),且版本≥0.8.0。具体操作,请参见ack-koordinator(ack-slo-manager)。
为达到最佳的混部使用效果,建议您使用神龙裸金属服务器和Alibaba Cloud Linux。
资源优先级与QoS
资源优先级和服务质量QoS(Quality of Service)是ACK差异化SLO混部模型的两个核心概念。
资源优先级是对节点资源容量的描述,为了解决集群“分配率高,利用率低”的矛盾,优先级之间的主要区别如下:
各优先级的资源总量会受高优先级资源的申请量和使用量的影响,例如已申请但未使用的Product资源会以Batch优先级再次分配。
资源优先级策略的激进或保守,决定了集群资源的超卖容量,与资源稳定性的高低成反相关。
超卖优先级的资源以标准的extended-resource形式更新在Node信息中。
目前的资源模型包括以下两个资源等级:
资源优先级 | 资源计算原理 | 资源名称 |
Product | 通常为节点对应的物理资源量。 | K8s原生的Node可分配资源(Allocatable),包括CPU和Memory。 |
Batch | 根据节点利用率情况动态计算产生的超卖资源,计算模型为:整机物理资源-Product优先级的真实使用量,详情请参见动态资源超卖。 | 以extended-resource形式在Node状态中动态更新,包括 |
QoS是对应用性能敏感程度的描述,为了说明不同应用对资源质量需求的差异,影响Pod运行过程中的性能表现。具体表现为使用的隔离参数不同,宿主机资源紧张时会优先满足高等级QoS的需求。目前的资源模型包括以下两个服务质量等级:
QoS等级 | 适合应用类型 | 资源质量 |
LS (Latency Sensitive) | 延迟敏感型,即在线服务。 | 内核CPU时间片优先调度,内存回收时优先保障,可以使用更多的L3Cache和内存带宽资源等。 |
BE (Best Effort) | 资源消耗型,即混部对应的离线作业。 | 内核CPU时间片调度优先级较低,资源紧张时内存会被优先回收,L3Cache和内存带宽等资源的使用受限。 |
资源优先级和QoS是两个独立的维度,可以排列组合进行使用。但由于受模型定义和实际的需求情况的影响,部分排列组合存在约束,常用的典型场景包括以下两种:
Product+LS:典型的在线应用,通常对应用时延要求较高,对资源质量要求较高。例如Web服务、有延时要求的流式计算等。
Batch+BE:用于混部场景中的低优离线,对资源质量的要求相对更低。例如批处理类型的Spark或MR任务、AI类型的训练任务等。
管理混部策略
ack-koordinator提供了统一的ConfigMap来管理各项混部策略,您可以参照以下步骤,开启所有混部相关的优化策略。
使用以下ConfigMap,创建configmap.yaml文件。
#ConfigMap ack-slo-config样例。 apiVersion: v1 kind: ConfigMap metadata: name: ack-slo-config namespace: kube-system data: colocation-config: |- { "enable": true } resource-qos-config: |- { "clusterStrategy": { "lsClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } }, "beClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } } } } resource-threshold-config: |- { "clusterStrategy": { "enable": true } }
各项配置关联的混部策略说明如下:
配置项
功能描述
colocation-config
通过对节点负载数据的实时收集,可以充分挖掘集群中已分配但未使用的资源量,实现对集群资源的动态超卖,详情请参见动态资源超卖。
resource-qos-config
针对不同资源维度提供精细化管理能力,在容器运行阶段优先保障高优先级应用的QoS,详情请参见容器CPU QoS、容器内存QoS和容器L3 Cache及内存带宽隔离。
resource-threshold-config
宿主机弹性资源压制策略,根据资源使用水位对低优Pod的可用资源进行动态限制,详情请参见弹性资源限制。
执行以下命令,创建Configmap。
kubectl apply -f configmap.yaml
部署应用
使用以下内容,创建nginx-ls-pod.yaml文件。
为在线应用添加延时敏感型
LS
标签。此处以Nginx服务的Pod为例,在Pod的labels
处增加koordinator.sh/qosClass: LS
键值对。# nginx-ls-pod.yaml文件。 apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: LS app: nginx name: nginx spec: containers: - image: 'koordinatorsh/nginx:v1.18-koord-exmaple' imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 8000 hostPort: 8000 # 压测请求访问的端口。 protocol: TCP resources: limits: cpu: '8' memory: 1Gi requests: cpu: '8' memory: 1Gi volumeMounts: - mountPath: /apps/nginx/conf name: config hostNetwork: true restartPolicy: Never volumes: - configMap: items: - key: config path: nginx.conf name: nginx-conf name: config
使用以下内容,创建ffmpeg-be-pod.yaml文件。
为离线应用添加计算密集型
BE
标签,并申请超卖资源kubernetes.io/batch-cpu
和kubernetes.io/batch-memory
。此处以转码类型的Pod为例,在Pod的labels
处增加koordinator.sh/qosClass: BE
键值对。# ffmpeg-be-pod.yaml文件。 apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: BE name: be-ffmpeg spec: containers: - command: - start-ffmpeg.sh - '30' - '2' - /apps/ffmpeg/input/HD2-h264.ts - /apps/ffmpeg/ image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1' imagePullPolicy: Always name: ffmpeg resources: limits: # 单位为千分之一核。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi" requests: # 单位为千分之一核。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi"
执行以下命令,部署在线应用和离线应用的Pod。
kubectl apply -f nginx-ls-pod.yaml kubectl apply -f ffmpeg-be-pod.yaml
后续操作
应用部署完毕后,您可以使用ACK的在离线混部能力,详情请参见在线服务与视频转码应用混部。
关于在离线混部功能的更多信息,请参见: