3. 资源画像基础：Pod资源请求与限制的语义、QoS类别与碎片的关系
在Kubernetes集群中，资源碎片的本质是节点可分配资源（Allocatable）被零散占用后，剩余资源无法满足任何待调度Pod的最小资源需求，从而形成“有资源但不可用”的困境。要理解碎片如何产生，必须先掌握Pod资源声明的核心语义以及由此衍生的QoS（服务质量）类别。
3.1 Pod资源请求与限制的语义
每个Pod中的容器都可以声明两类资源参数：requests（请求）和limits（限制）。这两者的语义差异直接决定了调度决策与运行时资源竞争行为。
| 参数 | 语义 | 调度影响 | 运行时行为 |
|---|---|---|---|
| requests | 容器启动所需的最小资源保证 | 调度器依据requests计算节点剩余容量，决定是否调度 |
Kubelet保证容器至少获得requests量的资源 |
| limits | 容器可使用的资源上限 | 不影响调度决策（仅requests参与调度） |
超过limits时，CPU会被节流，内存可能触发OOM Kill |
关键认知：调度器只看
requests，不看limits。这意味着即使Pod设置了很高的limits，只要requests很低，调度器仍可能将多个此类Pod堆叠到同一节点，造成节点实际负载远超requests总和，但调度层面却认为节点“仍有空间”。
资源声明的组合方式决定了Pod的QoS类别，而QoS类别又进一步影响了节点资源碎片的形态与治理策略。
3.2 QoS类别：Guaranteed / Burstable / BestEffort
Kubernetes根据Pod内容器是否设置requests和limits，将Pod划分为三种QoS类别。这三类Pod在节点上的分布模式，直接决定了碎片产生的概率与类型。
| QoS类别 | 声明条件 | 资源保证 | 碎片风险 |
|---|---|---|---|
| Guaranteed | 所有容器requests == limits，且均设置 |
最高，资源独占性强 | 低（资源块整齐，但可能留下大块空洞） |
| Burstable | 至少一个容器设置requests，且requests < limits |
中等，可突发使用空闲资源 | 高（资源声明与使用不一致，易产生零散空洞） |
| BestEffort | 所有容器均未设置requests和limits |
最低，无资源保证 | 极高（调度时无约束，运行时被驱逐，碎片动态变化） |
实践观察：在大多数生产集群中，Burstable Pod占比超过70%。这类Pod的
requests通常远低于limits，导致调度器认为节点资源充足，但实际运行时资源消耗波动大，极易在节点上形成“声明占用”与“实际占用”之间的资源空洞，这是碎片治理的核心难点。
3.3 QoS类别与碎片的关系
碎片并非单一维度的资源剩余，而是多维资源（CPU、内存、扩展资源）在节点上的分布不匹配。不同QoS类别的Pod在节点上混合部署时，会形成三种典型的碎片模式：
- Guaranteed Pod 聚集碎片：多个Guaranteed Pod占用固定大小的资源块，当Pod被删除后，节点上留下与Pod声明大小完全一致的资源空洞。如果后续Pod的
requests无法恰好匹配这些空洞，则空洞无法被复用，形成“整齐但不可用”的碎片。 - Burstable Pod 动态碎片：Burstable Pod的
requests较小，但limits较大。调度器按requests分配资源，但运行时Pod可能突发使用大量资源。当多个Burstable Pod交错调度和终止后，节点上会留下大量“声明小、实际占用波动大”的零散空洞，碎片粒度极细。 - BestEffort Pod 抢占碎片：BestEffort Pod不声明资源，调度器将其视为“零资源占用”。但当节点资源紧张时，BestEffort Pod会被优先驱逐。驱逐后留下的资源空洞往往与驱逐时机、其他Pod的资源使用模式耦合，碎片位置和大小高度随机。
碎片治理陷阱：仅通过调整
requests和limits的数值无法彻底解决碎片问题。如果所有Pod都设置为Guaranteed，虽然碎片变得整齐，但节点资源利用率会大幅下降（因为requests必须等于limits，无法超分）。碎片治理需要在资源利用率和碎片率之间寻找平衡点。
3.4 资源碎片形成的可视化流程
下图展示了三种QoS类别的Pod在节点上混合部署后，资源碎片如何逐步形成：
3.4 碎片量化指标：从QoS视角看碎片率
为了量化碎片程度，可以引入碎片率（Fragmentation Ratio）指标，从QoS类别的分布角度评估节点健康度：
| 指标名称 | 计算公式 | 含义 | 治理阈值建议 |
|---|---|---|---|
| CPU碎片率 | 1 - (最大连续CPU核数 / 总剩余CPU核数) | CPU资源在节点上的连续可用程度 | > 0.5 时需介入治理 |
| 内存碎片率 | 1 - (最大连续内存块 / 总剩余内存) | 内存资源在节点上的连续可用程度 | > 0.4 时需介入治理 |
| QoS混合度 | 节点上QoS类别种类数（1~3） | QoS类别越混杂，碎片模式越复杂 | 3类共存时建议通过准入控制收敛 |
核心结论：资源碎片的根源不在于资源总量不足，而在于资源声明的不一致性。Guaranteed Pod产生“整齐但刚性”的碎片，Burstable Pod产生“动态且零散”的碎片，BestEffort Pod产生“随机且不可预测”的碎片。后续章节的准入控制策略和资源画像技术，正是针对这三种碎片模式分别设计治理手段。