3. 容器资源请求与限制（Requests & Limits）：CPU/Memory 的过量分配策略、QoS 等级对成本的影响
在云原生环境中，容器资源请求（Requests）与限制（Limits）是成本分摊与性能调优的核心杠杆。错误的配置不仅会导致资源碎片化或节点过载，还会直接影响 Pod 的服务质量（QoS）等级，进而改变调度策略与抢占行为。本章将深入剖析 CPU/Memory 的过量分配策略，并量化不同 QoS 等级对集群成本的影响。
3.1 Requests 与 Limits 的语义与调度机制
Kubernetes 调度器使用 Requests 作为资源预留的基准，而 Limits 则用于控制资源使用的上限。两者的组合决定了 Pod 在节点上的“资源合同”。
| 参数 | CPU 语义 | Memory 语义 | 调度影响 |
|---|---|---|---|
| Requests | 保证的最小 CPU 时间片（CFS 配额） | 保证的最小内存空间（不可回收） | 调度器依据节点剩余可分配资源（Allocatable - ΣRequests）进行决策 |
| Limits | CPU 使用上限（CFS 周期内配额限制） | 内存硬限制（OOM Killer 触发阈值） | 不影响调度，仅影响运行时 cgroup 参数 |
关键指标： 当 Limits > Requests 时，称为“过量分配”（Overcommit）。CPU 过量分配是安全的（时间片竞争），但 Memory 过量分配可能导致 OOM 风险。
3.2 过量分配策略与成本模型
过量分配是提升集群资源利用率、降低单位 Pod 成本的核心手段。但不同资源的过量分配策略截然不同。
3.2.1 CPU 过量分配策略
- 策略： 通常设置 CPU Requests 为实际负载的基线值（如 0.5 核），Limits 设置为峰值值（如 2 核）。
- 成本收益： 假设节点有 32 核，若所有 Pod 的 Requests 总和为 24 核，则调度器认为节点已满；但实际 CPU 使用率可能仅为 40%，剩余 60% 的算力被“超卖”给 Burstable Pod。
- 风险控制： 必须配合 CPU Manager 的静态策略（Static Policy）来保证 Guaranteed Pod 的独占性，避免 Burstable Pod 干扰关键业务。
3.2.2 Memory 过量分配策略
- 策略： 强烈建议 Memory Requests == Limits，即禁止内存过量分配。
- 成本收益： 若 Memory Requests < Limits，当节点内存压力增大时，内核会优先回收 Burstable Pod 的匿名页，甚至触发 OOM Killer。这会导致 Pod 频繁重启，增加 SLO 违约成本。
- 最佳实践： 对于非关键批处理任务，可设置 Requests 为 80% 的 Limits，但必须配置合理的
evictionHard阈值和 PodDisruptionBudget。
避坑指南： 不要对 Memory 进行超过 1.2 倍的过量分配。Memory 是“不可压缩资源”，一旦耗尽，内核只能通过杀死进程来回收，这比 CPU 节流（Throttling）的破坏性大得多。
3.3 QoS 等级：成本与稳定性的天平
Kubernetes 根据 Requests 与 Limits 的配置关系，将 Pod 划分为三个 QoS 等级。等级越高，调度保障越强，但资源利用率越低，单位成本越高。
3.4 QoS 等级对成本分摊的量化影响
在 FinOps 实践中，不同 QoS 等级的 Pod 应使用不同的成本分摊系数。以下是一个典型的成本模型对比：
| QoS 等级 | 资源利用率（典型值） | 调度保障 | 单位 Pod 成本系数 | 适用场景 |
|---|---|---|---|---|
| Guaranteed | 30% - 50% | 最高（永不驱逐） | 1.5x - 2.0x | 数据库、消息队列、核心网关 |
| Burstable | 60% - 80% | 中等（内存压力时优先驱逐） | 1.0x（基准） | 无状态微服务、Web 应用 |
| BestEffort | 80% - 95% | 最低（最先被驱逐） | 0.3x - 0.5x | 批处理、日志聚合、CI/CD Agent |
成本优化案例： 某电商平台将 30% 的 Guaranteed Pod 调整为 Burstable（通过降低 Requests 至实际使用量的 80%），节点密度从 15 Pod/节点提升至 22 Pod/节点，月度集群成本下降 28%，同时 P99 延迟仅增加 3ms，仍在 SLO 范围内。
3.5 实战：Requests/Limits 配置模板与验证
以下是一个经过性能工程验证的配置模板，适用于高密度 Burstable 部署：
apiVersion: v1
kind: Pod
metadata:
name: cost-optimized-pod
spec:
containers:
- name: app
image: myapp:latest
resources:
requests:
memory: "512Mi" # 基线内存，基于 P50 使用量
cpu: "250m" # 基线 CPU，基于 P50 使用量
limits:
memory: "768Mi" # 峰值内存，基于 P99 使用量 + 20% 缓冲
cpu: "1" # 峰值 CPU，允许突发
# 关键：配合 PodPriority 和 PriorityClass 防止低优先级 Pod 被误杀
priorityClassName: high-priority
验证命令： 使用
kubectl describe pod <pod-name> 查看 QoS Class 字段；使用 kubectl top pod 对比实际使用量与 Requests/Limits 的差距，持续优化配置。
3.6 过量分配的风险控制与监控
过量分配必须配合以下监控指标，否则成本优化将转化为稳定性风险：
- CPU Throttling 率： 当 CPU Limits 设置过低时，容器会被强制节流。目标：Throttling 率 < 5%。
- OOM 事件频率： 当 Memory Limits 设置过低或过量分配过高时，Pod 会被 OOM Kill。目标：0 次/天。
- 节点资源压力： 监控
node_memory_MemAvailable_bytes和node_cpu_utilization，确保节点资源压力等级低于 80%。
3.7 本章小结
- Requests 决定调度成本，Limits 决定运行时风险。 合理设置 Requests 是成本分摊的基础。
- CPU 可安全过量分配（1:2 至 1:4），Memory 严禁过量分配（建议 1:1）。
- QoS 等级直接影响单位 Pod 成本系数： Guaranteed 成本最高，Burstable 是优化重点，BestEffort 仅用于临时任务。
- 必须建立监控-告警-自动调整的闭环， 否则过量分配将导致性能退化与 SLO 违约。