2. Kubernetes 资源模型基础：Request 与 Limit 的核心概念
在 Kubernetes 集群中，Pod 是调度的最小单元，但真正决定 Pod 能否被调度、能否稳定运行的底层机制，是 资源模型。Kubernetes 通过 Request 与 Limit 两个核心参数，定义了容器对 CPU 和内存的“最低保障”与“最高上限”。理解这两个参数，是诊断资源配额超限、LimitRange 冲突以及调度亲和性问题的前提。
2.1 Request 与 Limit 的定义与作用
| 参数 | 语义 | 调度影响 | 运行时影响 |
|---|---|---|---|
| Request | 容器启动时保证分配的最小资源量 | 调度器根据所有 Pod 的 Request 总和，判断节点是否满足资源容量 | cgroup 保证该容器至少获得 Request 量的 CPU 时间片与内存 |
| Limit | 容器运行时允许使用的最大资源上限 | 不影响调度决策（仅影响 QoS 等级） | cgroup 硬限制：CPU 使用超过 Limit 会被节流，内存超过 Limit 会触发 OOM Kill |
关键原则：Request ≤ Limit。当 Request = Limit 时，容器属于 Guaranteed QoS 等级；当 Request < Limit 时，属于 Burstable 等级；当两者均未设置时，属于 BestEffort 等级。
2.2 CPU 与内存的资源单位
- CPU：以 cores 为单位，支持小数与整数。1 CPU = 1 个 vCPU / 1 个 Hyperthread。常用单位：
100m（100 millicores = 0.1 核）、500m、1、2。 - 内存：以 bytes 为单位，支持二进制与十进制后缀。常用单位：
128Mi（128 Mebibytes）、1Gi、512Mi、2Gi。
常见误区：CPU 的
1000m 等于 1 核，但 1m 是最小调度单位。内存的 1G（Gigabyte）与 1Gi（Gibibyte）存在约 7% 的差异，Kubernetes 默认使用二进制单位（Mi/Gi），请勿混用。
2.3 Request 与 Limit 的调度与运行时行为
下图展示了从 Pod 提交到节点运行的全流程中，Request 与 Limit 分别在调度阶段和 cgroup 阶段的作用位置：
2.4 典型配置示例
以下是一个包含两个容器的 Pod 定义，展示了 CPU 与内存的 Request/Limit 配置方式：
apiVersion: v1
kind: Pod
metadata:
name: resource-demo
spec:
containers:
- name: app
image: nginx
resources:
requests:
cpu: "500m" # 保证 0.5 核
memory: "256Mi" # 保证 256 MiB
limits:
cpu: "1" # 上限 1 核
memory: "512Mi" # 上限 512 MiB
- name: sidecar
image: alpine
resources:
requests:
cpu: "100m"
memory: "64Mi"
limits:
cpu: "200m"
memory: "128Mi"
最佳实践：生产环境中，建议始终为每个容器同时设置 Request 和 Limit。对于延迟敏感型应用，保持 Request = Limit（Guaranteed QoS）；对于批处理或弹性负载，可设置 Request < Limit（Burstable QoS），允许突发使用空闲资源。
2.5 资源超限的典型场景
- CPU 节流：容器 CPU 使用超过 Limit 时，cgroup 会限制其 CPU 时间片，导致应用响应变慢、延迟抖动。
- 内存 OOM Kill：容器内存使用超过 Limit 时，内核直接杀死容器进程（OOM Killer），Pod 状态变为
OOMKilled。 - 调度失败：节点上所有 Pod 的 Request 总和超过节点容量时，新 Pod 处于
Pending状态，调度器报Insufficient cpu或Insufficient memory。 - LimitRange 冲突：当命名空间配置了 LimitRange 策略，而 Pod 的 Request/Limit 不在允许范围内时，Pod 创建被拒绝。