vpa 在 kubernetes 中需先部署并验证 metrics server，再按序安装 vpa-recommender、vpa-updater 和 vpa-admission-controller 三个组件，且必须为 go 应用显式创建 vpa 对象，禁用 hpa，推荐值约 10 分钟后生成，首次生效必重启 pod。
Go 应用在 Kubernetes 中部署本身不特殊，但配置 VPA 垂直扩缩容时容易因组件缺失、权限不足或策略误配导致 VPARecommendation 不生成、Pod 不被更新，甚至引发反复重启。VPA 不是“开箱即用”的控制器，它依赖 Metrics Server 且与 HPA 冲突，必须按顺序、带验证地部署。
Metrics Server 必须先部署并确认指标可查
VPA 的 VPARecommender 组件完全依赖 Metrics Server 提供的 pod_cpu_usage 和 pod_memory_working_set 指标。如果 Metrics Server 未就绪或指标延迟超过 5 分钟，VPA 就无法生成任何建议。
- 执行
kubectl get apiservices | grep metrics，确认v1beta1.metrics.k8s.io状态为True - 运行
kubectl top pods -n default，若报错metrics not available或超时，说明 Metrics Server 异常（常见于 RBAC 权限缺失或证书不匹配） - 在线部署推荐用官方 manifest：
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.2/components.yaml（注意 v0.7.x 兼容 Kubernetes 1.24+） - 部署后等待 2–3 分钟，再检查
kubectl get pods -n kube-system | grep metrics-server是否为Running
VPA 组件安装不能只跑 kubectl apply
VPA 由三个独立 Deployment 组成：vpa-recommender、vpa-updater、vpa-admission-controller。直接 apply 官方 YAML 后，常因 ServiceAccount 权限不足或 webhook 配置失败导致部分组件 CrashLoopBackOff。
- 优先使用官方脚本安装（更稳定）：
./hack/vpa-up.sh（需 clonehttps://github.com/kubernetes/autoscaler仓库） - 若手动部署，必须确认
vpa-admission-controller的caBundle已注入到ValidatingWebhookConfiguration，否则 Pod 创建会被拦截并卡在Pending - 检查关键日志：
kubectl logs -n kube-system deploy/vpa-recommender，若出现no metrics found for pod，说明 Metrics Server 仍不可用 - 验证组件健康：
kubectl get deployment -n kube-system | grep vpa，三者都应为READY 1/1
VPA 对象必须显式绑定 Deployment，且不能和 HPA 共存
VPA 不会自动扫描集群中所有工作负载——你必须为每个需要垂直伸缩的 Go 应用 Deployment 单独创建一个 VerticalPodAutoscaler 对象。更重要的是，VPA 和 HPA 不能作用于同一个 Deployment，否则 vpa-updater 会拒绝修改资源请求（因 HPA 可能正在滚动更新副本）。
- 示例 VPA 配置（适用于 Go HTTP 服务）：
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: go-app-vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: go-app
updatePolicy:
updateMode: "Auto" # 或 "Off"（仅推荐不执行）、"Initial"（仅创建时设）
resourcePolicy:
containerPolicies:
- containerName: "go-app-container"
minAllowed:
cpu: "100m"
memory: "128Mi"
maxAllowed:
cpu: "2000m"
memory: "2Gi"
- 确保
targetRef.name与你的 Go Deployment 名字完全一致（区分大小写） - Go 应用通常内存增长缓慢但 CPU 波动大，建议设置较宽的
minAllowed/maxAllowed范围，避免频繁触发Recreate（VPA 默认策略） - 若已存在 HPA，请先
kubectl delete hpa go-app-hpa，否则 VPA 更新会静默失败
VPA 推荐生效要等至少 10 分钟，且首次更新必重启 Pod
VPA 的 recommender 默认每 10 分钟计算一次建议，updater 在收到建议后才触发 Pod 重建。这意味着从部署 VPA 到看到第一个 Pod 被替换，至少需要 10–15 分钟；而且无论更新幅度多小，VPA 都会删除旧 Pod 并新建（除非用 updateMode: Off + 手动 patch）。
- 检查是否生成建议：
kubectl get vparecommendations -o wide，正常应有go-app-vpa-xxx条目，STATE为Recommended - 查看推荐详情：
kubectl get vparecommendation go-app-vpa-xxx -o yaml，关注recommendation.containerRecommendations[].target - 若长时间无推荐，检查 Go 应用是否真有资源使用（如空闲时 CPU 持续为 0，VPA 会跳过计算）；可临时加压：
ab -n 1000 -c 10 http://go-app-svc/ - 生产环境 Go 服务若要求高可用，慎用
updateMode: Auto；建议先用Off模式观察推荐值 1–2 天，再人工 patch 到 Deployment 的resources.requests
VPA 的核心价值不在“自动”，而在“数据驱动的资源配置依据”——它给出的 target 值比经验估算更可靠，但它的执行机制（Pod 重启）决定了它不适合对启动时间敏感或状态强依赖的 Go 微服务。真正落地时，多数团队把 VPA 当作“资源审计工具”，而非全自动控制器。
