问题描述
想要以两种不同的方式绘制节点的网络带宽使用情况：
- 通过查看该节点的全局指标。
- 通过汇总每个Pod的相应指标。
为了实现这一目标，用户使用了以下Prometheus查询（以接收带宽为例）：
- 对整个节点（来自node-exporter的指标）：
sum(irate(node_network_receive_bytes_total{instance="10.142.0.54:9100"}[$__rate_interval])) by (device)
- 对每个Pod（来自kubelet的指标）：
sum(irate(container_network_receive_bytes_total{node="$node",container!=""}[$__rate_interval])) by (pod,interface)
在生成了一些针对名为 thrpt-receiver 的HTTP服务的负载后，结果显示在以下Grafana仪表板上：
如果我查看原始指标，没有应用sum()和irate()的情况下，我看到的情况如下：
解决方案
请注意以下操作注意版本差异及修改前做好备份。
检查Pod的网络命名空间
用户发现了导致图表出现巨大差异的原因。所有上述提到的Pod都有一个共同点：它们使用主机的网络命名空间，因此它们的网络指标完全相同，并且等于全局主机的指标（只是稍有不同的精度）。
你可以使用以下命令检查Pod是否使用了主机的网络命名空间：
kubectl get pod -o jsonpath='{.spec.hostNetwork}' prometheus-stack-prometheus-node-exporter-jnhw7
kubectl -n kube-system get pod -o jsonpath='{.items[*].spec.hostNetwork}' kube-proxy-gke-triggermesh-product-control-plane-7fc0ad24-z586 gke-metrics-agent-5cv4m prometheus-to-sd-tk8jv fluentbit-gke-xh879
你会发现，所有这些Pod的hostNetwork属性都设置为true，这就是它们的网络指标与主机的指标相同的原因。
解决方法
为了解决这个问题，你可以考虑将Pod的网络命名空间与主机分离，以便它们的网络指标能够独立统计。这样，每个Pod的指标就不会再与主机的指标相等。
请注意，这可能需要重新配置Pod，具体操作如下：
- 修改Pod的网络配置，使其不再使用主机的网络命名空间。
- 检查修改后的指标，确保每个Pod的指标都与主机的指标不同。
通过这些步骤，你应该能够获得正确的网络指标，而不再受到Pod网络命名空间的影响。
附加评论
另一位用户提到了类似的问题，他们的node-exporter Pod的带宽大幅增加（超过400MB/s），但他们无法解释这种情况。在他们的案例中，一个Redis Pod的网络传输非常高，这些流量通过calico/kube-proxy在主机网络上进行路由。虽然主机机器只有150MB/s的网络传输，但这是由calico引起的，它只将外部流量路由到其他节点，大量流量仍然停留在主机本身的虚拟网络中。
这个评论提供了对这个问题的额外见解，说明了可能出现的不同情况，以及如何应对这些情况。
正文完