VPA 阈值配置指南3 个参数止住频繁扩缩容让 Pod 资源稳定运行【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler凌晨的告警群又被 Pod 重启刷屏负载明明没变VPAVertical Pod Autoscaler却每隔十几分钟改一次资源请求触发一轮滚动重建。根子往往在 VPA 阈值配置缺少边界。下面用 3 个参数把推荐值锁进稳定区间。Pod 反复重启、告警刷屏还原 VPA 频繁扩缩容的现场先对照一下你的线上是不是这个剧本监控面板上 CPU 使用率在 300m~800m 之间来回摆VPA 大约每 10 分钟产出一版新推荐updateMode是默认的Recreate所以每次推荐变化都伴随着 Pod 被删掉重建告警系统里Pod restart事件一条接一条业务侧表现为接口偶发毛刺、连接被重置。这套行为的机制其实很直白Recommender推荐器持续采样 Pod 用量并刷新推荐值Updater更新器发现推荐值和实际请求有差异就执行调整。没有上下限约束时任何一点小波动都会被当成需要修正于是扩缩容追着噪音跑。三步修复 VPA 频繁扩缩容设 minAllowed/maxAllowed、收窄 controlledResources、选对 updateMode修复动作按这个顺序来改的是同一个 VPA 对象里的resourcePolicy和updatePolicy给推荐值加上下限在containerPolicies里写minAllowed和maxAllowedVPA 的推荐值只会落在这个区间内小幅波动不再产生新推荐。收窄受控资源用controlledResources指定 VPA 只管理内存或只管理 CPU把另一类资源交给 HPA 或人工减少两个组件互相改值的机会。选对更新方式集群支持原地调整时把updateMode设为InPlaceOrRecreate能原地改就不重建不支持就保持Recreate。注意旧值Auto已弃用建议写显式模式。最短可用的配置长这样以业务部署order-api为例apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: order-api-vpa spec: targetRef: { apiVersion: apps/v1, kind: Deployment, name: order-api } resourcePolicy: containerPolicies: - containerName: * minAllowed: { cpu: 500m, memory: 200Mi } # 推荐值下限锁住波动下沿 maxAllowed: { cpu: 800m, memory: 512Mi } # 推荐值上限锁住波动上沿 controlledResources: [memory] # 只管理内存CPU 交给 HPA updatePolicy: updateMode: InPlaceOrRecreate # 优先原地更新失败再重建minAllowed maxAllowed 怎么取值controlledResources 与 updateMode 配置逐项拆解minAllowed / maxAllowed管的是推荐值的边界Recommender 算出的值先被裁剪到这个区间再交给 Updater。两者默认都不设限这正是频繁调整的温床。取值不用拍脑袋拉最近 7~14 天的用量曲线下限取基线附近比如 P50 略高一点别低于真实基线上限取 P95 再留 20%~30% 余量。区间宁可比真实波动稍宽别卡得太死——推荐值长期顶在上限往往说明业务在涨而不是配置对了。controlledResources决定 VPA 动哪些资源默认[cpu, memory]全管。它最常见的用途是配合 HPA 分工HPA 按 CPU 调副本数水平方向VPA 只调单 Pod 内存垂直扩缩容方向两边各管一摊就不打架。如果某个容器比如 sidecar不想被碰可以在对应containerPolicies条目里把mode设为Off。updateMode决定推荐值以什么方式落到 Pod 上可选值有Off只算不动适合先观察、Initial只在新 Pod 创建时应用、Recreate重建 Pod、InPlaceOrRecreate先试原地改不行再重建。原地更新依赖 Kubernetes 1.33 并开启InPlacePodVerticalScaling特性门VPA 1.5.0 起默认开启1.7.0 移除了这个门版本不够时老老实实用Recreate。参数控制什么取值建议minAllowed / maxAllowed推荐值区间默认无限制下限贴基线约 P50上限 P95 加余量controlledResourcesVPA 管理哪些资源默认 cpumemory与 HPA 共存时只留[memory]updateMode推荐值如何落到 PodAuto已弃用集群 ≥1.33 选InPlaceOrRecreate否则Recreate验证 VPA 推荐值是否停摆看推荐值、数重启、按负载微调配置生效不生效两个信号最直接推荐值停不停、重启还多不多。kubectl describe vpa order-api-vpa # 看当前推荐值隔几小时对比是否还在变 kubectl get pods -l apporder-api -w # 盯 24 小时数 Pod 重启次数健康的状态是describe里的推荐值在一天内基本不动Pod 事件里不再周期性出现 VPA 触发的重建。如果开了原地更新还能在监控里看vpa_updater_in_place_updated_pods_total这类指标确认调整大多走原地路径而不是重建。后续按业务负载微调推荐值长期顶在maxAllowed说明区间偏窄或业务在涨放宽上限长期贴在minAllowed说明下限虚高适当下调省成本有明显日间波峰波谷的工作负载可以把区间放宽一档接受推荐值贴边运行避免追峰。仓库里 vertical-pod-autoscaler/docs/quickstart.md 的 hamster 示例就是一个自带minAllowed/maxAllowed的最小起点照着改就行。⚠️ 避坑指南VPA 阈值不生效、原地更新失败、与 HPA 互相打架现象改了 VPA 对象Pod 资源纹丝不动。原因多半是 vpa-updater 或 admission-controller 组件没跑起来或者updateMode被设成了Off只计算不执行。处理用kubectl get pods -n kube-system | grep vpa确认三个组件都 Running再看describe vpa的 Events 有无报错。现象InPlaceOrRecreate设了却每次都重建 Pod。原因通常是集群低于 1.33、InPlacePodVerticalScaling特性门未开或 VPA 版本太旧1.4.0 需要显式开启该门。处理升级集群或 VPA≥1.5.0 默认开启短期接受回退到Recreate的行为。现象CPU 请求被 VPA 和 HPA 来回改副本数跟着抖。原因是controlledResources默认包含 cpuHPA 也按 CPU 扩缩容两边目标不同却改同一个量。处理把controlledResources收窄成[memory]让 CPU 归 HPA 管具体做法可以参考 vertical-pod-autoscaler/docs/faq.md 里如何只让 VPA 管理特定资源一节。VPA 阈值配置小结稳定运行靠的是贴着负载调minAllowed/maxAllowed定区间、controlledResources定分工、updateMode定落地方式三件事做完VPA 频繁扩缩容带来的 Pod 反复重启基本能稳定住剩下的就是把区间往真实负载上磨。更多字段细节可查 vertical-pod-autoscaler/docs/features.md。你现在集群的 VPA 是Recreate还是InPlaceOrRecreate版本够 1.33 吗欢迎评论区聊聊你的配置和踩过的坑。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考