VPA 频繁重启调这 3 个参数让 Pod 资源稳住【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler凌晨两点告警又刷屏了同一批 Pod 每隔十几分钟被驱逐重建一次CPU 请求在 300m 和 800m 之间来回跳。查下来不是流量问题而是 Vertical Pod AutoscalerVPA的阈值配置没设对——推荐值跟着使用率波动不停刷新Pod 资源稳不下来。把下面三个参数调到位这种频繁扩缩容可以明显收敛。VPA 为什么总在动VPA 的链路是三段式的recommender推荐器持续采集 Pod 的 CPU、内存使用历史算出新的推荐值写进 VPA 对象admission controller 在 Pod 创建时把推荐值注入进去updater更新器盯着存量 Pod一旦发现当前 request 和推荐值差异较大就按 updateMode即 VPA 拿到新推荐值后怎么把新配置落到 Pod 上执行变更最常见的手段是驱逐重建。说白了推荐值本身会随负载起伏业务稍微波动推荐值跟着变updater 一算差异显著又是一轮驱逐。换句话说没有阈值约束时任何一点使用率抖动都会传导成一次 Pod 重建——这正是 VPA 频繁扩缩容的根因。三个参数各管一件事参数作用取值范围默认值minAllowed / maxAllowed给推荐值夹一个上下限request 出不了这个区间CPU 从 1m 起、内存从 1Mi 起上限不设不限制controlledResources决定 VPA 管哪些资源可只让它管 CPU 或内存[cpu]、[memory]、[cpu,memory][cpu,memory]updateMode新推荐值以什么方式落到 Pod 上Recreate、InPlaceOrRecreate、InPlace、Initial、OffAuto 已废弃RecreateminAllowed 和 maxAllowed 怎么设什么时候需要它应用用量有规律性起伏你想把 request 锁在一个安全区间里。区间别拍脑袋取应用实际用量的 P10 当 minAllowed、P99 当 maxAllowed留出余量但不留空档。controlledResources 与 updateMode 怎么取舍controlledResources 什么时候需要它CPU 交给 HPA 扩副本数内存这种慢变量留给 VPA各管各的避免两个组件抢着改。updateMode 选择上什么时候需要它集群到了 1.33不想每次调资源都重建 Pod就选 InPlaceOrRecreate 优先原地 resize失败再回退重建。把 hamster 的 VPA 改一版仓库里 vertical-pod-autoscaler/docs/quickstart.md 的 hamster 示例是最常被抄的起步配置但它的阈值区间太宽、又全权管两种资源等于没管。关键变化对照如下改前quickstart 示例改后minAllowed 100m / 50MimaxAllowed 1 核 / 500Mi区间过宽minAllowed 提到 500m / 200MimaxAllowed 收到 1000m / 500MicontrolledResources 两种资源全管只留[memory]CPU 交出去未指定 updateMode行为等价 Recreate显式设为 InPlaceOrRecreateapiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster resourcePolicy: containerPolicies: - containerName: * minAllowed: cpu: 500m # 下限CPU 请求不低于 500m memory: 200Mi # 下限内存请求不低于 200Mi maxAllowed: cpu: 1000m # 上限CPU 请求不超过 1 核 memory: 500Mi # 上限内存请求不超过 500Mi controlledResources: [memory] # CPU 交给 HPAVPA 只管内存 updatePolicy: updateMode: InPlaceOrRecreate # 优先原地更新失败再回退重建一次真实的调优记录一个电商团队的订单服务上了 VPA 之后事情开始变糟CPU 实际用量长期在 300m 到 800m 之间波动推荐值跟着一起抖updater 差不多每 10 分钟就触发一次调整Pod 不断重建重启触发的告警比业务告警还多。他们做的调整很简单把 minAllowed 设为 cpu 500m、maxAllowed 设为 cpu 800m再让 controlledResources 只留[cpu]。这样用量在 500m–800m 区间内波动时推荐值不再越界updater 也就没有差异显著的变更可执行。调优前调优后CPU request 波动区间300m–800m每次波动都追平推荐值稳定在 500m–800m资源调整频率约每 10 分钟一次约每天一次Pod 重建频繁反复触发告警基本无感vertical-pod-autoscaler/deploy/recommender-deployment.yaml 里的推荐器只负责算真正决定动与不动的是你在 resourcePolicy 里划的界——阈值之内波动就不触发调整。别踩这几个坑 ⚠️VPA 配置不生效admission controller 没跑起来症状新建 Pod 还是老 requestVPA 对象里有推荐值但落不下去。排查kubectl get pod -n kube-system | grep vpa-admission-controller应为 Running再看kubectl describe mutatingWebhookConfiguration vpa-webhook-config确认 webhook 已注册。修复重新部署 VPA 组件确认 recommender、updater、admission-controller 三个 Pod 都 Runningwebhook 配置缺失就按官方部署流程重跑一遍。详细步骤见 vertical-pod-autoscaler/docs/faq.md。原地更新失败一直回退到重建集群版本不够症状updateMode 设了 InPlaceOrRecreatePod 照样被驱逐updater 日志里能看到 in-place resize 失败。排查kubectl version看集群是否 1.33 以上再确认 kube-apiserver 启用了 InPlacePodVerticalScaling 特性 gate。修复升级集群并打开该 gate暂时升不了版本就别硬用这个模式先用 Initial 或接受 Recreate。要求与回退行为详见 vertical-pod-autoscaler/docs/features.md。推荐值被 LimitRange 顶住或越界症状推荐值出格跟集群里 LimitRange 的 min/max 对不上。排查kubectl get limitrange -n namespace比对它和 VPA 的 minAllowed/maxAllowed 谁更紧。修复让 LimitRange 的区间做成 VPA 阈值的超集。注意这里两者冲突时 VPA 会优先遵循自己的 resourcePolicy把值设到 LimitRange 之外——所以对齐比放任冲突更省心。阈值配置的本质是在资源利用率与稳定性之间做取舍minAllowed/maxAllowed 压得住波动也压得住利用率controlledResources 和 updateMode 则决定 VPA 动哪部分、以什么代价动。把这三件事想清楚再下发配置Pod 资源基本就能稳住。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
VPA 频繁重启调这 3 个参数让 Pod 资源稳住【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler凌晨两点告警又刷屏了同一批 Pod 每隔十几分钟被驱逐重建一次CPU 请求在 300m 和 800m 之间来回跳。查下来不是流量问题而是 Vertical Pod AutoscalerVPA的阈值配置没设对——推荐值跟着使用率波动不停刷新Pod 资源稳不下来。把下面三个参数调到位这种频繁扩缩容可以明显收敛。VPA 为什么总在动VPA 的链路是三段式的recommender推荐器持续采集 Pod 的 CPU、内存使用历史算出新的推荐值写进 VPA 对象admission controller 在 Pod 创建时把推荐值注入进去updater更新器盯着存量 Pod一旦发现当前 request 和推荐值差异较大就按 updateMode即 VPA 拿到新推荐值后怎么把新配置落到 Pod 上执行变更最常见的手段是驱逐重建。说白了推荐值本身会随负载起伏业务稍微波动推荐值跟着变updater 一算差异显著又是一轮驱逐。换句话说没有阈值约束时任何一点使用率抖动都会传导成一次 Pod 重建——这正是 VPA 频繁扩缩容的根因。三个参数各管一件事参数作用取值范围默认值minAllowed / maxAllowed给推荐值夹一个上下限request 出不了这个区间CPU 从 1m 起、内存从 1Mi 起上限不设不限制controlledResources决定 VPA 管哪些资源可只让它管 CPU 或内存[cpu]、[memory]、[cpu,memory][cpu,memory]updateMode新推荐值以什么方式落到 Pod 上Recreate、InPlaceOrRecreate、InPlace、Initial、OffAuto 已废弃RecreateminAllowed 和 maxAllowed 怎么设什么时候需要它应用用量有规律性起伏你想把 request 锁在一个安全区间里。区间别拍脑袋取应用实际用量的 P10 当 minAllowed、P99 当 maxAllowed留出余量但不留空档。controlledResources 与 updateMode 怎么取舍controlledResources 什么时候需要它CPU 交给 HPA 扩副本数内存这种慢变量留给 VPA各管各的避免两个组件抢着改。updateMode 选择上什么时候需要它集群到了 1.33不想每次调资源都重建 Pod就选 InPlaceOrRecreate 优先原地 resize失败再回退重建。把 hamster 的 VPA 改一版仓库里 vertical-pod-autoscaler/docs/quickstart.md 的 hamster 示例是最常被抄的起步配置但它的阈值区间太宽、又全权管两种资源等于没管。关键变化对照如下改前quickstart 示例改后minAllowed 100m / 50MimaxAllowed 1 核 / 500Mi区间过宽minAllowed 提到 500m / 200MimaxAllowed 收到 1000m / 500MicontrolledResources 两种资源全管只留[memory]CPU 交出去未指定 updateMode行为等价 Recreate显式设为 InPlaceOrRecreateapiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster resourcePolicy: containerPolicies: - containerName: * minAllowed: cpu: 500m # 下限CPU 请求不低于 500m memory: 200Mi # 下限内存请求不低于 200Mi maxAllowed: cpu: 1000m # 上限CPU 请求不超过 1 核 memory: 500Mi # 上限内存请求不超过 500Mi controlledResources: [memory] # CPU 交给 HPAVPA 只管内存 updatePolicy: updateMode: InPlaceOrRecreate # 优先原地更新失败再回退重建一次真实的调优记录一个电商团队的订单服务上了 VPA 之后事情开始变糟CPU 实际用量长期在 300m 到 800m 之间波动推荐值跟着一起抖updater 差不多每 10 分钟就触发一次调整Pod 不断重建重启触发的告警比业务告警还多。他们做的调整很简单把 minAllowed 设为 cpu 500m、maxAllowed 设为 cpu 800m再让 controlledResources 只留[cpu]。这样用量在 500m–800m 区间内波动时推荐值不再越界updater 也就没有差异显著的变更可执行。调优前调优后CPU request 波动区间300m–800m每次波动都追平推荐值稳定在 500m–800m资源调整频率约每 10 分钟一次约每天一次Pod 重建频繁反复触发告警基本无感vertical-pod-autoscaler/deploy/recommender-deployment.yaml 里的推荐器只负责算真正决定动与不动的是你在 resourcePolicy 里划的界——阈值之内波动就不触发调整。别踩这几个坑 ⚠️VPA 配置不生效admission controller 没跑起来症状新建 Pod 还是老 requestVPA 对象里有推荐值但落不下去。排查kubectl get pod -n kube-system | grep vpa-admission-controller应为 Running再看kubectl describe mutatingWebhookConfiguration vpa-webhook-config确认 webhook 已注册。修复重新部署 VPA 组件确认 recommender、updater、admission-controller 三个 Pod 都 Runningwebhook 配置缺失就按官方部署流程重跑一遍。详细步骤见 vertical-pod-autoscaler/docs/faq.md。原地更新失败一直回退到重建集群版本不够症状updateMode 设了 InPlaceOrRecreatePod 照样被驱逐updater 日志里能看到 in-place resize 失败。排查kubectl version看集群是否 1.33 以上再确认 kube-apiserver 启用了 InPlacePodVerticalScaling 特性 gate。修复升级集群并打开该 gate暂时升不了版本就别硬用这个模式先用 Initial 或接受 Recreate。要求与回退行为详见 vertical-pod-autoscaler/docs/features.md。推荐值被 LimitRange 顶住或越界症状推荐值出格跟集群里 LimitRange 的 min/max 对不上。排查kubectl get limitrange -n namespace比对它和 VPA 的 minAllowed/maxAllowed 谁更紧。修复让 LimitRange 的区间做成 VPA 阈值的超集。注意这里两者冲突时 VPA 会优先遵循自己的 resourcePolicy把值设到 LimitRange 之外——所以对齐比放任冲突更省心。阈值配置的本质是在资源利用率与稳定性之间做取舍minAllowed/maxAllowed 压得住波动也压得住利用率controlledResources 和 updateMode 则决定 VPA 动哪部分、以什么代价动。把这三件事想清楚再下发配置Pod 资源基本就能稳住。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
