cluster_state:fail 是因节点间IP不一致导致“认不出彼此”，主因是 cluster-announce-ip 未设为 $(POD_IP) 或 nodes.conf 残留旧IP，需用 Downward API 注入并自动修正。
redis-cli cluster info 显示 cluster_state:fail 怎么快速确认原因
直接进任意一个Pod执行 redis-cli cluster info，如果第一行是 cluster_state:fail，基本可以锁定是节点间互相“认不出彼此”了。这不是Redis自身崩溃，而是集群元数据中记录的IP和当前实际Pod IP不一致。常见诱因包括：节点重启、滚动更新、Node故障触发Pod漂移到新机器、或者初始部署时没固化宣告地址。
--cluster-announce-ip 必须用 $(POD_IP)，不能写死或用 hostname
Redis 7.0 的集群发现机制默认基于绑定地址（bind）和本地网络接口推导对外宣告IP，但在K8s里这会变成 Pod 内部的随机IP，且重启即失效。必须显式覆盖：
-
--cluster-announce-ip的值必须来自 K8s Downward API 注入的$(POD_IP)，不是$(HOSTNAME)，也不是硬编码的10.244.x.x - 环境变量注入要完整写成：
valueFrom: fieldRef: fieldPath: status.podIP（注意是status.podIP，不是spec.nodeName或其他） - 如果用了
initContainer预生成nodes.conf，它里面写的IP也得同步替换——否则 Redis 启动时读到旧IP仍会广播错误信息
nodes.conf 文件残留旧IP会导致集群反复失联
Redis 启动后会把当前节点信息写入 /var/lib/redis/nodes.conf（路径由 cluster-config-file 指定）。这个文件不会自动刷新，Pod 重启后若没清理或重写，里面存的还是上一次的IP，导致整个集群“集体失忆”。解决方法有两种：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在容器启动前加一个
initContainer，用sed -i替换nodes.conf中匹配myself行的旧IP为当前$POD_IP - 或在主容器
command前插入 shell 脚本段，检查并修正该文件（参考fix-pod-ip.sh的逻辑） - 切忌手动进 PV 修改——除非你确定该PV只被这一个Pod挂载，且已停掉所有Redis实例，否则极易引发脑裂
StatefulSet 不是银弹，但能规避 80% 的IP漂移问题
如果你还在用 Deployment 部署 Redis 集群，现在就该停下来评估迁移。StatefulSet 提供的稳定主机名（如 redis-0.redis-headless.default.svc.cluster.local）和有序启停，天然适配 Redis 集群对节点身份一致性的要求。但要注意：
- 必须搭配无头 Service（
clusterIP: None），否则 DNS 解析不到单个 Pod - 每个 Pod 的
cluster-announce-ip仍建议设为$(POD_IP)，不要图省事设成 Service 名——Redis 集群通信走的是点对点 TCP，不经过 kube-proxy - 若已用 Deployment 上线，可先加
--cluster-announce-ip+nodes.conf自动修复脚本稳住局面，再排期迁移到 StatefulSet
真正容易被忽略的点是：即使配置全对，第一次创建集群时，如果 redis-cli --cluster create 命令传入的节点地址用了 Service 名而非 Pod IP，生成的 nodes.conf 初始内容就带错——后续所有修复都只是在补漏。所以初始化那一步，必须确保命令里填的是每个 Pod 当前可解析的稳定 DNS 名（即 StatefulSet 的 pod-name.service-name.ns.svc.cluster.local）或明确的 $(POD_IP)。
