HashiCorp Vault Helm部署后Pod反复出现seal/unseal循环原因排查

• 核心原因是存储后端配置冲突：你在values.yaml中同时启用了Raft和Consul两种存储后端：
  • 配置了ha.raft.enabled=true，指定了Raft存储配置
  • 又在ha.config中配置了Consul存储参数
    Vault启动时会出现存储后端加载逻辑冲突，非Leader节点会短暂出现状态同步异常，返回未初始化、已封存的探针检测结果，同步完成后状态恢复正常，所以出现循环告警又自动恢复的现象。你看到UI全程可用是因为UI流量会被路由到正常的Leader节点，所以不会受非Leader节点临时状态异常的影响。
• 次要原因是就绪探针配置缺陷：默认的就绪探针调用vault status时没有跳过TLS验证，你配置的VAULT_ADDR为HTTPS域名，如果探针所在容器内部不信任TLS证书、或者域名无法在集群内部解析，就会出现请求失败，误判为未就绪。
• 额外触发因素：Raft集群的Follower节点和Leader进行状态同步时本身存在毫秒级的延迟，如果探针检测频率过高，刚好命中同步窗口也会触发临时告警。

1. 移除重复存储配置，保持仅有一种存储后端：
   • 如果使用Raft存储，直接删除ha.config字段下的全部配置内容，仅保留ha.raft.config的配置即可
   • 如果使用Consul存储，将ha.raft.enabled设置为false，删除ha.raft相关的所有配置
2. 调整就绪探针配置，适配HTTPS场景，在values.yaml中新增以下配置：

server:
  readinessProbe:
    exec:
      command: ["/bin/sh", "-c", "VAULT_ADDR=https://127.0.0.1:8200 vault status -tls-skip-verify"]
    initialDelaySeconds: 15
    periodSeconds: 10
    failureThreshold: 3

该配置将探针请求地址改为本地环回地址，同时跳过TLS验证，避免依赖外部域名解析和证书信任。
3. 如果告警仍然存在，可以适当调高failureThreshold的数值，允许少量同步窗口的探针失败，避免误告警。

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