Kubernetes 中 Redis StatefulSet 高可用部署怎么配置

在 Kubernetes 中部署 Redis 高可用集群，最推荐采用 StatefulSet 配合 Headless Service 和持久化存储（PVC）的方案。适用场景为需要稳定网络标识和数据持久化的生产环境，风险边界在于存储类（StorageClass）必须支持动态供给，否则 Pod 重建后数据可能丢失。

先说结论：StatefulSet 是管理 Redis 有状态服务的核心资源，必须结合 Headless Service 实现稳定域名解析。

适合：需要持久化存储、稳定网络标识和有序部署的数据库类应用。
先准备：确认集群已配置支持动态供给的 StorageClass，规划好 Sentinel 或 Cluster 架构模式。
验收：检查 Pod 状态为 Running，验证主从复制状态及故障转移功能是否正常。

命令速用版

以下是基于 StatefulSet 部署 Redis 的核心资源清单片段，包含无头服务和有状态集配置。

apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  clusterIP: None
  ports:
  - port: 6379
    name: redis
  selector:
    app: redis
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    spec:
      containers:
      - name: redis
        image: redis:6.2
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

为什么会这样

StatefulSet 能为每个 Pod 提供唯一的网络标识和持久化存储绑定，这是 Redis 集群通信的基础。

与 Deployment 不同，StatefulSet 管理的 Pod 拥有固定的主机名（如 redis-0、redis-1），即使 Pod 被重建，其网络标识和绑定的持久卷（PV）也不会改变。Redis 集群依赖稳定的节点身份进行 Gossip 协议通信和槽位分配，Headless Service（clusterIP: None）则确保 DNS 解析直接返回 Pod IP 列表，满足节点发现需求。公开资料中没有看到可靠的量化数据表明 StatefulSet 比 Deployment 性能更高，但其稳定性对有状态服务至关重要。

分步处理

按照存储、网络、计算资源的顺序依次创建，确保依赖关系正确。

1. 配置存储类（StorageClass）
检查集群是否存在默认 StorageClass，若没有需先配置 NFS 或云存储供给器。执行命令kubectl get storageclass，确认输出中有标记为(default)的条目。若使用 NFS，需优化挂载参数如rsize和wsize以提升 IO 性能。

2. 创建无头服务（Headless Service）
创建clusterIP: None的 Service，用于 StatefulSet 内部稳定域名解析。确保 Service 的selector标签与 StatefulSet 的 Pod 标签一致，否则 DNS 解析将失败。

3. 部署 StatefulSet
定义副本数，哨兵模式通常建议 3 节点（1 主 2 从），集群模式建议 6 节点（3 主 3 从）。在容器配置中挂载 ConfigMap 管理redis.conf，开启appendonly yes确保持久化。若使用哨兵模式，需额外部署 Sentinel 容器或侧车容器监控主库状态。

4. 初始化集群
Pod 启动后，若使用 Redis Cluster 模式，需执行槽位分配命令。若使用 Sentinel 模式，确保哨兵配置文件正确指向主库名称和端口。

怎么验证是否生效

通过 Kubernetes 状态检查和 Redis 内部命令双重确认集群健康度。

1. 检查 Pod 状态
执行kubectl get pods -l app=redis，确认所有 Pod 状态为Running且重启次数稳定。检查 PVC 状态是否为Bound，确保持久化卷已绑定。

2. 验证 Redis 角色
进入 Pod 内部执行redis-cli info replication，查看role字段确认主从关系是否符合预期。对于集群模式，执行redis-cli cluster info，确认cluster_state为ok。

Kubernetes 中 Redis StatefulSet 高可用部署怎么配置

3. 测试故障转移
手动删除主节点 Pod，观察 Sentinel 是否触发自动选举，或集群模式是否重新分片。验证期间服务应短暂波动后恢复，数据不丢失。

常见坑

部署过程中容易在存储供给和网络解析环节遇到问题，需提前规避。

1. 存储类缺失导致 Pod pending
若未配置 StorageClass 或默认存储类不可用，PVC 将无法绑定，Pod 会一直处于Pending状态。解决方式是先创建有效的 StorageClass 或在 PVC 中指定存在的存储类名称。

2. 域名解析失败
Headless Service 名称必须与 StatefulSet 的serviceName字段完全一致，否则 Pod 无法通过域名互相发现。确保集群 DNS 服务（CoreDNS）运行正常。

3. 配置文件挂载错误
直接修改 ConfigMap 后 Pod 不会自动重启加载新配置。对于 Redis 核心配置变更，建议删除 Pod 触发重建，或使用侧车容器动态重载配置。

常见问题

Redis 高可用选哨兵模式还是集群模式？

数据量小且只需主从切换选哨兵模式，数据量大需水平扩展选集群模式。

哨兵模式架构简单，适合 1 主多从场景，主要解决高可用问题；集群模式支持分片存储，适合大规模数据场景，但运维复杂度较高。

StatefulSet 删除后数据会丢失吗？

默认不会丢失，因为 PVC 默认保留策略是 Retain。

删除 StatefulSet 只会删除 Pod 资源，关联的 PVC 和 PV 默认保留。若需彻底清除数据，需手动删除 PVC 资源对象。

为什么必须使用 Headless Service？

因为 StatefulSet 需要稳定的网络标识，普通 Service 的 ClusterIP 会屏蔽后端 Pod IP。

Headless Service 直接将 DNS 解析到 Pod IP 列表，满足 Redis 节点间直接通信和故障发现的需求。

参考来源

《K8s StatefulSet 实战：部署高可用 Redis 集群》
在 Kubernetes 上部署高可用 Redis 集群的完整实践指南-CSDN 博客
K8S Redis 5.0.3 集群部署:3 主 3 从 StatefulSet + NFS 存储完整配置
KubeSphere 实战：用 StatefulSet 部署 Redis 集群的完整流程与避坑指南
Kubernetes09-部署 redis 高可用集群 (StatefulSet)