📚 课程目录第2章弹性伸缩基础

弹性伸缩基础：水平Pod自动伸缩（HPA）与垂直Pod自动伸缩（VPA）的原理

在云原生架构中，弹性伸缩是保障服务稳定性与资源利用率的核心手段。Kubernetes 提供了两种互补的自动伸缩机制：水平 Pod 自动伸缩（HPA）和垂直 Pod 自动伸缩（VPA）。理解两者的原理、适用场景及协同方式，是构建高效指标采集链路的前提。

2.1 水平Pod自动伸缩（HPA）

HPA 通过调整工作负载的 副本数量 来响应负载变化。其核心思想是：当指标升高时增加 Pod 副本，指标降低时减少副本，使系统整体处理能力与实时需求匹配。

2.1.1 工作原理

HPA 控制器是一个控制循环，默认每 15 秒（由 --horizontal-pod-autoscaler-sync-period 控制）执行一次以下流程：

指标采集：从 Metrics Server、Prometheus 或自定义指标 API 获取目标 Pod 的当前指标值。
期望副本计算：根据当前指标值与目标值的比率，计算期望副本数。
更新工作负载：修改 Deployment/StatefulSet 的 replicas 字段，触发滚动更新或扩缩容。
冷却与回退：通过 --horizontal-pod-autoscaler-downscale-stabilization-window 等参数防止抖动。

  核心公式：

  期望副本数 = ceil[当前副本数 × (当前指标值 / 目标指标值)]

  例如：当前 2 个 Pod，CPU 使用率 80%，目标 50%，则期望副本数 = ceil[2 × (80/50)] = ceil[3.2] = 4。

2.1.2 支持的指标类型

指标类型	来源	典型用例
ResourceMetric	Metrics Server	CPU、内存利用率
PodMetric	自定义指标 API	QPS、请求延迟 P99
ObjectMetric	自定义指标 API	Ingress 流量、消息队列长度
ExternalMetric	外部指标 API	云服务队列深度、数据库连接数

2.1.3 关键配置参数

behavior.scaleUp.stabilizationWindowSeconds：扩容稳定窗口，默认 0 秒。
behavior.scaleDown.stabilizationWindowSeconds：缩容稳定窗口，默认 300 秒。
behavior.scaleUp.policies：扩容策略，如 Pods: 4/min 或 Percent: 100%/15s。
behavior.scaleDown.policies：缩容策略，通常更保守。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 1000
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

最佳实践：HPA 应至少配置两个指标——一个资源指标（如 CPU）用于基础容量规划，一个业务指标（如 QPS）用于精确响应负载变化。避免仅依赖单一指标导致误判。

2.2 垂直Pod自动伸缩（VPA）

VPA 通过调整 Pod 的 资源请求（Requests）和限制（Limits） 来匹配实际负载。与 HPA 增加副本不同，VPA 改变单个 Pod 的资源配置，适用于有状态应用或无法水平扩展的工作负载。

2.2.1 工作原理

VPA 由三个组件协同工作：

Recommender：基于历史指标和当前使用率，计算推荐的 CPU/内存请求值。
Updater：驱逐需要调整资源的 Pod，使其被重新创建时使用新的资源规格。
Admission Controller（VPA Admission Plugin）：在 Pod 创建时注入推荐的资源值，覆盖原始配置。

2.2.2 更新模式

模式	行为	适用场景
`Auto`	自动驱逐 Pod 并更新资源请求	无状态服务，可接受短暂重启
`Recreate`	与 Auto 类似，但强制重新创建	需要确保资源立即生效
`Initial`	仅在 Pod 创建时分配推荐值	新部署的服务，避免运行时驱逐
`Off`	仅提供推荐，不自动执行	人工审核后手动调整

2.2.3 资源推荐算法

VPA Recommender 使用 百分位算法 生成推荐值：

收集过去 8 天的 Pod 资源使用数据（默认窗口）。
计算 CPU 使用率的第 50 百分位（P50）作为基准。
计算内存使用率的第 95 百分位（P95）作为基准。
添加安全边际（默认 15% 的缓冲区）。
输出 lowerBound、target、upperBound 三个推荐值。

注意：VPA 与 HPA 在 CPU/内存指标上存在冲突。如果同时使用 HPA（基于资源指标）和 VPA，可能导致控制循环互相干扰。推荐方案：HPA 基于自定义指标（如 QPS），VPA 负责资源优化；或使用 VPA 的 Initial 模式仅初始化资源。

lowerBound：低于此值 Pod 可能 OOM 或 CPU 节流，触发 Updater 驱逐 • target：推荐的最佳资源请求值，兼顾性能与利用率 • upperBound：高于此值表示资源过度分配，建议下调

2.3 HPA 与 VPA 的协同策略

在实际生产环境中，HPA 和 VPA 并非二选一，而是需要根据工作负载特征设计协同策略：

场景	推荐方案	说明
无状态 Web 服务	HPA（基于 QPS）+ VPA（Initial 模式）	HPA 控制副本数，VPA 仅初始化资源，避免运行时冲突
有状态数据库	仅 VPA（Auto 模式）	数据库通常无法水平扩展，VPA 自动调整资源请求
批处理任务	HPA（基于队列深度）	任务队列长度驱动副本数，资源请求固定
混合负载	HPA（自定义指标）+ VPA（Off 模式）	VPA 仅提供推荐，人工审核后手动调整资源规格

关键原则：避免 HPA 和 VPA 同时基于同一资源指标（如 CPU）进行自动调整。如果必须同时使用，确保 HPA 基于业务指标（如 QPS、延迟），VPA 负责资源优化，两者在指标维度上正交。

2.4 指标采集对伸缩的影响

无论是 HPA 还是 VPA，其决策质量直接取决于 指标采集的时效性、准确性和粒度：

采集延迟：Metrics Server 默认 15 秒采集间隔，HPA 每 15 秒同步一次，端到端延迟约 30-60 秒。对于突发流量，这个延迟可能导致扩容滞后。
指标平滑：VPA Recommender 使用 8 天历史数据，对短期波动不敏感；HPA 支持 averageValue 聚合，减少毛刺影响。
自定义指标链路：使用 Prometheus Adapter 时，从指标暴露到 HPA 消费的完整链路包括：应用暴露 → Prometheus 采集 → Adapter 查询 → HPA 计算。每个环节都可能引入延迟或数据丢失。