K8s Pod 驱逐排查手册：从 Evicted 信号到根因定位

频繁 Evicted 是集群在报警，不是偶然

很多团队对 Pod 频繁被驱逐的处理方式是「重新部署就好了」，直到某天核心业务在高峰期被连环驱逐才意识到问题。驱逐（Eviction）不是故障，是 kubelet 在节点资源触线时的自我保护——它一直在工作，你看到 Evicted 频发，说明保护线被反复击穿。这篇讲我们排查 Pod 驱逐的完整路径。

一、先分清驱逐的三种来源

打开 kubectl get pod，看 Message 字段，驱逐基本分三类：

1. 资源压力驱逐：内存压力（MemoryPressure）、磁盘压力（DiskPressure）、PID 压力。Message 里会写明 "The node was low on resource: memory"。

2. 抢占驱逐：高优先级 Pod 抢占低优先级的资源，Message 含 "preempted"。

3. 策略驱逐：PDB（PodDisruptionBudget）或节点维护触发，属正常运维动作。

三类来源的解法完全不同，别一上来就调资源预留。

二、资源压力驱逐：三条最常见的根因线

磁盘线（最容易被忽视）：容器日志写满、emptyDir 膨胀、镜像堆积都会触发 DiskPressure。检查项：kubectl describe node 里的 Allocatable 与已用差值；镜像 GC 阈值（--eviction-hard=imagefs.available<15% 是否合理）；业务容器日志是否做了轮转与外送（很多 Evicted 的真凶是「日志无轮转写满根分区」）。

内存线：节点内存水位看似不高却仍驱逐，通常是页缓存计入的错觉——available 才是驱逐判据，不是 usage。容器内存泄漏（Go/C++ 服务长尾增长）会让 working set 缓慢逼近 limits，触发 oom-evict。监控项：container_memory_working_set_bytes / limit 的比值，超过 90% 告警。

PID 线：高频创建线程/进程的应用（如 shell 脚本型 Job）会撞 pid 压力，加 --pod-max-pids 限制并排查泄漏点。

三、驱逐前的信号：把告警做在 Evicted 之前

等看到 Evicted 已经晚了半步。我们的做法是把三类指标做成前置告警：

- 节点级：kube_node_status_condition{condition="MemoryPressure|DiskPressure"} == 1；

- 容器级：working set / limit > 85% 持续 5 分钟；

- 系统级：kubelet summary API 的 nodefs.available、imagefs.available 低于 20%。

配合 --eviction-minimum-reclaim 给驱逐后留出恢复空间，避免「驱逐-重启-再驱逐」的震荡循环。

四、清完表症后的三个根治动作

1. 资源画像：用 VPA 建议值或一周的 P95 使用量为每个服务校准 requests/limits，消灭「拍脑袋配额」；

2. 优先级分层：核心业务设高 PriorityClass，确保驱逐时牺牲的是可容忍的低价值负载；

3. 压测验证：用压力工具把节点推到驱逐线，验证告警先于驱逐、驱逐顺序符合预期——这套演练建议每季度跑一次。

结语

驱逐是集群的免疫系统，频繁报警说明「病灶」在持续存在。按「分类 → 信号 → 根治」的路径走一遍，大多数团队可以在两周内把 Evicted 从日常事件变成罕见事件。