Flink on k8s的使用方式哪些？

知识点图片

Flink on Kubernetes (K8s) 的使用方式可以从两个核心维度来划分：部署架构模式（底层资源交互方式） 和 作业生命周期模式（集群与作业的关系）。

在实际生产中，通常是将这两个维度的某种组合付诸实践。以下是详细分类和介绍：

这是区分度最明显的方式，主要有以下三种：

这是目前最推荐、最符合云原生（GitOps）理念的方式。

原理：在 K8s 中部署 Flink 官方的 Operator（控制器），通过自定义资源（CRD，如 FlinkDeployment）来声明式地管理 Flink 集群和作业。
特点：
- 声明式管理：只需编写 YAML 文件，即可完成作业的提交、停止、更新。
- 自动化运维：支持自动保存 Savepoint、平滑升级版本、自动故障恢复。
- 高级特性：原生支持 Autoscaler（根据流量自动伸缩 TaskManager 并结合 Savepoint 重启）。
适用场景：现代化生产环境、CI/CD 与 GitOps 流程。

Flink 自身具备直接与 K8s API 交互的能力。

原理：用户通过 Flink 客户端（CLI）提交命令，Flink 客户端调用 K8s API 创建 JobManager Pod；JobManager 根据作业资源需求，动态向 K8s 申请并创建 TaskManager Pod。
特点：
- 动态资源分配：按需拉起 TaskManager，作业结束后自动销毁，节省资源。
- 无需额外安装 Operator，只需配置好 K8s RBAC（角色权限）。
适用场景：不想安装 Operator，但希望获得动态资源管理能力的场景。

将 K8s 仅仅作为一个普通的容器运行时，Flink 完全感知不到 K8s 的存在。

原理：运维人员手动编写 K8s 原生的 Deployment、Service、ConfigMap 等资源文件，分别启动固定数量的 JobManager 和 TaskManager。
特点：
- 完全静态：资源无法动态伸缩，必须预先规划好 TaskManager 的副本数。
- 配置繁琐，升级和维护成本高。
适用场景：受限于 K8s权限（无法给 Flink 授予 K8s API 访问权限时）的旧系统或过渡方案。

在上述的每种部署架构下，又可以细分为以下两种运行形态（传统的 Per-Job 模式在 Flink 1.15+ 已被废弃）：

运行机制：为单个作业启动一个专属的 Flink 集群。应用的 main() 方法在 K8s 上的 JobManager Pod 中执行，下载依赖并在集群端解析 JobGraph。
优点：
- 强隔离性：不同作业之间 CPU、内存、网络完全隔离，互不影响。
- 减轻客户端压力：客户端只负责发请求，不再需要消耗大量带宽去下载依赖和生成 JobGraph。
缺点：每次运行小作业都会拉起一套 Pod，有轻微的启动延迟。
适用场景：生产环境中的长期运行任务（Streaming 任务）。

运行机制：预先在 K8s 上拉起一个长期运行的共享 Flink 集群（常驻 JobManager 和若干 TaskManager），多个作业共享这个集群的资源。
优点：
- 启动速度极快：无需等待 Pod 创建即可提交作业。
缺点：
- 资源隔离差：一个作业崩溃（如 OOM）可能导致整个 TaskManager 甚至 JobManager 崩溃，进而影响其他作业。
- 可能会有类加载冲突。
适用场景：开发测试环境、Ad-hoc 交互式查询（如配合 Apache Zeppelin、Flink SQL Gateway）、运行时间极短的批处理小任务。

在实际选型中，主流的最佳实践组合如下：

使用方式	自动化程度	隔离性	复杂度	推荐使用场景
Operator + Application 模式	最高	高	中等（需装Operator）	绝大多数生产环境的最佳选择，适合流处理。
Operator + Session 模式	高	低	中等	测试环境、交互式 Flink SQL 平台。
Native + Application 模式	中	高	低	无法安装 Operator 时的生产替代方案。
Standalone 模式	低	视情况	低（仅需基本K8s知识）	极少数受权限严格限制的遗留系统。

当前业界的绝对主流演进趋势是：直接采用 Flink Kubernetes Operator，并在该框架下根据业务是流作业还是交互式作业，分别使用 Application CR 或 Session CR。

右滑查看面试常问

播面