将内存请求设置为小于限制的用例是什么？ K8s答案

【问题标题】：What is the use case of setting memory request less than limit in . K8s将内存请求设置为小于限制的用例是什么？ K8s
【发布时间】：2019-01-16 00:36:20
【问题描述】：

我了解将 CPU 请求设置为小于限制的用例 - 如果实例有空闲 CPU，它允许每个容器中的 CPU 突增，从而导致最大 CPU 利用率。但是，我无法真正找到对内存执行相同操作的用例。大多数应用程序在分配内存后不会释放内存，因此应用程序将有效地请求“限制”内存（这与设置请求 = 限制具有相同的效果）。唯一的例外是在已经分配了所有内存的实例上运行的容器。我真的没有看到这方面的任何优点，缺点是更难以监控的不确定性行为（一个容器由于大量 GC 而具有比另一个容器更高的延迟）。我能想到的唯一用例是内存缓存中的阴影，您希望在其中允许内存使用量激增。但即使在这种情况下，也会面临其中一个节点表现不佳的风险。

【问题讨论】：

"大多数应用程序在分配内存后不会释放内存" 你从哪里得到的？ 您隐含考虑的应用程序的子集可能是正确的，但总的来说听起来并不正确。
@Andrew Savinykh。公平的。我指的是一个典型的 JVM 应用程序，没有 NIO。堆通常不会自行收缩

标签： kubernetes

【解决方案1】：

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

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

在我的用例中，我经常将内存请求设置为我的应用程序平均使用的内存量，并将限制设置为 +25%。这可以让我在大多数情况下避免容器被杀（这很好），但当然它会让我面临内存过度分配（这可能是你提到的问题）。

【讨论】：

【解决方案2】：

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

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

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

设置低于限制的内存请求将为您的 pod 提供活动爆发的空间。此外，您还要确保在 boost 期间可供 Pod 使用的内存实际上是一个合理的数量。

设置内存限制 == 内存请求是不可取的，因为活动高峰会将其置于高速公路上，被内核杀死 OOM。 Kubernetes 中的内存限制不能被限制，如果内存压力是最可能的情况（让我们记住没有交换分区）。

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

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

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

【讨论】：