VPA 与 Cluster Autoscaler：Pod 资源调整与节点扩缩容

1. VPA（Vertical Pod Autoscaler）：垂直 Pod 自动扩缩容。
2. Cluster Autoscaler（CA）：集群节点自动扩缩容。

先看一个生产环境中的场景。

假设你运行一个 Java 微服务：

flowchart TB
    N0["Deployment"]
    N1["Pod-1：CPU 500m，Memory 512Mi"]
    N2["Pod-2：CPU 500m，Memory 512Mi"]
    N3["Pod-3：CPU 500m，Memory 512Mi"]
    N0 --> N1
    N0 --> N2
    N0 --> N3

业务运行一段时间后，发现：

• 每个 Pod 的 CPU 使用率不高。
• 每个 Pod 的内存长期接近 512Mi。
• 部分请求出现 OOMKilled。
• 增加 Pod 数量并没有完全解决单个实例内存不足的问题。

这时候就需要考虑 VPA。

另一方面，如果 HPA 将 Pod 数量从 3 个增加到 20 个，但集群已经没有足够资源，就需要 Cluster Autoscaler。

一、VPA：Vertical Pod Autoscaler#

1. 什么是 VPA？#

VPA 全称：

Vertical Pod Autoscaler，垂直 Pod 自动扩缩容器。

它的主要作用是：

根据容器历史资源使用情况，自动推荐或调整 CPU 和 Memory 的 Requests、Limits。

注意与 HPA 的区别：

• HPA：调整 Pod 数量。
• VPA：调整单个 Pod 的资源配置。

例如：

原来的配置：

1
resources:
2
  requests:
3
    cpu: 500m
4
    memory: 512Mi

VPA 分析一段时间的运行情况后，可能推荐：

1
resources:
2
  requests:
3
    cpu: "1"
4
    memory: "1Gi"

也就是说：

1
原来：
2
CPU：500m
3
Memory：512Mi
4

5
调整后：
6
CPU：1 核
7
Memory：1Gi

这样可以使 Pod 的资源请求更接近实际需求。

2. VPA 解决什么问题？#

实际生产环境中，经常遇到以下问题：

注意：

VPA 不能保证消除 OOMKilled。如果应用存在内存泄漏或瞬时内存峰值过高，仍然需要从应用本身排查。

二、VPA 的整体架构#

VPA 主要由三个组件构成：

1. Recommender
2. Updater
3. Admission Controller

1. Recommender：资源推荐器#

Recommender 负责分析 Pod 的历史资源使用情况。

例如：

1
Pod-1
2
CPU 使用：
3
200m
4
250m
5
300m
6
280m
7

8
Memory 使用：
9
400Mi
10
450Mi
11
500Mi
12
480Mi

Recommender 根据历史指标和算法，计算资源推荐值。

输出：

1
CPU Request：350m
2
Memory Request：600Mi

它的核心职责：

• 收集资源使用历史。
• 分析资源使用趋势。
• 计算资源推荐值。
• 将推荐值提供给 VPA。

注意：推荐值不一定等于简单的平均值。VPA 会根据资源使用分布、历史窗口和安全边际等因素进行计算。

2. Updater：更新器#

Updater 负责检查现有 Pod 是否需要调整资源配置。

例如：

1
当前 Pod：
2
Memory Request = 512Mi
3

4
VPA 推荐：
5
Memory Request = 1Gi

如果配置允许自动更新，Updater 会判断是否需要驱逐并重新创建 Pod。

为什么需要重新创建？

因为传统 Kubernetes 工作负载中的容器资源 Requests 和 Limits 通常不能直接在运行中的容器上任意修改。

因此，VPA 的部分更新模式需要通过重新创建 Pod 来应用新的资源配置。

3. Admission Controller：准入控制器#

Admission Controller 负责在 Pod 创建时，根据 VPA 推荐结果调整 Pod 的资源配置。

例如：

Deployment 创建新 Pod：

1
resources:
2
  requests:
3
    cpu: 500m
4
    memory: 512Mi

