中设置内存请求小于限制的用例是什么？K8s

Question

我理解设置CPU请求小于限制的用例——如果实例有空闲CPU，它允许每个容器中的CPU爆发，从而导致最大CPU利用率。然而，我真的找不到对内存做同样事情的用例。大多数应用程序在分配内存后不会释放内存，因此实际上应用程序会请求“限制”内存(这与设置request = limit的效果相同)。唯一的例外是在已经分配了所有内存的实例上运行的容器。我看不出这有什么好处，坏处是更不确定的行为，很难监控(由于繁重的GC，一个容器比另一个容器有更高的延迟)。我能想到的唯一用例是内存缓存中的阴影，在这种情况下，您需要考虑内存使用的峰值。但是，即使在这种情况下，也存在其中一个节点性能不佳的风险。

Answer 1

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

如果没有内存请求和上限，Kubernetes 会将请求默认为限制（这可能会导致调度失败，即使满足 pods 的实际需求也是如此）。

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

设置低于限制的内存请求将会给你的pod空间来进行突发活动。此外，您还要确保Pod在加速期间可以使用的内存实际上是一个合理的数量。

设置内存限制==内存请求是不可取的，因为活动峰值会使它在高速公路上被内核杀死。如果内存压力是最有可能的情况，库伯内特斯中的内存限制就不能被限制（让我们记住没有交换分区）。

引用威尔·汤姆林（Will Tomlin）和他关于请求与限制的有趣文章，我强烈推荐：

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

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

Answer 2

也许不是真正的答案，而是对这个主题的看法。

与CPU和内存限制的区别在于当达到限制时会发生什么。在CPU的情况下，容器保持运行，但是CPU的使用是有限的。如果达到内存限制，容器将被终止并重新启动。

在我的用例中，我经常将内存请求设置为应用程序平均使用的内存量，限制为25%。这让我在大多数时候避免了容器杀戮（这很好），但这当然会使我面临内存过度分配的问题（正如您所提到的，这可能是一个问题）。