一、Flink部署模式简介

Apache Flink在1.14版本之前,支持4种类型的Resouce Providers,也称资源提供者,在本文中称之为部署模式,它们分别是Standalone、 Kubernetes、YARN和Mesos,但在1.14版本及后续版本中减少为3种,分别是Standalone、 Kubernetes和YARN,少了Mesos。有关Flink Resouce Providers的详细介绍,大家可以到Apache Flink官方网站查阅,官方网址为https://nightlies.apache.org/flink/flink-docs-release-1.17/docs/deployment/resource-providers/standalone/overview/。

目前在实际应用中,绝大部分公司主要使用Standalone和YARN模式,尤其是YARN模式居多,使用Kubernetes模式的比较少。

1、Standalone模式

Standalone模式直接将Flink集群(这里的集群是指JobManager和TaskManager的组合)部署在虚拟机或物理机上,也就是JobManager和TaskManager是运行在宿主机上的。Standalone模式的主要特点是Flink集群的资源规模在启动时是确定的,也就是需要先定义好JobManager和TaskManager的CPU、内存以及每个TaskManager提供的Slot槽位等参数,在worker配置文件里定义好TaskManager的实例列表,后期如果需要扩容,则需要停止运行中的集群,重新调整资源和TaskManager的实例数量后再启动,这会有一个停机维护的过程。

在 Standalone模式下,提交到Flink集群的作业会竞争集群的资源,或者是共享集群的资源,当集群的可用Slot数量不足以满足新的作业运行要求时,新的作业会被挂起。此外,性能差的作业,或运行异常的作业有可能会拖垮整个集群,导致同一个集群里的其他作业跟着挂掉。所以,Standalone模式通常用在开发和测试环境,生产环境上很少使用这种模式。

2、YARN模式

Flink作为大数据流处理计算框架,虽然本身支持Standalone模式,无需其他框架也可以运行,但资源调度并不是它的强项,所以,大多数场景下需要专业的框架做资源调度,比如说YARN或Kubernetes。在实际应用中,由于Hadoop的普遍使用,所以YARN是当下采用得最多的。整体来看,在YARN上部署Flink作业的过程是:客户端把Flink作业提交到ResourceManager,在资源满足需求的情况下,ResourceManager会在选定的NodeManager上创建Container容器,然后在这些容器上部署JobManager和TaskManger的实例,从而启动Flink集群。Flink会根据作业所需要的slot数量动态创建TaskkManger,如果作业运行完毕,相应的JobManager和TaskManger占用的YARN容器资源也会一同释放。

Flink在YARN模式下,分别支持Apllication、Session和Per-Job三种运行模式,其中Per-Job运行模式是YARN特有的,但从1.15版本开始被废弃。Apllication和Session这两种运行模式在Kubernetes里也支持,在后续的文章中会具体讲解。

 

3、Kubernetes模式

在Kubernetes模式下,Flink所需的计算资源由K8s容器平台提供,以容器Pod为单元进行资源的管理和调度,也就是说,Flink集群的JobManager和TaskManager是运行在Pod里,这与YARN模式下运行在Container里运行类似。

Kubernetes模式下,Flink又细分为Native Kubernetes和Flink Kubernetes Operator两种模式,在实际应用中,比较少使用Native Kubernetes,而是使用Flink Kubernetes Operator居多。此外,Flink Kubernetes Operator也是Apache Flink官方提供和推荐的,它可以极大地简化将Flink应用部署到K8s上的配置。有关Kubernetes Operator的相关说明,大家可以到它的官网查看 https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/。

本文讲解的是Flink Kubernetes Operator模式,因为随着Kubernetes的普遍应用,越来越多的企业已经体会到基于容器所带来的优势和便利,这也是云原生现在很火的原因。大数据主要解决的是数据存储和计算的问题,计算资源的隔离和弹性供给是计算任务得以稳定高效运行的关键,传统的存算一体的部署方式,将各种组件都安装在一台物理机或虚拟机上,组件之间的运行难以避免会出现CPU和内存资源的竞争。而对于容器化和Kubernetes而言,它的天然优势就是解决计算资源的供给问题,所以大数据与Kubernetes的结合,或者说大数据容器化(BigData On K8s),是未来大数据新的应用方式。

二、Flink Kubernetes Operator是什么

