共计 3500 个字符，预计需要花费 9 分钟才能阅读完成。
简介：因为混部是一个简单的技术及运维体系，包含 K8s 调度、OS 隔离、可观测性等等各种技术，之前的一篇文章《历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的？》，次要聚焦在调度优先级和服务质量模型上，明天咱们来关注一下资源配额多租相干的内容。
引言
在阿里团体，离线混部技术从 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 团队的人决策什么利用能够腾挪出空间，在这个时候，跨团队的交换效率是十分低下的。所以在调度前，咱们就须要再减少一个环节。如下图所示：
在这个环节内，引入了资源配额和租户这 2 个概念。租户，是进行资源配额调配的团队单位。配额，则是多个租户在应用无限的集群资源时，相互在当时达成的一个共识。当时是一个十分重要的关键词，也就是说不能等到 pod 到了调度时、运行时，再去通知创建者这个 pod 因为配额有余而创立不进去，而是须要在创立 pod 之前，就给各个团队一个对资源的心理预期，每年初在配置资源配额时，给 A 团队或者 B 团队定一个往年能够应用的配额总量，这样当 A 团队配额用完时，A 团队外部能够先进行资源优先级排序，把不重要的 pod 删除掉，如果还不够，那就再和 B 团队磋商，是否能够从 B 团队的配额划分一些配额过去。这样的话，就无需任何状况下都要进行点对点的低效率沟通。A 团队和 B 团队在年初的时候就须要对本人的业务的资源用量，做一个大略的估算，也就是资源估算。
所以从这个角度来说，资源配额，是多个租户之间低频高效率沟通单干的一种形式。如果把配额这个概念放到经济学中，是不是就有点计划经济的感觉了呢？其实外面的核心思想是统一的，都是在无限的资源状况下，各个组织之间在当时达成一个高效率的单干沟通计划。
低优资源配额从哪里来？
apiVersion: v1
kind: Pod
metadata:
annotations:
alibabacloud.com/qosClass: 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
再回到明天想探讨的话题，云原生混部的资源配额，和 K8s 社区原生的资源配额有什么区别？从下面的 yaml 配置能够看到，低优资源咱们应用了社区的扩大资源来进行治理，所以，很牵强附会的就是对低优 CPU 和低优内存做一个配额总量的管制，并且这些总量会在不同部门之间进行当时的估算调配，这些逻辑和社区的资源配额逻辑是一样的，在这里就不赘述了，大家能够看社区的官网文档：《资源配额》
然而低优资源还有一些逻辑是和社区资源配额是不一样的，并且，因为 CPU 和内存这 2 种资源天生的个性不同，所以还有区别，接下来用一张表来展示这个概念。
能够看到，因为 CPU 是可压缩资源，咱们引入了低优 CPU 超卖比这个参数，在原有集群 100C 的根底上，能够另外超卖出 60C 的资源，给所有的低优工作应用。而对于内存这种不可压缩资源而言，总体 100G，依照低优内存调配比这个参数，划分了 40G 之后，剩下给高中优的用量就只剩 60G 了。因为在混部集群的治理中，由此失去的一个论断就是，要给集群的机器配置更多的内存，这样才有足够的数量不影响在线业务应用。
注：可压缩资源 (例如 CPU 循环，disk I/O 带宽) 都是速率性的能够被回收的，对于一个 task 能够升高这些资源的量而不去杀掉 task；和不可压缩资源 (例如内存、硬盘空间) 这些一般来说不杀掉 task 就没法回收的。
《在 Google 应用 Borg 进行大规模集群的治理 5-6》- 6.2 性能隔离
这里顺便卖个关子，具体这个配比多少是适合的，包含这几个参数到底设置多少是正当的，在阿里云的商用产品 ACK 麻利版混部外面会有具体内容输入。
基于容量的弹性配额调度
云原生混部在配额方面，和社区的第二个区别在哪里呢？能够看到的是，引入混部后会引入大量的离线运算工作，和比拟有法则的在线业务相比，离线工作像洪水一样是一波一波的，在整个工夫区间内更不法则。有可能 A 团队在跑大数据计算，把本人的低优配额都跑完了，然而 B 团队的大数据计算这个时候还没跑，还有闲暇的配额。
那么，是否能够把这部分的配额利用起来，先“借”给 A 部门应用呢？这里就能够引入另外一个能力，基于容量的配额调度。
反对定义不同层级的资源配额。如上图所示，您能够依据具体情况（比方：公司的组织构造）配置多个层级的弹性配额。弹性配额组的叶子节点能够对应多个 Namespace，但同一个 Namespace 只能归属于一个叶子节点。
- 反对不同弹性配额之间的资源借用和回收。
- Min：您能够应用的保障资源（Guaranteed Resource）。当整个集群资源缓和时，所有用户应用的 Min 总和须要小于集群的总资源量。
- Max：您能够应用的资源下限。
引入了这个弹性配额调度后，咱们发现组织中多个团队在应用低优资源时的“弹性”更强了，当 B 团队有闲暇的配额时，能够动静的“借”给 A 团队应用，反之亦然。这样集群在全时间段外面的利用率进一步晋升，更充沛和无效的利用了集群的资源。
相干解决方案介绍
进入了 2022 年，混部在阿里外部曾经成为了一个十分成熟的技术，为阿里每年节俭数十亿的老本，是阿里数据中心的根本能力。而阿里云也把这些成熟的技术通过两年的工夫，积淀成为混部产品，开始服务于各行各业。
在阿里云的产品族外面，咱们会把混部的能力通过 ACK 麻利版，以及 CNStack（CloudNative Stack）产品家族，对外进行透出，并联合龙蜥操作系统（OpenAnolis），造成残缺的云原生数据中心混部的一体化解决方案，输入给咱们的客户。
预报：对于混部水位线，也就是保障可靠性的最初一道防线，咱们会在后一篇文章外面进行介绍。
参考链接
1、《资源配额》：
https://kubernetes.io/zh/docs…
2、《在 Google 应用 Borg 进行大规模集群的治理 5-6》：
https://my.oschina.net/HardyS…
3、《Capacity Scheduling》：
https://help.aliyun.com/docum…
4、龙蜥操作系统 https://openanolis.cn/
原文链接
本文为阿里云原创内容，未经容许不得转载。
