Kubernetes 中 requests 和 limits 的区别是什么，QoS 如何划分？

结论：requests 是调度依据——调度器按它选节点、保证资源；limits 是运行上限——CPU 超限被节流（throttle），内存超限触发 OOMKill。两者组合决定 Pod 的 QoS 等级：Guaranteed、Burstable、BestEffort。

展开：QoS 划分：所有容器 requests==limits 是 Guaranteed；都没设是 BestEffort；其余是 Burstable。节点资源紧张（驱逐）时按 BestEffort → Burstable → Guaranteed 顺序杀 Pod，所以核心服务应配 Guaranteed 或至少 requests 充分的 Burstable。关键认知：1）CPU 是可压缩资源，超 limits 只是降速不杀进程，但 throttle 会造成延迟毛刺，对延迟敏感服务常见做法是 requests==limits 或干脆不设 CPU limit；2）内存不可压缩，超 limit 直接 OOMKill，limits 要留有余量；3）requests 设得过高浪费资源（节点利用率低）、过低造成超卖，节点上 Pod 争抢 CPU 时按 requests 比例分配。生产建议：requests 按 P95 实际用量定，配 VPA 或定期校准；命名空间用 ResourceQuota 控总量、LimitRange 设默认值，防止漏配 requests 的 Pod 拖累调度。追问方向：驱逐阈值 eviction-hard 与节点压力驱逐机制。