![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/4e44fbe067424231a2dae8fe7d82afff.png)

作者 | 黃濤、汪萌海
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/wj0hrHIRHnBUNZZXnRm5xg)

作為更進一步的雲端計算形態，雲原生正在成為雲時代的技術新標準，透過重塑整個軟體生命週期，成為釋放雲價值的最短路徑。

在企業內部，將雲原生基礎架構作為企業內部的統一架構已成為大勢所趨。與此同時，也必然帶來了由各種基礎平臺整合帶來的相容性問題，特別是規模越大、歷史沉澱越多的企業，這種“技術債務”體現得越明顯。

本文分享的經驗來自於阿里巴巴過去數年來在混合排程方面積累的生產實踐積累，具有很強的生產實用價值。內容由淺入門，逐漸深入到排程器內幕，講述在大規模容器排程場景下，阿里巴巴針對雲原生應用設計的統一基礎設施 ASI（Alibaba Serverless infrastructure）排程器如何管理阿里巴巴如此複雜、繁忙的資源排程任務；並嘗試透過一些具體的案例讓您得以充分理解，相信會為有類似問題的讀者開啟設計思路，並提供落地借鑑。透過本文，相信您將系統地理解阿里巴巴複雜任務場景下的資源混合排程。

# 排程器總覽

ASI 在阿里集團內部引領著容器全面上雲的實施，承擔了包括阿里集團內部輕量級容器架構演進、運維體系雲原生化等職責，並進一步加速促進了新興的技術包括 Mesh、Serverless、Faas 等在阿里集團內的落地；支撐了包括淘寶、天貓、優酷、高德、餓了麼、UC、考拉等幾乎所有經濟體內部業務、阿里云云產品眾多場景及生態。

ASI 的核心基於 Kubernetes，並提供完整的雲原生技術棧支援。如今的 ASI 也已成功實現與阿里雲容器服務 ACK（Alibaba Cloud Container Service for Kubernetes）的會師；而 ACK 既保留了雲上的各種能力，也能成功應對阿里集團複雜的業務環境。

ASI 排程器是 ASI 雲原生的核心元件之一。在 ASI 雲原生的發展歷程中，排程器的作用至關重要。最直觀的認知是：阿里巴巴規模龐大的線上電商交易1容器，例如購物車、訂單、淘寶詳情等，每一臺容器的分佈，包括容器編排、單機計算資源、記憶體資源，均由排程器分配和排程；特別是在 雙11 零點峰值場景下，少數容器編排錯誤都有可能給業務帶來致命影響，排程器需負責把控峰值時每一臺容器計算的質量，其重要性可想而知。

ASI 排程器起源於 2015 年線上電商交易1容器排程，這一年最早的排程器僅涵蓋線上交易 T4（阿里早期基於LXC和Linux Kernel定製的容器技術）和 Alidocker 場景，出生即責任重大，並在 2015 年扛住 雙11 流量峰值中發揮作用。

ASI 排程器的演進之路也伴隨著雲原生髮展的全過程。它經歷了最早期的線上交易1容器排程器、Sigma 排程器、Cerebulum 排程器、ASI 排程器；到如今我們正在建設的下一代排程器 Unified-Scheduler，它將進一步吸收並融合過去數年阿里巴巴 ODPS（伏羲）、Hippo 搜尋、線上排程在各個領域的先進經驗。各階段的排程解讀如下圖：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/583e69d039ae4a7cb1ff0f17e2cb02f7.png)

在 ASI 排程器的演進過程中有非常多的挑戰需要解決，主要體現在：

- **排程器排程的任務種類豐富多樣**，有海量的線上長生命週期容器和 POD 例項、Batch 任務、眾多形態的 BestEffort 任務等不同 SLO 等級的任務；有計算型、儲存型、網路型、異構型等眾多不同資源型別的任務，不同任務的訴求和場景又千差萬別。

- **排程之上的宿主資源各異**。排程管理著阿里集團內部數量龐大的宿主資源，包括眾多機型的存量非雲物理機、雲上神龍、ECS、異構機型如 GPU/FPGA 等。

- **排程器服務場景廣泛**。例如：最典型的泛交易場景；最複雜的中介軟體場景；Faas/Serverless/Mesh/Job 等眾多新興計算場景；餓了麼、考拉、神馬等新興生態場景；公共雲上伴隨著多租安全隔離的排程訴求；還有全球範圍內都非常具有挑戰性的 ODPS（伏羲）、Hippo、螞蟻、ASI 統一排程場景。

