\n\n本文深入分析了 Kubernetes 中 HPA 负载存在资源浪费却难以优化的原因。核心在于请求配置与扩缩容行为深度耦合，团队出于对生产稳定性的极度重视，宁愿忍受浪费也不愿冒险。
译自：HPA-managed workloads: Why the obvious waste stays
作者：Yasmin Rajabi
运行 Kubernetes 的团队通常能清楚地看到他们在哪里过度配置了。请求值（Requests）高于实际需求，系统始终留有余量，容量处于低效使用状态。
这种情况已经存在一段时间了，但随着更多团队在 Kubernetes 上运行突发性更强的模型推理工作负载，并开始更直接地感受到过度配置带来的成本压力，这一问题现在表现得愈发频繁。
然而，这些工作负载却无人敢动。
这种情况在 HPA（水平 Pod 自动扩缩容）管理的业务中最为明显。低效是显而易见的：随着 HPA 的扩容，浪费也随之扩大。但不那么明显的是，当你尝试改变它时会发生什么。
这些工作负载已经在真实的生产流量下进行了扩缩容。团队观察过它们在流量峰值、发布和故障期间的表现。这种历史表现建立了信任。一旦建立了这种信任，容忍低效就比面对不可预测性要容易得多。
大多数优化方法最大的问题不在于数学计算，而在于它们将其视为一个数学问题。团队并不是在为平均利用率做优化。他们是在为一个季度中最糟糕的那五分钟的弹性做优化。任何不能理解这一区别的方法，都是在解决错误的问题。
问题不在于发现浪费
大多数团队在几分钟内就能发现过度配置的工作负载。我敢打赌，每个组织至少都有一个 Grafana 仪表盘，展示着已分配容量与已使用容量之间的巨大差异。更难的问题是，应用更改后会发生什么。
对于 HPA 管理的工作负载，请求值（Requests）不仅仅是一个规格输入，它们还塑造了扩缩容行为。HPA 的决策取决于利用率比率，因此当请求值改变时，这些比率也会改变。这会改变扩缩容开始的时机以及副本数增加的激进程度。
这就是资源变更与代码部署在本质上感觉不同的原因。一个糟糕的部署有明确的回滚路径。而一个糟糕的资源变更则更加隐蔽。它改变了工作负载与调度程序之间的一份无形契约，而且故障模式可能直到周五下午流量激增、触及旧请求值下不存在的阈值时才会浮现。到那时，可能已经发生了另外三件事，想要证明因果关系几乎是不可能的。
更改请求值不仅仅是资源调整，它是对工作负载扩缩容方式的更改。这就是让团队感到紧张的原因。
团队究竟在保护什么
在大多数情况下，这并不是因为惰性或无知。这是一个深思熟虑的选择。团队正在保护已经奏效的行为：
- 流量峰值期间可预测的水平扩容
- 真实流量下稳定的延迟
- 发布和故障期间已知的行为表现
- 在需求变动时，能够解释服务将如何应对
一旦事物看起来运行“良好”，任何可能改变其扩缩容行为的变动都会被视为高风险。大多数团队宁愿忍受浪费，也不愿在他们已经依赖的服务中引入一个新的变量。
诚实地面对原因是有意义的：设置这些资源值的人，正是那些在凌晨 2 点出故障时被呼叫的人。风险并非抽象。一个缩减规模的建议在技术上可能是正确的，但如果它涉及到一个在六个月前发生过事故的团队所拥有的服务，那个团队是不会做任何改变的。节省成本的机会抵不上个人责任的风险。
为什么标准的“规格优化”到此为止
大多数规格优化（Rightsizing）工作流假设一个简单的循环：调整请求值，观察结果，迭代。这对于稳定的服务是有效的，因为在这些服务中，更改请求值不会同时改变扩缩容行为。
但在 HPA 管理的工作负载中，这套逻辑失效了，因为请求值与扩缩容是耦合的。在模型推理工作负载中，情况变得更加棘手，因为流量变化极快，且持有额外余量的成本异常显眼。
这种失效模式特别危险，因为它不是即时发生的。一个服务可能全周都显示低平均使用率，然后遇到一个流量峰值，这时原本看似浪费的余量恰恰是它保持稳定的原因。如果自动化工具仅根据最近的平均值进行过于紧凑的裁剪，就没有考虑到业务背景：产品发布、季节性高峰、市场活动或季末激增，而这些并不在过去两周的数据中。
这就是为什么即使浪费很明显，这些工作负载依然被排除在例行规格优化工作之外的原因。
需要满足什么条件团队才会行动
如果团队要在这里进行优化，保持现有的扩缩容行为是底线。更改请求值不能悄悄改变工作负载扩容的时机或其响应的激进程度。
有效的方法是将请求值和 HPA 目标值视为一对耦合的整体。原子化地同时调整两者，这样即使资源占用减少，工作负载在负载下的行为依然保持不变。
但即便是有正确的技术方法，仅凭这一点也是不够的。团队需要看到每项变更背后的依据，而不仅仅是建议。他们需要符合他们所承担的 SLO（服务等级目标）的护栏。他们需要一条从可见性开始，演进到经过批准的建议，最后在建立信任后才升级到自动化的路径。直接跳到完全自主并不能建立信心，它跳过了建立信心的过程。
这种信任曲线在更广泛的 Kubernetes 市场中也有所体现。在 CloudBolt 最近关于 Kubernetes 自动化信任差距 的研究中，团队一致报告称，可见性和建议比自主执行更容易被采纳。
团队还需要回滚操作简单直接。不是“提交工单然后等待”，而是由团队已经信任的相同健康信号触发的、自动且快速的回滚。
如果没有这一切，默认的答案依然很简单：别碰它。端 工智能
