Kubernetes吊舱在获取了超过请求数量的内存后，是否会提供回内存

Question

我正在试图了解K8S吊舱内存分配的行为，但到目前为止，我在互联网上读到的材料没有什么好运气。

我的问题是，如果我有一个用以下值定义的内存POD模板

Limits:
  cpu:     2
  memory:  8Gi
Requests:
  cpu:     500m
  memory:  2Gi

假设我的应用程序突然需要更多内存，POD分配了4Gi（从2Gi初始内存）来完成任务。POD是否会将其获取的额外2Gi返还给底层操作系统，并在任务完成后再次成为2Gi POD，或者在任务完成后将作为具有4Gi内存的POD使用。

我的应用程序是一个在Apache Tomcat上运行的Java应用程序，为6Gi定义了最大堆。

Answer 1

库伯内特斯资源请求基本上在三次生效：

>

在最初计划新的POD时，资源请求（仅）用于查找具有足够空间的节点。请求总数必须小于节点的物理大小。未考虑限制和实际利用率。

如果进程分配内存，这将使其总利用率超过pod的限制，则分配将失败。

如果节点内存不足，Kubernetes将检查该节点上的吊舱，并逐出实际使用量超过其请求的吊舱。

假设您有一个内存为16 GiB的节点。您可以在一个部署中运行这个特定的pod，其中包含8个副本；它们都可以放在节点上，为了便于讨论，让我们假设Kubernetes将它们都放在那里。无论pod在做什么，第9个pod都无法安装在节点上，因为内存请求将超过物理内存。

如果pod继续分配总共4 GiB的内存，只要物理系统有内存就可以了。但是，如果节点内存不足，Kubernetes将看到这个pod比其请求多使用了2 GiB；这可能会导致pod被逐出（销毁并重新创建，可能在另一个节点上）。

如果进程确实将内存返回给操作系统，这将显示在指标的“实际利用率”部分；因为它的使用量现在将低于它的请求，所以如果节点确实运行内存溢出，它被驱逐的危险会更小。（但是，许多垃圾收集系统会尽可能长时间地保留操作系统内存并重用它；参见例如GC是否将内存释放回操作系统？。）