*作者：南異*

## 引言

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

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

## K8s 原生模型

在實際的生產實踐中，即使是很多對雲原生和 K8s 比較熟悉的技術人員，往往也會混淆排程優先順序（Priority）和服務質量（QoS）。

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

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1a0c25c63064b489c29e89bb3e43d62~tplv-k3u1fbpfcp-zoom-1.image "1.png")

從 API 層面詳細描述的話，可以看下面這張表

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d7d17ba697949ecaa0a28f22f391299~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## 混部需要解決的問題

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

當一個叢集被線上服務部署分配部署完以後，由於線上應用的高保障的特性，會給容器一個 peak 的資源規格，這樣有可能導致實際真實利用率很低。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c07f52f7a77f44bb8c2d7b311be485df~tplv-k3u1fbpfcp-zoom-1.image "3.png")

我們希望將這部分空閒但是未使用的資源超賣出來提供給低 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 上的執行時的情況

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04f8e9a99294423fa13c78ba051a203e~tplv-k3u1fbpfcp-zoom-1.image "4.png")

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

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/28460b4bdf1d4050bd35c44b72d99fc0~tplv-k3u1fbpfcp-zoom-1.image "5.png")

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

當這三種型別優先順序任務實際在排程和執行時發生的行為，如下面這個表所示

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9762dad0fe894303b9410e3a1194c156~tplv-k3u1fbpfcp-zoom-1.image "6.png")

也就是說，混部的優先順序會同時作用於排程和執行時，最大程度的保證高 SLO 的高優、中優任務使用叢集內的資源。

## 配額、水位線、多租隔離

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

## 相關解決方案介紹

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

在阿里雲的產品族裡面，我們會把混部的能力透過 ACK 敏捷版，以及 CNStack（CloudNative Stack）產品家族，對外進行透出，並結合龍蜥作業系統（OpenAnolis），形成完整的雲原生資料中心混部的一體化解決方案，輸出給我們的客戶。

## 參考文件

*1）* *<https:></https:>*

*2）* *<https:></https:>*

*3）* *<https:></https:>*

*4）* *<https:></https:>*

*5）* *<https:></https:>*

*6）* *<https:>*

## 文內詳情連結

1）節點壓力驅逐(Node-pressure Eviction)：
*<https:></https:>*

2）PriorityClass：
*<https:>*

3）PodDisruptionBudget：
*<https:></https:>*

4）Eviction：
*<https:></https:>*

5）QosClass：
*<https:></https:>*

6）PriorityClass：
*<https:>*

7）PodDisruptionBudget：

*<https:></https:>*

8）Eviction：
*<https:></https:>*

點選[**此處**](https://www.aliyun.com/activity/middleware/cnstack)，即可檢視阿里雲專有云敏捷版雲原生 Stack 相關介紹！</https:></https:></https:>

歷經 7 年雙 11 實戰，阿里巴巴是如何定義雲原生混部排程優先順序及服務質量的？

相關文章