1. Flink Standalone Cluster
（1）Standalone Cluster：在多job任务多租户的quota管理和隔离方面存在问题，运维管理难度大
（2）Flink Cluster on Kubernetes 的部署模式：只利用Flink cluster和K8s deployment、service等基础能力，简化了cluster的部署流程；可通过每个job一个cluster的方式运行来解决隔离问题，但对运维管理和资源利用率有较大挑战
（3）Helm chart方式进一步简化on k8s的部署
（4）Flink K8s Operator：通过遵循K8s的CRD+Operator范式，可以更原生的利用K8s的能力来管理Flink job的生命周期等，也可以通过Operator监视任务运行情况，进行一定的cluster弹性伸缩
总结：
-
无论 Operator、Helm Chart 或者是直接使用 Kubectl Yaml 的方式，Flink 都感知不到 K8s 的存在。
-
目前主要使用静态的资源分配。需要提前确认好需要多少个 TaskManager，如果 Job 的并发需要做一些调整，TaskManager 的资源情况必须相应的跟上，否则任务无法正常执行。
-
用户需要对一些 Container、Operator 或者 K8s 有一些最基本的认识，这样才能保证顺利将 Flink 运行到 K8s 之上。
-
对于批处理任务，或者想在一个 Session 里提交多个任务不太友好。无法实时申请资源和释放资源。因为 TaskManager 的资源是固定的，批处理任务可能会分多个阶段去运行，需要去实时地申请资源、释放资源，当前也无法实现。如果需要在一个 Session 里跑多个 Job 并且陆续运行结束当前也无法实现。这时如果维持一个比较大的 Session Cluster，可能会资源浪费。但如果维持的 Session Cluster 比较小，可能会导致 Job 跑得慢或者是跑不起来。
基于这几点，Flink社区推进了一个 Native 的集成方案，这个 Native 类似于 Yarn 这种原生的集成，就是让 Flink 原生的感知到下层 Cluster 的存在。
2. Flink Native Integration的新架构
为什么叫 Native 方式？包括如下几个含义。
-
资源申请方式：Flink 的 Client 内置了一个 K8s Client，可以借助 K8s Client 去创建 JobManager，当 Job 提交之后，如果对资源有需求，JobManager 会向 Flink 自己的 ResourceManager 去申请资源。这个时候 Flink 的 ResourceManager 会直接跟 K8s 的 API Server 通信，将这些请求资源直接下发给 K8s Cluster，告诉它需要多少个 TaskManger，每个 TaskManager 多大。当任务运行完之后，它也会告诉 K8s Cluster 释放没有使用的资源。相当于 Flink 用很原生的方式了解到 K8s Cluster 的存在，并知晓何时申请资源，何时释放资源。
-
Native 是相对于 Flink 而言的，借助 Flink 的命令就可以达到自治的一个状态，不需要引入外部工具就可以通过 Flink 完成任务在 K8s 上的运行。
（1）首先，对Flink自身架构进行了重构，实现对不同集群管理系统的适配
（2）在新架构基础上，实现了Native on K8s的新模式
（3）Flink K8s Operator的整合：资源的动态管理交由Flink任务自身，Operator负责任务的管理控制，相互协作，实现运行模式和管理全面Native on K8s
