雲原生架構下複雜工作負載混合排程的思考與實踐

作者：實驗室小陳/大資料開放實驗室

 10月25日，第一屆中國雲端計算基礎架構開發者大會在長沙召開，星環科技與眾多國內外廠商共同就“雲原生”、“安全與容錯”和“管理與優    化”等雲端計算領域話題進行了深入交流和探討。星環科技容器雲研發工程師關於"基於Kubernetes的複雜工作負載混合排程器思考與實  

踐"相關內容進行了分享，本文是對會議上內容的整理 。

近年來，雲原生的概念席捲了整個雲端計算領域，以Kubernetes為代表的雲原生技術所帶來的變革引發了企業深思，越來越多的企業     逐步將基礎架構向雲原生架構遷移，業務應用也以遵從雲原生十二要素標準進行開發部署。技術交付理念的變革同時也加快了企業       數字化和智慧化轉型的過程。

雲原生技術初期天然適合微服務架構，而隨著整個雲原生技術的快速發展和雲原生基礎架構的不斷夯實，企業逐漸開始將傳統大資料的分析型應用和計算型應用“搬上”雲原生架構。至此，雲原生基礎架構作為企業內部的統一基礎架構已成為必然趨勢。然而，將雲原生基礎架構作為統一的基礎架構也勢必面臨著基礎平臺整合後的相容性問題，例如：傳統大資料任務如何在雲原生架構下進行編排和排程、大資料中所提倡的計算資料本地化如何在雲原生架構下完美落地等。因此，雖然統一雲原生基礎架構是大勢所趨，但依然有很長的路要走。

星環科技是雲原生技術的早期實踐者，為推動統一雲原生基礎架構進行了多方面探索，資料雲平臺產品TDC即是星環在統一雲原生基礎架構方面多年積累和實踐的產物。TDC覆蓋了分析雲、資料雲、應用雲三方面功能，在一個平臺內滿足企業對於三類雲平臺的建設要求，包含資料倉儲、流式引擎、分析工具、DevOps等應用，能夠同時應對多樣、複雜的工作負載場景。為此，星環科技底層雲平臺多年來做了不少工作，接下來就分享下我們在統一雲原生基礎架構下關於複雜工作負載混合排程器的思考與實踐。

統一雲原生基礎架構

在統一雲原生基礎架構的概念出現後，如何解決多型別工作負載的編排和排程成為了一個亟待解決的問題，包括但不限於MicroService、BigData、AI、HPC型別的工作負載。對於MicroService則是雲原生架構天然支援的，所以如何滿足其餘型別的工作負載的編排、排程是迫切需要解決的，典型的如Spark、TensorFlow等社群代表計算任務，HDFS、HBase等大資料儲存服務。而以Kubernetes為核心的開源社群針對這些需求也做了相應的嘗試，比如透過Spark Operator以及TensorFlow Operator等解決了任務編排的問題，但是排程相關的能力仍然有缺失的。除此之外還有一些大資料生態的企業級特性也是原生Kubernetes排程能力無法支援的。為此，我們針對如何解決在統一基礎架構背景下Kubernetes所缺失的排程能力進行了調研和思考。

大資料 / AI生態排程器

讓我們來回顧下在大資料/AI生態的相關排程器的特性，主要調研物件為Mesos和YARN。

•    Mesos

Mesos誕生於加州大學伯克利分校，後經開源後在Twitter被大規模使用，技術原型參考Google內部的排程器進行設計實現。Mesos是一個具有兩級排程架構的框架，其本身主要專注於做基於DRF演算法的資源分配，具體提交的任務資源如何管控和分配則是由特定的Framework實現。因此，在如此靈活的架構下，開發者們有非常廣闊的發揮空間。但是由於其自身並沒有能夠提供太多功能特性導致沒有建立起相應的生態，使得越來越多使用者望而卻步，轉而尋求其他專案。Mesos的特性總結如下：

• 兩級排程架構，更加靈活

• 專注於基於DRF演算法的資源分配

• 可自定義Framework來實現特定任務的資源排程和管理

• 支援線上、離線、HPC型別任務排程

• YA RN

