歷經(jīng) 7 年雙 11 實戰(zhàn),阿里巴巴是如何定義云原生混部調(diào)度優(yōu)先級及服務(wù)質(zhì)量的?
阿里巴巴在離線混部技術(shù)從 2014 年開始,經(jīng)歷了七年的雙十一檢驗,內(nèi)部已經(jīng)大規(guī)模落地推廣,每年為阿里集團節(jié)省數(shù)十億的資源成本,整體資源利用率達(dá)到 70% 左右,達(dá)到業(yè)界領(lǐng)先。這兩年,我們開始把集團內(nèi)的混部技術(shù)通過產(chǎn)品化的方式輸出給業(yè)界,通過插件化的方式無縫安裝在標(biāo)準(zhǔn)原生的 K8s 集群上,配合混部管控和運維能力,提升集群的資源利用率和產(chǎn)品的綜合用戶體驗。
由于混部是一個復(fù)雜的技術(shù)及運維體系,包括 K8s 調(diào)度、OS 隔離、可觀測性等等各種技術(shù),本文將聚焦在 K8s 層的容器優(yōu)先級和服務(wù)質(zhì)量模型上,希望給業(yè)界提供一些可借鑒的思路。
K8s 原生模型
在實際的生產(chǎn)實踐中,即使是很多對云原生和 K8s 比較熟悉的技術(shù)人員,往往也會混淆調(diào)度優(yōu)先級(Priority)和服務(wù)質(zhì)量(QoS)。
所以,在談混部的模型前,首先我們對 K8s 原生的概念做詳細(xì)的介紹,詳見下表:
從 API 層面詳細(xì)描述的話,可以看下面這張表
混部需要解決的問題
混部主要解決的問題是,在保證部署應(yīng)用的服務(wù)等級目標(biāo) SLO 的前提下,充分利用集群中的空閑資源,來提升集群整體的利用率。
當(dāng)一個集群被在線服務(wù)部署分配部署完以后,由于在線應(yīng)用的高保障的特性,會給容器一個 peak 的資源規(guī)格,這樣有可能導(dǎo)致實際真實利用率很低。
我們希望將這部分空閑但是未使用的資源超賣出來提供給低 SLO 的離線作業(yè)使用,以此提高整體機器水位。這樣就需要提供基于 SLO 的調(diào)度能力,以及考慮到機器真實資源水位進行調(diào)度,避免熱點的產(chǎn)生。
另外,由于在線通常 SLO 比較高,離線 SLO 比較低,那么當(dāng)機器水位整體提升過高的時候,可以通過搶占離線的作業(yè)方式,來保障在線應(yīng)用的 SLO。以及需要利用率內(nèi)核層面 cgroup 的隔離特性來保障高 SLO 和低 SLO 作業(yè)。
那么,在這些在線和離線的 Pod 之間,我們就需要用不同的調(diào)度優(yōu)先級和服務(wù)質(zhì)量等級,以滿足在線和離線的實際運行需求。
云原生混部定義的應(yīng)用等級模型
首先請看一下在混部中一個 Pod 的 yaml 是怎么定義的
apiVersion: v1 kind: Pod metadata: annotations: alibabacloud.com/qosClass: BE # {LSR,LS,BE} labels: alibabacloud.com/qos: 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
這是在混部里面我們引入的 Pod 的等級,和社區(qū)原生不同的地方在于,我們顯式的在 anotation 和 label 里面申明了 3 種等級:LSR、LS、BE。這 3 種等級會同時和調(diào)度優(yōu)先級(Priority)、服務(wù)質(zhì)量(Qos)產(chǎn)生關(guān)聯(lián)。
具體的每個容器的資源用量,LSR 和 LS 還是沿用原有的 cpu/memory 的配置方式,BE 類任務(wù)比較特殊,通過社區(qū)標(biāo)準(zhǔn)的 extended-resource 模式來申明資源。
那么,這 3 類等級具體代表的運行時含義又是什么呢?可以參考這個圖,看下這三類應(yīng)用在 CPU 上的運行時的情況
以及詳細(xì)的對其他資源使用的影響:
可以看到,這個等級,不但和 Pod 在單機上運行的 CPU、內(nèi)存有關(guān),還和網(wǎng)絡(luò) Qos 的全鏈路優(yōu)先級有關(guān),避免低優(yōu)的離線類任務(wù)搶占了所有的網(wǎng)絡(luò)帶寬。阿里在內(nèi)核方面做的工作有效的保證了運行時的應(yīng)用穩(wěn)定性,2021 年雙 11 期間,阿里成為全球首家將所有業(yè)務(wù)都放在自家公共云上的大型科技公司,這意味著阿里云有能力應(yīng)對高難度復(fù)雜環(huán)境下的技術(shù)挑戰(zhàn),也帶來了非常大的技術(shù)收益:阿里巴巴業(yè)務(wù)的研發(fā)效率提升了 20%、CPU 資源利用率提升 30%、應(yīng)用 100% 云原生化、在線業(yè)務(wù)容器可達(dá)百萬規(guī)模,同時計算效率大幅提升,雙 11 整體計算成本三年下降 30%。在這個過程中,混合部署技術(shù)發(fā)揮了重要作用。內(nèi)核團隊及云原生團隊工程師踩了無數(shù)的坑,沉淀了包括彈性 CPU 帶寬、Group Identity、SMT expeller、memcg 異步回收、內(nèi)存水線分級、memcg OOM 等多項高級特性,處于業(yè)界領(lǐng)先水平。這些工作都會在系列的文章里面后續(xù)一一介紹。
當(dāng)這三種類型優(yōu)先級任務(wù)實際在調(diào)度和運行時發(fā)生的行為,如下面這個表所示
也就是說,混部的優(yōu)先級會同時作用于調(diào)度和運行時,最大程度的保證高 SLO 的高優(yōu)、中優(yōu)任務(wù)使用集群內(nèi)的資源。
配額、水位線、多租隔離
本文僅聚焦討論了 K8s 單 Pod 的調(diào)度優(yōu)先級,在實際使用時,為了保證應(yīng)用的 SLO,需要配合單機的水位線、租戶的配額、以及 OS 隔離能力等等使用,我們會在后續(xù)文章里面詳細(xì)探討。
相關(guān)解決方案介紹
進入了 2021 年,混部在阿里內(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ù)中心混部的一體化解決方案,輸出給我們的客戶。