概念定位
QoS 级别由容器上 requests 与 limits 的写法推导出来，不需要显式声明，kubelet 在 Pod 创建时算出并写进 status.qosClass。适用平台是 Kubernetes。它决定的是节点资源紧张时的处置顺序：BestEffort 最先被驱逐，Guaranteed 最后，Burstable 居中。理解这条规则的价值在于——想让关键服务在资源压力下活下来，就要在设计 requests 与 limits 时把 QoS 一并对齐，而不是事后被动接受。
基本信息
| 适用平台 | Kubernetes，Pod 级属性，由 kubelet 自动判定 |
|---|---|
| 影响因素 | 每个容器的 cpu、memory 的 requests 与 limits 写法 |
| 查看方式 | kubectl get pod -o jsonpath='{.status.qosClass}' |
| 处置场景 | 节点内存不足时的驱逐顺序，以及 OOM 发生时的取舍 |
典型使用场景
- 保护核心服务：为支付、网关类服务设 requests=limits，拿到 Guaranteed 级别
- 设计降级顺序：把批处理任务设成 BestEffort，资源紧张时先让它退让
- 排查被驱逐的 Pod：确认它属于哪个级别，验证驱逐顺序是否符合预期
- 容量规划评审：用 QoS 分布判断集群里有多少负载处在「不设 requests」的裸奔状态
- 配合 requests-limits 调优：均衡资源利用率与稳定性，避免全量 Guaranteed 造成资源浪费
查看 QoS
查看 QoS
kubectl get pod web-x -o jsonpath='{.status.qosClass}' # 快速取级别
kubectl describe pod web-x | grep -i qos # describe 里的 QoS Class 行
kubectl get pods -A -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,QOS:.status.qosClass' # 全局分布
kubectl get pod web-x -o jsonpath='{.spec.containers[*].resources}' # 核对 requests/limits 写法QoS 判定与驱逐
| 级别 | 判定条件 | 驱逐顺序 |
|---|---|---|
| Guaranteed | 所有容器 cpu/memory 的 requests 等于 limits | 最后（同级别内按超出 requests 的程度排序） |
| Burstable | 至少一个容器设了 requests 或 limits，但不满足 Guaranteed | 居中 |
| BestEffort | 所有容器都没设 requests 与 limits | 最先被驱逐 |
同级之间不是先到先杀：kubelet 会参考实际用量超出 requests 的程度排序，超出越多越先被驱逐。
QoS 由 kubelet 计算，不能手工指定；想改级别只能改 requests 与 limits 的写法，然后重建 Pod。
设计时的取舍
- 核心链路（网关、支付、鉴权）建议 Guaranteed，把稳定性放在资源利用率之前
- 可重试的离线任务用 BestEffort 或轻量 Burstable，让它在压力下先退让
- 内存 requests 别虚低：requests 是驱逐排序的基准之一，写得过低反而不利于存活
- CPU limits 会带来节流风险，CPU 密集服务应结合压测结果设定，不照抄模板值