3. HPA 配置详解

HorizontalPodAutoscaler（HPA）是 Kubernetes 实现工作负载弹性伸缩的核心控制器。本章深入拆解 HPA YAML 的完整结构，逐一解析 minReplicas、maxReplicas、targetAverageUtilization、targetAverageValue 以及 behavior 字段的语义、配置要点与实战陷阱。

3.1 HPA YAML 完整结构

一个标准的 HPA 资源定义包含 API 版本、种类、元数据、伸缩目标、副本范围、指标规则和行为策略。以下是一个生产级 HPA 示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 800Mi
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15
      - type: Percent
        value: 100
        periodSeconds: 15
      selectPolicy: Max
版本说明：生产环境请始终使用 autoscaling/v2 API 版本，它支持多指标、自定义指标和 behavior 字段。v1 版本仅支持单 CPU 指标且无行为控制，已不推荐使用。

3.2 minReplicas 与 maxReplicas

这两个字段定义了副本数的上下边界，是 HPA 伸缩的安全护栏。

字段 默认值 语义 生产建议
minReplicas 1（未设置时） HPA 允许缩容的最小副本数，保证基础容量 至少 2~3，保障高可用
maxReplicas 无（必须显式设置） HPA 允许扩容的最大副本数，防止资源耗尽 根据集群容量和业务峰值设定，通常为 min 的 5~10 倍
避坑指南：
  • minReplicas 不能为 0（除非配合 cluster-autoscaler 且使用特殊配置）。
  • maxReplicas 必须大于 minReplicas，否则 HPA 会报错。
  • 当 Pod 因 PDB（PodDisruptionBudget）或节点资源不足无法调度时，HPA 可能无法达到 maxReplicas，需结合集群自动伸缩策略。

3.3 targetAverageUtilization 与 targetAverageValue

这两个字段是 HPA 指标目标值的两种表达方式，分别对应“百分比利用率”和“值”。

3.3.1 targetAverageUtilization（百分比利用率）

仅适用于 CPU 和内存等资源指标。HPA 计算所有 Pod 的平均使用率（当前使用量 / Request 值），并与目标利用率比较。

  • 计算公式： 期望副本数 = 当前副本数 × (当前平均利用率 / 目标利用率)
  • 典型配置： CPU 目标利用率 70%~80%，内存目标利用率 60%~70%。
  • 注意事项： 必须为容器设置 requests，否则 HPA 无法计算利用率。

3.3.2 targetAverageValue（值）

适用于资源指标和自定义指标。HPA 计算所有 Pod 的平均值，直接与目标值比较。

  • 计算公式： 期望副本数 = 当前副本数 × (当前平均值 / 目标值)
  • 典型配置： 内存平均使用量 800Mi，自定义 QPS 指标 1000。
  • 优势： 不依赖 requests 设置，适合内存等非 CPU 指标。
对比维度 targetAverageUtilization targetAverageValue
适用指标类型 CPU、内存等资源指标 资源指标 + 自定义指标 + 外部指标
依赖 Request 是，必须设置 否
语义直观性 高（百分比更易理解） 中（需了解业务基准值）
适合场景 CPU 密集型服务 内存、QPS、延迟等值指标
实战建议： 对于 CPU 指标优先使用 averageUtilization；对于内存指标推荐使用 averageValue，因为内存利用率受 JVM、缓存等影响，百分比往往不准确。

3.4 behavior 字段：精细化伸缩控制

behavior 字段是 autoscaling/v2 引入的弹性策略控制机制，允许分别定义扩容和缩容的行为，包括稳定窗口、策略类型、选择策略等。

3.4.1 核心子字段

子字段 说明 默认值
stabilizationWindowSeconds 稳定窗口，HPA 在窗口期内取最大/最小推荐值，防止抖动 扩容：0；缩容：300
policies 策略列表，每个策略包含 type（Pods/Percent）、value、periodSeconds 扩容：Pods 4 + Percent 100；缩容：Percent 100
selectPolicy 多策略时选择方式：Max（取最大变化量）、Min（取最小）、Disabled（禁用该方向） 扩容：Max；缩容：Max

3.4.2 稳定窗口（Stabilization Window）

