Deploy Apache Flink Natively on YARN/Kubernetes

作者：任春德

Apache Flink作為下一代大資料計算引擎，在迅速發展強大中，其内部架構也在不斷優化重構，以适應更多運作時環境和更大計算規模，

Flink Improvement Proposals-6

重新設計了在各叢集管理系統(Standalone/YARN/Kubernetes等)上資源排程的統一架構，本文将介紹資源排程的架構發展及其清晰分層等設計特點，YARN上per-Job和session兩種模式的實作，以及正在讨論開發的與K8S雲原生融合的詳細設計。

本文内容如下：

• Apache Flink Standalone Cluster
• Apache Flink 與 YARN 的原生融合
• Apache Flink 與 K8S 的原生融合
• 小結

如圖1，Flink的Standalone叢集部署是主從架構，其中主JobManager(簡稱JM)負責Job的計算單元Task排程，TaskManager(簡稱TM)向JobManager彙報并負責在其内部用線程執行Task。

之是以是Standalone，是因為其不依賴其他底層資源排程系統，直接部署啟動在各自的裸機器節點上，雖然可以用一些自動化運維工具友善地部署和管理，但是存在以下幾個問題：

• 隔離：多Job運作在一個叢集，可能同一TM上執行不同Job的Task，其線程所用資源(cpu/mem)無法控制，互相影響，甚至一個Task造成整個TM的Out Of Memory，使其之上的Job都受影響；多個Job的排程也在同一個JM中，同樣存在被有問題Job影響的問題。
• 多租戶的資源用量(quota)管理：無法控制使用者的Job資源使用總量，缺乏租戶間的資源協調管理。
• 叢集的可用性：雖然JM可以部署有Standby，支援High Available，但JM、TM程序缺乏被看護，難免因以上隔離等問題造成過多程序宕掉，整個叢集不可用。
• 叢集的可運維：版本更新，擴縮容等都需要複雜的運維操作。

為了解決以上問題，需要将Flink跑在流行成熟的資源排程系統上，如YARN、Kubernetes、Mesos，如何實作呢？

Flink 與 YARN 的原生融合

Apache Flink Standalone Cluster on YARN

簡單有效的一種部署方式是利用YARN自身支援的特性，将Flink Standalone部署到

YARN

叢集上，如圖2(Apache Flink Standalone Cluster ON YARN)，

• 多個Job可以相應地起多個YARN Application，每個app是一個standalone cluster，各自獨立運作，而且依靠YARN本身支援的cgroups等隔離手段，避免了多任務間的互相影響，隔離問題迎刃而解。
• 不同使用者的App也可以運作在不同的YARN排程隊列中，通過queue quota管理能力解決多租戶的問題。
• 同時可以利用YARN對App程序的重新開機重試再排程的政策，使Flink Standalone Cluster高可用。
• 簡單的參數、配置檔案修改，通過YARN的distributed cache分發Flink jar，就可以友善的更新和擴縮容。

雖然解決了以上問題，但是每個(少量)Job起一個Standalone Cluster，難以達到高效的資源利用，因為：

• Cluster的規模(多少個TM)是在啟動YARN App時參數靜态指定的，Flink自身的編譯優化使其較難在運作前預估資源的需求，那就難以合理化TM數量，多了資源浪費，少了影響Job執行速度甚至無法運作。
• 每個TM擁有的資源大小也是參數靜态指定，同樣難以預估實際需要，不能針對不同的Task資源需求來動态申請不同大小的TM，隻能設定相同規格大小的TM，那就難以恰好放置整數個Task，剩餘的部分資源浪費。
• App的啟動(1.Submit YARN App)和Flink Job的送出(7.Submit Job)需要2階段完成，會使每個任務的送出效率低，造成叢集的資源流轉率也會降低。

大規模YARN叢集中Flink Job越多，資源浪費的會更可觀，成本損失越大，而且不隻是on YARN存在以上問題，Standalone直接運作于其他資源排程系統之上，也是有相同問題，是以阿裡巴巴實時計算率先在YARN實際生産經驗上改進了Flink的資源利用模型，後續與社群讨論設計實作了一套通用的架構，适用于不同的資源排程系統。

FLIP-6 - Deployment and Process Model

FLIP-6