- **在基礎設施層的職責眾多**。排程器部分承擔著基礎設施機型定義、計算儲存網路資源整合、收斂硬體形態、透明化基礎設施等眾多職責。

關於阿里雲原生詳細的發展歷程，有興趣的同學可以透過[《一個改變世界的“箱子”》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247497419&idx=1&sn=1b22ae73908f0d65498ec7f08042ce53&chksm=fae6fd04cd917412b0d51ba8e34b33563ddb858194665879fb7223080c5c03fe7a74fc65a04c&scene=21#wechat_redirect)這篇文章來了解。下面，我們重點來分享 ASI 排程器是如何管理著阿里如此龐大規模、如此複雜繁忙的計算資源排程任務。

# 排程器初探

## 1. 排程器是什麼

排程器在 ASI 眾多元件中的作用非常核心。排程器是雲原生容器平臺排程系統內眾多核心元件之一；排程器是資源交付的基石。排程器是 ASI 雲原生的大腦。排程器的價值主要體現在：

- 能力強大 & 場景豐富的資源交付(計算、儲存)

- 成本最優的資源交付

- 業務執行時穩定最優的資源交付

更通俗地講，排程器要做的是：

- 一次作業排程的最優：在叢集內選擇一臺最合適的宿主機，並在這臺宿主機上，以最佳的資源使用姿勢，做到最少的相互干擾（如 CPU 分佈、IO 爭搶）來執行使用者提交的計算作業。

- 叢集全域性排程的最優：確保全域性資源編排最優（如碎片等）、資源執行最穩定、全域性成本最優。

在 ASI 雲原生體系中，中心排程器所在的位置如下圖（其中標紅的框框所示）：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3b4684dd31154b78943a300ebc3e3827.png)

## 2. 廣義的排程器

在大部分時候，業界講到排程器指的是“中心排程器”，例如社群的 K8s kube-scheduler。但真實的排程場景複雜，每一次排程都是一個複雜又靈活的綜合體協同。作業提交後，它需要中心排程器、單機排程、核心排程多層次排程共同協調，並進一步在 K8s 元件 kubelet、controller 等配合下完成執行；線上排程場景，又有著批次編排排程器；而重排程下的多次排程則確保叢集總是保持最優。

**ASI 廣義的排程器理解為：中心排程器、單機排程、核心排程、重排程、規模化編排排程、多層排程 一體的綜合體**。

### 1）中心排程器

中心排程器負責計算每一個（或一批）作業的資源編排計算，它確保一次排程最優。中心排程器為這個具體的任務計算確定諸如叢集、地域、執行節點（宿主機）等資訊，更進一步細化節點上的 CPU 分配、儲存、網路資源分配。

中心排程器在 K8s 生態元件協同下，管理著大部分任務的生命週期。

ASI 雲原生的演進之路中，中心排程器即上文描述的 Sigma 排程器、Cerebulum 排程器、ASI 排程器等等。

### 2）單機排程

主要負責兩類職責：

**第一類職責**：統籌協同單機內多 POD 的最佳執行。ASI 在接受到中心排程器的節點選擇指令後，將任務排程到具體的節點上執行，單機排程即開始工作：

- 單機排程將立刻、或週期性、或運維式 動態確保單機內多 POD 的工作最優，這意味著它將在單機內統籌協同資源，例如：每一個 POD 的 CPU 核分配的最佳調整。
- 實時根據 POD 的執行指標如負載、QPS 等，針對部分執行時資源執行單機內的 VPA 擴縮容、或對低優先順序的任務執行驅逐等操作。例如：動態擴充套件 POD 的 CPU 容量。

**第二類職責**：單機資源資訊的採集、上報、匯聚計算，為中心排程提供決策依據。在 ASI 內，單機排程元件主要指 SLO-Agent、Kubelet 的部分增強能力；在正在建設的 Unified-Scheduler 排程內，單機排程主要指 SLO-Agent、Task-Agent、以及 Kubelet 的部分增強能力。

### 3）核心排程

單機排程從資源視角統籌單機內多 POD 的最佳執行，但任務的執行態實際由核心控制。這就需要核心排程。

### 4）重排程

中心排程器確保了每次任務的最佳排程，即一次性排程問題；但中心排程器並不能實現叢集維度的全域性最優，這就需要重排程。

