Spring Boot 内存计算器不使用容器内存限制答案

【问题标题】：Spring Boot Memory Calculator does not use container memory limitsSpring Boot 内存计算器不使用容器内存限制
【发布时间】：2021-09-18 03:51:49
【问题描述】：

我正在使用 spring-boot-maven-plugin 2.5.0 构建的 kubernetes 上运行一个容器。我尝试使用paketobuildpacks/builder 0.1.127-base 和0.1.115-base。

当我启动我的 pod 时，它会显示以下内容：

Calculating JVM memory based on 3353816K available memory

但是，这些是 kubectl describe pod 返回的请求/限制：

    Limits:
      cpu:     500m
      memory:  1Gi
    Requests:
      cpu:      500m
      memory:   1Gi

我读到内存计算器应该基于这些内存限制。我该怎么做才能让内存计算器根据容器内存进行计算？我希望有人可以帮助我解决这个问题。

【问题讨论】：

标签： kubernetes spring-boot-maven-plugin

【解决方案1】：

问题是因为内存计算器不适用于 cgroups v2。我的同事在 https://github.com/paketo-buildpacks/libjvm/pull/82

上为 buildpack 创建了一个拉取请求

现在我们更改了一些内核参数，以便使用旧的命名约定。

【讨论】：

【解决方案2】：

答案将由三部分组成。

Kubernetes

正如您正确指出的那样，容器可以检测调度 pod 的所有节点的内存。

$ free -h # run in host OS
              total        used        free      shared  buff/cache   available
Mem:           3.8G        949M        1.3G        2.0M        1.6G        2.7G
Swap:            0B          0B          0B
$ kubectl exec -it ubuntu2 -- free -h # run in a pod's container
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       961Mi       1.3Gi       2.0Mi       1.6Gi       2.7Gi
Swap:            0B          0B          0B

如果没有指定requests 和limits，容器可以消耗所有节点的内存（以及cpu）。什么负责什么：

requests - 使用工作节点上的容器调度 pod 所需的最小内存量。这应该是一个合理的数字，因为如果它太大，调度程序将很难找到一个可以启动这个 pod 的节点。容器有可能并且允许消耗比请求更多的内存。
limits - 限制分配给容器的最大内存量。一旦容器超过限制，它将被驱逐并重新创建。

Motivation for memory requests and limits

Kubernetes 中的 JVM 应用程序

过去，当 Java 应用程序托管在本地实例上时，有多少可用内存以及允许应用程序消耗多少内存是众所周知的。

由于所有集群都不同，并且容器可以看到工作节点上的全部内存量，因此应该定义 JVM 内存选项。在使用 requests 和 limits 的 kubernetes 中，可以为应用程序的容器提供确切所需的内存量，并将其与分配的 JVM heap memory 匹配。

有不同的选项可用于设置JVM 选项。与堆内存相关的最常见的有：

Explicit Heap Memory – Xms and Xmx Options

如何将其传递给 kubernetes 中的容器

StackOverflow 上已经有两个很好的答案可以解决类似的问题。

Answer 1 和 Answer 2

简而言之，它们涵盖了如何使用kubernetes environment variables 将选项传递给JVM，例如-Xms 和 -Xmx。

有用的链接：

（请熟悉）：

【讨论】：