Requests和Limits如何决定Pod的调度

Kubernetes调度解密：Requests和Limits如何决定Pod的"落户"选择？

在Kubernetes集群中，每个Pod的诞生都要经历一场看不见的"选房"大战。这场战役的胜负关键，就在于我们今天要说的两位主角——Requests（资源请求）和Limits（资源限制）。它们就像Pod的"购房资格证"和"房屋面积上限"，直接决定了Pod能在哪个节点安家落户。

---

一、调度大厅的"验资"流程

当一个新的Pod出生时，调度器会带它走一遍严格的资质审核流程：

1. 验资环节（Check Requests）

   resources:
     requests:
       cpu: "800m"   # 需要0.8个CPU核心
       memory: "2Gi"  # 需要2GB内存
   

   • 调度器会扫描所有节点，计算可用资源 = 节点总资源 - 已分配Requests
   • 只允许可用资源 ≥ Pod总Requests的节点进入候选名单

2. 竞价环节（实际调度）

   • 通过初步筛选的节点进入最终PK
   • 调度器根据节点亲和性、污点容忍等策略选择最优节点

真实场景示例：
假设某节点配置为4核8GB内存，已运行Pod的总Requests为3核5GB，则该节点剩余资源为：

• 可用CPU：4 - 3 = 1核（1000m）
• 可用内存：8 - 5 = 3GB

此时申请以下资源的Pod可以调度成功：

requests:
  cpu: "800m"   # ≤ 1000m
  memory: "2Gi"  # ≤ 3Gi

---

二、Requests的三大隐藏特性

1. 资源锁定机制

   • 节点上已分配的Requests总量永远不会超过节点容量
   • 即使实际使用率很低，其他Pod也无法抢占已分配空间

2. 超卖风险区

   # 查看节点资源分配情况
   kubectl describe node <node-name>
   

   Allocated resources:
     cpu:                3800m/4000m (95%)
     memory:             6484Mi/8192Mi (79%)
   

   • 当Allocated接近100%时，新Pod将无法调度
   • 实际资源使用可能远低于分配量，造成资源浪费

3. 服务质量分级

   配置类型	QoS等级	驱逐优先级
   同时设置req+lim	Guaranteed	最低
   仅设置limits	Burstable	中等
   未设置任何限制	BestEffort	最高

---

三、Limits的运行时管控

虽然Limits不影响调度，但它像一把达摩克利斯之剑高悬在容器上方：

1. CPU的温柔限制

   limits:
     cpu: "1.5"  # 相当于1500m
   

   • 采用CFS配额机制（每100ms为一个周期）
   • 当容器试图超额使用时，会被限流（Throttling）
   • 真实影响：导致应用响应延迟增加

2. 内存的死亡红线

   limits:
     memory: "4Gi"
   

   • 超过限制立即触发OOM Killer
   • 容器会被强制终止并重启
   • 血泪教训：Java应用需预留至少300MB堆外内存

---

四、生产环境经典调度问题解析

案例1：幽灵Pod占用问题

kubectl get pods -A --field-selector=status.phase=Pending

• 现象：大量Pod处于Pending状态
• 诊断：

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

  常见错误信息：Insufficient cpu/memory
• 解决方案：
  • 调整Requests值
  • 添加新节点
  • 设置弹性伸缩（Cluster Autoscaler）

案例2：节点资源碎片化

• 现象：节点显示有剩余资源，但无法调度新Pod
• 诊断：

  kubectl describe node | grep -A 5 Allocated
  

  发现剩余500m CPU，但新Pod需要600m
• 解决方案：
  • 使用更小粒度的Requests（如改为100m为单位）
  • 启用动态资源分配（DRA）

---

五、高手都在用的调度优化技巧

1. 智能超卖策略

   # 适用于低优先级批处理任务
   resources:
     requests:
       cpu: "500m"
     limits:
       cpu: "2"
   

   • 按实际负载动态调整超卖比例
   • 配合PriorityClass实现抢占式调度

2. 拓扑感知调度

   spec:
     topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: zone
       whenUnsatisfiable: DoNotSchedule
   

   • 配合Requests实现跨可用区部署
   • 避免资源集中导致的调度瓶颈

3. 实时资源画像

   # 安装metrics-server
   kubectl top nodes
   

   NAME       CPU(cores)  CPU%   MEMORY(bytes)  MEMORY%
   node-01    1320m       33%    4543Mi         56%
   node-02    980m        24%    3921Mi         49% 
   

   • 根据实际使用率动态调整Requests
   • 配合VPA实现自动资源调优

---

六、调度专家的检查清单

当你的Pod出现调度问题时，按照这个路线图排查：

1. 资源是否充足？

   • 检查节点容量与已分配Requests
   • 查看Pending Pod的事件日志

2. 配置是否正确？

   • 确认单位使用正确（m vs 核，Mi vs Gi）
   • 检查LimitRange是否冲突

3. 约束是否合理？

   • 验证节点亲和性/反亲和性规则
   • 检查污点与容忍配置

4. 系统是否健康？

   • 确认kube-scheduler是否正常运行
   • 检查API Server的调度器配置

---

通过合理配置Requests和Limits，我们不仅能让Pod找到合适的"家"，更能让整个Kubernetes集群变成精密的资源调配系统。记住，好的调度策略就像优秀的城市规划——既要保证每个居民（Pod）的生存空间，又要实现城市（集群）资源的最大化利用。