Kubernetes 的 Horizontal Pod Autoscaler（HPA）负责根据实时负载自动调整工作负载的副本数量。它不像 Cluster Autoscaler 那样扩容节点，而是专注于 Pod 级别，让 Deployment、StatefulSet 或自定义资源能够跟随流量曲线上下浮动。启用 HPA 之后，运维人员不需要盯着监控面板手动执行 kubectl scale，但前提是配置正确、指标链路完整。

HPA 的计算逻辑并不复杂，但很多生产事故都出现在细节上，比如忘记设置资源请求、metrics-server 没有安装、behavior 参数没有调优导致频繁抖动。本文会把这些点逐个拆开说明。

一、HPA 的工作原理与指标来源

HPA 控制器默认每 15 秒从聚合 API 层读取一次指标数据，然后根据公式计算期望副本数。对于基于 CPU 使用率的资源指标，公式通常为：期望副本数 = ceil(当前副本数 × (当前 CPU 使用率 / 目标 CPU 使用率))。比如当前有 2 个副本，平均 CPU 使用率为 80%，目标是 50%，则期望副本数为 ceil(2 × 1.6) = 4。这个计算过程虽然简单，但前提是每个 Pod 都声明了 CPU 请求，否则使用率无法按百分比归一化。

HPA 支持多种指标类型。Resource 类型直接引用 Pod 的资源请求比例，适合 CPU 和内存；Pods 类型基于应用暴露的自定义指标，例如每秒请求数；Object 类型针对集群内某个对象，比如 Ingress 的 QPS；External 类型可以对接外部系统，比如云监控或消息队列积压量。不同指标类型需要不同的适配器，最常用的资源指标由 metrics-server 提供。没有部署 metrics-server 时，HPA 会一直提示 unable to fetch metrics，因此这是配置前的第一步。

验证指标链路是否通畅，可以执行 kubectl top pods 或 kubectl top nodes。如果命令能正常输出 CPU 和内存数据，说明 metrics-server 工作正常。也可以直接查看 API 返回：kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods。只要这一层数据可用，HPA 的 Resource 指标就能稳定获取。

二、从零开始配置 HPA 自动扩缩容

先创建一个 Deployment 作为被控对象。这里要特别强调 resources.requests 字段，因为 HPA 计算 CPU 和内存利用率时，分母就是 Pod 请求值，而不是节点实际容量。下面是一个简单的 Web 应用资源清单。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: app
        image: nginx:1.25
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi

创建好 Deployment 后，接着定义 HPA 对象。autoscaling/v2 版本支持同时配置多个指标，HPA 会对每个指标分别计算期望副本数，最终取最大值。以下示例同时监控 CPU 和内存，CPU 平均使用率超过 60% 就扩容，内存平均使用率超过 70% 也扩容，但最终副本数不会超过 10 个。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70

使用 kubectl apply -f hpa.yaml 创建后，可以通过 kubectl get hpa webapp-hpa -w 查看状态。TARGETS 列通常会显示当前值与目标值的比例，例如 42%/60%。如果这一列长时间显示 unknown，说明指标链路有问题，需要先检查 metrics-server 和资源请求。要验证自动扩容是否生效，可以给 Pod 增加负载，观察 REPLICAS 列是否从 2 逐步上升。

三、用 behavior 参数控制扩缩容节奏

默认情况下，HPA 的扩缩容动作相对保守，扩容可能不够快，缩容可能过于频繁。如果业务流量变化剧烈，可以使用 behavior 字段自定义行为。该字段在 autoscaling/v2 中提供，允许分别为 scaleUp 和 scaleDown 定义稳定窗口和策略。

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 60
    - type: Pods
      value: 4
      periodSeconds: 60
    selectPolicy: Max
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60
    selectPolicy: Min

上面这段配置表示扩容时不等待稳定窗口，60 秒内可以按当前副本数的 100% 或固定增加 4 个 Pod，两者取较大值；缩容时则要观察过去 300 秒，只有负载持续较低才会缩减，且 60 秒内最多缩减 10% 的副本数。这样能够减少流量低谷期的频繁伸缩，也避免因为指标瞬间波动而反复创建和销毁 Pod。

将 behavior 合并到 HPA 清单时，只需把它放在 spec 之下、scaleTargetRef 和 metrics 平级的位置。需要注意的是，stabilizationWindowSeconds 的取值会直接影响响应速度：设成 0 表示立即响应，但对于毛刺型流量可能造成扩容过快；设得太大又会让缩容显得迟钝。实际生产环境建议结合业务特征，先小范围压测再调整。

四、HPA 调优与常见问题排查

最常见的故障是 HPA 状态一直显示 unknown。多数情况下，这不是 HPA 本身的问题，而是指标聚合层没有就绪。可以先执行 kubectl get apiservices | grep metrics 查看 metrics API 是否可用，再确认 metrics-server Pod 是否正常运行。另一个容易被忽略的原因是 Pod 没有设置资源请求。没有 requests 时，HPA 无法计算 Resource 类型的利用率，会直接跳过该指标。

如果副本数没有按预期增加，还要检查 maxReplicas 是否过小、minReplicas 是否过大。当多个指标同时配置时，HPA 取所有指标计算出的最大值，因此即使 CPU 很低，内存持续超标也会触发扩容。反过来，缩容不生效通常是因为稳定窗口尚未结束，或者当前副本数已经等于 minReplicas。

在与 Cluster Autoscaler 配合时，如果节点资源不足，HPA 扩容出来的 Pod 会处于 Pending 状态，需要等节点扩容完成后才能运行。此时建议为节点池预留一定冗余，或者为关键业务设置优先级，避免 Pod 长时间无法调度。另外，给 Pod 设置合理的 requests 和 limits，既能保证 HPA 计算的准确性，也有助于调度器做出更合理的装箱决策。