如何在云原生混部場景下利用資源配額高效分配集群資源？

精選
作者：南異 2022-04-21 10:38:34
云計算
云原生
新聞 進入了 2022 年，混部在阿里內(nèi)部已經(jīng)成為了一個非常成熟的技術(shù)，為阿里每年節(jié)省數(shù)十億的成本，是阿里數(shù)據(jù)中心的基本能力。

01 引言

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

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

02 資源配額概述

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

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

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

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

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

K8s	經(jīng)濟學(xué)	公司財務(wù)	抽象概念相同處
配額	計劃經(jīng)濟	預(yù)算	事先的，低頻的，少數(shù)大的組織之間進行溝通
調(diào)度優(yōu)先級	市場經(jīng)濟	執(zhí)行	事中的，高頻的，大量小的個體之間進行溝通
服務(wù)質(zhì)量	決算	事后統(tǒng)計的，實際發(fā)生的值

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

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ū)的擴展資源來進行管理，所以，很順理成章的就是對低優(yōu) CPU 和低優(yōu)內(nèi)存做一個配額總量的控制，并且這些總量會在不同部門之間進行事先的預(yù)算分配，這些邏輯和社區(qū)的資源配額邏輯是一樣的，在這里就不贅述了，大家可以看社區(qū)的官方文檔：《資源配額》

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

	CPU	內(nèi)存
集群機器的所有資源總量	100C	100G
混部參數(shù)	低優(yōu) CPU 超賣比：60%	低優(yōu)內(nèi)存分配比：40%
K8s 原生資源配額總量（對應(yīng)于混部的高、中優(yōu)總配額）	100C	60G
混部低優(yōu)配額總量	60C	40G

可以看到，由于 CPU 是可壓縮資源，我們引入了 低優(yōu) CPU 超賣比 這個參數(shù)，在原有集群 100C 的基礎(chǔ)上，可以另外超賣出 60C 的資源，給所有的低優(yōu)任務(wù)使用。而對于內(nèi)存這種不可壓縮資源而言，總體 100G，按照 低優(yōu)內(nèi)存分配比 這個參數(shù)，劃分了 40G 之后，剩下給高中優(yōu)的用量就只剩 60G 了。因為在混部集群的管理中，由此得到的一個結(jié)論就是，要給集群的機器配置更多的內(nèi)存，這樣才有足夠的數(shù)量不影響在線業(yè)務(wù)使用。

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)前題目：如何在云原生混部場景下利用資源配額高效分配集群資源？
標(biāo)題來源：http://www.5511xx.com/article/dpjochj.html