如何在云原生混部场景下利用资源配额高效分配集群资源？

引言

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

由于混部是一个复杂的技术及运维体系，包括 K8s 调度、OS 隔离、可观测性等等各种技术，之前的一篇文章《历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的？》，主要聚焦在调度优先级和服务质量模型上，今天我们来关注一下资源配额多租相关的内容。

资源配额概述

首先想提一个问题，在设计上，既然 K8s 的调度器已经可以在没有资源的情况下，让 pod 处于 pending 状态，那为什么，还需要有一个资源配额（Resource Quota）的设计？

我们在学习一个系统时，不但要学习设计本身，还需要考虑为什么这个设计是必须的？如果把这个设计从系统中砍掉，会造成什么后果？因为在一个系统中增加任何一项功能设计，都会造成好几项边际效应（Side Effect），包括使用这个系统的人的心智负担，系统的安全性、高可用性，性能，都需要纳入考虑。所以，功能不是越多越好。越是优秀的系统，提供的功能反而是越少越好。例如 C 语言只有 32 个关键字，而用户可以通过自定义组合这些基础能力，实现自己想要的任何需求。

回到原问题，一个集群的资源一定是有限的，无论是物理机上的 CPU、内存、磁盘，还有一些别的资源例如 GPU 卡这些。光靠调度，是否能解决这个问题呢？如果这个集群只有一个用户，那么这个问题其实还是能忍受的，例如看到 pod pending了，那就不创建新的 pod 了；如果新的 pod 比较重要，这个用户可以删掉旧的 pod，然后再创建新的。但是，真实的集群是被多个用户或者说团队同时使用的，当 A 团队资源不够了，再去等 B 团队的人决策什么应用可以腾挪出空间，在这个时候，跨团队的交流效率是非常低下的。所以在调度前，我们就需要再增加一个环节。如下图所示：