4. Kubecost 事件采集架构：Agent模式、Prometheus集成、ETL管道、数据湖设计

Kubecost 的事件采集架构是成本可观测性的数据基座。它通过 Agent 模式 实现轻量级部署，利用 Prometheus 集成 获取原生指标，经过 ETL 管道 进行数据清洗与聚合，最终将标准化数据写入 数据湖 以支撑历史分析与故障时间线还原。理解这一架构，是构建资源配额模型与事件流还原策略的前提。

4.1 采集架构总览：四层数据流

Kubecost 的数据采集并非单一进程完成，而是由四个逻辑层协作实现：

4.2 Agent 模式：轻量级集群内采集器

Kubecost Agent 是一个部署在目标集群内的 DaemonSet 或 Deployment，它不运行完整的成本分析引擎，只执行以下三项任务：

1. 指标拉取： 从集群内 Prometheus（或直接通过 kube-state-metrics API）拉取 CPU、内存、GPU、网络、存储的用量指标。
2. 元数据收集： 采集命名空间、标签、注解、控制器类型、节点池信息等资源元数据。
3. 数据推送： 将原始指标与元数据打包，通过 HTTPS 推送到中央 Kubecost 后端或对象存储。

Agent 模式相比完整 Prometheus 联邦的优势在于：

4.3 Prometheus 集成：指标来源与联邦机制

当集群已部署 Prometheus 时，Kubecost 优先通过 Prometheus 联邦 API 获取数据。集成过程涉及以下关键指标组：

• 容器指标： container_cpu_usage_seconds_total、container_memory_working_set_bytes、container_network_receive_bytes_total
• 节点指标： node_cpu_seconds_total、node_memory_MemTotal_bytes、node_filesystem_size_bytes
• Kubernetes 对象指标： kube_pod_container_resource_requests、kube_namespace_labels、kube_deployment_labels
• GPU 指标（如适用）： DCGM_FI_DEV_GPU_UTIL、nvidia_gpu_memory_used_bytes

联邦配置示例（Prometheus server 端）：

scrape_configs:
  - job_name: 'kubecost-federate'
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{__name__=~"container_.*"}'
        - '{__name__=~"kube_.*"}'
        - '{__name__=~"node_.*"}'
    static_configs:
      - targets: ['prometheus-kube-prometheus-prometheus:9090']

4.4 ETL 管道：从指标到成本的转换引擎

ETL 管道是 Kubecost 的核心处理环节，运行在 kubecost-cost-analyzer 容器中。它按以下阶段处理数据：

ETL 管道的关键配置参数：

# values.yaml 中的 ETL 相关配置
kubecostProductConfigs:
  etl:
    enabled: true
    resolution: 1h          # 聚合粒度：1h / 30m / 5m
    retentionDays: 90       # 数据湖保留天数
    storageClass: "standard" # 持久卷存储类
    cloudProvider: "aws"    # 云提供商：aws / gcp / azure
    customPrices:           # 自定义单价覆盖
      cpu: "0.031611"
      memory: "0.004237"
      gpu: "0.700000"

4.5 数据湖设计：持久化与历史回溯

Kubecost 的数据湖并非传统意义上的 Hadoop 数据湖，而是一个 分层存储架构，用于持久化 ETL 输出，支撑故障时间线还原中的历史成本查询。

数据湖的存储层次：

• 热层（内存 + SSD）： 最近 7 天的聚合数据，用于实时仪表盘和告警。
• 温层（持久卷 / PVC）： 7-90 天的数据，以 Parquet 格式存储，支持按命名空间、标签、时间范围快速过滤。
• 冷层（对象存储 S3/GCS/Azure Blob）： 超过 90 天的归档数据，用于年度审计和容量规划。

数据湖的目录结构示例：

kubecost-data-lake/
├── year=2025/
│   ├── month=03/
│   │   ├── day=15/
│   │   │   ├── hour=08/
│   │   │   │   ├── namespace_cost.parquet
│   │   │   │   ├── controller_cost.parquet
│   │   │   │   └── label_cost.parquet
│   │   │   └── hour=09/
│   │   └── day=16/
│   └── month=04/
└── year=2026/

4.6 采集架构总览图

下图展示了从 Agent/Prometheus 到数据湖的完整数据流，以及 ETL 管道在其中的核心位置：

4.7 架构设计要点总结

• Agent 优先： 新集群部署推荐 Agent 模式，降低运维复杂度；已有 Prometheus 的集群使用联邦模式以复用现有基础设施。
• ETL 幂等性： ETL 管道支持重复执行，相同输入产生相同输出，确保故障恢复后数据一致性。
• 数据湖分层： 热/温/冷三层存储策略平衡查询性能与存储成本，Parquet 格式压缩比可达 5:1。
• 故障隔离： 采集层故障不影响 ETL 层已有数据；ETL 层故障不影响数据湖中已持久化的历史数据。