Kubernetes Pod 被驱逐 — 节点压力与临时存储

读取 Evicted 事件与节点压力条件，排查 Kubernetes 驱逐原因，修复资源 requests、ephemeral-storage 限制和 kubelet 回收阈值。

现象

Pod 状态变为 Evicted 且不会被原地重启；kubectl describe pod 提示 The node was low on resource: ephemeral-storage；同一节点上的多个 Pod 同时失败；驱逐后新 Pod 因容量不足一直 Pending。

诊断

先列出失败 Pod 并查看驱逐消息：

kubectl get pods -A --field-selector status.phase=Failed -o wide
kubectl describe pod -n app orders-7c9f8b6d5-2xk4p | sed -n '/Status:/,/Events:/p'

消息通常会指出具体资源，甚至点名容器，例如某容器写入量超过 request。再看节点压力条件：

kubectl describe node ip-10-0-3-17 | grep -A8 -E 'Conditions:|Allocated resources:'

MemoryPressure、DiskPressure 或 PIDPressure 为 True 就是 kubelet 开始驱逐的直接原因。需要进入节点确认磁盘时，可用：

kubectl debug node/ip-10-0-3-17 -it --image=busybox -- df -h /var/lib/kubelet

若文件系统使用率超过驱逐阈值，同时存在大量未使用镜像，说明镜像回收没有跟上。

修复

为所有工作负载补齐 CPU、内存与 ephemeral-storage 的 requests/limits，给 emptyDir 设置 sizeLimit，日志输出到 stdout 由采集器收集而不是写入容器文件系统：

resources:
  requests:
    cpu: 250m
    memory: 256Mi
    ephemeral-storage: 1Gi
  limits:
    memory: 512Mi
    ephemeral-storage: 2Gi

为关键服务设置更高的 priorityClassName，使 kubelet 优先驱逐低优先级 Pod；清理无用镜像或扩容节点磁盘。不要只调高驱逐阈值，那只是把磁盘耗尽的时间推迟。

验证

删除遗留的 Evicted Pod，确认替代 Pod 能调度并保持 Running，节点 MemoryPressure 与 DiskPressure 均为 False；连续观察一天各 Pod 的临时存储用量，kubectl get events --field-selector reason=Evicted 不再出现新记录，才说明限制与清理真正生效。