Kubernetes Pod驱逐风暴排查：从资源压力到调度器调优的完整修复指南

Pod驱逐风暴的现象与成因

Kubernetes集群中Pod驱逐风暴（Eviction Storm）是一个令人头疼的问题：大量Pod同时被驱逐，重新调度后又再次被驱逐，形成恶性循环。典型表现为kubelet日志中密集出现资源不足或MemoryPressure等驱逐事件，应用服务大面积不可用。

驱逐风暴的根因通常不是单一资源不足，而是多个因素叠加：节点资源配置过于激进、驱逐阈值（Eviction Threshold）设置不合理、PriorityClass配置导致低优先级Pod反复被驱逐、以及调度器在高驱逐频率下做出次优调度决策。

Kubelet驱逐机制的工作原理

Kubelet的驱逐机制分为软驱逐（Soft Eviction）和硬驱逐（Hard Eviction）两种。软驱逐在资源低于阈值后等待一个宽限期（grace period），如果在宽限期内资源未恢复，则开始驱逐Pod。硬驱逐没有宽限期，一旦触发立即执行。

默认配置下，硬驱逐阈值为memory.available小于100Mi和nodefs.available小于10%。当节点内存或磁盘低于这些值时，Kubelet会按Pod优先级从低到高、按资源使用量从大到小的顺序驱逐Pod。

查看当前节点的驱逐配置和资源压力状态：

# 查看节点状况
kubectl describe node <node-name> | grep -A5 Conditions

# 查看kubelet驱逐事件
kubectl get events --field-selector reason=Evicted -A

# 查看特定节点的kubelet日志
journalctl -u kubelet | grep -i eviction

# 查看节点资源使用详情
kubectl top node

调整kubelet驱逐阈值防止雪崩

默认的驱逐阈值对于生产环境通常不够安全。100Mi的内存余量意味着当可用内存低于100Mi时才开始驱逐，此时系统可能已经处于严重压力下，驱逐操作本身也会消耗内存，进一步加剧压力。

建议将硬驱逐阈值调整为更保守的值：

# kubelet配置 /var/lib/kubelet/config.yaml
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "15%"
  nodefs.inodesFree: "10%"
  imagefs.available: "15%"
evictionSoft:
  memory.available: "1Gi"
  nodefs.available: "20%"
evictionSoftGracePeriod:
  memory.available: "1m30s"
  nodefs.available: "2m"
evictionMaxPodGracePeriodSeconds: 60
evictionMinimumReclaim:
  memory.available: "200Mi"
  nodefs.available: "5%"

关键调整说明：

1. 硬驱逐内存阈值提高到500Mi。给系统留出足够的缓冲空间，避免驱逐操作本身加剧内存压力。

2. 增加软驱逐配置。在资源压力还不严重时提前温和地驱逐低优先级Pod，避免等到硬驱逐触发时才大规模暴力驱逐。

3. 设置evictionMinimumReclaim。每次驱逐至少回收200Mi内存，避免逐个Pod驱逐但每次回收量不足，导致反复触发驱逐。

PriorityClass与PDB防止关键服务被驱逐

驱逐风暴中最致命的问题是关键服务Pod被一起驱逐。解决方案是配置PriorityClass和PodDisruptionBudget：

# 关键服务的PriorityClass
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical-service
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
---
# 批处理任务的PriorityClass
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: batch-job
value: 10000
globalDefault: false

配合PodDisruptionBudget确保关键服务的最小可用副本数：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: critical-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: critical-api

调度器调优缓解驱逐后的重新调度压力

大规模驱逐后，调度器面临大量待调度Pod的冲击。默认的调度器配置可能导致Pod被集中调度到少数节点上，再次触发这些节点的驱逐。调优方向是将资源评分策略从MostAllocated改为LeastAllocated，有效分散Pod分布，降低单节点资源压力。

监控指标与预警阈值设置

要提前发现驱逐风险，需要在Prometheus中配置关键指标的告警规则：

groups:
- name: eviction-risks
  rules:
  - alert: NodeMemoryPressureWarning
    expr: |
      (node_memory_MemAvailable_bytes
       / node_memory_MemTotal_bytes) < 0.2
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "节点内存可用率低于20%"
  - alert: HighEvictionRate
    expr: |
      increase(kube_pod_container_status_reason
        {reason="Evicted"}[30m]) > 5
    labels:
      severity: critical
    annotations:
      summary: "30分钟内驱逐事件超过5次"

这套规则在资源压力达到驱逐阈值的50%时就发出预警，给运维团队留出干预时间，避免等到驱逐已经发生才响应。

完整的驱逐风暴治理不是单一配置调整，而是从阈值设置、优先级划分、调度策略到监控预警的系统性工程。每个环节都需要与集群的实际资源状况和应用特性匹配，定期做混沌工程验证才能确保方案在真实故障场景下有效。