Vertical Pod Autoscaler 实战：VPA 配置示例与推荐行为深度解析
发布时间：2026/9/16 14:36:39 作者：尧图编辑部 阅读量：1,286
Vertical Pod Autoscaler 实战VPA 配置示例与推荐行为深度解析【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler本篇技术指南以 Kubernetes Vertical Pod AutoscalerVPA的官方示例文档 vertical-pod-autoscaler/docs/examples.md 为核心骨架系统讲解 VPA 在真实集群中的十个典型配置场景从 Limit/Request 比例保持、LimitRange 封顶、资源策略覆盖到多 Recommender 部署、OOMKill 后内存回调、CPU 管理静态策略适配、驱逐行为约束、命名空间限定、Webhook failurePolicy 与全局资源上限。读者学完后将能够针对不同工作负载画像精准调优 vpa-recommender 与 vpa-admission-controller 的启动参数并理解每个配置背后的源码级实现原理。目录场景一保持 Limit 与 Request 成比例场景二将推荐值封顶在 LimitRange 内场景三资源策略覆盖 LimitRange场景四启动多个 Recommender 服务不同工作负载画像场景五OOMKill 后的自定义内存回调策略场景六适配 CPU 管理静态策略整数 CPU 推荐场景七按伸缩方向与资源类型控制驱逐行为场景八限定 VPA 监控的命名空间范围场景九设置 Webhook 的 failurePolicy场景十全局资源上限防止 Pod 不可调度总结场景一保持 Limit 与 Request 成比例问题背景Kubernetes 允许容器单独声明requests与limits二者不必相等。VPA 默认只修改容器的requests但在容器模板中显式声明了limits时VPA 在应用推荐值时会把limits与requests之间的比例关系一并保持下来。示例说明容器模板声明requests为 500 milli CPU 1 GB 内存limits为 2 GB 内存即 limit/request 比例为 2:1VPA 给出的推荐值1000 milli CPU 2 GB 内存VPA 应用推荐后的结果requests更新为 1000 milli CPU 2 GB 内存同时内存limits被更新为4 GB维持模板中 2:1 的 limit/request 比例。底层原理这一行为由 vpa-updater 在应用RecommendedPodResources时执行——当模板存在limits时updater 会基于新requests与原有比例重新计算limits。这意味着不要在容器模板中显式设置 limit 而期望 VPA 忽略它若希望 VPA 只调 request 不调 limit应在模板中移除 limit 声明或借助场景三的资源策略进行控制。场景二将推荐值封顶在 LimitRange 内问题背景集群管理员通常会通过 LimitRange 对命名空间内的容器资源施加最大限制。VPA 应用推荐值时会主动将推荐值钳制到 LimitRange 允许的范围内避免推荐值违反准入策略导致 Pod 更新失败。示例说明容器模板requests500 milli CPU 1 GB 内存limits2 GB 内存LimitRange每容器内存limits上限为 3 GBVPA 推荐值1000 milli CPU 2 GB 内存应用结果内存limits被设置为3 GB封顶到 LimitRange 上限内存requests被设置为1.5 GB保持模板中 2:1 的 limit/request 比例3 GB / 2 1.5 GB。关键点VPA 会先按场景一的规则推导出推荐值2 GB request → 4 GB limit再检测到 4 GB 超出 LimitRange 上限 3 GB于是以 3 GB 为新的 limit 基准并反向按比例推算 request1.5 GB从而同时满足不超 LimitRange与保持模板比例两个约束。CPU 推荐1000 milli CPU不受影响因为它未超出任何限制。场景三资源策略覆盖 LimitRange问题背景LimitRange 提供的是上限封顶而 VPA 的ContainerResourcePolicy.spec.resourcePolicy.containerPolicies提供的是下限保底minAllowed与上限约束maxAllowed。当两者冲突时资源策略优先于 LimitRange 的推导结果。示例说明容器模板requests500 milli CPU 1 GB 内存limits2 GB 内存LimitRange每容器内存limits上限 3 GB资源策略要求容器requests至少为 750 milli CPU 2 GB 内存VPA 推荐值1000 milli CPU 2 GB 内存应用结果内存requests被提升到2 GB遵循资源策略的下限高于推荐值本身的 2 GB 逻辑内存limits被设置为4 GB按模板 2:1 的 limit/request 比例2 GB × 2 4 GB。值得注意的细节在此例中内存 limit4 GB实际上超出了 LimitRange 上限3 GB但资源策略明确要求了更高的 request因此 VPA 遵循资源策略。这提醒使用者当资源策略的minAllowed与 LimitRange 上限发生冲突时VPA 会尊重资源策略的显式要求。因此在同时配置 LimitRange 与 VPA 资源策略时需要保证二者的取值协调一致避免出现 Pod 更新后仍被准入控制器拒绝的连锁问题。资源策略的完整字段包括minAllowed、maxAllowed、controlledResources、controlledValues等可在 vertical-pod-autoscaler/docs/api.md 中查阅对应的 Go 类型定义位于 vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go。场景四启动多个 Recommender 服务不同工作负载画像问题背景vpa-recommender 使用**百分位percentile**从历史用量直方图中计算推荐值。不同业务对风险偏好不同有的希望覆盖 90% 的用量峰值有的希望更激进地覆盖 95%。默认的TargetCPUPercentile为 0.990%但你可以启动多个 Recommender各自使用不同百分位服务不同画像的工作负载。关键启动参数定义于 vertical-pod-autoscaler/pkg/recommender/config/config.go参数作用默认值--recommender-nameperformance指定该 Recommender 的名称只有 VPA 在 spec 中显式声明使用该名称时才会收到它的推荐默认名default--target-cpu-percentile0.95用于计算 CPU target 推荐的用量百分位不影响 CPU 下界、上界及内存推荐0.9操作步骤以标准部署 vertical-pod-autoscaler/deploy/recommender-deployment.yaml 为基底复制一份并修改containers[0].argscontainers: - name: recommender args: - --recommender-nameperformance - --target-cpu-percentile0.95在VerticalPodAutoscaler的 spec 中通过recommenders字段选择使用哪个 Recommenderspec: recommenders: - name: performance源码佐证--recommender-name的 flag 注释明确说明——Recommender 只会为配置了相同 recommender name 的 VPA 生成推荐如果 name 保持默认值它也会为未显式指定 recommender 的 VPA 生成推荐不要在同一集群中运行两个同名 Recommender。这意味着标准推荐器默认名会继续服务所有未显式指定recommenders的 VPA而额外的performance推荐器只服务显式选择它的 VPA二者可并行共存。注意不同 Recommender 之间各自维护独立的推荐历史与 checkpoint切换 Recommender 意味着 VPA 会基于新推荐器的模型重新开始计算。场景五OOMKill 后的自定义内存回调策略问题背景当 VPA 观察到容器发生 OOMKill 事件时会基于事件中的内存使用量上调内存推荐值其计算遵循如下公式recommendation max( memory-usage-in-oomkill-event oom-min-bump-up-bytes, memory-usage-in-oomkill-event * oom-bump-up-ratio )即取绝对值增量与比例增量两者中的较大者防止内存增量过小导致再次 OOM。两个可配置参数定义于 vertical-pod-autoscaler/pkg/recommender/config/config.go默认常量见 vertical-pod-autoscaler/pkg/recommender/model/aggregations_config.go参数作用默认值--oom-bump-up-ratioOOM 发生后的内存回调比例1.2即内存上调 20%--oom-min-bump-up-bytesOOM 发生后内存的最小绝对增量字节100 * 1024 * 1024 100 MiB在 Recommender 部署中使用containers: - name: recommender args: - --oom-bump-up-ratio2.0 - --oom-min-bump-up-bytes524288000上例将比例回调调整为 2.0翻倍最小绝对增量调整为 524288000 字节 500 MiB。适合内存波动剧烈、一次 OOM 后需要大幅回弹的业务。源码细节flag 注释还强调这两个值属于全局默认值适用于所有 VPA除非在 VPA spec 中按对象覆盖对应聚合配置的 per-VPA 覆盖机制。公式中max()取两者的较大值即当usage * ratio大于usage min-bump时按比例放大否则按最小增量放大。场景六适配 CPU 管理静态策略整数 CPU 推荐问题背景Kubernetes 的 CPU 管理静态策略static policy 要求容器在创建时即分配到整数个 CPU才能获得独占 CPU 的保证。若 VPA 推荐出小数 CPU如 1.5 核则容器无法匹配静态策略。为此VPA 提供一个推荐后处理器post-processor将 CPU 推荐向上取整为整数取整后仍然执行推荐值的封顶capping逻辑。启用方式为 vpa-recommender 传入--cpu-integer-post-processor-enabledtrueflag 定义与注释见 vertical-pod-autoscaler/pkg/recommender/config/config.go。按容器粒度选择启用该后处理器只作用于在 VPA 对象上打了特定注解的容器。注解格式为vpa-post-processor.kubernetes.io/{containerName}_integerCPUtrue其中{containerName}替换为目标容器名。例如容器名为app则注解键为vpa-post-processor.kubernetes.io/app_integerCPU。源码佐证实现位于 vertical-pod-autoscaler/pkg/recommender/routines/cpu_integer_post_processor.go常量vpaPostProcessorPrefix vpa-post-processor.kubernetes.io/、vpaPostProcessorIntegerCPUSuffix _integerCPU注解值必须是true才会生效Process()从 VPA 注解中提取容器名仅对匹配容器执行setIntegerCPURecommendation取整方式为recommendation.RoundUp(resource.Scale(0))即向绝对值增大方向舍入到整数核注解同时出现在启用了该后处理器的 VPA 对象上时CPU 推荐会被向上取整为整数且 capping封顶仍在其后应用——因此取整结果仍受maxAllowed/全局上限约束。若同一容器未打注解则该后处理器对其推荐不做任何处理。场景七按伸缩方向与资源类型控制驱逐行为问题背景vpa-updater 通过驱逐 Pod 使其重建从而应用新的资源推荐。频繁驱逐会带来不必要的业务中断。VPA 支持在 spec 中声明.updatePolicy.evictionRequirements为驱逐行为增加额外约束一个EvictionRequirement包含一个资源列表和一个changeRequirement后者通过对比新推荐值与容器当前 requests进行求值。可用取值类型定义见 vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.gochangeRequirement含义TargetHigherThanRequests新目标推荐高于当前 requests即扩容才允许驱逐TargetLowerThanRequests新目标推荐低于当前 requests即缩容才允许驱逐示例仅在 CPU 或内存扩容时允许驱逐同时禁止两者都缩容时的驱逐updatePolicy: evictionRequirements: - resources: [cpu, memory] changeRequirement: TargetHigherThanRequests语义细节结合 vertical-pod-autoscaler/pkg/updater/priority/scaling_direction_pod_eviction_admission.go 的Admit实现每个EvictionRequirement需要被求值为true才能允许驱逐所有声明的 requirement 都必须通过单个 requirement 的求值规则为其resources列表中至少一个资源满足changeRequirement即视为通过checkChangeRequirement逐个资源比较currentRequests与recommendation因此上例中只要 CPU 或内存任一方向扩容驱逐即被允许只有 CPU 与内存同时缩容时才被阻止。重要提醒这并不能完全阻止缩容——Pod 可能因其他原因如节点重启、手动删除、Deployment 滚动更新被重建重建后的 Pod 会应用最新推荐值包括更小的资源请求。更完整的上下文与用法说明参见官方 AEP vertical-pod-autoscaler/enhancements/4831-control-eviction-behavior/README.md。场景八限定 VPA 监控的命名空间范围问题背景默认情况下 VPA 的三个组件recommender、updater、admission-controller会处理所有命名空间中的 VPA 对象。在多租户或敏感命名空间如kube-system共存的集群中管理员往往希望缩小监控范围。两个互斥选项定义于 vertical-pod-autoscaler/common/flags.go 的InitCommonFlags参数作用--ignored-vpa-object-namespaces逗号分隔的命名空间列表忽略这些命名空间中的 VPA 对象--vpa-object-namespace只监控单个命名空间中的 VPA 对象约束这两个选项不能同时使用互斥。源码在 vertical-pod-autoscaler/common/flags.go 的ValidateCommonConfig中强制校验若两者同时非空组件会记录错误并调用klog.FlushAndExit直接退出防止以错误配置运行。典型用法# 忽略 kube-system 与 monitoring 两个命名空间 --ignored-vpa-object-namespaceskube-system,monitoring # 或只监控 business 命名空间 --vpa-object-namespacebusiness该参数对 recommender、updater、admission-controller 三个组件通用需在所有组件上保持一致配置。另外被忽略的命名空间中的 VPA 对象不会被垃圾回收器清理flag 注释中的说明。场景九设置 Webhook 的 failurePolicy问题背景VPA admission-controller 以 MutatingAdmissionWebhook 的形式拦截 Pod 创建请求并注入推荐值。Webhook 默认的failurePolicy为Ignore——即 Webhook 调用失败时Pod 创建流程继续执行不注入推荐值保证可用性优先。改为 Fail通过为 vpa-admission-controller 传入以下参数可将 failurePolicy 切换为Fail--webhook-failure-policy-failtrueflag 定义见 vertical-pod-autoscaler/pkg/admission-controller/config/config.go其注释明确提示请谨慎使用。实现上admission-controller 在注册 webhook 配置时根据该 flag 选择admissionregistration.Fail或admissionregistration.Ignore见 vertical-pod-autoscaler/pkg/admission-controller/config.go 与对应测试 vertical-pod-autoscaler/pkg/admission-controller/config_test.go。风险与缓解若 VPA 出现故障Fail策略可能导致所有 Pod 创建失败影响面极大。官方文档建议若确实需要Fail应配合使用场景八的命名空间限定来缩小风险面搭配--ignored-vpa-object-namespaceskube-system保证系统关键组件所在命名空间不受 Webhook 故障影响或使用--vpa-object-namespace只让 Webhook 处理特定命名空间。场景十全局资源上限防止 Pod 不可调度问题背景known-limitations 文档 指出vpa-recommender并不感知集群的最大可分配资源allocatable可能推荐出比集群最大节点还大的资源量。即使集群启用了 Cluster Autoscaler新增节点也无法容纳该 PodPod 将永久停留在Pending不可调度状态。解决方案为 vpa-recommender 指定两个全局上限参数参数作用--container-recommendation-max-allowed-cpu单容器 CPU 推荐的全局最大值--container-recommendation-max-allowed-memory单容器内存推荐的全局最大值flag 定义见 vertical-pod-autoscaler/pkg/recommender/config/config.go类型为resource.QuantityValue支持1000m、4Gi等 Kubernetes 资源量写法。优先级规则flag 注释与官方文档共同确认若 VPA 已在.spec.resourcePolicy.containerPolicies.maxAllowed中定义 max allowed则优先于全局上限若 VPA 只对 cpu 或 memory其中一种定义了 max allowed则全局上限会合并到缺失的那个维度若 VPA 完全未定义 max allowed则使用全局上限。推荐取值公式建议按最大节点的可分配资源减去 DaemonSet Pod 的资源请求再减去安全余量计算max allowed largest nodes allocatable - resource requests of DaemonSet pods - safety margin其中largest nodes allocatable取自节点的.status.allocatable字段。[!WARNING] 这两个 flag 是容器级container-level上限。如果某个 Pod 启用多个容器自动伸缩各容器推荐值的总和仍可能超过最大节点的 allocatable理论上依然可能不可调度。不过实践中该情况并不常见——通常一个 Pod 中只有一个主容器其余是无需自动伸缩或资源请求极低的 sidecar。配置时可结合场景三的 per-VPAmaxAllowed为特殊 Pod 单独收紧上限进一步降低风险。总结本文基于 vertical-pod-autoscaler/docs/examples.md 的十个官方示例串联了 VPA 三组件recommender / updater / admission-controller的关键配置面Limit/Request 比例保持与 LimitRange 封顶决定了推荐值如何落地到 Pod资源策略与全局资源上限提供了从 per-VPA 到集群级的双重约束多 Recommender 与百分位调整让不同业务按风险偏好获得差异化推荐OOMKill 回调、整数 CPU 后处理器、驱逐行为约束则针对具体运行场景提供了细粒度调优手段而命名空间限定与 Webhook failurePolicy共同构成了多租户场景下的安全护栏。相关参数均可在 vertical-pod-autoscaler/pkg/recommender/config/config.go、vertical-pod-autoscaler/common/flags.go 与 vertical-pod-autoscaler/pkg/admission-controller/config/config.go 中核对默认值与语义标准部署模板参考 vertical-pod-autoscaler/deploy/recommender-deployment.yaml。建议在生产环境变更任一参数前先在测试集群结合 vertical-pod-autoscaler/docs/development-and-testing.md 中的集成测试流程验证行为。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
尧图网站开发 