K8s单副本HashiCorp Vault已解封仍CrashLoopBackOff排查

Vault解封流程不强制要求3副本法定仲裁数，单副本模式完全可以正常解封运行，你遇到的CrashLoopBackOff是资源配置和HA适配两个问题叠加导致的，和副本数仲裁规则无关。

• 退出码137是典型的OOMKilled信号：你手动调低了资源request/limit配置，vault operator init和多次unseal操作会产生远高于日常运行的内存峰值，超出配置的内存上限后Pod会被系统直接发送SIGKILL信号终止，和你看到的命令执行完立刻退出、Pod重启的现象完全吻合。你可以执行kubectl describe pod vault-0查看上一次容器退出的Reason，会明确标注为OOMKilled。
• HA模式单节点适配缺失：你使用Consul作为存储后端开启了HA模式，默认配置下Vault启动后会尝试探测集群其他节点完成active节点选举，单副本场景下没有其他节点可以通信，会一直卡在standby状态（和你unseal返回结果里HA Mode: standby、Active Node Address: <none>的状态一致），如果配置了就绪/存活探针，会因为一直无法进入可用状态被kubelet触发重启。
• 额外注意：你之前exec进入Pod执行的unseal状态只保存在当前容器的内存中，只要Pod重启就会回到密封状态，这是Vault的正常安全设计，不是故障。

• 调整资源配额：将Vault的memory limit至少调高到1Gi（1.9.2版本单实例日常运行建议512Mi，init/unseal阶段峰值内存可达700-800Mi），调整后重启Pod先解决OOM问题。
• 适配单副本HA配置：在Vault的Consul存储配置段中添加redirect_addr = "http://vault-0.vault-internal:8200"参数，显式指定当前节点的通信地址，跳过多节点集群探测逻辑，启动后会直接选举自身为active节点，不会一直卡在standby状态。
• （可选）开启mlock配置：在Vault启动参数中添加-mlock=true，防止进程内存被交换到swap分区引发异常。
• 如果需要避免Pod每次重启都手动解封，可以配置KMS自动解封机制，不需要每次重启后手动输入密钥。

补充说明：Vault官方推荐3副本是为了满足高可用场景下的故障容忍能力（3节点可容忍1节点故障，5节点可容忍2节点故障），单节点部署仅会失去高可用能力，不存在无法解封、无法运行的限制。

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