3. 成本数据采集：kube-state-metrics、Prometheus、cAdvisor 的指标采集与聚合

成本分摊模型的精度，完全取决于底层数据的采集质量。在 Kubernetes 环境中，kube-state-metrics、cAdvisor 和 Prometheus 构成了成本数据采集的“铁三角”。本章将深入剖析这三个组件的指标来源、采集粒度以及聚合策略，为后续的成本分摊计算打下坚实的数据基础。

3.1 数据采集铁三角：职责与指标

三个组件各司其职，分别提供成本计算所需的不同维度数据。下表清晰地展示了它们的核心职责与关键指标：

3.2 指标采集流程与聚合策略

理解数据从产生到聚合的完整链路，是设计成本模型的前提。下面的 SVG 图展示了从 Pod 到最终成本视图的端到端数据流。

3.3 核心指标详解与 PromQL 示例

在实际工程中，我们通常使用以下 PromQL 语句来获取成本分摊所需的关键数据。请务必注意 rate() 和 avg_over_time() 等函数在聚合窗口上的选择。

3.3.1 获取 Pod 的 CPU 使用量（核心/秒）

  # 计算过去5分钟内，每个Pod的CPU使用率（核心数）
  sum(
    rate(container_cpu_usage_seconds_total{container!="POD", container!=""}[5m])
  ) by (namespace, pod, container)

3.3.2 获取 Pod 的内存工作集（字节）

  # 获取当前时刻的内存工作集，常用于实时成本计算
  sum(
    container_memory_working_set_bytes{container!="POD", container!=""}
  ) by (namespace, pod, container)

3.3.3 获取 Pod 的 CPU 资源请求量

  # 从 kube-state-metrics 获取资源请求，用于计算分配率
  sum(
    kube_pod_container_resource_requests{resource="cpu"}
  ) by (namespace, pod, container)

3.4 数据关联与标签对齐

成本分摊的核心难点在于将 cAdvisor 的 Usage 数据与 kube-state-metrics 的 Request/Limit 数据关联到同一个 Pod 或 Namespace 上。这依赖于 Prometheus 的标签（Label）机制。

• 关联键： namespace、pod、container 是三个核心关联标签。
• 标签缺失： 某些 cAdvisor 指标可能缺少 container 标签（如 container_network_receive_bytes_total），需要在 PromQL 中通过 on() 或 ignoring() 进行多指标关联。
• 自定义标签： 建议在 kube-state-metrics 中启用 --metric-labels-allowlist 参数，将业务标签（如 team、cost-center）注入到指标中，实现更灵活的成本分摊。

3.5 采集架构最佳实践

为了支撑大规模集群的成本数据采集，建议遵循以下架构原则：

1. 独立采集任务： 在 Prometheus 中为成本数据创建独立的 scrape_config，避免与监控告警任务互相干扰。
2. 合理设置采集间隔： 成本数据对实时性要求不高，建议将 scrape_interval 设置为 30s 或 60s，降低 Prometheus 和 kubelet 的负载。
3. 数据保留策略： 成本分摊通常需要查看月度趋势，建议将成本相关指标的 retention 时间设置为 30 天以上，并启用 --storage.tsdb.retention.size 限制存储大小。
4. 使用 Recording Rules： 将复杂的成本分摊 PromQL 预计算为 record 规则，大幅提升查询性能。