Kubernetes 1.37 HPA 如何缩到 0 个 Pod：外部指标、ScaledToZero 与恢复条件

队列消费者、按需批处理和 GPU 任务常常有一段很长的空闲时间：服务一直保留 Pod，成本在没有工作时仍然持续发生。Kubernetes 1.37 把 HorizontalPodAutoscaler（HPA）缩到 0 个 Pod 的能力推进到 Beta，并默认开启，但它不是把任意 Deployment 都改成“无人值守自动唤醒”。关键前提是，HPA 必须依赖对象指标或外部指标，不能只看 CPU 或内存。

把 spec.minReplicas 设为 0 只是打开下限，真正能否从 0 恢复，还取决于外部指标是否能在没有工作 Pod 时继续提供可用信号，以及指标适配器和扩容路径是否已经验证。

Kubernetes 1.37 这项变化解决了什么

过去，HPA 通常至少保留一个副本。对于消息队列消费者、定时批处理或低频 GPU 推理服务，这个副本可能大部分时间都在等待。v1.37 的变化是：当 HPA 使用对象指标或外部指标时，可以把工作负载降到 0，等指标恢复到扩容条件后再拉起 Pod。

这里的“对象指标”可以理解为与 Kubernetes 对象相关的业务信号，“外部指标”则常见于队列积压数、待处理任务数等集群外部或适配器提供的观测值。新闻本身值得关注的地方，不是多了一个 YAML 字段，而是弹性伸缩的空闲态开始有了明确的控制器状态。

先搭一个最小的 scale-to-zero 实验

准备一个不会误导结论的指标

实验不要先拿 CPU 利用率做验证。可以选择消息队列的待处理数量、任务服务的 backlog 或其他能在消费者缩到 0 后仍由独立系统维护的外部指标。指标适配器需要能够把这个信号暴露给 HPA，且在没有目标 Pod 时不会因为查询对象消失而返回空值。

配置时只保留一个明确的扩容信号，避免同时混入多个不易解释的阈值。示意配置如下，字段名称和指标适配器的实际定义要以你使用的指标 API 为准：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 12
  metrics:
  - type: External
    external:
      metric:
        name: queue_backlog
      target:
        type: AverageValue
        averageValue: "1"

这个片段表达的是实验边界：空闲时允许为 0，有待处理任务时目标上限为 12。它不是某个云厂商指标适配器的通用复制品；实际部署前要核对 queue_backlog 是否真实存在、查询范围是否正确、阈值单位是否与适配器一致。

用状态字段确认是否由 HPA 缩到 0

应用配置后，先看 HPA 和目标 Deployment 的状态，不要只看 Pod 列表。重点是 HPA 的 status.conditions：当控制器主动完成缩零时，应出现 type: ScaledToZero 且 status: "True"；恢复到非零副本后，该条件会以 NotScaledToZero 表示当前不再处于 HPA 缩零状态。

可复核的检查思路是：

kubectl get hpa queue-worker -o yaml
kubectl get deployment queue-worker
kubectl get pods -l app=queue-worker

空闲时，Deployment 副本数应为 0，HPA 条件同时说明这是控制器的缩零结果。若只看到 Deployment 为 0，却没有对应条件，先排查是否有人手动改过副本数，不要把两个状态混在一起。

从 0 恢复时，真正需要验收的顺序

把一条测试消息放入队列后，观察顺序应该是：外部指标上升，HPA 重新计算目标，Deployment 副本数从 0 增加，Pod 通过就绪检查，消费者开始取消息。每一步都要有时间戳或事件记录，否则看到 Pod 最终启动，并不能证明扩容是被正确的指标触发。

• 空闲态：队列为零，Deployment 副本为 0，HPA 条件为 ScaledToZero=True。
• 来量态：独立指标系统仍能读到 backlog，HPA 没有因为目标为空而失去信号。
• 启动态：Deployment 创建 Pod，应用就绪检查通过，扩容延迟符合业务可接受范围。
• 处理态：队列长度下降，消费者确实处理了消息，而不是只启动了空 Pod。
• 回收态：处理完成后再次缩到 0，并重新出现可解释的缩零状态。

为什么 CPU 和内存不能直接负责唤醒

CPU 和内存是运行中 Pod 的资源指标。工作负载已经为 0 时，没有活跃 Pod 产生这类指标，HPA 就缺少“该不该从 0 拉起”的输入。因此，Kubernetes 官方说明这项 scale-to-zero 能力面向对象指标或外部指标，而不是把 CPU、内存目标也自动变成唤醒信号。

常见的错误做法是把 minReplicas 改成 0，然后仍只保留 CPU 指标，最后把无法恢复归结为 HPA 不稳定。更稳的设计是让队列、任务调度器或独立采集链路承担唤醒信号，CPU 和内存只在 Pod 已经运行后参与常规水平扩缩容。

上线前的边界与回退动作

Beta 代表能力已经进入更成熟的阶段，不代表所有工作负载都适合缩零。冷启动很重、必须保持连接、或者指标链路本身会随 Pod 一起消失的服务，都应先保留最小副本。回退也很直接：把 minReplicas 临时恢复为 1，确认业务稳定后再分析指标适配器和启动延迟。

发布时至少记录三组数据：缩到 0 的时间、外部指标恢复到扩容阈值的时间、首个 Pod 就绪并处理业务的时间。它们能把“省下了空闲成本”和“用户是否等得起冷启动”放到同一张验收表里。

常见问题

设置了 minReplicas: 0，为什么仍然保持一个 Pod？

先看指标类型和 HPA 条件。若使用 CPU 或内存目标，或者控制器判断当前指标不满足缩零条件，保持最小运行副本是预期边界；也要排除其他控制器或手动副本设置的影响。

缩到 0 后，HPA 会不会永远不再扩容？

不会，只要外部指标链路在空负载时仍可查询，并且来量后能及时返回高于目标的值。若指标来自已缩零的应用自身，信号可能一起消失，这种设计就不适合拿来唤醒。

ScaledToZero 和手动 replicas=0 有什么区别？

前者是 HPA 控制器主动缩零，并会在 HPA 状态条件中留下可识别的状态；后者是人工或其他控制器修改副本数。排查时同时查看 HPA、Deployment 和事件，不能只凭副本数判断来源。

适合先拿什么业务做试点？

优先选择有独立队列或任务表、允许冷启动、能够重试的批处理和异步消费者。对实时请求入口、长连接服务和启动后还要预热很久的任务，应先测延迟，再决定是否缩零。

把新闻变化落到一次可复现验收

Kubernetes 1.37 的 scale-to-zero 值得采用的前提，是把它当成一条完整的信号链来验证：外部指标在零副本时仍可用，HPA 状态能解释缩零来源，来量后 Deployment 能恢复，业务最终真的被处理。只改一个副本下限而没有这四项证据，得到的只是一个看起来更省资源、实际可能无法唤醒的配置。