2. 资源画像基础：定义、关键指标与采集原理

资源画像是云原生成本分摊模型的核心数据底座。它通过持续观测工作负载（Pod、Node、命名空间）在 CPU、内存、网络、存储四个维度的实际用量，生成一组高保真、带时间戳的“资源消费快照”。没有准确的资源画像，任何分摊模型都只是“黑盒估算”。

2.1 资源画像的定义与价值

资源画像（Resource Profile）是对云原生环境中每个可计费单元（通常以 Pod 为最小粒度）在特定时间窗口内资源消耗行为的数字化描述。它包含三个核心特征：

• 多维度：同时覆盖 CPU、内存、网络 I/O、存储 I/O 与容量。
• 时间序列化：以秒/分钟级粒度记录，支持聚合与回放。
• 可归因：通过标签（Labels）与注解（Annotations）关联到业务单元、团队或项目。

2.2 关键指标定义与采集粒度

下表列出资源画像的四大类关键指标及其在 Kubernetes 环境中的典型采集来源与粒度：

2.3 采集原理：从 cgroup 到 Prometheus

Kubernetes 资源画像的采集链路遵循“内核 cgroup → kubelet/cAdvisor → Metrics Server / Prometheus → 成本引擎”的经典架构。下图展示了核心数据流：

2.4 采集原理的关键技术细节

资源画像的准确性取决于采集层的三个关键技术决策：

1. 指标源选择：cAdvisor 暴露的 container_cpu_usage_seconds_total 和 container_memory_working_set_bytes 是业界标准。避免直接使用 container_memory_usage_bytes，因为它包含缓存，会导致内存画像偏高 20%~40%。
2. 采样与聚合策略：Prometheus 默认 15s 拉取一次。在成本分摊场景中，建议将原始数据按 5 分钟窗口聚合为 P50/P90/P99 分位数，以消除瞬时尖刺对分摊结果的影响。
3. 标签传递与保留：必须确保 Pod 的 namespace、pod、container 标签以及业务自定义标签（如 team、project、env）在采集链路中不被丢弃。这是后续按维度分摊的基础。

2.5 资源画像数据模型示例

以下是一个标准化的资源画像记录结构（以 JSON 格式表示），用于成本分摊引擎的输入：

{
  "timestamp": "2025-03-21T14:30:00Z",
  "window": "5m",
  "workload": {
    "namespace": "production",
    "pod": "api-server-7d8f9c6b4-x2y3z",
    "container": "api-server",
    "labels": {
      "team": "platform",
      "service": "api-gateway",
      "env": "prod"
    }
  },
  "resources": {
    "cpu": {
      "usage_avg_cores": 0.85,
      "usage_p99_cores": 1.20,
      "request_cores": 2.0,
      "limit_cores": 4.0
    },
    "memory": {
      "usage_avg_bytes": 524288000,
      "usage_p99_bytes": 734003200,
      "working_set_bytes": 503316480,
      "request_bytes": 1073741824,
      "limit_bytes": 2147483648
    },
    "network": {
      "rx_bytes_total": 157286400,
      "tx_bytes_total": 104857600
    },
    "storage": {
      "ephemeral_usage_bytes": 20971520,
      "pvc_usage_bytes": 1073741824
    }
  }
}