Apache Flink是当下主流了流式计算引擎，在企业的实时数仓、实时BI、数据湖、智能推荐和风险风控等场景中有广泛的应用。Apache Flink支持多种Resource Providers，也就是可以在多种资源平台上运行，本系列文章以当前热门的容器平台Kubernetes作为Flink的Resource Proivder，全面讲解如何在Kubernetes平台上以Flink Kubernetes Operator的方式运行Flink作业应用。

一、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模式通常用在开发和测试环境，生产环境上很少使用这种模式。

Flink 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里也支持，在后续的文章中会具体讲解。

Flink YARN 模式

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模式

综合而言，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 Oeperator架构图

就如前面所述, 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，是一个持续进行的循环。

Ctroller 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组件，由它提供证书服务。

原文阅读