Kubernetes部署高可用Redis集群实战指南

先直接给出结论：如果想让 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 集群稳定性。