3. 资源模型解析：CPU与内存的Request/Limit语义、服务质量（QoS）等级、资源超卖与竞争

3.1 核心资源语义：Request 与 Limit

在 Kubernetes 资源模型中，Request 和 Limit 是容器运行时治理的基石。Request 是容器启动时向调度器承诺的“最小保障资源”，而 Limit 是容器运行时允许使用的“资源上限”。理解两者的语义差异，是进行容量调优和配额校准的前提。

属性 CPU 内存（Memory）
Request 调度依据，基于 CPU 时间片（Shares）实现，保证容器至少获得该计算能力。 调度依据，作为内存预留量，Kubelet 据此计算节点可用容量。
Limit 硬上限，通过 CFS 配额（CFS Quota）限制 CPU 时间，超过则被节流（Throttle）。 硬上限，通过 cgroup memory.limit_in_bytes 限制，超过则触发 OOM Kill。
未设置 Limit 容器可无限使用空闲 CPU，但受节点总容量限制。 容器可无限使用内存，但极易引发节点 OOM，导致 Pod 被驱逐。
超卖风险 CPU 超卖导致节流，应用响应变慢，但不会直接崩溃。 内存超卖导致 OOM Kill，应用进程直接终止，影响可用性。
关键实践： 生产环境中，建议始终为内存设置 Limit = Request，避免因内存泄漏导致节点级故障。CPU 可根据业务容忍度适当超卖（如 Limit = 2x Request），但需配合 HPA 和监控告警。

3.2 服务质量（QoS）等级：Guaranteed / Burstable / BestEffort

Kubernetes 根据 Pod 内所有容器的 Request 与 Limit 配置，自动将 Pod 划分为三个 QoS 等级。该等级决定了节点资源竞争时的驱逐优先级和资源回收顺序。

  • Guaranteed（保证级）：每个容器都设置了 Request 和 Limit，且两者相等。调度器保证资源，节点压力大时最后被驱逐。
  • Burstable（可突发级）：至少一个容器设置了 Request，且存在 Limit > Request 或未设置 Limit。允许突发使用空闲资源，但竞争时优先于 Guaranteed 被驱逐。
  • BestEffort（尽力而为级）：所有容器均未设置 Request 和 Limit。无资源保障，节点资源紧张时最先被驱逐。
QoS 等级判定规则： 
# Guaranteed 示例
resources:
  requests:
    cpu: "1"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "1Gi"

# Burstable 示例（Limit > Request）
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

# BestEffort 示例（无 resources 字段）
# 或 resources 字段为空
QoS 等级驱逐优先级与资源竞争关系 QoS 等级驱逐优先级与资源竞争关系 Guaranteed Request == Limit Burstable Limit > Request BestEffort 无 Request / Limit 驱逐优先级：BestEffort > Burstable > Guaranteed 节点资源竞争时的行为 • 节点内存不足时：BestEffort 最先被驱逐，释放内存 • 若仍不足：驱逐 Burstable Pod（按优先级排序） • 最后才驱逐 Guaranteed Pod（仅当节点处于系统 OOM 状态） • CPU 竞争时：Guaranteed 获得完整时间片，Burstable 被节流

3.3 资源超卖与竞争机制

资源超卖（Overcommit）是提升集群利用率的核心手段，但也是导致资源竞争和稳定性风险的根源。Kubernetes 通过 QoS 等级 和 cgroup 层级 实现资源竞争时的优先级调度。

3.3.1 CPU 超卖与节流

当节点上所有 Pod 的 CPU Request 总和超过节点总 CPU 容量时，即发生 CPU 超卖。Kubernetes 使用 CFS（Completely Fair Scheduler）按权重分配 CPU 时间片：

  • 每个 Pod 的 CPU Shares = 其 CPU Request 值（以 millicores 计）。
  • 调度器按 Shares 比例分配 CPU 时间。Guaranteed Pod 获得完整保障，Burstable Pod 在空闲时获得额外时间，BestEffort Pod 仅获得剩余时间。
  • 当 CPU 满载时，Limit 通过 CFS Quota 强制限制 Burstable 和 BestEffort 的 CPU 使用上限。

3.3.2 内存超卖与 OOM Kill

内存超卖比 CPU 超卖更危险，因为内存不可压缩。当节点内存使用超过总容量时，内核 OOM Killer 介入：

  • OOM Killer 根据 oom_score 选择进程杀死。oom_score 由 QoS 等级和内存使用量决定。
  • BestEffort Pod 的 oom_score 最高，Guaranteed Pod 最低。
  • 即使 Guaranteed Pod 设置了 Limit，若节点内存耗尽，仍可能被 OOM Kill（概率极低）。
容量调优警告： 内存超卖比例建议控制在 1.2x 以内（即所有 Pod Request 总和 ≤ 节点内存的 120%）。超过此比例，节点 OOM 概率显著上升，且 Burstable Pod 的稳定性无法保证。建议为关键业务 Pod 设置 Guaranteed QoS。
资源超卖与竞争流程 资源超卖与竞争流程 节点资源池（CPU + Memory） Guaranteed Pod Request = Limit 资源保障：100% Burstable Pod Limit > Request 资源保障：部分 BestEffort Pod 无 Request/Limit 资源保障：无 竞争结果与调优建议 • CPU 竞争：Guaranteed 获得完整时间片，Burstable 被节流，BestEffort 几乎无时间 • 内存竞争：BestEffort 最先 OOM Kill，Burstable 次之，Guaranteed 最后 • 调优策略：关键业务用 Guaranteed，批处理用 Burstable，测试用 BestEffort

3.4 容量调优与配额校准实践

基于上述资源模型，容器运行时治理的容量调优应遵循以下步骤：

  1. 基线采集：通过 Prometheus 等监控工具，采集业务 Pod 在峰值和低谷期的 CPU 和内存实际使用量。
  2. Request 校准：将 Request 设置为 P99 或 P95 的实际使用量，避免过度预留。
  3. Limit 设置：内存 Limit = Request（禁止超卖）；CPU Limit 可设为 Request 的 1.5~2 倍（允许突发）。
  4. QoS 规划：核心服务（如 API Gateway、数据库）使用 Guaranteed；中间件（如消息队列）使用 Burstable；离线任务（如数据清洗）使用 BestEffort。
  5. 超卖比例控制：CPU 超卖比例 ≤ 3x，内存超卖比例 ≤ 1.2x，并配置 PodDisruptionBudget 保护关键服务。
配额校准检查清单： 
1. 所有生产 Pod 是否都设置了 Request 和 Limit？
2. 内存 Limit 是否等于 Request？（避免 OOM 风险）
3. 关键业务 Pod 是否为 Guaranteed QoS？
4. 节点 CPU 超卖比例是否 ≤ 3x？
5. 节点内存超卖比例是否 ≤ 1.2x？
6. 是否配置了 HPA 基于实际利用率自动扩缩？
← 上一章 📖 返回目录 下一章 →