三级服务质量等级决定资源不足时先杀谁

[[requests与limits双设置项是对抗多多益善心理的过度申请浪费]]留下的 超额分配风险，靠服务质量等级（QoS Level）来兜底——这是Pod的一个隐含 属性，纯粹由requests和limits的设置方式推导出来，不需要用户单独声明。 三级由高到低：Guaranteed——Pod中所有容器都设置了limits和requests且 两者相等；Burstable——部分容器requests小于limits，或者只设requests不 设limits；BestEffort——limits和requests都不设置。不设限制看起来是”最 灵活”的选择（可以使用节点上所有可用计算资源），但Google在Borg论文里 明确给出近乎惩罚性的建议：节点资源不足时优先杀掉这类Pod——这类Pod正是 最不稳定的风险来源，因为它没有对自己需要多少资源做出任何承诺。因此 建议把数据库这类有状态、不容中断的应用设为Guaranteed（除非用超了自己 声明的limits，或者节点内存压力大到把所有更低等级的Pod都杀光了，否则不 会被自动杀死）；临时的、不重要的任务设为BestEffort（调度时更容易找到 宿主机，也更容易被优先牺牲）。这套等级制度背后是一句直白的价值判断—— “所有Pod生来平等，但有些Pod比其他Pod更加平等”（书中借用《动物庄园》 的名句）：Kubernetes明确不承诺对所有工作负载一视同仁，而是要求你用 requests/limits的设置方式主动表明这个Pod有多重要。