4. 资源画像基础：容器资源请求与限制（Requests/Limits）、CPU与内存资源模型、Pod QoS分类
在云原生成本分摊模型中，资源画像是连接基础设施消耗与业务成本的桥梁。本章聚焦 Kubernetes 资源调度的三个核心概念：Requests/Limits、CPU/内存资源模型以及Pod QoS 分类。理解这些基础是后续实现精准成本分摊的前提。
4.1 资源请求（Requests）与限制（Limits）
Kubernetes 通过 requests 和 limits 两个字段控制容器对节点资源的占用行为：
| 属性 | 语义 | 调度影响 | 资源竞争行为 |
|---|---|---|---|
| Requests | 容器保证能获取的最小资源量 | 调度器依据 requests 选择节点 |
节点资源充足时，容器可超用至 limits |
| Limits | 容器允许使用的最大资源上限 | 不影响调度决策 | CPU 限流（throttle），内存超限触发 OOM Kill |
成本分摊关键点：成本模型通常基于
requests 进行资源预留计费，因为 requests 决定了节点上不可被其他 Pod 占用的“预留容量”。超用部分（burst）按实际使用量额外计费。
4.2 CPU 与内存资源模型
CPU 和内存的资源模型在可压缩性和回收机制上存在本质差异，直接影响成本分摊策略：
- CPU（可压缩资源）：单位
m（毫核），1000m = 1 核。超限时通过 CFS 配额进行限流（throttle），容器不会被杀掉，但性能会下降。 - 内存（不可压缩资源）：单位
Mi、Gi。超限时内核 OOM Killer 会直接终止容器进程，属于硬性边界。
成本分摊差异：CPU 成本可按“预留 + 实际使用”混合模型分摊；内存成本必须严格按
limits 或 requests 上限分摊，因为超用会导致不可恢复的故障。
4.3 Pod QoS 分类
Kubernetes 根据 Pod 内所有容器的 requests 和 limits 配置，自动将 Pod 归入三种 QoS（服务质量）类别。QoS 决定了节点资源紧张时的驱逐优先级，也是成本分摊模型中风险权重的重要因子。
| QoS 类别 | 配置条件 | 驱逐优先级 | 成本分摊含义 |
|---|---|---|---|
| Guaranteed | 所有容器 requests == limits（CPU 和内存均需设置） |
最低（最不易被驱逐） | 资源预留明确，成本可精确归属 |
| Burstable | 至少一个容器 requests < limits 或仅设置 requests |
中等 | 存在超用风险，成本需考虑 burst 因子 |
| BestEffort | 所有容器均未设置 requests 和 limits |
最高（最先被驱逐） | 无资源保证，成本分摊需按实际使用量估算 |
生产环境建议：避免使用 BestEffort 类 Pod 承载关键业务。在成本分摊模型中，BestEffort Pod 通常需要额外增加“不稳定系数”来反映其高驱逐风险带来的隐性成本。
4.4 资源模型与 QoS 关系图
下图展示了从容器资源声明到 Pod QoS 分类的完整映射关系，以及不同 QoS 在节点资源竞争时的行为差异：
4.5 资源画像在成本分摊中的实践要点
- Requests 是成本基线：节点上所有 Pod 的
requests总和决定了节点资源的“已售出”容量，是成本分摊的基准分母。 - Limits 是风险上限：内存
limits超限会导致 OOM，成本模型中需为 Burstable Pod 预留“超用风险准备金”。 - QoS 影响权重：Guaranteed Pod 的成本权重为 1.0；Burstable Pod 建议权重 1.1~1.3；BestEffort Pod 建议权重 1.5~2.0（含驱逐重建成本）。
- 监控数据校准：结合 Prometheus 容器指标（
container_cpu_usage_seconds_total、container_memory_working_set_bytes）验证requests设置是否合理，避免资源浪费。
成本分摊公式示例：
对于 Burstable Pod，可在上述公式基础上乘以
Pod 成本 = (CPU_requests / 节点总CPU_requests) × 节点CPU成本 + (Mem_requests / 节点总Mem_requests) × 节点内存成本对于 Burstable Pod，可在上述公式基础上乘以
QoS 权重因子。