Request deep dive

问题

在k8s的pod里配置了cpu/mem request, 实际在pod运行中，如果使用不到对应的cpu/mem，节点也会把对应的cpu/mem给这个pod预留好么？

先说结论：是的，节点会预留对应的资源，即使 Pod 实际没用到。 requests 是"承诺”，节点必须兑现，即使 Pod 不用。

核心机制

Request = 资源预留（保证）！

resources:
  requests:
    cpu: "1000m"      # 预留 1 核 CPU
    memory: "1Gi"     # 预留 1GB 内存
  limits:
    cpu: "2000m"      # 最多用 2 核
    memory: "2Gi"     # 最多用 2GB

调度时：

  • Kubernetes 调度器检查节点可分配资源
  • 如果节点剩余资源 < Pod requests，调度失败（Pending）
  • 调度成功后，节点标记这些资源为"已分配”

运行时：

  • ✅ CPU/内存已预留，其他 Pod 无法使用
  • ❌ 即使 Pod 实际只用 10% CPU，剩余 90% 也不会分配给其他 Pod
  • ✅ Pod 可以超过 requests 使用（直到 limits）

实例场景：节点有 4 核 CPU

# 节点总资源
Total CPU: 4000m

# Pod A 配置
requests.cpu: 2000m
实际使用: 500m  (只用了 25%)

# 节点状态
已分配: 2000m (给 Pod A)
可用: 2000m
浪费: 1500m (Pod A 预留但未用)

此时：

  • 新 Pod B 如果 requests.cpu = 2500m → 调度失败（虽然实际只用了 500m）
  • 新 Pod C 如果 requests.cpu = 1500m → 调度成功

为什么这样设计呢，是为了避免资源争抢

如果不预留，会有这样一种场景：

  • 10 个 Pod 都声称需要 1 核
  • 节点只有 4 核
  • 运行时全部争抢 → 性能下降

常见浪费场景

# 开发环境过度配置
requests:
  cpu: "2000m"      # 预留 2 核
  memory: "4Gi"     # 预留 4GB

# 实际使用
实际 CPU: 100m (5%)
实际内存: 500Mi (12%)

# 浪费
CPU: 1900m
内存: 3.5Gi

优化建议

先查看 Pod 实际使用

kubectl top pod <pod-name>

对比 requests， 合理设置 requests。推荐：根据实际使用 + 20% buffer：

resources:
  requests:
    cpu: "120m"      # 实际用 100m
    memory: "600Mi"  # 实际用 500Mi
  limits:
    cpu: "500m"      # 允许突发
    memory: "1Gi"    # 防止 OOM

总结

维度 说明
预留 ✅ 节点会预留 requests 的资源
实际使用 可能远低于 requests
其他 Pod ❌ 无法使用已预留但未用的资源
优化 监控并调整 requests