Admission Controller 拦截 Pod 创建请求，并根据 VPA 推荐结果调整：

1
resources:
2
  requests:
3
    cpu: 1
4
    memory: 1Gi

随后 Pod 按照新的资源配置创建。

4. 三个组件的关系#

可以记忆为：

1
Recommender：计算
2
Updater：替换
3
Admission Controller：注入

三、VPA 更新模式：Off、Initial、Recreate 与 InPlaceOrRecreate#

VPA 有几种不同的更新模式。

其中最重要的是：

• Off
• Initial
• Recreate
• InPlaceOrRecreate

1. Off：只推荐，不自动修改#

1
updatePolicy:
2
  updateMode: "Off"

含义：

VPA 只计算推荐资源值，不自动修改现有 Pod。

例如：

1
当前 Requests：
2
CPU：500m
3
Memory：512Mi
4

5
VPA 推荐：
6
CPU：1
7
Memory：1Gi

但现有 Pod 仍然使用：

1
CPU：500m
2
Memory：512Mi

适合：

• 生产环境资源评估。
• 观察资源使用趋势。
• 在正式调整之前进行验证。

这是比较安全的初始使用方式。

2. Initial：只在创建 Pod 时调整#

1
updatePolicy:
2
  updateMode: "Initial"

含义：

只在新 Pod 创建时应用推荐资源。

已经运行的 Pod 不会因为 VPA 推荐变化而被主动驱逐更新。

例如：

1
旧 Pod：
2
CPU Requests = 500m
3

4
VPA 推荐：
5
CPU Requests = 1
6

7
新 Pod 创建：
8
CPU Requests = 1

适合：

希望新创建的 Pod 使用更合理的资源配置，但不希望 VPA 主动重建现有 Pod。

3. Recreate：通过重新创建 Pod 更新#

1
updatePolicy:
2
  updateMode: "Recreate"

含义：

当资源推荐值变化，需要更新现有 Pod 时，Updater 可以驱逐旧 Pod，再由工作负载控制器创建新 Pod。

例如：