YARN是Hadoop 2.0版本中釋出的一款原生的資源管理和排程框架。隨著YARN的釋出，Hadoop徹底確立了自己在大資料領域的核心地位，所有的大資料元件和服務均可以由YARN進行排程和管理。雖然其架構相比Mesos不夠靈活，但是YARN相比Mesos有Hadoop強大的生態背書，其發展可謂順風順水，相關特性和能力也被企業所推崇，解決了企業中關於資源排程和管理的諸多問題。其特性總結如下：

• 單級排程架構，不夠靈活

• 支援層次化的資源佇列，可以對映多租戶和企業組織架構

• 支援資源共享、彈性排程、公平排程

• 支援多種大資料任務編排排程

• 支援線上、離線、HPC型別任務排程

﹀

Kubernetes原生排程器

相比於大資料/AI生態排程器，Kubernetes原生排程器在微服務、無狀態應用等領域具有得天獨厚的優勢，而在統一雲原生基礎架構背景下，Kubernetes原生排程器所顯露出的能力不足則被不斷放大。 下面列舉了一些Kubernetes原生排程器的不足點：

• 不支援多租戶模型下的資源排程

• 不支援大資料、AI型別任務的排程

• 不支援資源佇列

• 不支援資源共享和彈性排程

• 不支援細粒度資源管控

• 不支援應用感知排程

• 排程排序演算法單一

Kubernetes生態排程器

• Volcano

Volcano（）專案是華為雲開源的Kubernetes原生批處理系統，可以支援批處理任務排程，補足了Kubernetes原生排程器在這方面的能力缺失。Volcano的架構如下所示：

其主要特性包括但不限於如下：

• 支援批處理任務、MPI任務、AI任務排程

• 支援統一Workload定義，透過新增CRD Job來編排和排程不同工作負載

• 支援單一Job異構Pod模板定義，打破Kubernetes原生資源束縛

• 支援資源佇列、資源共享和彈性排程

• 支援組排程、公平排程等多種排程策略

雖然Volcano專案本身足夠優秀，提供了很多Kubernetes原生排程器不具備的新特性，但在統一雲原生基礎架構這樣的背景下，仍然可能會存在一些限制，比如：

1. 部署形式為如果多排程器形式（與Kubernetes原生排程器共存），則可能出現和原生排程器的資源排程衝突問題，因此更適合於在專有叢集部署；2.   當前版本中不支援多級層次化的資源佇列，使得在企業多租戶場景下不能夠很好的進行對映。

• YuniKorn

YuniKorn（）專案為Cloudera發起並開源的專案，定位於跨平臺的通用排程器，其三層架構設計能夠實現對底層多種平臺的適配，當前可以支援Kubernetes，YARN的支援還在開發中。 YuniKorn專案的誕生是為了能夠實現批處理任務、長時執行服務以及有狀態服務都可以由統一排程器排程。YuniKorn的架構如下所示：

其主要特性包括但不限於如下：

• 架構設計靈活，可以實現跨平臺

• 支援批處理任務、長時執行服務、有狀態服務排程

• 支援層次化的資源池/佇列定義

• 支援佇列間的資源公平排程

• 支援基於公平策略的跨佇列的資源搶佔

• 支援GPU資源排程

YuniKorn專案建立之初也是調研瞭如kube-batch（Volcano中的核心功能實現）這樣的專案後進行設計，因此設計層面相比kube-batch多了一些考慮，優秀的設計進一步也為統一排程器的實現奠定了基礎。但由於其shim層為適配各個底層平臺需要不斷補齊這一層的能力，以此來跟上社群的節奏，因此也不能算是完全相容Kubernetes原生的排程器。

• Scheduling Framework v2

在Kubernetes生態發展火熱的同時，社群也沒有停下腳步。從Kubernetesv1.16版本開始引入新的Scheduling Framework，從而進一步解放對於排程器的擴充套件能力。核心思想是將Pod排程過程中的每個環節都儘可能外掛化，並把原有的排程演算法/策略全部用外掛的形式重寫，從而來適配新的Scheduling Framework。擴充套件點如下圖所示：

