Kubernetes VPA：垂直自动扩缩容建议

栗子

发布时间：2026-09-09| 4人浏览过

原创

理解 VPA：它如何生成 CPU 与内存建议

VPA (Vertical Pod Autoscaler) 与 HPA (Horizontal Pod Autoscaler) 的核心区别在于扩缩维度：HPA 通过增减 Pod 副本数应对流量波动，而 VPA 专注于调整单个 Pod 的 CPU 与内存请求（requests）和限制（limits）。VPA 由三个核心组件协同工作：Recommender 负责持续采集 Metrics Server 或 Prometheus 提供的历史与实时资源使用数据，通过统计算法（如分位数回归）计算出最优资源配比；Updater 负责监控当前 Pod 资源与推荐值的差异，并在策略允许时触发更新；Admission Controller 则在 Pod 创建或重建时拦截请求，将计算出的资源值注入到容器规范中。VPA 生成的建议值分为三类：Target 代表算法认为最理想的资源分配值；Lower Bound 是维持当前工作负载稳定运行的最低安全阈值；Upper Bound 则是防止资源过度分配的硬性上限。这些建议并非凭空猜测，而是基于过去数天至数周的实际负载曲线动态演算得出，确保既能避免 OOM 或 CPU 节流，又能提升集群整体资源利用率。

该节需要什么真实配图：Kubernetes VPA 官方架构图或基于真实 VPA 组件关系制作的架构截图，清晰展示 Recommender、Updater、Admission Controller 与 Pod/Deployment 的关系。 — Kubernetes 官方 VPA 架构图，展示 Recommender、Updater、Admission Controller 与 Pod/Deployment 的协作关系。

部署并创建 VPA：先用 Off 模式观察建议值

在生产环境启用 VPA 前，必须确保集群已正确部署 Metrics Server 或兼容的自定义指标 API，否则 Recommender 将无法获取基础监控数据。创建 VPA 对象时，建议优先将 updateMode 设置为 Off，以便在不干扰业务的前提下观察 .status.recommendation 字段的输出。配置 YAML 中，targetRef 用于绑定目标 Deployment 或 StatefulSet；containerPolicies 允许针对特定容器定义资源策略，其中 minAllowed 与 maxAllowed 用于划定资源调整的硬性边界，防止算法给出极端值；controlledResources 则明确指定 VPA 仅管理 CPU 或内存。例如，通过 kubectl apply -f vpa-off.yaml 部署后，可执行 kubectl get vpa <name> -o yaml 查看状态。此时 VPA 仅处于只读分析阶段，不会触发任何 Pod 变更。经过 24 至 48 小时的负载积累，recommendation.containerRecommendations 中将逐步填充 target、lowerBound 和 upperBound 的具体数值，为后续自动调整提供可靠依据。

该节需要什么真实配图：真实 Kubernetes VPA YAML 配置与 kubectl get vpa -o yaml 输出截图，突出 updateMode、资源策略和 recommendation 字段。 — 真实 kubectl VPA 输出截图，包含 updateMode、RecommendationProvided 以及 CPU/内存的 Lower Bound、Target 等推荐值。

从建议到自动调整：选择更新模式并验证效果

确认建议值合理后，可根据业务容忍度切换更新模式。Off 模式仅输出建议；Initial 模式仅在 Pod 首次创建时应用建议，适合无状态且启动频繁的任务；Recreate 模式会在检测到资源偏差时主动驱逐旧 Pod 并重建新 Pod，适用于可接受短暂中断的服务；InPlaceOrRecreate 与 InPlace 则依赖 Kubernetes 1.27+ 的原地调整特性，尝试在不重建的情况下修改容器资源，失败时回退到重建。验证效果时，可通过 kubectl describe pod 对比调整前后的 requests 与 limits，并使用 kubectl get events 追踪 Updater 的调度行为。务必注意，Recreate 模式会触发 Pod 驱逐，若未配置合理的 PodDisruptionBudget (PDB)，可能导致服务可用性骤降。建议在变更窗口期逐步放量，并配合 kubectl rollout status 监控 Deployment 就绪状态，确保自动扩缩容不会引发级联故障。

该节需要什么真实配图：真实终端验证截图，展示 VPA recommendation、Pod 资源请求变化、Pod 重建或原地 resize 前后的状态。 — 真实终端验证截图，展示 kubectl get pod 与 kubectl get vpa 的结果以及 VPA 自动模式下的推荐 CPU/内存值。

避坑与生产实践：资源边界、HPA 冲突与 Pending 风险

VPA 的推荐算法虽智能，但缺乏对集群全局拓扑的感知，极易因建议值超出节点可分配资源（Allocatable）而导致 Pod 陷入 Pending 状态。因此，必须严格配置 minAllowed 与 maxAllowed，将其限制在节点实际可用范围内。另一个高频陷阱是 VPA 与 HPA 的指标冲突：若两者同时基于 CPU 或内存指标进行调节，会形成 VPA 调大请求导致 HPA 认为负载降低而缩容副本的震荡循环。官方明确建议，同一工作负载的 CPU 或内存指标只能交由 VPA 或 HPA 之一管理，若需共存，HPA 应切换至自定义指标（如 QPS 或延迟）。此外，多 VPA 对象匹配同一工作负载会引发 Webhook 注入冲突，需确保 targetRef 唯一性；部分旧版集群不支持 Pod 级别资源覆盖，需提前验证 Admission Controller 兼容性。结合 PDB 设置最小可用副本比例，并定期审查 VPA 事件日志，是保障生产环境平稳运行的关键防线。