关于Flink Kubernetes Operator是什么,Flink官方已经给出了清晰定义,在此我引用它的定义,原文大家可以到https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-release-1.4/ 查阅。

Flink Kubernetes Operator扩展了Kubernetes API,能够管理和操作Flink部署,具有以下特点:

1是部署和监控Flink Application和Session模式的FlinkDeployment(这里的FlinkDeployment是Flink集群在K8s上的资源类型)

2是升级、挂起和删除FlinkDeployment

3是提供完整的日志记录和运行指标监控集成

4是能实现Flink 应用的灵活部署,与Kubernetes工具原生集成

综合而言,Flink Kubernetes Operator作为一个Kubernetes的Control plane控制平面,它管理Flink应用程序的完整部署生命周期。尽管Flink也提供Native原生的方式在k8s上部署Flink应用程序,但使用自定义资源CRD和Operator模式才是官方主推的Flink On K8s部署方式。

三、Flink Kubernetes Operator详解

1、Flink Kubernetes Operator架构

Flink Kubernetes Operator的架构图如下所示

就如前面所述, Flink Kubernetes Operator作为一个控制平面,管理Flink应用程序的完整部署生命周期。在实际的生产环境应用中,我们通常将Flink Kubernetes Operator部署在指定的K8s NameSpace中(这个NameSpace的名字通常是flink),然后在一个或多个托管名称空间中管理Flink应用的部署。

Flink Kubernetes Operator会创建和监控2种自定义资源, 它们分别是FlinkDeployment和FlinkSessionJob, 这2个自定义资源是一个集群范围的资源, 在使用之前需要在API Server上完成注册声明, 这个在安装Flink Kubernetes Operator时会自动完成。

Flink Kubernetes Operator运行态结构见红底部分, 它运行的时候会启动2个Container,这2个Container是运行在同一个Pod里,一个是flink-operator,另一个是flink-webhook,这个Pod由ReplicaSet和Deployment定义它的规格,例如JobManager和TaskManager的副本数量和资源配额等。此外, 还有Service和ConfigMap, 其中Service是用于提供flink-webhook接口服务的, ConfigMap是用于存储Flink默认的配置信息和operator自身的配置信息的.

用户要提交Flink作业到K8s上运行, 他要做的就是开发好Flink作业程序, 编写好FlinkDeployment Yaml文件,然后用kubectl提交到K8s,之后Flink Kubernetes Operator会根据Yaml的定义把这个Flink集群创建出来,  例如Yaml定义JobManager的数量为2,则会创建2个JobManager,此外,构成这个集群相应的Pod、Deployment、Service、ConfigMap和Ingress资源也都会自动创建出来。

2、Flink Kubernetes Operator的控制循环

Flink Kubernetes Operator会持续跟踪与FlinkDeployment和FlinkSessionJob自定义资源相关的集群事件。当Flink Kubernetes Operator接收到新的资源更新时,它将采取行动将Flink集群调整到所需的状态,这个过程称为reconcile,是一个持续进行的循环。

Control loop 

3、Flink Webhook

Webhook是一个HTTP回调,通过特定条件或事件触发HTTP POST请求发送到Webhook服务端,服务端根据请求数据进行相应的处理。

在Kubernetes中,Webhook通常是用于实现动态准入控制的,它的功能主要是接受API Server的认证请求,然后调用不同的认证服务进行认证。

Flink Webhook就是用于实现准入控制,分为两种:一是验证性质的准入Webhook(Validating Admission Webhook),对应的是/validate接口,二是修改性质的准入 Webhook(Mutating Admission Webhook),对应的是/mutate接口。

Flink Webhook 

以Flink Webhook为例,在FlinkDeployment资源持久化到ETCD之前API Server需要调用/mutate接口对该资源规格描述进行修改,比如增加默认配置信息、init Container或者sidecar Container;此外,在将FlinkDeployment资源持久化到ETCD之前API Server也需要调用/validate接口校验yaml文件,如果yaml文件定义的信息不准确则拒绝创建资源并给出相应信息。

Flink Webhook默认使用TLS协议进行通信,也就是HTTPS,所以在使用Flink Kubernetes Operator时,需要先安装cert-manager组件,由它提供证书服务。

在下一篇文章中,我们再来讲解Flink Kubernetes Operator的安装和使用。

更多有关Flink Kubernetes Operator的视频和学习资料,可以到bigdataonk8s观看和获取。

 

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