Elasticsearch ES_Java_Opts 和 Kubernetes 资源限制之间有什么关系
What is the relationship between Elasticsearh ES_Java_Opts and Kubernetes Resource Limits
所以我在 Kubernetes 中有一个 Elasticsearch 集群。
运行 所在的机器有 30 GB RAM 和 8 个内核。
现在根据经验法则，我们将 RAM 的 50% 设置为 ES_JAVA_OPTS，其余部分用于文件缓存。
这里是 15 GB
同样在 helm 图表中，我们有如下提到的资源需求：
resources:
limits:
cpu: 8
memory: 15Gi
requests:
cpu: 8
memory: 15Gi
我的问题是 50% RAM 是主机的（即 30 GB）还是 helm chart 中指定的限制 15 GB
谁能解释一下 kubernetes 如何利用 RAM
因为如果主机和文件缓存不被视为部署应用程序的利用率，我们就可以了。但如果它在资源限制内，我需要将其增加到 30GB。
编辑：
这里的问题是，如果一个 elasticsearch 节点使用 50% 的 RAM 作为堆，50% 作为文件缓存，我提到在 30GB 机器中堆为 15GB（50% 的 RAM）。所以我应该提到部署模板中的资源限制大约 15GB，Heap 需要 30GB（比如 28GB），根据规则 Elasticsearch 需要能够缓存文件。
这让人担心，好像 pod 在任何给定时刻超过了模板上提到的限制 kubernetes 重新启动 pod。
所以换句话说，我想知道 RAM 文件缓存是否在 pod 的整体内存使用中发挥作用。
注意：我使用实例存储作为 ES 数据的主要存储，因为与 EBS 相比速度非常快。
结论:
将Heap保留在系统RAM中的一半，并在资源限制中提及（如果有）
我不是 k8s 和 docker 方面的专家，但我的理解是，docker 容器使用主机资源并使用资源限制，您可以对其可以使用的资源进行硬性限制消费。
如果您将资源限制设置为 15GB，那么您的 docker 容器总体上可以消耗 15GB 的主机 RAM.now 它是否会与主机共享文件系统缓存取决于您的方式配置了您的 docker 音量。
因为 docker 容器可以选择使用 bind volume 与主机共享文件系统或拥有自己的数据量（这是短暂的，不适合作为有状态应用程序的 ES） .在第一个选项中，它应该与主机共享文件系统缓存，并且你不应该进一步增加资源限制（推荐你有有状态的 ES）在第二个选项中，因为它将使用自己的文件系统，你必须为其分配 RAM它的文件系统缓存，并且必须将 RAM 增加到 30 GB，但是您还必须为主机 OS 提供一些 space。
容器将始终看到节点的内存而不是容器内存。在 Kubernertes 中，即使你为容器设置了内存限制，容器本身并不知道这个限制。
这会影响在系统上查找可用内存并使用该信息来决定要保留多少内存的应用程序。
这就是您设置 JVM heap size 的原因。如果没有指定，JVM 将根据 host/node 总内存而不是容器的可用内存（您已声明为限制）设置最大堆大小。
查看有关限制在 k8s 中如何工作的 this 文章。
所以我在 Kubernetes 中有一个 Elasticsearch 集群。
运行 所在的机器有 30 GB RAM 和 8 个内核。
现在根据经验法则，我们将 RAM 的 50% 设置为 ES_JAVA_OPTS，其余部分用于文件缓存。
这里是 15 GB
同样在 helm 图表中，我们有如下提到的资源需求：
resources:
limits:
cpu: 8
memory: 15Gi
requests:
cpu: 8
memory: 15Gi
我的问题是 50% RAM 是主机的（即 30 GB）还是 helm chart 中指定的限制 15 GB
谁能解释一下 kubernetes 如何利用 RAM
因为如果主机和文件缓存不被视为部署应用程序的利用率，我们就可以了。但如果它在资源限制内，我需要将其增加到 30GB。
编辑：
这里的问题是，如果一个 elasticsearch 节点使用 50% 的 RAM 作为堆，50% 作为文件缓存，我提到在 30GB 机器中堆为 15GB（50% 的 RAM）。所以我应该提到部署模板中的资源限制大约 15GB，Heap 需要 30GB（比如 28GB），根据规则 Elasticsearch 需要能够缓存文件。
这让人担心，好像 pod 在任何给定时刻超过了模板上提到的限制 kubernetes 重新启动 pod。
所以换句话说，我想知道 RAM 文件缓存是否在 pod 的整体内存使用中发挥作用。
注意：我使用实例存储作为 ES 数据的主要存储，因为与 EBS 相比速度非常快。
结论:
将Heap保留在系统RAM中的一半，并在资源限制中提及（如果有）
我不是 k8s 和 docker 方面的专家，但我的理解是，docker 容器使用主机资源并使用资源限制，您可以对其可以使用的资源进行硬性限制消费。
如果您将资源限制设置为 15GB，那么您的 docker 容器总体上可以消耗 15GB 的主机 RAM.now 它是否会与主机共享文件系统缓存取决于您的方式配置了您的 docker 音量。
因为 docker 容器可以选择使用 bind volume 与主机共享文件系统或拥有自己的数据量（这是短暂的，不适合作为有状态应用程序的 ES） .在第一个选项中，它应该与主机共享文件系统缓存，并且你不应该进一步增加资源限制（推荐你有有状态的 ES）在第二个选项中，因为它将使用自己的文件系统，你必须为其分配 RAM它的文件系统缓存，并且必须将 RAM 增加到 30 GB，但是您还必须为主机 OS 提供一些 space。
容器将始终看到节点的内存而不是容器内存。在 Kubernertes 中，即使你为容器设置了内存限制，容器本身并不知道这个限制。
这会影响在系统上查找可用内存并使用该信息来决定要保留多少内存的应用程序。
这就是您设置 JVM heap size 的原因。如果没有指定，JVM 将根据 host/node 总内存而不是容器的可用内存（您已声明为限制）设置最大堆大小。
查看有关限制在 k8s 中如何工作的 this 文章。