必须先确保KEDA Operator、Metrics Adapter和Admission Webhook三个核心组件在keda命名空间中全部Running，且scaledobjects.keda.sh等三个CRD已注册成功，否则无法创建ScaledObject；验证命令为kubectl get pods -n keda和kubectl get crd | grep keda。
确认KEDA已安装并验证集群就绪状态
必须先确保KEDA Operator、Metrics Adapter和Admission Webhook三个核心组件已在目标Kubernetes集群中运行，否则后续所有伸缩配置都将无法生效。
执行kubectl get pods -n keda检查keda-operator、keda-metrics-apiserver、keda-admission-webhooks三个Pod是否全部处于Running状态；若命名空间不存在或Pod未就绪，【必须先完成KEDA部署】，不可跳过此步直接写ScaledObject。
接着运行kubectl get crd | grep keda，确认scaledobjects.keda.sh、scaledjobs.keda.sh、triggerauthentications.keda.sh三个CRD均已注册成功。缺少任一CRD都会导致YAML创建失败且报错模糊。
为Redis队列消费者配置ScaledObject伸缩规则
假设你的Worker Deployment名为doc-processor，任务队列在Redis中键名为redis_queue:doc_tasks，需按每5个待处理任务触发1个Pod扩容，最小0副本、最大8副本。
方法一：使用redis_scaler直接对接Redis List长度
创建scaledobject-redis.yaml，关键字段必须包含：scaleTargetRef指向Deployment名称、triggers.type设为redis、metadata.listLength设为5（即队列长度阈值）、metadata.host填Redis服务地址（如redis-master:6379）、metadata.password从Secret引用而非明文写入。
方法二：通过TriggerAuthentication解耦认证信息
先创建名为redis-trigger-auth的TriggerAuthentication资源，把Redis密码存进Secret并在此声明key路径；再在ScaledObject的triggers下引用authenticationRef.name，这样密码变更时只需更新Secret，无需重发ScaledObject。
应用配置后，执行kubectl apply -f scaledobject-redis.yaml，几秒内即可看到KEDA开始轮询Redis队列长度。
验证队列驱动扩缩容是否真实生效
第一步：向Redis队列批量推入20条测试任务，命令为redis-cli RPUSH redis_queue:doc_tasks "task-1" "task-2" ...；
第二步：立即执行kubectl get hpa，确认HPA对象已由KEDA自动创建，名称通常为keda-hpa-scaledobject-xxx；
第三步：等待约15秒（KEDA默认探测间隔为5秒，需2～3轮确认），运行kubectl get deploy doc-processor，观察REPLICAS字段是否从0→4（20÷5=4）；
第四步：清空Redis队列，命令为redis-cli DEL redis_queue:doc_tasks，再等90秒（KEDA默认缩容冷却时间为5分钟，但首次清空后通常在90秒内触发缩容），检查Pod副本是否回落至0；
注意：若副本数卡在非零值不缩容，大概率是Worker容器未正确ACK消息，导致KEDA误判队列仍有积压——务必确认消费者代码中每条消息处理完成后调用了LPOP或BRPOP并成功删除，否则KEDA将持续维持当前副本数。
