被驱逐是什么
被驱逐表示节点为了给自己减压,主动终止了运行中的对象。它不是因为应用崩溃,而是节点在磁盘、内存或进程数接近阈值时的自保行为。判断这条信号的关键在事件:事件里会写明是哪种资源低于阈值,据此可以判断是容量不足还是清理不及时。
为什么对象删不掉
被驱逐的对象常常保留在列表里显示为已驱逐状态,不会被自动清除。这是有意设计:保留现场便于排查,但也会让列表变脏、占用查询结果。清理这类对象不会影响由控制器管理的业务——控制器早已在其他地方重建了替代实例。
基本信息
| 适用环境 | 任何 Kubernetes 发行版,由节点上的组件执行 |
|---|---|
| 触发资源 | 根文件系统空间、镜像文件系统空间、可分配内存、可分配进程数 |
| 与崩溃的区别 | 应用本身正常,是节点主动终止 |
| 与内存超限的区别 | 后者由容器自身上限触发,属于容器级 |
| 对象状态 | 保留在列表中显示为已驱逐,需要手工清理 |
| 顺序依据 | 按保障等级与用量超出请求值的程度排序 |
典型使用场景
- 磁盘占满:节点根分区空间耗尽,触发批量驱逐
- 镜像堆积:历史镜像与容器层未回收,镜像分区空间不足
- 内存紧张:整体用量长期高于可用量,驱逐变频繁
- 进程数触顶:单节点上小进程过多,可分配进程数接近上限
- 巡检发现:定期扫描列表中处于已驱逐状态的对象
- 容量告警复盘:确认驱逐是否与业务增长或配置调整相关
查看与清理
查看与清理
kubectl get pods -A | grep -i evicted # 找出被驱逐的对象
kubectl describe pod web-x | grep -iE 'evicted|node has|threshold' # 看具体原因
kubectl get events --field-selector reason=Evicted --sort-by=.lastTimestamp | tail -10
kubectl get pods -A --field-selector status.phase=Failed | grep -i evicted
kubectl delete pod web-x # 清理残留对象驱逐信号对照
| 信号 | 常见触发 | 缓解方向 |
|---|---|---|
| 根文件系统可用空间 | 日志与临时文件堆积 | 清理日志、调整保留策略 |
| 镜像文件系统可用空间 | 镜像与容器层过多 | 回收未使用镜像、加大分区 |
| 可分配内存 | 整体用量高于可用量 | 降低负载或扩容节点 |
| 可分配进程数 | 小进程数量过多 | 限制进程数或调整参数 |
被驱逐的对象需要手工删除,删除它不会影响业务,控制器管理的替代实例早已在新节点上运行。
压力未解除时重建的实例会被继续驱逐,应先把节点资源恢复到阈值之上,再考虑应用层调整。