3. 容器运行时资源模型：CPU请求与限制、内存请求与限制、QoS类别
在Kubernetes集群中，Pod是调度的最小单元，而容器是资源隔离与限制的最小边界。理解容器运行时资源模型是进行容量调优、SLO治理与错误预算计算的基础。本章将深入剖析CPU与内存的请求（Requests）与限制（Limits）语义，以及由此衍生出的三种QoS（Quality of Service）类别。
3.1 CPU资源：请求与限制
CPU是可压缩资源，意味着当容器超出其限制时，系统会通过节流（Throttling）而非杀死进程来限制其使用。CPU的计量单位可以是整数核心（1、2）或毫核（m，1000m = 1核心）。
| 属性 | 语义 | 调度影响 | 运行时行为 |
|---|---|---|---|
| requests.cpu | 容器启动时保证的最小CPU时间片 | kube-scheduler依据此值选择满足剩余资源的节点 | CFS配额保证该容器至少获得此份额 |
| limits.cpu | 容器可使用的CPU上限 | 不影响调度决策 | 超出时触发CFS节流，容器变慢但不会OOM |
最佳实践：对于延迟敏感型服务，建议将CPU requests与limits设置为相同值，避免因突发节流导致P99延迟抖动。对于批处理任务，可适当设置limits > requests以利用空闲资源。
3.2 内存资源：请求与限制
内存是不可压缩资源。当容器尝试分配超过limits.memory的内存时，内核会触发OOM Killer直接终止该容器进程。内存单位通常使用Mi、Gi或M、G。
| 属性 | 语义 | 调度影响 | 运行时行为 |
|---|---|---|---|
| requests.memory | 容器启动时保证的最小内存量 | kube-scheduler依据此值选择节点 | cgroups保证该容器至少拥有此内存 |
| limits.memory | 容器可使用的内存硬上限 | 不影响调度决策 | 超出时触发OOM Kill，容器被重启 |
关键风险：如果只设置limits.memory而不设置requests.memory，Kubernetes会自动将requests设置为与limits相同的值。这可能导致节点资源利用率下降，因为调度器会按limits值预留资源。
3.3 QoS类别：Guaranteed / Burstable / BestEffort
Kubernetes根据Pod内容器的requests与limits配置组合，自动为每个Pod分配一个QoS类别。该类别决定了节点资源紧张时Pod被驱逐的优先级。
3.4 三类QoS的详细对比
| QoS 类别 | 配置条件 | 典型场景 | OOM 风险 | 驱逐优先级 |
|---|---|---|---|---|
| Guaranteed | 所有容器均设置 requests 与 limits，且两者相等 | 数据库、关键API服务、支付系统 | 低（仅当超出limits时） | 最低 |
| Burstable | 至少一个容器设置了 requests 或 limits，且不满足Guaranteed条件 | Web服务器、微服务、批处理任务 | 中等（可能因节点内存碎片触发） | 中等 |
| BestEffort | 所有容器均未设置 requests 与 limits | 开发测试、非关键日志采集、缓存预热 | 高（节点内存不足时优先被杀死） | 最高 |
3.5 资源模型对HPA与SLO的影响
在HPA面板化呈现与容量调优中，资源模型直接影响以下关键指标：
- CPU利用率指标：HPA默认使用
requests.cpu作为分母计算利用率。如果requests设置过低，即使CPU使用率很高，HPA也可能不会触发扩容。 - 内存利用率指标：内存利用率 = 实际使用量 / requests.memory。当内存使用接近limits时，OOM风险急剧上升，SLO中的错误预算将快速消耗。
- QoS与错误预算：BestEffort Pod在节点压力下被驱逐的概率远高于Guaranteed Pod，这会导致服务中断，直接消耗SLO中的错误预算。
容量调优核心原则：
- 生产环境关键服务应使用 Guaranteed QoS，设置合理的requests与limits，避免因资源竞争导致性能抖动。
- 利用HPA的
--cpu-initialization-period和--cpu-utilization-limit参数，结合requests值进行精细化扩缩容。 - 定期审计Pod的QoS分布，将非关键工作负载标记为Burstable或BestEffort，提高整体资源利用率。
3.6 典型配置示例
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
spec:
containers:
- name: app
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "500m"
limits:
memory: "512Mi"
cpu: "1000m"上述Pod中，CPU requests（500m）≠ limits（1000m），内存 requests（256Mi）≠ limits（512Mi），因此该Pod的QoS类别为Burstable。在节点内存压力下，它将在BestEffort Pod之后、Guaranteed Pod之前被驱逐。