播面

Flink on Kubernetes (K8s) 的使用方式可以从两个核心维度来划分：集群运行架构模式（Runtime Mode） 和 部署与管理实现方式（Management Approach）。

理解这两个维度是掌握 Flink on K8s 的关键。

维度一：按集群运行架构模式划分（Runtime Mode）

这决定了 Flink 任务的生命周期、资源隔离程度以及 JobManager 的职责。

1. Application 模式（强烈推荐）

• 原理：为每一个提交的 Flink 任务启动一个专属的集群。用户代码的 main() 方法直接在 K8s 上的 JobManager Pod 中运行，而不是在客户端运行。
• 优点：
  • 极佳的资源隔离：作业之间互不影响。
  • 减轻客户端压力：客户端不需要下载依赖、生成 JobGraph，节省了客户端网络带宽和计算资源。
  • 云原生友好：任务结束，集群随之销毁，生命周期与 K8s Pod 完全对齐。
• 适用场景：生产环境的长期流处理作业首选。

2. Session 模式（会话模式）

• 原理：预先在 K8s 上启动一个长期运行的 Flink 集群（包含共享的 JobManager），多个作业可以同时提交到这个集群中共享资源。TaskManager 可以根据作业需求动态申请或静态预留。
• 优点：
  • 作业提交速度快（不需要每次都拉起新的 JobManager Pod）。
  • 适合资源占用极小、运行时间短的作业。
• 缺点：
  • 缺乏资源隔离：一个作业崩溃（如 OOM）可能会导致整个集群（JobManager）宕机，波及其他作业。
• 适用场景：开发测试环境、Ad-hoc 临时查询、高频但轻量的短时间批处理作业。

3. Per-Job 模式（单作业模式）

• 原理：每个作业独立一个集群，但 main() 方法在客户端运行，生成 JobGraph 后再提交给 K8s 上的 JobManager。
• 现状：已过时并被弃用（Deprecated）。自 Flink 1.15 起逐步被废弃，社区推荐全面转向 Application 模式。

维度二：按部署与管理实现方式划分（Management Approach）

这决定了你如何与 K8s 交互、如何运维集群以及资源是如何申请的。

1. Flink Kubernetes Operator（官方推荐，现代主流标准）

• 介绍：Apache Flink 官方推出的 Kubernetes Operator（基于 CRD 控制器机制）。
• 使用方式：通过编写声明式的 YAML 文件（定义 FlinkDeployment 或 FlinkSessionJob 资源）来管理 Flink。
• 核心特性：
  • 真正的 GitOps：通过声明式 API 管理 Flink 生命周期。
  • 自动升级与状态管理：原生支持带 Savepoint 的无缝升级，版本回滚。
  • 自动扩缩容（Autoscaling）：支持基于 Flink 运行指标的动态伸缩。
• 适用场景：现代企业级生产环境的最佳实践。

2. Native Kubernetes（原生集成模式）

• 介绍：无需部署 Operator，利用 Flink 内置的 K8s 客户端，通过 flink-cli 命令行工具直接与 K8s 的 API Server 交互。
• 使用方式：
  bash

  ./bin/flink run-application -t kubernetes-application \
    -Dkubernetes.cluster-id=my-first-flink-cluster \
    -Dkubernetes.container.image=custom-flink-image \
    local:///opt/flink/usrlib/my-flink-job.jar

• 原理：Flink 的 JobManager 直接充当 K8s 的客户端，当需要资源时，JobManager 会主动调用 K8s API 动态创建 TaskManager Pod；作业空闲时，会自动销毁 TaskManager Pod。
• 适用场景：已有一套基于命令行的调度系统（如 Airflow/DolphinScheduler），且不希望引入额外 Operator 组件的团队。

3. Standalone on Kubernetes（传统 YAML 模式）

• 介绍：将 K8s 仅作为纯粹的容器编排工具（类似于当作虚拟机来用），Flink 完全感知不到自己运行在 K8s 上。
• 使用方式：纯手工或通过 Helm 编写原生 K8s 资源定义，配置 JobManager 的 Deployment、TaskManager 的 Deployment，以及打通两者的 Service。
• 缺点：
  • 无法实现 TaskManager 的动态申请与释放（只能固定副本数）。
  • 运维繁琐，扩缩容和故障恢复能力弱。
• 适用场景：
  • 企业安全策略极度严格，绝对不允许 Pod 拥有访问 K8s API Server 的权限（RBAC）。
  • 学习或测试 K8s 部署基础。

总结与选型建议