Kubernetes Pod驱逐机制深度解析与资源配额管理

Pod驱逐的触发条件

Kubernetes节点在资源压力下会主动驱逐Pod以保护节点稳定性。驱逐由kubelet执行，分为软驱逐（Soft Eviction）和硬驱逐（Hard Eviction）两类。软驱逐给予宽限期，硬驱逐立即执行。

默认硬驱逐阈值：

– memory.available低于100Mi：可用内存低于100Mi时立即驱逐

– nodefs.available低于10%：节点文件系统可用空间低于10%时驱逐

– nodefs.inodesFree低于5%：inode数低于5%时驱逐

– imagefs.available低于15%：镜像文件系统空间低于15%时驱逐

当节点内存或磁盘达到阈值，kubelet按Pod优先级和资源使用量排序，先驱逐低优先级、超量使用资源的Pod。

配置自定义驱逐策略

在kubelet配置文件中自定义驱逐参数：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "15%"
  imagefs.available: "20%"
evictionSoft:
  memory.available: "1Gi"
  nodefs.available: "20%"
evictionSoftGracePeriod:
  memory.available: "2m"
  nodefs.available: "5m"
evictionMaxPodGracePeriod: 60
evictionMinimumReclaim:
  memory.available: "200Mi"
  nodefs.available: "5%"

软驱逐配置了2分钟和5分钟的宽限期，给应用时间做优雅退出。evictionMinimumReclaim确保每次驱逐释放足够资源，避免频繁触发驱逐。

Pod驱逐的优先级排序逻辑

kubelet驱逐Pod时按以下顺序排序：

1. Pod优先级（PriorityClass）：高优先级Pod优先保留，低优先级先驱逐。系统组件的critical pod通过system-cluster-critical或system-node-critical优先级类保护。

2. 资源超量使用比：实际使用量超过请求量（request）越多的Pod越先驱逐。计算公式：

usageRatio = actualUsage / request
# usageRatio越高，越优先被驱逐

3. BestEffort Pod优先驱逐：没有设置request/limit的Pod属于BestEffort，在Burstable和Guaranteed之前被驱逐。

三者的驱逐顺序：BestEffort > Burstable > Guaranteed。

内存驱赶与OOMKilled的区别

这两个概念经常被混淆，但触发机制和表现完全不同：

驱逐（Eviction）：kubelet检测到节点内存不足，主动杀Pod。Pod状态变为Failed，reason为Evicted。驱逐是节点级保护行为。

OOMKilled：容器内存使用超过limit，内核cgroup OOM killer直接杀进程。Pod状态中containerStatuses里有lastState.terminated.reason=”OOMKilled”。这是容器级限制行为。

关键区别：驱逐由kubelet在用户态执行，OOMKilled由内核在内核态执行。驱逐会触发Pod重新调度，OOMKilled在同一个Pod内重启容器。

排查方法：

# 查看Pod是否被驱逐
kubectl get pods -A | grep Evicted

# 查看OOMKilled事件
kubectl describe pod <pod-name> | grep -A5 "OOMKilled"

# 查看cgroup OOM记录
dmesg | grep -i "oom-kill"

LimitRange与ResourceQuota的配合使用

集群级驱逐策略解决了节点压力问题，但还需要在命名空间级别控制资源分配。ResourceQuota限制命名空间资源总量，LimitRange限制每个Pod的资源范围：

# ResourceQuota：限制命名空间总资源
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-quota
  namespace: production
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    pods: "50"

---
# LimitRange：限制每个Pod的资源范围
apiVersion: v1
kind: LimitRange
metadata:
  name: mem-cpu-limit
  namespace: production
spec:
  limits:
  - type: Container
    max:
      cpu: "4"
      memory: 8Gi
    min:
      cpu: "100m"
      memory: 128Mi
    default:
      cpu: "500m"
      memory: 512Mi
    defaultRequest:
      cpu: "200m"
      memory: 256Mi

LimitRange的default字段确保未指定limit的容器获得默认值，防止BestEffort Pod无限消耗节点内存导致驱逐。

监控驱逐事件与容量规划

持续监控驱逐事件可以提前发现资源瓶颈：

# 通过kubelet指标监控驱逐
curl http://<node-ip>:10250/metrics | grep eviction

# 关键指标
# kubelet_eviction_stats_present: 是否有驱逐信号达到阈值
# kubelet_eviction_threshold_met: 当前哪些驱逐阈值被触发

在Grafana中配置驱逐告警面板，监控以下关键信号：

– memory.available_bytes趋势下降速度

– 驱逐事件频率（超过1次/小时需要扩容）

– Pod重启次数（OOMKilled频率）

容量规划建议：节点内存预留20%给系统进程和kubelet，设置Pod request为实际使用量的1.2倍，limit为request的2倍，在保障性能的同时留出驱逐缓冲空间。