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
适用场景:
- 开发测试环境
- 小规模集群(节点数 < 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
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 架构图:
配置步骤:
- 启动 ZooKeeper 集群(至少 3 节点)
- 修改 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
- 启动多个 JobManager:
# 节点 1
./bin/jobmanager.sh start
# 节点 2
./bin/jobmanager.sh start
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 模式只适合测试,别往生产上放