### 5）規模化編排排程

規模化編排排程是阿里巴巴大規模線上排程的特有場景，自 17 年開始建設，現在已經非常成熟，並仍在持續增強中。

利用規模化編排能力，我們可以一次性排程數萬、數十萬容器，一次性確保叢集維度所有容器的全域性最佳編排。它非常巧妙地彌補了一次性中心排程的弊端，規避了大規模建站場景下需反覆重排程的複雜度。

關於**核心排程、重排程、規模化編排排程**，我們將在下面的章節中詳細展開。

### 6）排程分層

另一個維度，我們也會定義排程分層，包括 一層排程、二層排程、三層排程...等；Sigma 在離線混部場景甚至引入了零層排程的概念。每個排程系統對排程分層的理解和定義會不一樣，並都有各自的概念。例如，在過去的 Sigma 體系內，排程分為 0 層、1 層 和 2 層排程：

- 0 層排程器負責的職責是負責全域性資源檢視和管理，並承接各個 1 層排程間的排程仲裁，以及具體執行；1 層排程主要是對應 Sigma 排程器、伏羲排程器 [也可以包含其它排程器]。
- 在 Sigma 體系中，Sigma 排程器作為 1 層排程，負責資源層的分配。
- 2 層排程交由不同的接入業務各自實現（例如電商交易、廣告 Captain、資料庫 AliDB 等）。2 層排程充分貼近和理解各自業務，並站在業務全域性視角做眾多最佳化，建設排程能力，如業務驅逐、有狀態應用故障自動運維等，做到貼心服務。

Sigma 的排程分層體系的致命弊端是，各個二層排程的技術能力和投入參差不齊；例如廣告的二層排程系統非常優秀，但並不是所有的二層排程對業務貼心到極致。ASI 吸取教訓，將眾多能力下沉至 ASI 內，並進一步標準化上層 PAAS，簡化上層的同時增強上層能力。

而今天正在建設的下一代排程器概念內，也分為多層，例如：計算負載層（主要指 Workload 的排程管理）、計算排程層（如 DAG 排程、MR 排程等）、業務層（同 Sigma 2 層的概念）。

## 3. 排程資源型別

我嘗試用正在建設的 Unified-Scheduler 排程器來讓大家更好地理解。在 Unified-Scheduler 排程器內，排程著 Product 資源、Batch 資源、BE 計算資源三種分等級的資源形態。

不同排程器對分等級的資源形態有不同的定義，但本質上大同小異。為了讓大家更好地理解這一精髓，我在後續的章節對 ASI 排程器也做了詳細講解。

### 1）Product（線上）資源

有 Quota 預算的資源，且排程器需保障其最高階別的資源可用性。典型代表是線上電商核心交易的長生命週期 POD 例項。最經典的例子就是 雙11 核心鏈路上的購物車（Cart2）、訂單（tradeplatform2）等交易核心的業務 POD。這些資源要求算力的嚴格保障、高優先順序、實時性、響應低延時、不可被干擾等等。

舉例來說，線上交易的長生命週期 POD 的存在時間很長，數天、數月、甚至數年。大部分應用研發同學申請的應用，在構建完畢後需要申請數臺長生命週期例項，這些都是 Product 資源。淘寶、天貓、聚划算、高德、友盟、合一、菜鳥、國際化、閒魚....等等眾多業務研發同學申請的 POD（或容器）例項，相當大部分都是 product 資源。

Product 資源不僅僅指線上長生命週期的 POD；凡是符合上述定義的資源請求，都是 Product 資源。但並不是所有的長生命週期 POD 都是 Product 資源。例如阿里內部“Aone 實驗室”用於執行 CI 構建任務的 POD，可以長生命週期存在，但它可以被低成本驅逐搶佔。

### 2）Batch 資源

線上業務使用的 Product 資源的 Allocate 和 Usage 之間的 Gap 在一段時間內是比較穩定的，這個 Gap 和 Prod 未分配的資源就作為BE資源，售賣給針對 latency 不那麼敏感和但是對資源穩定性有一定需求的業務。Batch 有 quota 預算，但是保證一段時間內（例如 10 分鐘）的一定機率（例如 90%）的資源可用性。

也就是說，Product（線上）資源申請走了賬面上的資源，但實際上從負載利用率指標來看可能有眾多算力未被使用；此時將發揮排程器的差異化 SLO 分等級排程能力，將那些未跑滿的部分，作為超發資源充分使用，售賣給 Batch 資源。

