为什么需要 VPAKubernetes 的资源管理长期面临一个尴尬的问题设多了浪费资源集群利用率低下设少了OOM Killed、CPU Throttling、服务不可用不设BestEffort QoS随时可能被驱逐HPAHorizontal Pod Autoscaler解决了水平扩展的问题——流量大了加 Pod流量小了减 Pod。但很多工作负载并不适合水平扩展不适合 HPA 的场景原因单实例有状态服务无法多副本内存密集型批处理增加副本不能减少单 Pod 内存需求启动时间极长的服务水平扩展响应太慢许可限制License只允许固定实例数GPU 工作负载GPU 资源昂贵需要精确分配VPAVertical Pod Autoscaler就是为这些场景设计的——它自动调整 Pod 的 CPU 和 Memory 的 request/limit而不是增减 Pod 数量。VPA vs HPA 对比维度VPAHPA扩展方向垂直调资源水平调副本数调整对象CPU/Memory request limitPod replicas是否需要重启 Pod取决于 updateMode不需要依赖组件metrics-server VPA Controllermetrics-server或自定义指标适用工作负载单实例、有状态、GPU无状态、可水平扩展响应速度较慢需重建 Pod快创建新 Pod与 Cluster Autoscaler 配合互补配合紧密GA 状态部分 GAv1.0GAVPA vs HPA 工作流对比: HPA 流程: 指标上升 → HPA Controller 检测到 → 增加 replicas → Scheduler 调度新 Pod 指标下降 → HPA Controller 检测到 → 减少 replicas → 删除多余 Pod VPA 流程: 指标持续偏高 → VPA Recommender 计算推荐值 → Admission Controller 拦截 Pod 创建 → 注入新资源值 → Pod 以新资源配置启动 (Auto 模式) 指标持续偏高 → VPA Updater 检测到偏差 → 驱逐旧 Pod → Deployment 重建 Pod → Admission Controller 注入新值 → 新 Pod 以推荐资源配置启动VPA 架构原理VPA 由三个核心组件构成VPA 架构: ┌────────────────────────────────────────────────────────────┐ │ VPA 系统架构 │ ├────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ Recommender │ │ metrics-server │ │ │ │ (推荐器) │◄───│ (指标采集) │ │ │ │ │ └──────────────────┘ │ │ │ - 分析历史指标 │ │ │ │ - 计算推荐值 │ │ │ │ - 定期更新 │ │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Admission │ ┌──────────────────┐ │ │ │ Controller │◄───│ API Server │ │ │ │ (准入控制器) │ │ (Mutating │ │ │ │ │ │ Webhook) │ │ │ │ - 拦截 Pod 创建 │ └──────────────────┘ │ │ │ - 注入资源值 │ │ │ └──────────────────┘ │ │ │ │ ┌──────────────────┐ │ │ │ Updater │ │ │ │ (更新器) │ │ │ │ │ │ │ │ - 检测偏差 │ │ │ │ - 驱逐旧 Pod │ │ │ │ - 触发重建 │ │ │ └──────────────────┘ │ │ │ └────────────────────────────────────────────────────────────┘Recommender推荐器Recommender 持续从 metrics-server 获取 Pod 的资源使用数据基于历史数据计算出推荐的 CPU 和 Memory 值。计算逻辑CPU 推荐值取历史 CPU 使用率的某个百分位数默认 95th percentileMemory 推荐值取历史 Memory 使用峰值 安全余量默认 15%安全范围提供 Lower Bound 和 Upper Bound表示推荐值的置信区间# Recommender 输出的推荐值示例status:recommendation:containerRecommendations:-containerName:apptarget:cpu:500m# 推荐目标值memory:512MilowerBound:cpu:250m# 最低推荐值memory:256MiupperBound:cpu:1000m# 最高推荐值memory:1GiuncappedTarget:cpu:500m# 不受 min/max 限制的原始推荐值memory:512MiAdmission Controller准入控制器当 Pod 被创建时VPA 的 Mutating Webhook 拦截请求将 VPA 推荐的资源值注入到 Pod 的容器 spec 中。请求流: kubectl apply → API Server → Mutating Webhook (VPA) │ ▼ 注入 resources: requests: cpu: 500m memory: 512Mi │ ▼ Scheduler → 新 Pod带推荐资源值Updater更新器Updater 只在updateMode: Auto时活跃。它检查正在运行的 Pod 的资源配置是否偏离了 VPA 的推荐值。如果偏离超过阈值Updater 会驱逐evict旧 Pod让 Deployment/StatefulSet 重建 Pod新 Pod 在创建时被 Admission Controller 注入推荐值。关键约束Updater 不会同时驱逐所有 Pod它尊重 PodDisruptionBudgetPDB确保服务可用性。安装部署前提条件Kubernetes 1.25推荐 1.27metrics-server 已安装并正常工作集群有 Mutating Webhook 支持安装 metrics-server# 检查 metrics-server 是否已安装kubectltopnodes kubectltoppods# 如果未安装使用官方 Helm charthelm repoaddmetrics-server https://kubernetes-sigs.github.io/metrics-server/ helminstallmetrics-server metrics-server/metrics-server\--namespacekube-system\--setargs{--kubelet-insecure-tls,--kubelet-preferred-address-typesInternalIP}安装 VPA# 克隆 VPA 仓库gitclone https://github.com/kubernetes/autoscaler.gitcdautoscaler/vertical-pod-autoscaler# 使用安装脚本会创建 CRD、ServiceAccount、Deployment 等./hack/vpa-up.sh# 或者使用 Helm推荐helm repoaddcowboysysop https://cowboysysop.github.io/charts/ helminstallvpa cowboysysop/vertical-pod-autoscaler\--namespacekube-system\--setadmissionController.enabledtrue验证安装# 检查 VPA 组件状态kubectl get pods-nkube-system|grepvpa# 期望输出:# vpa-recommender-xxx 1/1 Running 0 5m# vpa-updater-xxx 1/1 Running 0 5m# vpa-admission-controller-xxx 1/1 Running 0 5m# 检查 CRDkubectl get crd|grepverticalpodautoscaler# 期望输出:# verticalpodautoscalercheckpoints.autoscaling.k8s.io# verticalpodautoscalers.autoscaling.k8s.ioYAML 配置详解基本 VPA 配置apiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:my-app-vpanamespace:productionspec:targetRef:apiVersion:apps/v1kind:Deploymentname:my-appupdatePolicy:updateMode:Auto# 核心参数见下文详解resourcePolicy:containerPolicies:-containerName:appminAllowed:cpu:100mmemory:128MimaxAllowed:cpu:4memory:8GicontrolledResources:-cpu-memorycontrolledValues:RequestsAndLimits# 或 RequestsOnly多容器 Pod 配置apiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:multi-container-vpanamespace:productionspec:targetRef:apiVersion:apps/v1kind:Deploymentname:my-appupdatePolicy:updateMode:AutoresourcePolicy:containerPolicies:# 主应用容器 - 完全自动调整-containerName:appminAllowed:cpu:200mmemory:256MimaxAllowed:cpu:2memory:4Gi# Sidecar 容器 - 只调整 CPU-containerName:istio-proxycontrolledResources:-cpuminAllowed:cpu:50mmaxAllowed:cpu:500m# 日志收集器 - 不调整跳过-containerName:fluent-bitmode:OffupdateMode 三种模式VPA 的核心行为由updatePolicy.updateMode控制有三种模式1. Off 模式仅推荐不执行updatePolicy:updateMode:OffVPA 只计算推荐值不修改 Pod 资源配置推荐值写入 VPA 的 status 字段可供人工参考适用场景初期观察阶段、生产环境谨慎上线# 查看推荐值kubectl get vpa my-app-vpa-oyaml|grep-A20recommendation2. Initial 模式仅在创建时注入updatePolicy:updateMode:Initial只在 Pod 首次创建时注入推荐资源值已运行的 Pod 不会被驱逐或修改适用场景Job、一次性任务、不允许中断的服务3. Auto 模式全自动updatePolicy:updateMode:Auto新 Pod 创建时注入推荐值已运行的 Pod 如果偏差超过阈值会被驱逐重建适用场景Deployment 管理的无状态/有状态服务Auto 模式驱逐条件: 偏差计算: |当前值 - 推荐值| / 当前值 默认阈值: - CPU: 偏差 10% 且绝对差 100m - Memory: 偏差 15% 且绝对差 100Mi 满足任一资源超出阈值 → 触发驱逐模式对比模式创建时注入运行时更新驱逐 Pod适用场景Off❌❌❌观察、评估Initial✅❌❌Job、不可中断服务Auto✅✅✅Deployment 标准服务生产环境配置建议渐进式上线策略推荐的 VPA 上线步骤: Week 1-2: Off 模式 → 收集推荐数据对比人工设定值 Week 3: Initial 模式 → 新 Pod 使用推荐值观察效果 Week 4: Auto 模式 → 全自动调整持续监控资源边界设置生产环境中必须设置 minAllowed 和 maxAllowed防止 VPA 推荐出极端值resourcePolicy:containerPolicies:-containerName:appminAllowed:cpu:100m# 不低于 0.1 核memory:256Mi# 不低于 256MBmaxAllowed:cpu:4# 不超过 4 核memory:8Gi# 不超过 8GB设置原则minAllowed服务能正常运行的最低配置做过压测验证maxAllowed不超过单节点资源的 50%防止 VPA 把整个节点的 Pod 都调上去controlledValues 的选择# 同时调整 requests 和 limits保持比例controlledValues:RequestsAndLimits# 只调整 requestslimits 保持不变controlledValues:RequestsOnly选择行为适用场景RequestsAndLimits同时调整 R 和 L保持 R:L 比例大多数场景RequestsOnly只调 RL 固定需要固定 limit 的场景如 Guaranteed QoS与 PDB 配合# PodDisruptionBudget 确保 VPA 驱逐时不影响可用性apiVersion:policy/v1kind:PodDisruptionBudgetmetadata:name:my-app-pdbspec:minAvailable:2# 或 maxUnavailable: 1selector:matchLabels:app:my-appVPA Updater 在驱逐 Pod 时会尊重 PDB。如果驱逐会导致违反 PDBUpdater 会等待。VPA 与 HPA 的冲突处理VPA 和 HPA 不能同时作用于同一个指标。这是 K8s 社区明确指出的约束。为什么会冲突冲突场景: VPA: 检测到 CPU 使用率高 → 增加 Pod 的 CPU request HPA: 检测到 CPU 使用率高 → 增加 Pod 副本数 两者同时响应 → 资源浪费既增加了单 Pod 资源又增加了副本数解决方案方案 1按指标分离VPA 管理 MemoryHPA 管理 CPU# VPA 只管 MemoryapiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:my-app-vpaspec:targetRef:apiVersion:apps/v1kind:Deploymentname:my-appupdatePolicy:updateMode:AutoresourcePolicy:containerPolicies:-containerName:appcontrolledResources:-memory# 只控制 Memory---# HPA 只管 CPUapiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:my-app-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:my-appmetrics:-type:Resourceresource:name:cpu# 只关注 CPUtarget:type:UtilizationaverageUtilization:70方案 2VPA 使用 Off 模式为 HPA 提供参考VPA 在 Off 模式下提供 Memory 推荐值人工据此设定 Pod 的 Memory request然后 HPA 基于 CPU 做水平扩展。冲突检测# 检查是否有冲突配置kubectl get vpa, hpa-nproduction-ojson|\jq.items[] | select(.spec.targetRef.name my-app) | {kind: .kind, metrics: .spec.metrics, resources: .spec.resourcePolicy}生产注意事项1. Pod 驱逐导致短暂不可用VPA Auto 模式通过驱逐 Pod 来实现资源调整。即使是 Rolling Update也会有短暂的容量下降。VPA 驱逐时序: T0: VPA Updater 决定驱逐 Pod-A资源配置过时 T1: Pod-A 被驱逐graceful termination T2: Deployment 检测到 Pod-A 缺失创建 Pod-B T3: Admission Controller 给 Pod-B 注入新的资源值 T4: Pod-B 调度、启动、就绪 影响: T1 到 T4 之间服务容量减少 1 个 Pod 缓解: 确保 Deployment replicas 2配合 PDB2. 冷启动问题新创建的 Pod 没有历史数据VPA Recommender 需要积累足够的数据才能给出准确推荐。# 配置 Recommender 参数--min-replicas2# 至少 2 个副本才启用 VPA--history-length8d# 保留 8 天历史数据--history-resolution1h# 历史数据分辨率 1 小时3. Java 应用的 Memory 特殊处理JVM 的内存模型堆 非堆 元空间使得 Memory 推荐值需要特别关注# Java 应用 VPA 配置建议resourcePolicy:containerPolicies:-containerName:java-appminAllowed:memory:512Mi# 不能低于 JVM 基础需求maxAllowed:memory:4Gi# JVM 参数应使用容器感知配置:# -XX:UseContainerSupport# -XX:MaxRAMPercentage75.0# -XX:InitialRAMPercentage50.04. 监控和告警# Prometheus 告警规则apiVersion:monitoring.coreos.com/v1kind:PrometheusRulemetadata:name:vpa-alertsspec:groups:-name:vparules:-alert:VPARecommendationExtremeexpr:|vpa_recommendation{recommendation_typetarget} / vpa_recommendation{recommendation_typelowerBound} 5for:1hlabels:severity:warningannotations:summary:VPA 推荐值偏离下界过大-alert:VPAPodEvictionStormexpr:|increase(vpa_eviction_count[10m]) 5for:5mlabels:severity:criticalannotations:summary:VPA 短时间内驱逐过多 Pod5. 与 Cluster Autoscaler 配合VPA 和 Cluster AutoscalerCA是互补关系协作流程: VPA 调大 Pod 资源 → Pod 需要更多节点资源 → CA 发现资源不足 → 扩容节点 VPA 调小 Pod 资源 → 节点资源利用率下降 → CA 发现节点空闲 → 缩容节点确保 CA 的--scale-down-delay-after-add参数足够长建议 30 分钟避免 VPA 刚调大资源CA 就开始缩节点。实际效果数据以某生产环境的 Java 微服务为例上线 VPA 前后的对比指标上线前手动设定上线后VPA Auto变化平均 CPU Request 利用率35%68%94%平均 Memory Request 利用率42%75%78%OOM Killed 次数/月121-92%CPU Throttling 时间占比8%2%-75%集群整体资源浪费率55%22%-60%Pod 驱逐次数/周03-5-常见问题排查VPA 没有给出推荐值# 检查 Recommender 日志kubectl logs-nkube-system-lappvpa-recommender--tail50# 检查 metrics-server 是否正常kubectltoppods-nproduction# 检查 VPA 是否能找到目标资源kubectl describe vpa my-app-vpa-nproduction# 关注 Conditions 中的 FetchingHistory 和 LowConfidenceVPA 推荐值过高或过低# 查看详细推荐值和历史kubectl get vpa my-app-vpa-ojsonpath{.status.recommendation}|jq.# 检查是否有异常数据点影响推荐kubectl get vpa my-app-vpa-ojsonpath{.status.conditions}|jq.Pod 被频繁驱逐# 查看驱逐事件kubectl get events --field-selectorreasonEvicted-nproduction# 检查 VPA Updater 日志kubectl logs-nkube-system-lappvpa-updater--tail50# 如果频繁驱逐考虑:# 1. 切换为 Initial 模式# 2. 增大 maxAllowed 范围# 3. 增加 controlledValues 为 RequestsOnlyVPA 的价值不在于完全取代人工调优而是提供一个持续优化的基线。在资源利用率和稳定性之间找到平衡点才是 VPA 落地的核心目标。