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 的原生融合

• 小結

Apache Flink Standalone Cluster

如圖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的資源調度協議，現Blink的分支實現架構下圖所示，用戶使用文檔見Flink on K8S，merge到主幹Master上的工做正在進行中

小結

部署管理、資源調度是大數據處理系統的底層基石，經過FLIP-6的抽象分層和重構，Apache Flink構建了牢固的基礎，能夠「原生」地運行於各大資源調度系統（YARN/Kubernetes/Mesos）上，支撐起更大規模更高併發的計算，高效地利用集羣資源，爲後續的不斷髮展強大提供了可靠的保障。 相關功能的優化改進依然在繼續，如Resource Profile配置資源的難度使一些開發者望而生畏，而且嚴重下降了Flink的易用性，咱們在嘗試實現資源和併發配置的Auto Config/Scaling等功能來解決此類問題；「Serverless」架構在迅速發展，期待Flink與Kubernetes的融合成爲雲原生的強大計算引擎(類FaaS)，爲用戶節省資源，帶來更大的價值。

更多資訊請訪問 Apache Flink 中文社區網站