全面記錄了此次部署架構的重構，新的子產品如圖3。類似MapReduce-1架構向YARN+MapReduce-2的更新，将資源排程與Job計算邏輯單元(Task)的排程分成2層，使兩個子產品（系統）——ResourceManager(RM)和JobManager(JM)各司其職，與底層資源排程系統的耦合降低（隻需實作不同plugable的ResourceManager即可），減少邏輯複雜度降低開發維護難度，優化JM實作資源按Task所需申請，解決了Standalone on YARN/K8S的資源使用率低的問題，同時還有利于叢集和Job規模的擴充。

• Dispatcher: 負責與Client通信接收Job的送出，生成JobManager，生命周期可跨Job。
• ResourceManager: 對接不同資源排程系統，實作資源的排程（申請/釋放），管理Container/TaskManager，同樣生命周期可跨Job。
• JobManager: 每個Job一個執行個體，負責Job的計算邏輯的排程執行。
• TaskManager: 向RM注冊彙報資源情況，從JM接收Task執行并彙報狀态。

Apache Flink與YARN的原生融合

根據以上架構，Flink on YARN實作了2種不同的部署運作模式Per-Job和Session（使用者使用文檔

Flink on Yarn

）。

Per-Job

Per-Job即一個Flink Job與其YARN Application(App)生命周期綁定，執行過程如圖4，在送出YARN App時同時将Flink Job的file/jars通過

YARN Distributed Cache

分發，一次性完成送出，而且JM是根據JobGraph産生的Task的資源實際需求來向RM申請slot執行，Flink RM再動态的申請/釋放YARN的Container。完美(?)解決了之前的所有問題，既利用了YARN的隔離又有高效的資源利用。

Session

Per-Job完美？No，還是存在局限，YARN App的送出時資源申請和啟動TM的時間較長(秒級)，尤其在互動式分析短查詢等場景上，Job計算邏輯執行時間很短，那麼App的啟動時間占比大就嚴重影響了端到端的使用者體驗，缺少了Standalone模式上Job送出快的優點。但FLIP-6架構的威力，還是能輕松化解這個問題，如圖5，通過預啟動的YARN App來跑一個Flink Session（Master和多個TM已啟動，類似Standalone可運作多個Job），再送出執行Job，這些Job就可以很快利用已有的資源來執行計算。

Blink

分支與Master具體實作有點不同（是否預起TM），後續會合并統一，并且繼續開發實作Session的資源彈性——按需自動擴縮TM數量，這點是standalone無法實作的。

Resource Profile

前面是架構上的變化，而要實作資源按需申請，需要有協定API，這就是Resource Profile，可以描述單個算子(Operator)的CPU & Memory等的資源用量，進而RM根據這些資源請求來向底層資源管理系統申請Container來執行TM，詳細的使用文檔見

Task slots and resources

。

Flink 與 Kubernetes 的原生融合

最近幾年，

Kubernetes

的發展迅猛，已然成為了雲時代的原生作業系統，下一代的大資料計算引擎Apache Flink的部署與其融合，是否可以開辟大資料計算的新大陸？

Apache Flink Standalone Cluster on Kubernetes

依靠K8S自身支援Service部署的強大能力，Flink Standalone Cluster可以通過簡單的

K8S: Deployment & Service

或

Flink Helm chart

很容易的部署到K8S叢集上，但同樣有類似Standalone on YARN的資源使用率低等問題，是以還是需要“原生融合”。

Apache Flink 和 Kubernetes 的原生融合

Flink與K8S的“原生融合”，主要是在FLIP-6架構上實作K8SResourceManager來對接Kubernetes的資源排程協定，現

的分支實作架構下圖所示，使用者使用文檔見

Flink on K8S

，merge到主幹Master上的工作正在進行中

部署管理、資源排程是大資料處理系統的底層基石，通過FLIP-6的抽象分層和重構，Apache Flink建構了牢固的基礎，可以“原生”地運作于各大資源排程系統（YARN/Kubernetes/Mesos）上，支撐起更大規模更高并發的計算，高效地利用叢集資源，為後續的不斷發展強大提供了可靠的保障。

相關功能的優化改進依然在繼續，如Resource Profile配置資源的難度使一些開發者望而生畏，并且嚴重降低了Flink的易用性，我們在嘗試實作資源和并發配置的Auto Config/Scaling等功能來解決此類問題；“Serverless”架構在迅速發展，期待Flink與Kubernetes的融合成為雲原生的強大計算引擎(類FaaS)，為使用者節省資源，帶來更大的價值。

更多資訊請通路

Apache Flink 中文社群網站