### 3）Best Effort(BE)資源

指沒有 Quota 預算，不保障資源可用性，隨時可以被壓制和搶佔；節點上已分配在節點的 Usage 低於一個水位的時候，排程器認為這部分 Gap 是一個“比較不穩定/不記賬”的資源，那麼這個 Gap 就稱為 BE 資源。

我們可以這樣來比方：Product、Batch 資源負責大塊吃肉，BE 資源則負責消費 Product 和 Batch 不要的殘渣。例如：日常開發工作中，研發需要跑很多 UT 測試任務，這類計算任務對計算資源的質量要求並不高，時間延時的容忍度也比較高，也不大好評估額度預算，針對這類場景去購買大量的 Product 或者 Batch 資源，將非常不划算；但如果使用最廉價的 BE 資源，收益將相當可觀。此時，BE 資源就是 Product/Batch 執行中沒有用到的資源。

**很容易理解到，正是透過這種分等級的資源排程能力，從技術層面，Unified-Scheduler 排程器可以將一臺物理節點的資源使用，發揮到極致**。

# 排程器能力總覽![3.png](https://ucc.alicdn.com/pic/developer-ecology/c3cde5a0629a44e0801d594ac0a1f838.png)

下圖是 ASI 圍繞著廣義排程需覆蓋的職責，並對應不同資源等級訴求、以及服務的豐富業務場景，構建的排程能力總覽。透過這張圖，大家可以理解到 ASI 排程器的技術全貌。

# 典型線上排程能力

## 1. 線上排程的業務訴求

在 ASI 雲原生容器平臺上，線上部分服務著交易、導購、直播、影片、本地生活、菜鳥、高德、合一、友盟、海外等數十個 BU 的各類排程場景。其中最高等級的“Product 資源”的排程佔比最為龐大。

線上業務的排程與離線排程、眾多 JOB 型排程相比較，有著典型的差異（描述線上場景時，大家可以想象到，離線排程的世界同樣精彩）。

### 1）生命週期

- Long Running：線上應用的容器生命週期普遍都比較長。少則數天，大部分以月計，部分長尾應用甚至存活數年。
- 啟動時間長：應用的映象體積大，下載映象時間較長，服務啟動記憶體預熱等等，這導致應用啟動時間在幾秒、數十分鐘都有。

長生命週期的特性，與一些典型的短生命週期任務排程（如 FaaS 函式計算），在任務特徵上有著本質的不同，背後的技術挑戰也截然不同。例如：相對短生命週期的函式計算場景的挑戰是：最極致的排程效率、百毫秒的執行效率、快速的排程吞吐、POD 執行時效能等。而長生命週期 POD 帶來的差異化挑戰是：全域性最優的排程必須依賴重排程來持續迭代最佳化；執行時的最佳排程必須依賴單機重排程持續最佳化保障。可以想象，在過去非雲原生時代，眾多業務不可遷移，對排程而言簡直是噩夢；這意味著排程器不僅僅面對排程能力的技術問題，還需面對難度巨大的存量業務治理推動；線上應用的啟動時間長，又更加劇降低了重排程的靈活度，帶來更多的複雜度。

### 2）容器執行時

- 容器執行時需要支援業務的實時互動、快速響應、低業務 RT 等訴求。線上容器執行時，大部分系統需承擔實時互動職責，並對延遲異常敏感，稍大的延遲將帶來明顯糟糕的業務體感。

- 資源特徵明顯：如網路消耗型、IO 消耗型、計算消耗型等等。相同特徵的例項共存時，極易發生彼此間的明顯資源爭搶。

線上容器的執行時由於對業務和算力都非常敏感，因此對排程質量提出了非常苛刻的挑戰。

### 3）應對阿里線上應用特有的複雜業務模型

- 流量高低峰特徵：線上業務的服務一般都會有比較明顯的高低峰，例如餓了麼的高峰是在中午和晚上、淘寶的高峰也有明顯的波谷和峰值。

- 突發流量：業務的複雜度，導致這些突發流量並不一定能呈現一定規律；例如直播業務可能因為某個突發的事件導致流量激增。突發流量背後的技術訴求往往是彈性，最經典的案例是 2020 年疫情期間的釘釘彈性訴求。

