Evicted 由节点资源压力或 kubelet 配置异常触发，需依次检查 MemoryPressure/DiskPressure、kubelet 日志中的 eviction manager 提示、镜像/日志堆积情况，以及 config.yaml 中过激的 eviction-hard 设置。
直接查节点资源和 kubelet 日志，Evicted 不是随机发生的，背后一定有明确的触发信号。
先看节点有没有资源压力
Evicted 最常见原因是节点资源耗尽。重点检查三类指标：
-
内存：运行
kubectl describe node，看Conditions下是否出现MemoryPressureTrue -
磁盘：同样在
describe node输出里找DiskPressure；也可登录节点执行df -h和df -i，特别关注/var/lib/kubelet和容器运行时（如/var/lib/rancher/k3s/agent/containerd）所在分区 -
inodes 耗尽：即使磁盘空间没满，
df -i显示 inode 使用率 100% 同样会触发驱逐，常见于大量小日志文件或未清理的临时镜像层
再查 kubelet 的实时行为
K3s 的 kubelet 日志是核心线索，它会明确记录“为什么驱逐”：
- 在对应节点上执行：
journalctl -u k3s -n 200 --no-pager | grep -i -E "(evict|pressure|failed|gc)" - 重点关注含
eviction manager、NodeHasMemoryPressure、NodeHasDiskPressure或imageGC failed的行 - 如果看到类似
evicting pod: xxx, reason: memory usage is over threshold，就锁定了根本原因
确认是不是镜像或日志堆积导致
K3s 环境中，镜像 GC 失败或 Pod 日志无限制增长是高频诱因：
- 检查镜像数量：
crictl images | wc -l，若超千个且长期未清理，可能触发imageGCFailed - 查日志目录大小：
du -sh /var/lib/rancher/k3s/agent/logs/*或挂载到节点的emptyDir、hostPath日志路径 - 是否有 Pod 配置了
limitRange但没设日志轮转，导致单个容器日志涨到几十 GB
顺手验证下有没有配置异常
某些 K3s 启动参数会放大驱逐敏感度：
- 检查
/etc/rancher/k3s/config.yaml是否设置了过激的eviction-hard，比如memory.available 或nodefs.available - 确认没有误删
systemd单元文件或修改过k3s.service的内存限制（如MemoryLimit=），导致 kubelet 自身被 OOM kill 后反复重启并误报压力 - 运行
kubectl get events --sort-by=.lastTimestamp，过滤出最近 1 小时内带Evicted或NodeNotReady的事件，看是否集中在某个节点或时间点