宿主机内存碎片化会导致容器启动失败、Pod卡在ContainerCreating状态，因内核无法分配高阶连续页（如order:6），即使空闲内存充足；可通过/proc/buddyinfo、dmesg日志和Pod事件确认，临时用drop_caches与compact_memory缓解，长期需优化vm参数及K8s资源预留与调度策略。
宿主机内存碎片化不是Kubernetes调度器直接报错的原因，但它会间接导致容器启动失败、Pod卡在Pending或ContainerCreating状态，尤其在长期运行的节点上。Docker（或containerd）底层依赖内核分配连续物理内存页（尤其是高阶order页），当/proc/buddyinfo显示高阶页（如order=4及以上）几乎为0时，即使总空闲内存充足，也可能无法成功创建容器——这会被误判为“调度失败”，实则是节点上层运行时启动失败。
确认是否为内存碎片化问题
登录疑似异常节点，执行以下命令：
- 查看内存页分配状态：
cat /proc/buddyinfo。重点关注Normal或DMA32zone中order:4及以上的数值是否持续为0或极低； - 检查内核日志是否有
page allocation failure：dmesg -T | grep -i "order.*failure\|oom\|alloc"； - 观察Pod事件：
kubectl describe pod <pod-name>，若出现FailedCreatePodSandBox且无明确资源不足提示，需结合节点日志进一步判断。
临时缓解：触发内存规整与缓存清理
该操作在节点上执行，无需重启服务，但需具备root权限：
- 先同步脏页（可选，提升释放效果）：
sync； - 清空页缓存、dentry和inode缓存：
echo 3 > /proc/sys/vm/drop_caches； - 触发内存规整（compact）以合并碎片页：
echo 1 > /proc/sys/vm/compact_memory； - 再次运行
cat /proc/buddyinfo，确认order:4+页数量明显回升。
长期规避：节点级配置优化
单纯靠手动drop_caches治标不治本。建议从系统层加固：
- 启用
vm.compaction_proactiveness=10（Linux 5.10+），让内核更积极进行后台内存规整； - 调大
vm.min_free_kbytes（例如设为物理内存的1%~2%），预留足够连续页供关键分配； - 禁用透明大页（
transparent_hugepage=never内核启动参数），避免加剧碎片； - 对K8s节点，设置
--system-reserved=memory=1Gi等参数，为系统保留资源，减少OOM Killer干扰内存管理。
配合K8s调度策略降低风险
即使节点内存充足，碎片化也会影响新Pod启动。可在集群层面做预防：
- 为关键工作负载添加
resources.requests.memory并略高于实际需求（如多留100Mi），避免因微小碎片导致分配失败； - 使用
nodeSelector或affinity避开已知老化节点，或通过node.kubernetes.io/memory-pressure污点自动隔离； - 监控
node_memory_Bounce（若Prometheus采集了buddyinfo指标）或自定义脚本定期上报order4_pages，触发告警并自动驱逐节点上的Pod以重启运行时。
