Redis集群不能直接用HPA扩缩容，因StatefulSet需Operator通过CR（如RedisCluster）变更clusterSize等字段触发扩缩，且自动扩缩需Prometheus+prometheus-adapter+自定义控制器链路实现。
Redis集群不能直接用HPA扩缩容，因为StatefulSet不被原生支持
HorizontalPodAutoscaler（HPA）默认只支持 Deployment、ReplicaSet、ReplicationController 和 StatefulSet（从 Kubernetes v1.23+ 开始），但 Redis 集群通常由多个角色组成（如 leader/follower 或 master/slave），且依赖拓扑稳定的网络标识和持久化存储。即使 HPA 能“触发”StatefulSet 的副本数变更，Redis Operator 本身不会自动响应这个变更——它只监听自己 CRD（如 RedisCluster 或 RedisFailover）的 spec 变化。
常见错误现象：kubectl autoscale statefulset/redis-leader --cpu-percent=70 --min=3 --max=6 执行成功，但实际 Pod 数量不变，kubectl get hpa 显示 Target 状态为 Unknown 或 NotScaled，日志里出现 failed to get cpu utilization: unable to get metrics for resource cpu。
- 根本原因：Metrics Server 没有采集到 StatefulSet 下 Pod 的指标（尤其当 Pod 启用了资源 request 但未显式暴露 /metrics 端点时）
- 更关键的是：Redis Operator 不 watch
StatefulSet副本变化，它只 watch 自己的 CR 对象（如RedisCluster） - 如果你绕过 Operator 直接 patch
StatefulSet，会导致 Operator 认为状态“偏离期望”，后续可能强制 revert 修改
正确路径：通过修改 RedisCluster CR 的 clusterSize 字段触发 Operator 扩缩
Redis-Operator（如 Opstree 或 Spotahome 版本）管理集群的核心是自定义资源（CR），扩缩容必须走 CR 更新流程。例如，Opstree 的 RedisCluster CR 中，spec.clusterSize 控制总节点数，而 Spotahome 的 RedisFailover 则需同时调整 spec.redis.replicas 和 spec.sentinel.replicas。
操作步骤：
- 确认当前 CR 名称：
kubectl get rediscluster或kubectl get redisfailover - 编辑 CR：
kubectl edit rediscluster redis-cluster（Opstree）或kubectl edit redisfailover rf-redis（Spotahome） - 修改对应字段：
– Opstree：spec.clusterSize: 5（从 3 扩到 5）
– Spotahome：spec.redis.replicas: 5和spec.sentinel.replicas: 3 - 保存退出后，Operator 会在几秒内检测变更，开始滚动更新节点并触发数据分片迁移（如使用 Redis Cluster 模式）
注意：clusterSize 是总节点数，不是主节点数；Opstree 默认按 1 leader + N follower 构建，所以设为 5 表示 1 主 4 从（或自动分配为 3 主 2 从，取决于分片策略）。务必提前确认你用的 Operator 版本是否支持该字段动态更新（v1beta2+ 一般支持）。
让 CPU 使用率成为扩缩容决策依据：必须接入 Prometheus + HPA + 自定义指标适配器
单纯改 CR 是手动行为。要实现“根据 CPU 使用率自动扩缩”，必须把 HPA 绑定到 Redis CR 的“逻辑目标”上——但 Kubernetes 原生 HPA 不认识 RedisCluster。解决方案是：用 prometheus-adapter 把 Redis 实例的 CPU 指标暴露为自定义指标（如 redis_cpu_usage_percent），再让 HPA 基于该指标驱动一个“代理控制器”去 patch Redis CR。
典型链路：
- Prometheus 抓取每个 Redis Pod 的
container_cpu_usage_seconds_total，计算出 % 利用率（除以container_spec_cpu_quota） -
prometheus-adapter将该值注册为可被 HPA 查询的指标：redis_cpu_usage_percent - 编写一个轻量控制器（或用 KEDA），监听该指标超过阈值（如 80%），然后执行：
kubectl patch rediscluster redis-cluster -p '{"spec":{"clusterSize":5}}' --type=merge - Operator 检测到 CR 变更，执行扩缩容逻辑
性能影响：Prometheus 抓取间隔建议设为 15s，避免高频查询拖慢指标系统；KEDA 触发延迟通常在 30–60s，不适合毫秒级突增场景。另外，Redis 分片迁移期间 CPU 升高是正常现象，需在 HPA 策略中加入 stabilizationWindowSeconds 防止震荡。
容易忽略的关键点：数据一致性与扩缩容窗口期
Redis 扩容不是加个 Pod 就完事。Operator 在调大 clusterSize 后，会启动新节点、等待加入集群、执行 CLUSTER MEET、再 CLUSTER ADDSLOTS 迁移哈希槽——整个过程可能持续 2–5 分钟，期间部分 slot 请求会返回 MOVED 重定向，客户端必须支持自动重定向（如 JedisCluster、redis-py-cluster）。
真正危险的操作是缩容：
- 如果缩容时没等 slot 迁移完成，
HPA或控制器就删掉节点，会导致数据丢失或集群不可用 - Opstree 的
RedisCluster缩容前会检查CLUSTER NODES输出，但某些版本存在 race condition - 强烈建议：缩容前手动执行
kubectl exec -it redis-cluster-leader-0 -- redis-cli CLUSTER NODES，确认待删除节点 slot 已全部迁出
最终效果取决于你用的 Operator 实现细节——Opstree v1.12+ 支持 spec.autoScaling 字段（实验性），而 Spotahome 官方明确不提供自动扩缩容，只留接口供你集成。别指望一条 kubectl autoscale 命令搞定。
