2. K8s资源模型基础：Pod、Node、Namespace的资源抽象，Request与Limit的语义与区别
Kubernetes 的资源模型是容量规划与准入控制的基石。理解 Pod、Node、Namespace 三层的资源抽象，以及 Request 与 Limit 的语义差异，是后续进行瓶颈分析与资源优化不可或缺的前提。
2.1 三层资源抽象：Pod、Node、Namespace
Kubernetes 将资源管理抽象为三个层次，每一层解决不同维度的资源约束问题：
| 抽象层 | 资源对象 | 核心作用 | 容量规划关注点 |
|---|---|---|---|
| Pod 层 | Pod（容器组） | 定义单个工作负载的资源需求与上限 | 容器级 CPU/Memory 的 Request 与 Limit |
| Node 层 | Node（节点） | 提供物理/虚拟机的总资源池 | 节点可分配容量、系统预留、驱逐阈值 |
| Namespace 层 | Namespace（命名空间） | 多租户资源配额与隔离边界 | ResourceQuota 与 LimitRange 策略 |
容量规划视角： Pod 层决定“每个实例要多少资源”，Node 层决定“集群能放多少实例”，Namespace 层决定“租户间如何公平分配”。三层必须协同配置，缺一不可。
2.2 Request 与 Limit 的语义与区别
Request 和 Limit 是 Pod 资源规格中最核心的两个字段，它们的语义差异直接影响调度决策与运行时行为。
2.2.1 核心语义对比
| 属性 | Request（请求） | Limit（限制） |
|---|---|---|
| 调度依据 | Kube-scheduler 根据所有 Pod 的 Request 总和决定节点能否容纳新 Pod | 不参与调度决策 |
| CPU 行为 | 保证 Pod 至少获得 Request 量的 CPU 时间（CFS 配额） | Pod 最多使用 Limit 量的 CPU，超限时被节流（throttle） |
| Memory 行为 | 保证 Pod 至少获得 Request 量的内存 | Pod 最多使用 Limit 量的内存，超限时触发 OOM Kill |
| QoS 等级 | 决定 Pod 的 QoS 类别（Guaranteed / Burstable / BestEffort） | 与 Request 共同决定 QoS 类别 |
| 超卖风险 | 低（Request 是硬承诺） | 高（Limit 可远大于 Request，造成节点资源争抢） |
2.2.2 QoS 等级与资源保障
Request 与 Limit 的组合方式决定了 Pod 的 QoS（服务质量）等级，进而影响节点资源不足时的驱逐优先级：
- Guaranteed（保证级）： 每个容器 Request == Limit，且不为 0。优先级最高，最晚被驱逐。
- Burstable（可突发级）： 至少一个容器 Request < Limit，或 Request 未设置但 Limit 已设置。中等优先级。
- BestEffort（尽力而为级）： 所有容器均未设置 Request 和 Limit。优先级最低，最先被驱逐。
常见误区： 将 Request 设得过低而 Limit 设得过高，虽然能提高节点装箱率，但会大幅增加 Burstable Pod 被驱逐的风险。容量规划时应根据实际负载特征合理设置 Request/Limit 比例，通常建议 CPU 比例 1:1~1:2，Memory 比例 1:1~1:1.5。
2.3 资源抽象与调度关系图
下图展示了 Pod、Node、Namespace 三层资源抽象如何协同工作，以及 Request/Limit 在调度与运行时的作用路径：
2.4 资源模型配置示例
以下是一个典型的生产级 Pod 资源定义，展示了 Request 与 Limit 的合理配置方式：
apiVersion: v1
kind: Pod
metadata:
name: web-app-pod
namespace: production
spec:
containers:
- name: web-app
image: nginx:1.25
resources:
requests:
cpu: "500m" # 保证 0.5 核 CPU
memory: "256Mi" # 保证 256 MiB 内存
limits:
cpu: "1000m" # 最多使用 1 核 CPU
memory: "512Mi" # 最多使用 512 MiB 内存
关键配置原则：
- Request 应基于稳态负载： 取过去 7 天 P50 或 P75 分位的资源使用量。
- Limit 应基于峰值容忍度： 通常为 Request 的 1.5~2 倍，避免 OOM 或 CPU 节流影响业务。
- 避免设置过大的 Limit： 过大的 Limit 会导致节点资源争抢，增加驱逐风险。
2.5 Namespace 资源配额示例
通过 ResourceQuota 限制 Namespace 级别的资源总量，防止单个租户耗尽集群资源：
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
requests.cpu: "10" # 该 Namespace 所有 Pod 的 CPU Request 总和不超过 10 核
requests.memory: "20Gi" # 该 Namespace 所有 Pod 的 Memory Request 总和不超过 20Gi
limits.cpu: "20" # 该 Namespace 所有 Pod 的 CPU Limit 总和不超过 20 核
limits.memory: "40Gi" # 该 Namespace 所有 Pod 的 Memory Limit 总和不超过 40Gi
pods: "50" # 该 Namespace 最多运行 50 个 Pod
容量规划最佳实践： 在创建 Namespace 时即配置 ResourceQuota 和 LimitRange，结合准入控制器（如
ResourceQuota 和 LimitRanger）强制约束，从源头避免资源滥用。这是后续章节“准入控制协同优化”的核心前置条件。
2.6 资源抽象与准入控制关系图
下图展示了资源模型如何与准入控制链交互，形成从定义到执行的完整闭环：
2.7 本章小结
- 三层抽象： Pod 定义资源需求，Node 提供资源容量，Namespace 实施配额隔离。
- Request 是调度承诺： 保证 Pod 获得最低资源，决定调度可行性。
- Limit 是运行时上限： 防止 Pod 过度使用资源，超限时触发节流或 OOM。
- QoS 等级： 由 Request/Limit 组合决定，直接影响驱逐优先级。
- 准入控制： 通过 LimitRanger 和 ResourceQuota 在 Pod 创建时强制校验和注入，是容量治理的第一道防线。