一、为什么选择 Operator 来部署 Redis
在 Kubernetes 上直接使用 Deployment 或 StatefulSet 运行 Redis 实例，确实能快速拉起来一个进程，但 Redis 集群的运维复杂度并不在启动这一步。以常见的 Redis Cluster 为例，至少需要三个主节点分别承担哈希槽，每个主节点还要配置对应的从节点，当某个主节点宕机后，从节点需要自动提升并接管槽位，同时客户端要能感知新的拓扑。如果只依靠基础资源对象，这些动作都要通过额外的脚本、sidecar 或者人工干预完成，而且很难覆盖网络分区、节点重启、扩容缩容等边界场景。
Operator 模式的核心思路，是把这些运维逻辑编码到 Kubernetes 控制器中。用户只需要描述期望的集群状态，例如几个主节点、几个副本、是否开启持久化、资源限制是多少，剩下的创建、对账、修复工作全部由 Operator 完成。控制器会持续比较实际状态和期望状态，发现偏差就执行调谐，直到集群重新回到稳定状态。这种声明式管理方式与 Kubernetes 原生设计一致，也更适合长时间运行的数据库类工作负载。目前社区常用的 Redis Operator 有 ot-container-kit/redis-operator、Redis Enterprise Operator 等，前者完全开源且支持 Redis Cluster 和哨兵两种模式，本文以它作为示例。
需要说明的是，Operator 并不是替代 Redis 本身，而是把人工运维经验变成软件能力。例如，节点加入集群时，Operator 会执行 CLUSTER MEET 命令；主节点故障时，它会检查从节点状态并触发 CLUSTER FAILOVER。这些动作对用户透明，但理解背后的 Redis 机制有助于排查问题。
二、安装 Redis Operator 并准备环境
开始之前，需要确认 Kubernetes 集群版本不低于 1.19，并且已经配置好默认的 StorageClass，因为后续创建 Redis 持久化卷时会依赖动态供应。如果集群没有默认 StorageClass，可以在自定义资源中显式指定 storageClassName。同时，建议将 Operator 部署在独立的命名空间中，例如 redis-operator，避免与业务负载混在一起。
最简单的方式是通过 Helm 安装。先添加 Helm 仓库，再安装 Chart：
helm repo add ot-helm https://ot-container-kit.github.io/helm-charts/ helm repo update helm install redis-operator ot-helm/redis-operator --namespace redis-operator --create-namespace
执行完成后，可以检查 Operator 的 Pod 是否正常运行：
kubectl get pods -n redis-operator kubectl get crd | grep redis
上述命令会列出 Operator 部署的 Pod，并确认 RedisCluster、RedisSentinel 等自定义资源定义已经注册到集群中。如果看到 redisclusters.redis.redis.opstreelabs.in 这样的 CRD，说明安装成功。
如果不使用 Helm，也可以直接下载 Operator 的部署清单并执行 kubectl apply -f，但 Helm 方式更容易管理版本和升级。安装过程中如果镜像拉取较慢，可以提前配置镜像加速或替换为本地仓库地址。Operator 默认会创建一个 Deployment 和一个 ServiceAccount，并在后台持续监听自定义资源的变化。
三、通过自定义资源创建 Redis 集群
安装好 Operator 后，下一步是编写 RedisCluster 自定义资源的 YAML 文件。下面是一个三主三从的 Redis Cluster 配置示例，集群共 6 个节点，每个节点使用 5Gi 持久化卷，并开启 Redis Exporter 以便 Prometheus 采集监控指标。
apiVersion: redis.redis.opstreelabs.in/v1beta2
kind: RedisCluster
metadata:
name: redis-cluster
spec:
clusterSize: 3
persistenceEnabled: true
kubernetesConfig:
image: quay.io/opstree/redis:7.0.12
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
cpu: 500m
memory: 1Gi
redisExporter:
enabled: true
image: quay.io/opstree/redis-exporter:1.44.0
storage:
volumeClaimTemplate:
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 5Gi
clusterSize 字段表示主节点数量，Operator 会自动为每个主节点创建一个从节点，所以最终会运行 6 个 Pod。这里没有指定 storageClassName，会使用集群默认的 StorageClass。如果生产环境对 IO 性能有要求，建议使用基于 SSD 的存储类，并在 volumeClaimTemplate 中显式指定。
将上述内容保存为 redis-cluster.yaml，然后执行 kubectl apply -f redis-cluster.yaml。Operator 会立即开始创建 StatefulSet、Service 和 PVC。可以通过以下命令观察创建进度：
kubectl get rediscluster kubectl get pods -l app=redis-cluster-leader kubectl get pods -l app=redis-cluster-follower
等到所有 Pod 都进入 Running 状态，并且 READY 列显示 1/1，说明集群已经启动完成。此时 Operator 会自动完成 Redis Cluster 的初始化，包括分配哈希槽、建立主从关系和同步数据。注意，如果使用本地开发环境没有默认 StorageClass，需要先创建 local-path 或 hostpath 存储类，否则 PVC 会一直处于 Pending 状态。
四、验证集群状态与故障转移
集群创建完成后，需要验证节点是否都正确加入了集群。可以进入任意一个 Redis Pod，使用 redis-cli 查看集群信息：
kubectl exec -it redis-cluster-leader-0 -- redis-cli cluster info kubectl exec -it redis-cluster-leader-0 -- redis-cli cluster nodes
cluster info 会显示 cluster_state:ok，表示所有哈希槽都已分配且节点在线。cluster nodes 则列出每个节点的 ID、角色、槽位范围和连接状态。如果看到 3 个 leader 和 3 个 follower，并且每个 leader 的槽位范围加起来覆盖 0-16383，说明拓扑正确。
为了验证 Operator 的故障自愈能力，可以手动删除一个主节点 Pod，模拟节点宕机。Operator 会检测到实际状态与期望状态不一致，先尝试重建 Pod，同时由于 Redis 集群中该主节点不可用，对应的从节点会自动执行故障转移并提升为新的主节点。观察命令如下：
kubectl delete pod redis-cluster-leader-1 kubectl get pods -w
在新的 Pod 启动后，再次执行 cluster nodes，可以看到原来的从节点已经变成了 leader，而重建的 Pod 成为了 follower。整个过程中，如果客户端配置了合理的重试和拓扑刷新机制，业务不会长时间中断。这个测试也说明 Operator 的价值不在于简单的重启 Pod，而是能协调 Redis 内部的角色变更，使集群始终满足高可用要求。
五、日常运维与配置建议
生产环境中，除了完成部署，还需要关注持久化、备份、监控和升级几个方面。Redis Operator 默认开启了 AOF 持久化，但建议根据数据容忍度调整 appendfsync 策略。如果对性能要求极高，可以选择 everysec；如果对数据安全要求更高，则使用 always。这些参数可以通过自定义资源中的 redisConfig 字段覆盖默认的 redis.conf 配置。
备份方面，Redis Operator 本身不负责定时备份，可以结合 Kubernetes CronJob 定期执行 BGSAVE 或使用 Velero 对 PVC 做快照。Prometheus 监控可以通过前面启用的 Redis Exporter 暴露指标，配合 ServiceMonitor 即可被 Prometheus Operator 自动抓取。此外，建议为 Redis Pod 设置 PodDisruptionBudget，避免在节点维护时一次性驱逐过多主节点。
升级 Operator 时，应先在测试环境验证新版 CRD 的兼容性，再通过 Helm 执行滚动升级。升级过程中不要同时修改 Redis 集群的自定义资源，以免控制器在调谐时产生冲突。最后，Redis 对网络延迟非常敏感，如果集群跨可用区部署，应尽量使用低延迟的网络插件，并为每个可用区规划合理的节点分布，避免主从节点集中在同一个故障域。
