基于K8部署Flink扩容TaskManager后重部署时HA功能异常

前置说明 #

该问题属于Flink 1.12版本Kubernetes HA模式的已知共性问题，核心根因为不同组件leader选举锁竞争、ConfigMap更新时序不一致，以及TM注册逻辑未做地址一致性校验。

排查步骤 #

• 校验HA核心配置正确性
  检查flink-conf.yaml中以下配置是否符合规范：

  high-availability: org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory
  high-availability.storageDir: <共享存储路径，所有JM、TM需具备读写权限>
  high-availability.kubernetes.namespace: <Flink集群部署的K8s命名空间>
  kubernetes.jobmanager.service-account: <绑定了ConfigMap读写权限的ServiceAccount>
  重点确认high-availability.kubernetes.leader-election.lease-duration默认值为15s，1.12版本该参数默认值过短，扩容TM时集群压力上升容易触发不必要的leader重选举。

• 核对JM组件leader归属
  分别拉取两个JobManager的运行日志，搜索LeaderElection关键字，确认Dispatcher和ResourceManager（RM）两个核心组件的leader是否运行在同一个JM进程上。1.12版本存在两个组件leader分属不同JM的bug，会直接导致ConfigMap中存储的两个组件leader地址不一致。
• 验证ConfigMap权限与更新状态
  确认备用JM进程是否具备ConfigMap修改权限，部分权限配置不当的场景下，备用JM失去ConfigMap写权限后，无法同步更新RM leader的地址信息，导致ConfigMap中存储的RM leader地址长期停留在旧的备用JM地址。
• 排查异常TM的连接逻辑
  拉取连接错误的TM日志，搜索Connect to ResourceManager关键字，确认1.12版本TM启动时优先读取RM leader的ConfigMap地址，不会自动对比Dispatcher的leader地址做一致性校验，因此RM地址异常时TM会直接连到错误JM且不会主动重试。

解决方案 #

无版本升级适配方案 #

• 调整leader选举超时参数，降低非必要重选举概率：

  high-availability.kubernetes.leader-election.lease-duration: 30s
  high-availability.kubernetes.leader-election.renew-deadline: 25s
  high-availability.kubernetes.leader-election.retry-period: 5s
  

• 扩容TM前增加一致性校验动作：执行kubectl annotate cm <集群HA对应的ConfigMap名称> flink.io/force-retry=yes，强制所有JM重新同步一次leader信息，确保RM和Dispatcher的leader地址一致后再执行TM扩容操作。
• 新增TM启动预校验逻辑：在TM的启动脚本中增加前置检查，先分别读取Dispatcher和RM的ConfigMap地址，如果两个地址不一致则延迟10s重试，连续3次校验不通过则主动退出，由K8s自动重建Pod，避免TM连接到错误的RM地址。

根因修复方案 #

该问题对应Flink社区FLINK-21189、FLINK-20961两个修复记录，升级Flink版本到1.13.2及以上即可彻底解决RM与Dispatcher leader不同步、TM无自动重连正确leader的缺陷。

临时应急方案 #

当已经出现地址不一致的故障时，直接删除存储RM leader信息的ConfigMap，Flink会自动触发新一轮leader选举，1分钟内即可同步所有组件的leader地址，异常TM会自动重连到正确的JM，无需重启整个集群。

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