Flink on K8s 概述

总结下来就几点：

1、Native模式比Standalone模式好

Standalone模式需要提前确认好每个任务需要使用的资源，并在配置文件里面配置，每一个任务都是固定资源大小，申请多了浪费，少了怕出问题。

Native模式不需要预先确定需要使用的资源数量，系统会实时根据任务需要自动去k8s集群申请能申请到的资源。

2、Application和Session模式各有优劣，不同情况使用不同模式

Application模式资源隔离性强，每个人物都是单独的集群，不会出现并发问题。每个任务都需要启动一个集群，会先启动JobManager，然后启动TaskManager，效率会比较低。适合流处理任务

对比yarn环境下的perjob提交任务速度快很多，大约是十几秒就能提交执行；yarn环境下提交任务需要一分多钟。

Session模式需要提前创建好集群，所有任务共享集群资源，并发下可能会有问题。共用集群，只需要启动TaskManager，效率高。适合批处理任务

operator模式的利弊

还有一种方式叫operator模式，这种方式的优点是有一个开源服务，这个服务来帮你管理yml配置文件，你不需要自己去管理各种资源的配置。但是需要单独启动这个服务，然后调用这个服务的api去管理yml文件的配置功能。

优点： 

管理 Flink 集群更加便捷

flink-operator 更便于我们管理 Flink 集群，我们不需要针对不同的 Flink 集群维护 Kubenretes 底层各种资源的部署脚本，唯一需要的，就是 FlinkCluster 的一个自定义资源的描述文件。用户只需要在该文件中声明期望的 Flink 集群配置，flink-operator 会自动完成 Flink 集群的创建和维护工作。如果创建 Per Job 集群，也只需要在该 yaml 中声明 Job 的属性，如 Job 名称，Jar 包路径即可。通过 flink-operator，上文提到的四种 Flink 运行模式，分别对应一个 yaml 文件即可，非常方便。

声明式

        通过执行脚本命令式的创建 Flink 集群各个底层资源，需要用户保证资源是否依次创建成功，往往伴随着辅助的检查脚本。借助 flink operator 的控制器模式，用户只需声明所期望的 Flink 集群的状态，剩下的工作全部由 Flink operator 来保证。在 Flink 集群运行的过程中，如果出现资源异常，如 JobMaster 意外停止甚至被删除，Flink operator 都会重建这些资源，自动的修复 Flink 集群。

自定义保存点

用户可以指定 autoSavePointSeconds 和保存路径，Flink operator 会自动为用户定期保存快照。

自动恢复

流式任务往往是长期运行的，甚至 2-3 年不停止都是常见的。在任务执行的过程中，可能会有各种各样的原因导致任务失败。用户可以指定任务重启策略，当指定为 FromSavePointOnFailure，Flink operator 自动从最近的保存点重新执行任务。

Ingress 集成

用户可以定义 Ingress 资源，flink operator 将会自动创建 Ingress 资源。云厂商托管的 Kubernetes 集群一般都有 Ingress 控制器，否则需要用户自行实现 Ingress controller。

Prometheus 集成

通过在 Flink 集群的 yaml 文件里指定 metric exporter 和 metric port，可以与 Kubernetes 集群中的 Prometheus 进行集成。

缺点：

需要单独启动一个服务

它的很多优点基于api的方式也能实现

3、启动方式

Standalone模式：定义好配置文件，然后通过kubectl命令去创建集群，目前没找到api方式创建

Nat