01 引言

在阿里集團(tuán)，離線混部技術(shù)從 2014 年開(kāi)始，經(jīng)歷了七年的雙十一檢驗(yàn)，內(nèi)部已實(shí)現(xiàn)大規(guī)模落地推廣，每年為阿里集團(tuán)節(jié)省數(shù)十億的資源成本，整體資源利用率為 70%左右，達(dá)到業(yè)界領(lǐng)先水平。這兩年，我們開(kāi)始把集團(tuán)內(nèi)的混部技術(shù)通過(guò)產(chǎn)品化的方式輸出給業(yè)界，通過(guò)插件化的方式無(wú)縫安裝在標(biāo)準(zhǔn)原生的 K8s 集群上，配合混部管控和運(yùn)維能力，提升集群的資源利用率和產(chǎn)品的綜合用戶體驗(yàn)。

由于混部是一個(gè)復(fù)雜的技術(shù)及運(yùn)維體系，包括 K8s 調(diào)度、OS 隔離、可觀測(cè)性等等各種技術(shù)，之前的一篇文章《 歷經(jīng) 7 年雙 11 實(shí)戰(zhàn)，阿里巴巴是如何定義云原生混部調(diào)度優(yōu)先級(jí)及服務(wù)質(zhì)量的？ 》，主要聚焦在調(diào)度優(yōu)先級(jí)和服務(wù)質(zhì)量模型上，今天我們來(lái)關(guān)注一下資源配額多租相關(guān)的內(nèi)容。

02 資源配額概述

首先想提一個(gè)問(wèn)題，在設(shè)計(jì)上，既然 K8s 的調(diào)度器已經(jīng)可以在沒(méi)有資源的情況下，讓 pod 處于 pending 狀態(tài)，那為什么，還需要有一個(gè)資源配額（Resource Quota）的設(shè)計(jì)？

我們?cè)趯W(xué)習(xí)一個(gè)系統(tǒng)時(shí)，不但要學(xué)習(xí)設(shè)計(jì)本身，還需要考慮為什么這個(gè)設(shè)計(jì)是必須的？如果把這個(gè)設(shè)計(jì)從系統(tǒng)中砍掉，會(huì)造成什么后果？因?yàn)樵谝粋€(gè)系統(tǒng)中增加任何一項(xiàng)功能設(shè)計(jì)，都會(huì)造成好幾項(xiàng)邊際效應(yīng)（Side Effect），包括使用這個(gè)系統(tǒng)的人的心智負(fù)擔(dān)，系統(tǒng)的安全性、高可用性，性能，都需要納入考慮。所以，功能不是越多越好。越是優(yōu)秀的系統(tǒng)，提供的功能反而是越少越好。例如 C 語(yǔ)言只有 32 個(gè)關(guān)鍵字，而用戶可以通過(guò)自定義組合這些基礎(chǔ)能力，實(shí)現(xiàn)自己想要的任何需求。

回到原問(wèn)題，一個(gè)集群的資源一定是有限的，無(wú)論是物理機(jī)上的 CPU、內(nèi)存、磁盤，還有一些別的資源例如 GPU 卡這些。光靠調(diào)度，是否能解決這個(gè)問(wèn)題呢？如果這個(gè)集群只有一個(gè)用戶，那么這個(gè)問(wèn)題其實(shí)還是能忍受的，例如看到 pod pending了，那就不創(chuàng)建新的 pod 了；如果新的 pod 比較重要，這個(gè)用戶可以刪掉舊的 pod，然后再創(chuàng)建新的。但是，真實(shí)的集群是被多個(gè)用戶或者說(shuō)團(tuán)隊(duì)同時(shí)使用的，當(dāng) A 團(tuán)隊(duì)資源不夠了，再去等 B 團(tuán)隊(duì)的人決策什么應(yīng)用可以騰挪出空間，在這個(gè)時(shí)候，跨團(tuán)隊(duì)的交流效率是非常低下的。所以在調(diào)度前，我們就需要再增加一個(gè)環(huán)節(jié)。如下圖所示：