flowchart TB
    N0["旧 Pod：<br/>Memory Requests = 512Mi"]
    N1["VPA 推荐：<br/>Memory Requests = 1Gi"]
    N2["Updater 驱逐旧 Pod"]
    N3["Deployment 创建新 Pod"]
    N4["Admission Controller 注入新资源"]
    N5["新 Pod：<br/>Memory Requests = 1Gi"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5

注意：

这可能造成 Pod 重启或短暂容量下降。

生产环境需要结合副本数量、PodDisruptionBudget 和应用可用性设计。

4. InPlaceOrRecreate：优先原地调整#

较新版本的 VPA 还支持：

1
updatePolicy:
2
  updateMode: "InPlaceOrRecreate"

含义：

优先尝试原地调整容器资源；如果无法原地调整，再考虑通过重新创建 Pod 完成更新。

但需要注意：

原地调整能力与 Kubernetes 版本、VPA 版本、容器资源更新支持及具体资源类型有关，不能假设所有集群都能无重启修改资源。

5. 四种模式对比#

四、安装与配置 VPA#

VPA 不是所有 Kubernetes 集群默认安装的组件，需要额外部署。

它属于 Kubernetes 自动伸缩生态中的独立组件。

1. 检查 VPA 是否安装#

1
kubectl get crd | grep verticalpodautoscaler

如果已经安装，通常能看到类似：

1
verticalpodautoscalers.autoscaling.k8s.io

也可以检查组件：

1
kubectl get pods -n kube-system | grep vpa

2. VPA 示例配置#

假设已经安装 VPA。

创建：

1
apiVersion: autoscaling.k8s.io/v1
2
kind: VerticalPodAutoscaler
3

4
metadata:
5
  name: nginx-vpa
6

7
spec:
8
  targetRef:
9
    apiVersion: apps/v1
10
    kind: Deployment
11
    name: nginx
12

13
  updatePolicy:
14
    updateMode: "Off"

解释：

这里先使用 Off 模式，只生成资源推荐值。

3. 查看 VPA 推荐结果#

1
kubectl get vpa

查看详细信息：

1
kubectl describe vpa nginx-vpa

重点关注：

1
Recommendation:
2
  Container Recommendations:
3
    Container Name: nginx
4

5
    Target:
6
      Cpu: 350m
7
      Memory: 600Mi

不同 VPA 版本的输出格式可能有所不同。

常见推荐字段：

注意：

VPA 资源推荐结果并不代表资源已经应用到正在运行的 Pod。

需要区分：

Recommendation 是建议，Update 是实际调整。

五、VPA 推荐值如何理解？#

VPA 不只是给出一个资源数字，还会提供多个推荐范围。

例如：

1
Container Recommendations:
2

3
CPU:
4
  Lower Bound: 200m
5
  Target:      500m
6
  Upper Bound: 800m
7

8
Memory:
9
  Lower Bound: 256Mi
10
  Target:      768Mi
11
  Upper Bound: 1Gi

它们分别代表什么？

例如：

1
CPU Target = 500m

意味着 VPA 建议将 CPU Requests 调整到 500m 左右。

注意：这些推荐值主要用于资源配置优化，不是容器实际使用量的硬性保证。

1. VPA 的资源计算逻辑#

可以简单理解为：

flowchart TB
    N0["历史资源使用数据"]
    N1["统计资源使用分布"]
    N2["计算资源需求"]
    N3["加入安全边际"]
    N4["生成推荐值"]
    N5["应用资源上下限约束"]
    N6["输出推荐结果"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6

例如：

某个 Java 应用长期内存使用在 500Mi 左右，但偶尔出现 800Mi 峰值。

VPA 不一定会将 Requests 设置为 500Mi，而可能根据使用分布推荐更高的数值，避免资源请求长期偏低。

2. VPA 只调整 Requests 吗？#

不完全是。

VPA 可以根据配置和版本调整 CPU、Memory 的 Requests，也可以涉及 Limits。

通常生产环境需要特别关注：

• Requests 是否合理。
• Limits 是否过低。
• 是否会因为资源调整触发容器重启。
• 是否影响 QoS 等级。

一个常见的设计方式是让 VPA 主要负责 Requests 推荐，再由团队根据应用特性确定 Limits。

六、VPA 与 HPA 如何协同？#

这是生产环境非常重要的内容。

假设：

flowchart TB
    N0["Deployment"]
    N1["Pod-1"]
    N2["Pod-2"]
    N3["Pod-3"]
    N0 --> N1
    N0 --> N2
    N0 --> N3

HPA 根据 CPU 使用率决定是否增加 Pod。

VPA 根据历史资源使用情况调整 CPU Requests。

但是问题来了：

HPA 的 CPU 利用率计算依赖 CPU Requests，而 VPA 又会修改 CPU Requests。

这可能造成控制器之间相互影响。

1. 冲突示例#

假设：

1
CPU 实际使用：400m
2
CPU Requests：500m

那么：

[ CPU 利用率 =\frac{400}{500}\times100%=80% ]

HPA 目标是 50%，因此可能扩容。

随后 VPA 将 Requests 调整到：

1
CPU Requests：1

此时：

[ CPU 利用率 =\frac{400}{1000}\times100%=40% ]

HPA 又可能认为当前资源使用率已经偏低。

于是：

flowchart TB
    N0["VPA 提高 Requests"]
    N1["HPA 计算 CPU 利用率下降"]
    N2["HPA 缩容"]
    N0 --> N1
    N1 --> N2

这可能形成不理想的控制关系。

2. 生产环境建议#

需要注意，VPA 的具体资源控制范围应结合所用版本及配置确认。

核心原则：避免 HPA 与 VPA 同时争夺同一资源指标的控制权。

七、Cluster Autoscaler：节点自动扩缩容#

现在进入 Kubernetes 自动伸缩体系的第三个组件。

1. 什么是 Cluster Autoscaler？#

Cluster Autoscaler，简称 CA。

它的主要作用：

根据集群中 Pod 的调度需求，自动增加或减少 Kubernetes Node。

例如：

当前集群：

1
Node-1：4 核 CPU
2
Node-2：4 核 CPU

现在 HPA 扩容：

1
当前 Pod：4
2
目标 Pod：12

但两个节点已经没有足够资源。

于是出现：

1
Pod-1：Running
2
Pod-2：Running
3
Pod-3：Running
4
Pod-4：Running
5

6
Pod-5：Pending
7
Pod-6：Pending
8
Pod-7：Pending
9
...

Cluster Autoscaler 会检查这些 Pending Pod。

如果发现增加节点可以解决调度问题，就会向底层基础设施申请新的 Node。

例如：

flowchart TB
    N0["HPA 扩容"]
    N1["Pod Pending"]
    N2["Cluster Autoscaler"]
    N3["检查调度条件"]
    N4["请求云平台扩容"]
    N5["新增 Node"]
    N6["Scheduler"]
    N7["Pod 成功调度"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6
    N6 --> N7

注意：

Cluster Autoscaler 并不是直接创建 Pod，而是负责节点容量调整。

2. Cluster Autoscaler 的工作前提#

Cluster Autoscaler 通常需要：

1. Kubernetes 集群存在可扩缩节点组。
2. 节点组能够通过云平台 API 或其他基础设施接口扩缩容。
3. 有可用的节点资源规格。
4. 节点组没有超过最大节点数量。
5. 新节点能够加入 Kubernetes 集群。

例如云平台中：

1
Node Group：worker-group
2

3
Min Size：2
4
Max Size：10
5
Desired Size：3

含义：

当集群资源不足时，CA 可以请求增加节点，但不能超过 Max Size。

八、Cluster Autoscaler 如何触发扩容？#

重点来了：

是不是只要节点 CPU 使用率达到 80%，Cluster Autoscaler 就会增加节点？

不是。

Cluster Autoscaler 最核心的扩容触发条件是：

存在无法调度的 Pod，并且增加节点能够帮助这些 Pod 成功调度。

1. Pending Pod 触发扩容#

例如：

Node-1：

1
CPU Allocatable：4 核
2
已分配 Requests：3.8 核

Node-2：

1
CPU Allocatable：4 核
2
已分配 Requests：3.9 核

现在创建一个 Pod：

1
resources:
2
  requests:
3
    cpu: "1"

Scheduler 检查：

1
Node-1：剩余 0.2 核
2
Node-2：剩余 0.1 核

没有节点满足要求。

于是：

1
Pod：Pending
2
Reason：FailedScheduling

CA 检测到这个 Pending Pod。

如果节点组中存在适合该 Pod 的节点类型，就会尝试扩容。

2. 扩容过程#

flowchart TB
    N0["Pod Pending"]
    N1["Scheduler 调度失败"]
    N2["Cluster Autoscaler 检查"]
    N3["模拟增加节点后的调度结果"]
    N4["选择合适的 Node Group"]
    N5["调用云平台 API"]
    N6["增加云主机"]
    N7["Node 加入 Kubernetes"]
    N8["Pod 被 Scheduler 调度"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6
    N6 --> N7
    N7 --> N8

注意：

如果 Pod 因为节点亲和性、污点、卷拓扑等约束而无法调度，即使增加普通节点，也可能无法解决问题。

例如：

1
nodeSelector:
2
  gpu: nvidia

如果新增节点没有：

1
gpu=nvidia

那么新增普通节点也无法帮助该 Pod 调度。

CA 需要的是能够满足 Pod 调度条件的节点，而不是任意节点。

九、Cluster Autoscaler 如何缩容？#

扩容解决资源不足问题。

缩容则解决资源浪费问题。

假设：

1
Node-1：运行 3 个 Pod
2
Node-2：运行 2 个 Pod
3
Node-3：没有业务 Pod
4
Node-4：没有业务 Pod

如果业务流量下降，HPA 将副本数量从 20 减少到 5。

那么：

Node-3、Node-4 可能变成空闲节点。

Cluster Autoscaler 可以尝试将它们缩容。

1. 节点缩容的基本条件#

通常需要满足：

• 节点资源利用率足够低。
• 节点上的 Pod 可以安全迁移。
• 其他节点有足够资源容纳这些 Pod。
• 不违反 PodDisruptionBudget。
• 不存在阻止节点删除的特殊条件。

2. 缩容过程#

flowchart TB
    N0["业务流量下降"]
    N1["HPA"]
    N2["减少 Pod 副本"]
    N3["部分 Node 空闲"]
    N4["Cluster Autoscaler"]
    N5["检查节点是否可以迁移 Pod"]
    N6["驱逐可迁移 Pod"]
    N7["删除空闲 Node"]
    N8["云平台释放计算资源"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6
    N6 --> N7
    N7 --> N8

注意：

Cluster Autoscaler 不会简单地因为节点 CPU 使用率低就立即删除节点。

它需要先评估节点上的工作负载是否可以安全迁移。

十、PodDisruptionBudget（PDB）：节点缩容保护机制#

这是理解 Cluster Autoscaler 缩容时必须掌握的知识。

1. 什么是 PDB？#

PDB 全称：

PodDisruptionBudget。

它用于限制应用在主动中断操作期间允许同时不可用的 Pod 数量。

例如：

一个 Web 服务有 5 个副本。

我们希望：

无论节点维护还是集群缩容，至少保持 4 个 Pod 可用。

可以使用 PDB。

2. 创建 PDB#

1
apiVersion: policy/v1
2
kind: PodDisruptionBudget
3

4
metadata:
5
  name: web-pdb
6

7
spec:
8
  minAvailable: 4
9

10
  selector:
11
    matchLabels:
12
      app: web

解释：

1
minAvailable: 4

表示主动中断期间，至少需要保持 4 个匹配的 Pod 可用。

如果当前有 5 个健康 Pod：

1
允许同时中断：1 个

如果已经有 1 个 Pod 不健康：

1
当前健康 Pod：4
2
允许再中断：0 个

3. maxUnavailable#

PDB 还可以使用：

1
apiVersion: policy/v1
2
kind: PodDisruptionBudget
3

4
metadata:
5
  name: web-pdb
6

7
spec:
8
  maxUnavailable: 1
9

10
  selector:
11
    matchLabels:
12
      app: web

表示：

最多允许 1 个匹配的 Pod 不可用。

注意：

minAvailable 和 maxUnavailable 不能同时配置。

4. PDB 如何影响节点缩容？#

假设：

1
Web Deployment：5 个副本
2

3
PDB：
4
minAvailable = 4

现在 CA 想要删除 Node-1。

Node-1 上运行：

1
Web-1
2
Web-2

如果一次驱逐两个 Pod，就可能违反 PDB。

因此 CA 需要通过 Eviction API 进行受 PDB 约束的驱逐。

如果没有足够的可用 Pod 预算，节点缩容可能被阻止或延迟。

这可以避免节点维护或缩容时，大量业务副本同时中断。

5. PDB 与普通 Pod 删除的区别#

这是容易考错的知识点：

PDB 主要约束通过 Eviction API 发起的自愿中断。

它不是一个绝对的 Pod 存活保证。

例如：

• 节点突然宕机。
• 内核崩溃。
• 直接删除 Pod 对象。
• 某些不受 Eviction API 约束的操作。

都不能认为一定会被 PDB 阻止。

另外，Deployment 正常缩容属于工作负载自身的副本调整，不等同于节点维护时的 Eviction 操作，不能依赖 PDB 阻止 HPA 缩容。

十一、HPA + Cluster Autoscaler 联动#

这是 Kubernetes 生产环境最重要的弹性伸缩架构之一。

1. 完整业务场景#

假设一个电商系统：

初始状态：

1
Node-1：4 CPU
2
Node-2：4 CPU
3

4
Deployment：
5
3 个 Web Pod

突然出现促销活动，访问量大幅增加。

HPA 检测到 CPU 使用率超过目标：

1
当前 Pod：3
2
目标 Pod：15

HPA 将 Deployment 的期望副本数调整为 15。

但是：

1
Node-1：资源不足
2
Node-2：资源不足

于是部分 Pod 进入 Pending。

CA 检测到：

1
存在无法调度的 Pod

开始请求云平台增加节点。

最终：

1
Node-1
2
  +--- Web-1
3
  +--- Web-2
4

5
Node-2
6
  +--- Web-3
7
  +--- Web-4
8

9
Node-3
10
  +--- Web-5
11
  +--- Web-6
12
  +--- Web-7
13

14
Node-4
15
  +--- Web-8
16
  +--- Web-9
17
  ...

业务恢复后：

1. HPA 减少 Pod 副本。
2. 部分节点变为空闲节点。
3. CA 检查是否可以安全迁移 Pod。
4. CA 删除多余节点。
5. 云平台释放计算资源。

2. 完整架构#

Kubernetes 弹性伸缩架构

flowchart TB
    N0["业务流量变化"]
    N1["Metrics Server / Prometheus<br/>提供 CPU、Memory、业务指标"]
    N2["HPA<br/>调整 Pod 副本数量"]
    N3["Scheduler<br/>尝试将 Pod 调度到现有节点"]
    N4["Pod Pending<br/>现有节点资源不足或无法满足调度条件"]
    N5["Cluster Autoscaler<br/>请求底层基础设施增加 Node"]
    N6["新 Node 加入集群"]
    N7["Pod 成功调度，业务扩容完成"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4
    N4 --> N5
    N5 --> N6
    N6 --> N7

3. 三种自动伸缩机制的分工#

实际生产中还需要注意：

HPA 扩容速度、节点启动速度、镜像下载时间、应用启动时间都存在延迟。

因此，不能认为 HPA 和 CA 一旦联动，业务流量增长时就一定能立即完成扩容。

对于流量突发业务，还可以结合：

• 预热副本。
• 最小副本设置。
• 节点预留容量。
• 节点组最小规模。
• 合理的扩容策略。

十二、Cluster Autoscaler 与 HPA 的常见故障#

1. HPA 已经扩容，但 Pod 一直 Pending#

查看：

1
kubectl get pods -o wide

查看：

1
kubectl describe pod <pod-name>

如果出现：

1
FailedScheduling
2
Insufficient cpu

说明节点资源不足。

进一步检查：

1
kubectl get nodes

如果 CA 已安装，还需要检查 CA 日志：

1
kubectl logs -n kube-system \
2
  deployment/cluster-autoscaler

具体 Deployment 名称取决于安装方式。

2. Pod Pending，但是 CA 没有扩容#

常见原因：

重点：

CA 不是看到 Pending Pod 就无条件扩容。

它需要判断新增节点是否能够解决调度问题。

3. CA 无法缩容#

常见原因：

• 节点上有不能安全驱逐的 Pod。
• PDB 不允许继续驱逐。
• Pod 使用了本地存储。
• Pod 有特殊调度约束。
• 其他节点没有足够资源容纳这些 Pod。
• 节点仍然有较高资源利用率。
• 节点处于缩容保护状态。

排查：

1
kubectl logs -n kube-system \
2
  deployment/cluster-autoscaler

以及：

1
kubectl get pdb -A

1
kubectl describe pdb web-pdb

十三、CKA 必须掌握的命令#

补充：

VPA、Cluster Autoscaler 属于扩展组件，是否可用取决于集群是否安装和配置。CKA 核心考试中更应优先掌握 Pod、Deployment、资源配置、HPA 和 PDB 的基本操作与排错。

十四、本节知识体系总结#

Kubernetes 自动伸缩体系

HPA：Horizontal Pod Autoscaler 水平扩缩容 调整 Pod 副本数量

VPA：Vertical Pod Autoscaler 垂直扩缩容 调整 Pod CPU、Memory 资源配置

CA：Cluster Autoscaler 节点扩缩容 调整 Kubernetes Node 数量

VPA 组件

VPA 更新模式

PDB 关键字段