KEDA缩容过快导致AI漫剧任务被强制终止，根本原因是cooldownPeriod设置过短、restoreToOriginalReplicaCount未显式启用，以及Redis Streams伸缩器仅依赖pending消息数而忽略已拉取未ACK任务；需将cooldownPeriod设为任务P95耗时2倍以上、显式配置restoreToOriginalReplicaCount: true，并通过maxReplicaCount和pollingInterval调优避免激进缩容。
当KEDA将渲染Worker从12个副本瞬间缩到2个，正在执行的AI漫剧合成任务被强制终止，日志里出现大量container killed due to OOMKilled或preStop hook timeout，说明缩容节奏已脱离业务容忍边界。
确认缩容是否真由KEDA触发
第一步：检查最近5分钟内所有ScaledObject的伸缩事件
kubectl get events -n <strong>【your-namespace】</strong> --field-selector reason=ScaleDown,reason=ScaleUp --sort-by=.lastTimestamp | tail -20
第二步：定位具体触发缩容的ScaledObject
执行kubectl get scaledobject -n <strong>【your-namespace】</strong> -o wide，比对EVENTS列中最近一次ScaleDown时间与Pod终止时间是否重合。若时间差在3秒内，基本可锁定KEDA为源头。
第三步：查看该ScaledObject当前指标快照
kubectl get scaledobject <strong>【so-name】</strong> -n <strong>【your-namespace】</strong> -o jsonpath='{.status.triggeredMetrics[0].value}'。如果返回值远低于minReplicaCount（例如显示0但minReplicaCount: 4），说明指标采集异常或队列已清空，但业务侧仍有长时任务未完成——这是缩容过快的典型前置信号。
检查ScaledObject配置中的关键陷阱
方法一：验证cooldownPeriod是否被设为过短值
执行kubectl get scaledobject <strong>【so-name】</strong> -n <strong>【your-namespace】</strong> -o yaml，重点检查cooldownPeriod字段。若该值≤60，且你的AI渲染任务平均耗时＞90秒，KEDA会在第一个任务结束、队列短暂归零后立即启动缩容，完全不等待后续任务启动。必须将其设为任务P95耗时的2倍以上，例如cooldownPeriod: 300（5分钟）。
方法二：确认restoreToOriginalReplicaCount是否关闭
该字段默认为true，意味着KEDA缩容后会把HPA的minReplicas临时覆盖为当前缩容值。若你的Deployment本身设置了minReplicas: 8，但KEDA缩到2后未恢复，下次扩容起点就变成2而非8，导致弹性基线永久下移。务必在ScaledObject中显式设置restoreToOriginalReplicaCount: true。
方法三：检查scaleTargetRef是否指向正确资源
常见错误是scaleTargetRef.name写成Service名或ConfigMap名。KEDA只能缩Deployment/StatefulSet/Job。执行kubectl get deploy,sts,job -n <strong>【your-namespace】</strong> | grep <strong>【target-name】</strong>确认目标存在且类型匹配。写错会导致KEDA反复尝试缩容失败，日志刷屏failed to scale target，间接引发误判和连环缩容。
抓取真实缩容时刻的上下文证据
执行kubectl logs -n keda keda-operator-<strong>【pod-id】</strong> --since=10m | grep -E "(ScaleDown|trigger.*metric|decrease)"，过滤出缩容决策日志。
关键线索看这行：scaling down deployment <strong>【your-deploy】</strong> from 12 to 2 replicas because metric 'redis_streams_pending' value is 0。如果此时redis_streams_pending确为0，但你清楚有3个任务仍在执行（可通过redis-cli LLEN your:stream交叉验证），说明KEDA用的是“待消费消息数”而非“正在处理消息数”，它根本不知道worker已拉取但未ACK的任务——这是Redis Streams伸缩器的固有局限，必须配合parallelism和maxReplicaCount做兜底。
立即执行kubectl patch scaledobject <strong>【so-name】</strong> -n <strong>【your-namespace】</strong> --type='json' -p='[{"op":"add","path":"/spec/maxReplicaCount","value":16},{"op":"add","path":"/spec/pollingInterval","value":30}]'，将最大副本上限提高并缩短轮询间隔，避免单次缩容幅度过大。
