确认redis-operator真正在工作需两步：先执行kubectl get crd | grep -i "rediscluster\|redisfailover"验证CRD注册成功，再用kubectl logs -n ot-operators deployment/redis-operator | grep -i "reconciling\|ReconcileRedisCluster"检查控制器是否高频滚动打印reconcile日志。
能，但前提是选对 Operator、CRD 注册成功、控制器持续 reconcile，否则集群卡在 NotReady 是常态。
怎么确认 redis-operator 真正在工作
Operator 不是“装完就跑”，它必须持续 reconcile 才算活。只靠 kubectl apply -f 部署完 CRD 和 Deployment 并不等于它已就绪。
- 先查 CRD 是否注册成功：
kubectl get crd | grep -i "rediscluster\|redisfailover"，必须看到类似redisclusters.redis.ot-container-kit.com或redisfailovers.databases.spotahome.com的输出 - 再查控制器日志：
kubectl logs -n ot-operators deployment/redis-operator | grep -i "reconciling\|ReconcileRedisCluster"，应有高频滚动日志（每秒 1–2 条），不是只打印一次就停住 - 如果日志里反复出现
failed to list pods或context deadline exceeded，大概率是 RBAC 权限没给全，需检查 ClusterRoleBinding 是否绑定到 operator ServiceAccount
为什么 RedisCluster 创建后长期 Pending 或 NotReady
绝大多数不是配置写错，而是 Operator 没法把“期望状态”落地为真实 Pod 行为，常见断点如下：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
nodes.conf残留：StatefulSet 重建 Pod 后 IP 变了，但旧/data/nodes.conf里还存着上一轮的节点 ID + 过期 IP，导致握手失败；Operator 不会自动清理该文件，除非你挂的是 emptyDir 或带storageClassName的 PVC（hostPath 会跨 Pod 持久化脏数据） - Pod 卡在 InitContainer：常见于镜像拉取失败、
init-chown-data容器因 SecurityContext 权限不足无法修改目录属主，或 ConfigMap 挂载路径与容器内预期不一致（如 Operator 期望挂到/usr/local/etc/redis/redis.conf，但你手写 YAML 错配成/etc/redis/redis.conf） - Headless Service 未就绪：Operator 依赖 Headless Service 的 DNS 记录（如
redis-cluster-0.redis-cluster-headless.default.svc.cluster.local）做节点发现；若 Service 的selector与 StatefulSet 的matchLabels对不上，DNS 解析失败，集群初始化直接卡死
spec 中哪些字段改了会触发滚动更新，哪些会强制重建
Operator 的 reconcile 逻辑决定了变更敏感度，不是所有字段都支持热更新：
- 安全可热更：
spec.redisConfig.configMapName（只要 ConfigMap 内容变，Operator 会 patch Pod 的 volume mount）、spec.resources（会触发 Pod 重启，但不删 PVC） - 触发重建（PVC 保留但 Pod 全量重调度）：
spec.storage.volumeClaimTemplate.spec.storageClassName（StorageClass 不可变更）、spec.replicationFactor（从 1 改为 2 会新增副本 Pod，但不会删旧 Pod） - 必须删资源重来：
spec.clusterSize（主节点数）从 3 改为 5，ot-container-kit/operator 不支持在线扩主节点，会拒绝更新并报错clusterSize is immutable；此时只能kubectl delete rediscluster再重 apply
备份与故障恢复不能只靠 Operator 自带逻辑
Operator 能保集群活着，但不等于数据安全。它的 backup 字段（如 opstree/redis-operator 的 spec.backup）只负责调用 redis-cli --rdb 并上传到 S3，但有两个硬伤：
- 备份时机不可控：默认是定时 job，若集群正处在槽位迁移中，RDB 文件可能不一致；没有 pre-backup hook 让你先执行
CLUSTER INFO校验状态 - 恢复流程非声明式：Operator 不提供
restoreFromBackup字段，恢复得手动下载 RDB、挂进新 Pod 的/data、改权限、再启动——这一步完全游离在 Operator 控制之外 - 真正可用的方案是：用 Velero 备份整个
RedisClusterCR + 对应 PVC，或用外部工具（如 MinIO + custom cronjob）把 RDB 推送到对象存储，并配合 Prometheus 告警redis_cluster_keys突降来触发人工介入
