Pod驱逐不是故障而是Kubernetes主动维持稳定的核心机制；需通过事件日志、节点状态和磁盘细节快速定位内存/Disk/PID压力类型，并按类型采取资源配额收紧、QoS升级、镜像/日志清理及kubelet阈值调优等针对性措施。
生产环境的 Pod 驱逐不是故障，而是 Kubernetes 主动维持系统稳定的核心机制。关键在于把“被动挨打”变成“主动防御”——既要快速识别驱逐根源，也要从架构和配置层面切断反复触发的链条。
快速定位驱逐原因
发现 Evicted Pod 后，别急着删，先查三处：
-
Pod 事件日志：运行
kubectl describe pod <pod-name> -n <ns>，重点看 Events 区域，如 "The node was low on resource: memory" 直接指明压力类型 -
节点资源水位：用
kubectl top node查内存/CPU 使用率；再执行kubectl describe node <node-name>，在 Conditions 和 Allocatable/Allocated 部分确认 MemoryPressure、DiskPressure 是否为 True -
磁盘细节：若提示 disk 压力，进一步区分是
nodefs（日志、emptyDir 占满根分区）还是imagefs（镜像层堆积、容器写层膨胀），可通过df -h登录节点验证
按压力类型针对性处理
不同资源压力，应对策略差异明显：
-
内存压力：最危险，可能引发 OOM Killer 杀进程。优先检查是否有 Pod 未设 memory limits 或实际用量远超 requests；临时缓解可清理缓存（
echo 1 > /proc/sys/vm/drop_caches），但根本要靠资源配额收紧 + QoS 等级提升 -
磁盘压力（nodefs）：常见于日志爆炸或大量临时卷残留。启用 logrotate、限制容器日志大小（
--log-opt max-size=50m --log-opt max-file=3），定期清理/var/log/pods和/var/lib/kubelet/pods -
磁盘压力（imagefs）：镜像过多或 dangling layer 未清理。配置 kubelet 的
--image-gc-high-threshold（默认 85%）和--image-gc-low-threshold（默认 80%），并定期执行crictl rmi --prune
预防性加固配置
避免反复驱逐，得从 kubelet 层面调优：
- 设置合理的
--eviction-hard：比如memory.available<1Gi、nodefs.available<5%，留出缓冲空间，而非用默认的 100Mi/10% - 预留系统资源：
--system-reserved=memory=1Gi、--kube-reserved=memory=500Mi，防止 kubelet 自身被挤占而失联 - 启用最小回收：
--eviction-minimum-reclaim=memory.available=256Mi,nodefs.available=1Gi，确保每次驱逐后释放足够资源，避免震荡 - 延长压力状态过渡期：
--eviction-pressure-transition-period=5m，防止指标短暂抖动就反复触发 Condition 切换
应用层抗驱逐设计
让 Pod 在压力下更“耐扛”：
- 所有容器必须声明
resources.requests和limits，且尽量让 request ≈ limit（升为 Guaranteed QoS），避免被优先驱逐 - 对非关键任务（如批处理 Job），显式设置
priorityClassName为低优先级，与核心服务隔离 - 关键服务 Pod 加 toleration 容忍节点污点，例如容忍
node.kubernetes.io/memory-pressure:NoExecute并设tolerationSeconds: 120，争取缓冲时间 - 配置合理的
terminationGracePeriodSeconds（如 30–60 秒），配合应用优雅关闭逻辑，减少数据丢失风险
