4. 资源画像概念：什么是资源画像？

资源画像（Resource Profile）是对 Kubernetes Pod 在运行周期内资源使用行为的数字化建模。它不再依赖 Pod 的 Request/Limit 静态声明，而是通过采集历史监控数据，为每个 Pod 生成一组描述其 CPU、内存、网络 I/O 随时间变化规律的特征向量。资源画像是实现节点碎片整理与 FinOps 标签治理的数据基座。

4.1 资源画像的三维建模维度

一个完整的资源画像从三个核心维度对 Pod 进行建模，每个维度对应不同的 FinOps 优化策略：

4.2 基于历史指标的行为建模流程

资源画像的生成遵循“采集 → 清洗 → 聚合 → 建模 → 分类”五步流水线。以下是一个典型的建模流程：

1. 数据采集：通过 Prometheus/cAdvisor 以 15s～60s 间隔拉取 Pod 级容器指标，保留至少 7 天历史窗口。
2. 数据清洗：剔除冷启动阶段（前 5 分钟）、OOM 重启前后、节点故障等异常数据点。
3. 时间窗口聚合：按 1h/6h/24h 粒度计算 P50、P95、P99 分位数，生成“日周期特征向量”。
4. 行为模式提取：使用滑动窗口检测“突发峰值”、“稳态运行”、“周期性波动”三类基础模式。
5. 画像标签生成：输出结构化的 JSON 画像记录，写入 CRD 或标签系统。

4.3 资源画像的典型输出结构

以下是一个经过建模后的资源画像 JSON 示例，展示了 CPU 和内存维度的特征向量：

{
  "pod": "nginx-ingress-controller-7d8b9c",
  "namespace": "ingress-nginx",
  "profile_version": "v2",
  "cpu": {
    "request_ratio": 0.42,
    "limit_ratio": 0.18,
    "p50_utilization": 0.35,
    "p95_utilization": 0.68,
    "p99_utilization": 0.82,
    "burst_factor": 2.34,
    "throttle_percent": 1.2,
    "pattern": "periodic_burst"
  },
  "memory": {
    "working_set_p50_mb": 128,
    "working_set_p95_mb": 256,
    "working_set_p99_mb": 384,
    "rss_base_mb": 96,
    "growth_rate_mb_per_hour": 0.5,
    "pattern": "stable"
  },
  "network": {
    "ingress_mbps_p50": 15.2,
    "egress_mbps_p50": 8.7,
    "connection_count_p50": 120,
    "pattern": "steady_flow"
  }
}

4.4 资源画像与静态声明的对比

传统 Kubernetes 资源管理依赖 Request/Limit 的静态声明，而资源画像提供了动态、数据驱动的视角。两者的关键差异如下：

4.5 资源画像驱动的行为模式分类

基于历史指标建模后，Pod 的资源行为可归纳为四种典型模式。每种模式对应不同的节点碎片整理策略：

• 稳态型（Stable）：CPU/内存使用率波动 < 15%，适合与同类 Pod 共置，碎片风险低。
• 周期突发型（Periodic Burst）：每天固定时段出现 2～5 倍峰值，适合错峰调度，利用碎片窗口。
• 随机尖刺型（Spiky）：峰值不可预测，P99 利用率 > 3× P50，需要预留安全缓冲，碎片整理优先级高。
• 闲置型（Idle）：长期利用率 < 5%，是碎片整理和成本回收的首要目标。

4.6 资源画像在 FinOps 标签治理中的角色

资源画像的输出可以直接映射为 FinOps 标签，实现“画像驱动标签、标签驱动治理”的闭环：

• profile/pattern=stable|burst|spiky|idle：行为模式标签，用于调度策略和碎片整理优先级。
• profile/cpu_burst_factor=2.34：CPU 突发系数标签，用于 Overcommit 比例计算。
• profile/memory_stability=high：内存稳定性标签，用于内存超卖决策。
• profile/optimization_target=reclaim|resize|reshcedule：优化动作标签，驱动自动化工具链。