4、成本数据采集方法：Prometheus + kube-state-metrics + node-exporter + cost-analyzer 数据采集架构

在 Kubernetes 集群升级场景中，成本基线对比的准确性完全依赖于底层数据的采集质量。本章将深入剖析以 Prometheus 为核心、kube-state-metrics、node-exporter 和 cost-analyzer 为数据源的采集架构，确保每一笔资源消耗都能被精确捕获并关联到成本维度。

4.1 采集架构总览

该架构采用“拉取（Pull）”与“推送（Push）”混合模式，通过 Prometheus 作为时序数据库统一存储，再经由 cost-analyzer 进行成本分摊计算。整体数据流分为三层：基础设施指标层、Kubernetes 对象状态层、成本聚合层。

4.2 核心组件详解

4.2.1 node-exporter：节点资源使用率

node-exporter 部署在每个 Kubernetes 节点上（DaemonSet），负责暴露操作系统级别的硬件与内核指标。它是判断升级后节点资源利用率是否异常的基础数据源。

4.2.2 kube-state-metrics：K8s 对象状态

kube-state-metrics 通过监听 Kubernetes API Server，生成关于 Deployment、StatefulSet、Pod、HPA 等资源对象的元数据指标。它不直接采集资源使用率，而是提供“资源规格”与“副本数”等状态信息，是成本分摊计算中“资源请求量”的来源。

# 示例：kube-state-metrics 暴露的 Pod 资源请求指标
kube_pod_container_resource_requests{container="nginx", namespace="prod", resource="cpu", unit="core"} 0.5
kube_pod_container_resource_requests{container="nginx", namespace="prod", resource="memory", unit="byte"} 2.147483648e+09
kube_deployment_spec_replicas{deployment="web-app", namespace="prod"} 3

4.2.3 cost-analyzer：成本分摊引擎

cost-analyzer（Kubecost 开源核心组件）从 Prometheus 读取 node-exporter 和 kube-state-metrics 的数据，结合用户配置的云供应商价格模型（如 AWS EKS 节点单价、Azure AKS 实例费率），将集群总成本按 CPU、内存、存储、网络等维度分摊到每个命名空间、Deployment 甚至 Pod。

4.3 采集配置示例

以下为 Prometheus 采集配置的核心片段，展示如何通过 ServiceMonitor 自动发现各 exporter 端点：

# prometheus-adapter 或 Prometheus Operator 的 ServiceMonitor 配置
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: node-exporter-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/component: exporter
      app.kubernetes.io/name: node-exporter
  endpoints:
  - port: http-metrics
    interval: 30s
    scrapeTimeout: 10s
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-state-metrics-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: kube-state-metrics
  endpoints:
  - port: http-metrics
    interval: 60s
    scrapeTimeout: 30s

4.4 数据采集质量保障

成本基线对比的可靠性取决于数据采集的完整性与一致性。升级前后必须确保以下条件：

• 采集周期一致：升级前后使用相同的 scrape_interval（建议 30s），避免因采样粒度不同导致基线偏差。
• 指标保留时长：Prometheus 本地存储建议保留至少 30 天数据，以便回看升级前基线。
• 标签一致性：确保升级前后命名空间、标签命名规则不变，否则 cost-analyzer 的分摊逻辑会断裂。
• 节点数量与规格：记录升级前后的节点列表（实例类型、数量），作为成本对比的固定参照系。

4.5 升级前后成本基线对比的数据准备

在升级操作执行前，必须完成以下数据采集与基线固化工作：

1. 导出升级前 7 天成本快照：通过 cost-analyzer API 获取命名空间级别的每日成本 CSV。
2. 标记基线时间窗口：在 Prometheus 中记录 upgrade_before_timestamp 标签，用于后续查询过滤。
3. 备份 Prometheus 数据：使用 snapshot API 创建数据快照，防止升级过程中数据丢失。
4. 部署升级后采集验证：升级完成后立即检查所有 exporter 端点是否正常返回数据，确保采集链路无中断。