K8s 里 request 设得偏高导致超卖不足，实际用量长期只有 30% 怎么权衡？

背景：我负责一个 12 节点（8C16G、节点池混部）的生产集群，Kubernetes 1.28，containerd。最近做成本复盘时发现一个反复出现的矛盾：很多业务 Pod 的 CPU/Memory request 是按压测峰值 × 1.5 设置的，结果节点实际用量长期只有 25%–35%，但业务方拒绝降 request，理由是「万一峰值来了」。

现象：

• 节点级 CPU 平均利用率 ~28%，Memory ~33%；
• 但个别 Pod 的 request 是 limit 的 80%，导致调度器把它们当「大 Pod」排布，节点装箱率很差；
• 一次扩容 4 台节点后，利用率从 40% 掉到 22%，财务那边开始追问云资源账单。

已尝试的排查与结果：

1. 上了 vertical-pod-autoscaler（VPA）只开 recommendation 模式跑了两周，发现推荐值普遍比当前 request 低 40%–60%，但业务方不敢直接应用；
2. 试了 KEDA 做 HPA 联动，但业务方反馈「弹性扩容慢，冷启动要 30s+」，放弃了纯弹性路线；
3. 和 SRE 团队约定了一个「request 不超过 90 天 P95 × 1.2」的治理规则，但推不动，因为业务方说 P95 不覆盖真正的突发。

期望得到的答案形态：

• 有没有一套可落地的「request 治理 + 弹性兜底」组合方案，既能让装箱率提上去，又不让业务方裸奔？
• VPA + HPA 组合用的具体配置坑（比如 VPA 和 HPA 同时改 CPU 会冲突，怎么分工）；
• 有没有人用过「节点池分层 + request 分级」的做法（比如核心业务独占节点池、非核心混部），效果如何？
• 成本侧：怎么向业务方量化「降 request 的收益 vs 风险」，用什么数据说话？