基于CPU阈值的K8s HPA扩缩容异常：空闲Pod无法缩容求助

一、HPA正常缩容的时间 #

HPA默认的缩容稳定期是300秒（5分钟），由horizontal-pod-autoscaler-downscale-stabilization参数控制。此外，HPA默认每15秒采集一次指标，需连续3次（共45秒）检测到指标低于阈值，再等待缩容稳定期结束后，才会触发缩容动作。

二、当前问题的核心原因 #

你的推测完全正确：单个Pod持续CPU超标，拉高了Deployment的整体平均CPU使用率，导致HPA判定当前Pod数量仍无法满足负载需求，因此不会触发缩容。而流量集中在单个Pod的情况，大概率是服务或Ingress配置了会话粘性（比如ClientIP类型的会话保持），导致新扩容的Pod无法分到流量，始终处于空闲状态。

三、解决方案 #

1. 优化流量分发，消除单点过载 #

• 检查Service的sessionAffinity配置：如果开启了ClientIP类型的会话粘性，可直接关闭，或通过sessionAffinityConfig.clientIP.timeoutSeconds缩短会话超时（默认3小时），让流量能均匀分配到所有Pod，避免单个Pod持续超标。
• 检查Ingress层面的粘性配置：比如Nginx Ingress的nginx.ingress.kubernetes.io/affinity注解，同样调整或关闭该配置，确保流量能分发到所有可用Pod。

2. 调整HPA缩容策略参数 #

• 缩短缩容稳定期：修改kube-controller-manager的启动参数--horizontal-pod-autoscaler-downscale-stabilization，例如设置为60s，让HPA更快响应空闲Pod的缩容需求。注意不要设置过短，避免出现频繁扩缩容的抖动问题。
• 调整指标评估灵敏度：修改horizontal-pod-autoscaler-sync-period（默认15秒）缩短指标采集间隔，或调整horizontal-pod-autoscaler-tolerance（默认0.1）降低触发阈值的容忍度，让HPA更精准地判断负载变化。

3. 改用基于请求数的HPA指标 #

CPU使用率是间接的负载指标，改用基于实际请求QPS的指标更贴合流量场景。比如通过Prometheus Adapter暴露http_requests_per_second指标后，执行以下命令配置HPA：

kubectl autoscale deployment php-apache --min=1 --max=10 --metrics-type="Pods" --metrics-name="http_requests_per_second" --target-value=100

这样HPA会直接根据Pod的请求量调整数量，避免因流量分布不均导致的误判。

4. 使用Keda实现精细化扩缩容（高级场景） #

如果需要更复杂的基于流量分布或节点状态的扩缩容逻辑，可以使用Keda（Kubernetes Event-driven Autoscaling）。它支持多种触发器（HTTP请求数、消息队列长度等），能针对单个Pod的实际负载进行判断，甚至可以自动缩容完全空闲的Pod，解决传统HPA依赖平均指标的局限性。

内容的提问来源于stack exchange，提问作者paul