一、背景

Flink版本为1.14.6，采用Flink on native k8s模式部署，以Application方式提交运行作业；另外，有一个Flink作业调度管理平台，每次作业停止操作都会在调度管理平台调用Flink的stop-with-savepoint脚本。

二、问题现象

一个Flink作业重启后，运行快速失败

三、问题排查

• 查看暂停日志

  • JM发起3次savepoint_suspend的cp均失败（failed to complete checkpoint）

  • Flink作业被强制停止（JM日志报cannot found deployment xxxx）

• 查看启动日志

  • JM从sp恢复拉起作业，作业报错恢复失败（状态kakfa-offset数据过期）

• 查看作业的cp/sp

  • cp状态丢失，sp仅有一个半年前的状态

四、问题分析

• 现有调度平台Flink作业暂停逻辑分析

  1.使用flink stop-with-savepoint暂停作业（包含3次重试）

  2.检测作业状态，若未停止，则执行k8s的kubectl delete命令强制删除

• Flink1.14.6原生停止脚本逻辑分析

  1.执行sp操作

  2.删除cp数据

  3.优雅停止作业

  过程中存在异步操作，同时没有事务管理，初步评估在执行sp失败且删除cp成功的场景下有丢失最近的cp/sp概率

• CP失败常见原因

  1.资源不足：内存、磁盘、cpu/线程竞争

  2.背压：barrier无法及时传递，超时失败

  3.状态过大

  4.外部依赖故障：上下游组件异常阻塞

  5.配置不合理：cp太频繁、超时太短

  6.网络问题：网络长时间抖动延迟

五、问题结论

• 原生Flink1.14.6停止脚本存在小概率丢状态风险

六、解决方案

• 完善Flink作业暂停的处理逻辑，保障有最近可用的cp/sp

  1. 调用flink stop脚本前，先将最近成功的cp备份

  2. 判断作业停止状态增加JM-deployment与TM-pod状态检测

• 加强Flink作业运行异常指标告警

  1. cp连续失败告警

  2. 作业重启次数告警

  3. 数据消费延迟告警

七、总结

我们在使用开源组件技术的过程中，系统功能设计上尽量将组件作为可用的工具，多考虑整体的健壮性与鲁棒性。