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 中文社区网站