goldilocks 的 vpa 推荐仅为只读建议，不自动修改 deployment；需手动或通过自建 webhook 应用建议，最终依赖 deployment 滚动更新生效。
Goldilocks 的 VPA 推荐是只读建议，不自动改 Deployment
Goldilocks 本身**不会修改你的 Pod 资源配置**，它只是基于 VPA Recommender 的历史指标（CPU/内存使用峰值、均值、90分位等）生成 status.recommendation.containerRecommendations。这些数据存在 VPA 对象里，模式默认是 updateMode: "Off" —— 换句话说，VPA 连容器都不动一下，纯看不练。
常见错误现象：有人部署完 Goldilocks 就等着“自动优化”，结果一周后发现 Pod 资源请求纹丝不动，Dashboard 上的绿色建议条也从来没生效。原因就是没后续动作。
- Webhook 方式本质是监听 VPA 对象变更（比如通过
watchAPI），拿到新建议后触发外部逻辑（如调用kubectl patch或更新 Helm values） - 手动方式是人肉点开 Dashboard，复制 CPU/Memory 建议值，再编辑
Deployment.spec.template.spec.containers[].resources.requests - 两者都绕不开“写 Deployment”这一步 —— Kubernetes 不允许直接 patch Pod 的 requests，必须滚动更新 Pod 模板
Webhook 自动化不是开箱即用，得自己搭触发链路
Goldilocks 官方**不提供内置 Webhook 服务端**，也没有 /webhook endpoint 或预置 receiver。所谓“VPA 推荐 webhook”，其实是你得自己写个监听器，比如用 client-go watch verticalpodautoscalers.autoscaling.k8s.io 资源，过滤出 status.conditions[].type == "RecommendationProvided" 的事件，再解析 status.recommendation。
容易踩的坑：
- 没做去重：VPA 可能连续 emit 相同建议，导致重复 patch Deployment，引发不必要的滚动更新
- 没加安全边界：直接把
target值当requests写进去，万一指标毛刺高估了 300%，Pod 下次就 OOMKilled - 没校验命名空间标签：Goldilocks 默认只对打了
goldilocks.fairwinds.com/enabled=true的 ns 生效，但 webhook 监听的是全集群 VPA，可能误处理测试环境对象 - 没控制频率：哪怕加了去重，如果每 5 分钟检查一次 VPA 状态，仍可能因 metrics server 延迟导致建议抖动
手动应用建议反而更可控，适合稳态生产环境
对多数中小团队，每周花 15 分钟人工核对 Goldilocks Dashboard，比搭一套 webhook 更快、更少出错。关键是把“看建议”和“改配置”拆成两个可审计的动作。
实操建议：
- 打开
http://localhost:8080（kubectl port-forward svc/goldilocks-dashboard -n goldilocks 8080:80），筛选出Confidence≥ 80% 的推荐项 - 取
target值 × 1.2 作为新requests（留 20% 缓冲），limits可设为requests × 2或保持原策略 - 用
kubectl edit deploy/<name> -n <ns></ns></name>修改，或走 CI 流水线更新 Helmvalues.yaml后helm upgrade - 改完立刻观察：用
kubectl top pods -n <ns></ns>和kubectl describe pod确认新 Pod 的 requests 已生效，且无OOMKilled或NodePressure事件
滚动更新是唯一安全落地方式，别碰 Recreate 或直接删 Pod
无论 webhook 还是手动改，最终都得靠 Deployment 的滚动更新机制生效。这是唯一不影响服务可用性的路径 —— 新 Pod 拉起、就绪、流量接入，旧 Pod 才被优雅终止。
性能与风险提示：
-
maxSurge: 25%和maxUnavailable: 25%是默认保守值，若应用支持多实例并行，可适当调高maxSurge加速更新 - 千万别用
kubectl delete pod强制刷新：这会绕过 Deployment 控制器，导致副本数临时不足，且新 Pod 可能因资源不足调度失败 - 避免在业务高峰时段批量更新多个 Deployment：即使单个滚动更新平滑，叠加后仍可能造成节点 CPU 短时超卖
- 如果应用有长连接或状态缓存，确认 readinessProbe 已正确定义，否则新 Pod 可能在未就绪时就被打入流量
真正难的从来不是怎么拿到建议，而是判断“这个建议值到底敢不敢用”——它依赖你对应用内存泄漏模式、GC 行为、突发流量容忍度的理解。Dashboard 上那个绿色数字，永远只是参考线，不是判决书。
