为何需在Kubernetes中为Deployment/Pod设置内存限制而非调高内存请求？

首先得搞清楚K8S里request（请求）和limit（限制）的本质区别：request是Pod调度时向集群申请的预留资源，K8S只会把Pod调度到能满足所有Pod请求总和的节点上；limit是Pod运行时能使用的最大资源上限，超过这个值K8S会直接触发OOM杀死进程。这两者作用完全不同，不能互相替代。

为什么必须设置内存限制？ #

• 防止资源滥用，保障集群稳定性
  如果不设内存限制，某个Pod的进程出现内存泄漏或突发流量导致内存暴涨，会耗尽节点上的所有可用内存。不仅自身会被节点的OOM Killer随机杀死（节点层面的OOM规则更不可控），还会挤垮同一节点上的其他Pod，甚至导致节点宕机。设置限制后，K8S会在Pod内存接近上限时提前干预，把影响控制在单个Pod范围内。

• 平衡调度效率与资源利用率
  如果每个Pod都把请求设得足够高，节点上的预留资源会被大量占用，但实际运行中Pod可能只用到其中一小部分，造成严重的资源浪费。比如一个Pod平时仅需512MB内存，请求却设为2GB，节点原本能容纳4个这样的Pod，现在只能放1个，集群利用率直接降到四分之一。而限制可以让Pod在节点有空闲资源时临时使用超出请求的内存，同时又给了明确上限，既提高资源利用率又能兜底。

• 多租户场景下的公平性
  在多租户集群中，没有限制的话，某个租户的Pod可能抢占所有节点资源，导致其他租户的Pod无法正常运行。设置限制能确保每个租户的资源使用被约束在合理范围内，避免“强者通吃”的情况。

• OOM行为的可控性
  你提到的崩溃循环，其实是可控的表现——通过限制，你能明确知道Pod的内存阈值，进而针对性优化：比如调整限制大小、排查内存泄漏、优化应用逻辑。如果没有限制，Pod可能在节点内存耗尽时被随机杀死，排查问题的难度会大幅提升，甚至可能影响整个节点的其他服务。

为什么只靠高请求不可行？ #

• 调度难度增加
  高请求意味着Pod需要更大的节点资源预留，很多节点可能无法满足这个请求，导致Pod长时间处于Pending状态无法调度。
• 资源浪费严重
  高请求但低实际使用会造成大量内存闲置，集群的性价比极低。
• 应对突发流量不灵活
  即使请求设得很高，当遇到超出预期的突发流量时，Pod还是可能需要更多内存。这时候如果没有限制，要么挤垮节点，要么被节点OOM杀死；而有了限制，你可以通过HPA（水平Pod自动扩缩容）增加Pod数量来分散负载，比单纯拉高单个Pod的请求更灵活高效。

内容的提问来源于stack exchange，提问作者vmayer