K8s 三种 QoS 等级 & 与 Resources（requests/limits）的核心关联
先一句话总结：K8s 的 Guaranteed、Burstable、BestEffort 三种 QoS，完全由 Pod 容器的 ** resources.requests ** 和 ** resources.limits ** 配置规则自动决定 ，不是手动指定标签，是靠资源配置自动划分，进而决定调度优先级、OOM 打分、驱逐被杀顺序。
一、先明确 Resources 两个核心字段
-
requests ：Pod 申请最少需要多少资源（调度用，节点剩余资源够 requests 才会调度）
-
limits ：Pod 允许使用最大资源上限（超了会被限流/杀掉）
二、三种 QoS 对应的资源配置规则
1. Guaranteed（最高优先级）
资源配置条件：
Pod 里所有容器 ，CPU 和内存都同时配置了 requests 和 limits ，且 requests = limits。
关联点：
-
资源配额固定，不超量占用节点资源
-
节点资源紧张时最后被驱逐、最后被OOM杀死
-
适合核心业务、数据库、中间件等不能随便挂的应用
2. Burstable（中等优先级）
资源配置条件：
不满足 Guaranteed，且至少有一个容器配置了 CPU 或内存的 requests（或 limits）。
常见两种情况：
-
配了 requests 没配 limits
-
requests ≠ limits
-
部分容器配了资源、部分没配
关联点：
-
有基础资源申请，调度会考虑资源
-
可以弹性超用到 limits 上限；没设 limits 就可占用节点空闲资源
-
资源不足时，优先级低于 Guaranteed、高于 BestEffort，中间被驱逐
3. BestEffort（最低优先级）
资源配置条件：
Pod 里所有容器都完全不配置 requests 和 limits。
关联点：
-
调度器不做资源预留，随便调度到任意节点
-
能白嫖节点所有空闲资源
-
节点内存/CPU压力大时，最先被驱逐、最先被OOM杀掉
-
适合临时测试、离线小脚本、无关紧要的轻量任务
三、核心联系总结
- QoS 由 Resources 配置自动生成，无手动枚举QoS字段
你配好 requests/limits，K8s 自动归类成三种QoS。
- requests 决定调度
Guaranteed/Burstable 有 requests，调度会校验节点资源；BestEffort 无 requests，调度不校验。
- limits 决定资源超用上限 & QoS 等级
全容器 requests=limits → Guaranteed；
有配资源但不等/不全 → Burstable；
完全不配资源 → BestEffort。
- QoS 最终决定驱逐/杀Pod顺序
资源紧缺时被杀优先级：
BestEffort > Burstable > Guaranteed
（左边最先杀，右边最后杀）
四、极简对照表
| QoS 等级 | 资源配置规则（requests/limits） | 优先级 | 驱逐顺序 |
|---|---|---|---|
| Guaranteed | 所有容器CPU/内存 requests=limits 都配置 | 最高 | 最后杀 |
| Burstable | 至少配了一项requests/limits，不满足Guaranteed | 中等 | 中间杀 |
| BestEffort | 所有容器都不配 requests、limits | 最低 | 最先杀 |