Flink Kubernetes部署模式：云原生流处理的实战指南

itlodge

85人浏览 · 2026-07-05 10:19:51

itlodge · 2026-07-05 10:19:51 发布

引子

三年前，老张运维着一套基于 YARN 的 Flink 集群。2000+ 节点的 Hadoop 集群，光是硬件折旧每月就要吃掉公司 10 万+。更让他头疼的是，每次大促前扩容，他和团队都要在机房熬两三个通宵——YARN 的调度粒度太粗了，申请下来的资源经常浪费，真正需要的资源申请不到。

“就不能换个方式吗？” 老张在一次技术分享会上问。

“试试 Kubernetes 呗。” 一个在阿里工作过的工程师笑着说，“我们用 K8s 跑的 Flink，扩容通知一声就行，资源利用率提升了 40%。”

"真的假的？"老张半信半疑。

"不只是真的，"工程师收起笑容，“而且这已经是业界的默认选择了。”

这就是我们今天的主题：Flink Kubernetes 部署模式。

不是技术不够先进，是你的基础设施已经落后了。

关于Flink k8s部署的三种误解

误解一：“Kubernetes 只是容器编排，跟 Flink 关系不大。”

这是最危险的错误。

Kubernetes 不只是容器编排，它已经变成了现代云平台的事实操作系统。Gartner 调研显示，到 2025 年，超过 85% 的企业将在生产中运行容器化应用。你用的不是"容器编排"，你用的是新一代的运行时。

而且，Flink 从 1.9 版本开始原生支持 Kubernetes。这不是生搬硬套，是官方的第一等公民。

致命反例： 某电商公司坚持用 YARN 部署 Flink，结果每次大促资源申请排队 2 小时起步，业务方投诉不断。转了 K8s 后，自动伸缩让资源秒到，业务方笑开了花。

误解二：“Flink on K8s 和 Standalone 差不多，就是换个地方跑。”

错了。Kubernetes 为 Flink 提供的是全新的可能性。

Standalone 模式下，你得自己管理节点、监控、故障恢复。而 Kubernetes 天然提供：

自动扩缩容
服务发现与负载均衡
滚动升级
故障自愈

致命反例： 某金融公司用 Standalone 部署 Flink，TaskManager 挂了需要人工介入恢复，平均恢复时间 15 分钟。转到 K8s 后，Pod 失败自动重启，恢复时间从分钟降到了秒级。

误解三：“直接用 YAML 部署就行，不需要 Flink 的 Native 集成。”

这是浅尝辄止。

如果只是把 Flink 二进制包放进 Docker 镜像，然后用 Kubernetes 跑起来，那确实是"能跑"。但 Flink Native Kubernetes 模式提供的是深度集成：

Flink 直接调用 K8s API 申请资源
无需提前准备 TaskManager 集群
任务提交时才按需创建 Pod

致命反例： 某团队用传统方式在 K8s 上部署 Flink，需要提前维护 50 个 TaskManager Pod，资源利用率不到 20%。改用 Native 模式后，任务开始前没有 Pod，运行时自动拉起，结束后自动销毁，利用率提升到 80%。

Flink k8s部署的正解只有一个

一句话定义

Flink Native Kubernetes 部署：Flink 直接调用 Kubernetes API，按需动态创建 JobManager 和 TaskManager Pod，实现流处理任务的云原生自动化管理。

简单说：Flink 变成了 Kubernetes 的" Citizens"，而不是 Kubernetes 里的"租客"。

核心架构与组件

                    ┌─────────────────────────────────┐
                    │    Kubernetes Cluster            │
                    │                                  │
    ┌───────────────┼───────┐                          │
    │  JobManager   │       │                          │
    │  Deployment   │       │                          │
    │  (HA模式)     │       │                          │
    └───────────────┼───────┘                          │
                    │            ┌─────────────────┐    │
                    │            │ TaskManager Pod │    │
                    │            │  Slot 0         │    │
                    │            │  Slot 1         │    │
                    │            │  ...            │    │
                    │            └─────────────────┘    │
                    │                                  │
                    │  ┌───────── ┌──────────┐        │
                    │  │ Pod #1  │ Pod #2   │ ...   │
                    │  │ Task-1  │ Task-2   │       │
                    │  │ Slot 0  │ Slot 0   │       │
                    │  │ Slot 1  │ Slot 1   │       │
                    │  └──────────┴──────────┘        │
                    └─────────────────────────────────┘

