2. Kubernetes 资源模型基础：Pod 资源请求(Request)与限制(Limit)的定义、作用与区别

在 Kubernetes 集群中，Pod 是最小的调度与运行单元。为了让调度器（kube-scheduler）做出合理的节点选择，以及让节点上的 kubelet 对容器进行有效的资源管控，Kubernetes 为每个容器定义了两种资源规格：Request（请求） 和 Limit（限制）。这两个参数是资源画像与临时资源预留优化的基石。

2.1 核心定义

2.2 作用机制详解

2.2.1 Request 的作用

• 调度准入：调度器计算每个节点的已分配 Request 总和，只有剩余可分配资源 ≥ 新 Pod 的 Request 时，节点才会被纳入候选。
• CPU 权重分配：当节点 CPU 资源紧张时，CFS（完全公平调度器）按各容器的 CPU Request 比例分配时间片。Request 越高，获得 CPU 时间片的比例越大。
• 内存保障：kubelet 根据内存 Request 计算节点的“已分配内存”，用于驱逐决策（Eviction）。内存 Request 越高的 Pod，在节点内存压力下被驱逐的优先级越低。

2.2.2 Limit 的作用

• CPU 节流：当容器 CPU 使用量超过 Limit 时，CFS 会限制其时间片配额，导致容器进入 Throttling 状态，表现为延迟上升、吞吐下降。
• 内存硬限制：当容器内存使用量超过 Limit 时，内核会直接触发 OOM Killer，终止容器进程（通常重启 Pod）。
• 资源隔离：Limit 防止单个容器“抢占”同节点其他容器的资源，是集群稳定性的一道防线。

2.3 Request 与 Limit 的区别

2.4 资源模型与临时资源预留的关系

在 Deployment 滚动升级场景中，新 Pod 和旧 Pod 会短暂共存。此时，节点上的资源预留总量 = 旧 Pod 的 Request + 新 Pod 的 Request。如果 Request 设置过高，升级期间的临时资源预留会急剧膨胀，导致节点资源紧张甚至调度失败。理解 Request 与 Limit 的区别，是后续优化临时资源预留策略的前提。

2.5 资源模型关系图

2.6 典型配置示例

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx:latest
    resources:
      requests:
        cpu: "500m"        # 0.5 核，调度保证
        memory: "256Mi"    # 256 MiB，内存预留
      limits:
        cpu: "1000m"       # 1 核，CPU 上限
        memory: "512Mi"    # 512 MiB，内存硬限制