节点压力驱逐是什么
kubelet 持续监测节点的 memory.available、nodefs.available、imagefs.available、pid.available 等信号，一旦触碰软阈值或硬阈值就主动驱逐 Pod 来给节点续命。硬阈值立即执行，软阈值给一段宽限期并持续观察；选择驱逐对象的顺序与 Pod 的 QoS 等级直接相关：先 BestEffort，再 Burstable，最后 Guaranteed，同等级内再按资源使用是否超过 requests 排序。
基本信息
| 执行者 | 节点上的 kubelet（不是调度器，也不经 apiserver 决策） |
|---|---|
| 监测信号 | memory.available、nodefs.available、imagefs.available、pid.available |
| 阈值类型 | 软阈值（带宽限期）与硬阈值（立即执行） |
| 驱逐顺序 | BestEffort > Burstable（超 requests 者优先）> Guaranteed |
| 表现 | Pod 状态变 Failed，原因显示 Evicted，事件里留下原文 |
典型使用场景
- Pod 突然消失：状态显示 Evicted 而非 OOMKilled，说明是被 kubelet 驱逐而不是被内核杀死
- 内存告警联动：事件里同时出现节点 MemoryPressure 与 Evicted，可确认两者因果
- 批处理与在线服务混布：低优先级批任务应设为 BestEffort 或低优先级，避免挤掉在线服务
- 磁盘写满应急：清理镜像与日志的同时预期会有一批被驱逐的 Pod 需要重建
- 容量复盘：统计一段时间内的 Evicted 事件数量，评估节点是否长期超卖
取证与核对
取证与核对
kubectl get events -A --field-selector reason=Evicted --sort-by=.lastTimestamp | tail -10
kubectl describe pod evicted-x | grep -i -A3 evicted # 事件里会写明触发的信号与阈值
kubectl get pod evicted-x -o jsonpath='{.status.reason} {.status.message}'
journalctl -u kubelet --no-pager | grep -i -E 'evict|pressure' | tail -20
kubectl describe node node1 | sed -n '/Conditions:/,/Addresses:/p' # 核对当前压力条件驱逐与杀死对照
| 现象 | 触发者 | 判定依据 |
|---|---|---|
| 状态 Evicted，原因 Evicted | kubelet 驱逐 | 节点资源触及阈值，按 QoS 与超用比例挑选 |
| 退出码 137，原因 OOMKilled | 内核 OOM killer | 容器超出自身 memory limit 被内核直接杀 |
| Pod 长时间 Terminating | 驱逐中等待宽限期 | grace period 未过，或容器忽略终止信号 |
| Pod 被重建后仍落回同一节点 | 控制器重建 | 节点资源未缓解，需要先修节点或调整调度约束 |
驱逐阈值与默认值随版本演进，且可以在 kubelet 配置中覆盖。判断线上行为时应以该节点实际生效的 kubelet 配置为准，而不是凭印象套用旧版本的默认阈值。
被驱逐的 Pod 不会自动恢复运行：由 Deployment、StatefulSet 等控制器重新创建（StatefulSet 会复用原 PVC）。如果只反复重建而没有降低节点资源水位，同一个 Pod 可能又被驱逐，形成循环。