- 資源冗餘：線上業務從出生的那一刻開始，就定義了冗餘資源；這主要是出於容災的考慮。但站在阿里巴巴全域性視角，相當多的長尾應用因規模小而對成本和利用率不敏感，積少成多，背後是巨大的算力浪費。

### 4）特有的規模化運維訴求

- 複雜的部署模型：例如：需要支援應用單元化部署，多機房容災，小流量、灰度、正式多環境部署的複雜排程需求。

- 大促 & 秒殺的規模化峰值特徵：阿里巴巴的各種大促貫穿全年，比如大家熟悉的 雙11、雙12、春節紅包等等。整個鏈路上的應用壓力、資源消耗都會隨著大促峰值流量的增長成倍增加，這需要排程器強大的規模化排程能力。

- 大促建站：大促的時間是計劃性的，為了節約雲資源的採購成本，必須儘可能降低雲資源的保有時間。排程器需最快速度完成大促前的建站，並在大促後快速歸還資源到阿里雲。這意味著極其嚴苛的規模化排程效率訴求，並把更多的時間留給業務。

## 2. 一次排程：排程基本能力

下表詳細描述了線上排程最常見的排程能力：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/be676e8aa23f4e829ae39656d31fa19e.png)

- 應用基本訴求對應的是：應用擴容對應的基本訴求，例如 POD 規格、OS 等。在 ASI 排程器內，它被抽象為普通的 label 匹配排程。

- 容災與打散：locality 排程，ASI 已經透過各種手段獲取到諸多詳細資訊，例如上圖中的 網路核心、ASW 等。

- 高階策略：ASI 會盡可能標準化、通用化業務訴求，但仍然不可避免地存在一些業務，對資源、執行時有眾多特定要求，例如特定的基礎設施環境如硬體等、容器能力的特定訴求如 HostConfig 引數、核心引數訴求等。

- 關於排程規則中心：業務對策略的特定要求，決定了排程背後還將對應一個強大的排程策略中心，它指導著排程器使用正確的排程規則；排程規則中心的資料來自於學習，或專家運維經驗。排程器採納這些規則，並應用於每一個 POD 的擴容分配中。

## 3. 應用間編排策略

因叢集節點數量有限，彼此潛在干擾的眾多應用，不得已需在同一節點並存時，這時就需要應用間編排策略，來確保每一個宿主節點和每一個 POD 執行時最優。

實際的排程生產實踐中，“業務穩定性”永遠是排在第一位，但資源卻總是有限的；我們很難平衡“資源成本最優”和“業務穩定性”。大部分情況下，應用間編排策略都能完美地解決這一平衡；透過定義應用之間（如 CPU 消耗密集型、網路消耗型、IO 密集型、峰值模型特徵等）的並存策略，叢集內充分打散，或同一節點並存時又有充分的策略約束保護，進而做到不同 POD 間的干擾機率最小。

更進一步，排程器在執行時輔以更多技術手段最佳化，例如：透過網路優先順序控制、CPU 精細編排控制等策略，來儘可能規避應用間執行時的潛在影響。

應用間編排策略帶來的其它挑戰是：排程器在建設好本職的應用間編排能力外，還需充分理解其上執行的每一個業務執行特徵。

## 4. CPU 精細化編排

CPU 精細編排在“線上排程領域”內是非常有意思的話題，它包括 CpuSet 排程、CpuShare 排程。其它場景的排程領域，例如離線排程領域，它並沒有這麼重要，甚至不可被理解；但線上交易場景下，無論是理論推斷、實驗室場景、還是無數次大促壓測資料，都證明了精準的 CPU 排程就是這麼重要。

CPU 精細編排的一句話解讀是：調核，確保 CPU 核最大化、最穩定地被使用。

CPU 精細編排如此重要，以至於 ASI 在過去的數年，已經將這一規則吃透並使用到了極致。相信您在看到下表後（僅含 CpuSet 精細編排排程），您也會感嘆 ASI 甚至已經將它玩出了花樣。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/83818ac911ee466aa2f30a394470ffec.png)

