在K8S中，Requests 和 Limits 如何影响 Pod 的调度?

在 Kubernetes 中，Requests（请求）和 Limits（限制） 是资源管理的关键机制，它们直接影响 Pod 的调度行为、节点资源分配以及运行时稳定性。以下是它们如何影响 Pod 调度的详细分析：

---

核心概念

类型	作用	调度影响
Requests	定义 Pod 最低需要的资源量（调度保证）	✅ 决定 Pod 能否被调度到节点（硬性条件）
Limits	定义 Pod 最多可使用的资源量（运行时约束）	❌ 不影响调度（调度器不考虑 Limits），但影响运行时稳定性（如 OOMKilled）

---

调度器如何工作？

Kubernetes 调度器（kube-scheduler）在调度 Pod 时只考虑 Requests，具体流程如下：

graph TD A[新 Pod 创建] --> B{调度器筛选节点} B --> C[检查节点剩余资源 ≥ Pod 的 Requests] C --> D[满足条件?] D -->|是| E[将 Pod 绑定到节点] D -->|否| F[标记节点不可用]

关键步骤：

1. 节点资源计算：
   调度器维护每个节点的 可分配资源（Allocatable）：
   可分配资源 = 节点总资源 - Kubelet/系统预留 - 已调度 Pod 的 Requests 总和
   注：已调度 Pod 的 Limits 不参与计算！

2. Requests 作为调度依据：

   • 调度器检查节点剩余资源是否满足 Pod 中所有容器的 Requests 总和。
   • 若不满足（例如 CPU Requests 或内存 Requests 不足），节点被排除。

3. 示例：
   假设节点有 1 CPU 可分配：

   • Pod A 设置 requests: {cpu: 0.8} → 可调度（剩余 0.2 CPU）
   • Pod B 设置 requests: {cpu: 0.3} → 不可调度（0.3 > 0.2）
     即使 Pod B 的 limits: {cpu: 1.5} 允许超用，调度仍失败！

---

不同资源类型的影响

1. CPU 资源

• Requests：
  • 调度器保证节点预留指定量的 CPU 时间片。
  • 若节点 CPU 资源不足，Pod 无法调度。
• Limits：
  • 运行时约束：容器 CPU 使用量可突破 Requests，但不超过 Limits。
  • 不影响调度（CPU 是可压缩资源，超限时会被内核限流）。

2. 内存资源

• Requests：
  • 调度器保证节点预留指定量的物理内存。
  • 若节点内存不足，Pod 无法调度。
• Limits：
  • 运行时约束：容器内存使用量超过 Limits 时会被 OOMKilled（内存不足终止）。
  • 不影响调度（但实际内存超售可能导致节点不稳定）。

---

调度失败常见原因

1. 节点资源不足：

   kubectl describe pod <pod-name> | grep -A 10 Events
   

   错误消息：
   0/X nodes are available: X Insufficient cpu, X Insufficient memory.

2. 资源碎片化：
   节点剩余资源分散，无法满足单个大 Requests 的 Pod（如：节点剩 1.5 CPU，但无连续 1 CPU 满足大 Pod）。

3. 未设置 Requests：

   • 若 Pod 未指定 Requests，默认值为 0 → 可能调度到资源紧张的节点。
   • 风险： 节点资源耗尽时，该 Pod 可能被驱逐（低优先级）。

---

最佳实践与配置策略

1. 合理设置 Requests

• 原则：
  • 最小值：保证应用稳定运行所需资源（如 JVM 需预留堆内存）。
  • 最大值：避免浪费（通常设置为平均使用量的 120-150%）。
• 示例：

  resources:
    requests:
      cpu: "0.5"    # 0.5 核
      memory: "512Mi" 
    limits:
      cpu: "1"      # 最多使用 1 核
      memory: "1Gi"  # 超过 1GiB 会被 OOMKilled
  

2. Limits 与 Requests 的比例

• 无状态服务：
  可设置 limits > requests（如 limits.cpu = 2 * requests.cpu），允许突发流量。
• 有状态服务（如数据库）：
  建议 limits = requests，避免资源竞争导致性能抖动。

3. 使用 QoS 类别优化调度

Kubernetes 基于 Requests/Limits 自动分配 QoS 等级：

QoS 等级	条件	调度与驱逐优先级
Guaranteed	所有容器设置 limits=requests	✅ 最高（最后被驱逐）
Burstable	至少一个容器设置 requests < limits	⚠️ 中等
BestEffort	未设置 requests/limits	❌ 最低（最先被驱逐）

策略： 关键服务设置为 Guaranteed 确保资源保障。

---

高级调度技巧

1. 资源超售（谨慎使用）

• 场景： 集群整体利用率低，允许适度超售。
• 方法：
  • 设置 limits > requests（如 CPU limits 是 requests 的 2 倍）。
  • 使用 Vertical Pod Autoscaler (VPA) 自动调整 Requests/Limits。

2. 拓扑分布约束

结合资源请求与拓扑分布，优化高可用：

spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
  resources:
    requests:
      cpu: "1"

---

总结：Requests vs Limits 对调度的影响

特性	Requests	Limits
是否影响调度	✅ 是（决定 Pod 能否分配到节点）	❌ 否
调度器计算依据	节点剩余资源 ≥ Pod Requests 总和	不参与计算
关键错误	Insufficient cpu/memory	OOMKilled（运行时）
资源配置建议	按应用基线设置	按峰值容量设置
超售风险	过度超售导致调度失败	过度超售导致节点不稳定

⚠️ 核心结论：

• Requests 是调度通行证：决定 Pod 能否获得节点资源席位。
• Limits 是运行时护栏：防止 Pod 过度消耗资源导致节点故障。
• 未设置 Requests 等同于 requests=0，可能导致调度到超售节点！