Flink 集群部署模式这个话题我在不同团队里被问过不下十次每次问法还都不一样有人问“作业为什么老是抢不到资源”有人问“为什么作业一提交就 OOM”还有人问“到底是 Session 省事还是 Application 省心”。这些问题表面看是运维问题往下挖一层十有八九是部署模式没选对或者选了却没把配套参数调明白。Flink 的部署模式决定了三件事集群的生命周期由谁管、资源由谁分配、作业的隔离边界在哪里。这三件事想清楚了后面 80% 的坑都能提前避开。这篇文章我从最原始的 Standalone 讲到 YARN 的三种提交方式再讲到 Kubernetes 上从 Session 到 Application 的演进路线中间穿插 Slot 与内存的换算过程、HA 与 Checkpoint 的配置细节以及一份我这些年踩坑攒下来的排查速查表。适合刚接手 Flink 集群、准备把作业从测试环境搬到线上环境的同学也适合已经在跑但总觉得资源利用率不对劲、想回头梳理一遍的老手。1. 部署模式全景先搞清楚你到底在选什么1.1 集群生命周期、资源管理、作业隔离三个维度很多人把“部署模式”理解成一个配置项其实它是一组权衡。我在给新人讲这块时习惯先让他们回答三个问题第一这个集群是长期跑着还是用完就销毁第二CPU 和内存是提前圈一块地还是按作业实际需要随用随取第三两个作业跑在同一批机器上它们之间需不需要互相“看不见”这三个问题分别对应集群生命周期、资源管理方式、作业隔离级别。Standalone 模式下集群是你自己起的进程起完就一直挂着资源是静态划死的JobManager 挂了要靠外部协调服务来兜底。YARN 模式下集群本身没有 Flink 进程你提交一次作业YARN 帮你拉起一批容器作业结束容器就回收。Kubernetes 模式下JobManager 和 TaskManager 各自是一个 Pod资源由 K8s 的调度器和资源配额管。这三种方式在“谁负责拉起进程”这件事上是完全不同的答案。隔离性上差别更微妙。Session 模式里多个作业共享同一批 TaskManager共享的是 Slot 池和 JVM 堆一个作业把堆打满同机器的另一个作业会跟着受影响这种“邻居噪音”在测试环境不明显上了生产就是灾难。Per-Job 和 Application 模式把每个作业隔离到独立的 TaskManager 进程里故障边界清晰得多代价是资源申请和启动耗时增加。所以选模式的本质是在启动速度、资源利用率、故障隔离这三者之间找平衡点。1.2 主流部署模式横向对照我把日常用得最多的几种模式整理成一张表这张表建议直接存下来选型的时候比翻文档快得多模式集群生命周期资源管理隔离级别典型适用场景Local进程内随启动脚本结束无无本地调试、单元测试Standalone手动启动常驻静态划分作业共享集群固定规模的独立机房、教学演示YARN Session手动启动常驻YARN 动态作业共享 TM小作业多、提交频繁的探索期YARN Per-Job随作业创建销毁YARN 动态作业独占 TM单个作业资源固定、需要强隔离YARN Application随作业创建销毁YARN 动态作业独占 TM且 main 在集群内生产主力尤其是需要统一管控的场景K8s Session手动启动常驻K8s 动态作业共享 TM已有 K8s 基础设施、团队共享集群K8s Application随作业创建销毁K8s 动态作业独占 TM云原生环境下生产首选K8s Operator 托管由控制器管理K8s 动态作业独占 TM需要声明式管理、批量运维的场景这张表里有几个容易忽略的细节。Session 模式的资源在启动那一刻就固定了你起了一个 4 个 TaskManager 的会话集群后面就算有 20 个作业排队也只能在这 4 个 TM 的 Slot 里挤扩不了容——除非手动再起 TM 或重启会话。Application 模式则相反作业提交后由集群内部按需申请 TM作业需要的并行度有多大就申请多少资源用完释放。还有一个关键区别是用户代码的 jar 包在哪里被解析。Session 和 Per-Job 模式下main()方法在客户端执行客户端负责生成 JobGraph 再提交Application 模式下main()在集群的 JobManager 里执行。这一点对依赖管理影响极大客户端执行意味着客户端的 classpath 会混进作业里客户端的依赖冲突会直接炸掉作业提交。我在一个项目里就遇到过客户端机器上装了某个日志框架的另一个大版本作业死活提交不上去报NoSuchMethodError排查了大半天最后发现是客户端环境不干净。Application 模式从设计上避免了这类问题这也是它成为生产主力的核心原因之一。提示如果你的团队还在用“客户端机器统一装一套 Flink 再提交作业”的方式先确认一下客户端和集群的 Flink 版本是否严格一致。版本不一致导致的序列化异常极其难查。2. 从 Standalone 说起最“裸”也最容易被低估2.1 Standalone 的架构与关键配置项Standalone 是 Flink 最朴素的运行形态一个 JobManager 进程若干 TaskManager 进程靠配置文件里的地址互相做服务发现。没有资源调度器在中间协调机器是你给好的Slot 是你在taskmanager.numberOfTaskSlots里写死的内存是你用taskmanager.memory.process.size圈定的。听起来简陋但正因为没有任何中间层它的启动速度最快链路最短出问题的时候排查路径也最清晰。配置文件里几个绕不开的项jobmanager.rpc.address指向 JobManager 所在主机jobmanager.rpc.port默认 6123parallelism.default是集群默认并行度taskmanager.numberOfTaskSlots决定每个 TM 能提供几个 Slottaskmanager.memory.process.size决定 TM 进程总内存。注意 Slot 数是纯逻辑切分不绑定 CPU配了 8 个 Slot 的 TM 如果只有 2 个物理核8 个 Slot 会争抢这 2 个核CPU 上下文切换开销会很高性能反而下降。我一般建议 Slot 数等于 taskmanager 所处机器的可用核数或者略小于它。高可用方面Standalone 需要外部协调服务来做 JobManager 的选主配置high-availability: zookeeper加上high-availability.storageDir指向一个共享存储JobManager 的元数据JobGraph、Checkpoint 指针会写在那里。没有这套配置JobManager 一挂整个集群的作业全丢只能从最近一次外部记录的 Checkpoint 手动恢复。这一点经常被忽略很多人以为配了 Checkpoint 就安全了其实 Checkpoint 只保证“数据状态可恢复”不保证“作业自动恢复”自动恢复要靠 HA 机制去重新拉起 JobManager 并从 HA 存储读取元数据。2.2 什么时候该用它什么时候别碰我的判断标准很粗暴如果这个 Flink 集群只服务一个业务线、作业数量在个位数、资源需求长期稳定、团队里有人能盯着机器Standalone 完全够用而且它的运维心智负担比 YARN 和 K8s 都低。反之只要出现“作业数量随时在变”“资源需要在多个业务之间调拨”“没有专人守着机器”这几个信号中的任意一个就该往上走一层用带资源调度的部署方式。Standalone 有一个容易被低估的优势故障定位快。因为链路短日志就在你指定的目录里进程号、GC、线程栈全都能直接抓不像容器环境那样还要先进 Pod 再看。我在做性能压测和参数调优的时候经常会在 Standalone 上先跑通基线量出这套作业在干净环境下的吞吐和延迟再去 YARN 或 K8s 上验证调度层带来的额外开销这样能很快区分“是作业本身慢”还是“是调度环境的问题”。需要避开的坑主要有两个。一是机器重启后的恢复Standalone 的进程不会自动拉起得有进程守护或外部脚本来兜底否则机器一重启集群就静默消失作业全挂。二是多作业共用时的资源争抢模块 A 的作业突然把并行度从 4 调到 16把 Slot 全占了模块 B 的作业就只能排队等而这种争抢在 Standalone 里没有任何配额手段可以限制。所以只要是多团队共用我就不会推荐 Standalone。3. Flink on YARN三种提交模式的区别与坑3.1 Session 模式启动快但资源是“死”的YARN Session 的做法是先在 YARN 上申请一批容器拉起一个常驻的 Flink 集群之后所有作业都提交到这个集群里跑。启动命令大致是yarn-session.sh -n 4 -jm 2048 -tm 4096 -s 8含义是申请 4 个 TaskManager 容器JobManager 2G每个 TaskManager 4G每个 TM 提供 8 个 Slot。这个模式的诱惑力在于提交作业的速度——因为集群已经在那儿了flink run只需要把 jar 传上去、生成 JobGraph、分配到现有 Slot几百毫秒到几秒就能跑起来。做数据探索、频繁提交小作业、跑临时 SQL 的时候特别顺手。但代价也很直接整个集群的资源在启动那一刻就锁死了-n 4 -s 8意味着总共 32 个 Slot 的天花板作业再多也只能排在这 32 个 Slot 里。更麻烦的是“补资源”这件事。理论上可以再起一个 TaskManager 加入同一个会话集群但那需要手动执行脚本没法像 Application 模式那样由 JobManager 按需自动申请。所以实际使用中Session 集群的资源规划往往要么严重浪费按峰值配平时一半空转要么长期不够按均值配高峰排队。我在一个中型项目里量过Session 模式的 Slot 平均利用率大概只有 40% 出头剩下六成的时间资源是闲着的。Session 模式的另一个隐性风险是故障扩散。所有作业共享 TaskManager 进程一个作业如果有内存泄漏把 TM 的堆撑爆整个 TM 进程会被 JVM 或者 YARN 杀掉跑在这个 TM 上的其他作业全部失败一起重启。这种“一颗老鼠屎”的效应在多团队共用 Session 集群时特别常见。3.2 Per-Job 模式隔离好但客户端负担重Per-Job 模式是“一个作业一个集群”提交作业时客户端先向 YARN 申请一个 JobManager 容器JobManager 启动后按作业需要的并行度申请 TaskManager 容器作业跑完所有容器释放。隔离性上它是彻底赢了——作业之间的内存、CPU、故障域完全独立一个作业崩了不会波及别人。命令形式在较新版本里是flink run -t yarn-per-job -c 主类 作业jar-t指定目标类型。相比老版本的-m yarn-cluster新写法更清晰。需要注意的是这个模式在 Kubernetes 上已经被标记为弃用YARN 上仍然可用但社区的方向明确是往 Application 模式收敛新项目我基本不再推荐 Per-Job。它的主要负担在客户端。main()方法在客户端本地执行客户端要能访问到 YARN 的配置、能访问 Hadoop 的类库、还要能连上 JobManager 的 RPC 端口。这意味着客户端环境必须“干净且完整”Flink 版本一致、Hadoop 依赖一致、网络可达。我遇到过最典型的一次故障是客户端在办公网、集群在机房网中间有防火墙客户端能提交作业到 YARN因为走 ResourceManager 的端口是通的但后续连不上 JobManager 的 6123 端口作业一直停在“提交中”。这种情况改成 Application 模式就绕过去了因为不需要客户端在跑起来之后持续连 JobManager。3.3 Application 模式把 main 搬进集群Application 模式的核心改动只有一句话把用户代码的main()执行搬到集群里。客户端只负责把 jar 和配置传给 YARN 的 ResourceManagerResourceManager 拉起一个 JobManager 容器JobManager 在里面执行 main、生成 JobGraph、申请 TaskManager全程不需要客户端参与。提交命令是flink run-application -t yarn-application -c 主类 作业jar。这个改动带来的好处比看起来大得多。第一客户端的依赖地狱消失了作业用的类库全部来自集群侧和用户 jar不会混进办公电脑上的杂七杂八。第二客户端可以在提交完成后就退出不需要保持长连接这一点对做自动化发布 pipeline 极其友好——CI 机器提交完就释放不用挂着等作业跑完。第三运维边界变清楚了作业出问题的时候排查范围缩小到集群内不用猜客户端干了什么。代价是部署包的准备方式变了。因为 JobManager 在集群里执行 main它需要拿到 Flink 的运行时 jar 和用户 jar。通常有两种做法一种是把用户 jar 上传到共享存储提交时通过yarn.application.classpath或者-yt之类的参数指定另一种是把 Flink 发行包预先放到集群每个节点上。我一般倾向于用共享存储的方案把 Flink 的 lib 目录和用户 jar 一起打包上传提交时指定路径这样版本管理清晰升级也方便。3.4 YARN 模式的资源参数与一次实际提交记录参数这一块我用得最多的几个是-Djobmanager.memory.process.size2048m、-Dtaskmanager.memory.process.size4096m、-Dtaskmanager.numberOfTaskSlots4、-Dparallelism.default8。这里最容易翻车的是 YARN 容器大小和 Flink 进程内存的关系。Flink 申请 YARN 容器时申请的容器内存必须大于等于taskmanager.memory.process.size因为 process size 是 JVM 进程的总内存里面已经包含了堆、堆外、Metaspace、JVM 自身开销。如果 YARN 队列的最大容器配额比如yarn.scheduler.maximum-allocation-mb设成了 3072小于你请求的 4096提交会直接被拒报InvalidResourceRequestException。反过来如果容器给够了 4096但 Flink 里配的 process size 是 8192那 TM 启动后进程会涨到 8G 以上超出容器上限被 YARN 的监控杀掉日志里留下Container killed by YARN for exceeding memory limits。这个报错我一共见过四次每次都是配置对不上。还有一个常被忽略的项是 vCore。YARN 的调度默认是按内存和虚拟核两个维度算的一个 4 Slot 的 TM 如果只申请 1 个 vCoreYARN 会认为这台机器上能塞很多个这样的容器结果多个 TM 挤在同一台机器上抢 CPU。我一般把taskmanager.numberOfTaskSlots设成和申请的 vCore 数一致让逻辑 Slot 数和物理核数对齐避免 CPU 超卖。注意YARN 模式下如果开了日志聚合作业结束后仍能在 ResourceManager 的 Web UI 上看到日志如果没开作业容器一销毁日志就没了事后排查基本没戏。这个开关建议默认打开。4. Flink on Kubernetes从 Session 到 Native 的演进4.1 Session 与 Application 两种形态的选择依据Kubernetes 上的 Flink 部署绕不开的同样是“共享还是独占”这道题。Session 模式用kubernetes-session.sh起一个常驻集群JobManager 是一个 PodTaskManager 是按需拉起的一批 Pod多个作业共享这批 TM。Application 模式用flink run-application -t kubernetes-applicationJobManager Pod 里执行 main再按需申请 TM Pod作业结束所有 Pod 回收。从我的实际感受看K8s 上 Session 模式的处境比 YARN 上更尴尬。K8s 的弹性本来就是它的招牌能力而 Session 模式恰恰把弹性锁死了——会话集群起来的时候定义了多少 TM后面就基本是多少除非手动扩。所以如果已经在 K8s 上我基本只会用 Application 模式或者用 Operator 做声明式管理。Application 模式在 K8s 上需要几个前置条件一个能推拉镜像的仓库、一个具备创建 Pod 权限的 ServiceAccount、一个能挂载的配置来源ConfigMap 或直接打进镜像、以及 JobManager 的 Service 暴露方式。kubernetes.rest-service.exposed.type可以选ClusterIP、NodePort、LoadPort只有需要从集群外访问 Web UI 或 REST API 时才需要非 ClusterIP否则保持 ClusterIP 最省事也最安全。关于 HAK8s 上的 Flink 从较早版本开始支持用 ConfigMap 作为高可用存储high-availability.type: kubernetes配合high-availability.storageDir指向一个对象存储路径。这样 JobManager Pod 挂了新 Pod 起来能从 ConfigMap 里读到作业元数据从 Checkpoint 恢复。如果用的是基于 ZooKeeper 的 HA那就得在 K8s 里额外部署一套协调服务组件数量增加运维成本也上去我一般优先选原生方案。4.2 资源配置的三个关键字段与镜像准备K8s 上的资源控制有两层一层是 Flink 自己的内存模型taskmanager.memory.process.size等另一层是 Pod 的resources.requests和resources.limits。这两层必须对齐而且 Pod 的 limit 必须大于Flink 的 process size给日志采集、监控探针这些边车容器留出空间。一个典型配置是 process size 配 4096mPod 的requests.memory配 4Gilimits.memory配 5Gi。为什么 limit 要留余量因为 JVM 的进程内存并不是一个硬边界堆外分配、线程栈、本地库的映射内存都可能让实际占用略微超过配置值。如果 limit 和 process size 卡得一模一样很容易触发 OOMKilledPod 被 kubelet 直接干掉日志里只留一个OOMKilled状态什么堆栈都没有排查起来非常痛苦。我踩过一次一个作业稳定跑了三天后突然间歇性 OOMKilled最后发现是某个序列化框架在堆外申请内存刚好把余量吃干净了把 limit 从 4Gi 调到 5Gi 就再没出现过。镜像准备这块思路有两种。一种是直接用官方的 Flink 镜像把用户 jar 和依赖通过-Dkubernetes.jobmanager.volume之类的挂载进去另一种是自己构建镜像把 Flink 发行包、用户 jar、配置文件一起打进去提交时只指定镜像名和入口类。前者灵活、升级方便后者部署简单、启动快因为不用每次拉 jar。团队规模小、作业数量少的时候我倾向后者作业多、需要频繁更新代码的时候用前者。还有一个细节要注意kubernetes.container.image.pull-policy建议设成IfNotPresent配合固定的镜像 tag 使用。如果设成Always每次起 Pod 都要去仓库确认一遍节点上镜像大了之后拉取时间能拖到几十秒作业启动变慢而且仓库抖动会直接影响作业启动成功率。用latest这种浮动 tag 更是自找麻烦回滚都回不去。4.3 Pod 模板与临时存储的处理Flink 的 K8s 部署支持通过kubernetes.pod-template-file指定 Pod 模板这一点在生产里非常有用。我通常会在模板里干三件事给容器加节点亲和性和污点容忍让 TM 只调度到指定的机器池挂载一个emptyDir到 Flink 的临时目录避免容器根文件系统写满配置资源限制和环境变量。临时存储这个问题特别值得说。Flink 的 TaskManager 在跑批作业或者大规模 Shuffle 的时候会把中间结果写到本地磁盘默认路径在容器内的临时目录。容器的根文件系统通常不大写满之后会触发节点驱逐Pod 直接消失作业失败日志里看到的只是一个模糊的容器退出码。解决办法是挂载一个emptyDir到taskmanager.tmp.dirs指定的路径emptyDir的大小可以通过sizeLimit限制用medium: Memory还能走内存盘但对内存消耗要算进 limit 里。这个改动看着小实际能省掉很多“莫名其妙挂掉”的问题。日志采集也是同理Pod 销毁日志就没了。要么把日志目录挂到持久卷要么依赖节点的日志采集代理把 stdout 收走。Flink 容器里的日志默认输出到文件需要通过log4j-console.properties让一部分关键日志同时打到 stdout否则采集代理抓不到东西。提示K8s 环境里排查作业启动失败第一步永远是kubectl describe pod看 Events 里的调度失败原因和容器退出码比看 Flink 日志快十倍。退出码 137 基本就是 OOMKilled 或者被驱逐。5. 资源与并行度的换算Slot、TaskManager 与内存模型5.1 Slot 共享机制与并行度的对应关系Slot 是 Flink 里的资源单位一个 TaskManager 按numberOfTaskSlots切成若干份每个 Slot 能跑一个并行子任务。但 Slot 只隔离内存不隔离 CPU——同一个 TM 里的多个 Slot 共享这台机器的 CPU 核靠操作系统的调度去争抢。理解这一点很关键因为它解释了为什么“Slot 配多了不一定更快”。Slot 共享Slot Sharing是另一个容易搞混的概念。同一个作业的不同算子默认可以共享一个 Slot比如 source 的并行度是 4、map 的并行度是 4、sink 的并行度是 4它们可以全部塞进 4 个 Slot 里每个 Slot 里跑一条“source→map→sink”的完整链路。这个设计的目的是避免“source 在忙、sink 在闲”的资源浪费让 Slot 内的资源得到充分利用。所以一个作业所需的最小 Slot 数不是所有算子并行度之和而是所有算子并行度的最大值。举个具体例子作业里 source 并行度 4flatMap 并行度 8keyBy 后 window 并行度 8sink 并行度 4。这个作业需要的 Slot 数是 8不是 24。如果 TM 配了 4 个 Slot那就需要 2 个 TM。这个算法在规划资源的时候必须算清楚否则要么申请多了浪费要么申请少了报NoResourceAvailableException。什么时候需要关掉 Slot 共享当作业里有重算子比如大窗口聚合和轻算子比如简单的过滤混在一起时共享 Slot 会让它们互相拖累重的那个把 CPU 占满轻的只能等。这种场景可以用slotSharingGroup把重算子单独拎出来分组让它们独占 Slot。这是个进阶手段一般作业用不上但遇到“某个算子明显拖慢整体”的时候值得一试。5.2 内存模型拆解与一步步的计算过程Flink 从 1.10 开始用统一的内存模型配置入口是taskmanager.memory.process.size也就是整个 TM 进程的总内存。这个总内存往下分几层先扣掉 JVM Metaspace 和 JVM Overhead剩下的叫 Flink 总内存Flink 总内存里再分框架堆、框架堆外、任务堆、任务堆外、Managed Memory、Network Memory。这几层的默认值都有推导规则理解规则比死记数值有用。我拿一个具体的配置走一遍计算。假设taskmanager.memory.process.size 4096m其他用默认值第一步jvm.metaspace.size默认 256m。第二步jvm.overhead默认按 process size 的 0.1 计算且限定在 192m 到 1024m 之间。4096 × 0.1 409.6取 410m 左右。第三步Flink 总内存 4096 - 256 - 410 3430m。第四步Network Memory 默认按 Flink 总内存的 0.1 计算限定在 64m 到 1024m 之间。3430 × 0.1 343m。第五步Managed Memory 默认按 Flink 总内存的 0.4 计算3430 × 0.4 1372m。这部分是给 RocksDB 状态后端和批处理算子用的。第六步框架堆 128m、框架堆外 128m、任务堆外 0m默认。第七步任务堆 3430 - 343 - 1372 - 128 - 128 - 0 1459m。这个结果意味着什么意味着用户代码能用的堆只有 1.4G 左右。很多人在配 4G 的 TM 之后发现作业老是 GC 频繁甚至 OOM就是没意识到一半以上的内存被 Managed Memory 和网络缓冲吃掉了。如果你的作业不用 RocksDB、状态很小可以把taskmanager.memory.managed.fraction调低到 0.2 甚至 0.1把内存还给任务堆如果用了 RocksDB 且状态很大那就得反向操作把 managed fraction 调高同时把 process size 加大。内存分区默认规则4096m 时的实际值调整建议JVM Metaspace固定 256m256m类加载多时调到 384mJVM Overhead10%192m~1024m约 410m一般不动Network Memory10%64m~1024m约 343mShuffle 大时调高Managed Memory40% of Flink 总内存约 1372m无 RocksDB 时降到 0.2Framework Heap128m128m一般不动Task Heap剩余部分约 1459m用户代码可用内存5.3 一个 8 并行度作业的完整资源规划实例假设有一个实时作业source 并行度 8处理链路并行度 8sink 并行度 4作业需要的 Slot 数是 8。现在要决定 TM 怎么配。先定 Slot 数。假设每个 TM 所在机器 4 核那就把numberOfTaskSlots设成 4避免 CPU 超卖。8 个 Slot 除以每个 TM 4 个需要 2 个 TM。再定内存。假设作业状态不大几 GB 以内用 RocksDB 增量 Checkpoint那么每个 TM 配 4G process size 差不多Managed Memory 有 1.3G 左右够用。如果状态到了几十 GB就要把 process size 提到 8G 甚至 16G同时 managed fraction 保持 0.4 以上。然后是 YARN 或 K8s 侧的配额。YARN 要确认队列的maximum-allocation-mb不小于 4096maximum-allocation-vcores不小于 4。K8s 要确认命名空间的ResourceQuota允许 2 个 4Gi 的 Pod节点上有足够的可分配资源。这些配额限制看着是运维的事但规划阶段不确认提交时就会被拒白白浪费一轮调试时间。最后算一下总资源账2 个 TM × 4G 8G 内存2 个 TM × 4 vCore 8 核加上 JobManager 的 2G 内存和 1 核。这个账我一般会在提交前写进变更单里出问题的时候对照着看很容易发现是哪一层配少了。6. 高可用、状态与容错配置6.1 HA 配置的三种组合与选择HA 的核心是两件事JobManager 挂了谁来接管以及新起来的 JobManager 从哪里读到作业元数据。第一种组合是外部协调服务加共享存储配置high-availability: zookeeper、high-availability.storageDir指向 HDFS 或对象存储路径。这套方案成熟稳定但要多维护一套协调服务组件越多故障面越大。第二种是 K8s 原生 HAhigh-availability.type: kubernetes元数据存在 ConfigMap 里状态存在对象存储。这套的好处是不引入额外组件坏处是 ConfigMap 有大小限制大约 1MB如果作业的 JobGraph 特别大算子特别多、序列化后的 DAG 很复杂可能会超出限制导致 HA 写入失败。我遇到过一例一个自动生成的超大 DAG 作业HA 一直报写入失败最后是靠拆分作业解决的。第三种是 Standalone 环境下的单点容忍即不配 HA靠外部脚本监控进程、挂了就重启然后手动从 Savepoint 恢复。这种方式只适合能接受分钟级中断的场景线上核心作业不要这么干。不管用哪种组合high-availability.cluster-id都要显式设置尤其是 YARN 的 Application 模式和 K8s 环境集群 ID 是恢复时识别“这是同一个作业”的依据。ID 没设对重启后新集群找不到旧元数据只能从零开始状态全丢。6.2 Checkpoint 配置的取舍与状态后端选择Checkpoint 的配置里我最关注四个参数间隔、超时、最小间隔、可容忍失败次数。间隔太短会让作业频繁做快照挤占正常处理的时间间隔太长则恢复时要重放很多数据。经验值是间隔设在 1 到 5 分钟超时设为间隔的 3 到 5 倍最小间隔设为间隔的一半左右可容忍失败次数给 2 到 3 次。状态后端这块现在基本就两个选择内存型HashMapStateBackend和 RocksDB。状态在几百 MB 以内、对延迟极敏感的作业用内存型读写没有序列化开销但状态大小受堆限制且全量 Checkpoint 每次都把整个状态写一遍。状态在 GB 级以上、需要增量 Checkpoint 的作业用 RocksDB状态存在本地磁盘的 SST 文件里Checkpoint 只上传增量部分代价是读写有序列化开销延迟略高。RocksDB 的增量 Checkpoint 有几个前提Checkpoint 存储必须是支持原子重命名的文件系统对象存储在部分实现上需要注意且必须开启state.backend.incremental: true。不开这个开关RocksDB 也做全量上传一个几十 GB 的状态每次全传网络和存储压力都很大还容易超时。我在一个作业上量过开了增量之后 Checkpoint 耗时从 90 秒降到 8 秒效果非常直观。注意Checkpoint 存储路径不要和 HA 存储路径混在一起两者生命周期不同HA 只保留最新一份Checkpoint 要保留多份用于回滚。分开存能避免清理策略互相干扰。7. 常见问题与排查实录7.1 高频故障速查表下面这张表是我这些年攒下来的基本都是现场排查过的问题按报错关键词索引现象 / 报错关键词大概率原因处理方向NoResourceAvailableExceptionSlot 不够或并行度超过 Slot 总数算清最大并行度扩 TM 或调并行度Container killed by YARN for exceeding memory limits容器内存小于进程实际占用核对 process size 与容器配额留 10% 余量Pod 状态OOMKilledK8s limit 太紧limit 至少比 process size 高 1Gi作业提交报NoSuchMethodError客户端 classpath 污染改用 Application 模式或清理客户端依赖提交后卡在“正在提交”客户端连不上 JobManager 端口检查网络策略或改用 Application 模式Checkpoint 持续失败存储写入慢或状态太大换存储、开增量、调大超时TaskManager 频繁掉线但无异常日志心跳超时或 GC 停顿过长看 GC 日志调大心跳超时加内存反压指标长期红下游算子处理能力不足定位瓶颈算子扩并行度或优化逻辑作业重启后状态丢失HA 元数据没读到或 cluster-id 变了核对 HA 配置与 cluster-id容器被驱逐退出码 137临时存储写满或内存超限挂载 emptyDir检查磁盘用量表格用起来快但有两个前提要清楚。一是报错关键词要抓准很多异常的根因藏在 WARN 级别日志里不在 ERROR 里二是排查顺序永远是“先看资源、再看网络、最后看代码”因为资源问题最容易验证代码问题最难定位。我见过太多人一上来就怀疑代码逻辑翻了两小时源码最后发现是 Slot 数配少了。7.2 几个不写在文档里的实操经验第一个经验先跑一个最小作业探路。换新环境、上新部署模式的时候不要直接拿正式作业去试先提交一个fromElements(1).print()这样的最小作业验证“提交链路通不通、资源能不能申请到、日志能不能看到、Web UI 能不能访问”。这一步花五分钟能省掉后面几个小时的瞎猜。我换 K8s 环境的时候就是这么干的最小作业直接卡在镜像拉取上一眼就看出是私有仓库的凭证没配。第二个经验Slot 数不要超过物理核数。这条我前面提过一次但值得再说因为它的危害是隐性的——不是报错而是性能缓慢下降。8 个 Slot 挤在 2 核上CPU 上下文切换的开销能吃掉三成吞吐而且监控上看 CPU 占用率很高容易误判成“资源不够要扩容”实际是配错了。第三个经验日志级别不要长期开 DEBUG。排查问题的时候开 DEBUG 很爽但忘了关就是灾难。DEBUG 日志的 IO 开销在大流量下非常可观更麻烦的是磁盘会被迅速写满容器环境里直接触发驱逐。我一般会在配置里给 DEBUG 加一个过期提醒或者干脆用运行时的 REST 接口临时改级别排查完就改回去。第四个经验Savepoint 和 Checkpoint 要分开管。Checkpoint 是自动的、滚动的、会被清理的Savepoint 是手动的、带版本语义的、要长期保留的。做版本升级、逻辑变更、集群迁移之前必须先打一个 Savepoint 并验证它能恢复。我习惯在变更前打 Savepoint然后在测试集群上先验证恢复流程确认没问题再动生产这个习惯救过我好几次。第五个经验给每套环境算一笔资源账。把并行度、Slot 数、TM 数、每个 TM 的内存、JobManager 内存、总核数、总内存这些列成一张表贴在变更单或者文档里。这套账目在扩容、缩容、迁移的时候是基准线出问题的时候一对照就能发现哪里不对。凭感觉配参数的人早晚会在某个深夜被叫起来改配置。最后再补充一个关于模式迁移的观察。从 Standalone 迁到 YARN或者从 YARN 迁到 K8s真正的难点不在提交命令的变化而在依赖管理和日志可见性。Standalone 时代jar 和配置都在本机出了问题直接看本机日志到了 YARN 和 K8sjar 要在集群侧可达日志要通过聚合系统去捞。我建议在迁移之前先把这两件事在新环境里跑通——用最小作业验证 jar 分发、用日志聚合验证能查到历史日志然后再动正式作业。这两步做完迁移过程中的大部分“玄学问题”都会变成可解释的常规问题。 Flink集群部署模式选型与资源调优实践
Flink 集群部署模式这个话题我在不同团队里被问过不下十次每次问法还都不一样有人问“作业为什么老是抢不到资源”有人问“为什么作业一提交就 OOM”还有人问“到底是 Session 省事还是 Application 省心”。这些问题表面看是运维问题往下挖一层十有八九是部署模式没选对或者选了却没把配套参数调明白。Flink 的部署模式决定了三件事集群的生命周期由谁管、资源由谁分配、作业的隔离边界在哪里。这三件事想清楚了后面 80% 的坑都能提前避开。这篇文章我从最原始的 Standalone 讲到 YARN 的三种提交方式再讲到 Kubernetes 上从 Session 到 Application 的演进路线中间穿插 Slot 与内存的换算过程、HA 与 Checkpoint 的配置细节以及一份我这些年踩坑攒下来的排查速查表。适合刚接手 Flink 集群、准备把作业从测试环境搬到线上环境的同学也适合已经在跑但总觉得资源利用率不对劲、想回头梳理一遍的老手。1. 部署模式全景先搞清楚你到底在选什么1.1 集群生命周期、资源管理、作业隔离三个维度很多人把“部署模式”理解成一个配置项其实它是一组权衡。我在给新人讲这块时习惯先让他们回答三个问题第一这个集群是长期跑着还是用完就销毁第二CPU 和内存是提前圈一块地还是按作业实际需要随用随取第三两个作业跑在同一批机器上它们之间需不需要互相“看不见”这三个问题分别对应集群生命周期、资源管理方式、作业隔离级别。Standalone 模式下集群是你自己起的进程起完就一直挂着资源是静态划死的JobManager 挂了要靠外部协调服务来兜底。YARN 模式下集群本身没有 Flink 进程你提交一次作业YARN 帮你拉起一批容器作业结束容器就回收。Kubernetes 模式下JobManager 和 TaskManager 各自是一个 Pod资源由 K8s 的调度器和资源配额管。这三种方式在“谁负责拉起进程”这件事上是完全不同的答案。隔离性上差别更微妙。Session 模式里多个作业共享同一批 TaskManager共享的是 Slot 池和 JVM 堆一个作业把堆打满同机器的另一个作业会跟着受影响这种“邻居噪音”在测试环境不明显上了生产就是灾难。Per-Job 和 Application 模式把每个作业隔离到独立的 TaskManager 进程里故障边界清晰得多代价是资源申请和启动耗时增加。所以选模式的本质是在启动速度、资源利用率、故障隔离这三者之间找平衡点。1.2 主流部署模式横向对照我把日常用得最多的几种模式整理成一张表这张表建议直接存下来选型的时候比翻文档快得多模式集群生命周期资源管理隔离级别典型适用场景Local进程内随启动脚本结束无无本地调试、单元测试Standalone手动启动常驻静态划分作业共享集群固定规模的独立机房、教学演示YARN Session手动启动常驻YARN 动态作业共享 TM小作业多、提交频繁的探索期YARN Per-Job随作业创建销毁YARN 动态作业独占 TM单个作业资源固定、需要强隔离YARN Application随作业创建销毁YARN 动态作业独占 TM且 main 在集群内生产主力尤其是需要统一管控的场景K8s Session手动启动常驻K8s 动态作业共享 TM已有 K8s 基础设施、团队共享集群K8s Application随作业创建销毁K8s 动态作业独占 TM云原生环境下生产首选K8s Operator 托管由控制器管理K8s 动态作业独占 TM需要声明式管理、批量运维的场景这张表里有几个容易忽略的细节。Session 模式的资源在启动那一刻就固定了你起了一个 4 个 TaskManager 的会话集群后面就算有 20 个作业排队也只能在这 4 个 TM 的 Slot 里挤扩不了容——除非手动再起 TM 或重启会话。Application 模式则相反作业提交后由集群内部按需申请 TM作业需要的并行度有多大就申请多少资源用完释放。还有一个关键区别是用户代码的 jar 包在哪里被解析。Session 和 Per-Job 模式下main()方法在客户端执行客户端负责生成 JobGraph 再提交Application 模式下main()在集群的 JobManager 里执行。这一点对依赖管理影响极大客户端执行意味着客户端的 classpath 会混进作业里客户端的依赖冲突会直接炸掉作业提交。我在一个项目里就遇到过客户端机器上装了某个日志框架的另一个大版本作业死活提交不上去报NoSuchMethodError排查了大半天最后发现是客户端环境不干净。Application 模式从设计上避免了这类问题这也是它成为生产主力的核心原因之一。提示如果你的团队还在用“客户端机器统一装一套 Flink 再提交作业”的方式先确认一下客户端和集群的 Flink 版本是否严格一致。版本不一致导致的序列化异常极其难查。2. 从 Standalone 说起最“裸”也最容易被低估2.1 Standalone 的架构与关键配置项Standalone 是 Flink 最朴素的运行形态一个 JobManager 进程若干 TaskManager 进程靠配置文件里的地址互相做服务发现。没有资源调度器在中间协调机器是你给好的Slot 是你在taskmanager.numberOfTaskSlots里写死的内存是你用taskmanager.memory.process.size圈定的。听起来简陋但正因为没有任何中间层它的启动速度最快链路最短出问题的时候排查路径也最清晰。配置文件里几个绕不开的项jobmanager.rpc.address指向 JobManager 所在主机jobmanager.rpc.port默认 6123parallelism.default是集群默认并行度taskmanager.numberOfTaskSlots决定每个 TM 能提供几个 Slottaskmanager.memory.process.size决定 TM 进程总内存。注意 Slot 数是纯逻辑切分不绑定 CPU配了 8 个 Slot 的 TM 如果只有 2 个物理核8 个 Slot 会争抢这 2 个核CPU 上下文切换开销会很高性能反而下降。我一般建议 Slot 数等于 taskmanager 所处机器的可用核数或者略小于它。高可用方面Standalone 需要外部协调服务来做 JobManager 的选主配置high-availability: zookeeper加上high-availability.storageDir指向一个共享存储JobManager 的元数据JobGraph、Checkpoint 指针会写在那里。没有这套配置JobManager 一挂整个集群的作业全丢只能从最近一次外部记录的 Checkpoint 手动恢复。这一点经常被忽略很多人以为配了 Checkpoint 就安全了其实 Checkpoint 只保证“数据状态可恢复”不保证“作业自动恢复”自动恢复要靠 HA 机制去重新拉起 JobManager 并从 HA 存储读取元数据。2.2 什么时候该用它什么时候别碰我的判断标准很粗暴如果这个 Flink 集群只服务一个业务线、作业数量在个位数、资源需求长期稳定、团队里有人能盯着机器Standalone 完全够用而且它的运维心智负担比 YARN 和 K8s 都低。反之只要出现“作业数量随时在变”“资源需要在多个业务之间调拨”“没有专人守着机器”这几个信号中的任意一个就该往上走一层用带资源调度的部署方式。Standalone 有一个容易被低估的优势故障定位快。因为链路短日志就在你指定的目录里进程号、GC、线程栈全都能直接抓不像容器环境那样还要先进 Pod 再看。我在做性能压测和参数调优的时候经常会在 Standalone 上先跑通基线量出这套作业在干净环境下的吞吐和延迟再去 YARN 或 K8s 上验证调度层带来的额外开销这样能很快区分“是作业本身慢”还是“是调度环境的问题”。需要避开的坑主要有两个。一是机器重启后的恢复Standalone 的进程不会自动拉起得有进程守护或外部脚本来兜底否则机器一重启集群就静默消失作业全挂。二是多作业共用时的资源争抢模块 A 的作业突然把并行度从 4 调到 16把 Slot 全占了模块 B 的作业就只能排队等而这种争抢在 Standalone 里没有任何配额手段可以限制。所以只要是多团队共用我就不会推荐 Standalone。3. Flink on YARN三种提交模式的区别与坑3.1 Session 模式启动快但资源是“死”的YARN Session 的做法是先在 YARN 上申请一批容器拉起一个常驻的 Flink 集群之后所有作业都提交到这个集群里跑。启动命令大致是yarn-session.sh -n 4 -jm 2048 -tm 4096 -s 8含义是申请 4 个 TaskManager 容器JobManager 2G每个 TaskManager 4G每个 TM 提供 8 个 Slot。这个模式的诱惑力在于提交作业的速度——因为集群已经在那儿了flink run只需要把 jar 传上去、生成 JobGraph、分配到现有 Slot几百毫秒到几秒就能跑起来。做数据探索、频繁提交小作业、跑临时 SQL 的时候特别顺手。但代价也很直接整个集群的资源在启动那一刻就锁死了-n 4 -s 8意味着总共 32 个 Slot 的天花板作业再多也只能排在这 32 个 Slot 里。更麻烦的是“补资源”这件事。理论上可以再起一个 TaskManager 加入同一个会话集群但那需要手动执行脚本没法像 Application 模式那样由 JobManager 按需自动申请。所以实际使用中Session 集群的资源规划往往要么严重浪费按峰值配平时一半空转要么长期不够按均值配高峰排队。我在一个中型项目里量过Session 模式的 Slot 平均利用率大概只有 40% 出头剩下六成的时间资源是闲着的。Session 模式的另一个隐性风险是故障扩散。所有作业共享 TaskManager 进程一个作业如果有内存泄漏把 TM 的堆撑爆整个 TM 进程会被 JVM 或者 YARN 杀掉跑在这个 TM 上的其他作业全部失败一起重启。这种“一颗老鼠屎”的效应在多团队共用 Session 集群时特别常见。3.2 Per-Job 模式隔离好但客户端负担重Per-Job 模式是“一个作业一个集群”提交作业时客户端先向 YARN 申请一个 JobManager 容器JobManager 启动后按作业需要的并行度申请 TaskManager 容器作业跑完所有容器释放。隔离性上它是彻底赢了——作业之间的内存、CPU、故障域完全独立一个作业崩了不会波及别人。命令形式在较新版本里是flink run -t yarn-per-job -c 主类 作业jar-t指定目标类型。相比老版本的-m yarn-cluster新写法更清晰。需要注意的是这个模式在 Kubernetes 上已经被标记为弃用YARN 上仍然可用但社区的方向明确是往 Application 模式收敛新项目我基本不再推荐 Per-Job。它的主要负担在客户端。main()方法在客户端本地执行客户端要能访问到 YARN 的配置、能访问 Hadoop 的类库、还要能连上 JobManager 的 RPC 端口。这意味着客户端环境必须“干净且完整”Flink 版本一致、Hadoop 依赖一致、网络可达。我遇到过最典型的一次故障是客户端在办公网、集群在机房网中间有防火墙客户端能提交作业到 YARN因为走 ResourceManager 的端口是通的但后续连不上 JobManager 的 6123 端口作业一直停在“提交中”。这种情况改成 Application 模式就绕过去了因为不需要客户端在跑起来之后持续连 JobManager。3.3 Application 模式把 main 搬进集群Application 模式的核心改动只有一句话把用户代码的main()执行搬到集群里。客户端只负责把 jar 和配置传给 YARN 的 ResourceManagerResourceManager 拉起一个 JobManager 容器JobManager 在里面执行 main、生成 JobGraph、申请 TaskManager全程不需要客户端参与。提交命令是flink run-application -t yarn-application -c 主类 作业jar。这个改动带来的好处比看起来大得多。第一客户端的依赖地狱消失了作业用的类库全部来自集群侧和用户 jar不会混进办公电脑上的杂七杂八。第二客户端可以在提交完成后就退出不需要保持长连接这一点对做自动化发布 pipeline 极其友好——CI 机器提交完就释放不用挂着等作业跑完。第三运维边界变清楚了作业出问题的时候排查范围缩小到集群内不用猜客户端干了什么。代价是部署包的准备方式变了。因为 JobManager 在集群里执行 main它需要拿到 Flink 的运行时 jar 和用户 jar。通常有两种做法一种是把用户 jar 上传到共享存储提交时通过yarn.application.classpath或者-yt之类的参数指定另一种是把 Flink 发行包预先放到集群每个节点上。我一般倾向于用共享存储的方案把 Flink 的 lib 目录和用户 jar 一起打包上传提交时指定路径这样版本管理清晰升级也方便。3.4 YARN 模式的资源参数与一次实际提交记录参数这一块我用得最多的几个是-Djobmanager.memory.process.size2048m、-Dtaskmanager.memory.process.size4096m、-Dtaskmanager.numberOfTaskSlots4、-Dparallelism.default8。这里最容易翻车的是 YARN 容器大小和 Flink 进程内存的关系。Flink 申请 YARN 容器时申请的容器内存必须大于等于taskmanager.memory.process.size因为 process size 是 JVM 进程的总内存里面已经包含了堆、堆外、Metaspace、JVM 自身开销。如果 YARN 队列的最大容器配额比如yarn.scheduler.maximum-allocation-mb设成了 3072小于你请求的 4096提交会直接被拒报InvalidResourceRequestException。反过来如果容器给够了 4096但 Flink 里配的 process size 是 8192那 TM 启动后进程会涨到 8G 以上超出容器上限被 YARN 的监控杀掉日志里留下Container killed by YARN for exceeding memory limits。这个报错我一共见过四次每次都是配置对不上。还有一个常被忽略的项是 vCore。YARN 的调度默认是按内存和虚拟核两个维度算的一个 4 Slot 的 TM 如果只申请 1 个 vCoreYARN 会认为这台机器上能塞很多个这样的容器结果多个 TM 挤在同一台机器上抢 CPU。我一般把taskmanager.numberOfTaskSlots设成和申请的 vCore 数一致让逻辑 Slot 数和物理核数对齐避免 CPU 超卖。注意YARN 模式下如果开了日志聚合作业结束后仍能在 ResourceManager 的 Web UI 上看到日志如果没开作业容器一销毁日志就没了事后排查基本没戏。这个开关建议默认打开。4. Flink on Kubernetes从 Session 到 Native 的演进4.1 Session 与 Application 两种形态的选择依据Kubernetes 上的 Flink 部署绕不开的同样是“共享还是独占”这道题。Session 模式用kubernetes-session.sh起一个常驻集群JobManager 是一个 PodTaskManager 是按需拉起的一批 Pod多个作业共享这批 TM。Application 模式用flink run-application -t kubernetes-applicationJobManager Pod 里执行 main再按需申请 TM Pod作业结束所有 Pod 回收。从我的实际感受看K8s 上 Session 模式的处境比 YARN 上更尴尬。K8s 的弹性本来就是它的招牌能力而 Session 模式恰恰把弹性锁死了——会话集群起来的时候定义了多少 TM后面就基本是多少除非手动扩。所以如果已经在 K8s 上我基本只会用 Application 模式或者用 Operator 做声明式管理。Application 模式在 K8s 上需要几个前置条件一个能推拉镜像的仓库、一个具备创建 Pod 权限的 ServiceAccount、一个能挂载的配置来源ConfigMap 或直接打进镜像、以及 JobManager 的 Service 暴露方式。kubernetes.rest-service.exposed.type可以选ClusterIP、NodePort、LoadPort只有需要从集群外访问 Web UI 或 REST API 时才需要非 ClusterIP否则保持 ClusterIP 最省事也最安全。关于 HAK8s 上的 Flink 从较早版本开始支持用 ConfigMap 作为高可用存储high-availability.type: kubernetes配合high-availability.storageDir指向一个对象存储路径。这样 JobManager Pod 挂了新 Pod 起来能从 ConfigMap 里读到作业元数据从 Checkpoint 恢复。如果用的是基于 ZooKeeper 的 HA那就得在 K8s 里额外部署一套协调服务组件数量增加运维成本也上去我一般优先选原生方案。4.2 资源配置的三个关键字段与镜像准备K8s 上的资源控制有两层一层是 Flink 自己的内存模型taskmanager.memory.process.size等另一层是 Pod 的resources.requests和resources.limits。这两层必须对齐而且 Pod 的 limit 必须大于Flink 的 process size给日志采集、监控探针这些边车容器留出空间。一个典型配置是 process size 配 4096mPod 的requests.memory配 4Gilimits.memory配 5Gi。为什么 limit 要留余量因为 JVM 的进程内存并不是一个硬边界堆外分配、线程栈、本地库的映射内存都可能让实际占用略微超过配置值。如果 limit 和 process size 卡得一模一样很容易触发 OOMKilledPod 被 kubelet 直接干掉日志里只留一个OOMKilled状态什么堆栈都没有排查起来非常痛苦。我踩过一次一个作业稳定跑了三天后突然间歇性 OOMKilled最后发现是某个序列化框架在堆外申请内存刚好把余量吃干净了把 limit 从 4Gi 调到 5Gi 就再没出现过。镜像准备这块思路有两种。一种是直接用官方的 Flink 镜像把用户 jar 和依赖通过-Dkubernetes.jobmanager.volume之类的挂载进去另一种是自己构建镜像把 Flink 发行包、用户 jar、配置文件一起打进去提交时只指定镜像名和入口类。前者灵活、升级方便后者部署简单、启动快因为不用每次拉 jar。团队规模小、作业数量少的时候我倾向后者作业多、需要频繁更新代码的时候用前者。还有一个细节要注意kubernetes.container.image.pull-policy建议设成IfNotPresent配合固定的镜像 tag 使用。如果设成Always每次起 Pod 都要去仓库确认一遍节点上镜像大了之后拉取时间能拖到几十秒作业启动变慢而且仓库抖动会直接影响作业启动成功率。用latest这种浮动 tag 更是自找麻烦回滚都回不去。4.3 Pod 模板与临时存储的处理Flink 的 K8s 部署支持通过kubernetes.pod-template-file指定 Pod 模板这一点在生产里非常有用。我通常会在模板里干三件事给容器加节点亲和性和污点容忍让 TM 只调度到指定的机器池挂载一个emptyDir到 Flink 的临时目录避免容器根文件系统写满配置资源限制和环境变量。临时存储这个问题特别值得说。Flink 的 TaskManager 在跑批作业或者大规模 Shuffle 的时候会把中间结果写到本地磁盘默认路径在容器内的临时目录。容器的根文件系统通常不大写满之后会触发节点驱逐Pod 直接消失作业失败日志里看到的只是一个模糊的容器退出码。解决办法是挂载一个emptyDir到taskmanager.tmp.dirs指定的路径emptyDir的大小可以通过sizeLimit限制用medium: Memory还能走内存盘但对内存消耗要算进 limit 里。这个改动看着小实际能省掉很多“莫名其妙挂掉”的问题。日志采集也是同理Pod 销毁日志就没了。要么把日志目录挂到持久卷要么依赖节点的日志采集代理把 stdout 收走。Flink 容器里的日志默认输出到文件需要通过log4j-console.properties让一部分关键日志同时打到 stdout否则采集代理抓不到东西。提示K8s 环境里排查作业启动失败第一步永远是kubectl describe pod看 Events 里的调度失败原因和容器退出码比看 Flink 日志快十倍。退出码 137 基本就是 OOMKilled 或者被驱逐。5. 资源与并行度的换算Slot、TaskManager 与内存模型5.1 Slot 共享机制与并行度的对应关系Slot 是 Flink 里的资源单位一个 TaskManager 按numberOfTaskSlots切成若干份每个 Slot 能跑一个并行子任务。但 Slot 只隔离内存不隔离 CPU——同一个 TM 里的多个 Slot 共享这台机器的 CPU 核靠操作系统的调度去争抢。理解这一点很关键因为它解释了为什么“Slot 配多了不一定更快”。Slot 共享Slot Sharing是另一个容易搞混的概念。同一个作业的不同算子默认可以共享一个 Slot比如 source 的并行度是 4、map 的并行度是 4、sink 的并行度是 4它们可以全部塞进 4 个 Slot 里每个 Slot 里跑一条“source→map→sink”的完整链路。这个设计的目的是避免“source 在忙、sink 在闲”的资源浪费让 Slot 内的资源得到充分利用。所以一个作业所需的最小 Slot 数不是所有算子并行度之和而是所有算子并行度的最大值。举个具体例子作业里 source 并行度 4flatMap 并行度 8keyBy 后 window 并行度 8sink 并行度 4。这个作业需要的 Slot 数是 8不是 24。如果 TM 配了 4 个 Slot那就需要 2 个 TM。这个算法在规划资源的时候必须算清楚否则要么申请多了浪费要么申请少了报NoResourceAvailableException。什么时候需要关掉 Slot 共享当作业里有重算子比如大窗口聚合和轻算子比如简单的过滤混在一起时共享 Slot 会让它们互相拖累重的那个把 CPU 占满轻的只能等。这种场景可以用slotSharingGroup把重算子单独拎出来分组让它们独占 Slot。这是个进阶手段一般作业用不上但遇到“某个算子明显拖慢整体”的时候值得一试。5.2 内存模型拆解与一步步的计算过程Flink 从 1.10 开始用统一的内存模型配置入口是taskmanager.memory.process.size也就是整个 TM 进程的总内存。这个总内存往下分几层先扣掉 JVM Metaspace 和 JVM Overhead剩下的叫 Flink 总内存Flink 总内存里再分框架堆、框架堆外、任务堆、任务堆外、Managed Memory、Network Memory。这几层的默认值都有推导规则理解规则比死记数值有用。我拿一个具体的配置走一遍计算。假设taskmanager.memory.process.size 4096m其他用默认值第一步jvm.metaspace.size默认 256m。第二步jvm.overhead默认按 process size 的 0.1 计算且限定在 192m 到 1024m 之间。4096 × 0.1 409.6取 410m 左右。第三步Flink 总内存 4096 - 256 - 410 3430m。第四步Network Memory 默认按 Flink 总内存的 0.1 计算限定在 64m 到 1024m 之间。3430 × 0.1 343m。第五步Managed Memory 默认按 Flink 总内存的 0.4 计算3430 × 0.4 1372m。这部分是给 RocksDB 状态后端和批处理算子用的。第六步框架堆 128m、框架堆外 128m、任务堆外 0m默认。第七步任务堆 3430 - 343 - 1372 - 128 - 128 - 0 1459m。这个结果意味着什么意味着用户代码能用的堆只有 1.4G 左右。很多人在配 4G 的 TM 之后发现作业老是 GC 频繁甚至 OOM就是没意识到一半以上的内存被 Managed Memory 和网络缓冲吃掉了。如果你的作业不用 RocksDB、状态很小可以把taskmanager.memory.managed.fraction调低到 0.2 甚至 0.1把内存还给任务堆如果用了 RocksDB 且状态很大那就得反向操作把 managed fraction 调高同时把 process size 加大。内存分区默认规则4096m 时的实际值调整建议JVM Metaspace固定 256m256m类加载多时调到 384mJVM Overhead10%192m~1024m约 410m一般不动Network Memory10%64m~1024m约 343mShuffle 大时调高Managed Memory40% of Flink 总内存约 1372m无 RocksDB 时降到 0.2Framework Heap128m128m一般不动Task Heap剩余部分约 1459m用户代码可用内存5.3 一个 8 并行度作业的完整资源规划实例假设有一个实时作业source 并行度 8处理链路并行度 8sink 并行度 4作业需要的 Slot 数是 8。现在要决定 TM 怎么配。先定 Slot 数。假设每个 TM 所在机器 4 核那就把numberOfTaskSlots设成 4避免 CPU 超卖。8 个 Slot 除以每个 TM 4 个需要 2 个 TM。再定内存。假设作业状态不大几 GB 以内用 RocksDB 增量 Checkpoint那么每个 TM 配 4G process size 差不多Managed Memory 有 1.3G 左右够用。如果状态到了几十 GB就要把 process size 提到 8G 甚至 16G同时 managed fraction 保持 0.4 以上。然后是 YARN 或 K8s 侧的配额。YARN 要确认队列的maximum-allocation-mb不小于 4096maximum-allocation-vcores不小于 4。K8s 要确认命名空间的ResourceQuota允许 2 个 4Gi 的 Pod节点上有足够的可分配资源。这些配额限制看着是运维的事但规划阶段不确认提交时就会被拒白白浪费一轮调试时间。最后算一下总资源账2 个 TM × 4G 8G 内存2 个 TM × 4 vCore 8 核加上 JobManager 的 2G 内存和 1 核。这个账我一般会在提交前写进变更单里出问题的时候对照着看很容易发现是哪一层配少了。6. 高可用、状态与容错配置6.1 HA 配置的三种组合与选择HA 的核心是两件事JobManager 挂了谁来接管以及新起来的 JobManager 从哪里读到作业元数据。第一种组合是外部协调服务加共享存储配置high-availability: zookeeper、high-availability.storageDir指向 HDFS 或对象存储路径。这套方案成熟稳定但要多维护一套协调服务组件越多故障面越大。第二种是 K8s 原生 HAhigh-availability.type: kubernetes元数据存在 ConfigMap 里状态存在对象存储。这套的好处是不引入额外组件坏处是 ConfigMap 有大小限制大约 1MB如果作业的 JobGraph 特别大算子特别多、序列化后的 DAG 很复杂可能会超出限制导致 HA 写入失败。我遇到过一例一个自动生成的超大 DAG 作业HA 一直报写入失败最后是靠拆分作业解决的。第三种是 Standalone 环境下的单点容忍即不配 HA靠外部脚本监控进程、挂了就重启然后手动从 Savepoint 恢复。这种方式只适合能接受分钟级中断的场景线上核心作业不要这么干。不管用哪种组合high-availability.cluster-id都要显式设置尤其是 YARN 的 Application 模式和 K8s 环境集群 ID 是恢复时识别“这是同一个作业”的依据。ID 没设对重启后新集群找不到旧元数据只能从零开始状态全丢。6.2 Checkpoint 配置的取舍与状态后端选择Checkpoint 的配置里我最关注四个参数间隔、超时、最小间隔、可容忍失败次数。间隔太短会让作业频繁做快照挤占正常处理的时间间隔太长则恢复时要重放很多数据。经验值是间隔设在 1 到 5 分钟超时设为间隔的 3 到 5 倍最小间隔设为间隔的一半左右可容忍失败次数给 2 到 3 次。状态后端这块现在基本就两个选择内存型HashMapStateBackend和 RocksDB。状态在几百 MB 以内、对延迟极敏感的作业用内存型读写没有序列化开销但状态大小受堆限制且全量 Checkpoint 每次都把整个状态写一遍。状态在 GB 级以上、需要增量 Checkpoint 的作业用 RocksDB状态存在本地磁盘的 SST 文件里Checkpoint 只上传增量部分代价是读写有序列化开销延迟略高。RocksDB 的增量 Checkpoint 有几个前提Checkpoint 存储必须是支持原子重命名的文件系统对象存储在部分实现上需要注意且必须开启state.backend.incremental: true。不开这个开关RocksDB 也做全量上传一个几十 GB 的状态每次全传网络和存储压力都很大还容易超时。我在一个作业上量过开了增量之后 Checkpoint 耗时从 90 秒降到 8 秒效果非常直观。注意Checkpoint 存储路径不要和 HA 存储路径混在一起两者生命周期不同HA 只保留最新一份Checkpoint 要保留多份用于回滚。分开存能避免清理策略互相干扰。7. 常见问题与排查实录7.1 高频故障速查表下面这张表是我这些年攒下来的基本都是现场排查过的问题按报错关键词索引现象 / 报错关键词大概率原因处理方向NoResourceAvailableExceptionSlot 不够或并行度超过 Slot 总数算清最大并行度扩 TM 或调并行度Container killed by YARN for exceeding memory limits容器内存小于进程实际占用核对 process size 与容器配额留 10% 余量Pod 状态OOMKilledK8s limit 太紧limit 至少比 process size 高 1Gi作业提交报NoSuchMethodError客户端 classpath 污染改用 Application 模式或清理客户端依赖提交后卡在“正在提交”客户端连不上 JobManager 端口检查网络策略或改用 Application 模式Checkpoint 持续失败存储写入慢或状态太大换存储、开增量、调大超时TaskManager 频繁掉线但无异常日志心跳超时或 GC 停顿过长看 GC 日志调大心跳超时加内存反压指标长期红下游算子处理能力不足定位瓶颈算子扩并行度或优化逻辑作业重启后状态丢失HA 元数据没读到或 cluster-id 变了核对 HA 配置与 cluster-id容器被驱逐退出码 137临时存储写满或内存超限挂载 emptyDir检查磁盘用量表格用起来快但有两个前提要清楚。一是报错关键词要抓准很多异常的根因藏在 WARN 级别日志里不在 ERROR 里二是排查顺序永远是“先看资源、再看网络、最后看代码”因为资源问题最容易验证代码问题最难定位。我见过太多人一上来就怀疑代码逻辑翻了两小时源码最后发现是 Slot 数配少了。7.2 几个不写在文档里的实操经验第一个经验先跑一个最小作业探路。换新环境、上新部署模式的时候不要直接拿正式作业去试先提交一个fromElements(1).print()这样的最小作业验证“提交链路通不通、资源能不能申请到、日志能不能看到、Web UI 能不能访问”。这一步花五分钟能省掉后面几个小时的瞎猜。我换 K8s 环境的时候就是这么干的最小作业直接卡在镜像拉取上一眼就看出是私有仓库的凭证没配。第二个经验Slot 数不要超过物理核数。这条我前面提过一次但值得再说因为它的危害是隐性的——不是报错而是性能缓慢下降。8 个 Slot 挤在 2 核上CPU 上下文切换的开销能吃掉三成吞吐而且监控上看 CPU 占用率很高容易误判成“资源不够要扩容”实际是配错了。第三个经验日志级别不要长期开 DEBUG。排查问题的时候开 DEBUG 很爽但忘了关就是灾难。DEBUG 日志的 IO 开销在大流量下非常可观更麻烦的是磁盘会被迅速写满容器环境里直接触发驱逐。我一般会在配置里给 DEBUG 加一个过期提醒或者干脆用运行时的 REST 接口临时改级别排查完就改回去。第四个经验Savepoint 和 Checkpoint 要分开管。Checkpoint 是自动的、滚动的、会被清理的Savepoint 是手动的、带版本语义的、要长期保留的。做版本升级、逻辑变更、集群迁移之前必须先打一个 Savepoint 并验证它能恢复。我习惯在变更前打 Savepoint然后在测试集群上先验证恢复流程确认没问题再动生产这个习惯救过我好几次。第五个经验给每套环境算一笔资源账。把并行度、Slot 数、TM 数、每个 TM 的内存、JobManager 内存、总核数、总内存这些列成一张表贴在变更单或者文档里。这套账目在扩容、缩容、迁移的时候是基准线出问题的时候一对照就能发现哪里不对。凭感觉配参数的人早晚会在某个深夜被叫起来改配置。最后再补充一个关于模式迁移的观察。从 Standalone 迁到 YARN或者从 YARN 迁到 K8s真正的难点不在提交命令的变化而在依赖管理和日志可见性。Standalone 时代jar 和配置都在本机出了问题直接看本机日志到了 YARN 和 K8sjar 要在集群侧可达日志要通过聚合系统去捞。我建议在迁移之前先把这两件事在新环境里跑通——用最小作业验证 jar 分发、用日志聚合验证能查到历史日志然后再动正式作业。这两步做完迁移过程中的大部分“玄学问题”都会变成可解释的常规问题。