3. Flink 部署模式:Standalone、YARN、Kubernetes 与高可用配置

聊到 Flink 的部署,很多新手第一反应就是「把包丢上去跑就行」。嗯,真这么简单就好了。我在生产环境摸爬滚打这几年,见过太多因为部署模式选错导致的血泪案例。说白了,部署模式选不对,后面运维全是坑。

这一章,我把 Flink 的几种主流部署模式掰开揉碎讲清楚。包括 Standalone、YARN、Kubernetes,还有高可用怎么配。你想想看,一个流批一体任务跑着跑着挂了,JobManager 也挂了,那数据不就断流了吗?所以高可用不是可选项,是必选项。

3.1 Standalone 模式:最纯粹的部署方式

Standalone 模式是 Flink 自带的集群管理方式。不需要依赖 Hadoop YARN 或者 Kubernetes,开箱即用。我个人习惯在开发测试环境用这个模式,简单直接。

架构组成:一个 JobManager + 多个 TaskManager。JobManager 负责调度,TaskManager 负责干活。

启动方式:

# 启动集群
./bin/start-cluster.sh

# 提交任务
./bin/flink run -m localhost:8081 -c com.example.MyJob myjob.jar
注意:Standalone 模式没有资源隔离。TaskManager 之间抢资源是常事。我曾经在一个测试集群上,两个任务互相抢内存,直接把 JVM 搞 OOM 了。所以生产环境慎用。

适用场景:

  • 开发测试环境
  • 小规模集群(节点数 < 10)
  • 对资源隔离要求不高的场景

3.2 YARN 模式:大数据生态的标配

如果你的公司已经上了 Hadoop 生态,那 YARN 模式几乎是首选。Flink on YARN 的好处是资源由 YARN 统一管理,不用自己操心节点分配。

YARN 模式下有两种提交方式:

模式 特点 适用场景
Session 模式 先启动一个常驻集群,多个任务共享 短任务多、任务频繁提交
Per-Job 模式 每个任务启动一个独立集群,用完即销毁 长任务、资源隔离要求高

Per-Job 模式提交命令:

./bin/flink run -m yarn-cluster \
  -yjm 1024 -ytm 2048 \
  -c com.example.MyJob myjob.jar
我的经验:生产环境我强烈推荐 Per-Job 模式。虽然启动慢一点,但每个任务独享资源,一个任务挂了不影响其他任务。Session 模式下,一个任务把 Slot 占满,其他任务就只能干等着。

YARN 模式的优势:

  • 资源统一管理,YARN 负责分配和回收
  • 支持动态扩缩容
  • 与 HDFS、Hive 等组件天然集成

3.3 Kubernetes 模式:云原生的未来

Kubernetes 模式是近几年最火的部署方式。说白了,就是把 Flink 跑在容器里,让 K8s 来管。我最近两年参与的项目,新上的流批一体任务基本都跑在 K8s 上。

Flink on K8s 也有两种模式:

  • Session 模式:先部署一个 Flink 集群到 K8s,然后提交任务
  • Job 模式:每个任务独立部署,任务结束集群自动销毁

Job 模式部署示例:

# 使用 Flink 原生 Kubernetes 集成
./bin/flink run-kubernetes \
  -Dkubernetes.cluster-id=my-flink-job \
  -Dkubernetes.container.image=flink:1.17 \
  -Dkubernetes.jobmanager.cpu=1 \
  -Dkubernetes.taskmanager.cpu=2 \
  -c com.example.MyJob myjob.jar

K8s 模式的核心优势:

  • 容器化部署,环境一致性高
  • 弹性伸缩,根据负载自动调整资源
  • 故障恢复快,Pod 挂了自动重启

不过要注意,K8s 模式对运维要求比较高。你得懂 K8s 的基本概念,比如 Pod、Service、ConfigMap 这些。我曾经帮一个团队排查问题,发现他们的 TaskManager Pod 一直重启,最后原因是资源限制设得太低,容器被 OOMKill 了。

3.4 高可用配置:别让任务挂了没人管

高可用(HA)是生产环境的底线。没有 HA,JobManager 挂了整个集群就瘫痪了。Flink 的 HA 核心思路是:多个 JobManager 节点 + 外部状态存储。

HA 架构图:

Flink 高可用架构 ZooKeeper / Etcd JobManager Leader (Active) JobManager Standby (Passive) TaskManager 1 TaskManager 2 TaskManager 3 Leader 故障时,Standby 通过 ZooKeeper 选举成为新 Leader 作业状态从外部存储恢复,实现无缝切换

配置步骤:

  1. 启动 ZooKeeper 集群(至少 3 节点)
  2. 修改 flink-conf.yaml:
# 启用 HA
high-availability: zookeeper
high-availability.zookeeper.quorum: zk1:2181,zk2:2181,zk3:2181
high-availability.storageDir: hdfs:///flink/ha
high-availability.zookeeper.path.root: /flink
high-availability.cluster-id: /default_cluster

# JobManager 数量
jobmanager.rpc.address: 0.0.0.0
high-availability.jobmanager.port: 6123
  1. 启动多个 JobManager:
# 节点 1
./bin/jobmanager.sh start

# 节点 2
./bin/jobmanager.sh start
避坑指南:我曾经遇到过一个情况,ZooKeeper 集群网络抖动,导致 JobManager 频繁选举。每次选举都会中断当前作业,数据延迟飙升。后来我加了超时配置:high-availability.zookeeper.client.session-timeout: 60000,把超时时间从默认的 30 秒改成 60 秒,问题才解决。

YARN 模式下的 HA 配置:

YARN 模式不需要单独配 ZooKeeper,YARN 自己会管理 JobManager 的故障恢复。你只需要在 flink-conf.yaml 里配好:

yarn.application-attempts: 10
yarn.application-attempt-failures-validity-interval: 600000

这样 JobManager 挂了,YARN 会自动重启一个新的。

3.5 三种模式对比总结

特性 Standalone YARN Kubernetes
资源管理 Flink 自管理 YARN 统一管理 K8s 统一管理
资源隔离 弱 中 强(容器级)
弹性伸缩 手动 自动 自动
运维复杂度 低 中 高
高可用支持 需额外配置 ZK 原生支持 原生支持
适用场景 开发测试 生产环境(Hadoop 生态) 生产环境(云原生)

我的建议:

  • 如果公司已经有 Hadoop 集群,无脑选 YARN 模式
  • 如果公司在推容器化、云原生,选 K8s 模式
  • Standalone 模式只适合测试,别往生产上放