Kubernetes容器编排实战：Pod驱逐机制与故障应急响应处理指南

Pod驱逐机制是Kubernetes稳定性的核心防线

Kubernetes容器编排中，Pod驱逐（Eviction）是节点压力下的自动保护机制，也是SRE稳定性工程必须深入理解的一环。当节点资源不足时，kubelet会主动驱逐低优先级Pod，为高优先级服务腾出资源。理解驱逐的触发条件、评分算法和防御策略，直接关系到生产环境的稳定性。

节点压力驱逐的触发条件

kubelet监控节点的四类资源：内存、磁盘inode、磁盘文件系统、pid。每类资源都设有驱逐信号（Eviction Signal）和阈值（Eviction Threshold）。当可用资源低于阈值时，kubelet启动驱逐流程。

默认的内存驱逐阈值是memory.available<100Mi，即节点可用内存低于100MiB时触发。磁盘驱逐阈值是nodefs.available<10%和imagefs.available<15%。这些默认值对大型集群来说过于激进，线上环境通常需要根据节点规格调整：

# kubelet配置
--eviction-hard=memory.available<500Mi,nodefs.available<10%,imagefs.available<15%
--eviction-soft=memory.available<1Gi,nodefs.available<15%
--eviction-soft-grace-period=memory.available=2m,nodefs.available=5m
--eviction-max-pod-grace-period=60

软驱逐阈值（eviction-soft）触发后不会立即驱逐，而是等待宽限期（grace-period）到期。这段时间内如果资源恢复到阈值以上，驱逐不会发生。软硬驱逐配合使用，可以有效减少因瞬时压力造成的Pod抖动。

驱逐评分与Pod选择算法

当需要驱逐Pod时，kubelet按以下维度对Pod评分：Pod优先级（PriorityClass）、资源请求量、本地数据量、创建时间。评分越高的Pod越先被驱逐。

一个常见的运维误区：认为QoS Class为Guaranteed的Pod不会被驱逐。事实上，Guaranteed Pod只是评分更低，当节点压力极端时同样会被驱逐。真正的保障手段是设置PodDisruptionBudget和PriorityClass，并在节点层面做好资源预留。

故障应急响应：驱逐风暴的处置

驱逐风暴是指多个节点同时触发驱逐，大量Pod在集群中重新调度，导致剩余节点也达到资源阈值，形成级联驱逐。这是Kubernetes运维中最危险的故障模式之一。

处置步骤：

1. 立即冻结调度器：kubectl cordon所有受影响节点，防止新Pod被调度到压力节点。

2. 手动缩容非关键工作负载：临时降低Deployment副本数，释放资源。

3. 检查集群自动扩缩容（Cluster Autoscaler）是否正常工作，必要时手动添加节点。

4. 排查根因：是真实负载增长，还是某个Pod内存泄漏导致节点资源耗尽？kubectl top pods -A --sort-by=memory快速定位资源消耗Top Pod。

监控告警体系建设

在监控告警体系中，以下指标必须纳入告警规则：

# Prometheus告警规则示例
- alert: NodeUnderMemoryPressure
  expr: kube_node_status_condition{condition="MemoryPressure",status="true"} == 1
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "Node {{ $labels.node }} under memory pressure"

- alert: PodEvictionRate
  expr: rate(kube_pod_evicted_total[5m]) > 0.5
  for: 1m
  labels:
    severity: critical

Pod驱逐率告警应设为P0级别——当每分钟驱逐超过0.5个Pod时，意味着集群已经开始不稳定，需要在用户感知之前介入。

混沌工程验证驱逐策略

理论上的驱逐策略需要通过混沌工程来验证。使用Chaos Mesh或Litmus注入节点内存压力，观察驱逐行为是否符合预期：

用stress-ng在节点上制造内存压力：kubectl run stress --image=progrium/stress -- --vm 2 --vm-bytes 80%，观察kubelet是否按预期的优先级顺序驱逐Pod。测试重点确认：Guaranteed Pod是否在Burstable Pod之前保留，PriorityClass高的工作负载是否得到了保护。

混沌工程的价值在于：在真实故障发生之前，暴露配置中的隐患。驱逐策略没有经过压力测试的集群，本质上就是在赌运气。