结论：kubectl scale无法抵御Redis雪崩，必须用Operator+自定义HPA驱动槽位重平衡。因单纯扩容StatefulSet不触发slot迁移、节点无法自动加入集群，且原生HPA指标对连接数/内存压力不敏感，仅Operator能封装redis-cli reshard、CLUSTER MEET等逻辑实现真实负载分担。
直接说结论：靠 kubectl scale 手动扩缩 StatefulSet 不能抵御 Redis 雪崩，必须用 Operator + 自定义指标（如 redis_connected_clients 或 redis_used_memory_ratio）驱动的 HPA，且需配合集群槽位重平衡逻辑。
为什么 kubectl scale statefulset/redis-cluster --replicas=8 会失效
单纯增加 Pod 数量只是“多开几个 Redis 实例”，但 Redis Cluster 的数据分片（16384 个 slot）不会自动重新分配。新节点是空的，老节点仍超载，连接数、内存、CPU 压力集中在少数主节点上，雪崩风险反而可能加剧。
- Redis Cluster 要求手动执行
redis-cli --cluster reshard才能迁移 slot，Operator 才能封装这步 -
StatefulSet扩容后，新 Pod 缺少初始化逻辑（如CLUSTER MEET、CLUSTER REPLICATE），无法自动加入集群 - HPA 默认只看 CPU/Memory，而 Redis 雪崩常由连接数突增或内存碎片率飙升触发，原生指标不敏感
必须用 Redis Operator 支持的自定义 HPA
主流 Operator（如 ot-container-kit/redis-operator 或 redis-operator.k8s.com/v1 CRD）提供 RedisCluster 自定义资源，其控制器能监听 HPA 事件并触发 slot 迁移、主从关系重建等动作。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先部署 Prometheus +
redis-exporter，暴露redis_connected_clients、redis_used_memory_bytes等指标 - 创建
HorizontalPodAutoscaler，target 指向RedisCluster类型，而非普通 Deployment - 关键配置示例：
metrics: - type: Pods pods: metric: name: redis_connected_clients target: type: AverageValue averageValue: 5000 - Operator 控制器收到 HPA 扩容信号后，会自动调用
redis-cli --cluster add-node和reshard，保证新节点承载真实流量
避免槽位迁移卡住的三个硬性条件
即使用了 Operator，slot 迁移失败也会让扩缩容“假成功”——Pod 起来了，但数据没分过去，压力仍在原节点。
- 所有 Redis Pod 必须能互相通过 DNS 访问（依赖
Headless Service，如redis-0.redis-headless.default.svc.cluster.local） - 每个 Pod 的
resources.limits.memory必须显式设置，否则redis-cli --cluster reshard在内存不足时会静默失败 - 迁移期间禁止写入大 key（>1MB），否则
MIGRATE命令超时，默认 60 秒，超时后 slot 状态卡在importing/migrating
真正起作用的不是“加机器”，而是“加机器 + 自动重分片 + 客户端无感重路由”。Operator 封装了后者，裸 StatefulSet 做不到。别跳过 redis-exporter 的指标校验和迁移前的 CLUSTER NODES 状态检查——这是最容易被忽略、却最常导致扩缩容失灵的环节。
