Flink on K8S滚动更新时Checkpoint/Savepoint恢复机制问询

场景前提明确 #

• 作业部署在K8s，4个Pod对应4个TaskManager（每个算子并行度1，即source -> filter -> map -> sink各占一个Pod）
• 数据流配置为At-Least-Once或Exactly-Once一致性模式

问题1：当pod1（filter）重启时，source任务中的记录是否会立即保存到外部Checkpoint存储？ #

不会。Flink的Checkpoint是周期性触发的（由execution.checkpointing.interval配置），单个Pod重启属于K8s层面的运维操作，不会触发Flink立即执行Checkpoint。

但数据不会因此丢失：当K8s重启filter对应的Pod时，Flink JobManager会检测到该Task故障，触发整个作业的故障恢复流程。恢复时，Flink会加载最近一次成功完成的Checkpoint，将所有算子的状态恢复到该Checkpoint的时间点——包括Source算子记录的消费偏移量。之后Source会从该偏移量开始重新消费数据，确保所有数据都会被重新处理。

问题2：若滚动更新发生时Checkpoint尚未完成，map任务（pod3）中的当前处理数据是否会丢失？ #

不会丢失，但处理逻辑会根据一致性模式有所不同：

• 未完成的Checkpoint会因Task故障被直接丢弃，Flink会使用上一个已成功完成的Checkpoint作为恢复基准
• 对于Exactly-Once模式：
  Map任务中在未完成Checkpoint之后处理的数据，会在恢复后从Checkpoint的状态点重新处理，结合Sink端的两阶段提交（2PC）机制，最终只会被提交一次，既不丢失也不重复
• 对于At-Least-Once模式：
  Map任务的未提交数据会在恢复后被重新处理，可能会出现重复，但不会丢失

完整恢复流程（结合你的场景） #

1. K8s执行滚动更新，按顺序重启Pod（如pod1→pod2→pod3→pod4）
2. 当任意一个Pod（比如filter的pod1）被重启时，Flink JobManager检测到对应的TaskManager离线，触发作业故障恢复
3. Flink加载最近一次成功的Checkpoint/Savepoint，将所有算子的状态（包括Source的消费偏移量、Filter的过滤规则状态、Map的转换状态、Sink的提交状态）恢复到该Checkpoint的时间点
4. Source从Checkpoint记录的偏移量开始重新拉取数据，数据流依次经过Filter、Map、Sink重新处理
5. 根据一致性模式完成最终数据提交：
   • Exactly-Once：Sink通过2PC确保只有Checkpoint覆盖范围内的数据被提交，避免重复和丢失
   • At-Least-Once：Sink直接提交所有接收到的数据，可能存在重复但无数据丢失

额外注意事项 #

K8s滚动更新的参数（如maxUnavailable、maxSurge）需要和Flink的容错配置配合：建议不要同时重启多个TaskManager，避免多个Task同时故障导致Checkpoint无法正常完成，延长恢复时间。

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