4. 资源画像基础：Pod资源画像定义、CPU/Memory画像指标、画像数据采集源

资源画像是云原生成本优化的第一道工序。没有准确的资源画像，FinOps 协同就失去了数据锚点。本章聚焦 Pod 级别的资源画像定义、核心指标体系和数据采集源，为后续的画像分析与成本优化建立数据基础。

4.1 Pod资源画像定义

Pod 资源画像是指对 Kubernetes 集群中每个 Pod 及其容器的资源使用行为进行量化描述的过程。它不同于简单的“当前使用量”监控，而是通过时间序列数据提炼出 Pod 的资源使用特征，包括：

• 稳态使用量：Pod 在正常运行状态下的资源消耗基线。
• 峰值与谷值：资源使用的波动范围与频率。
• 资源利用率：实际使用量相对于 Request/Limit 的比例。
• 资源浪费量：已申请但未使用的资源量。

4.2 CPU/Memory画像指标

CPU 和 Memory 是资源画像中最核心的两个维度。下表列出了每个维度的关键画像指标及其业务含义：

4.3 画像数据采集源

Kubernetes 生态中，Metrics Server 和 Prometheus 是最主流的两种数据采集源。它们在数据精度、存储周期和查询能力上存在显著差异，适用于不同的画像场景。

4.3.1 Metrics Server

• 定位：Kubernetes 内置的轻量级资源度量组件，用于 HPA 和 kubectl top 命令。
• 数据特点：仅保留当前时刻的瞬时数据，无历史存储。
• 采集指标：CPU 使用率（millicores）、Memory 使用量（bytes）。
• 适用场景：实时查看、快速诊断、HPA 动态扩缩容。
• 局限性：无法做历史趋势分析和分位数计算，不适合深度画像。

4.3.2 Prometheus

• 定位：云原生监控事实标准，支持多维数据模型和强大查询语言 PromQL。
• 数据特点：拉取模式，可配置保留周期（通常 15~30 天），支持聚合与降采样。
• 采集指标：container_cpu_usage_seconds_total、container_memory_working_set_bytes、container_network_receive_bytes_total 等。
• 适用场景：资源画像分析、成本分摊、历史趋势、异常检测。
• 优势：支持自定义标签、分位数计算、长时间窗口聚合。

4.4 数据采集架构

下图展示了从 Pod 到画像数据的完整采集链路，以及 Metrics Server 和 Prometheus 在架构中的位置：

4.5 关键采集指标清单

在进行资源画像时，需要从 Prometheus 中采集以下核心指标。建议在 Prometheus 的 scrape_config 中明确配置这些指标，避免采集过多无关数据：

avg(
  rate(container_cpu_usage_seconds_total{namespace="production", pod="web-app-7d8f9c"}[5m])
) / 
kube_pod_container_resource_requests{resource="cpu", namespace="production", pod="web-app-7d8f9c"}
* 100

4.6 数据采集最佳实践

• 采集频率：Prometheus 默认 15s 拉取一次，对于资源画像建议保持 30s 以内，避免数据稀疏导致分位数失真。
• 标签保留：确保 Prometheus 采集时保留 pod、namespace、container 标签，这是后续按工作负载聚合画像的基础。
• 数据降采样：对于超过 30 天的历史数据，使用 Prometheus 的 recording rules 将原始数据降采样为 5 分钟或 1 小时粒度，平衡存储成本与查询性能。
• 避免指标爆炸：对于高基数标签（如 pod 标签随 Deployment 滚动更新而变化），建议使用 __meta_kubernetes_pod_annotation_* 或 kube_pod_labels 进行关联，而非直接采集原始 pod 名称。