基於這樣的擴充套件能力，社群興趣小組也發起了Scheduler-Plugins（）專案，來呈現出基於Scheduling Framework v2可以實現哪些Kubernetes原生排程器不具備的能力。當前已經實現瞭如GangScheduling、ElasticQuota、CapacityScheduling、LoadAwareScheduling等外掛。開發者可以直接基於該專案編譯scheduler或將該專案外掛引入自定義的scheduler進行編譯，從而保證既能完全相容Kubernetes原生排程器的全部能力，又可以享受到擴充套件外掛帶來的好處。

TDC中的思考與實踐

在統一雲原生基礎架構背景下，TDC也面臨著如何解決多種工作負載混合排程的問題。 基於對開源社群相關專案的調研和TDC自身痛點的思考，針對排程器提出瞭如下需求：

• 全域性唯一的排程器，防止資源排程衝突

• 支援多租戶場景下的資源排程

• 支援多種工作負載的合理排程

• 支援資源共享和彈性排程

• 支援細粒度的資源管控

• 支援多種排程演算法

• 支援應用感知排程

• 支援多種排程策略

結合上述Kubernetes生態排程器的發展和現狀，我們基於社群原生的擴充套件能力Scheduling Framework v2設計了一款適合TDC需求場景的排程器 -- Transwarp Scheduler。

Transwarp Scheduler設計

借鑑社群優秀開源專案的設計思想，Transwarp Scheduler中有兩個核心：一是完全基於Scheduling Framework進行擴充套件實現，保證對社群原有能力的完全相容性；二是在此基礎上進行抽象封裝，增加資源佇列的定義來滿足TDC在資源排程層面的功能需求。而為減少使用者在使用Transwarp Scheduler時的遷移和學習成本，Transwarp Scheduler中沒有增加新的Workload相關的CRD。

• 資源佇列

資源佇列是一個CRD，我們將其命名為Queue。其具有如下特性：

• 支援層次化定義

• 支援佇列間按權重資源共享

• 支援佇列間的資源借用和回收

• 支援佇列間的公平排程

• 支援佇列內的細粒度資源管控

• 支援佇列內的多種排序演算法

透過這樣的資源佇列定義，可以利用其層次化定義能力來模擬企業多租戶場景中的資源配額管理，並做到共享和彈性配額，以突破原生Kubernetes中所支援的ResourceQuota的硬配額限制，實現更細粒度的資源管控。同時，每個佇列內部又可以指定精確的排序演算法，從而滿足不同組織部門的特定需求，在支援原生Kubernetes排程器能力的基礎上不斷補齊在大資料/AI場景下通常需要的資源佇列的排程管理能力。 為了可以在排程過程中將Pod的排程和資源佇列進行關聯，我們透過擴充套件SchedulingFramework的外掛來實現， 主要外掛如下：

1. QueueSort外掛： 實現Sort擴充套件點，根據Pod所屬Queue的排序演算法進行排序，預設不同佇列之間基於HDRF演算法進行公平排程。

2. QueueCapacityCheck外掛： 實現PreFilter擴充套件點，對Queue的資源使用情況進行檢查和預處理。

3. QueueCapacityReserve外掛： 實現Reserve擴充套件點，對確定使用Queue的資源進行鎖定；實現UnReserve擴充套件點，對排程/繫結失敗但是已經鎖定的Queue資源進行釋放。

4. QueuePreemption外掛： PostFilter擴充套件點，實現資源回收時的搶佔功能。

• 資源佇列繫結

除了資源佇列的CRD外，我們同樣新增資源佇列繫結的CRD，命名QueueBinding。之所以新增QueueBinding是為了使得資源佇列的定義只專注於資源排程層面工作，而不必去關注和Kubernetes的資源本身關聯性，如資源佇列和哪個名稱空間繫結、資源佇列允許提交多少個Pod等。這樣的限制條件本身並不是資源佇列關注的，如果嘗試耦合在資源佇列中定義，將使得資源佇列的控制器程式碼增加相應的變化處理。而透過QueueBinding這樣的CRD，可以使得資源佇列從Kubernetes資源相關性中解耦出來，這部分的限制檢查邏輯則由QueueBinding的控制器來完成。Queue、QueueBinding和Kubernetes資源的關係如下所示：

• 大資料/AI 排程能力擴充套件