> 科普：以一臺 96 核（實際上我們說的都是 96 個邏輯核）的 X86 架構物理機或神龍為例，它有 2 個 Socket，每個 Socket 有 48 個物理核，每個物理核下有 2 個邏輯核。【當然，ARM 的架構又與X86不同】。
> 
> 由於 CPU 架構的 L1 L2 L3 Cache 設計，最理想的分配是：同一個物理核下的 2 個邏輯核，其中一個核 分配給最核心的線上交易應用如 Carts2（購物車業務），另一個核分配給另一個不繁忙的非核心應用；這樣在日常、或 雙11 零點峰值時，Carts2 可以佔盡便宜。這種用法，在實際的生產環境、壓測演練環境中均屢試不爽。
> 
> 假如我們將同一個物理核上的兩個邏輯核，都同時分配給 Carts2 時，由於業務峰值的相同（尤其是同一個 POD 例項），資源的最大化使用就會大打折扣。
> 
> 理論上我們也應該儘量規避兩個同樣都是交易核心的應用，例如 Carts2（購物車業務）、tradePlatform2（訂單），使其不要去共用這兩個邏輯核。但實際上在微觀層面，Carts2 和 tradePlatform2 的峰值會有差異，所以實際上影響還小。儘管這樣的 CPU 分配看起來有些“將就”；但物理資源總歸是有限的，也只能保持這份“將就”了。
> 
> 而在 numa-aware 開啟時，為了最大化使用 L3 Cache 來提升計算效能，同一個 POD 的更多核，又應確保儘量規避跨 Socket。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/bb3095595747493fac1a8e7fb9c9e1c2.png)

而當使用 CPUShare 時，Request 和 Limit 如何分配，也非常有學問；CPUSet 和 CPUShare 並存時，排程將更加複雜（例如：CpuSet 容器的新擴容、或下線，潛在的訴求是整機所有 POD 的 CPU 重排程）；而在新興的 GPU 異構排程場景下，CPU 與 GPU 的並存分配也具備一定的技巧。

## 5. 規模化編排排程

規模化編排主要應用於建站、搬站或規模化遷移場景，例如阿里巴巴頻繁的大促建站、機房遷移訴求下的超大規模搬站等。基於成本考量，我們需要在儘可能短的時間，以極少的人力成本快速建立數十萬級別 POD。

多個任務依次請求的隨機性和不可預見性，決定了中心排程在規模化領域存在諸多弊端。在沒有規模化編排能力之前，阿里巴巴大規模站點的建設，往往需經歷複雜的 “業務自擴容 -> 反覆重排程” 的過程，這將耗費大量人力數週的精力。好在我們有了規模化編排排程，在小時級規模化交付效率的同時，又能確保 99% 以上的資源分配率。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/56b3db1894fd428b9dbca9b76954b182.png)

# 通用排程能力

## 1. 重排程

中心排程器做到了一次性最優排程；但與最終想要的叢集維度全域性排程最優，是兩個完全不一樣的概念。重排程也包括全域性中心重排程和單機重排程。

為什麼一定需要中心重排程作為一次性排程的補償呢？我們舉幾個例子：

- ASI 排程叢集記憶體在眾多長生命週期的 POD 例項；隨著時間的積累，叢集維度必將產生眾多資源碎片、CPU 利用率不均等問題。

- 大核 POD 的分配需要動態的騰挪式排程能力（實時驅逐某些小核 POD 並空閒出資源）、或基於提前規劃的全域性重排程，在眾多節點上預空閒一些大核。

- 資源供給總是緊張的。對某個 POD 做一次性排程時，可能存在一定“將就”，這意味著某種瑕疵和不完美；但叢集資源又是動態變化的，我們可以在其後的某個時刻，對該 POD 發起動態遷移，即重排程，這將帶來業務更佳的執行時體驗。

中心重排程的演算法、實現上往往非常複雜。我們需要深入理解各類重排程場景並充分覆蓋，定義清晰的重排程 DAG 圖，動態執行並確保執行的成功率。

眾多場景也需要單機重排程。例如：CPU 精細編排的 SLO 最佳化、基於 OQS 資料驅動的單機重排程最佳化等。

需要強調的是，單機重排程的執行，必須先解決安全風控的問題，規避不可控的爆炸半徑。在單機側風控能力不足前，我們建議您暫不要採用節點自治方式，而是改為嚴格保護控制下的中心統一觸發。實際上在 K8s 域內，會出現非常多不可避免的節點自治場景（例如 pod yaml 變化時，Kubelet 將執行相應變更），過去 ASI 花費數年持續梳理每一個潛在的風控點，並迭代建設了分等級風控管理（核按鈕、高危、中危等）的 Defender 系統；針對潛在風險項，執行單機側動作前，與中心的 Defender 互動，透過安全防控規避災難事件的發生。我們建議排程器必須同樣做到嚴密的安全防禦等級，才允許節點自治操作。

