ot-container-kit/redis-operator是生产可用的主流选择，社区活跃、文档全、支持cluster/sentinel/standalone多模式；判断依据为kubectl get crd输出含redisclusters.redis.ot-container-kit.com且operator日志持续打印reconciling。
redis-operator 能直接替代手写 StatefulSet + ConfigMap + Headless Service 的整套 YAML，但前提是选对 Operator、配对 CRD、避开节点 IP 变更和集群元数据不一致这两个最常导致“集群起不来”的坑。
怎么判断该用哪个 Redis Operator？
目前生产可用的主流选择就两个：ot-container-kit/redis-operator（社区活跃、文档全、支持 Cluster/Sentinel/Standalone 多模式）和 opstree/redis-operator（企业级功能多，比如内置 TLS 自动轮换、备份策略）。别碰那些只维护到 2021 年的 fork 项目——它们没适配 Kubernetes v1.25+ 的 PodDisruptionBudget 和 TopologySpreadConstraints，部署后 kubectl get rediscluster 会卡在 Pending 状态。
验证方式很简单：
- 运行
kubectl get crd | grep redis，确认输出里有redisclusters.redis.ot-container-kit.com或类似名称 - 检查 Operator Pod 日志：
kubectl logs -n ot-operators deployment/redis-operator | grep -i "reconciling"，看到持续输出才说明控制器在正常工作
为什么 RedisCluster 创建后节点一直 NotReady？
绝大多数情况是 nodes.conf 文件残留或 IP 没刷新。Redis Cluster 启动时会把首次生成的节点 ID 和 IP 写死进 /data/nodes.conf，而 StatefulSet 重建 Pod 后，新 Pod 的 IP 已变，但旧文件还在，导致节点互相拒绝握手。
正确做法不是靠脚本硬改，而是让 Operator 控制整个生命周期：
- 确保 CR 中启用了
spec.podAntiAffinity: true，避免主从挤在同一节点 - 必须挂载
emptyDir或带storageClassName的 PVC 到/data，不能用 hostPath - 禁用任何外部初始化 Job —— Operator 自带的
redis-trib初始化逻辑只在所有 Pod 进入Running状态后才触发
如果已出问题，手动修复成本高：删掉所有 Pod 和对应 PVC，再 kubectl delete rediscluster，等 Operator 清理完 finalizer 后重试。
如何让密码、TLS、资源限制生效？
Operator 不会把 CR 中的 spec.redisConfig 直接覆盖进容器内 redis.conf，它只注入关键项（如 cluster-enabled yes），其余配置需通过 configMapRef 显式挂载。
示例片段：
spec:
redisConfig:
cluster-enabled: "yes"
protected-mode: "no"
configMapRef:
name: redis-custom-config
而密码和 TLS 必须走独立字段：
-
spec.passwordSecretRef.name指向含password键的 Secret -
spec.tls.enabled: true且spec.tls.secretName指向含tls.crt和tls.key的 Secret -
spec.resources下的requests/limits是给容器设的，不是给 Redis 进程设的；实际内存上限还得靠maxmemory配置项控制
Operator 真的能自动故障转移吗？
能，但仅限于主节点宕机且其从节点健康的情况。Operator 通过定期执行 CLUSTER NODES 命令检测状态，发现主节点失联后，会调用 CLUSTER FAILOVER 命令触发从节点升主。但它不会处理以下场景：
- 整个 StatefulSet 所在节点宕机（需依赖 Kubernetes 的 node controller 触发驱逐）
- 从节点自身卡住（比如
replica-serve-stale-data no且主从断连超时） -
nodes.conf权限错误（Operator 默认以非 root 用户运行，/data目录权限必须为 755）
所以务必在 CR 中设置 spec.failurePolicy: "Recreate"，并配合 PodDisruptionBudget 控制最大不可用副本数——否则一次滚动升级可能让整个集群不可写。
kubectl apply -f redis-cluster.yaml 后发现 rediscluster 状态卡在 Provisioning，这时候得立刻查 Operator 日志，而不是去翻每个 Pod 的 redis.conf。Operator 的“声明式”本质是它只管状态对齐，不管中间过程是否符合人脑直觉。
