Linux 知识库

Appearance

控制器-VerticalPodAutoscaler(VPA) ​

简介 ​

Vertical Pod Autoscaler (VPA) 是 Kubernetes 生态中一个强大的自动扩缩组件，它能根据 Pod 的历史实际资源使用情况，自动调整其 CPU 和内存的请求（Requests）和限制（Limits）。

它不是通过增加 Pod 数量（水平伸缩），而是通过调整单个 Pod 的资源配置（垂直伸缩）来解决问题，非常适合数据库这类有状态应用，或是水平扩容有限制的场景。

VPA 的核心组件如何协作 ​

VPA 通过三个核心组件协同工作，形成一个闭环的控制系统。下图展示了它们之间的协作关系和数据流：

组件功能详解：

  • Recommender（推荐器）：VPA 的核心决策模块。它会持续监控 Pod 的 CPU、内存历史用量以及OOM事件，通过专业的统计算法（如带衰减权重的直方图）生成推荐值。这些推荐值包含三档：lowerBound（下限，低于此值性能可能不佳）、target（目标推荐值）和upperBound（上限，高效用上限）。
  • Updater（更新器）：负责执行更新策略。它会将 Pod 当前的资源与 VPA 的推荐值进行比较，每当差异超出阈值时（具体规则取决于 updateMode），便会采取行动，例如驱逐 Pod 以使其被控制器重建。
  • Admission Controller（准入控制器）：作为集群的“看门人”，拦截所有 Pod 的创建请求（包括新建和因驱逐而重建的），自动将 target 推荐值写入新 Pod 的资源请求中，从而在 Pod 启动前就配置好“最优化”的值。

VPA 的更新模式 ​

VPA 的更新模式（updateMode）至关重要，它决定了 VPA 以何种方式、多大“强度”来应用推荐值。

  • Off (仅推荐)：仅作“顾问”，计算推荐值供人工参考，不执行任何自动更新，推荐值通过 kubectl describe vpa <vpa-name> 查看。
  • Initial (仅初始化)：仅在新 Pod 创建时应用一次推荐值，后续不再改动，适合在 Pod 生命周期内不支持重启的应用。
  • Recreate (重建)：一旦推荐值变化，立即驱逐并重建 Pod。这是 VPA 1.4.0 之前 Auto 模式的默认行为，可能引起服务波动。
  • InPlaceOrRecreate (首选原地更新)：这是新一代模式。Kubernetes 1.27 引入 Alpha , 1.35 成为 GA。它会优先尝试“原地”调整容器资源（无需重启 Pod），若失败则回退至 Recreate，能最大限度地降低对业务的影响。

VPA 的配置与资源策略 ​

VPA 的工作范围和行为可以通过其 YAML 配置文件进行精细化定制：

  1. 指定目标 (targetRef)：通过 spec.targetRef 字段明确指定 VPA 要管理的原生工作负载类型（如 Deployment、StatefulSet 等）。
  2. 设置安全边界 (resourcePolicy)：通过 spec.resourcePolicy 下的 containerPolicies 设置资源限制，防止推荐失控：
    • minAllowed / maxAllowed：为每个容器设置允许的资源请求的最小值和最大值，VPA 的推荐值将始终遵守该边界。
    • controlledResources：指定 VPA 只管理 Requests，还是同时管理 Requests 和 Limits。默认为 RequestsOnly。
    • controlledValues（可选）：微调 VPA 对资源请求的具体控制行为。
  3. 最小理论值：VPA 给出的推荐值有下限。CPU 单 Pod 最小推荐值为 25m，内存单 Pod 最小推荐值为 250Mi

VPA 与 HPA 的关系与最佳实践 ​

VPA 和水平 Pod 自动扩缩器 HPA 是互补工具。HPA 负责增减 Pod 副本数量以应对流量洪峰，而 VPA 则负责为这些 Pod 设定合理的资源规格。然而，同时运行它们可能会引发冲突：

  • 核心冲突：如果 HPA 基于 CPU 扩缩容，而 VPA 又调整了 Pod 的 CPU 请求，HPA 的计算基准就变了，可能导致 HPA 误判，引发“死亡螺旋”——Pod 数量激增、资源利用率降低、进而触发送更低的请求值。

因此，可以参考以下策略以安全地协同使用：

  • 分离监控指标：这是最关键的原则。如果必须同时使用 VPA 和 HPA，请配置 HPA 监控 CPU 和内存之外的指标（如请求数/秒、消息队列长度），避免与 VPA 管理的资源指标冲突。
  • 为 VPA 设置安全边界：通过 minAllowed 和 maxAllowed 限制可能的风险。
  • 采用渐进式上线策略：在关键生产环境中，先用 Off 模式观察 VPA 推荐值，确认无误后再考虑在非核心业务上启用 InPlaceOrRecreate 等自动更新模式。
  • 由 VPA 管理资源请求：一个常见的生产实践是，让 HPA 基于自定义指标来管理 Pod 数量，然后“授权” VPA 专门负责管理 Pod 的资源请求。

主要限制与注意事项 ​

在生产环境部署 VPA 之前，务必考虑其现有的限制：

  • 可能驱逐 Pod：在 Recreate 或 InPlaceOrRecreate 回退模式下，VPA 会通过驱逐 Pod 来应用新配置。这种中断对单副本应用影响较大，可能会造成约2-3分钟的周期性停机。对于多副本 Deployment，虽无完全停机，但也可能出现短暂连接错误。
  • 可能提出过量资源建议：VPA 缺乏全局视图，建议的 upperBound 可能超过节点可用资源，导致 Pod 因资源不足而卡在 Pending 状态。
  • 与 HPA 的天然冲突：如上节所述，同时使用 VPA 和监控 CPU/内存指标的 HPA 极易产生冲突，需严格遵循最佳实践进行规避。
  • 处于 Beta 阶段，未大规模测试：上游社区和各大云厂商均将 VPA 标记为 Beta 功能，警告其在超大规模集群中的表现尚需验证。
  • 集群范围的限制：单个集群中关联到 VerticalPodAutoscaler 对象的 Pod 总数上限为 1000 个，大规模集群需注意配额。
  • 对特定工作负载支持不佳：
    • JVM 应用：VPA 难以感知 JVM 内部的堆内存使用，可能导致推荐配置与实际需求不符。
    • DaemonSet 和裸 Pod：VPA 不支持直接管理由 DaemonSet 创建的 Pod 或未受控（replication controller）管理的裸 Pod。若指向此类对象可能导致行为异常。
  • 数据易失性：VPA 的 Recommender 组件默认只将历史数据存储在内存中，重启会丢失。虽有持久化选项，但默认不开启。

总结与建议 ​

Kubernetes VPA 是一个非常强大的资源优化工具，但在使用它的自动更新功能前，尤其在关键生产环境中，需要谨慎并做好充分准备。

若决定启用Recreate或InPlaceOrRecreate模式，强烈建议进行如下准备：

  1. 确保应用具备高可用性，至少运行 2 个以上副本。
  2. 配置 PodDisruptionBudget (PDB)，以限制因主动驱逐造成的服务中断。
  3. 全面测试应用的启动与恢复流程。

推荐的实践路径：

  1. 仅观察：为新应用部署一个 updateMode: Off 的 VPA，持续观察数天至一周，让其收集数据。
  2. 人工审查：通过 kubectl describe vpa 检查 Recommendation 字段，评估其建议是否合理。
  3. 启用更新：确认建议值安全后，将 updateMode 修改为 InPlaceOrRecreate。