天天看點

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

作者:南異

引言

阿裡巴巴在離線混部技術從 2014 年開始,經曆了七年的雙十一檢驗,内部已經大規模落地推廣,每年為阿裡集團節省數十億的資源成本,整體資源使用率達到 70% 左右,達到業界領先。這兩年,我們開始把集團内的混部技術通過産品化的方式輸出給業界,通過插件化的方式無縫安裝在标準原生的 K8s 叢集上,配合混部管控和運維能力,提升叢集的資源使用率和産品的綜合使用者體驗。

由于混部是一個複雜的技術及運維體系,包括 K8s 排程、OS 隔離、可觀測性等等各種技術,本文将聚焦在 K8s 層的容器優先級和服務品質模型上,希望給業界提供一些可借鑒的思路。

K8s 原生模型

在實際的生産實踐中,即使是很多對雲原生和 K8s 比較熟悉的技術人員,往往也會混淆排程優先級(Priority)和服務品質(QoS)。

是以,在談混部的模型前,首先我們對 K8s 原生的概念做詳細的介紹,詳見下表:

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

從 API 層面較長的描述的話,可以看下面這張表

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

混部需要解決的問題

混部主要解決的問題是,在保證部署應用的服務等級目标 SLO 的前提下,充分利用叢集中的空閑資源,來提升叢集整體的使用率。

當一個叢集被線上服務部署配置設定部署完以後,由于線上應用的高保障的特性,會給容器一個 peak 的資源規格,這樣有可能導緻實際真實使用率很低。

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

我們希望将這部分空閑但是未使用的資源超賣出來提供給低 SLO 的離線作業使用,以此提高整體機器水位。這樣就需要提供基于 SLO 的排程能力,以及考慮到機器真實資源水位進行排程,避免熱點的産生。

另外,由于線上通常 SLO 比較高,離線 SLO 比較低,那麼當機器水位整體提升過高的時候,可以通過搶占離線的作業方式,來保障線上應用的 SLO。以及需要使用率核心層面 cgroup 的隔離特性來保障高 SLO 和低 SLO 作業。

那麼,在這些線上和離線的 Pod 之間,我們就需要用不同的排程優先級和服務品質等級,以滿足線上和離線的實際運作需求。

雲原生混部定義的應用等級模型

首先請看一下在混部中一個 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  # 機關 位元組,和普通記憶體一樣。機關可以為 Gi Mi Ki GB MB KB
      requests:
        alibabacloud.com/reclaimed-cpu: 1000
        alibabacloud.com/reclaimed-memory: 2048      

這是在混部裡面我們引入的 Pod 的等級,和社群原生不同的地方在于,我們顯式的在 anotation 和 label 裡面申明了 3 種等級:LSR、LS、BE。這 3 種等級會同時和排程優先級(Priority)、服務品質(Qos)産生關聯。

具體的每個容器的資源用量,LSR 和 LS 還是沿用原有的 cpu/memory 的配置方式,BE 類任務比較特殊,通過社群标準的 extended-resource 模式來申明資源。

那麼,這 3 類等級具體代表的運作時含義又是什麼呢?可以參考這個圖,看下這三類應用在 CPU 上的運作時的情況

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

以及詳細的對其他資源使用的影響:

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

可以看到,這個等級,不但和 Pod 在單機上運作的 CPU、記憶體有關,還和網絡 Qos 的全鍊路優先級有關,避免低優的離線類任務搶占了所有的網絡帶寬。阿裡在核心方面做的工作有效的保證了運作時的應用穩定性,2021 年雙 11 期間,阿裡成為全球首家将所有業務都放在自家公共雲上的大型科技公司,這意味着阿裡雲有能力應對高難度複雜環境下的技術挑戰,也帶來了非常大的技術收益:阿裡巴巴業務的研發效率提升了 20%、CPU 資源使用率提升 30%、應用 100% 雲原生化、線上業務容器可達百萬規模,同時計算效率大幅提升,雙 11 整體計算成本三年下降 30%。在這個過程中,混合部署技術發揮了重要作用。核心團隊及雲原生團隊工程師踩了無數的坑,沉澱了包括彈性 CPU 帶寬、Group Identity、SMT expeller、memcg 異步回收、記憶體水線分級、memcg OOM 等多項進階特性,處于業界領先水準。這些工作都會在系列的文章裡面後續一一介紹。

當這三種類型優先級任務實際在排程和運作時發生的行為,如下面這個表所示

曆經 7 年雙 11 實戰,阿裡巴巴是如何定義雲原生混部排程優先級及服務品質的?

也就是說,混部的優先級會同時作用于排程和運作時,最大程度的保證高 SLO 的高優、中優任務使用叢集内的資源。

配額、水位線、多租隔離

本文僅聚焦讨論了 K8s 單 Pod 的排程優先級,在實際使用時,為了保證應用的 SLO,需要配合單機的水位線、租戶的配額、以及 OS 隔離能力等等使用,我們會在後續文章裡面詳細探讨。

相關解決方案介紹

進入了 2021 年,混部在阿裡内部已經成為了一個非常成熟的技術,為阿裡每年節省數十億的成本,是阿裡資料中心的基本能力。而阿裡雲也把這些成熟的技術經過兩年的時間,沉澱成為混部産品,開始服務于各行各業。

在阿裡雲的産品族裡面,我們會把混部的能力通過 ACK 靈活版,以及 CNStack(CloudNative Stack)産品家族,對外進行透出,并結合龍蜥作業系統(OpenAnolis),形成完整的雲原生資料中心混部的一體化解決方案,輸出給我們的客戶。

參考文檔

1)

https://kubernetes.io/docs/concepts/scheduling-eviction/

2)

https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

3)

https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

4)

https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

5)

https://kubernetes.io/docs/tasks/configure-pod-container/extended-resource/

6)

https://my.oschina.net/HardySimpson/blog/1359276

文内詳情連結

1)節點壓力驅逐(Node-pressure Eviction):

2)PriorityClass:

https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass

3)PodDisruptionBudget:

https://kubernetes.io/docs/tasks/run-application/configure-pdb/

4)Eviction:

https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/

5)QosClass:

https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

6)PriorityClass:

7)PodDisruptionBudget:

8)Eviction:

點選

此處

,即可檢視阿裡雲專有雲靈活版雲原生 Stack 相關介紹!