K8S状态为“Evicted”的pod的处理办法&问题解析

摘要：本文介绍了Kubernetes中Evicted Pod的处理方法及原因分析。处理步骤包括查找Evicted Pod、查看原因和清理操作。常见触发原因分为三类：1)资源类(内存/磁盘不足、inode耗尽)；2)节点问题(NodeNotReady、PID耗尽)；3)调度/策略因素(超时、镜像拉取失败、手动drain)。kubelet会主动驱逐Pod但保留记录，需根据具体原因进行排查处理。清理前应

weixin_49053853

558人浏览 · 2025-08-14 11:12:12

weixin_49053853 · 2025-08-14 11:12:12 发布

一、处理办法

查找整个 Kubernetes 集群中所有状态为 Evicted 的 Pod：

kubectl get pods --all-namespaces --field-selector=status.phase=Failed | grep Evicted

如需进一步分析 Evicted 原因，可查看具体 Pod 的详情。通过以下命令，查看 pod 的 “Message” 和 “Events”。

kubectl describe pod <pod-name> -n <namespace>


# 或直接过滤看具体原因
kubectl describe pod <pod-name> -n <namespace> | grep -A5 "Reason:"

清理所有 Evicted Pod。（清理前建议先确认这些 Evicted Pod 是否已不再需要！！！）

kubectl get pods --all-namespaces --field-selector=status.phase=Failed | grep Evicted | awk '{print $2 " -n " $1}' | xargs -L1 kubectl delete pod

二、问题解析

Pod 状态被标记为 “Evicted”，本质上是 kubelet 在节点上主动把 Pod 驱逐（kill 并清理）了，但它仍作为一条失败记录留在 API Server 里，方便排障。常见触发原因可以分三大类：资源、节点、调度/策略。

1️⃣ 资源类（最常见）

触发条件	典型日志/事件关键词	说明
节点内存不足	The node was low on resource: memory	kubelet 在发生 OOM 前，会基于 evictionHard / evictionSoft 阈值，主动杀掉占用内存最多的 Pod。
节点磁盘不足	The node was low on resource: ephemeral-storage 或 nodefs/imagefs	临时存储、日志、镜像层把磁盘打满，kubelet 驱逐 Pod 以释放空间。
inode 耗尽	The node was low on resource: nodefs.inodesFree	小文件过多，inode 用光，Pod 被驱逐。

2️⃣ 节点本身问题

触发条件	典型日志/事件关键词	说明
Node NotReady / 网络失联	The node was NotReady / NodeStatusUnknown	节点失联，controller-manager 会设置 TaintNodeNotReady ，kubelet 在恢复后可能把之前无法上报的 Pod 标记为 Evicted。
PID 耗尽	The node had PID pressure	节点上进程数过多，触发 pid.available 的驱逐阈值。

3️⃣ 调度/策略/人为

触发条件	典型日志/事件关键词	说明
超过 Pod 的 `activeDeadlineSeconds`	Pod was active on the node longer than the specified deadline	Job/CronJob 给 Pod 设置了 spec.activeDeadlineSeconds ，运行时间超过该值后，kubelet 会将 Pod 标记为 Failed → Evicted。
镜像拉取失败且长时间无法恢复	ImagePullBackOff 或 ErrImagePull 持续出现	虽然最终状态可能显示 Failed 而非直接 Evicted，但极端情况下 kubelet 会清理长时间无法启动的 Pod，随后记录为 Evicted。
管理员手动 drain 节点	eviction by user 或 kubectl drain 相关事件	运维人员执行 kubectl drain 驱逐节点上的 Pod，以便维护或下线节点。被驱逐的 Pod 会显示为 Evicted。