Kubernetes 节点压力驱逐：Pod 被赶走前有很多信号

Kubernetes 节点压力驱逐：Pod 被赶走前有很多信号

一、Pod 被驱逐不是突然发生的玄学

Kubernetes 里 Pod 因为节点压力被驱逐时，很多人第一反应是看应用日志。但节点压力驱逐通常不是应用突然崩了，而是 kubelet 根据内存、磁盘、PID 等资源压力做出的保护动作。Pod 被赶走前，系统其实已经给过很多信号。

排查这类问题，要先看节点条件和事件，再看容器日志。只盯业务日志，很可能看到的是应用被终止后的残缺信息，而不是驱逐原因。

二、节点压力信号来自多个资源维度

常见压力包括 MemoryPressure、DiskPressure、PIDPressure。

flowchart TD A[节点资源压力] --> B[MemoryPressure] A --> C[DiskPressure] A --> D[PIDPressure] B --> E[kubelet 驱逐判断] C --> E D --> E E --> F[选择 Pod 驱逐]

kubelet 会根据阈值判断是否触发驱逐。硬阈值到了就要立即处理，软阈值会结合持续时间判断。不同资源压力对应的排查方向完全不同。

三、先看事件和节点条件

基础排查命令可以从这里开始。

kubectl describe node <node-name> kubectl get events --sort-by=.lastTimestamp -A kubectl describe pod <pod-name> -n <namespace> kubectl top node

事件里通常会出现 Evicted、MemoryPressure、DiskPressure 等信息。节点 describe 能看到条件变化、资源分配和 kubelet 报告。

四、QoS 等级会影响驱逐顺序

Kubernetes 会根据 Pod QoS、资源使用和请求量选择驱逐对象。BestEffort 最危险，Burstable 次之，Guaranteed 最稳。没有设置 requests 的 Pod，在节点压力下更容易被清理。

但 Guaranteed 也不是免死金牌。节点资源真的不够时，任何 Pod 都可能受影响。资源请求只是帮助调度和驱逐排序，不是凭空变出资源。

磁盘压力经常被低估。容器日志、emptyDir、镜像层、临时文件都可能占满节点磁盘。业务看起来 CPU 和内存都正常，但 Pod 仍然因为 DiskPressure 被驱逐。

最后，要把节点压力纳入容量规划。只给应用设置 requests/limits 不够，还要监控节点可分配资源、系统预留、镜像垃圾回收和日志轮转。Pod 被驱逐时再补配置，已经是事故后动作。

驱逐排查还要看 kubelet 配置。evictionHard、evictionSoft、systemReserved、kubeReserved会影响节点给业务 Pod 留下多少空间。集群默认值不一定适合所有业务，尤其是日志量大、镜像频繁更新或节点规格偏小的环境。

临时存储也要显式声明。很多应用只设置 CPU 和内存，却不设置 ephemeral-storage。结果日志、缓存和临时文件一涨，节点磁盘压力上来，Pod 被驱逐时大家才发现调度层根本不知道它需要多少临时空间。

最后，修复动作要分短期和长期。短期可以清理镜像、扩节点、限制日志；长期要改资源请求、日志轮转、镜像缓存和节点池规划。只清一次磁盘，下次高峰还会回来。

五、总结

Kubernetes 节点压力驱逐有明确机制，不是玄学。排查要从节点条件、事件、QoS、资源请求和磁盘使用入手。Pod 被赶走前通常已经有信号，关键是监控和排障流程要先看对地方。