Kubernetes v1.37 HPA 缩容到零如何准备外部指标

我第一次把队列消费者做“按需启动”时，最容易误判的一点是：把 HPA 的 minReplicas 改成 0，并不等于它能从零自动醒来。Kubernetes v1.37 把 HPA 缩容到零推进到 Beta 并默认启用，但前提是 HPA 使用仍能在没有 Pod 时返回值的 Object 或 External 指标。

准备重点只有一句话：让队列长度、积压量这类外部信号独立于消费者 Pod 持续存在，并能从 external.metrics.k8s.io 读到；CPU、内存这类只能从运行中 Pod 得到的资源指标，不能负责从零唤醒。

官方资料：https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/

版本说明：https://kubernetes.io/blog/2026/09/02/kubernetes-v1-37-hpa-scale-to-zero-beta/

先确认缩容到零的适用边界

HPA 常见的 CPU、内存利用率都来自正在运行的 Pod。副本数为零以后，没有新的 Pod 可以被采样，也就没有信号把工作负载拉回来。队列长度、待处理任务数或外部服务请求量不同，它们可以由 Prometheus 等监控系统持续记录。

让外部指标在零 Pod 时仍然可读

以队列消费者为例，链路应是“队列或应用产生指标 → Prometheus 保存序列 → 指标适配器暴露 External Metrics API → HPA 查询”。适配器的发现规则必须稳定地匹配指标名和队列标识，不能只在消费者 Pod 存在时才生成这条序列。

Prometheus Adapter 的配置思路可以写成下面这样。这里的 name 标签用于把同一条队列指标与 HPA 的 selector 对上，具体安装参数仍要按现有监控方案调整。

# 这段配置把队列积压聚合为 HPA 可查询的 External 指标。
externalRules:
  - seriesQuery: '{__name__="queue_consumer_lag",name!=""}'
    metricsQuery: 'sum(>{>}) by (name)'
    resources:
      overrides:
        namespace:
          resource: namespace

先不要急着创建 HPA，直接验证聚合 API 是否有返回：

# 用 URL 编码后的 selector 查询 default 命名空间中的队列指标。
kubectl get --raw \
  '/apis/external.metrics.k8s.io/v1beta1/namespaces/default/queue_consumer_lag?labelSelector=name%3Dworker_tasks'

如果这里拿不到当前值，HPA 从零恢复就没有可靠输入。此时应检查 Prometheus 序列、适配器 discovery、命名空间匹配和聚合层权限，而不是反复调整副本数。

编写 autoscaling/v2 的 HPA

确认指标可读后，再把缩放目标写进 HPA。下面的例子表示每 30 个排队任务期望一个消费者，最大不超过 10 个。

# HPA 允许 queue-worker 在无积压时归零，有积压时按外部值恢复。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_consumer_lag
          selector:
            matchLabels:
              name: worker_tasks
        target:
          type: Value
          value: "30"

这里的 Value 是整个外部指标的目标值；如果你的适配器返回的是每个 Pod 的平均量，应重新评估 AverageValue 与指标聚合方式，避免把“总积压”误当成“单 Pod 积压”。

用 API 与状态条件验收

我会把验收拆成两层：第一层确认 API 返回指标，第二层确认 HPA 是否认为零副本由自己管理。HPA 自动缩到零后，状态里会出现 ScaledToZero=True；如果运维者直接把 Deployment 手动设为零，HPA 会把它视为暂停，不会凭外部指标擅自唤醒。

# 查看 HPA 条件与失败原因，重点关注 ScaledToZero 和外部指标获取状态。
kubectl describe hpa queue-worker -n default

若看到 ScalingActive=False 或 FailedGetExternalMetric，优先沿着 API 查询、适配器日志和 selector 排查。副本数停在零本身不是充分的故障证据。

为升级、回滚和冷启动留边界

v1.37 升级期间，apiserver 负责接受 minReplicas: 0，controller-manager 负责实际伸缩；版本错位时不要提前创建这类 HPA。回滚或关闭特性前，先把相关 HPA 改回至少一个副本，并把当前为零的工作负载拉起。

另外，缩到零节省的是闲置资源，付出的是冷启动时间。它更适合可等待的持久队列消费者，不适合要求请求立即有 Pod 接住的普通 HTTP 服务；Service 不会替零副本工作负载缓存请求。生产中还应结合默认的缩容稳定窗口、队列保留时间、镜像拉取时间和消费者初始化时间做灰度。

常见问题

只写 minReplicas: 0 为什么不生效？

必须至少存在一个 Object 或 External 指标，并且 v1.37 的特性在 apiserver 与 controller-manager 两端都可用；只写 CPU 或内存指标不满足条件。

Prometheus 有数据，HPA 仍提示指标不存在怎么办？

Prometheus 有序列不等于聚合 API 已暴露。先查询 external.metrics.k8s.io，再检查适配器的 seriesQuery、标签 selector、命名空间和权限。

Deployment 手动缩到零后能否自动恢复？

不能把手动置零当成 HPA 自动缩零。只有 HPA 自己缩到零并记录 ScaledToZero=True 时，后续外部指标才会触发恢复。