关键不是修容器，而是盯住宿主机挂载路径——它才是真正的瓶颈；需用df -h查宿主机真实挂载点空间，清理日志与临时文件，改用pv/pvc并设配额，配合监控告警防复发。
直接解决 Docker 容器挂载存储卷时因磁盘空间不足导致异常，关键不是“修容器”，而是盯住宿主机上被挂载的物理路径——它才是真正的瓶颈。容器内看到的存储卷（如 /data）只是映射，背后是宿主机某个目录或设备，一旦那里满了，容器读写就会失败，报 no space left on device 或日志写不进、文件创建失败等错误。
查清挂载点真实空间占用
别只看容器里 df -h，那反映的是挂载视图，不是源头：
- 用
kubectl describe pod <pod-name></pod-name>或docker inspect <container-id></container-id>找出 volumeMounts 对应的 hostPath 或实际挂载路径（比如/mnt/data或/var/lib/kubelet/pods/xxx/volumes/.../volume-name） - 登录宿主机，运行
df -h /mnt/data（替换成你的真实路径），确认该挂载点使用率是否 ≥90% - 若挂载的是 LVM、NFS 或云盘，还需检查底层设备：对 LVM 运行
vgdisplay和lvdisplay；对 NFS 检查服务端空间；对云盘确认配额或扩容状态
快速释放挂载路径下的空间
定位到满的目录后，优先清理高风险项：
-
清空大日志文件：执行
find /mnt/data -name "*.log" -size +50M -exec truncate -s 0 {} \;（仅清空内容，不删文件，避免应用因文件句柄失效崩溃） -
清理临时文件和缓存：检查
/mnt/data/tmp、/mnt/data/cache等子目录，删除过期或无主文件；对 Kubernetes 的 emptyDir，确认是否被 Pod 错误写爆 -
检查残留数据卷：若用的是 hostPath + 本地目录，运行
du -sh /mnt/data/* | sort -hr | head -5，找出异常大的子目录，再结合lsof +D /mnt/data查看哪些进程还在占用已删除但未释放的文件
防止下次再满：从挂载方式和策略入手
单纯清理治标，得让挂载行为本身更健壮：
- 为 hostPath 类型 volume，提前在宿主机上设置磁盘配额（如
setquota）或用独立分区挂载，避免挤占系统盘 - 改用 PersistentVolume（PV）+ PVC，配合 StorageClass 设置
volumeBindingMode: WaitForFirstConsumer，让调度器避开已满节点；同时在 PV 中声明capacity，K8s 能感知并拒绝超限绑定 - 对 Docker 单机场景，若挂载的是
docker volume，确保其后端存储（如本地 ext4 分区、NFS）有余量，并定期执行docker volume prune清理未引用卷 - 所有写密集型应用（如日志服务、数据库），必须在容器启动时通过
--log-opt max-size=100m --log-opt max-file=3限制日志，或把日志输出重定向到外部日志系统，而非存进挂载卷
长期可用：监控与自动响应
靠人盯不现实，要建立闭环：
- 在 Prometheus + Node Exporter 中添加
node_filesystem_avail_bytes{mountpoint=~"/mnt/data.*"}告警规则，阈值设为 10GB 或 15% - 对 K8s 集群，启用
ephemeral-storagerequest/limit，并配置 kubelet--eviction-hard=ephemeral-storage.available，让驱逐早于彻底写满 - 编写简单脚本定时扫描挂载路径：
if [ $(df /mnt/data | awk 'NR==2 {print $5}' | sed 's/%//') -gt 90 ]; then echo "ALERT" | mail -s "Full disk" admin@example.com; fi
