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

你可能感兴趣的:(flink)