在這個(gè)環(huán)節(jié)內(nèi)，引入了資源配額和租戶這 2 個(gè)概念。租戶，是進(jìn)行資源配額調(diào)配的團(tuán)隊(duì)單位。配額，則是多個(gè)租戶在使用有限的集群資源時(shí)，互相在事先達(dá)成的一個(gè)共識(shí)。事先是一個(gè)非常重要的關(guān)鍵詞，也就是說(shuō)不能等到 pod 到了調(diào)度時(shí)、運(yùn)行時(shí)，再去告訴創(chuàng)建者這個(gè) pod 因?yàn)榕漕~不足而創(chuàng)建不出來(lái)，而是需要在創(chuàng)建 pod 之前，就給各個(gè)團(tuán)隊(duì)一個(gè)對(duì)資源的心理預(yù)期，每年初在配置資源配額時(shí)，給 A 團(tuán)隊(duì)或者 B 團(tuán)隊(duì)定一個(gè)今年可以使用的配額總量，這樣當(dāng) A 團(tuán)隊(duì)配額用完時(shí)，A 團(tuán)隊(duì)內(nèi)部可以先進(jìn)行資源優(yōu)先級(jí)排序，把不重要的 pod 刪除掉，如果還不夠，那就再和 B 團(tuán)隊(duì)商量，是否可以從 B 團(tuán)隊(duì)的配額劃分一些配額過(guò)來(lái)。這樣的話，就無(wú)需任何情況下都要進(jìn)行點(diǎn)對(duì)點(diǎn)的低效率溝通。A 團(tuán)隊(duì)和 B 團(tuán)隊(duì)在年初的時(shí)候就需要對(duì)自己的業(yè)務(wù)的資源用量，做一個(gè)大概的估算，也就是資源預(yù)算。

所以從這個(gè)角度來(lái)說(shuō)，資源配額，是多個(gè)租戶之間低頻高效率溝通合作的一種方式。如果把配額這個(gè)概念放到經(jīng)濟(jì)學(xué)中，是不是就有點(diǎn)計(jì)劃經(jīng)濟(jì)的感覺(jué)了呢？其實(shí)里面的核心思想是一致的，都是在有限的資源情況下，各個(gè)組織之間在事先達(dá)成一個(gè)高效率的合作溝通方案。

03 低優(yōu)資源配額從哪里來(lái)？

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  # 單位 字節(jié)，和普通內(nèi)存一樣。單位可以為 Gi Mi Ki GB MB KB
      requests:
        alibabacloud.com/reclaimed-cpu: 1000
        alibabacloud.com/reclaimed-memory: 2048

再回到今天想討論的話題，云原生混部的資源配額，和 K8s 社區(qū)原生的資源配額有什么區(qū)別？從上面的 yaml 配置可以看到，低優(yōu)資源我們使用了社區(qū)的擴(kuò)展資源來(lái)進(jìn)行管理，所以，很順理成章的就是對(duì)低優(yōu) CPU 和低優(yōu)內(nèi)存做一個(gè)配額總量的控制，并且這些總量會(huì)在不同部門之間進(jìn)行事先的預(yù)算分配，這些邏輯和社區(qū)的資源配額邏輯是一樣的，在這里就不贅述了，大家可以看社區(qū)的官方文檔：《資源配額》

但是低優(yōu)資源還有一些邏輯是和社區(qū)資源配額是不一樣的，并且，由于 CPU 和內(nèi)存這 2 種資源天生的特性不同，所以還有區(qū)別，接下來(lái)用一張表來(lái)展現(xiàn)這個(gè)概念。

可以看到，由于 CPU 是可壓縮資源，我們引入了 低優(yōu) CPU 超賣比 這個(gè)參數(shù)，在原有集群 100C 的基礎(chǔ)上，可以另外超賣出 60C 的資源，給所有的低優(yōu)任務(wù)使用。而對(duì)于內(nèi)存這種不可壓縮資源而言，總體 100G，按照 低優(yōu)內(nèi)存分配比 這個(gè)參數(shù)，劃分了 40G 之后，剩下給高中優(yōu)的用量就只剩 60G 了。因?yàn)樵诨觳考旱墓芾碇校纱说玫降囊粋€(gè)結(jié)論就是，要給集群的機(jī)器配置更多的內(nèi)存，這樣才有足夠的數(shù)量不影響在線業(yè)務(wù)使用。

