request 是一个容器被保证得到的量（用于调度）；limit 是它不得超过的上限（在运行时强制）。二者共同决定 Pod 被放置在哪里、在压力下如何被限流或杀死，以及一个 Pod 获得哪个**服务质量（Quality of Service，QoS）**等级。
REQUEST → 为容器预留的量。SCHEDULER 用 request 之和
来判断某个 node 是否有空间。这是你被保证的下限。
LIMIT → 容器可用的最大值。在运行时强制：
CPU 超过 limit → 被限流（放慢，不杀死）
内存超过 limit → 被 OOM 杀死（容器终止，然后重启）
spec:
containers:
- name: app
image: myapp:1.0
resources:
requests:
cpu: "250m" # 0.25 个核，被保证
memory: "256Mi"
limits:
cpu: "500m" # 可突发到 0.5 个核，然后被限流
memory: "512Mi" # 超过它 → OOMKilled
node 有 4 CPU / 8Gi 可分配。
scheduler 把已放置 Pod 的 REQUEST 求和；只有当一个新 Pod 的
request 仍能装进剩余量时它才放得下。（limit 不用于放置。）
→ request 设得太低 → node 被超额分配，Pod 争抢资源。
→ request 设得太高 → 浪费容量，Pod 卡在 Pending（放不下）。
Guaranteed → cpu 和 memory 的 request == limit（每个容器都是）
→ 最后被驱逐（优先级最高）
Burstable → 有 request 但它们 < limit（或只部分设置）
→ 在 BestEffort 之后被驱逐
BestEffort → 完全没有 request 或 limit
→ node 内存不足时最先被驱逐
kubectl describe pod app | grep -i qos # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods # 实际 CPU/内存使用
kubectl describe node <node> # 已分配资源 vs 容量
✓ 对关键应用，始终把内存 request 设为等于 limit，以获得可预测、OOM 安全的行为
✓ 把 CPU request 设为稳态需求；CPU limit 常常留空以允许突发
✓ 依据真实使用（kubectl top / metrics）合理设定大小 —— 而非靠猜
✓ 用 LimitRange / ResourceQuota 在每个 namespace 强制合理的默认值
request 和 limit 是 Kubernetes 公平、可预测地共享有限 node 资源的方式，因此理解这个区别及其后果是必备的性能与可靠性知识。核心洞见是它们服务于不同目的：request 是一个被保证的预留，scheduler 用它来放置 Pod（把 request 求和判断 node 是否有空间，忽略 limit），而 limit 是在运行时强制的上限，对不同资源强制方式不同——超过 CPU limit 会被限流（放慢），但超过内存 limit 会让容器被 OOM 杀死并重启。把 request 设错两边都有真实代价：太低则 node 被超额分配、Pod 互相饿死；太高则容量被浪费、Pod 因放不下而卡在 Pending。三个 QoS 等级——Guaranteed（request 等于 limit）、Burstable（request 低于 limit）和 BestEffort（什么都没设）——决定内存压力下的驱逐顺序，BestEffort 最先被杀、Guaranteed 最后，这正是你保护关键 workload 所需理解的。掌握实用建议（对关键应用把内存 request 设为等于 limit，依据 kubectl top 的真实使用合理设定大小，用 LimitRange/ResourceQuota 强制默认值）把这从理论变成稳健的容量规划。由于资源配置错误是真实集群中不稳定、开销浪费和 Pending Pod 最常见的原因之一，精通 request、limit 和 QoS 是在 Kubernetes 上运行高效、稳定 workload 的基础。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