19-2、K8s 三种 QoS 等级 与 Resources（requests_limits）的核心关联

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