## 2. 核心排程

核心排程存在的背景是：一臺並行執行著眾多工的繁忙宿主機，即使中心排程 & 單機排程，已共同確保其最佳資源分配（如 CPU 分配、IO 打散等），但實際執行時，多工間不可避免地進行核心態的資源爭搶，在大家熟知的在離線混部場景中競爭尤為激烈。這就需要中心排程、單機排程、核心排程 透過眾多協同，例如統籌任務的各類資源優先順序，並交由核心排程控制執行。

這也對應眾多核心隔離技術。包括 CPU：排程優先順序 BVT、Noise Clean 機制等；記憶體：記憶體回收、OOM 優先順序等；網路：網路金銀銅優先順序、IO 等等。

在今天我們還有了安全容器。基於安全容器的 Guest Kernel 和 Host Kernel 隔離機制，我們可以更優雅地規避核心執行態的部分爭搶問題。

## 3. 彈性排程、分時排程

彈性和分時的邏輯都是更好的資源複用，只是維度不一樣。

ASI 排程器與阿里雲基礎設施層充分協同，利用 ECS 提供的強大彈效能力，在餓了麼場景，低峰期向雲歸還資源，高峰期重新申請相應資源。

我們可以使用 ASI 大資源池（注：ASI 資源池的宿主資源均來自於阿里云云資源）的內建彈性 Buffer，也可以直接使用阿里雲 IaaS 層的彈性技術。二者的平衡是一個很有爭議的話題，也是一個比較藝術的過程。

ASI 的分時排程更是將資源複用做到了極致，並帶來了巨大的成本最佳化。透過每天晚上大規模停用線上交易 POD 例項，釋放的資源用於 ODPS 離線任務使用，每天早上離線任務退水並重新拉起線上應用。這個經典場景更是將在離線混部技術的價值發揮到最大。

分時的精髓是資源複用，以及依賴的大資源池建設管理，這是資源運營 & 排程技術 的綜合。這需要排程器積累多多益善的豐富形態作業、以及多多益善的海量作業任務。

## 4. 垂直伸縮排程/X+1/VPA/HPA

垂直伸縮排程是一種秒級交付技術，非常完美地部分解決了突發流量問題。垂直伸縮排程也是大促零點峰值壓力風險的殺手鐧，透過對存量 POD 的資源垂直調整、準確可靠的 CPU 排程和洗牌演算法來做到計算資源的秒級交付。垂直伸縮排程、VPA 技術一脈相承，垂直伸縮排程也是 VPA 的場景之一。

“X+1” 水平擴容排程在某種意義上也可以理解為 HPA 場景之一，只不過 “X+1” 水平擴容排程由手動觸發。“X+1” 側重於強調極致的資源交付效率，這背後是研發效率的極大提升：線上 POD“X（若干）”分鐘可啟動完畢提供業務服務；除應用啟動外的所有其它操作，務必在 “1” 分鐘內全部完成。

垂直伸縮排程與 “X+1” 水平擴容排程互為補充，共同為各類峰值保駕護航。

ASI 也正在實施更多的 VPA 和 HPA 場景。例如，我們可以透過 VPA 技術，額外提供螞蟻春節紅包更多數量的免費算力，這將是非常大的成本節約。

VPA/HPA 等排程技術更多場景的極致實施，也是阿里巴巴未來將繼續追求完善的地方。

## 5. 分等級[差異化 SLO]的資源排程

差異化 SLO 排程是排程器的精髓之一；這節內容與上文中的【排程資源型別】章節存在一定的重複。鑑於差異化 SLO 的複雜度，所以有意將它放在本章的最後一節來講述。

ASI 排程器內，也非常精確地定義了 SLO(服務質量目標)、QoS 和 Priority。

### 1）SLO

SLO 描述的是服務質量目標。ASI 透過不同的 QoS 和 Priority 來提供差異化 SLO，不同的 SLO 有不同的定價。使用者可以根據不同的業務特性來決定"認購"哪類 SLO 保障的資源。如：離線的資料分析任務，則可以使用低等級的 SLO 以享受更低的價格。而對於重要業務場景則可以使用高等級的 SLO，當然價格也會更高。

### 2）QoS

