先直接给出结论：如果想让 Redis Cluster 在 Kubernetes 中长期、稳定运行，真正可靠的方案只有 StatefulSet + Headless Service + PersistentVolumeClaim。原因并不难理解：Deployment 天生无法提供固定 hostname、可解析的 DNS，以及每个实例独占的持久化存储。一旦 Pod 重启，IP 和节点身份信息都可能发生变化，带来的通常不只是短暂抖动，更可能出现集群脑裂，甚至直接触发 CLUSTERDOWN 错误。
结论很明确：在 Kubernetes 部署高可用 Redis Cluster 时，只有 StatefulSet + Headless Service + PersistentVolumeClaim 这一组合能够稳定跑通。其他方案，例如 Deployment，在节点重建、Pod 漂移或 IP 变更之后，几乎必然导致 Redis 集群脑裂，或者出现 CLUSTERDOWN 错误。
为什么不能用 Deployment 部署 Redis Cluster
Redis Cluster 节点之间的协作依赖 gossip 协议。因此，每个节点都必须具备一套稳定的“身份标识”：固定 hostname、可解析的 DNS 名称，以及不会随意变化的数据存储路径。问题正出在这里：Deployment 创建的 Pod 一旦重启，IP 可能变化、hostname 也可能变化，同时还无法天然绑定独立 PVC。这样一来，nodes.conf 中保存的仍然是旧地址，地址信息一旦失效，新节点就难以正确加入集群，redis-cli --cluster check 也会持续报错，例如 Node XXX is not connected，或 ERR Node XXX is not in cluster。
StatefulSet能提供稳定的pod-name-0、pod-name-1这类有序命名，结合Headless Service后，可稳定解析为redis-cluster-0.redis-cluster.default.svc.cluster.local- 每个 Pod 都必须挂载独立 PVC，否则多个实例共用同一份
nodes.conf会互相覆盖，最终造成槽位元数据冲突 - 镜像启动参数必须包含
--cluster-enabled yes，而且不能完全依赖默认配置；尤其是较新的redis:6.2+镜像，默认并未开启集群模式
StatefulSet 中必须设置的关键字段
其中任何一项缺失，Redis 集群初始化都可能卡在 “Waiting for cluster to join”，或者反复出现 MOVED 重定向失败的问题。
serviceName必须指向一个Headless Service（clusterIP: None），否则无法通过 DNS 解析到 Pod 的 A 记录volumeClaimTemplates中的accessModes必须设置为["ReadWriteOnce"]，因此只有 NFS、Longhorn 等支持该模式的存储类才适合使用；而ReadWriteMany在大多数场景下都容易引发nodes.conf写入竞争- 容器的
env中需要显式注入POD_IP，用于动态替换nodes.conf里的旧 IP，很多实战教程会通过update-node.sh脚本来处理这一步 - 启动命令需要绕过镜像默认配置，例如：
command: ["/bin/sh", "-c", "sed -i 's/.*bind.*/bind 0.0.0.0/g' /etc/redis/redis.conf && exec redis-server /etc/redis/redis.conf"]
集群初始化必须在所有 Pod Ready 后手动执行
Kubernetes 不会自动帮你执行 redis-cli --cluster create。也就是说，StatefulSet 创建出 6 个 Pod 之后，它们只是“已经启动”，并不代表“已经组成 Redis 集群”。很多人常见的误区是看到 Pod 进入 Ready 状态就认为部署完成，结果执行 CLUSTER INFO 时仍然返回 cluster_state:fail。
- 可以先执行
kubectl exec -it redis-cluster-0 -- redis-cli -p 6379 CLUSTER NODES检查状态；如果只有一行输出，并且connected为0，就说明集群尚未初始化 - 必须进入任意一个 Pod 手动执行：
redis-cli --cluster create $(seq 0 5 | xargs -I{} echo "redis-cluster-{}.redis-cluster.default.svc.cluster.local:6379") --cluster-replicas 1 - 如果提示
Sorry, Redis Cluster only supports the default port (6379)，通常说明某个 Pod 的containerPort配置错误，或者 Service 的targetPort指向了错误端口 - 初始化成功后，每个 Pod 的
/data/nodes.conf都会被重新写入，而且内容彼此不同——这是判断 Redis Cluster 是否真正成功组网的最可靠依据之一
扩容时槽位迁移必须人工介入
扩容 Redis Cluster 并不是简单把 replicas 数量调大就结束了。StatefulSet 扩容后，新的 Pod 的确会启动，但 Redis Cluster 不会自动把槽位分配给新节点，甚至可能因为 cluster_require_full_coverage no 配置不当，导致整个集群拒绝写入。
- 先执行
redis-cli --cluster add-node 新节点地址 任一老节点地址，把新节点加入现有集群 - 再通过
redis-cli --cluster reshard手动迁移槽位，并明确指定迁移数量、目标节点 ID 与来源节点 ID - 最后再使用
redis-cli --cluster rebalance做槽位均衡分布，但要谨慎操作，因为这一步可能带来大量数据迁移 - 务必确认新节点已经成为
master，并且在CLUSTER NODES中状态为connected，然后再去更新应用的连接字符串
还有一个最容易被忽视的细节：所有节点的 cluster-node-timeout 必须保持一致，而且不能低于网络 P99 延迟的 3 倍。在 Kubernetes 环境里，尤其是跨 AZ 或跨节点通信时，网络延迟通常会更高，因此建议将它设置为 15000 作为最低参考值；如果设置过小，就会频繁误判节点失联，进而触发不必要的主从切换，影响 Redis 集群稳定性。
