资源定容难的原因是配置在工作负载上线前就已确定，而负载的流量与行为持续变化。过量申请带来直接成本，不足则引发 OOM、CPU 节流与驱逐风险；节点自动伸缩器只按 request 决策，request 偏差会被放大为整集群的容量错配。

该测试版的做法是以生产历史为输入，分析使用曲线与节点内资源竞争，预测需求而非事后被动扩容，同时把 Istio、Linkerd、Vault agent 等注入 sidecar 的占用一并纳入计算。安全边界包括：只调整 request、不动 limit，受 HPA 或 KEDA 控制的资源保持不变，策略版本化并记录审计日志，尽量使用原地调整、必要时回退到滚动更新。现有客户可在不额外部署采集器的前提下先看建议与预计月度节省，再决定是否开启自动化。

对企业 IT 与平台团队而言，值得关注三点：一是可观测数据直接驱动基础设施变更正在从理念走向产品；二是把 request 的可信度交给自动化工具前，必须先确认遥测覆盖与价格模型；三是这类能力适合从开发、测试命名空间开始灰度，生产数据库等需要预留增长空间的负载仍应手动管理。

来源：The New Stack，原文。