JobManager 以 Deployment 或 StatefulSet 形式运行，支持 HA。

TaskManager 根据作业需求动态创建，不需要提前部署。

三种部署模式

模式	特点	适用场景
Application Mode	每个 Job 独立隔离，应用代码和依赖打成 JAR/镜像提交	生产环境首推，资源隔离好
Session Mode	共享 JobManager 和 TaskManager 集群	多个轻量 Job，资源复用
Reactive Mode (1.13+)	自动根据负载弹性伸缩	负载波动大，需要自动扩缩容

在这里插入图片描述

部署方式对比

# Application Mode（推荐）
# 资源按需申请，任务结束自动释放
$ flink run-application \\
    -t kubernetes-application \\
    -Dkubernetes.cluster-id=flink-app \\
    -Dkubernetes.namespace=default \\
    -Dkubernetes.container.image.flink=mycustom-flink-image:1.17 \\
    local:///opt/flink/usrlib/my-app.jar

# Session Mode（共享集群）
# 先启动一个 Flink Session 集群
$ flink-kubernetes-session.sh \\
    -Dkubernetes.cluster-id=my-first-flink-cluster \\
    -Dtaskmanager.memory.process.size=4096m \\
    -Dkubernetes.taskmanager.cpu=2

# 然后提交作业到 Session
$ flink run -t kubernetes-session \\
    -Dkubernetes.cluster-id=my-first-flink-cluster \\
    ./my-job.jar

可验证标准

怎么判断你的 Flink on K8s 部署成功了？

资源隔离： kubectl get pods -l app=flink -n <namespace> 查看每个 Job 有独立的 Pod 集合
HA 生效： 手动删除 JobManager Pod，看是否自动重启并恢复作业
弹性伸缩： 在高负载时 TaskManager Pod 数量是否自动增加
日志查看： kubectl logs -f <pod-name> 能实时查看 Flink 日志

应用

电商领域：大促场景

淘宝双十一、京东 618，流量瞬间暴涨 100 倍。

传统 YARN 方案：

提前一周申请资源
维护固定集群，平时资源浪费 70%
扩容需要小时级

Flink on K8s 方案：

平时用最小资源维持
大促前自动扩缩容（Reactive Mode）
大促后自动缩容，节省 60% 成本

数据： 某电商公司从 YARN 迁移到 K8s 后，流处理成本降低了 50%，延迟从秒级优化到毫秒级。

金融领域：实时风控

银行监测欺诈交易。

核心挑战：

规则需要频繁更新
零停机部署
多租户隔离（不同部门不同策略）

Flink on K8s 优势：

滚动更新： 新规则上线，Pod 逐个替换，业务无感知
命名空间隔离： finance-team-a 和 finance-team-b 完全隔离
ConfigMap 管理： 解耦代码和配置，配置更新不需要重新构建镜像

AI/大数据领域：实时特征工程

推荐系统的实时特征计算。

技术栈： Flink + Kafka + Redis

部署细节：

# Flink 读取 Kafka，实时计算特征写入 Redis
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
spec:
  flinkVersion: v1.17
  jobManager:
    resource:
      memory: 4096Mi
      cpu: 2
  taskManager:
    resource:
      memory: 8192Mi
      cpu: 4
    replicas: 10
  job:
    jarURI: local:///opt/flink/usrlib/feature-pipeline.jar
    parallelism: 40
    upgradeMode: stateful
    state: running

优势： Kafka Topic 的 partition 增加时，Flink 的 parallelism 可以自动调整，不用人工干预。

物联网领域：实时设备监控

智慧城市、工业 4.0。

特点：

设备数量多（百万级）
数据量大（每秒亿级事件）
延迟要求低（秒级报警）

Flink on K8s 的适配：

Sidecar 模式： Pod 内同时运行 Flink 组件和数据采集 Agent
持久化存储： 用 PVC（PersistentVolumeClaim）保存 Checkpoint 和 Savepoint 数据
边缘计算： 轻量级 K8s 集群（如 K3s）部署到边缘节点

开源社区与生态集成

Flink Kubernetes Operator（推荐）：

由社区维护，用声明式方式管理 Flink 应用。

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: flink-stream-job
spec:
  flinkVersion: v1.17
  jobManager:
    resource:
      memory: 4096Mi
      cpu: 2
  taskManager:
    resource:
      memory: 8192Mi
      cpu: 4
  job:
    jarURI: https://example.com/my-job.jar
    parallelism: 10
    upgradeMode: stateful
    state: running

