2. 资源碎片度量指标：可调度碎片率、不可调度碎片率、CPU/Memory碎片系数、碎片密度
在Kubernetes集群中，资源碎片是导致节点利用率下降、调度失败的核心原因之一。要治理碎片，首先需要一套可量化、可对比、可预警的度量指标体系。本章定义四个核心指标：可调度碎片率、不可调度碎片率、CPU/Memory碎片系数、碎片密度，并给出计算方式与适用场景。
2.1 指标定义与计算公式
| 指标名称 | 符号 | 计算公式 | 含义 |
|---|---|---|---|
| 可调度碎片率 | FSsched | 1 - (可调度最大Pod数 / 理论最大Pod数) | 节点虽可调度，但剩余资源碎片化，无法容纳更多Pod |
| 不可调度碎片率 | FSunsched | 1 - (已分配资源量 / 节点总资源量) | 节点因碎片导致无法调度新Pod，资源被浪费 |
| CPU碎片系数 | Fcpu | max(0, 1 - (可分配CPU核数 / 总CPU核数)) | CPU资源碎片化程度，0表示无碎片，1表示完全碎片 |
| Memory碎片系数 | Fmem | max(0, 1 - (可分配内存量 / 总内存量)) | 内存资源碎片化程度，0表示无碎片，1表示完全碎片 |
| 碎片密度 | Dfrag | ∑(碎片块大小 × 碎片块数量) / 节点总资源量 | 单位资源量上的碎片块数，反映碎片分布的密集程度 |
关键理解：可调度碎片率关注“还能不能调度”，不可调度碎片率关注“已经浪费了多少”。两者结合可以判断节点是“假性空闲”还是“真性碎片”。
2.2 指标计算示例
假设一个节点拥有 8 CPU、32 GiB 内存，当前已运行Pod的资源请求如下：
Pod A: CPU 2.5, Mem 4 GiB
Pod B: CPU 3.0, Mem 6 GiB
Pod C: CPU 1.5, Mem 8 GiB
Pod D: CPU 0.5, Mem 2 GiB
剩余资源：CPU = 8 - (2.5+3.0+1.5+0.5) = 0.5 CPU；内存 = 32 - (4+6+8+2) = 12 GiB。
- 可调度碎片率：剩余0.5 CPU无法满足任何新Pod的最小CPU请求（假设最小为1 CPU），可调度最大Pod数为0，理论最大Pod数为8，FSsched = 1 - 0/8 = 1.0（完全碎片）。
- 不可调度碎片率：已分配资源量 = 7.5 CPU + 20 GiB，节点总资源量 = 8 CPU + 32 GiB，FSunsched = 1 - (7.5/8 + 20/32)/2 = 1 - (0.9375 + 0.625)/2 = 0.21875。
- CPU碎片系数：可分配CPU核数 = 0.5，总CPU核数 = 8，Fcpu = 1 - 0.5/8 = 0.9375。
- Memory碎片系数：可分配内存量 = 12 GiB，总内存量 = 32 GiB，Fmem = 1 - 12/32 = 0.625。
- 碎片密度：假设碎片块大小为0.5 CPU和2 GiB，碎片块数量为1（CPU）和6（内存），Dfrag = (0.5×1 + 2×6) / (8+32) = 12.5/40 = 0.3125。
2.3 碎片度量体系架构
下图展示了碎片度量指标在Kubernetes集群中的采集、计算与消费链路：
2.4 指标对比与选型建议
| 指标 | 适用场景 | 优点 | 局限 |
|---|---|---|---|
| 可调度碎片率 | 准入控制、调度前预判 | 直接反映调度可行性 | 依赖Pod最小请求假设 |
| 不可调度碎片率 | 节点利用率评估、碎片治理优先级排序 | 计算简单，数据易获取 | 无法区分碎片类型 |
| CPU/Memory碎片系数 | 资源维度精细化分析 | 区分CPU与内存碎片，定位瓶颈 | 需要分别计算，不能合并 |
| 碎片密度 | 碎片分布分析、碎片整理效果评估 | 反映碎片分布的均匀性 | 计算复杂度较高 |
实践建议：在准入控制阶段，优先使用可调度碎片率作为快速过滤条件；在碎片治理策略制定时，结合CPU/Memory碎片系数定位具体资源瓶颈；在治理效果评估时，使用碎片密度衡量碎片分布的改善程度。
2.5 碎片系数与碎片密度的关系
碎片系数与碎片密度从不同维度描述碎片状态：
- 碎片系数：衡量资源被“切碎”的程度，值越高表示剩余资源越零散，越难以被新Pod利用。
- 碎片密度：衡量碎片在节点上的分布密集程度，值越高表示碎片块越多、越分散。
两者结合可以判断碎片类型：
| 碎片系数 | 碎片密度 | 碎片类型 | 治理策略 |
|---|---|---|---|
| 高 | 高 | 严重碎片化 | 立即触发Pod重调度或节点整理 |
| 高 | 低 | 集中式碎片 | 调整Pod资源请求，合并碎片块 |
| 低 | 高 | 分散式碎片 | 优化调度策略，减少小Pod分布 |
| 低 | 低 | 健康状态 | 维持现状，定期监控 |
注意：碎片系数和碎片密度需要结合节点实际负载情况综合判断。一个CPU碎片系数高但内存碎片系数低的节点，可能只需要调整CPU资源请求，而不需要整体重调度。
2.6 指标采集与计算实现
以下是一个基于Prometheus查询语言的碎片指标计算示例：
# 可调度碎片率（假设最小Pod请求为1 CPU、2 GiB内存）
1 - (
count(
node:node_allocatable_cpu_cores:sum
- node:node_allocatable_memory_bytes:sum / 2^30
) / count(node:node_allocatable_cpu_cores:sum)
)
# CPU碎片系数
max(0, 1 - (
sum(kube_pod_resource_request{resource="cpu"}) by (node)
/
sum(kube_node_status_allocatable{resource="cpu"}) by (node)
))
# 碎片密度（简化版）
sum(
(kube_pod_resource_request{resource="cpu"} < 1) * 1
) by (node) / sum(kube_node_status_allocatable{resource="cpu"}) by (node)
在实际生产环境中，建议将上述指标封装为Prometheus Recording Rules，以降低查询延迟并支持实时告警。