节点资源碎片化不是玄学，它是调度器把pod安置得太随意的后遗症。装箱率低，先天原因是节点规格搭配不合理，后天原因是调度策略没做碎片治理。
节点资源碎片化怎么解决：先看懂它是怎么形成的
内存才是碎片化的重灾区
内存是硬性门槛，不可压缩，进程占了就是占了，业内共识是，内存碎片是拉低装箱率的头号元凶，你申请了4个8GB的node，表面上总量32GB，可实际跑起来发现，很多pod的request只有1.5GB、2GB，调度器东塞一个西塞一个,剩下的空隙全变成边角料。
举一个很常见的场景：
- 节点A：剩余4.2GB内存，但最大空闲段只有1.8GB。
- 节点B：剩余3.6GB内存，最大空闲段有3.1GB。
- 新来的pod要2.5GB，调度器看了半天,只有节点B能塞下。
节点A那块4.2GB的区域看似宽裕，实则谁也住不进去，这就是碎片化最直接的表现数量上够用，形状上不匹配。
CPU碎片化是显性浪费
CPU不像内存那样严格受限，但它的碎片化表现更隐蔽，大量pod设置了requests: 500m、1000m，实际consumption可能只有两成，节点上CPU分配率看着到了85%，真实负载却只有20%，装箱率是假的，真实利用率更是假的，调度器按request走，不看真实水位,碎片化就这样被合法地保存下来。
磁盘与GPU是隐性坑
磁盘碎片体现在临时存储的request上，多数业务不会给自己的emptyDir设置精确的sizeLimit，但集群管理员给节点划的ephemeral-storage配额是一定的，pod一多，local volume和日志文件互相挤占，节点进入EvictionThreshold，又被迫赶走一批小pod，腾出来的空间大小不一，碎片又多了，GPU节点更不用讲，一个GPU卡只能给一个pod，显存用了30%也算整卡分配,碎片化指数直接拉满。
K8s装箱率低的原因是什么：碎片化是隐形杀手
碎片化怎么卡死调度器
调度器做的是“找得到就行”的活，不做“放得漂亮”的活，predicates阶段只看单节点是否满足，priorities阶段才看均衡和装箱，默认配置下，大多数集群用的是LeastRequestedPriority这类均衡策略，它会让pod尽量散开，结果就是每个节点都被切出很多小豁口,没有一个节点能吃下大pod。
情况会越来越极端：
- 节点总数变多,小豁口数量同步增长。
- 大pod来了，因单节点剩余不足,Pending。
- 小pod继续填,豁口变成碎渣。
- 你想加节点,结果加了之后碎片总量更多。
这是一个恶性循环，近年来，越来越多平台团队意识到，
默认调度策略根本没有为高装箱率设计，它是为高可用设计的,代价就是浪费。
亲和性和拓扑约束雪上加霜
PodTopologySpread、NodeAffinity这些约束，设计初衷是防故障域同损，可到了日常环境里，它们经常变成碎片放大器，比如你给某业务打上了topology.kubernetes.io/zone: az1的亲和要求，az1的节点已经塞得七七八八，az2空得冒烟，pod也只能在az1里挤，结果az1碎片化严重，az2利用率极低,整体装箱率被拉低一大截。
大块头Pod让碎片更无解
一个集群如果有几个需要12GB内存整段的Java服务或内存数据库，而节点内存上限是16GB，那你只能放一个，剩下的2GB、3GB空间，塞个sidecar都费劲，想提高装箱率就得搭配小pod去补，但小pod来得慢，补丁打不齐,碎片就这么沉淀下来了。
据某云厂商的公开材料，生产环境中因为碎片化导致的资源浪费，相当一部分集群超过三成,这个数字在混部场景里会更夸张。
节点资源碎片化怎么真正解决：调度侧与重建侧双管齐下
第一步：看清集群碎片分布
不要靠感觉，先量化，用kubectl describe node看每个节点的Allocated resources，然后按维度排序，更推荐装kube-capacity这个命令行工具，一行命令能看到每个节点的request、limit和实际剩余。
当出现以下信号时,说明碎片病得不轻：
- 多数节点剩余资源在1GB到3GB之间,呈犬牙交错状。
- 新提交的大pod频繁Pending，报
Insufficient memory。 - 节点总数在涨,业务总量没怎么涨。
- 单节点分配率看起来很高,业务方还在喊不够。
这四条如果中了三条，别急着加节点。加节点是给碎片化续命，不是治病。
第二步：给调度器装上“拼图意识”
改调度策略是见效最快的一步，在kube-scheduler的配置里，把Priorities从均衡策略换成MostRequestedPriority，或者直接用RequestedToCapacityRatio并给内存设置较高权重，让调度器默认往最满的节点塞，把节点塞成“实心砖”，而不是“蜂窝煤”。
如果你用的是kube-scheduler自带插件，操作路径是修改KubeSchedulerConfiguration，调整profile中的score权重，核心思路就一句话让新pod优先落在剩余资源最少、但刚好够用的节点上。
第三步：用descheduler定期做拼图
调度器只对新pod生效，老pod的布局已经定了，这时要上descheduler，社区默认的
LowNodeUtilization策略能识别出低利用率节点，把pod赶走再重新调度，配合PodLifeTime策略,把长运行pod的年龄作为重调度触发条件。
有两种操作路径：
- 安装descheduler的cronjob，每天凌晨跑一次，注意通过
evictLocalStoragePods和ignorePvcPods控制驱逐范围。 - 手动操作：
kubectl cordon一个节点，kubectl drain清空它，让上面的pod去别的节点重新碰碰运气，最后uncordon。
手动方式更像“大扫除”，适合一次性解决历史包袱,但生产环境务必先小范围验证。
第四步：节点池规格拆分
不同业务混用一个规格的节点池，是碎片化的温床,比较理想的方案是：
- Web/微服务用小规格节点池，16GB或32GB内存，4核或8核,让多数pod有较多排列组合。
- 高内存业务单独划一个64GB或128GB内存的节点池,大块内存整段用。
- 定时任务和AI推理用抢占式/spot池，接受被回收,但不接受它们和不被回收的业务搅在一起。
这样一来，节点池内部规格一致，pod大小相对均匀,碎片化天然减少。
第五步：让节点学会“瘦身”
有些节点被大量DaemonSet、日志采集器、监控agent占用了不少资源，这部分资源在计算装箱率时要单独扣出来，不然调度器永远按表面值排pod，建议用资源预留机制，把system-reserved和kube-reserved划清楚，再给DaemonSet单独设置priorityClass。别让系统进程混进业务资源池里抢座位。
装箱率低和云成本：算明白这笔账
碎片化的最终代价写进账单里，同样跑1000个pod，节点数从40台变成55台，整体成本上涨接近四成，在云环境里，选择合适型号的节点比贪图大规格省钱得多,举个例子：
| 节点规格 | 内存总量 | 可承载pod | 典型剩余碎片 | 单核成本效率 |
|---|---|---|---|---|
| 8GBx2个 | 16GB | 中 | 低 | 较优 |
| 16GBx1个 | 16GB | 中 | 高 | 较差 |
| 32GBx1个 | 32GB | 偏少 | 很高 | 差 |
大节点适合大计算型业务，不适合微服务混合部署。微服务集群以小节点为主，大节点仅用于特定工作负载,这个原则能直接把闲置率打下来。
在国内主流公有云上，同代CPU的通用型实例价格相近，差别主要体现在规格折扣上，但长期来看，账不能只看单价，
碎片率和真实利用率才是决定单位业务成本的关键,选择节点时的稳妥路径是：
- 统计业务pod的request中位数。
- 把节点规格定为中位数的4-6倍。
- 有两类规格即可,不要出现七八种规格混用。
节点资源碎片化怎么在日常巡检里发现
碎片化不是爆发型故障，它是慢性病,日常巡检应把这些动作固化成习惯：
- 每周执行一次
kubectl top nodes,对比真实使用量和request分配率之间的缺口。 - 每个月用
kube-capacity导一份报告，统计各节点“剩余资源中最大连续空闲段是多少”。 - 针对大pod的Pending事件做复盘,是不是每次都是因为碎片化导致无节点可用。
- 大规模发布前，先模拟调度一次，工具用
kubectl create job --dry-run=server那段逻辑验证可调度性。
当发现某节点池的分配率超过75%、但真实负载不到30%时，就意味着碎片化的水分已经很大了，这时候别等p待事件爆发，第一时间跑一次descheduler的LowNodeUtilization,把低效节点清空一轮。
相关问题：K8s节点资源碎片化怎么排查
Q：怎么快速判断集群碎片化程度？
A：先用kubectl describe node看每台节点的Allocated resources百分比，留意那些“分配率看起来一致但大小各不相同”的节点，再用kubectl get pods --field-selector=status.phase=Pending查看是否有卡住的pod，如果大量Pending pod都只是差1GB内存而无法调度,那基本能确认碎片化已经是主要矛盾。
Q：descheduler会打断业务吗？
A：有影响，但可控，descheduler默认驱逐Pod时遵守PDB和优先级，你也可以把evictLocalStoragePods关闭来保护有状态业务，建议先用cronjob在低峰期执行，同时不要让它一次驱逐太多pod，给集群留出重调度缓冲空间，重调度本身也是成本,频繁触发反而会有抖动风险。
Q：碎片化和扩容之间怎么取舍？
A：如果业务本身在增长，扩容是正常的，但如果节点总量增加而业务量没变化，那就是碎片化在逼你花钱，先清理碎片再做扩容决策，正常顺序是：调整调度策略，回收低效节点，观察一周，仍然不足再扩容，这样能压住相当一部分不必要的云资源成本，在IDC机房场景里，机柜资源紧张地域的扩容价格更不便宜，把碎片化治理放在扩容前面，省下的钱会非常可观。碎片化治理的本质是让每一台节点都尽量变成“整块砖”，而不是“补丁袋”。