4. 容器级成本采集架构：cAdvisor、Metrics Server、Prometheus 采集 CPU/内存/网络/存储的架构设计

容器级成本分摊的精度取决于底层指标采集链路的可靠性。本章深入剖析从 cAdvisor 原始数据暴露、Metrics Server 聚合采样，到 Prometheus 拉取与存储的完整架构，并针对 CPU、内存、网络、存储四类资源的采集路径与常见故障点进行拆解。

4.1 四层采集架构总览

容器资源指标采集遵循“节点代理 → 聚合缓存 → 时序存储 → 成本计算”的分层模型。每一层承担不同的职责，也对应不同的故障模式。

4.2 CPU 与内存采集路径

CPU 和内存是成本分摊中最核心的两类资源。它们的采集路径有显著差异，故障表现也各不相同。

4.2.1 CPU 采集：从 cgroup 到 Prometheus

• 原始数据源：/sys/fs/cgroup/cpu,cpuacct/cpuacct.usage — 纳秒级累计计数器。
• cAdvisor 处理：计算 delta(cpuacct.usage) / delta(time) / 核数，得到 CPU 使用率（小数）。
• Prometheus 指标：container_cpu_usage_seconds_total{container="...", pod="..."}。
• 成本计算：使用 rate(container_cpu_usage_seconds_total[5m]) 转换为每秒使用量，乘以 CPU 单价。

4.2.2 内存采集：RSS 与 WorkingSet 的选择

4.3 网络与存储采集路径

网络和存储的采集复杂度高于 CPU/内存，因为涉及多接口、多驱动和持久卷映射。

4.3.1 网络采集：接口级与 Pod 级

• cAdvisor 暴露：container_network_receive_bytes_total 和 container_network_transmit_bytes_total，按网络接口（eth0, lo）区分。
• Pod 级聚合：PromQL 使用 sum by (pod, namespace) (rate(container_network_receive_bytes_total{interface="eth0"}[5m]))。
• 成本分摊：通常只统计 eth0 流量，忽略 lo。按入站/出站分别计价。

4.3.2 存储采集：临时存储与持久卷

4.4 采集链路故障排查清单

当成本分摊数据出现异常时，按以下链路逐层排查，可快速定位故障层。

1. 检查 cAdvisor 端点：curl http://<node-ip>:10250/metrics/cadvisor | head -50，确认容器指标是否正常暴露。
2. 验证 Metrics Server：kubectl top pod -n <namespace>，确认 Pod 级资源指标是否可用。
3. 检查 Prometheus 目标状态：在 Prometheus UI 的 Targets 页面确认 kubelet 和 cadvisor 目标为 UP 状态。
4. 验证指标存在性：在 Prometheus 中查询 container_cpu_usage_seconds_total{container!="POD"}，确认有数据返回。
5. 检查标签完整性：确认指标包含 container、pod、namespace 标签，且无空值。
6. 验证成本计算 PromQL：在 Prometheus 中直接执行成本分摊 PromQL，确认计算结果合理。

# 检查 cAdvisor 指标是否包含目标容器
  curl -sk https://node-ip:10250/metrics/cadvisor | grep "container_cpu_usage_seconds_total{container=\"my-app\"}"
  
  # 检查 Metrics Server 聚合延迟
  kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/my-app | jq .

4.5 精度与性能权衡

采集间隔、保留周期和指标粒度直接影响成本分摊的精度和存储开销。以下为推荐配置：