历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的？

作者：南异

引言

阿里巴巴在离线混部技术从 2014 年开始，经历了七年的双十一检验，内部已经大规模落地推广，每年为阿里集团节省数十亿的资源成本，整体资源利用率达到 70% 左右，达到业界领先。这两年，我们开始把集团内的混部技术通过产品化的方式输出给业界，通过插件化的方式无缝安装在标准原生的 K8s 集群上，配合混部管控和运维能力，提升集群的资源利用率和产品的综合用户体验。

由于混部是一个复杂的技术及运维体系，包括 K8s 调度、OS 隔离、可观测性等等各种技术，本文将聚焦在 K8s 层的容器优先级和服务质量模型上，希望给业界提供一些可借鉴的思路。

K8s 原生模型

在实际的生产实践中，即使是很多对云原生和 K8s 比较熟悉的技术人员，往往也会混淆调度优先级（Priority）和服务质量（QoS）。

所以，在谈混部的模型前，首先我们对 K8s 原生的概念做详细的介绍，详见下表：

从 API 层面详细描述的话，可以看下面这张表

混部需要解决的问题

混部主要解决的问题是，在保证部署应用的服务等级目标 SLO 的前提下，充分利用集群中的空闲资源，来提升集群整体的利用率。

当一个集群被在线服务部署分配部署完以后，由于在线应用的高保障的特性，会给容器一个 peak 的资源规格，这样有可能导致实际真实利用率很低。

我们希望将这部分空闲但是未使用的资源超卖出来提供给低 SLO 的离线作业使用，以此提高整体机器水位。这样就需要提供基于 SLO 的调度能力，以及考虑到机器真实资源水位进行调度，避免热点的产生。

另外，由于在线通常 SLO 比较高，离线 SLO 比较低，那么当机器水位整体提升过高的时候，可以通过抢占离线的作业方式，来保障在线应用的 SLO。以及需要利用率内核层面 cgroup 的隔离特性来保障高 SLO 和低 SLO 作业。

那么，在这些在线和离线的 Pod 之间，我们就需要用不同的调度优先级和服务质量等级，以满足在线和离线的实际运行需求。

云原生混部定义的应用等级模型

首先请看一下在混部中一个 Pod 的 yaml 是怎么定义的

apiVersion: v1 kind: Pod metadata: annotations: alibabacloud.com/qosClass: BE # {LSR,LS,BE} labels: alibabacloud.com/qos: BE # {LSR,LS,BE} spec: containers: - resources: limits: alibabacloud.com/reclaimed-cpu: 1000 # 单位 milli core，1000表示1Core alibabacloud.com/reclaimed-memory: 2048 # 单位 字节，和普通内存一样。单位可以为 Gi Mi Ki GB MB KB requests: alibabacloud.com/reclaimed-cpu: 1000 alibabacloud.com/reclaimed-memory: 2048 

这是在混部里面我们引入的 Pod 的等级，和社区原生不同的地方在于，我们显式的在 anotation 和 label 里面申明了 3 种等级：LSR、LS、BE。这 3 种等级会同时和调度优先级（Priority）、服务质量（Qos）产生关联。

具体的每个容器的资源用量，LSR 和 LS 还是沿用原有的 cpu/memory 的配置方式，BE 类任务比较特殊，通过社区标准的 extended-resource 模式来申明资源。

那么，这 3 类等级具体代表的运行时含义又是什么呢？可以参考这个图，看下这三类应用在 CPU 上的运行时的情况

以及详细的对其他资源使用的影响：

可以看到，这个等级，不但和 Pod 在单机上运行的 CPU、内存有关，还和网络 Qos 的全链路优先级有关，避免低优的离线类任务抢占了所有的网络带宽。阿里在内核方面做的工作有效的保证了运行时的应用稳定性，2021 年双 11 期间，阿里成为全球首家将所有业务都放在自家公共云上的大型科技公司，这意味着阿里云有能力应对高难度复杂环境下的技术挑战，也带来了非常大的技术收益：阿里巴巴业务的研发效率提升了 20%、CPU 资源利用率提升 30%、应用 100% 云原生化、在线业务容器可达百万规模，同时计算效率大幅提升，双 11 整体计算成本三年下降 30%。在这个过程中，混合部署技术发挥了重要作用。内核团队及云原生团队工程师踩了无数的坑，沉淀了包括弹性 CPU 带宽、Group Identity、SMT expeller、memcg 异步回收、内存水线分级、memcg OOM 等多项高级特性，处于业界领先水平。这些工作都会在系列的文章里面后续一一介绍。

当这三种类型优先级任务实际在调度和运行时发生的行为，如下面这个表所示

也就是说，混部的优先级会同时作用于调度和运行时，最大程度的保证高 SLO 的高优、中优任务使用集群内的资源。

配额、水位线、多租隔离

本文仅聚焦讨论了 K8s 单 Pod 的调度优先级，在实际使用时，为了保证应用的 SLO，需要配合单机的水位线、租户的配额、以及 OS 隔离能力等等使用，我们会在后续文章里面详细探讨。

相关解决方案介绍

进入了 2021 年，混部在阿里内部已经成为了一个非常成熟的技术，为阿里每年节省数十亿的成本，是阿里数据中心的基本能力。而阿里云也把这些成熟的技术经过两年的时间，沉淀成为混部产品，开始服务于各行各业。

在阿里云的产品族里面，我们会把混部的能力通过 ACK 敏捷版，以及 CNStack（CloudNative Stack）产品家族，对外进行透出，并结合龙蜥操作系统（OpenAnolis），形成完整的云原生数据中心混部的一体化解决方案，输出给我们的客户。

参考文档

1） https://kubernetes.io/docs/concepts/scheduling-eviction/

2） https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

3） https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

4） https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

5） https://kubernetes.io/docs/tasks/configure-pod-container/extended-resource/

6） https://my.oschina.net/HardySimpson/blog/1359276

文内详情链接

1）节点压力驱逐(Node-pressure Eviction)： https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

2）PriorityClass： https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass

3）PodDisruptionBudget： https://kubernetes.io/docs/tasks/run-application/configure-pdb/

4）Eviction： https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/

5）QosClass： https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

6）PriorityClass： https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass

7）PodDisruptionBudget：

https://kubernetes.io/docs/tasks/run-application/configure-pdb/

8）Eviction： https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/

点击此处，即可查看阿里云专有云敏捷版云原生 Stack 相关介绍！