?1.?引言

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

由于混部是一個復(fù)雜的技術(shù)及運維體系，包括 K8s 調(diào)度、OS 隔離、可觀測性等等各種技術(shù)，之前的 2 篇文章：歷經(jīng) 7 年雙 11 實戰(zhàn)，阿里巴巴是如何定義云原生混部調(diào)度優(yōu)先級及服務(wù)質(zhì)量的？如何在云原生混部場景下利用資源配額高效分配集群資源？今天我們要關(guān)注的是混部在單機(jī)運行時的最后一道防線——單機(jī)水位線設(shè)計。

2.?為什么需要單機(jī)水位線

如上圖所示，Pod 的運行時的三個生命周期階段，在經(jīng)過配額檢查和調(diào)度后，終于，不同 Qos 等級的 Pod 運行在同一個節(jié)點上了，這個時候，高優(yōu)和中優(yōu)的 Pod 使用的是節(jié)點上的容器分配總量，而低優(yōu) Pod，則是基于高中優(yōu)實際的資源用量，然后被調(diào)度器調(diào)度到節(jié)點上面去運行。從下圖可以看到，當(dāng)一個節(jié)點上還有較多的空余資源時，完全可以提供給低優(yōu)資源使用，而當(dāng)高/中優(yōu) Pod 實際資源用量高過一定的值之后，資源競爭非常激烈時，節(jié)點上再跑低優(yōu) Pod 只會導(dǎo)致高/中優(yōu) Pod 的服務(wù)質(zhì)量受損，所以這個時候，我們將不再允許低優(yōu) Pod 在這個節(jié)點上運行。為了標(biāo)識或者說判斷節(jié)點資源的競爭激烈程度，那么非常順理成章的一個設(shè)計就是，看這個節(jié)點上的資源使用率是否過高。如果超過一定使用率，那么我們就需要對低優(yōu) Pod 做相應(yīng)的操作。這個判斷的臨界閾值，就是單機(jī)的水位線。

這里另外能看到的一點是，水位線僅僅是為低優(yōu) Pod 所設(shè)置的，高/中優(yōu) Pod 并不會感知到水位線，他們可以自由地使用整機(jī)的所有資源，所有的系統(tǒng)行為都和沒有打開混部是一樣的。

3?.水位線的分級

對于一個資源趨向于飽和的節(jié)點來說，我們對于低優(yōu) Pod 可以有各種操作的手段，如果僅僅是簡單的殺掉低優(yōu) Pod 的話，整個混部系統(tǒng)也可以工作，這個動作我們稱為“驅(qū)逐”。但如果在一定時間后，機(jī)器上的資源競爭又降低的話，那么低優(yōu) Pod 被殺死并在別的機(jī)器上重新啟動，這里會大大延長低優(yōu) Pod 的單個任務(wù)的執(zhí)行時間，所以在設(shè)計單機(jī)水位線時，需要盡可能的讓低優(yōu) Pod 也要在可以允許的時間范圍內(nèi)能夠“降級”運行。所以，我們有對低優(yōu) Pod 的第 2 種操作，就是降低對它的 CPU 供給量，這個操作我們稱為“壓制”。同時，如果一個節(jié)點上的資源趨于飽和，另外還比較順理成章的系統(tǒng)行為就是不讓新的低優(yōu) Pod 被調(diào)度進(jìn)來。

于是我們對于節(jié)點上低優(yōu) Pod 的行為就有 3 種：壓制、驅(qū)逐和禁止調(diào)度，由此就有三條水位線，同時，對于 CPU 這類的可壓縮資源和內(nèi)存這類不可壓縮資源，行為還有區(qū)別。

注：可壓縮資源(例如 CPU 循環(huán)，disk I/O 帶寬)都是速率性的可以被回收的，對于一個 task 可以降低這些資源的量而不去殺掉 task；和不可壓縮資源(例如內(nèi)存、硬盤空間)這些一般來說不殺掉 task 就沒法回收的。來自文章《在 Google 使用 Borg 進(jìn)行大規(guī)模集群的管理 5-6》- 6.2 性能隔離[1]

這些水位線總體列表如下：

這些水位線的合理配置值，應(yīng)該是 驅(qū)逐>壓制>禁止調(diào)度。不過在實際的混部生產(chǎn)中，我們一般會把禁止調(diào)度水位線和壓制水位線使用同一個配置值，來降低系統(tǒng)運維同學(xué)的理解成本，以及配置工作量。這樣合并后就會存在 CPU 的 2 條水位線，內(nèi)存的一條水位線。

4?.驅(qū)逐條件：基于滿足度的驅(qū)逐模式

這張圖展示了單機(jī)上實際的系統(tǒng)運行例子：

