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