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

小结

部署管理、资源调度是大数据处理系统的底层基石，通过FLIP-6的抽象分层和重构，Apache Flink构建了牢固的基础，可以“原生”地运行于各大资源调度系统（YARN/Kubernetes/Mesos）上，支撑起更大规模更高并发的计算，高效地利用集群资源，为后续的不断发展强大提供了可靠的保障。

相关功能的优化改进依然在继续，如Resource Profile配置资源的难度使一些开发者望而生畏，并且严重降低了Flink的易用性，我们在尝试实现资源和并发配置的Auto Config/Scaling等功能来解决此类问题；“Serverless”架构在迅速发展，期待Flink与Kubernetes的融合成为云原生的强大计算引擎(类FaaS)，为用户节省资源，带来更大的价值。