在中设置内存请求小于限制的使用场景是什么。K8s

Question

我理解将CPU请求设置为小于limit的用例-如果实例有空闲的CPU，它允许每个容器中的CPU突发，从而导致最大的CPU利用率。然而，我真的找不到使用内存做同样的事情的用例。大多数应用程序在分配内存后不会释放它，因此有效地应用程序将请求最多'limit‘内存(这与设置request =limit的效果相同)。唯一的例外是运行在已经分配了所有内存的实例上的容器。我真的看不到任何优点，缺点是更多的不确定性行为，很难监控(由于大量的GC，一个容器比另一个具有更高的延迟)。我唯一能想到的用例是在内存缓存中使用阴影，在这种情况下，您希望允许内存使用量达到峰值。但即使在这种情况下，也会面临其中一个节点表现不佳的风险。

Answer 1

也许不是一个真正的答案，而是一个关于这个主题的观点。

CPU和内存限制的不同之处在于达到限制时会发生什么。如果是CPU，容器会继续运行，但CPU使用率是有限的。如果达到内存限制，容器将被终止并重启。

在我的用例中，我经常将内存请求设置为我的应用程序平均使用的内存量，并且限制为+25%。这使我可以避免在大多数情况下杀死容器(这很好)，但它当然会使我暴露于内存过度分配(正如您所提到的，这可能是一个问题)。

Answer 2

实际上，您提到的主题很有趣，同时也很复杂，就像Linux内存管理一样。正如我们所知道的，当进程使用的内存超过限制时，它将迅速上升到潜在的“杀死”进程的“阶梯”上。进一步说，limit的目的是告诉内核什么时候应该考虑进程可能会被终止。另一方面，请求是一个直接的声明，“我的容器将需要这么多内存”，但除此之外，它们为调度器提供了关于Pod可以被调度到哪里(基于可用的节点资源)的有价值的信息。

如果没有内存请求和高限制，Kubernetes会将请求默认为限制(这可能会导致调度失败，即使pods实际需求得到满足)。

如果您设置了一个请求，但没有限制-容器将使用名称空间的默认限制(如果没有，它将能够使用整个可用的节点内存)

设置低于限制的内存请求将为您的pod提供活动突发的空间。此外，您还需要确保Pod在boost过程中可以消耗的内存实际上是合理的。

设置memory limit == memory request是不可取的，因为活动尖峰会使它处于被内核杀死的状态。Kubernetes中的内存限制不能被限制，如果存在内存压力，这是最可能的情况(让我们还记住，没有交换分区)。

引用Will Tomlin和他在Requests vs Limits上的有趣文章，我强烈推荐：

您可能会问，是否有理由设置高于请求的限制。如果您的组件具有稳定的内存占用，那么您可能不应该这样做，因为当容器超出其请求时，如果工作节点遇到内存不足的情况，则更有可能被驱逐。

总而言之--没有简单直接的答案。您必须确定内存需求，并使用监控和警报工具进行控制，并准备好根据需要更改/调整配置。