尧图网页设计 
Kubernetes VPA API 版本迁移完全指南从 v1beta1 / v1beta2 平滑升级到 autoscaling.k8s.io/v1【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler本指南以 Kubernetes Autoscaler 仓库中 vertical-pod-autoscaler/MIGRATE.md 为骨架系统梳理 Vertical Pod AutoscalerVPAAPI 从v1alpha1到v1的完整演进路线重点讲解两次关键迁移v1beta1 → v1beta2label selector 迁移到 targetRef与v1beta2 → v11.3.0 移除旧 API。读完本文你将掌握 VPA 对象的无损升级步骤、新旧 API 配置差异、vpa-up.sh/vpa-down.sh/vpa-apply-upgrade.sh脚本的用法以及如何通过ConfigUnsupported/ConfigDeprecated条件诊断迁移中的问题并可直接照抄文中的完整 Deployment VPA 示例投入生产。一、VPA API 演进脉络为什么需要迁移VPA 的 API 组从诞生至今经历过四个阶段对应着仓库中 pkg/apis/autoscaling.k8s.io 目录下的四个版本包API 版本引入版本状态目标 Pod 的指定方式poc.autoscaling.k8s.io/v1alpha10.2.x 及更早已废弃selectorautoscaling.k8s.io/v1beta10.3.x已废弃label selectorautoscaling.k8s.io/v1beta20.4.0已废弃1.3.0 起不再提供targetRef控制器引用autoscaling.k8s.io/v11.3.0 起当前稳定版本targetRef控制器引用每一次版本更迭都对应一次 API 语义变化理解这条脉络是安全迁移的前提。本文后续章节按两次主要迁移展开0.3.X → 0.4.0v1beta1 → v1beta2与0.4.X–1.2.X → 1.3.Xv1beta2 → v1。二、第一次迁移从 v1beta1 的 selector 到 v1beta2 的 targetRef0.3.X → 0.4.02.1 为什么放弃 label selector0.4.0 引入autoscaling.k8s.io/v1beta2时核心变化是如何表达VPA 要缩放哪些 Pod从 Kubernetes label selector 转向控制器引用controller reference。官方给出的原因有两点selector 极易误配置例如 VPA 对象意外匹配到集群中所有 Pod或多个 VPA 对象相互重叠overlapping导致多个 VPA 争夺同一批 Pod 的资源调整权与 Horizontal Pod AutoscalerHPAAPI 对齐HPA 很早就通过scaleTargetRef指定目标控制器VPA 的targetRef在语义上与之保持一致降低使用者同时维护两类 Autoscaler 的心智负担。2.2 新旧写法对照[已废弃]v1beta1使用 Kubernetes label selector 指定要缩放的 PodapiVersion: autoscaling.k8s.io/v1beta1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa-deprecated spec: selector: # selector is the deprecated way matchLabels: app: hamster[推荐]v1beta2使用目标控制器引用targetRef下例指向名为hamster的 DeploymentapiVersion: autoscaling.k8s.io/v1beta2 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster从源码定义可以印证这一结构差异v1beta1的VerticalPodAutoscalerSpec中字段为Selector *metav1.LabelSelector见 v1beta1/types.go而v1beta2与v1中该字段被替换为TargetRef *autoscalingv1.CrossVersionObjectReference见 v1/types.goCrossVersionObjectReference正是k8s.io/api/autoscaling/v1中 HPA 复用的类型这也解释了与 HPA 对齐的实现基础。2.3 targetRef 的语义细节targetRef的目标对象可以是公认控制器well-known controllerDeployment、ReplicaSet、DaemonSet、StatefulSet 等任何实现了 scale 子资源scale subresource的对象。VPA 通过目标对象的ScaleStatus获取其控制的 Pod 集合。需要注意两个关键点VPA 不要求 scale 子资源的完整实现——它不会用 scale 子资源去修改副本数那是 HPA 的职责唯一读取的是匹配该控制器下 Pod 的 label selector如果 VPA 无法使用指定的 target例如目标不是顶层控制器、或未实现 scale 子资源VPA 会在 status 中上报ConfigUnsupported条件且不产生推荐。上述校验逻辑在 pkg/recommender/input/cluster_feeder.go 中有完整实现它会检查 target 是否为顶层 well-known 或可扩展控制器例如目标存在父控制器时会提示 has a parent controller but it should point to a topmost well-known or scalable controller失败时写入ConfigUnsupported条件见 cluster_feeder.go。条件类型的定义位于 v1/types.go除ConfigUnsupported外还包括RecommendationProvidedrecommender 是否成功计算出推荐值LowConfidence对部分容器推荐置信度较低NoPodsMatchedlabel selector 未匹配到任何 PodConfigDeprecated配置已废弃、即将停止支持FetchingHistoryrecommender 正在加载历史样本。三、0.3 → 0.4 升级操作无损保留现有 VPA 对象官方明确承诺从 0.3 升级到 0.4 不会丢失已有 VPA 对象。推荐步骤如下运行./hack/vpa-apply-upgrade.sh——该脚本会以新版本重启 VPA 安装、注册新 API并保留所有已有 VPA 对象升级后你的v1beta1对象会被标记为deprecated但仍然正常工作将 VPA 定义中的 apiVersion 切换为autoscaling.k8s.io/v1beta2修改 VPA spec从 selector 迁移到 targetRefspec: # Note the empty selector field - this is needed to remove previously defined selector selector: targetRef: apiVersion: apps/v1 kind: Deployment name: deployment_name # This matches the deployment name注意第 4 步中必须保留空的selector:字段它的作用是将此前已定义的 selector 从对象中移除否则旧的 selector 语义仍会残留生效。执行kubectl apply -f应用上述 YAML。3.1 升级脚本的底层行为从仓库源码看vpa-apply-upgrade.sh本身极简只是调用了 hack/vpa-process-yamls.sh$SCRIPT_ROOT/hack/vpa-process-yamls.sh apply $*而vpa-process-yamls.shvpa-process-yamls.sh会依次处理vpa-v1-crd-gen、vpa-rbac、updater-deployment、recommender-deployment、admission-controller-deployment、admission-controller-service等清单并最终交由 hack/vpa-process-yaml.sh 对每个 YAML 做镜像地址与 TAG 替换后执行kubectl apply。替换规则中默认镜像仓库为registry.k8s.io/autoscaling默认 TAG 为1.7.1当前仓库默认版本可通过环境变量REGISTRY与TAG覆盖默认值覆盖时会打印 WARNING支持FEATURE_GATES环境变量为 Deployment 注入--feature-gates参数。这意味着升级不只是换 API 版本而是连同 CRD、RBAC 与三个组件recommender / updater / admission-controller一并重建。3.2 在 Off 模式下先试跑新 APIupdatePolicy.updateMode取值为Off时VPA 的 recommender仍会计算并写入推荐值但不会实际改动任何 Pod 资源相当于 dry run。官方建议可以先创建使用targetRef的新 VPA 对象并置于Off模式确认目标解析、推荐计算都符合预期后再切换为实际生效的模式。v1beta2 支持Off/Initial/Recreate/Auto四种模式见 v1beta2/types.go。四、第二次迁移v1beta2 → v10.4.X–1.2.X → 1.3.X4.1 迁移本身极其简单v1beta2API 已在 1.3.0 中被移除。好消息是v1beta2是v1的严格子集strictly a subset因此迁移动作非常简单——只需把apiVersion改为autoscaling.k8s.io/v1即可spec 结构完全兼容apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster从代码标记可确认两者的继承关系v1beta2的类型上标注了kubebuilder:deprecatedversion:warningautoscaling.k8s.io/v1beta2 API is deprecated、kubebuilder:unservedversion以及k8s:prerelease-lifecycle-gen:replacementautoscaling,v1,VerticalPodAutoscaler见 v1beta2/types.go即 v1beta2 的正式替代版本就是 v1而 v1 类型上标注了kubebuilder:storageversion是当前唯一的存储版本见 v1/types.go。4.2 v1 相比 v1beta2 的扩展能力虽然迁移动作只是改一行 apiVersion但 v1 相比 v1beta2 增加了不少新字段迁移后可立即使用UpdatePolicy扩展新增minReplicas覆盖全局--min-replicas标志、evictionRequirements自定义驱逐条件、evictAfterOOMSecondsOOM 后驱逐等待时间updateMode新增InPlace/InPlaceOrRecreate依赖集群特性门控InPlacePodVerticalScaling并宣告Auto为已废弃值见 v1/types.goResourcePolicy扩展新增controlledValuesRequestsAndLimits/RequestsOnly、oomBumpUpRatio、oomMinBumpUp、memoryAggregationIntervalSeconds、memoryAggregationIntervalCount等精细调优参数见 v1/types.goRecommenders选择器可指定由哪个 recommender 生成推荐StartupBoost启动加速支持Factor按倍数放大与Quantity指定绝对数值两种模式配合durationSeconds控制加速持续时间见 v1/types.go。五、完整示例现代 v1 配置 vs 遗留 v1beta1 配置5.1 [推荐] 现代 v1 配置下面的完整配置创建了一个双副本 Deployment配套一个使用targetRef的 v1 VPA并演示了resourcePolicy的典型用法apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster resourcePolicy: containerPolicies: - containerName: * minAllowed: cpu: 100m memory: 50Mi maxAllowed: cpu: 1 memory: 500Mi controlledResources: [cpu, memory] --- apiVersion: apps/v1 kind: Deployment metadata: name: hamster spec: selector: matchLabels: app: hamster replicas: 2 template: metadata: labels: app: hamster spec: securityContext: runAsNonRoot: true runAsUser: 65534 # nobody containers: - name: hamster image: registry.k8s.io/ubuntu-slim:0.14 resources: requests: cpu: 100m memory: 50Mi command: [/bin/sh] args: - -c - while true; do timeout 0.5s yes /dev/null; sleep 0.5s; done示例中各字段的语义与取值可对照 v1 API 源码进一步确认containerName: *DefaultContainerResourcePolicy作为所有未单独指定策略的容器的默认策略见 v1/types.gominAllowed/maxAllowed推荐值的下限与上限钳制默认无下限、无上限controlledResources参与计算的资源类型默认[cpu, memory]resources.requests中的初始请求值100m CPU / 50Mi 内存是 VPA 启动推荐的基准recommender 会基于实际用量历史给出新目标Deployment 的replicas: 2与matchLabels: app: hamster是 VPA 通过 targetRef 反查 Pod 集合的依据——VPA 从该 Deployment 的 scale 子资源读取 Pod selector再匹配 Pod。5.2 [已废弃] 遗留 v1beta1 配置作为对照这是使用 selector 的旧式写法仅用于理解差异不建议新配置使用apiVersion: autoscaling.k8s.io/v1beta1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa-deprecated spec: selector: matchLabels: app: hamster --- apiVersion: apps/v1 kind: Deployment metadata: name: hamster spec: selector: matchLabels: app: hamster replicas: 2 template: metadata: labels: app: hamster spec: containers: - name: hamster image: registry.k8s.io/ubuntu-slim:0.14 resources: requests: cpu: 100m memory: 50Mi command: [/bin/sh] args: - -c - while true; do timeout 0.5s yes /dev/null; sleep 0.5s; done将两段配置对比即可看出Deployment 部分完全一致唯一实质差异是 VPA 的 Pod 选择机制selector.matchLabelsvstargetRef。六、Alpha → Beta 迁移0.2.x → 0.4.0v1alpha1 时代如果你还在 0.2.x 时代使用poc.autoscaling.k8s.io/v1alpha1apiVersion那么 0.2.x 与 0.4.x 之间的迁移属于alpha → beta 切换包含 apiVersion 的整体变更无法像前两节那样原地升级。官方给出的最安全方式是先拆后建运行vpa-down.sh脚本彻底拆除旧的 VPA 安装——这会删除使用poc.autoscaling.k8s.io/v1alpha1apiVersion 定义的旧 VPA 对象运行vpa-up.sh脚本部署新版本 VPA从零开始创建 VPA 对象apiVersion 使用autoscaling.k8s.io/v1beta2或直接使用 v1并将 selector 写法切换为 targetRef具体规则见本文第二节。官方特别提示强烈建议升级到 0.4.X 版本0.3.X 的安装说明仅保留在 vpa-release-0.3 分支的 README 中作为历史参考。6.1 脚本行为补充说明hack/vpa-down.sh 本质上是vpa-process-yamls.sh delete并会额外检查集群中是否残留旧版vpa-up.sh创建的system:admission-controllerClusterRole / ClusterRoleBinding现已更名为system:vpa-admission-controller若发现会提示人工确认后手动清理vpa-up.sh/vpa-down.sh的部署清单位于 deploy 目录vpa-v1-crd-gen.yaml、vpa-rbac.yaml、recommender-deployment.yaml、updater-deployment.yaml、admission-controller-deployment.yaml、admission-controller-service.yaml也可通过 deploy/kustomization.yaml 以 Kustomize 方式组织。七、迁移后的验证与排障完成 apiVersion 切换并kubectl apply之后建议按以下顺序验证迁移是否成功确认 CRD 已注册新版本kubectl get crd verticalpodautoscalers.autoscaling.k8s.io -o yaml在spec.versions中应看到v1且标记为 storage 版本可对照 deploy/vpa-v1-crd-gen.yaml 中的 CRD 定义。检查 VPA 状态与条件kubectl get vpa kubectl describe vpa hamster-vpa重点关注RecommendationProvided是否变为True——表示 recommender 已针对 targetRef 解析出的 Pod 集合给出推荐是否出现ConfigUnsupported——若出现说明 targetRef 指向的对象不满足顶层 well-known / 可实现 scale 子资源的要求需要修正 target是否出现ConfigDeprecated——表示你的配置仍在使用已废弃的写法例如遗留的 selector 字段或旧 API 版本应尽快清理。用 Off 模式灰度在正式接管生产负载前先将新 VPA 的updatePolicy.updateMode设为Off观察若干周期确认status.recommendation的数值target/lowerBound/upperBound合理后再切换到Recreate或Initial等生效模式。八、迁移路线速查当前版本目标版本迁移动作是否丢失 VPA 对象 0.3.0v1alpha10.4.0v1beta2/v1vpa-down.sh拆除 →vpa-up.sh重建 → 用 targetRef 重新创建对象是旧对象被删除0.3.Xv1beta10.4.0v1beta2./hack/vpa-apply-upgrade.sh→ 改 apiVersion → 改 selector 为 targetRef →kubectl apply否0.4.X–1.2.Xv1beta21.3.Xv1仅将 apiVersion 改为autoscaling.k8s.io/v1否相关脚本均位于仓库 vertical-pod-autoscaler/hack 目录API 类型定义位于 vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.iov1 / v1beta2 / v1beta1 三个版本包的types.go可作为迁移时的字段权威参考。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes VPA API 版本迁移完全指南：从 v1beta1 / v1beta2 平滑升级到 autoscaling.k8s.io/v1
Kubernetes VPA API 版本迁移完全指南从 v1beta1 / v1beta2 平滑升级到 autoscaling.k8s.io/v1【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler本指南以 Kubernetes Autoscaler 仓库中 vertical-pod-autoscaler/MIGRATE.md 为骨架系统梳理 Vertical Pod AutoscalerVPAAPI 从v1alpha1到v1的完整演进路线重点讲解两次关键迁移v1beta1 → v1beta2label selector 迁移到 targetRef与v1beta2 → v11.3.0 移除旧 API。读完本文你将掌握 VPA 对象的无损升级步骤、新旧 API 配置差异、vpa-up.sh/vpa-down.sh/vpa-apply-upgrade.sh脚本的用法以及如何通过ConfigUnsupported/ConfigDeprecated条件诊断迁移中的问题并可直接照抄文中的完整 Deployment VPA 示例投入生产。一、VPA API 演进脉络为什么需要迁移VPA 的 API 组从诞生至今经历过四个阶段对应着仓库中 pkg/apis/autoscaling.k8s.io 目录下的四个版本包API 版本引入版本状态目标 Pod 的指定方式poc.autoscaling.k8s.io/v1alpha10.2.x 及更早已废弃selectorautoscaling.k8s.io/v1beta10.3.x已废弃label selectorautoscaling.k8s.io/v1beta20.4.0已废弃1.3.0 起不再提供targetRef控制器引用autoscaling.k8s.io/v11.3.0 起当前稳定版本targetRef控制器引用每一次版本更迭都对应一次 API 语义变化理解这条脉络是安全迁移的前提。本文后续章节按两次主要迁移展开0.3.X → 0.4.0v1beta1 → v1beta2与0.4.X–1.2.X → 1.3.Xv1beta2 → v1。二、第一次迁移从 v1beta1 的 selector 到 v1beta2 的 targetRef0.3.X → 0.4.02.1 为什么放弃 label selector0.4.0 引入autoscaling.k8s.io/v1beta2时核心变化是如何表达VPA 要缩放哪些 Pod从 Kubernetes label selector 转向控制器引用controller reference。官方给出的原因有两点selector 极易误配置例如 VPA 对象意外匹配到集群中所有 Pod或多个 VPA 对象相互重叠overlapping导致多个 VPA 争夺同一批 Pod 的资源调整权与 Horizontal Pod AutoscalerHPAAPI 对齐HPA 很早就通过scaleTargetRef指定目标控制器VPA 的targetRef在语义上与之保持一致降低使用者同时维护两类 Autoscaler 的心智负担。2.2 新旧写法对照[已废弃]v1beta1使用 Kubernetes label selector 指定要缩放的 PodapiVersion: autoscaling.k8s.io/v1beta1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa-deprecated spec: selector: # selector is the deprecated way matchLabels: app: hamster[推荐]v1beta2使用目标控制器引用targetRef下例指向名为hamster的 DeploymentapiVersion: autoscaling.k8s.io/v1beta2 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster从源码定义可以印证这一结构差异v1beta1的VerticalPodAutoscalerSpec中字段为Selector *metav1.LabelSelector见 v1beta1/types.go而v1beta2与v1中该字段被替换为TargetRef *autoscalingv1.CrossVersionObjectReference见 v1/types.goCrossVersionObjectReference正是k8s.io/api/autoscaling/v1中 HPA 复用的类型这也解释了与 HPA 对齐的实现基础。2.3 targetRef 的语义细节targetRef的目标对象可以是公认控制器well-known controllerDeployment、ReplicaSet、DaemonSet、StatefulSet 等任何实现了 scale 子资源scale subresource的对象。VPA 通过目标对象的ScaleStatus获取其控制的 Pod 集合。需要注意两个关键点VPA 不要求 scale 子资源的完整实现——它不会用 scale 子资源去修改副本数那是 HPA 的职责唯一读取的是匹配该控制器下 Pod 的 label selector如果 VPA 无法使用指定的 target例如目标不是顶层控制器、或未实现 scale 子资源VPA 会在 status 中上报ConfigUnsupported条件且不产生推荐。上述校验逻辑在 pkg/recommender/input/cluster_feeder.go 中有完整实现它会检查 target 是否为顶层 well-known 或可扩展控制器例如目标存在父控制器时会提示 has a parent controller but it should point to a topmost well-known or scalable controller失败时写入ConfigUnsupported条件见 cluster_feeder.go。条件类型的定义位于 v1/types.go除ConfigUnsupported外还包括RecommendationProvidedrecommender 是否成功计算出推荐值LowConfidence对部分容器推荐置信度较低NoPodsMatchedlabel selector 未匹配到任何 PodConfigDeprecated配置已废弃、即将停止支持FetchingHistoryrecommender 正在加载历史样本。三、0.3 → 0.4 升级操作无损保留现有 VPA 对象官方明确承诺从 0.3 升级到 0.4 不会丢失已有 VPA 对象。推荐步骤如下运行./hack/vpa-apply-upgrade.sh——该脚本会以新版本重启 VPA 安装、注册新 API并保留所有已有 VPA 对象升级后你的v1beta1对象会被标记为deprecated但仍然正常工作将 VPA 定义中的 apiVersion 切换为autoscaling.k8s.io/v1beta2修改 VPA spec从 selector 迁移到 targetRefspec: # Note the empty selector field - this is needed to remove previously defined selector selector: targetRef: apiVersion: apps/v1 kind: Deployment name: deployment_name # This matches the deployment name注意第 4 步中必须保留空的selector:字段它的作用是将此前已定义的 selector 从对象中移除否则旧的 selector 语义仍会残留生效。执行kubectl apply -f应用上述 YAML。3.1 升级脚本的底层行为从仓库源码看vpa-apply-upgrade.sh本身极简只是调用了 hack/vpa-process-yamls.sh$SCRIPT_ROOT/hack/vpa-process-yamls.sh apply $*而vpa-process-yamls.shvpa-process-yamls.sh会依次处理vpa-v1-crd-gen、vpa-rbac、updater-deployment、recommender-deployment、admission-controller-deployment、admission-controller-service等清单并最终交由 hack/vpa-process-yaml.sh 对每个 YAML 做镜像地址与 TAG 替换后执行kubectl apply。替换规则中默认镜像仓库为registry.k8s.io/autoscaling默认 TAG 为1.7.1当前仓库默认版本可通过环境变量REGISTRY与TAG覆盖默认值覆盖时会打印 WARNING支持FEATURE_GATES环境变量为 Deployment 注入--feature-gates参数。这意味着升级不只是换 API 版本而是连同 CRD、RBAC 与三个组件recommender / updater / admission-controller一并重建。3.2 在 Off 模式下先试跑新 APIupdatePolicy.updateMode取值为Off时VPA 的 recommender仍会计算并写入推荐值但不会实际改动任何 Pod 资源相当于 dry run。官方建议可以先创建使用targetRef的新 VPA 对象并置于Off模式确认目标解析、推荐计算都符合预期后再切换为实际生效的模式。v1beta2 支持Off/Initial/Recreate/Auto四种模式见 v1beta2/types.go。四、第二次迁移v1beta2 → v10.4.X–1.2.X → 1.3.X4.1 迁移本身极其简单v1beta2API 已在 1.3.0 中被移除。好消息是v1beta2是v1的严格子集strictly a subset因此迁移动作非常简单——只需把apiVersion改为autoscaling.k8s.io/v1即可spec 结构完全兼容apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster从代码标记可确认两者的继承关系v1beta2的类型上标注了kubebuilder:deprecatedversion:warningautoscaling.k8s.io/v1beta2 API is deprecated、kubebuilder:unservedversion以及k8s:prerelease-lifecycle-gen:replacementautoscaling,v1,VerticalPodAutoscaler见 v1beta2/types.go即 v1beta2 的正式替代版本就是 v1而 v1 类型上标注了kubebuilder:storageversion是当前唯一的存储版本见 v1/types.go。4.2 v1 相比 v1beta2 的扩展能力虽然迁移动作只是改一行 apiVersion但 v1 相比 v1beta2 增加了不少新字段迁移后可立即使用UpdatePolicy扩展新增minReplicas覆盖全局--min-replicas标志、evictionRequirements自定义驱逐条件、evictAfterOOMSecondsOOM 后驱逐等待时间updateMode新增InPlace/InPlaceOrRecreate依赖集群特性门控InPlacePodVerticalScaling并宣告Auto为已废弃值见 v1/types.goResourcePolicy扩展新增controlledValuesRequestsAndLimits/RequestsOnly、oomBumpUpRatio、oomMinBumpUp、memoryAggregationIntervalSeconds、memoryAggregationIntervalCount等精细调优参数见 v1/types.goRecommenders选择器可指定由哪个 recommender 生成推荐StartupBoost启动加速支持Factor按倍数放大与Quantity指定绝对数值两种模式配合durationSeconds控制加速持续时间见 v1/types.go。五、完整示例现代 v1 配置 vs 遗留 v1beta1 配置5.1 [推荐] 现代 v1 配置下面的完整配置创建了一个双副本 Deployment配套一个使用targetRef的 v1 VPA并演示了resourcePolicy的典型用法apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: hamster resourcePolicy: containerPolicies: - containerName: * minAllowed: cpu: 100m memory: 50Mi maxAllowed: cpu: 1 memory: 500Mi controlledResources: [cpu, memory] --- apiVersion: apps/v1 kind: Deployment metadata: name: hamster spec: selector: matchLabels: app: hamster replicas: 2 template: metadata: labels: app: hamster spec: securityContext: runAsNonRoot: true runAsUser: 65534 # nobody containers: - name: hamster image: registry.k8s.io/ubuntu-slim:0.14 resources: requests: cpu: 100m memory: 50Mi command: [/bin/sh] args: - -c - while true; do timeout 0.5s yes /dev/null; sleep 0.5s; done示例中各字段的语义与取值可对照 v1 API 源码进一步确认containerName: *DefaultContainerResourcePolicy作为所有未单独指定策略的容器的默认策略见 v1/types.gominAllowed/maxAllowed推荐值的下限与上限钳制默认无下限、无上限controlledResources参与计算的资源类型默认[cpu, memory]resources.requests中的初始请求值100m CPU / 50Mi 内存是 VPA 启动推荐的基准recommender 会基于实际用量历史给出新目标Deployment 的replicas: 2与matchLabels: app: hamster是 VPA 通过 targetRef 反查 Pod 集合的依据——VPA 从该 Deployment 的 scale 子资源读取 Pod selector再匹配 Pod。5.2 [已废弃] 遗留 v1beta1 配置作为对照这是使用 selector 的旧式写法仅用于理解差异不建议新配置使用apiVersion: autoscaling.k8s.io/v1beta1 kind: VerticalPodAutoscaler metadata: name: hamster-vpa-deprecated spec: selector: matchLabels: app: hamster --- apiVersion: apps/v1 kind: Deployment metadata: name: hamster spec: selector: matchLabels: app: hamster replicas: 2 template: metadata: labels: app: hamster spec: containers: - name: hamster image: registry.k8s.io/ubuntu-slim:0.14 resources: requests: cpu: 100m memory: 50Mi command: [/bin/sh] args: - -c - while true; do timeout 0.5s yes /dev/null; sleep 0.5s; done将两段配置对比即可看出Deployment 部分完全一致唯一实质差异是 VPA 的 Pod 选择机制selector.matchLabelsvstargetRef。六、Alpha → Beta 迁移0.2.x → 0.4.0v1alpha1 时代如果你还在 0.2.x 时代使用poc.autoscaling.k8s.io/v1alpha1apiVersion那么 0.2.x 与 0.4.x 之间的迁移属于alpha → beta 切换包含 apiVersion 的整体变更无法像前两节那样原地升级。官方给出的最安全方式是先拆后建运行vpa-down.sh脚本彻底拆除旧的 VPA 安装——这会删除使用poc.autoscaling.k8s.io/v1alpha1apiVersion 定义的旧 VPA 对象运行vpa-up.sh脚本部署新版本 VPA从零开始创建 VPA 对象apiVersion 使用autoscaling.k8s.io/v1beta2或直接使用 v1并将 selector 写法切换为 targetRef具体规则见本文第二节。官方特别提示强烈建议升级到 0.4.X 版本0.3.X 的安装说明仅保留在 vpa-release-0.3 分支的 README 中作为历史参考。6.1 脚本行为补充说明hack/vpa-down.sh 本质上是vpa-process-yamls.sh delete并会额外检查集群中是否残留旧版vpa-up.sh创建的system:admission-controllerClusterRole / ClusterRoleBinding现已更名为system:vpa-admission-controller若发现会提示人工确认后手动清理vpa-up.sh/vpa-down.sh的部署清单位于 deploy 目录vpa-v1-crd-gen.yaml、vpa-rbac.yaml、recommender-deployment.yaml、updater-deployment.yaml、admission-controller-deployment.yaml、admission-controller-service.yaml也可通过 deploy/kustomization.yaml 以 Kustomize 方式组织。七、迁移后的验证与排障完成 apiVersion 切换并kubectl apply之后建议按以下顺序验证迁移是否成功确认 CRD 已注册新版本kubectl get crd verticalpodautoscalers.autoscaling.k8s.io -o yaml在spec.versions中应看到v1且标记为 storage 版本可对照 deploy/vpa-v1-crd-gen.yaml 中的 CRD 定义。检查 VPA 状态与条件kubectl get vpa kubectl describe vpa hamster-vpa重点关注RecommendationProvided是否变为True——表示 recommender 已针对 targetRef 解析出的 Pod 集合给出推荐是否出现ConfigUnsupported——若出现说明 targetRef 指向的对象不满足顶层 well-known / 可实现 scale 子资源的要求需要修正 target是否出现ConfigDeprecated——表示你的配置仍在使用已废弃的写法例如遗留的 selector 字段或旧 API 版本应尽快清理。用 Off 模式灰度在正式接管生产负载前先将新 VPA 的updatePolicy.updateMode设为Off观察若干周期确认status.recommendation的数值target/lowerBound/upperBound合理后再切换到Recreate或Initial等生效模式。八、迁移路线速查当前版本目标版本迁移动作是否丢失 VPA 对象 0.3.0v1alpha10.4.0v1beta2/v1vpa-down.sh拆除 →vpa-up.sh重建 → 用 targetRef 重新创建对象是旧对象被删除0.3.Xv1beta10.4.0v1beta2./hack/vpa-apply-upgrade.sh→ 改 apiVersion → 改 selector 为 targetRef →kubectl apply否0.4.X–1.2.Xv1beta21.3.Xv1仅将 apiVersion 改为autoscaling.k8s.io/v1否相关脚本均位于仓库 vertical-pod-autoscaler/hack 目录API 类型定义位于 vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.iov1 / v1beta2 / v1beta1 三个版本包的types.go可作为迁移时的字段权威参考。【免费下载链接】autoscalerAutoscaling components for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/au/autoscaler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考