基於上述引入的資源佇列，我們在資源層面上進行更加精細完善的控制。但僅有資源管控是不夠的，還需要有面向特定工作負載的排程策略，尤其是原生Kubernetes排程器並不專長的大資料/AI領域。下述章節我們將以大資料/AI領域主流的計算框架Spark和TensorFlow的工作負載為參考，簡要說明在Transwarp Scheduler中實現相應的排程策略。

TensorFlow作業排程

開源專案KubeFlow中的tf-operator解決了TensorFlow作業如何在Kubernetes中進行編排的問題，使得使用者可以方便快捷的在Kubernetes中建立起單機或者分散式的TensorFlow作業執行。但是在Pod排程層面仍然有可能因為資源不足導致部分TensorFlow的Worker Pod被排程，而另一部分處於Pending狀態等待資源。TensorFlow框架本身由於Worker不能都同時啟動執行，將導致整個訓練任務hang住無法執行，因此造成了資源浪費。類似問題實際是因為在Kubernetes中缺乏GangScheduling的排程機制導致，無法實現作業的全部Pod要麼都排程要麼都不排程，從而將資源留給真正可以排程起來的作業。

為了彌補這樣的能力缺失，kube-batch、Volcano、YuniKorn等專案中都對GangScheduling的排程策略進行了實現，並對TensorFlow在Kubernetes的工作負載定義進行了適配，使得可以在應用對應的排程器時排程策略生效。同樣的在scheduler-plugins專案中也對GangScheduling/CoScheduling相關排程功能進行了實現。在Transwarp Scheduler中參考上述幾個專案實現的特點，透過擴充套件QueueSort、PreFilter、Permit、PostBind等外掛來補足了GangScheduling的能力，以滿足TensorFlow型別任務的排程需求。

Spark作業排程

Spark專案同樣有開源的spark-operator來解決其在Kubernetes上的編排問題，之所以Spark可以實現在Kubernetes上的執行，是因為Spark社群從2.3版本開始引入了Kubernetes作為ResourceManager的支援。但無論原生Spark對接Kubernetes的方式還是spark-operator部署Spark作業的方式，都和TensorFlow有相似的資源等待造成資源死鎖或者浪費的問題。比如同時多個Spark作業提交，同一時間啟動的Spark作業的Driver Pod把資源全部用盡，直接導致所有的Spark作業沒有一個可以正常執行完成，造成了資源死鎖問題。

該問題的解決方案類似TensorFlow的GangScheduling的排程策略，必須達成All-Or-Nothing的條件，不過Spark作業本身並沒有要求所有的Executor必須全部啟動才能開始計算，因此只需要保證至少有多少ExecutorPod可以排程時才能執行，否則Driver Pod也不應該被排程，從而做到有效且高效的排程。在Transwarp Scheduler中，透過在實現GangScheduling的基礎上增加一定可變條件，從而滿足Spark的作業排程。

Transwarp Scheduler架構

根據上面的設計概述，Transwarp Scheduler的架構和內部互動如下所示：

整個Transwarp Scheduler由三部分組成：

1.  Scheduler： 基於 Scheduling Framework實現排程器相關的核心功能， 排程策略外掛擴充套件均編譯到Scheduler。

2.  Controller Manager： 新增CRD Queue的控制器和 CRD QueueBinding的控制器。

3.  Webhook： 新增CRD Queue的admission webhook擴充套件點和 CRD QueueBinding的admission webhook擴充套件點。

﹀

未來展望

基 於上述設計和實現，目前Transwarp Scheduler已經可以滿足TDC產品諸多需求，解決 了 原生Kubernetes排程器無法支援的痛點，並會在後續的TDC版本中一同釋出。 除此之外，Transwarp Scheduler將會不斷探索一些更High Level的排程策略，如應用感知、負載感知等排程策略，也會積極採納和吸收社群的意見並將一些通用的設計和實現反饋社群。

雲原生的概念已被提出多年，伴隨著生態的快速發展，其概念也在不斷的被重新定義。星環科技的資料雲平臺產品 TDC 在雲原生的浪潮中也在不斷探索前進，為打造世界級的資料雲平臺產品而不斷前行。