container_memory_rss 与使用的节点内存的关系
container_memory_rss relation with node memory used
我正在尝试理解 container_memory_rss 或 container_memory_working_set_bytes 关于 node_memory_used 即（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 总是运行在一个节点上。我不明白为什么 container_memory_rss 或 container_memory_working_set_bytes 大于 node_memory_used
即 PROMQL 1 和 PROMQL 3 的值远远超过 PROMSQL 2 的值，即节点使用的内存。
我不知道我是否正确 pod / 容器 rss 不应该总是 <= 使用的节点内存（即使没有设置默认资源限制）
tl;博士
使用容器名称过滤器 (container!="") 排除总数：
sum(container_memory_rss{container!=""}) by (instance) / 2^30
说明
如果您 运行 第一个查询结果按容器名称分组，您会注意到大部分使用都来自没有名称的容器：
sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (name)) / 2^30
{} 3.9971389770507812
{name="prometheus"} 0.6084518432617188
{name="cluster-autoscaler"} 0.04230499267578125
实际上有几个条目没有名字，但它们都有一个 id:
sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (id)) / 2^30
# these do not have a container name
{id="/"} 1.1889266967773438
{id="/kubepods"} 0.900482177734375
{id="/kubepods/burstable"} 0.6727218627929688
{id="/system.slice/docker.service"} 0.07495498657226562
{id="/system.slice/kubelet.service"} 0.060611724853515625
# and this is an example id of a real container which has a name label
{id="/kubepods/burstable/pod562495f9-afa6-427e-8435-016c2b500c74/e73975d90b66772e2e17ab14c473a2d058c0b9ffecc505739ee1a94032728a78"} 0.6027107238769531
这些是每个 cgroup 的累积值。 cAdvisor 从 cgroups 中获取统计数据，如果您查看它们，您会发现熟悉的实体：
# systemd-cgls -a
├─kubepods
│ ├─podc7dfcc4e-74fc-4469-ad56-c13fe5a9e7d8
│ │ ├─61a1a58e47968e7595f3458a6ded74f9088789a865bda2be431b8c8b07da1c6e
│ │ └─d47601e38a96076dd6e0205f57b0c365d4473cb6051eb0f0e995afb31143279b
│ ├─podfde9b8ca-ce80-4467-ba05-03f02a14d569
│ │ ├─9d3783df65085d54028e2303ccb2e143fecddfb85d7df4467996e82691892176
│ │ └─47702b7977bed65ddc86de92475be8f93b50b06ae8bd99bae9710f0b6f63d8f6
│ ├─burstable
│ │ ├─pod9ff634a5-fd2a-42e2-be27-7e1028e96b67
│ │ │ ├─5fa225aad10bdc1be372859697f53d5517ad28c565c6f1536501543a071cdefc
│ │ │ └─27402fed2e4bb650a6fc41ba073f9994a3fc24782ee366fb8b93a6fd939ba4d3
如果您将 kubepods 的所有直接子项相加，您将得到与 kubepods 相同的值。由于这些总数 sum(container_memory_rss) by (instance) 显示了实际资源利用率的几倍。
解决方案就是过滤掉任何没有容器名称的值。您可以在查询时执行此操作，如顶部的示例所示，或者使用 relabel_config 配置 Prometheus 以在抓取时删除此类指标。
我正在尝试理解 container_memory_rss 或 container_memory_working_set_bytes 关于 node_memory_used 即（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 总是运行在一个节点上。我不明白为什么 container_memory_rss 或 container_memory_working_set_bytes 大于 node_memory_used
即 PROMQL 1 和 PROMQL 3 的值远远超过 PROMSQL 2 的值，即节点使用的内存。
我不知道我是否正确 pod / 容器 rss 不应该总是 <= 使用的节点内存（即使没有设置默认资源限制）
tl;博士
使用容器名称过滤器 (container!="") 排除总数：
sum(container_memory_rss{container!=""}) by (instance) / 2^30
说明
如果您 运行 第一个查询结果按容器名称分组，您会注意到大部分使用都来自没有名称的容器：
sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (name)) / 2^30
{} 3.9971389770507812
{name="prometheus"} 0.6084518432617188
{name="cluster-autoscaler"} 0.04230499267578125
实际上有几个条目没有名字，但它们都有一个 id:
sort_desc(sum(container_memory_rss{instance="ip-192-168-104-46"}) by (id)) / 2^30
# these do not have a container name
{id="/"} 1.1889266967773438
{id="/kubepods"} 0.900482177734375
{id="/kubepods/burstable"} 0.6727218627929688
{id="/system.slice/docker.service"} 0.07495498657226562
{id="/system.slice/kubelet.service"} 0.060611724853515625
# and this is an example id of a real container which has a name label
{id="/kubepods/burstable/pod562495f9-afa6-427e-8435-016c2b500c74/e73975d90b66772e2e17ab14c473a2d058c0b9ffecc505739ee1a94032728a78"} 0.6027107238769531
这些是每个 cgroup 的累积值。 cAdvisor 从 cgroups 中获取统计数据，如果您查看它们，您会发现熟悉的实体：
# systemd-cgls -a
├─kubepods
│ ├─podc7dfcc4e-74fc-4469-ad56-c13fe5a9e7d8
│ │ ├─61a1a58e47968e7595f3458a6ded74f9088789a865bda2be431b8c8b07da1c6e
│ │ └─d47601e38a96076dd6e0205f57b0c365d4473cb6051eb0f0e995afb31143279b
│ ├─podfde9b8ca-ce80-4467-ba05-03f02a14d569
│ │ ├─9d3783df65085d54028e2303ccb2e143fecddfb85d7df4467996e82691892176
│ │ └─47702b7977bed65ddc86de92475be8f93b50b06ae8bd99bae9710f0b6f63d8f6
│ ├─burstable
│ │ ├─pod9ff634a5-fd2a-42e2-be27-7e1028e96b67
│ │ │ ├─5fa225aad10bdc1be372859697f53d5517ad28c565c6f1536501543a071cdefc
│ │ │ └─27402fed2e4bb650a6fc41ba073f9994a3fc24782ee366fb8b93a6fd939ba4d3
如果您将 kubepods 的所有直接子项相加，您将得到与 kubepods 相同的值。由于这些总数 sum(container_memory_rss) by (instance) 显示了实际资源利用率的几倍。
解决方案就是过滤掉任何没有容器名称的值。您可以在查询时执行此操作，如顶部的示例所示，或者使用 relabel_config 配置 Prometheus 以在抓取时删除此类指标。