确认压力来源

节点出现 LargeDiskPressure 的提示时，先别急着删镜像或日志。建议先用 kubectl describe node <节点名> 查看 Conditions 部分，确认 DiskPressure 是否为 True。这个状态是 kubelet 根据本地磁盘占用情况计算出来的，一旦置为 True，节点上的 Pod 就可能被驱逐或禁止调度。

磁盘压力并不一定只是容量问题。根文件系统使用率超阈值会触发，inode 耗尽同样会触发。所以判断时要同时看 df -h 和 df -i，如果 inode 使用率已经 100%，即使容量还有剩余，节点也会进入压力状态。先确定压力来源，后面的清理动作才有针对性。

镜像清理：先看引用，再考虑批量 prune

清理容器镜像是释放磁盘空间的常用手段。在containerd运行时下，可以通过crictl images列出所有镜像，使用crictl rmi 删除不再使用的镜像。如果节点使用Docker，则可以执行docker image ls和docker rmi。为了安全起见，在删除之前先用crictl ps查看正在运行的容器，确认它们依赖的镜像，不要删除那些镜像。一个更快捷的方法是使用crictl rmi --prune，它会清理掉所有未被容器引用的镜像，但可能也会移除一些缓存的镜像，使用前需要评估是否必要。

我一般不会直接使用 --prune。更稳妥的方式是先按镜像的创建时间或大小排序，然后逐个确认。对于 containerd 环境，可以先用 crictl ps -a 拿到正在使用镜像的 ID，再用 crictl rmi <镜像ID> 删除目标镜像。如果节点是 Docker 运行时，对应的命令是 docker ps -a 和 docker rmi。这里要注意，手工导入的私有镜像往往没有仓库索引，一旦被 prune 删掉，重新拉取不一定成功，所以本地有特殊镜像时，尽量保留。

日志清理：清空文件而不是删除文件

容器日志通常占据大量磁盘空间，默认路径是/var/log/pods。要定位日志大户，可以先执行du -sh /var/log/pods/*，这会按Pod输出日志目录大小。找到占用高的Pod后，不要直接删除日志文件，因为容器运行时可能还持有该文件描述符，删除后空间不会立即释放，甚至会导致输出异常。较好的做法是清空文件内容，比如使用“true > /var/log/pods/namespace_pod-uid/container/0.log”这样的命令，不影响文件句柄，同时释放磁盘空间。也可以查看kubelet的日志轮转配置，合理设置日志文件大小和轮转参数。

清空日志时，命令里的 namespace_pod-uid 和 container 要替换成实际目录，路径可以通过 du -sh /var/log/pods/* 已经看到具体位置。除了 /var/log/pods，如果节点使用 Docker 运行时，/var/lib/docker/containers 下也会有同名日志，同样可以先用 du -sh 定位。如果系统日志 journald 占用也大，可以查看 journalctl --disk-usage，再用 journalctl --vacuum-size 限制。日志轮转参数建议查看 kubelet 的启动配置，里面有 containerLogMaxSize 和 containerLogMaxFiles，但修改后需要重启 kubelet，要选择维护窗口操作。

操作顺序与后续检查

当节点已经处于 LargeDiskPressure 状态时，建议按照先日志后镜像的顺序进行清理。日志增长往往更快，而且清空日志文件不影响容器运行，可以先快速释放一部分空间；镜像虽然也能腾出不少空间，但需要更多判断，删除错误后果也更严重。每次操作完成后，用 df -h 确认根文件系统使用率是否下降，不要攒到最后一起看。

如果日志和镜像都清理完，空间依然紧张，再检查系统包管理器缓存和临时文件。比如 apt 系统可以用 apt-get clean，yum 系统可以用 yum clean all，/tmp 下堆积的旧文件也可以清理。但清理时要避免 rm -rf 这种直接删除目录的方式，尤其是日志目录和运行中的容器目录，防止误删正在写入的文件。

容易忽略的清理点

清理过程中有几个容易踩的坑。一个是直接使用docker system prune -a清理所有未使用镜像，这会把一些手工加载的私有镜像也删掉，如果镜像仓库不可用，将造成工作负载无法恢复。另一个坑是清理日志时只关注/var/log/pods，却忽略了docker存储目录下的日志，比如/var/lib/docker/containers，这些目录也可能增长到很大。此外，一些系统服务也会产生大量系统日志，可以用journalctl --disk-usage查看，必要时通过journalctl --vacuum-size来限制。最后，清理完成后一定要检查节点是否还在压力状态，有时候空间释放了但kubelet需要几分钟才能更新状态。

在集群层面，也可以为节点配置自动清理策略，比如设置 eviction-hard 的参数来调整阈值，但这一步需要重启 kubelet，而且不同环境的磁盘增长速率不同，具体阈值要结合监控数据判断。清理动作本身不复杂，关键是平时留好日志轮转和镜像回收的机制，避免每次都被动进入压力状态再处理。