QoS 描述了資源保障質量。K8s 社群定義的 QOS 包括 Guaranteed、Burstable、BestEffort。ASI 中定義的 QOS，與社群並沒有進行完全對映（社群完全用 Request / Limit 來對映）。為了能將集團的場景（如 CPUShare，混部等）描述清晰，ASI 從另外一個維度定義了 QOS，它包括 LSE / LSR / LS / BE，清晰地劃分出不同的資源保障，不同的業務根據自身的延遲敏感度可以選擇不同的 QOS。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/3b265c74732a4f7e9200decdcfc27409.jpg)

### 3）PriorityClass

PriorityClass 和 QoS 是兩個維度的概念。PriorityClass 描述的則是任務的重要性。

資源分配策略和任務的重要性（即 PriorityClass 和 QoS）會有不同的組合，當然也需要存在一定的對應關係。例如，我們可以定義一個名為 Preemptible 的 PriorityClass，其大部分任務對應到 BestEffort 的 QoS。

各個排程系統對 PriorityClass 有不同的定義。例如：

- 在 ASI 中，ASI 的 priority 定義，目前定義了 System、Production、Preemptible、Production、Preemptible。這裡不詳細解讀每個等級的細節。
- 搜尋 Hippo 中定義的種類和粒度更細，包括：System、ServiceHigh、ServiceMedium、ServiceLow、JobHigh、JobMedium、JobLow 等。這裡不詳細解讀每個等級的細節。

# 全域性最優的排程

## 1. 排程模擬器

排程模擬器有點類似於阿里巴巴的全鏈路壓測系統，透過線上真實的流量回放、或模擬流量回放，在模擬環境驗證排程新的能力，進而不斷地錘鍊各種排程演算法，最佳化各類指標。

排程模擬器的另一個常見的用途是，是對線上疑難雜症問題做線下模擬，做到無害、高效地定位各類問題。

一定程度上，排程模擬器是全域性排程最優的基礎。有了排程模擬器，我們得以在模擬環境，反覆錘鍊各種演算法、技術框架、技術鏈路，進而做到全域性指標的最佳化，例如：全域性分配率、不同場景下的排程效能、排程穩定性等等。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/1a1cb8e480c44a8cb77c073118fb0818.png)

## 2. Elastic Scheduling Platform（ESP 平臺）

為了做到全域性最優的排程，圍繞著排程器，ASI 構建了一套全新的 Elastic Scheduling Platform（ESP 平臺），旨在圍繞排程器，打造基於排程資料指導 & 核心排程能力 & 產品化排程運營 的一站式自閉環排程效能系統。

在過去，我們已經建設了諸多類似模組，例如排程 SLO 巡檢、眾多排程工具、不同場景的二層排程平臺等；而基於 ESP 平臺，集合更多的二層排程能力，帶給 ASI 全域性最優的排程質量，並圍繞 業務穩定性、資源成本、使用者效能提升，帶給客戶更貼心的服務。

# 更多排程能力

本文嘗試著系統地講解 ASI 排程器的基本概念、原理和各種場景，並帶領您走進排程器美麗精彩的世界。排程器博大精深，遺憾的是，受限於篇幅，也不得不控制篇幅，非常多的內容點到為止並未深入展開。**在排程器內，還有更多更深層次的排程內幕，如異構機型排程、排程畫像、公平性排程、優先順序排程、騰挪排程、搶佔排程、磁碟排程、Quota、CPU 歸一化、GANG Scheduling、排程 Tracing、排程診斷等眾多排程能力，本文均未予闡述。受限於篇幅，本文也未講述 ASI 強大的排程框架結構及最佳化、排程效能最佳化等更多更深層次的技術內幕**。

早在 2019 年，ASI 已最佳化 K8s 單叢集至業界領先的萬級節點規模，並得益於阿里雲 ACK 強大的 K8s 運維體系，阿里集團內持續保有著數量眾多的大規模計算叢集，同時也積累了業界領先的 K8s 多叢集生產實踐。正是在這些大規模 K8s 叢集內，ASI 基於完善的容器排程技術，持續為眾多複雜的任務資源提供著計算資源算力。

在過去的數年，藉助於集團全面上雲的契機，阿里集團在排程領域，已實現了從 ASI 管控到阿里雲容器服務 ACK的全面遷移和進化。而阿里集團內複雜、豐富、規模化的業務場景，未來也將持續輸出、增強並錘鍊雲的技術能力。

揭開阿里巴巴複雜任務資源混合排程技術面紗

相關文章