4. Metrics Server 与 HPA：基于 CPU/内存的自动扩缩容原理

在 Kubernetes 集群中，水平 Pod 自动扩缩容（HPA）是实现弹性伸缩的核心组件。它通过持续监控工作负载的资源使用率（如 CPU 和内存），动态调整 Pod 的副本数量，从而在流量高峰时保证服务质量，在低谷时节省资源。Metrics Server 作为集群资源指标的聚合层，为 HPA 提供了实时的 CPU/内存数据来源。

4.1 Metrics Server：资源指标的采集与聚合

Metrics Server 是一个轻量级的集群级指标收集器，它从每个节点上的 kubelet 收集资源使用数据，并通过 Kubernetes API 聚合暴露给 HPA 和 kubectl top 命令。它不存储历史数据，只提供实时快照。

4.2 HPA 工作原理与核心流程

HPA 控制器作为一个控制循环，定期（默认每 15 秒）执行以下步骤：

1. 获取指标：通过 Metrics Server API 查询目标工作负载（Deployment/StatefulSet）当前所有 Pod 的 CPU 或内存使用率。
2. 计算期望副本数：根据当前总使用量和目标利用率，计算所需的 Pod 副本数。
3. 更新副本数：修改工作负载的 replicas 字段，触发控制器创建或删除 Pod。
4. 冷却/回弹：在扩缩容操作后，HPA 会进入冷却窗口，避免频繁抖动。

4.3 基于 CPU 与内存的扩缩容配置

HPA 支持通过 YAML 声明式配置。以下是一个典型的基于 CPU 和内存的 HPA 示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 500Mi

4.4 多指标协同与扩缩容策略

HPA 支持同时配置多个指标。当多个指标同时生效时，HPA 会分别计算每个指标对应的期望副本数，并取其中的最大值作为最终结果。这种机制确保了即使某个指标未达到阈值，其他指标也可能触发扩容。

4.5 冷却窗口与防抖动机制

为了防止频繁扩缩容导致的系统抖动（Thrashing），HPA 内置了冷却机制：

• 扩容冷却（Scale-up Cooldown）：默认 3 分钟。扩容操作后，HPA 会等待一段时间再评估是否需要再次扩容。
• 缩容冷却（Scale-down Cooldown）：默认 5 分钟。缩容操作后，HPA 会等待更长时间，避免因短暂流量下降而过度缩容。
• 容忍窗口（Tolerance）：默认 0.1（10%）。当计算出的期望副本数与当前副本数差异在 10% 以内时，HPA 不会执行扩缩容操作。

behavior:
  scaleUp:
    stabilizationWindowSeconds: 60
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

4.6 常见问题与排查思路