优势： 用 YAML 定义期望状态，Operator 自动保证实际状态与之一致。声明式管理，GitOps 友好。

一些技术方案的对比

Flink on YARN vs Flink on Kubernetes

维度	Flink + YARN	Flink + Kubernetes	冲击
资源粒度	粗（节点级别）	细（Pod/容器级别）	K8s 资源利用率提升 30-50%
启动时间	分钟级（需等待 YARN 调度）	秒级（容器就绪即运行）	快 10-100 倍
弹性伸缩	手动或半自动	全自动（Reactive）	自动化程度质的飞跃
故障恢复	依赖 YARN 机制	Pod 自动重启 + HA	RTO 从分钟降到秒级
多语言混合	难	天然支持	Java、Python、Go 应用共存
云原生生态	弱	强（Prometheus、Istio）	可观测性、Service Mesh 无缝集成
学习成本	Hadoop + YARN 双栈	只需 K8s	技术栈统一

数据： LinkedIn 统计显示，迁移到 K8s 后，作业失败后的恢复时间从 15 分钟缩短到 30 秒以内。

传统部署 vs 云原生化

传统部署：

申请物理机 → 安装 Hadoop → 配置 YARN → 部署 Flink → 手动调优
升级 Flink 版本需要停机数小时
监控依赖单独的 Zabbix/Ganglia

Flink on K8s：

kubectl apply -f flink-deployment.yaml，一键部署
滚动升级，零停机
监控天然集成 Prometheus + Grafana

差距在哪？ 从"运维工程师"到"平台工程师"的转变。

故事结束了

回到老张的问题。

三年后，老张成了公司云平台团队的负责人。他管理的 Flink 集群从 2000 节点缩减到了 500 节点，处理能力却提升了 3 倍。

"不是技术不够先进，"他在一次分享会上说，“是我们的思维方式落后了。”

Flink Native Kubernetes 不只是一套部署方案，它是云原生时代的流处理默认选项。当容器成为基础设施的事实标准，当 Serverless 成为架构的新常态，还坚持用 YARN 就像是拿到智能手机后坚持用座机。

最后的洞察： Flink on Kubernetes 的真正价值不在于技术本身，而在于它让你从"管理机器"转向"管理应用"——你不再需要关心底层节点在哪里，只需要告诉系统：“我要运行这个作业”，剩下的，交给云。

而在这个云的时代，

不会用 Kubernetes 的工程师，就像不会用智能手机的人。

所有评论(0)

查看更多评论

itlodge

@itlodge

已为社区贡献1条内容

Flink Kubernetes部署模式：云原生流处理的实战指南

itlodge

引子

关于Flink k8s部署的三种误解

误解一：“Kubernetes 只是容器编排，跟 Flink 关系不大。”

误解二：“Flink on K8s 和 Standalone 差不多，就是换个地方跑。”

误解三：“直接用 YAML 部署就行，不需要 Flink 的 Native 集成。”

Flink k8s部署的正解只有一个

一句话定义

核心架构与组件

三种部署模式

部署方式对比

可验证标准

应用

电商领域：大促场景

金融领域：实时风控

AI/大数据领域：实时特征工程

物联网领域：实时设备监控

开源社区与生态集成

一些技术方案的对比

Flink on YARN vs Flink on Kubernetes

传统部署 vs 云原生化

故事结束了

延伸阅读

🟢 入门（3本）

🟡 进阶（4本）

🔴 学术（3本）

所有评论(0)

itlodge

Flink Kubernetes部署模式：云原生流处理的实战指南

itlodge

引子

关于Flink k8s部署的三种误解

误解一：“Kubernetes 只是容器编排，跟 Flink 关系不大。”

误解二：“Flink on K8s 和 Standalone 差不多，就是换个地方跑。”

误解三：“直接用 YAML 部署就行，不需要 Flink 的 Native 集成。”

Flink k8s部署的正解只有一个

一句话定义

核心架构与组件

三种部署模式

部署方式对比

可验证标准

应用

电商领域：大促场景

金融领域：实时风控

AI/大数据领域：实时特征工程

物联网领域：实时设备监控

开源社区与生态集成

一些技术方案的对比

Flink on YARN vs Flink on Kubernetes

传统部署 vs 云原生化

故事结束了

延伸阅读

🟢 入门（3本）

🟡 进阶（4本）

🔴 学术（3本）

所有评论(0)

温馨提示：您尚未绑定手机号

itlodge