1. 当Pod突然被赶出家门时发生了什么早上8点你正喝着咖啡准备开始一天的工作突然手机疯狂震动——Kubernetes集群告警了打开监控一看好几个Pod状态变成了Evicted就像租客突然被房东赶出房子一样无家可归。这种情况在资源紧张的集群中特别常见我去年就遇到过某电商大促期间因为内存不足导致上百个订单服务Pod被集体驱逐的惨案。Pod被驱逐本质上是一种保护机制。当节点资源CPU/内存/磁盘不足时kubelet会像智能管家一样根据Pod的优先级和服务质量QoS决定哪些Pod应该被牺牲。这个过程就像飞机超售时的升舱策略经济舱乘客Burstable Pod会比头等舱乘客Guaranteed Pod先被请下飞机。查看被驱逐Pod最直接的方式是kubectl get pods -A | grep Evicted但这样只能看到结果我们需要像侦探一样找出真正的凶手。这时候describe命令就是你的放大镜kubectl describe pod pod-name -n namespace重点查看Events部分常见的犯罪证据包括The node was low on resource: memory内存不足failed to pull image nginx:latest镜像拉取失败node has taint {node.kubernetes.io/unschedulable: }节点污点2. 五大常见驱逐原因与精准诊断术2.1 资源不足节点超载的紧急处理这是最常见的驱逐原因就像早高峰挤不进地铁一样。上周我们一个生产集群就因此损失了20%的Pod。通过以下命令可以快速诊断# 查看节点资源压力 kubectl top nodes # 检查磁盘空间 kubectl describe node node-name | grep -A 10 Allocated resources内存不足时kubelet会按照这个顺序驱逐PodBestEffort Pods没设资源限制的Burstable Pods部分设限的Guaranteed Pods完全设限的紧急处理三板斧立即扩容如果是云环境最快方式是垂直扩容节点# AWS节点扩容示例假设使用eksctl eksctl get nodegroup --clustercluster-name eksctl scale nodegroup --clustercluster-name --nameng-name --nodesnew-count临时清理快速释放节点资源# 清理被驱逐的Pod kubectl delete pod --field-selector status.phaseFailed -n namespace # 清理悬空镜像 docker system prune -a -f资源调配调整Pod资源请求# pod.yaml片段示例 resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m2.2 镜像拉取失败破解下载中断困局这个问题就像做饭时发现食材缺货。最近某次升级中我们因为镜像仓库证书过期导致全集群Pod被驱逐。诊断命令kubectl describe pod pod-name | grep -i failed to pull kubectl get events -A | grep -i pull常见错误类型ErrImagePull根本拉不动认证/网络问题ImagePullBackOff重试多次失败解决方案工具箱检查镜像标签是否存在# 对于Docker Hub curl -s https://registry.hub.docker.com/v2/repositories/user/repo/tags/ | jq配置镜像拉取密钥# secret.yaml示例 apiVersion: v1 kind: Secret metadata: name: regcred data: .dockerconfigjson: base64-encoded-auth type: kubernetes.io/dockerconfigjson设置镜像拉取策略imagePullPolicy: IfNotPresent # 优先使用本地镜像2.3 节点污点处理不欢迎告示牌节点污点就像酒店门口的仅限VIP标识。曾经有团队因为忘记设置容忍度导致整个微服务无法调度。检查命令kubectl describe node node-name | grep Taints kubectl get pod pod-name -o yaml | grep tolerations -A 5典型场景专用GPU节点acceleratornvidia维护模式node.kubernetes.io/maintenance应对策略添加对应容忍度tolerations: - key: node.kubernetes.io/maintenance operator: Exists effect: NoSchedule临时移除污点维护结束后需恢复kubectl taint nodes node-name node.kubernetes.io/maintenance-3. 从救火到防火构建稳定防线3.1 实时监控给集群装上烟雾报警器去年双11我们通过提前设置的监控规则在内存使用达85%时就触发自动扩容避免了大规模驱逐。推荐配置# Prometheus告警规则示例 - alert: NodeMemoryPressure expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 15 for: 5m labels: severity: critical annotations: summary: Node memory critically low (instance {{ $labels.instance }})关键监控指标节点内存/CPU/磁盘压力Pod OOMKilled次数镜像拉取失败率3.2 资源规划制定合理的居住政策我们通过以下配置将生产环境Pod驱逐率降低了90%# 命名空间资源配额示例 apiVersion: v1 kind: ResourceQuota metadata: name: mem-cpu-quota spec: hard: requests.cpu: 20 requests.memory: 100Gi limits.cpu: 40 limits.memory: 200Gi最佳实践Guaranteed Pod占比应超过60%关键服务设置PriorityClassapiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 10000003.3 自动修复配置集群免疫系统这是我们的终极解决方案——配置了如下自动修复流程后已经连续200天没处理过手动驱逐告警# 使用Cluster Autoscaler --scale-down-utilization-threshold0.5 --scale-down-unneeded-time10m完整防护体系包括垂直Pod自动缩放器VPA水平Pod自动缩放器HPA节点自动缩放CA使用PodDisruptionBudget保护关键服务apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: minAvailable: 2 selector: matchLabels: app: zookeeper4. 特殊场景下的生存指南4.1 状态服务的优雅处理数据库类Pod被驱逐时我们吃过数据损坏的亏。现在都会这样配置lifecycle: preStop: exec: command: [/bin/sh, -c, pg_ctl stop -m fast] terminationGracePeriodSeconds: 60关键注意事项为有状态服务配置适当的PDB使用本地存储时设置nodeAffinity备份volumeBeforeEviction: true4.2 内核级优化给kubelet调参某次性能调优中我们发现默认参数并不适合SSD节点# kubelet参数优化 --eviction-hardmemory.available500Mi,nodefs.available10% --eviction-minimum-reclaimmemory.available0Mi,nodefs.available500Mi --eviction-pressure-transition-period1m4.3 大规模集群的批量处理当需要清理上千个被驱逐Pod时# 批量清理所有命名空间 kubectl get pods -A --field-selector status.phaseFailed -o json | \ jq -r .items[] | \(.metadata.namespace) \(.metadata.name) | \ xargs -n2 bash -c kubectl delete pod -n $0 $1记得先确认要删除的Pod列表kubectl get pods -A --field-selector status.phaseFailed | wc -l处理Pod驱逐就像照顾一个繁忙的公寓楼需要平衡资源分配、处理突发状况、维护基础设施。经过多次实战我现在会定期进行消防演练故意触发驱逐来测试系统的恢复能力。最近一次演练中我们的自动修复系统在3分钟内就恢复了所有被驱逐的服务这才是真正可靠的云原生架构。