Kubernetes 事故响应与集群可靠性实践：节点压力与 Pod 驱逐处理

场景

某 Kubernetes 集群中，节点因磁盘空间不足或内存压力触发 kubelet 的驱逐机制，导致运行中的 Pod 被强制终止并重新调度。

症状

• Pod 状态变为 Evicted 或 Failed
• kubectl describe node 显示 DiskPressure 或 MemoryPressure 条件为 True
• 节点上 df -h 显示磁盘使用率 > 85% 或 free -m 显示可用内存极低
• 集群监控告警（如 Prometheus + Alertmanager）触发 NodeDiskPressure 或 NodeMemoryPressure

诊断

1. 确认受影响的节点和 Pod： bash kubectl get pods --all-namespaces | grep Evicted kubectl describe node <node-name> | grep -A5 Conditions
2. 登录节点检查资源使用： bash ssh <node-ip> df -h free -m docker system df # 若使用 Docker journalctl -u kubelet -n 100 --no-pager | grep -i evict
3. 查看 kubelet 驱逐日志： bash journalctl -u kubelet -n 200 --no-pager | grep -E "(eviction|pressure|threshold)"

风险控制

• 尽快驱逐非关键 Pod 或清理旧日志/镜像释放空间： bash # 安全示例：删除未使用的 Docker 镜像（注意确认） docker image prune -a --force --filter "until=24h" # 清理残留容器日志（谨慎，避免删除活动容器日志） find /var/log/containers -name "*.log" -mtime +7 -delete
• 临时增加节点资源（如调整 --eviction-hard 阈值，需重启 kubelet，风险较高）
• 如果节点关键，谨慎使用 kubectl cordon 和 kubectl drain 将其下线

回滚

若清理操作导致问题，可从备份恢复数据。但通常回滚是针对驱逐的 Pod： - 被驱逐的 Pod 如果由 Deployment 管理，会自动重新调度到其他节点。确认调度正常： bash kubectl rollout status deployment/<name> -n <namespace> - 如果 Pod 未被自动创建，手动编辑 Deployment 增加副本数或重启： bash kubectl scale deployment <name> --replicas=3 -n <namespace> kubectl rollout restart deployment <name> -n <namespace> - 回滚节点配置：如果修改了 kubelet 参数，恢复原值并重启 kubelet。

验证

• 节点条件恢复为 False： bash kubectl describe node <node-name> | grep -A5 Conditions | grep -E "(DiskPressure|MemoryPressure)"
• 所有预期 Pod 处于 Running 状态： bash kubectl get pods --all-namespaces | grep -v Running | grep -v Completed
• 集群监控中告警解除

何时提交 OpsGlobal 工单

• 节点资源压力反复出现，无法通过临时清理解决
• 多个节点同时进入压力状态，影响集群整体可用性
• 需要长期优化集群规格、调整驱逐策略或引入自动扩缩容
• 团队缺乏 Kubernetes 深度运维经验，需要专家协助配置和复盘

向 OpsGlobal 提交工单时，请提供诊断命令的输出、节点资源趋势图以及受影响 Pod 名称，以便快速响应。