container_memory_rss 与使用的节点内存的关系

Question

我试图理解与node_memory_used有关的container_memory_rss或container_memory_working_set_bytes ，即（node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes）

这就是我的意思

PROMQL 1：

sum(container_memory_rss) by (instance) / 1024 / 1024 / 1024

{instance="172.19.51.8:10250"}        7.537441253662109

PROMQL 2：

sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) by (instance) / 1024 / 1024 / 1024

{instance="172.19.51.8:9100"}         2.2688369750976562

PROMQL 3：

sum(container_memory_working_set_bytes) by (instance) / 1024 / 1024 / 1024

{instance="172.19.51.8:10250"}        9.285114288330078

PROMQL 4：

sum(node_memory_MemAvailable_bytes) by (instance) / 1024 / 1024 / 1024

{instance="172.19.51.8:9100"}         13.356605529785156

所以如果一个 Pod 总是运行在一个 Node 上。我无法理解为什么container_memory_rss或 container_memory_working_set_bytes大于node_memory_used

即 PROMQL 1 和 PROMQL 3 的值远大于 PROMSQL 2 的值（即节点使用的内存）。

我不知道我是否正确，pod/容器 rss 不应该始终 <= 使用的节点内存（即使没有设置默认资源限制）

Answer 1

太长了；博士

\n

使用容器名称过滤器 ( container!="") 排除总计：

\n

sum(container_memory_rss{container!=""}) by (instance) / 2^30\n

\n

解释

\n

如果您运行第一个按容器名称对结果进行分组的查询，您会注意到大部分使用情况来自没有名称的容器：

\n

sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (name)) / 2^30\n\n{}                          3.9971389770507812\n{name="prometheus"}         0.6084518432617188\n{name="cluster-autoscaler"} 0.04230499267578125\n

\n

实际上有几个条目没有名称，但它们都有一个id：

\n

sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (id)) / 2^30\n\n# these do not have a container name\n{id="/"}                                1.1889266967773438\n{id="/kubepods"}                        0.900482177734375\n{id="/kubepods/burstable"}              0.6727218627929688\n{id="/system.slice/docker.service"}     0.07495498657226562\n{id="/system.slice/kubelet.service"}    0.060611724853515625\n\n# and this is an example id of a real container which has a name label\n{id="/kubepods/burstable/pod562495f9-afa6-427e-8435-016c2b500c74/e73975d90b66772e2e17ab14c473a2d058c0b9ffecc505739ee1a94032728a78"} 0.6027107238769531\n

\n

这些是每个 的累积值cgroup。cAdvisor从中获取统计数据cgroups，如果您查看它们，您会发现熟悉的实体：

\n

# systemd-cgls -a\n\xe2\x94\x9c\xe2\x94\x80kubepods\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80podc7dfcc4e-74fc-4469-ad56-c13fe5a9e7d8\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x8061a1a58e47968e7595f3458a6ded74f9088789a865bda2be431b8c8b07da1c6e\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80d47601e38a96076dd6e0205f57b0c365d4473cb6051eb0f0e995afb31143279b\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80podfde9b8ca-ce80-4467-ba05-03f02a14d569\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x809d3783df65085d54028e2303ccb2e143fecddfb85d7df4467996e82691892176\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x8047702b7977bed65ddc86de92475be8f93b50b06ae8bd99bae9710f0b6f63d8f6\n\xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80burstable\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80pod9ff634a5-fd2a-42e2-be27-7e1028e96b67\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x805fa225aad10bdc1be372859697f53d5517ad28c565c6f1536501543a071cdefc\n\xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x8027402fed2e4bb650a6fc41ba073f9994a3fc24782ee366fb8b93a6fd939ba4d3\n

\n

如果将 的所有直接子项相加，例如kubepods，您将得到相同的值kubepodshas。因为这些总数sum(container_memory_rss) by (instance)显示的是实际资源利用率的几倍。

\n

解决方案只是过滤掉任何没有容器名称的值。您可以在查询时执行此操作（如顶部的示例所示），也可以使用relabel_config配置 Prometheus以在抓取时删除此类指标。

\n