Kubernetes 自定义指标导出器：先把业务信号建模，再接入 HPA

明确结论

自定义指标导出器的核心不是多写一个 HTTP 服务，而是把真正驱动负载的业务状态转成稳定、可解释的时间序列。队列深度、活跃连接数或任务耗时比 CPU 更接近容量压力时，才值得把它们接入扩缩容决策。

完整链路应按“应用状态 → /metrics → Prometheus 抓取 → Custom Metrics API → HPA”逐段验收。任何一段只凭配置文件存在就判定成功，都会把采集故障误当成业务低负载。

核心技术要点

• 指标类型必须匹配语义：只增不减的总量使用 Counter，可升可降的队列深度使用 Gauge，延迟分布使用 Histogram；命名应带命名空间、含义和单位。
• 应用代码可控时优先直接埋点；数据来自外部系统或无法修改原应用时，再部署独立 exporter，避免无必要地增加一个运行单元。
• exporter 应分离 /metrics 与 /healthz，使用非 root 的精简镜像，并为 Deployment 设置明确的请求、限制和存活探针。
• Prometheus Operator 场景可用 ServiceMonitor 显式发现目标；把指标交给 HPA 还需要 Prometheus Adapter 将其注册到 Kubernetes Custom Metrics API。

适用场景

• 消息队列消费者按 backlog 扩容，而不是等 CPU 被动升高。
• WebSocket、长连接或会话型服务按活跃连接压力分配实例。
• 批处理与异步任务按等待任务量、处理速率和耗时分布调整容量。

实践建议

• 先写指标契约：名称、类型、单位、标签、更新频率、负责人和预期取值范围，禁止把高基数 ID 放进标签。
• 让采集周期短于 Prometheus 抓取周期，并在目标页确认状态为 UP，再用实际查询验证时间序列不是恒定值或陈旧值。
• 先用指标做看板和告警，观察一段真实流量后再交给 HPA；同时设置扩容上限、稳定窗口和故障降级策略。

局限与风险

• 官方示例展示的是基础链路，不代表指标天然适合自动扩缩容；滞后、噪声和高基数都可能造成抖动或监控成本失控。
• Prometheus 抓取成功不等于 HPA 可用，Adapter 规则、聚合维度和 Custom Metrics API 权限仍需单独验证。
• 独立 exporter 会引入额外部署、升级和安全维护成本；能在应用内直接埋点时不应机械拆分。

延伸阅读

原始资料来自 Kubernetes Blog。建议结合官方文档的最新版本核对具体 API、限制和配置。