2. VPA 基础概念：Vertical Pod Autoscaler 的工作原理与资源自动调整机制
Vertical Pod Autoscaler（VPA）是 Kubernetes 生态中用于自动调整 Pod 资源请求（Requests）和限制（Limits）的核心组件。与水平扩缩容（HPA）不同，VPA 通过垂直调整单个 Pod 的 CPU 和内存资源，解决资源利用率低、配置不合理等问题，是云原生成本优化的关键工具。
2.1 VPA 的核心工作流程
VPA 采用“Recommender → Updater → Admission Controller”三组件协作模式，实现资源建议的生成与自动注入。
核心流程： VPA 不直接修改运行中的 Pod，而是通过更新 Pod 模板或重建 Pod 来应用新的资源规格。
2.2 资源请求与限制的自动调整机制
VPA 的调整机制围绕 Requests 和 Limits 两个核心参数展开。Requests 用于调度决策，Limits 用于运行时资源上限控制。VPA 通过以下策略实现自动调整：
| 调整维度 | VPA 行为 | 对成本的影响 |
|---|---|---|
| CPU Requests | 基于历史 CPU 使用率的 P50~P95 分位数推荐 | 降低过度配置，减少集群资源浪费 |
| Memory Requests | 基于历史内存使用率的 P90~P95 分位数推荐，考虑 OOM 风险 | 避免内存超配导致的节点压力 |
| CPU Limits | 通常与 Requests 保持比例（如 1.5x~2x），或由用户自定义 | 防止突发流量导致 CPU 节流 |
| Memory Limits | 通常等于 Requests，或根据应用特性设置上限 | 减少 OOMKill 风险，提升稳定性 |
最佳实践： 对于生产环境，建议将 VPA 的
updateMode 设置为 "Auto" 或 "Initial"。Auto 模式会主动驱逐并重建 Pod 以应用新资源；Initial 模式仅在 Pod 首次创建时注入推荐值，适合无状态服务。
2.3 VPA 的推荐算法与资源水位计算
VPA Recommender 使用基于百分位数的资源推荐算法，核心计算逻辑如下：
- 数据采集： 从 Metrics Server 获取 Pod 过去 8 天的 CPU 和内存使用数据（默认窗口）。
- 分位数计算： 对 CPU 使用 P50（中位数）作为基准，对内存使用 P90~P95 作为基准，以应对内存的不可压缩特性。
- 安全边际： 在推荐值基础上增加 15% 的缓冲（Safety Margin），防止突发流量。
- 下限保护： 推荐值不低于容器原始 Requests 的 10%，避免过度缩容。
2.4 VPA 的三种更新模式对比
VPA 通过 updateMode 参数控制资源调整的自动化程度，不同模式适用于不同场景：
| 模式 | 行为描述 | 适用场景 | 成本优化效果 |
|---|---|---|---|
| Off | 仅生成推荐值，不自动应用 | 审计、手动评估阶段 | 无自动优化，需人工介入 |
| Initial | 仅在 Pod 创建时注入推荐值 | 无状态服务、滚动更新频繁的服务 | 中等，新 Pod 使用优化配置 |
| Auto | 自动驱逐并重建 Pod 以应用新资源 | 有状态服务、资源浪费严重的场景 | 高，持续优化资源利用率 |
注意事项： Auto 模式会导致 Pod 重建，可能引起服务短暂中断。建议结合 PodDisruptionBudget（PDB）使用，确保最小可用副本数。对于证书轮换作业等关键任务，建议在低峰期启用 Auto 模式。
2.5 VPA 与 HPA 的协同关系
在生产环境中，VPA 通常与 HPA（Horizontal Pod Autoscaler）配合使用，但需注意两者不能同时作用于同一 Pod 的同一资源维度：
- VPA 负责垂直维度： 调整单个 Pod 的 CPU/内存规格，解决“Pod 资源过大或过小”的问题。
- HPA 负责水平维度： 调整 Pod 副本数，解决“流量波动导致副本数不足或过多”的问题。
- 冲突规避： 避免 VPA 和 HPA 同时基于 CPU 或内存指标进行扩缩容，建议 HPA 使用自定义指标（如 QPS、连接数）。
通过 VPA 与 HPA 的合理搭配，可以实现“垂直调优 + 水平弹性”的双重成本优化策略，显著提升集群资源利用率。