4. 容器资源画像：Pod 级别的资源请求与限制分析

在云原生环境中，Pod 是调度的最小单元，也是成本核算的原子粒度。资源画像的核心在于分析 Request（请求）、Limit（限制） 与 实际使用率 三者之间的差距。过度配置（Over-provisioning）导致资源闲置浪费，配置不足（Under-provisioning）则引发性能抖动与稳定性风险。本节将建立 Pod 级别的量化分析方法，帮助团队精准定位成本优化空间。

4.1 核心概念与三值模型

Kubernetes 通过以下三个关键指标定义 Pod 的资源行为：

4.2 过度配置 vs 配置不足：量化差距

通过引入 申请率（Requested Ratio） 与 使用率（Utilization Ratio） 两个指标，可以量化 Pod 的资源效率：

• 申请率 = Request / 节点容量（反映集群预留密度）
• 使用率 = Actual Usage / Request（反映资源利用效率）

根据使用率的高低，可将 Pod 分为以下四类画像：

4.3 Pod 资源画像分析流程

以下是一个标准化的 Pod 资源画像分析步骤，建议按周或双周周期执行：

1. 数据采集： 使用 Prometheus 或云厂商监控服务，采集 Pod 级别的 CPU 和内存实际使用率（采样间隔 ≤ 30s）。
2. 分位数计算： 计算过去 7 天的 P50、P95、P99 使用率，作为调整 Request 的参考基线。
3. 差距分析： 对比当前 Request 与 P99 使用率，计算 浪费量 = Request - P99_Usage。
4. 风险识别： 标记所有实际使用率超过 Limit 80% 的 Pod，纳入稳定性观察名单。
5. 优化执行： 对过度配置的 Pod 下调 Request，对配置不足的 Pod 上调 Request 或调整 Limit。
6. 验证闭环： 调整后观察 48 小时，确认无 OOM 或 CPU 节流事件，且使用率提升至合理区间。

4.4 资源画像可视化：从数据到决策

下图展示了单个 Pod 在 7 天内的资源使用分布，以及 Request/Limit 与实际使用率的关系。通过这种可视化，可以直观识别过度配置与配置不足的区域。

4.5 实际案例分析：一个典型的过度配置 Pod

以下是一个实际生产环境的 Pod 资源数据，通过 Prometheus 查询得到：

# 查询语句示例（PromQL）
# CPU 使用率 P99
quantile_over_time(0.99, 
  rate(container_cpu_usage_seconds_total{namespace="production", pod="web-app-7d8f9c"}[5m])[7d:1m]
)

# 内存使用率 P99
quantile_over_time(0.99,
  container_memory_working_set_bytes{namespace="production", pod="web-app-7d8f9c"}[7d:1m]
)

4.6 自动化资源画像工具链

推荐使用以下开源工具实现 Pod 资源画像的自动化分析：

• Kuberhealthy / Goldilocks： 基于 VPA 推荐算法，自动生成 Pod 的 Request 建议值，并输出过度配置评分。
• Kubecost： 提供 Pod 级别的成本分配与资源效率仪表盘，支持按命名空间、标签、控制器聚合分析。
• Prometheus + Grafana： 自定义告警规则，当 Pod 使用率持续低于 30% 或高于 85% 时触发优化建议。

下图展示了自动化资源画像工具链的架构与数据流：

4.7 避坑指南：常见误区与最佳实践