Flink Kubernetes HA（高可用）实战原理、前置条件、配置项与数据保留机制

1. Kubernetes HA 的核心思路

Kubernetes HA 服务承担 Flink HA 的"协调部分"，典型职责包括：

• Leader election：选出唯一 Leader JobManager
• Service discovery：让组件找到当前 Leader
• 轻量一致性状态存储：用 Kubernetes 资源（典型是 ConfigMap）保存协调信息与指针

同时要注意一点：和 ZooKeeper HA 一样，Flink 的 JobManager 元数据不会直接都塞进 Kubernetes 里，而是写入 high-availability.storageDir 指向的文件系统目录，Kubernetes 中只保存指针与协调信息。这能避免把大量数据压到 apiserver/etcd 上。

2. 前置条件（Prerequisites）

要启用 Flink Kubernetes HA，需要满足：

• Kubernetes 版本 >= 1.9
• 运行 Flink 的 ServiceAccount 具备对 ConfigMaps 的权限：create / edit / delete

通常这意味着你需要在目标 namespace 里配置 RBAC：Role + RoleBinding（或 ClusterRole/ClusterRoleBinding，视你的安全策略而定）。

2.1 一个最小可用的 RBAC 示例（namespace 级）

下面示例只授予 ConfigMap 的必要权限（你可以按实际再收敛资源范围）：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: flink-sa
  namespace: flink
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: flink-ha-role
  namespace: flink
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: flink-ha-rb
  namespace: flink
subjects:
  - kind: ServiceAccount
    name: flink-sa
    namespace: flink
roleRef:
  kind: Role
  name: flink-ha-role
  apiGroup: rbac.authorization.k8s.io

如果你用的是 Flink 原生 K8s 集成或 Helm Chart，通常也会有对应的 SA/RBAC 模板，可以在此基础上确认是否包含 ConfigMaps 相关权限。

3. 必配配置项：启动 Kubernetes HA 集群的最小集合

在 flink-conf.yaml（或等效配置注入方式）里，至少要配置以下三项：

3.1 high-availability.type（必配）

high-availability.type: kubernetes

3.2 high-availability.storageDir（必配）

high-availability.storageDir: s3://flink/recovery

这是最关键的持久化目录：保存 JobManager 故障恢复所需的元数据。实际生产中你应放在高可靠的远端存储上：

• HDFS：hdfs:///flink/recovery
• 对象存储：S3 / OSS / GCS / ABFS 等（注意对应 FileSystem 插件要按 plugins 方式安装并能访问凭证）

3.3 kubernetes.cluster-id（必配）

kubernetes.cluster-id: cluster1337

它用于标识 Flink 集群（非常重要）。在 K8s HA 模式下，Flink 会使用这个 cluster-id 作为关联资源命名/选择器的一部分，用来区分不同 Flink 集群的 HA 协调数据。

4. 示例配置片段（可直接用）

kubernetes.cluster-id: <cluster-id>
high-availability.type: kubernetes
high-availability.storageDir: hdfs:///flink/recovery

你也可以把 storageDir 放对象存储，但务必确认：

• 已安装对应 FS 插件到 plugins/<fs-plugin>/
• 凭证与 endpoint 配置在正确的位置（插件隔离下，credential provider 也要放进同插件目录）

5. HA 数据清理与"删 Deployment 仍可恢复作业"的机制

Kubernetes HA 模式最实用的一点是：你可以通过删除 Deployment 来重启集群，同时保留 HA 数据，从而让作业自动恢复。

文档描述的行为是：

• 执行 kubectl delete deployment <cluster-id> 删除 Flink 集群部署

• Flink 集群相关资源会被删除，例如：

  • JobManager Deployment
  • TaskManager Pods
  • Services
  • Flink conf ConfigMap

• 但 HA 相关的 ConfigMaps 会被保留，因为它们不设置 owner reference（不被级联删除）

当你重新启动集群（同一个 kubernetes.cluster-id，同一个 high-availability.storageDir）时：

• 之前运行的作业会被恢复
• 并从最近一次成功的 checkpoint 继续重启

这也是生产上常见的"滚动重启/重建集群但不丢作业进度"的基础能力。

6. 生产实践建议

6.1 storageDir 一定要可靠且可持续访问

K8s HA 的协调信息在 ConfigMap，但真正的恢复元数据在 storageDir。storageDir 不可用会导致：

• JM 接管后无法恢复作业元数据
• 作业无法从最近 checkpoint 重启

6.2 cluster-id 必须稳定且唯一

• 同一集群重启恢复：cluster-id 必须保持不变
• 同一 namespace 多个 Flink 集群并存：cluster-id 必须不同，否则 HA 数据会串

6.3 RBAC 权限要"够用但不过大"

最低要能操作 ConfigMaps（含 create/update/delete）。如果权限不足，常见症状是：

• HA 初始化失败
• 无法选主或无法更新领导信息
• JobManager 反复重启

6.4 先验证"HA 可恢复"再上生产

建议在预发做一次演练：

1. 开启 checkpoint 并确保有成功 checkpoint
2. kubectl delete deployment <cluster-id>（或模拟 JM Pod 异常）
3. 重新部署同 cluster-id
4. 验证作业从最新 checkpoint 恢复而非从头开始