statefulset是部署redis主从/cluster的唯一可靠选择，因deployment无法提供稳定网络标识、有序启动及独立持久化存储，导致pod重建后必然断同步、丢数据、脑裂；而statefulset通过固定pod名、headless service dns、orderedready启停、volumeclaimtemplates绑定专属pvc，确保身份可识别、启动可序、数据不丢、角色可演进。
直接说结论：StatefulSet 是唯一靠谱的选择，Deployment 在 Redis 主从或 Cluster 场景下必然失败——不是“可能出问题”，而是“只要 Pod 重建就断同步、丢数据、脑裂”。关键不在“能不能跑起来”，而在“重启后还能不能认得彼此”。
为什么必须用 StatefulSet 而不是 Deployment
Deployment 的 Pod 名字带随机后缀（如 redis-7f8c9d6f5-abc12），IP 每次重建都变；Redis 主从依赖稳定的 replicaof 地址，从库写死一个 IP 或 Service ClusterIP 都不行：前者随 Pod 漂移失效，后者是轮询地址，无法指向特定主节点。StatefulSet 的 redis-0、redis-1 这类固定序号名 + Headless Service 提供的稳定 DNS（如 redis-0.redis-headless.default.svc.cluster.local），才是从库能长期信任的主库标识。
另外，StatefulSet 的 podManagementPolicy: OrderedReady（默认）保证了 redis-0 就绪后才启 redis-1，这对主从启动顺序至关重要——否则从库先起来，反复连不上主库，日志刷满 Connection refused。
- Deployment 适合 Nginx、API Server 这类无状态服务，客户端不关心后端具体是谁
- Redis 主从/Cluster 中每个节点都有身份语义：
redis-0是主还是从，redis-1是否负责槽位 0–5460，都必须可预期、可复现 - VolumeClaimTemplates 绑定的 PVC 名称也带序号（如
redis-data-redis-0），确保 Pod 重建后挂载的是同一块磁盘，AOF/RDB 文件不丢
Headless Service 必须配对使用
普通 Service 的 clusterIP 是单点虚拟 IP，无法区分具体 Pod；而 Headless Service（clusterIP: None）会为每个 StatefulSet Pod 生成独立 A 记录，这是整个方案能运转的 DNS 基础。
错误配置示例：clusterIP: "" 或漏掉 serviceName: redis 字段，会导致 StatefulSet 创建的 Pod 解析不到自身域名，redis-cli -h redis-0.redis-headless 直接失败。
- Service 的
selector必须和 StatefulSet 的template.metadata.labels完全一致，否则 DNS 记录不生成 - Service 名称（如
redis-headless）要和 StatefulSet 的spec.serviceName字段严格匹配，大小写都不能错 - Pod 内部用
redis-0.redis-headless.default.svc.cluster.local这种 FQDN 最稳妥，避免因 search domain 导致解析歧义
角色分配不能硬编码，得靠 Pod 序号动态判断
把 redis-0 固定设为主库、redis-1 和 redis-2 设为从库看似简单，但一旦发生故障转移（比如用 Sentinel 或 Cluster 模式），主节点可能变成 redis-2。硬编码配置会让新主库仍以从库身份启动，拒绝写入。
正确做法是在容器启动脚本里读取 $HOSTNAME，解析出序号，再结合外部协调机制（如哨兵查询、ConfigMap 标记、或者初始化 Job 分配）决定角色：
- 纯主从场景：可用 ConfigMap 存一份
master: redis-0，Pod 启动时curl或envFrom注入，但需配合更新 ConfigMap 的运维流程 - Sentinel 场景：从
sentinel-0.sentinel查sentinel get-master-addr-by-name mymaster，比对本机hostname -i - Redis Cluster 场景：必须靠初始化 Job 执行
redis-cli --cluster create，之后所有节点通过 gossip 自发现，不再依赖预设角色
常见坑：command 中直接写 redis-server --replicaof redis-0.redis-headless 6379 看似省事，但 redis-0 若宕机，其他 Pod 启动时会卡在 DNS 解析超时，导致整个 StatefulSet 卡住。
PVC 和持久化配置必须同步收紧
仅靠 StatefulSet + Headless Service 不等于高可用——如果 AOF 关闭、appendonly no，Pod 一删，内存数据全丢；如果多个 Pod 共享同一块 PVC，主从写冲突直接损坏 RDB 文件。
必须同时满足三项：
-
volumeClaimTemplates中每个模板都要有唯一name，且accessModes设为ReadWriteOnce，确保每个 Pod 挂独立 PVC - Redis 配置中强制开启 AOF：
--appendonly yes --appendfilename appendonly.aof，RDB 可选但不推荐单独依赖 - 容器
command末尾加--protected-mode no（仅限内网可信环境），否则默认拒绝非 127.0.0.1 的连接，从库连不上主库
最容易被忽略的一点：StatefulSet 更新镜像或配置时，滚动更新默认会逐个删除旧 Pod 并创建新 Pod，但 PVC 不会删。这意味着新 Pod 启动时加载的是旧 Pod 写入的 AOF 文件——如果旧主库已故障，这个 AOF 可能包含大量未同步到从库的写操作，恢复后反而扩大数据不一致范围。所以任何配置变更前，务必先确认主从同步状态（redis-cli info replication | grep sync_）。
