Apache Flink on K8s：四种运行模式，我该选择哪种？

1. 前言

Apache Flink 是一个分布式流处理引擎，它提供了丰富且易用的API来处理有状态的流处理应用，并且在支持容错的前提下，高效、大规模的运行此类应用。通过支持事件时间(event-time)、计算状态(state)以及恰好一次(exactly-once)的容错保证，Flink迅速被很多公司采纳，成为了新一代的流计算处理引擎。

2020 年 2 月 11 日，社区发布了 Flink 1.10.0 版本, 该版本对性能和稳定性做了很大的提升，同时引入了 native Kubernetes 的特性。对于 Flink 的下一个稳定版本，社区在 2020 年 4 月底冻结新特性的合入，预计在 2020 年 5 月中旬会推出 Flink 1.11，在新版本中将重点引入新特性，以扩容 Flink 的使用场景。

1.1 Flink 为什么选择 Kubernetes

Kubernetes 项目源自 Google 内部 Borg 项目，基于 Borg 多年来的优秀实践和其超前的设计理念，并凭借众多豪门、大厂的背书，时至今日，Kubernetes 已经成长为容器管理领域的事实标准。在大数据及相关领域，包括 Spark，Hive，Airflow，Kafka 等众多知名产品正在迁往 Kubernetes，Apache Flink 也是其中一员。

Flink 选择 Kubernetes 作为其底层资源管理平台，原因包括两个方面：

1）Flink 特性：流式服务一般是常驻进程，经常用于电信网质量监控、商业数据即席分析、实时风控和实时推荐等对稳定性要求比较高的场景；

2）Kubernetes 优势：为在线业务提供了更好的发布、管理机制，并保证其稳定运行，同时 Kubernetes 具有很好的生态优势，能很方便的和各种运维工具集成，如 prometheus 监控，主流的日志采集工具等；同时 K8S 在资源弹性方面提供了很好的扩缩容机制，很大程度上提高了资源利用率。

1.2 Flink on Kubernetes 的发展历史

在 Flink 的早期发行版 1.2 中，已经引入了 Flink Session 集群模式，用户得以将 Flink 集群部署在 Kubernetes 集群之上。

随着 Flink 的逐渐普及，越来越多的 Flink 任务被提交在用户的集群中，用户发现在 session 模式下，任务之间会互相影响，隔离性比较差，因此在 Flink 1.6 版本中，推出了 Per Job 模式，单个任务独占一个 Flink 集群，很大的程度上提高了任务的稳定性。

在满足了稳定性之后，用户觉得这两种模式，没有做到资源按需创建，往往需要凭用户经验来事先指定 Flink 集群的规格，在这样的背景之下，native session 模式应用而生，在 Flink 1.10 版本进入 Beta 阶段，我们增加了 native per job 模式，在资源按需申请的基础上，提高了应用之间的隔离性。

本文根据 Flink 在 Kubernetes 集群上的运行模式的趋势，依次分析了这些模式的特点，并在最后介绍了 Flink operator 方案及其优势。

2. Flink运行模式

本文首先分析了 Apache Flink 1.10 在 Kubernetes 集群上已经GA（生产可用）的两种部署模式，然后分析了处于 Beta 版本的 native session 部署模式和即将在 Flink 1.11 发布的 native per-job 部署模式，最后根据这些部署模式的利弊，介绍了当前比较 native kubernetes 的部署方式，flink-operator。

我们正在使用的 Flink 版本已经很好的支持了 native session 和 native per-job 两种模式，在 flink-operator 中，我们也对这两种模式也做了支持。

接下来将按照以下顺序分析了 Flink 的运行模式，读者可以结合自身的业务场景，考量适合的 Flink 运行模式。

• Flink session 模式
• Flink per-job 模式
• Flink native session 模式
• Flink native per-job 模式

这四种部署模式的优缺点对比，可以用如下表格来概括，更多的内容，请参考接下来的详细描述。