北京
你的EKS集群可能正在干一件很亏的事：节点利用率40%，账单却按78%的预留容量收。这不是右尺寸化没做好，而是调度器在"故意"浪费。
这篇文章讲了三行配置解决这个黑洞。不改任何工作负载，一个冲刺周期内把节点成本压下去25%-35%。
先看数字为什么对不上
一个典型EKS集群，Pod声明的CPU/内存请求加起来占节点容量的78%。集群自动扩缩容按这个数 provisioning 节点。财务收到的账单基于这些节点。但实际监控一看，利用率40%。
这38个百分点的gap叫"装箱效率损失"。它躲过了所有右尺寸化操作——因为你优化的是请求本身，而问题出在请求怎么被塞进节点。
Pod请求是"我可能会用到"的声明，不是实际用量。调度器按声明预留，自动扩缩容也只看预留。五个Pod各申2核（共10核预留），实际各跑1核（5核用量），节点显示100%预留、50%利用。这是设计如此，基于实际用量的超售会在突发流量时崩掉。
杠杆一：MostAllocated 评分策略
Kubernetes 默认调度器用 LeastAllocated，优先选空闲多的节点。逻辑是容错——Pod分散，单节点故障影响小。这默认没错，前提是你不为节点付费。
MostAllocated 反过来：优先选空闲少的节点，把Pod往紧了塞。这是显式开启的评分策略，副作用是故障爆炸半径变大。但云环境里，节点故障由云厂商处理，你的Pod本来就该设计为可迁移。
杠杆二：Karpenter 的 consolidation
MostAllocated 把节点塞满声明容量，实际用量留出的 headroom 由 Karpenter 的 consolidation 回收。它会：
• 把多个半空节点的工作负载合并到更少节点
• 自动替换为更小的实例类型
• 持续监控并重新优化
这是实时发生的，不需要人工指定实例类型。
杠杆三：三级优先级类
批处理任务（数据管道、CI构建、模型训练）可以打断。给它们打低优先级标签，高优先级Pod进来时直接驱逐。这让高优先级工作负载能挤进已装箱的节点，而不是触发新节点 provisioning。
三个杠杆一起转：MostAllocated 把声明容量压紧，consolidation 把实际 headroom 变现成更少的节点，优先级类让批处理成为"可压缩的填充物"。
为什么这比右尺寸化好推
右尺寸化要跟每个团队吵CPU内存请求该设多少。调度优化只改Pod落在哪里，政治成本低一个数量级。工作量在一个冲刺内能做完。而且做完之后右尺寸化更有效——因为装箱基线健康了，再调请求数字能看到真实的资源压力。
作者团队在典型EKS集群上跑出的数字：31%节点成本下降。范围通常是25%-35%，取决于原集群的装箱有多烂。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
