Pod驱逐问题的典型场景
Kubernetes集群中Pod被驱逐是运维团队经常遇到的故障类型。驱逐本身是kubelet保护节点的机制——当节点资源压力过大时，kubelet按优先级终止Pod以回收资源。问题在于，被驱逐的Pod如果属于关键业务服务，将直接导致服务中断或降级。
Pod驱逐的常见触发条件：节点磁盘压力（DiskPressure）、内存压力（MemoryPressure）、PID压力（PIDPressure）。其中磁盘压力最容易被忽略——日志文件未轮转、容器镜像堆积、临时文件未清理都可能在短时间内耗尽节点磁盘空间。
驱逐事件的定位方法
排查Pod驱逐的第一步是确认驱逐原因。kubectl describe node输出的Conditions字段会显示节点当前状态：
# 查看节点状态和资源压力
kubectl describe node node-name | grep -A 5 Conditions
# 输出示例：
# Conditions:
# Type Status Reason
# MemoryPressure True NodeHasInsufficientMemory
# DiskPressure False NodeHasNoDiskPressure
# PIDPressure False 查看Pod的驱逐事件记录：
# 查看Pod事件
kubectl get events --field-selector reason=Evict -A
# 查看具体Pod的驱逐原因
kubectl describe pod pod-name -n namespace | grep -A 10 Eventskubelet日志也包含详细的驱逐决策过程：
# 查看kubelet驱逐日志
journalctl -u kubelet | grep -i evict资源请求与限制的合理配置
Pod驱逐的根本原因往往是资源分配不合理。未设置requests和limits的Pod可以无限制地消耗节点资源，挤占其他Pod的配额：
# 合理的资源配额配置
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1000m"
memory: "1Gi"
# LimitRange设置命名空间默认值，防止未配额Pod
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
type: Containerrequests决定调度时的资源预留，limits决定运行时的资源上限。二者差距过大（超配比超过3:1）会导致节点实际资源消耗远超调度预期，增加驱逐风险。
QoS等级与驱逐优先级
Kubernetes根据Pod的资源配置将其分为三个QoS等级，驱逐时按等级从低到高终止：
Guaranteed：requests等于limits，内存和CPU都设置了。最高优先级，只在系统级压力下被驱逐。
Burstable：设置了requests但limits不完全等于requests。中等优先级。
BestEffort：未设置requests和limits。最低优先级，最先被驱逐。
关键业务服务必须配置为Guaranteed等级：
# Guaranteed QoS - requests和limits完全一致
resources:
requests:
cpu: "1000m"
memory: "2Gi"
limits:
cpu: "1000m"
memory: "2Gi"节点磁盘压力的预防与处理
磁盘压力引发的驱逐占运维故障的相当比例。日志管理和镜像清理是两个主要抓手：
# 配置容器日志轮转 /etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "50m",
"max-file": "3"
}
}
# 手动清理未使用的容器镜像
crictl rmi --prune
# 配置kubelet自动镜像回收
# /var/lib/kubelet/config.yaml
imageGCHighThresholdPercent: 80
imageGCLowThresholdPercent: 60日志收集应当从本地文件模式切换到Sidecar或DaemonSet模式，将日志直接发送到集中式日志系统，避免本地磁盘堆积。
PDB与优雅驱逐保障
PodDisruptionBudget（PDB）确保在主动驱逐场景（节点维护、集群缩容）下维持服务的最小可用副本数：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api-server-pdb
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app: api-serverPDB仅在主动驱逐场景生效，kubelet因资源压力发起的被动驱逐不受PDB约束。因此，PDB不能替代合理的资源配置，二者必须结合使用。
完整的Pod驱逐防控体系需要从资源规划、QoS分级、磁盘管理、PDB保障四个层面协同实施。任何单一手段都无法完全避免驱逐，纵深防御才是可靠方案。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/kubernetespod-qu-zhu-wen-ti-pai-cha-shi-zhan-cong-zi-yuan/
