HPA 一项自定义指标取不到，另一项下降后仍不缩容

HPA 配置了两个自定义指标。负载上来时可以扩容，负载降下来后却一直停在原来的副本数；其中一项显示 <unknown>，事件出现 FailedGetObjectMetric。即使另一项已经低于目标，缩容也可能被跳过。

这是多指标决策的保护条件：HPA 分别计算各指标建议的副本数，取其中最大的建议。有指标读取失败，而有效指标只建议缩容时，控制器无法确认缺失指标是否允许缩容，因此保留当前规模。有效指标建议扩容时，仍可能继续扩容，最后还要受副本上限和扩缩容策略约束。

先找出缺失的是哪一路

以下示例只读取对象，命名空间和 HPA 名称需要替换：

kubectl get hpa web -n team-app -o yaml
kubectl describe hpa web -n team-app
kubectl get --raw /apis/custom.metrics.k8s.io

核对 spec.metrics 中每一路的类型、目标值和对象。本文针对多路 Object 自定义指标，不是 CPU 利用率缺少 requests 的情形。后者可看 CPU TARGETS 为 unknown 的检查。

在事件和 conditions 中找到 FailedGetObjectMetric 点名的指标，再查看适配器日志与实际指标 API 响应。上面的第三条命令用于确认集群公开的 API 版本；查询具体指标时，要按该版本、命名空间、对象种类、对象名称和指标名构造路径。不能照搬另一套集群的接口地址，也不能用资源指标的 kubectl top 代替自定义指标查询。

记录查询时间、返回的数值及时间戳、空结果或错误响应。Prometheus 能查到某个值，只能说明这次上游查询有结果，不能证明适配器暴露的同一指标、标签和对象也正确。认证失败、指标映射错误、对象名称不匹配和采集服务不可达，都需要沿各自错误处理。

没有错误请求，与没有指标，是两件事

一种常见配置会用 HTTP 502、503 的请求速率作为扩缩容指标。没有这类请求时，查询可能返回空向量；适配器随后无法提供指标，HPA 看见的就是缺失，而不是数值 0。

如果业务定义确实是“采集正常且没有错误请求时，错误率为零”，可以修正导出或查询规则，让该情形持续返回有明确对象归属的零值。修改前要确认正常采集仍在进行、目标对象存在、分母和时间窗口有效，再核对适配器最终返回的数值。查询表达式要依据实际标签和适配器映射设计，不宜直接加一段无标签的零值表达式了事。

连接中断、权限错误或监控服务失效不能转换成零。否则“无法知道当前负载”会被解释成“负载已经消失”，可能让 HPA 在错误的时机缩容。删除失败的那一路指标也会改变容量决策，不能只为了让缩容恢复就移除它。

TARGETS 没变，不代表这一轮没有重新取值

旧版本的状态展示也可能使排查更难。在 Kubernetes 1.24 的部分错误返回路径中，控制器会更新错误条件，却没有走到正常更新指标状态的步骤。此时 status.currentMetrics 或 describe 中的数值可能保留旧值，不能据此断定控制器一直使用那个旧值计算。

应把这一轮带时间戳的指标 API 响应、控制器错误和 HPA 条件放在一起看。状态显示滞后，与有一项指标无效而跳过缩容，可以同时存在。不要靠不断编辑 HPA 来“刷新数字”，也不要把更早版本中相反方向的缩容缺陷当成当前保护规则失效。

指标恢复后，再检查缩容策略

保存现有 HPA、适配器映射和查询配置，通过原管理入口修改已经定位的故障。先确认所有指标持续返回合法数值，再观察条件、事件及目标工作负载的实际副本数。

指标正常也不保证立刻缩容。还要核对 minReplicas、maxReplicas、behavior.scaleDown、稳定窗口与速率限制，确认没有另一项有效指标仍建议较多副本。用允许的测试负载检查扩容和缩容，并核对业务响应；不要为了验证变化而直接降低生产容量保护。

若查询调整产生异常，恢复对应的查询或适配器配置，保留前后响应用于比较。已经发生的副本变化不会随配置回退自动撤销，实际规模和应用健康仍要单独确认。