requests与limits双设置项是对抗"多多益善"心理的过度申请浪费

资源配额设在容器上（Pod的配额是所含容器需求的累加值，无须手动设置）， 但Kubernetes给了requests和limits两个独立设置项，用途完全不同：requests 是给调度器用的，Kubernetes选哪个节点运行Pod只看requests；limits才是给 cgroups用的，真正传给cgroups做资源限制的是limits的值。这个设计源自 Google在Borg/Omega系统长期运行中总结的经验：用户申请资源配额时天然 倾向”多多益善”——按可能面临的最大压力甚至未来增长去估算，为了避免服务 中断都往大了申请。如果直接按申请量分配限额，结果会是硬件资源大部分 时间闲置、但这些闲置资源又已经”名花有主”、无法被别人使用。用requests 和limits拆开只是第一步——调度器按requests（相对保守的估计）去撮合， 但如果真按最保守安全的方式分配，就意味着编排系统必须为万一发生的极端 情况买单：如果允许节点分配给Pod的资源总和超过自己能提供的最大资源， 一旦某一刻这些Pod的真实消耗真的超标了，节点就无法继续履行调度时对Pod 许下的资源承诺，只能杀掉部分Pod腾资源——这正是[[三级服务质量等级决定 资源不足时先杀谁]]要解决的问题。理解这个链条能看清一件事：Kubernetes 牺牲”绝对安全”换取”硬件利用率”这个取舍，本身就注定了后续必须再造一整套 “该先牺牲谁”的规则来兜底，这不是可有可无的附加功能，而是这个取舍必然 带来的配套成本。