📚 课程目录第2章 Kubernetes资源模型基础

2. Kubernetes 资源模型基础：Pod 资源请求（Requests）与限制（Limits）的定义与区别

在 Kubernetes 集群中，Pod 是调度的最小单元，而 资源请求（Requests） 与 资源限制（Limits） 是定义 Pod 行为与保障集群稳定性的核心参数。理解两者的定义与区别，是掌握资源争抢与租户重调度测试的前提。

2.1 核心定义

参数	定义	调度影响	运行时行为
Requests（请求）	容器启动时向集群保证预留的最小资源量。Kubernetes 调度器依据此值选择满足条件的 Node。	调度决策依据：Node 必须满足所有 Pod 的 Requests 总和 ≤ Node 可分配资源。	容器至少能获得 Requests 指定的资源量，不会被其他 Pod 抢占。
Limits（限制）	容器在运行时允许使用的资源上限。超过此值时，CPU 会被限流，内存会被 OOM Kill。	不影响调度决策（除非开启 Guaranteed QoS 的特殊场景）。	容器可以突发使用超出 Requests 的资源，但不得超过 Limits。

关键认知： Requests 是“承诺”，Limits 是“天花板”。没有设置 Limits 时，容器可以无限使用 Node 空闲资源，但可能引发资源争抢。

2.2 资源维度：CPU 与内存

Kubernetes 对 CPU 和内存的处理机制存在本质差异，直接影响资源争抢的表现。

CPU（可压缩资源）： 超限时容器变慢（Throttling），但不会被杀。单位：m（毫核），1 CPU = 1000m。
内存（不可压缩资源）： 超限时容器会被 OOM Killer 终止。单位：Mi、Gi。

  实践要点： 内存 Limits 必须 ≥ Requests。如果内存使用超过 Limits，Pod 会立即被驱逐或重启，这是资源争抢测试中最常见的故障场景。

2.3 三种 QoS 类别：资源定义的直接结果

Requests 与 Limits 的组合方式决定了 Pod 的 服务质量等级（QoS），直接影响节点资源紧张时的驱逐优先级。

QoS 类别	定义条件	驱逐优先级	典型场景
Guaranteed	所有容器 Requests == Limits（且不为 0）	最低（最后被驱逐）	数据库、关键中间件
Burstable	至少一个容器 Requests < Limits，或仅设置 Requests	中等	Web 服务、批处理任务
BestEffort	所有容器未设置 Requests 和 Limits	最高（最先被驱逐）	测试、低优先级任务

租户重调度测试提示： 在资源争抢场景中，BestEffort Pod 会最先被驱逐，Burstable Pod 次之，Guaranteed Pod 最后。这是设计多租户隔离策略时必须考虑的因素。

2.4 Requests 与 Limits 的配置示例

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

上述配置表示：该容器至少保证 256Mi 内存和 0.5 核 CPU，最多可使用 512Mi 内存和 1 核 CPU。当内存超过 512Mi 时，容器会被 OOM Kill。

2.5 资源模型关系图

2.6 资源争抢场景中的行为对比

场景	CPU 争抢	内存争抢
容器使用量 ≤ Requests	完全保证，无争抢	完全保证，无争抢
Requests < 使用量 ≤ Limits	允许突发，但可能被限流	允许使用，但存在 OOM 风险
使用量 > Limits	CPU Throttling（变慢）	OOM Kill（容器重启）
未设置 Limits	可耗尽 Node 所有空闲 CPU	可耗尽 Node 所有空闲内存

  测试设计启示： 在租户重调度测试中，通过调整 Requests/Limits 比例可以精确控制 Pod 的 QoS 类别，从而验证不同优先级 Pod 在资源争抢时的驱逐顺序与重调度行为。