稳定窗口是 HPA 防止频繁伸缩的关键机制。HPA 在窗口期内记录所有历史推荐值，缩容时取窗口内的最大值，扩容时取最小值，从而过滤瞬时波动。

  • 缩容稳定窗口（默认 300 秒）： 避免因短暂负载下降而过度缩容，适合有流量毛刺的业务。
  • 扩容稳定窗口（默认 0 秒）： 通常不设窗口，保证快速响应负载增长。

3.4.3 策略类型与选择

每个策略定义了在 periodSeconds 时间内允许变化的 Pod 数量或百分比。

  • Pods 策略： 数量限制，适合小规模集群或精确控制。
  • Percent 策略： 相对比例限制，适合大规模集群或快速伸缩。
  • selectPolicy: Max： 取所有策略中变化量最大的值，扩容时常用。
  • selectPolicy: Min： 取变化量最小的值，缩容时常用。
生产配置示例：
  • 扩容：Pods: 4 + Percent: 100%，每 15 秒评估一次，取最大变化量，快速响应。
  • 缩容：Percent: 10%，每 60 秒评估一次，稳定窗口 300 秒，缓慢释放资源。

3.5 HPA 伸缩决策流程

以下 SVG 图展示了 HPA 从指标采集到副本调整的完整决策链路：

HPA 伸缩决策流程 指标采集 计算 Pod 平均值 计算期望副本数 稳定窗口过滤 策略限制（Pods/Percent） 更新 Deployment 副本数 关键说明 • 指标来源：Metrics Server / Prometheus • 稳定窗口默认：扩容 0s / 缩容 300s • 策略选择：Max 取最大变化量

3.6 多指标协同与策略优先级

当 HPA 配置多个指标时，每个指标独立计算期望副本数，HPA 取所有计算结果中的 最大值 作为最终期望副本数。这意味着任何一个指标触发扩容都会导致副本增加，而缩容需要所有指标都满足缩容条件。

多指标协同原则：
  • CPU 和内存同时配置时，以两者中较高的期望副本数为准。
  • 自定义指标（如 QPS）与资源指标混合使用时，建议将自定义指标的目标值设为业务容忍上限。
  • 避免配置相互矛盾的指标（如同时使用 CPU 利用率和内存值，且目标值不协调）。

3.7 常见配置错误与排查

错误场景 现象 根因 解决方案
HPA 无法获取指标 HPA 状态显示 Unknown Metrics Server 未部署或 Pod 未设置 requests 部署 Metrics Server，检查 Pod 资源请求
副本数频繁抖动 Pod 数量在短时间内反复增减 稳定窗口过小或指标波动剧烈 增大缩容稳定窗口（如 300s→600s），调整策略周期
扩容速度过慢 负载突增时副本数跟不上 扩容策略过于保守或 periodSeconds 过大 使用 Pods: 4 + Percent: 100%，缩短周期到 15s
缩容后立即扩容 缩容完成后马上又扩容 稳定窗口未生效或指标有延迟 检查 stabilizationWindowSeconds 配置，确认指标采集间隔
重要提醒： 修改 HPA 配置后，使用 kubectl describe hpa <name> 查看 Events 和 Conditions 字段，可以快速定位配置问题。重点关注 Metrics 和 Conditions 部分的状态信息。

3.8 生产级 HPA 配置模板

以下是一个面向生产环境的 HPA 配置模板，融合了多指标、合理稳定窗口和精细化策略：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: production-service-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: production-service
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 75
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 1Gi
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 600
      policies:
      - type: Percent
        value: 5
        periodSeconds: 120
      selectPolicy: Min
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Pods
        value: 6
        periodSeconds: 15
      - type: Percent
        value: 100
        periodSeconds: 15
      selectPolicy: Max
模板要点：
  • CPU 利用率目标 75%，留有余量应对突发。
  • 内存目标 1Gi 值，避免 JVM 堆外内存导致的利用率偏差。
  • 缩容稳定窗口 600 秒（10 分钟），策略取 Min，每次最多缩容 5%，防止过快释放资源。
  • 扩容无稳定窗口，策略取 Max，支持快速扩容应对流量高峰。
← 上一章 📖 返回目录 下一章 →