我了解将CPU请求设置为小于限制的用例-如果实例具有可用的CPU，则允许每个容器中的CPU突发，从而导致最大的CPU利用率。 但是，我真的找不到用内存做同样的用例。大多数应用程序在分配内存后不会释放内存，因此有效地，应用程序将请求最多“限制”的内存（与设置request = limit的作用相同）。唯一的例外是在已分配了所有内存的实例上运行的容器。我在这方面并没有真正的优点，缺点是更不确定的行为，很难监控（由于GC繁重，一个容器的延迟比另一个容器高）。 我能想到的唯一用例是内存缓存中的阴影，您希望允许内存使用量激增。但是即使在这种情况下，也可能存在节点之一表现不佳的风险。
答案 0 :(得分：1)
也许不是一个真正的答案，而是关于这个问题的观点。
与CPU和内存限制的区别是达到限制时发生的事情。如果使用CPU，容器将继续运行，但是CPU使用率受到限制。如果达到内存限制，容器将被杀死并重新启动。
在我的用例中，我经常将内存请求设置为应用程序平均使用的内存量，并且将限制设置为+ 25％。这使我可以避免在大多数情况下杀死容器（这很好），但是当然，这会使我面临内存过度分配的问题（这可能是您提到的问题）。
答案 1 :(得分：0)
实际上，您提到的主题很有趣，与此同时也很复杂，就像Linux内存管理一样。我们知道，当进程使用的内存超过限制时，它将迅速上升到潜在的“杀死”进程“阶梯”。更进一步，限制的目的是告诉内核何时应该考虑可能终止该进程。另一方面，请求是直接声明“我的容器将需要这么多的内存”，但除此之外，它们还向调度程序提供有关可在何处调度Pod的有价值的信息（基于可用的Node资源）。
如果没有内存请求和上限，Kubernetes会将请求默认为限制（即使满足Pod的实际要求，这也可能导致调度失败）。
如果您设置了一个请求，但没有限制-容器将使用名称空间的默认限制（如果没有限制，它将能够使用整个可用的Node内存）
设置的内存请求低于限制，您将为Pod腾出空间来进行活动爆发。另外，还要确保Pod在增强期间可以消耗的内存实际上是合理的数量。
设置内存限制==内存请求是不理想的，因为活动高峰会将其放置在要被内核杀死OOM的高速公路上。如果存在最可能出现的内存压力，则不能限制Kubernetes中的内存限制（还请记住，没有交换分区）。
我强烈建议documentation和他关于Will Tomlin的有趣文章：
您可能会问是否有理由将限制设置为高于 要求。如果您的组件的内存占用量稳定，则您 可能不应该，因为当容器超出其要求时， 如果工作节点遇到内存不足的情况，则更有可能被驱逐 条件。
总结-没有简单直接的答案。您必须确定内存需求，并使用监视和警报工具进行控制，并准备根据需要更改/调整配置。