如何在Kubernetes上部署高可用的Redis集群？-Redis-PHP中文网

结论是：statefulset + headless service + persistentvolumeclaim 是唯一能稳定运行 redis cluster 的组合，因为 deployment 无法提供固定 hostname、可解析 dns 和专属持久化存储，导致 pod 重启后 ip 和节点信息失效，引发脑裂或 clusterdown 错误。

如何在kubernetes上部署高可用的redis集群？

直接说结论：用 StatefulSet + Headless Service + PersistentVolumeClaim 是唯一能稳定跑通 Redis Cluster 的组合，其他方式（比如 Deployment）在节点重建或 IP 变更后必然导致集群脑裂或 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 中必须设置的关键字段

漏掉任意一项，集群初始化就会卡在 “Waiting for cluster to join” 或反复触发 MOVED 重定向失败。

Kubernetes Security Posture Scorecard

评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……

下载

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 后，它们只是“活着”，不是“组成了集群”。常见错误是等 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 会被重写，且内容各不相同 —— 这是验证是否真正组网成功的最可靠依据