确认磁盘压力驱逐需三步：先用kubectl get pods -A | grep Evicted定位Pod，再kubectl describe pod查Events中是否含nodefs或DiskPressure，最后kubectl describe node验证Conditions里DiskPressure=True并比对ephemeral-storage水位。
确认驱逐是否由磁盘压力引发
先看 Pod 状态和事件，快速锁定 DiskPressure：
- 执行 kubectl get pods -A | grep Evicted 找出被驱逐的 Pod
- 对任一被驱逐 Pod 运行 kubectl describe pod <pod-name> -n <ns>，重点查看 Events 区域——若出现 The node was low on resource: nodefs 或 DiskPressure，基本可断定是磁盘问题
- 再查节点状态：kubectl describe node <node-name>，在 Conditions 部分确认 DiskPressure=True，同时留意 Allocatable 和 Capacity 下的 ephemeral-storage 数值对比
定位容器内临时空间消耗源头
微服务容器写满本地磁盘，常见于日志、/tmp、emptyDir 或镜像可写层。需分层排查：
-
查容器日志文件大小：登录对应节点，进入容器存储目录（如
/var/lib/docker/containers/<id>/<id>-json.log），用du -sh *.log | sort -hr | head -5找出最大日志 -
进容器检查临时目录：用 kubectl exec -it <pod> -- sh 进入后运行
df -h /tmp /var/log /dev/shm和du -sh /tmp/* 2>/dev/null | sort -hr | head -3 -
检查 emptyDir 卷使用情况：在 Pod YAML 中确认是否有
emptyDir: {}；若有，该卷默认落在 nodefs 上，其内容即计入nodefs.available -
验证应用是否直写宿主机路径：比如 Java 应用未配置
-Djava.io.tmpdir=/dev/shm，可能默认写到容器根路径，最终撑爆 nodefs
验证 kubelet 驱逐阈值与实际水位
驱逐不是凭空发生，而是 kubelet 按预设阈值触发。需比对实际用量与配置：
- 查节点 kubelet 启动参数：ps aux | grep kubelet | grep eviction-hard，典型配置如
--eviction-hard=nodefs.available<10%,nodefs.inodesFree<5% - 查当前 nodefs 可用空间：df -h /（多数情况下 nodefs 指根分区）或 df -h /var/lib/kubelet
- 注意 inode 耗尽同样会触发驱逐：df -i /，尤其当大量小文件（如频繁打日志、生成 trace 文件）存在时
- 如果节点挂载了独立数据盘（如
/data）并用于容器存储，但 kubelet 仍监控/，就可能出现“数据盘没满、却因根盘满而驱逐”的误判
修复与预防措施
短期止血 + 长期加固，避免反复驱逐：
-
立即清理：清空大日志（
truncate -s 0 *.log）、删除无用临时文件、重启高 IO 微服务容器 -
为 Pod 显式声明 ephemeral-storage：在容器 resources 中加入
requests: ephemeral-storage: 2Gi和limits: ephemeral-storage: 4Gi，让调度器和 kubelet 共同约束 -
日志策略收敛：禁用 JSON 日志（改用 stdout/stderr + sidecar 收集），或通过
dockerd的max-size/max-file限制容器日志 -
emptyDir 加限制：若必须用 emptyDir，建议指定
sizeLimit: 512Mi，防止无限增长 - 关键服务设 Guaranteed QoS：确保 CPU/Memory 的 request == limit，并加上 ephemeral-storage 限制，提升驱逐优先级中的生存权重