注：可壓縮資源(例如 CPU 循環(huán)，disk I/O 帶寬)都是速率性的可以被回收的，對(duì)于一個(gè) task 可以降低這些資源的量而不去殺掉 task；和不可壓縮資源(例如內(nèi)存、硬盤空間)這些一般來(lái)說(shuō)不殺掉 task 就沒(méi)法回收的。

《在 Google 使用 Borg 進(jìn)行大規(guī)模集群的管理 5-6》- 6.2 性能隔離

這里順便賣個(gè)關(guān)子，具體這個(gè)配比多少是合適的，包括這幾個(gè)參數(shù)到底設(shè)置多少是合理的，在阿里云的商用產(chǎn)品 ACK 敏捷版混部里面會(huì)有具體內(nèi)容輸出。

04 基于容量的彈性配額調(diào)度

云原生混部在配額方面，和社區(qū)的第二個(gè)區(qū)別在哪里呢？可以看到的是，引入混部后會(huì)引入大量的離線運(yùn)算任務(wù)，和比較有規(guī)律的在線業(yè)務(wù)相比，離線任務(wù)像洪水一樣是一波一波的，在整個(gè)時(shí)間區(qū)間內(nèi)更不規(guī)律。有可能 A 團(tuán)隊(duì)在跑大數(shù)據(jù)計(jì)算，把自己的低優(yōu)配額都跑完了，但是 B 團(tuán)隊(duì)的大數(shù)據(jù)計(jì)算這個(gè)時(shí)候還沒(méi)跑，還有空閑的配額。

那么，是否可以把這部分的配額利用起來(lái)，先“借”給 A 部門使用呢？這里就可以引入另外一個(gè)能力，基于容量的配額調(diào)度。

1. 支持定義不同層級(jí)的資源配額。如上圖所示，您可以根據(jù)具體情況（比如：公司的組織結(jié)構(gòu)）配置多個(gè)層級(jí)的彈性配額。彈性配額組的葉子節(jié)點(diǎn)可以對(duì)應(yīng)多個(gè) Namespace，但同一個(gè) Namespace 只能歸屬于一個(gè)葉子節(jié)點(diǎn)。
2. 支持不同彈性配額之間的資源借用和回收。

• Min：您可以使用的保障資源（Guaranteed Resource）。當(dāng)整個(gè)集群資源緊張時(shí)，所有用戶使用的 Min 總和需要小于集群的總資源量。
• Max：您可以使用的資源上限。

引入了這個(gè)彈性配額調(diào)度后，我們發(fā)現(xiàn)組織中多個(gè)團(tuán)隊(duì)在使用低優(yōu)資源時(shí)的“彈性”更強(qiáng)了，當(dāng) B 團(tuán)隊(duì)有空閑的配額時(shí)，可以動(dòng)態(tài)的“借”給 A 團(tuán)隊(duì)使用，反之亦然。這樣集群在全時(shí)間段里面的利用率進(jìn)一步提升，更充分和有效的利用了集群的資源。

05 相關(guān)解決方案介紹

進(jìn)入了 2022 年，混部在阿里內(nèi)部已經(jīng)成為了一個(gè)非常成熟的技術(shù)，為阿里每年節(jié)省數(shù)十億的成本，是阿里數(shù)據(jù)中心的基本能力。而阿里云也把這些成熟的技術(shù)經(jīng)過(guò)兩年的時(shí)間，沉淀成為混部產(chǎn)品，開(kāi)始服務(wù)于各行各業(yè)。

在阿里云的產(chǎn)品族里面，我們會(huì)把混部的能力通過(guò) ACK 敏捷版 ， 以及 CNStack（CloudNative Stack）產(chǎn)品家族 ，對(duì)外進(jìn)行透出，并結(jié)合龍蜥操作系統(tǒng)（OpenAnolis），形成完整的 云原生數(shù)據(jù)中心混 部的 一體化解決方案 ，輸出給我們的客戶。