生产环境必须用 bitnami/redis-cluster Helm Chart 或 StatefulSet+Headless Service+initContainer 部署；禁用 Deployment，因其 Pod 无稳定 DNS 域名，导致 Redis Cluster 节点无法通过 gossip 正确发现与握手。
直接上结论：生产环境别手写 YAML 部署 Redis Cluster，优先用 bitnami/redis-cluster Helm Chart；若必须自建，StatefulSet + Headless Service + initContainer 初始化是唯一稳妥路径。
为什么不能用 Deployment 部署 Redis Cluster
Deployment 生成的 Pod 没有稳定网络标识（如固定 hostname、DNS A 记录），而 Redis Cluster 节点间依赖 gossip 协议通信，必须通过可解析的域名互相发现。Deployment 的 Pod 名称随机、IP 变更后 DNS 不刷新，会导致 CLUSTER NODES 输出中节点地址失效、握手失败、槽位无法分配。
常见错误现象包括：
-
Node xxx is not reachable（实际能 ping 通，但 redis-cli cluster nodes 显示 unreachable） - 集群初始化后只有部分节点上线，
redis-cli --cluster check报Can't connect to node - 扩容新节点后，老节点无法识别其 IP，
cluster meet失败
根本原因是：Deployment 不提供 pod-name.service-name.namespace.svc.cluster.local 这类可预测的 DNS 名，而 StatefulSet 的每个 Pod 都有固定序号和可解析域名（如 redis-cluster-0.redis-headless.default.svc.cluster.local）。
StatefulSet 初始化集群必须用 initContainer
Redis Cluster 要求所有节点先启动、再执行 redis-cli --cluster create 命令完成槽位分配。但 StatefulSet 默认按顺序创建 Pod（0→1→2…），如果在主容器里判断“是否为第一个 Pod 并执行 create”，会因竞争条件失败——多个 Pod 同时尝试初始化，或部分 Pod 尚未就绪就被调用 meet。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确做法是分离“等待集群就绪”和“执行初始化”两个阶段：
- initContainer 中用
until nslookup redis-cluster-0.redis-headless; do sleep 2; done等待全部 Pod DNS 可解析 - 主容器启动前，由一个专用 initContainer（如
redis-cluster-init镜像）在 Pod 0 上执行redis-cli --cluster create，其他 Pod 跳过 - 避免在 ConfigMap 或环境变量里硬编码所有节点 IP，改用 DNS 名（如
redis-cluster-0.redis-headless:6379）
漏掉 initContainer 或逻辑写在主容器里，会导致集群卡在 “no cluster configuration” 状态，redis-cli cluster info 返回 cluster_state:fail。
ConfigMap 更新后 Pod 不自动重载配置
Redis Cluster 的 redis.conf 里 cluster-config-file 是运行时自动生成的（如 /data/nodes.conf），不可被 ConfigMap 替换；但其他配置项（如 cluster-node-timeout、appendonly）修改后，不会热生效。
必须重启 Pod 才能加载新配置，且要注意：
-
kubectl delete pod redis-cluster-0会触发 StatefulSet 重建，但新 Pod 启动时会复用原有 PVC，nodes.conf保留旧集群状态，一般能自动加入 - 如果修改的是影响集群拓扑的参数（如
cluster-enabled），必须先redis-cli cluster reset再重建，否则报ERR This instance has cluster support disabled - 不要用
rollingUpdate直接更新整个 StatefulSet，应逐个滚动，避免多节点同时离线导致槽位不可用
最容易被忽略的一点：ConfigMap 挂载进容器后是只读的，但 redis-server 启动时会尝试写入 nodes.conf 到同一目录——必须确保该目录挂载的是可写的 EmptyDir 或 PVC，否则容器 CrashLoopBackOff，日志里出现 Cannot open or create the cluster configuration file。
