1. 导致HPA无法读取自定义指标显示<unknown>的常见原因 #

我碰到过好多次类似的情况，总结下来主要有这几个容易踩的坑：

• 指标名称/标签选择器不匹配
  先确认你HPA配置里写的指标名称，和kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1"返回的内容完全一致（包括大小写、后缀）。另外很多自定义指标会带pod、namespace这类标签，如果HPA里没指定正确的selector去匹配目标pod，就会找不到对应的数据。比如你用的是NGINX Ingress的pod级活跃连接数，得确保标签能精准定位到要扩缩容的应用pod。

• RBAC权限不足
  HPA的控制面需要有权限访问custom.metrics.k8s.io API。检查一下是否给horizontal-pod-autoscaler这个ServiceAccount绑定了custom-metrics-reader的ClusterRole，要是没绑定，HPA根本拉不到指标数据。你可以用这条命令快速验证：

  kubectl auth can-i get custom.metrics.k8s.io --as=system:serviceaccount:kube-system:horizontal-pod-autoscaler
  

  如果返回no，就得补全RBAC配置。

• Custom Metrics Adapter工作异常
  负责抓取NGINX指标并转换成K8s自定义指标的适配器（比如prometheus-adapter）可能出问题了。去看它的日志排查：

  kubectl logs -n kube-system <adapter-pod-name>
  

  有没有报错？比如指标抓取失败、PromQL转换规则写错，导致没法生成pod维度的指标。

• HPA指标配置字段错误
  如果是按Pod平均指标扩缩容，必须用targetAverageValue而不是targetValue。正确的配置格式应该是：

  target:
    type: AverageValue
    averageValue: 50 # 每个pod的目标活跃连接数
  

  要是写错成targetValue，HPA会把它当成集群全局指标，自然找不到对应数据。

• 指标维度不匹配
  有些NGINX指标是ingress控制器层面的全局指标（比如整个ingress的总活跃连接数），不是pod维度的。如果你的HPA是针对应用pod的，这种全局指标没法直接用，得先通过PromQL把指标聚合到pod维度，比如按后端pod分组统计连接数。

2. 基于Pod平均活跃连接数的扩缩容方式是否正确？ #

这个得结合你的业务场景判断，不能一概而论：

• 适合的场景
  如果你的服务是长连接为主（比如WebSocket服务、TCP业务服务），活跃连接数确实是最能反映pod负载的指标——每个pod能承载的长连接数是有限的，当平均连接数接近阈值时，扩容能直接缓解压力。这种场景下用这个指标比CPU利用率靠谱多了。

• 需要谨慎的场景
  如果是短连接的HTTP服务，活跃连接数可能不是最优选择。因为HTTP短连接建立和关闭很快，活跃连接数波动可能很大，而且没法准确反映真实的请求负载（比如瞬间大量请求过来，活跃连接数可能没到阈值，但CPU或请求队列已经爆了）。这种情况可能用请求速率（QPS）或者并发请求数更合适。

• 额外注意点
  要确保你用的活跃连接数是后端应用pod的连接数，而不是NGINX Ingress控制器的连接数。如果只是监控ingress的总连接数，得把这个数按后端pod数量拆分，转换成每个pod的平均连接数，否则HPA会基于全局指标做出错误的扩缩容决策。另外，要给这个指标设置合理的阈值——先压测一下你的pod能稳定承载多少活跃连接，再把阈值设到这个值的70%-80%，留有余地。

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