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

作者：南异
引言阿里巴巴在离线混部技术从 2014 年开始，经历了七年的双十一检验，内部已经大规模落地推广，每年为阿里集团节省数十亿的资源成本，整体资源利用率达到 70% 左右，达到业界领先。这两年，我们开始把集团内的混部技术通过产品化的方式输出给业界，通过插件化的方式无缝安装在标准原生的 K8s 集群上，配合混部管控和运维能力，提升集群的资源利用率和产品的综合用户体验。
由于混部是一个复杂的技术及运维体系，包括 K8s 调度、OS 隔离、可观测性等等各种技术，本文将聚焦在 K8s 层的容器优先级和服务质量模型上，希望给业界提供一些可借鉴的思路。
K8s 原生模型在实际的生产实践中，即使是很多对云原生和 K8s 比较熟悉的技术人员，往往也会混淆调度优先级（Priority）和服务质量（QoS）。
所以，在谈混部的模型前，首先我们对 K8s 原生的概念做详细的介绍，详见下表：

文章图片

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

文章图片

混部需要解决的问题混部主要解决的问题是，在保证部署应用的服务等级目标 SLO 的前提下，充分利用集群中的空闲资源，来提升集群整体的利用率。
当一个集群被在线服务部署分配部署完以后，由于在线应用的高保障的特性，会给容器一个 peak 的资源规格，这样有可能导致实际真实利用率很低。

文章图片

我们希望将这部分空闲但是未使用的资源超卖出来提供给低 SLO 的离线作业使用，以此提高整体机器水位。这样就需要提供基于 SLO 的调度能力，以及考虑到机器真实资源水位进行调度，避免热点的产生。
【历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的（）】另外，由于在线通常 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 上的运行时的情况

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

文章图片

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

文章图片

可以看到，这个等级，不但和 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/co...
2） https://kubernetes.io/docs/co...
3） https://kubernetes.io/docs/co...
4） https://kubernetes.io/docs/co...
5） https://kubernetes.io/docs/ta...
6） https://my.oschina.net/HardyS...
文内详情链接 1）节点压力驱逐(Node-pressure Eviction)：
https://kubernetes.io/docs/co...
2）PriorityClass：
https://kubernetes.io/docs/co...
3）PodDisruptionBudget：
https://kubernetes.io/docs/ta...
4）Eviction：
https://kubernetes.io/docs/co...
5）QosClass：
https://kubernetes.io/docs/ta...
6）PriorityClass：
https://kubernetes.io/docs/co...
7）PodDisruptionBudget：
https://kubernetes.io/docs/ta...
8）Eviction：
https://kubernetes.io/docs/co...
点击此处，即可查看阿里云专有云敏捷版云原生 Stack 相关介绍！