K8S监控节点因DiskPressure频繁驱逐Pod问题排查求助

咱们先把你遇到的现象串起来，核心矛盾是：节点根分区/dev/nvme0n1p2使用率89%触发了DiskPressure导致Pod被驱逐，但用ncdu扫根目录只看到3GB占用，同时kubelet镜像垃圾回收失败。Pod内df -h显示使用率低是正常的——因为Pod的文件系统和节点根分区是隔离的，两者不是一回事，不用纠结这个点。

一、核心原因拆解 #

1. 隐藏的磁盘占用没被ncdu检测到 #

ncdu默认扫描可见文件，但Linux里有两种常见的“隐形”磁盘占用：

• 被进程持有的已删除文件：如果日志、镜像层文件被删除，但对应进程（比如kubelet、containerd）还拿着文件句柄，磁盘空间不会被释放，ncdu也扫不到这些文件。
• 容器镜像/运行时的深层存储：containerd/docker的镜像存储目录（比如/var/lib/containerd）里的overlay2层文件，ncdu可能没完全扫描到。而t3.micro的根盘一般只有20GB，几个监控镜像加旧镜像很容易占满。

2. kubelet镜像垃圾回收失效 #

kubelet默认会在磁盘使用率超过85%时自动清理未被Pod引用的镜像，但如果所有镜像都被运行中的Pod在使用，或者你调整过垃圾回收阈值（比如设得太高），就会出现“想释放空间但释放不了”的报错。

二、分步解决办法 #

1. 紧急缓解：先释放节点磁盘空间 #

• 清理闲置容器镜像：
  如果用的是containerd，执行：

  crictl rmi --prune
  

  如果用的是docker，执行：

  docker image prune -a -f
  

  这个命令会删掉所有未被运行中Pod使用的镜像，能快速释放空间。注意：重启闲置Pod时需要重新拉取镜像，但监控类镜像体积不大，影响可控。
• 释放被进程占用的已删除文件：
  先找出这些文件：

  lsof | grep deleted
  

  看到对应进程后，重启该进程（比如systemctl restart containerd或systemctl restart kubelet），就能释放被占用的空间。

2. 长期根治：解决磁盘占用根源 #

• 迁移容器存储目录到额外EBS卷：
  t3.micro的根盘太小，适合挂载一个单独的EBS卷来存容器镜像和运行时数据：
  1. 给节点挂载一个10-20GB的EBS卷，格式化后挂载到/mnt/containerd；
  2. 停止containerd：systemctl stop containerd；
  3. 复制现有数据：cp -r /var/lib/containerd/* /mnt/containerd/；
  4. 修改/etc/containerd/config.toml，把root和state路径改成/mnt/containerd/root和/mnt/containerd/state；
  5. 重启containerd：systemctl start containerd。
• 调整kubelet垃圾回收阈值：
  修改kubelet配置文件（一般是/var/lib/kubelet/config.yaml），降低触发清理的阈值，避免磁盘使用率过高：

  imageGCHighThresholdPercent: 70
  imageGCLowThresholdPercent: 60
  

  保存后重启kubelet：systemctl restart kubelet。这样当磁盘使用率超过70%时就开始清理，低于60%停止。
• 配置日志轮转：
  节点上的系统日志、kubelet日志容易堆积，修改/etc/systemd/journald.conf：

  SystemMaxUse=1G
  SystemMaxFileSize=100M
  

  然后重启journald：systemctl restart systemd-journald，限制日志占用的最大空间。

3. 优化监控Pod的存储配置 #

• 给pgadmin配置持久化EBS卷，避免把数据存在节点临时存储；
• 给所有监控Pod加上ephemeral-storage的资源请求和限制，防止单个Pod占用过多节点磁盘：

  resources:
    requests:
      ephemeral-storage: "1Gi"
    limits:
      ephemeral-storage: "2Gi"
  

三、验证解决效果 #

1. 用df -h /dev/nvme0n1p2查看根分区使用率是否下降到安全阈值；
2. 查看kubelet日志：journalctl -u kubelet -f，确认没有再出现垃圾回收失败的提示；
3. 观察1-2小时，确认Pod不会再因DiskPressure被驱逐。

内容的提问来源于stack exchange，提问作者Juliatzin