直接回答：kubectl describe hpa 的 Events 与 Conditions 是入口——能拿到指标会显示当前值与目标值，拿不到就报 unable to fetch metrics。指标管道：CPU/内存走 metrics-server（资源指标），自定义/外部指标走 Prometheus Adapter 等。管道任何一环断，HPA 就停转——这是最常见根因，不是 HPA 本身的问题。

展开解析：排查清单按序：指标可用性——kubectl top pod 直接验证 metrics-server 链路，top 都不通先修 metrics-server（证书、APIService 注册 v1beta1.metrics.k8s.io 的 Available 状态）；Pod 没设 requests——CPU 利用率的基数是 requests，没设 requests 的 Pod HPA 算不出百分比直接报错；目标与阈值——targetAverageUtilization 50 而当前 45 不扩是正常工作，先确认预期；扩缩边界——minReplicas/maxReplicas 卡死、behavior 的 stabilizationWindowSeconds（缩容默认 5 分钟稳定窗）让“该缩不缩”是防抖动设计；副本数被抢占——GitOps（ArgoCD）或 CI 定时把 Deployment replicas 改回固定值，HPA 刚扩完被打回（解法：GitOps 里去掉 replicas 字段交给 HPA）；自定义指标——Prometheus Adapter 的 seriesQuery 没匹配到序列、指标 label 与 Pod 对不上，直接 kubectl get --raw /apis/custom.metrics.k8s.io/... 验证。扩容不生效的下游问题：HPA 扩了但没节点可调度（Pending）——那是 cluster autoscaler 的事，两层弹性要联动监控。调试期建议：把 scaleTargetRef 指向测试 Deployment 用压测工具打流量，观察 HPA 状态每分钟刷新（--horizontal-pod-autoscaler-sync-period 默认 15s），闭环验证配置。

追问方向：HPA v2 的 behavior 如何配置快速扩缓慢缩？基于外部指标（如队列长度）伸缩的架构？

（约 500 字）