Helm + Bitnami Redis Chart 部署哨兵集群是最可靠、最省心的生产方案，因其内置健壮的 initContainer 检查、DNS 等待逻辑和动态配置生成，可规避手动 StatefulSet 脚本导致的脑裂、IPv6 解析失败、哨兵选举超时等风险。
直接用 Helm + Bitnami 的 redis Chart 部署哨兵集群，是当前最可靠、最省心的生产方案。手动写 StatefulSet + 自定义启动逻辑容易在故障切换时丢数据、连错节点，或因 DNS 解析延迟导致哨兵选举失败。
为什么不用自己写 StatefulSet 启动脚本
很多团队照着网上教程写 shell 脚本判断主从、调用 redis-cli --sentinel get-master-addr-by-name，但实际运行中问题频出：
- Pod 启动顺序不可控，
sentinel-0.sentinel.default.svc.cluster.local可能还没就绪，脚本就去查主节点，返回空导致所有 Redis 实例都以主模式启动，形成脑裂 -
hostname -i在某些 CNI（如 Cilium）下返回的是 IPv6 地址，而哨兵配置只认 IPv4，造成SENTINEL monitor失败 - 哨兵之间通信依赖
sentinel announce-ip，但容器内无法稳定获取宿主机网卡 IP，硬编码或环境变量注入极易失效 - 滚动更新时，旧哨兵进程可能还在监听老 Pod 的 DNS 名，新哨兵加入后无法达成 2/3 投票共识
Bitnami Chart 内置了健壮的 initContainer 检查、DNS 等待逻辑和动态配置生成，已覆盖上述全部边界场景。
helm install 命令必须加的关键参数
Bitnami 的 redis Chart 默认部署单节点，要启用哨兵需显式开启并约束拓扑：
-
--set architecture=sentinel：这是开关，不设则不会创建哨兵 StatefulSet -
--set sentinel.replicas=3：哨兵至少 3 个才能容忍 1 个宕机；低于 3 个无法完成多数派选举 -
--set redis.replicas=3：Redis 数据节点也设为 3（1 主 2 从），和哨兵数对齐便于管理 -
--set auth.password=xxx：必须设密码，否则哨兵间通信和客户端连接均无认证，生产环境不合规 -
--set master.persistence.size=10Gi和--set replica.persistence.size=10Gi：避免使用默认的 8Gi，在 SSD 存储类下 IO 更稳
完整命令示例：
helm install redis bitnami/redis \ --namespace redis-prod \ --create-namespace \ --set architecture=sentinel \ --set sentinel.replicas=3 \ --set redis.replicas=3 \ --set auth.password='y0urS3cur3P@ss' \ --set master.persistence.storageClass=local-ssd \ --set replica.persistence.storageClass=local-ssd
客户端连接方式与 Spring Boot 配置要点
应用不能直连某个 Redis Pod IP，必须通过哨兵发现主节点。Spring Boot 2.3+ 默认用 Lettuce，配置如下：
-
spring.redis.sentinel.master=mymaster：必须和 Chart 中sentinel.masterGroupName一致（默认就是mymaster） -
spring.redis.sentinel.nodes=sentinel-0.redis-prod.svc.cluster.local:26379,sentinel-1.redis-prod.svc.cluster.local:26379,sentinel-2.redis-prod.svc.cluster.local:26379：填全部哨兵 DNS 地址，不要只写一个 -
spring.redis.password必须和auth.password相同，否则连接主节点时会认证失败 - 禁用
spring.redis.lettuce.pool的最大空闲连接数（设为-1），因为哨兵故障转移后，旧连接池里的连接可能指向已下线节点，Lettuce 会自动重建连接，无需手动刷新
若用 Jedis，需确认版本 ≥ 3.8.0，低版本对哨兵重连支持不完善，failover 后常出现 NOAUTH Authentication required 或 Connection refused。
验证哨兵是否真正生效
部署完成后别急着切流量，先做三件事验证：
- 进任意一个哨兵 Pod：
kubectl exec -it sentinel-0 -n redis-prod -- redis-cli -p 26379，执行SENTINEL MASTER mymaster，确认"num-slaves":"2"且"flags":"master" - 手动删掉主节点 Pod：
kubectl delete pod -l app.kubernetes.io/component=master -n redis-prod，等 30 秒后再次查SENTINEL MASTER，观察"num-slaves"是否变成 1，且新主节点 IP 是否变更 - 查日志：
kubectl logs -l app.kubernetes.io/component=sentinel -n redis-prod | grep "new configuration"，应看到类似+switch-master mymaster 10.244.1.15:6379 10.244.2.18:6379的日志
最容易被忽略的是：哨兵配置里 down-after-milliseconds 默认是 60000（1 分钟），意味着主节点挂了要等整整一分钟才触发切换。生产环境建议通过 --set sentinel.downAfterMilliseconds=10000 改成 10 秒，但需同步调低 failoverTimeout，否则可能因网络抖动误判。
