4. 资源画像概念：Pod/容器级别的资源使用特征采集与建模
资源画像是云原生成本优化与容量管理的核心基础。它通过对 Pod 及容器级别的 CPU、内存、网络、存储等资源使用特征进行持续采集与数学建模，将离散的监控数据转化为可预测、可归因、可调度的资源行为描述。没有准确的资源画像，成本分摊与 GitOps 同步窗口优化将失去数据支撑。
4.1 资源画像的四维采集对象
资源画像的采集维度覆盖容器运行时的全部关键资源。下表列出了每个维度的采集指标、数据来源与典型用途：
| 维度 | 核心指标 | 数据来源 | 画像用途 |
|---|---|---|---|
| CPU | 使用率（mCPU）、节流时间、CPU 亲和性 | cgroup cpuacct、kubelet /metrics/resource | 识别突发型与稳态型负载，计算 CPU 超分比 |
| 内存 | RSS、缓存、内存限制、OOM 事件 | cgroup memory、Prometheus container_memory_* | 确定内存预留水位，避免 OOM 与资源浪费 |
| 网络 | 入/出带宽、连接数、丢包率、重传率 | CNI 插件指标、kube-proxy 统计 | 评估网络密集型 Pod 的带宽成本与延迟影响 |
| 存储 | IOPS、吞吐量、卷容量使用率、IO 延迟 | CSI 驱动指标、kubelet volume_stats | 区分持久化存储与临时存储的成本归属 |
采集粒度建议：容器级指标采集周期推荐 15–30 秒，Pod 级聚合周期推荐 1 分钟。过高的采集频率会增加存储成本，过低则无法捕捉秒级突发特征。
4.2 资源使用特征的建模方法
原始采集数据需要经过建模才能形成可用的资源画像。建模过程通常包含三个步骤：数据清洗、特征提取与模式分类。
4.2.1 数据清洗与异常检测
- 去噪处理：剔除由于节点故障、采集抖动导致的异常尖刺（如 CPU 瞬时 100% 但持续不足 1 秒）。
- 缺失值填充：对于短时间（< 2 分钟）的数据空洞，使用线性插值或前向填充。
- 重采样对齐：将不同维度的采集数据统一到相同时间窗口（如 1 分钟均值），便于后续建模。
4.2.2 特征提取与统计量
对清洗后的时序数据，提取以下统计特征作为画像的数学基础：
- 均值（Mean）：反映资源使用的中心趋势，用于成本分摊的基准计算。
- 峰值（P99/P95/P50）：反映资源使用的尾部行为，用于容量规划与限流阈值设定。
- 标准差（StdDev）：衡量资源使用的波动程度，波动越大，预留资源浪费越多。
- 自相关性（Autocorrelation）：识别周期性模式（如白天高负载、夜间低负载）。
4.2.3 模式分类与标签化
基于提取的特征，将 Pod/容器划分为以下典型资源使用模式：
| 模式类型 | 特征描述 | 典型场景 | 成本优化策略 |
|---|---|---|---|
| 稳态型 | 均值高、标准差低、无显著峰值 | 数据库、消息队列 | 使用预留实例，减少弹性扩缩 |
| 突发型 | 均值低、P99 远高于均值、短时尖刺 | Web 服务、API 网关 | 使用突发实例或 HPA 快速响应 |
| 周期型 | 自相关性高、日/周规律明显 | 批处理任务、ETL 作业 | 按时间窗口调度，利用 Spot 实例 |
| 空闲型 | 均值极低、长时间无活动 | 开发环境、Sidecar 代理 | 缩容至零或使用共享资源池 |
建模输出示例：一个典型的 Web 服务 Pod 画像可能为：CPU 均值 120m、P99 450m、标准差 85m、自相关系数 0.12（无周期），归类为“突发型”。该画像将直接用于计算该 Pod 在 GitOps 同步窗口期间所需的额外资源预留。
4.3 资源画像的存储与更新策略
资源画像不是静态数据，需要持续更新以反映负载变化。推荐采用以下存储与更新策略：
- 短期画像（7 天）：存储在 Prometheus 或 Thanos 中，用于实时调度与成本分摊。
- 长期画像（30–90 天）：聚合后存入对象存储（如 S3、GCS），用于容量规划与趋势分析。
- 更新频率：每 24 小时重新计算一次画像，保留最近 3 个版本的画像快照，支持回滚对比。
4.4 资源画像与 GitOps 同步窗口的关联
在 GitOps 工作流中，同步窗口期间会触发大量 Pod 重建与配置变更。资源画像在此场景中的核心作用包括：
- 预计算同步开销：根据画像中的峰值特征，预估同步窗口期间需要额外分配的 CPU/内存资源量。
- 避免资源争抢：识别突发型 Pod，在同步窗口前为其预留资源，避免与稳态型 Pod 争抢。
- 成本分摊校准：将同步窗口期间的资源消耗单独标记，分摊到对应的 GitOps 变更请求（Commit/PR）上。
4.5 资源画像的验证与校准
资源画像的准确性直接影响成本分摊与调度决策。建议建立以下验证机制：
- 回测验证：使用过去 7 天的实际资源使用数据，验证画像预测的 P95 误差是否在 ±15% 以内。
- A/B 对比：选取 10% 的 Pod 应用新画像策略，对比资源利用率与成本分摊偏差。
- 人工审计：每周由 SRE 团队抽查 5–10 个高成本 Pod 的画像标签，确认模式分类是否合理。
常见陷阱：不要仅依赖均值进行资源画像。在 GitOps 同步窗口场景中，突发型 Pod 的 P99 峰值往往是均值 3–5 倍，忽略峰值会导致同步期间资源不足，引发级联故障。
4.6 小结：资源画像在课程中的定位
本章建立的资源画像体系是后续章节的数据基石：
- 第 5 章将基于画像中的统计特征，设计成本分摊权重算法。
- 第 6 章将利用模式分类结果，优化 GitOps 同步窗口的资源预留策略。
- 第 7 章将展示如何将画像数据写入 Prometheus 自定义指标，实现实时成本监控。