部署Flink Kubernetes Operator时的并行度计算疑问

核心计算逻辑 #

你看到的并行度10，本质是集群总TaskSlot数：TaskManager副本数（2） × 每个TaskManager的Slot数（5）= 10。下面分场景解释两种情况的差异：

场景1：注释taskManager.replicas时 #

此时Flink Kubernetes Operator会根据你设置的job.parallelism=2自动调度最少的TaskManager资源——1个TaskManager（自带5个Slot）就能满足2并行度的需求，所以作业以并行度2运行，符合预期。

场景2：设置taskManager.replicas=2时并行度变为10的原因 #

出现这种情况大概率是以下两种原因之一：

1. Savepoint恢复沿用旧并行度
   你的作业配置中upgradeMode: savepoint，如果之前的作业是以并行度10运行并生成了savepoint，恢复作业时Flink会优先使用savepoint中保存的并行度配置，直接覆盖你当前设置的job.parallelism=2。

2. Flink Operator自动调整并行度
   部分版本的Flink Kubernetes Operator存在逻辑：当显式指定taskManager.replicas时，会自动将作业并行度设置为集群总Slot数（即2×5=10），忽略job.parallelism的配置。

验证与解决建议 #

• 临时修改upgradeMode: stateless，不带savepoint重新提交作业，观察并行度是否回到2，以此验证是否是savepoint导致的问题。
• 检查作业代码中所有算子是否显式设置了并行度，如果有算子硬编码了并行度10，也会导致整体并行度被拉满。
• 若Operator自动调整的问题，可尝试在flinkConfiguration中显式添加job.parallelism: "2"，覆盖Operator的自动逻辑。

内容的提问来源于stack exchange，提问作者Yabha