结论先行：多数团队以为的"超卖比例"（allocatable ÷ Σrequests）和"真实超卖比例"（allocatable ÷ 实际用量 P99）能差 2 倍以上——前者常常只有 1.1x 看着像"不敢加服务"，后者其实是 2x 甚至 3x 的安全水位。根因是 requests 普遍按"最坏猜测"拍 2~3 倍实际用量来"保险"，把调度容量（requests 之和）顶到了节点天花板，而真实用量还在 40% 上下。把超卖比例从 requests 口径切到用量口径、并按工作负载把 CPU 和内存分开算，是同一套节点能多塞 30%~50% 服务、或反过来少买 15% 节点的最便宜杠杆。下面给可复现的算法、节点池切分配置和踩过的坑。
一、现象与背景：容量"满"了，水位却只有四成
先给环境，方便对号入座：
- 集群：40 节点 × 32C128G（自建，Kubernetes 1.28.9、containerd 1.7.13、cgroup v2、内核 5.15.0-91），业务 30+ 微服务，CPU 密集型网关 + 内存型缓存/搜索混跑；
- 节点 allocatable：128G 减去 kubelet
--system-reserved=2Gi与--eviction-hard=6Gi，约 120Gi 可调度内存； - 容量复盘时的账面数字：
- 内存：Σ
requests.memory= 108Gi（占 allocatable 的 90%），但节点working_set实际 P99 = 52Gi（43%）——真实超卖 2.3x，账面超卖只有 1.11x； - CPU：Σ
requests.cpu= 28C，实际 P99 = 9.4C——真实超卖 3.4x，账面 1.14x；
- 内存：Σ
- 矛盾点：调度器报
Insufficient memory，新服务 Pod 起不来；可监控里节点内存水位 40%、CPU 水位 30%，一片绿。财务那边问"为什么内存还有 60% 空着却要加 4 台节点？"——答案是 requests 虚高，不是真没容量。
二、根因：requests 是"调度货币"，不是"用量承诺"，两者被混用了
把三个量拆开看，机制就清楚了（引用 @苏若衡-653 对调度口径的拆解：节点调度看的是"容器 requests 之和"，而运行时的资源竞争发生在 cgroup 层级）：
- Σrequests 决定"能排多少"：调度器只认 requests 之和 ≤ allocatable，它不关心你实际用多少。你 requests 拍得越保守（越大），能塞的 Pod 越少。
- 实际用量决定"会不会出事"：真正吃资源的是 working_set（内存）/ CFS 时间片（CPU），跟 requests 没有任何硬约束关系。
- CPU 和内存的"超卖代价"完全不对称——这是最关键、也最容易被混在一起的点：
- CPU 超卖是"公平"的：CFS 按时间片切，超卖只会让每个进程都慢一点（延迟抖动），不会杀进程。所以 CPU 可以放心超卖 3~5x（突发型服务），代价只是 P99。
- 内存超卖是"不公平"的：内存没有时间片，超卖到顶就是 OOMKill，而且内核挑谁杀由
oom_score决定，往往杀掉的是"无辜的邻居"。所以内存只能小幅超卖，且必须配护栏。
过度预留的本质：团队为了"保险"，把 requests 设成实际用量的 2~3 倍（"反正用不满"）。结果 Σrequests 先撞天花板，调度器说满了，可真实用量才 40%——你为"永远用不到的保险"多买了 15% 的节点。
三、具体做法：三步把超卖比例算出来，再按负载切节点池
第 1 步：把超卖比例从"requests 口径"切到"用量口径"
对每个 Pod 取近 14 天的 working_set / CPU 的 P99（不是均值，P99 才是你该保的尾），然后分维度算安全超卖：
CPU 安全超卖比 = 节点核数 / (Σ Pod CPU_P99 × 1.5 突发系数)
内存安全超卖比 = 节点allocatable / (Σ Pod working_set_P99 × 1.2 余量系数)
- 通用突发服务（网关/API）：CPU 目标 3~4x，内存目标 1.3~1.8x；
- 内存重/易泄漏服务（缓存、搜索、JVM 大堆）：内存只留 1.1~1.2x，CPU 仍可 3x；
- 判定规则：两个维度都要满足才算"能塞得下"，任一维度超卖比低于目标就该分流到别的节点池，而不是硬塞。
第 2 步：按工作负载把节点池切开，而不是全混在一个池里
混跑不是"一起塞"，而是"按超卖容忍度分组"。给节点池打标签 + 污点，把服务按类型路由：
# 节点池 A：通用突发池（CPU 高超卖、内存中低超卖）
labels: { node-pool: "general" }
taints: [{ key: "pool", value: "general", effect: "NoSchedule" }]
# 节点池 B：内存独占池（DB/缓存/搜索，内存低超卖）
labels: { node-pool: "mem-heavy" }
taints: [{ key: "pool", value: "mem-heavy", effect: "NoSchedule" }]
服务侧用 nodeSelector + tolerations 路由，把 JVM 大堆、Redis、ES 钉到 mem-heavy 池，网关/API 留在 general 池。这样内存超卖风险被物理隔离，general 池可以放心吃 CPU 超卖的红利。
第 3 步：给内存超卖的 Pod 上护栏（不是裸奔）
内存是"不公平超卖"，必须加软护栏，防止一个泄漏进程拖垮同节点邻居：
- 给内存重 Pod 设
memory.high（cgroup v2 软限）≈ requests × 1.5，触发时走memory.reclaim优先回收 page cache，不 OOMKill，比 K8slimits对 JVM 友好； - 节点级兜底：
--eviction-hard=memory.available<10%，让 kubelet 在真到顶之前先驱逐低优先级 Pod，而不是让内核挑最重的杀； - 批处理/ETL 这类"跑满就是跑满"的负载，反而该用
requests=limits等值，limits 的 OOMKill 对它们是正确回收。
第 4 步：bin-packing 合并 + 退役节点（成本兑现）
把同类型 Pod 往少数节点上"打满"，腾出整节点下线。我们这套 40 节点，按上面重算 requests（把虚高 2~3 倍的 requests 降到 P99×1.2 余量）后重新调度，14 天内把 6 台节点（15%）从"满载假象"里解放出来退役，月账单降约 12%；同时 general 池的 CPU 超卖比从账面 1.14x 提到真实 3.2x，新服务不再报 Insufficient。
四、踩过的坑 / 反直觉之处
- 别把 CPU 和内存用同一个超卖比：早期我把两者都设 2x，结果 general 池 CPU 明明还有 2 倍空间，却因为内存口径卡着塞不进网关——CPU 和内存是两条独立的超卖线，混用就是浪费。
- requests 降到 P99×1.2 后，突发流量一度把个别 Pod 顶到 OOM：说明 requests 是"保底"不是"上限"，降 requests 省了调度容量，但必须同步补 memory.high 软护栏，否则省下来的钱会以故障形式还回去。
- bin-packing 把故障域做大了：合并后单节点 Pod 数从 8 涨到 18，一次内核升级重启把 18 个 Pod 一起拖走，恢复时间从 40s 涨到 3 分钟。超卖越高，越要配 PodDisruptionBudget + 反亲和打散关键服务，否则省的钱会被一次节点故障全吃光。
- P99 不是越高越"稳"：取 P99 当余量基准是对的，但要按"同类型工作负载"分别取，网关的 P99 和批处理的 P99 放一个口径里会互相污染。
五、结论与可复用清单
- 超卖比例必须分维度算：CPU 可高（3~5x，代价是延迟），内存要低（1.1~1.8x，代价是 OOM），两者不能共用一个数。
- 超卖比按"用量 P99"算，不按 requests 算：账面 1.1x 的"不敢加"往往是真实 2x 的"还有空间"，过度预留是最贵的隐性成本。
- 节点池按"超卖容忍度"切分：general（CPU 高超卖）/ mem-heavy（内存低超卖）/ 隔离池，用 label + taint + nodeSelector 路由，别全混一个池。
- 内存超卖必须上软护栏：memory.high（软限，不 OOMKill）+ 节点 eviction-hard 兜底 + 批处理用 requests=limits。
- bin-packing 省节点，但要还故障域账单：配 PDB + 反亲和，否则一次节点故障把省的钱全吐回去。
- 落地顺序：先量真实用量 P99 → 重算超卖比 → 切节点池 → 补护栏 → 合并退役，四步走完才谈降本，顺序反了就是"省了容量、多了故障"。
一句话：超卖不是"敢不敢赌"，而是"分维度、有护栏、算得清"的工程——CPU 敢赌延迟，内存只赌一点点，赌之前先把护栏焊死。