为什么DiskPressure 会自动恢复

核心机制：驱逐本身就是"自我治愈"的过程

DiskPressure 恢复往往不是"问题被解决"，而是驱逐动作本身释放了空间，形成了一个闭环：

磁盘空间不足 → 触发DiskPressure → kubelet驱逐Pod → 被驱逐Pod占用的空间被释放 → 磁盘空间恢复 → DiskPressure消失

1. 被驱逐的Pod自身释放了空间（最常见）

当Pod被Evicted时，kubelet会：

• 删除该Pod的容器（连带日志、可写层）
• 清理该Pod使用的 emptyDir 临时卷

如果你这些 albert-agent-2 的Pod本身占用了大量磁盘空间（比如临时文件、日志），驱逐掉几十个Pod之后，磁盘立刻就恢复了——这完全说得通，因为看你的截图有几十个副本同时被驱逐，释放的空间可能相当可观。

2. kubelet自动触发了镜像/容器垃圾回收

kubelet 在磁盘压力时会自动执行：

imageGCHighThresholdPercent（默认85%）→ 触发清理旧镜像
containerGC → 清理已停止的容器

这些GC动作会自动删除：

• 未被使用的镜像层
• 已退出容器的日志和可写层

3. 阈值有"软/硬"两级，会有自动恢复缓冲

evictionHard: nodefs.available: "10%" # 触发驱逐

evictionSoft: nodefs.available: "15%" # 软阈值，给一段观察期

一旦磁盘使用率回落到阈值以下（哪怟只是因为清理动作生效），kubelet 会自动把 Node 的 DiskPressure Condition 设置回 False——这是kubelet的自动检测机制，不需要人工干预。

4. 日志本身有周期性（如果是日志导致的）

比如：

• 某个应用在特定时间段（如批处理任务）疯狂打日志
• 任务结束后，日志增长停止，同时journald/docker log可能有自动rotate
• 磁盘使用率自然回落

这是一个"假恢复"，本质上磁盘压力问题依然存在隐患，原因：

1. 触发DiskPressure的根本原因没有被排查和修复（比如日志没配额、没做日志轮转）
2. 下次同样的场景重现，还会再次触发驱逐，导致同一批Pod再次被Evicted
3. 被驱逐的Pod会不断重建 → 重新写入数据/日志 → 再次占满磁盘 → 恶性循环

这就是为什么你现在还能看到几十个 Evicted 的历史Pod残留——它们是历史事件的"尸体"，不会自动被清理，需要手动删除。

# 1. 查看该节点是否还有磁盘使用率增长的趋势（用Prometheus/Grafana看历史曲线更直观）

kubectl top nodes

#2. 查看kubelet事件日志，确认当时驱逐的具体原因和释放了多少空间

kubectl get events --field-selector reason=Evicted -A

# 3. 检查这个Pod的容器配置，看有没有写大量本地文件的行为

kubectl describe deployment albert-agent-2 | grep -A 20 Volumes