Horizontal Pod Autoscaler 如何工作，它与 Cluster Autoscaler 有何关系？

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** 根据观测到的指标（CPU、内存或自定义指标）增加或减少 **Pod 副本**。**Cluster Autoscaler (CA)** 在 Pod 无法调度或 node 利用不足时增加或减少 **node**。它们工作在不同的层次，并协同工作。

## 两个 autoscaler，两个层次

```text
HPA  → 扩缩 POD  (一个 Deployment 更多/更少的副本)      —— 响应负载
CA   → 扩缩 NODE (增大/缩小集群的机器数)                 —— 响应 PENDING Pod
VPA  → (附带) 调整一个 Pod 的 request/limit             —— 响应合理设定大小

典型流程：负载上升 → HPA 加 Pod → Pod 装不下 → CA 加一个 node →
              Pod 得以调度。负载下降 → HPA 减 Pod → node 空闲 → CA 移除它。
```

## HPA 控制循环如何工作

```text
每约 15 秒 HPA controller：
  1. 从 metrics-server / 自定义 API 读取当前指标（例如各 Pod 平均 CPU）
  2. 计算：desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. 把 Deployment 朝该值扩缩（受 minReplicas/maxReplicas 约束）
例：4 个 Pod 处于 80% CPU，目标 50% → 4 * 80/50 = 6.4 → 7 个副本。
稳定窗口 (stabilization window) 抑制抖动（尤其在缩容时）。
```

## 一个 HPA manifest

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # 保持平均 CPU 约为 REQUEST 的 60%
  behavior:                           # 可选：调优扩容/缩容速度
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # 当前/目标指标、副本数
kubectl top pods                      # 需要 metrics-server
```

## 重要的依赖与注意事项

```text
• 基于 CPU/内存的 HPA 需要安装 metrics-server；利用率是相对于 REQUEST 计算的
  → 如果 request 未设或有误，HPA 的计算毫无意义。请正确设置 request。
• 自定义/外部指标（RPS、队列深度）需要一个 adapter（Prometheus Adapter, KEDA）。
• HPA 与手动的 `replicas` 冲突 —— 让 HPA 掌管副本数。
• Cluster Autoscaler 同样需要正确的 request：它查看 Pending Pod 的 REQUEST 来
  决定 node 扩缩。node 扩容需要数分钟（provisioning），所以要留出余量。
```

## 为什么这很重要

自动扩缩是 Kubernetes 自动匹配容量与需求的方式，理解这两个层次是区分高性价比、有韧性的集群与配置过度或不足的集群的高级知识。关键心智模型是 **HPA 扩缩 Pod** 以响应负载（依据观测到的 CPU、内存或自定义指标调整副本数），而 **Cluster Autoscaler 扩缩 node** 以响应调度压力（当 Pod Pending 时增加机器，当 node 空闲时移除它们）——它们工作在不同层次并协作：HPA 只有在有空间时才能加 Pod，而 CA 提供那个空间。理解 HPA 的控制循环——`desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)` 公式、周期性调和，以及防止抖动的稳定窗口——让你能配置和调试它，而不是把它当作魔法。注意事项才是高级判断力显现之处：基于 CPU/内存的 HPA **需要 metrics-server**，并**相对于 request** 计算利用率，所以错误或缺失的 request 会让它的计算毫无意义；自定义指标（每秒请求数、队列深度）需要像 Prometheus Adapter 或 KEDA 这样的 adapter；且 node 扩容需要数分钟，所以余量很重要。因为合理设定容量直接影响流量激增下的可靠性和平静时段的云开销，且因为两个 autoscaler 都依赖正确设置的 resource request，精通 HPA 和 Cluster Autoscaler 是高效、可靠地运维生产 Kubernetes 的基础。

两个 autoscaler，两个层次

HPA 控制循环如何工作

一个 HPA manifest

重要的依赖与注意事项

为什么这很重要

相关问题