• 在 t1 時間，總資源利用率達(dá)到壓制水位線的時候，對低優(yōu)先級的任務(wù)進(jìn)行壓制，保證整體資源利用率在壓制水位線之下，此時低優(yōu)任務(wù)不會再被調(diào)度進(jìn)來
• 在 t3 時間，總資源利用率開始進(jìn)一步上升，達(dá)到驅(qū)逐水位線時，會對低優(yōu)任務(wù)進(jìn)行刪除和驅(qū)逐的處理，保證高/中優(yōu)的資源使用

一個容易考慮到的設(shè)計是，驅(qū)逐低優(yōu)任務(wù)前去設(shè)定一個延遲時間，這樣可以讓低優(yōu) Pod 有更多的機(jī)會等到系統(tǒng)有足夠的資源，繼續(xù)運行，然而這個設(shè)計，會造成幾個問題：

• 內(nèi)存的驅(qū)逐必須是實時的，因為節(jié)點上內(nèi)存不足，會導(dǎo)致高/中優(yōu)任務(wù)內(nèi)存不足而 OOM
• 這個延遲時間并不好配置，配的短了沒有效果，配了長了反而會引起低優(yōu) Pod 長期“饑餓”而造成低優(yōu) Pod 運行時間更長
• 如果在一個節(jié)點上，有多個低優(yōu) Pod 都在運行，是否要驅(qū)逐所有的低優(yōu) Pod？是否可能盡量的少驅(qū)逐 Pod？

因此，我們發(fā)明了基于滿足度的低優(yōu) Pod 的 CPU 資源驅(qū)逐方式，定義了以下幾個概念：

• 窗口期：獲取 CPU 利用率的時間窗口（例如 5 分鐘），在窗口時間的平均 CPU 利用率超過驅(qū)逐水位線，則開始驅(qū)逐，可以避免抖動
• 低優(yōu) Pod 資源滿足率：= 低優(yōu) Pod 實際資源使用量/低優(yōu) Pod Request 資源量
• 低優(yōu) Pod 滿足率下限：一個百分比值，低于這個值的認(rèn)為低優(yōu) Pod 的資源供給不足

這樣，低優(yōu) Pod 的驅(qū)逐條件就變?yōu)榱耍?/p>

• 窗口期內(nèi)：平均低優(yōu) Pod 資源滿足率 < 低優(yōu) Pod 滿足率下限
• 窗口期內(nèi)：低優(yōu) Pod 平均 CPU 利用率接近 100%（如 90% 或者 80%）
• 當(dāng)前時間：平均低優(yōu) Pod 資源滿足率 < 低優(yōu) Pod 滿足率下限
• 最近時間：BE CPU  利用率接近100%（如 90% 或者 80%）

而驅(qū)逐低優(yōu) Pod 的排序為：

• 優(yōu)先驅(qū)逐調(diào)度優(yōu)先級 Priority 低的 Pod（是的，即使是低優(yōu) Pod，我們還是可以按照數(shù)值來細(xì)分不同的調(diào)度優(yōu)先級）
• 如果 2 個 Pod 調(diào)度優(yōu)先級一致，則計算驅(qū)逐哪一個 Pod 帶來的資源釋放更多，優(yōu)先驅(qū)逐能釋放更多資源的

內(nèi)存的驅(qū)逐方式和 CPU 基本類似，但沒有滿足率，到了驅(qū)逐水位線按照優(yōu)先級和內(nèi)存大小來進(jìn)行驅(qū)逐。

注：低優(yōu) Pod 的在別的節(jié)點上重建，還是依賴于低優(yōu) Pod 的管控系統(tǒng)（例如，離線計算的框架 Spark/Flink 等），這個重建過程往往涉及到臨時緩存的文件或者數(shù)據(jù)的遷移和一致性的校驗，這個重建操作并不適合在 K8s 層主動的去做操作，而是交給上層管控系統(tǒng)或者 operator 更加合適。

5.?展望：是否有更好的設(shè)計？

在本文的開始，提到了衡量系統(tǒng)資源的競爭激烈程度，最簡單和直觀的就是看資源利用率。當(dāng)然，在實際的大規(guī)模集群運行過程中，我們也看到了資源利用率高和資源競爭激烈并不是完全的一一對應(yīng)關(guān)系，甚至有些應(yīng)用在 CPU 利用率非常高的情況下，依然穩(wěn)定運行，而另外一些應(yīng)用，在一個低的 CPU 利用情況下，就會非常的“卡”。這就意味著如果我們有新的、更好的指標(biāo)來衡量系統(tǒng)的利用率，那么我們對相應(yīng)的 Workload 就能有更“微操”的操作，在保證應(yīng)用 SLO 的同時，提升集群的資源利用率。

6?.相關(guān)解決方案介紹

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

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

參考文檔：

[1]《在Google使用Borg進(jìn)行大規(guī)模集群的管理 5-6》：https://my.oschina.net/HardySimpson/blog/517283?