作者：南異

引言

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

由于混部是一個復雜的技術及運維體系，包括 K8s 調(diào)度、OS 隔離、可觀測性等等各種技術，本文將聚焦在 K8s 層的容器優(yōu)先級和服務質(zhì)量模型上，希望給業(yè)界提供一些可借鑒的思路。

K8s 原生模型

在實際的生產(chǎn)實踐中，即使是很多對云原生和 K8s 比較熟悉的技術人員，往往也會混淆調(diào)度優(yōu)先級（Priority）和服務質(zhì)量（QoS）。

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-HflPW1Yd-1638369891824)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f1a0c25c63064b489c29e89bb3e43d62~tplv-k3u1fbpfcp-zoom-1.image “1.png”)]

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-7XQrKJrL-1638369891829)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d7d17ba697949ecaa0a28f22f391299~tplv-k3u1fbpfcp-zoom-1.image “2.png”)]

混部需要解決的問題

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

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-XSu2OIAA-1638369891831)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c07f52f7a77f44bb8c2d7b311be485df~tplv-k3u1fbpfcp-zoom-1.image “3.png”)]

我們希望將這部分空閑但是未使用的資源超賣出來提供給低 SLO 的離線作業(yè)使用，以此提高整體機器水位。這樣就需要提供基于 SLO 的調(diào)度能力，以及考慮到機器真實資源水位進行調(diào)度，避免熱點的產(chǎn)生。

另外，由于在線通常 SLO 比較高，離線 SLO 比較低，那么當機器水位整體提升過高的時候，可以通過搶占離線的作業(yè)方式，來保障在線應用的 SLO。以及需要利用率內(nèi)核層面 cgroup 的隔離特性來保障高 SLO 和低 SLO 作業(yè)。

那么，在這些在線和離線的 Pod 之間，我們就需要用不同的調(diào)度優(yōu)先級和服務質(zhì)量等級，以滿足在線和離線的實際運行需求。

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

首先請看一下在混部中一個 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表示1Corealibabacloud.com/reclaimed-memory: 2048 # 單位 字節(jié)，和普通內(nèi)存一樣。單位可以為 Gi Mi Ki GB MB KBrequests:alibabacloud.com/reclaimed-cpu: 1000alibabacloud.com/reclaimed-memory: 2048

這是在混部里面我們引入的 Pod 的等級，和社區(qū)原生不同的地方在于，我們顯式的在 anotation 和 label 里面申明了 3 種等級：LSR、LS、BE。這 3 種等級會同時和調(diào)度優(yōu)先級（Priority）、服務質(zhì)量（Qos）產(chǎn)生關聯(lián)。

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

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-iamcF45i-1638369891833)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/04f8e9a99294423fa13c78ba051a203e~tplv-k3u1fbpfcp-zoom-1.image “4.png”)]

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-GXO9deQM-1638369891834)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/28460b4bdf1d4050bd35c44b72d99fc0~tplv-k3u1fbpfcp-zoom-1.image “5.png”)]

可以看到，這個等級，不但和 Pod 在單機上運行的 CPU、內(nèi)存有關，還和網(wǎng)絡 Qos 的全鏈路優(yōu)先級有關，避免低優(yōu)的離線類任務搶占了所有的網(wǎng)絡帶寬。阿里在內(nèi)核方面做的工作有效的保證了運行時的應用穩(wěn)定性，2021 年雙 11 期間，阿里成為全球首家將所有業(yè)務都放在自家公共云上的大型科技公司，這意味著阿里云有能力應對高難度復雜環(huán)境下的技術挑戰(zhàn)，也帶來了非常大的技術收益：阿里巴巴業(yè)務的研發(fā)效率提升了 20%、CPU 資源利用率提升 30%、應用 100% 云原生化、在線業(yè)務容器可達百萬規(guī)模，同時計算效率大幅提升，雙 11 整體計算成本三年下降 30%。在這個過程中，混合部署技術發(fā)揮了重要作用。內(nèi)核團隊及云原生團隊工程師踩了無數(shù)的坑，沉淀了包括彈性 CPU 帶寬、Group Identity、SMT expeller、memcg 異步回收、內(nèi)存水線分級、memcg OOM 等多項高級特性，處于業(yè)界領先水平。這些工作都會在系列的文章里面后續(xù)一一介紹。

當這三種類型優(yōu)先級任務實際在調(diào)度和運行時發(fā)生的行為，如下面這個表所示

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-MVNucXdz-1638369891835)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9762dad0fe894303b9410e3a1194c156~tplv-k3u1fbpfcp-zoom-1.image “6.png”)]

也就是說，混部的優(yōu)先級會同時作用于調(diào)度和運行時，最大程度的保證高 SLO 的高優(yōu)、中優(yōu)任務使用集群內(nèi)的資源。

配額、水位線、多租隔離

本文僅聚焦討論了 K8s 單 Pod 的調(diào)度優(yōu)先級，在實際使用時，為了保證應用的 SLO，需要配合單機的水位線、租戶的配額、以及 OS 隔離能力等等使用，我們會在后續(xù)文章里面詳細探討。

相關解決方案介紹

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

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

參考文檔

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

文內(nèi)詳情鏈接

1）節(jié)點壓力驅(qū)逐(Node-pressure Eviction)：
https://kubernetes.io/docs/concepts/scheduling-eviction/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：
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass

7）PodDisruptionBudget：

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

8）Eviction：
https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/

點擊此處，即可查看阿里云專有云敏捷版云原生 Stack 相關介紹！

總結

以上是生活随笔為你收集整理的历经 7 年双 11 实战，阿里巴巴是如何定义云原生混部调度优先级及服务质量的？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。