Kubernetes 事故响应：应对节点压力与 Pod 驱逐的实战指南

场景

假设你在深夜收到 Prometheus 告警，生产 Kubernetes 集群中一个关键微服务的 p99 延迟突增，同时出现少量 HTTP 503。初始检查显示某个工作节点状态为 NotReady，其他节点出现 MemoryPressure 和 DiskPressure。初步判断是资源争抢导致节点不稳定，Pod 开始被驱逐，但根因未知。

症状

• 应用响应时间显著上升，部分请求超时。
• Node 状态为 MemoryPressure 或 DiskPressure。
• kubectl get events 中出现大量 Evicted 和 OOMKilling。
• Pod 频繁重启，Restart 计数持续增加。
• kubectl top nodes 显示某个节点 CPU 或内存使用率超过 90%。

诊断

诊断的关键是区分“节点过载”还是“某个 Pod 失控”。首先获取集群全局视图，然后逐层下钻。

1. 查看节点状态和事件：kubectl get nodes 和 kubectl describe node <node>。关注 Conditions。
2. 查看资源使用：kubectl top nodes 和 kubectl top pods -n <namespace>。
3. 检查告警 Pod 的调度分布：kubectl get pods -o wide。
4. 深入问题 Pod：kubectl describe pod <pod> -n <namespace>，查看 Last State 和 Events。
5. 如果存在 HPA，检查是否扩展过快：kubectl get hpa -n <namespace>。
6. 查阅历史指标：如果使用 Prometheus，查询 node_memory_available、container_cpu_usage_seconds_total 等。

命令

# 快速集群健康检查
kubectl get nodes -o wide
kubectl get events --all-namespaces --sort-by=.lastTimestamp

# 资源使用概览
kubectl top nodes
kubectl top pods -A

# 细查节点压力
kubectl describe node <node> | grep -A20 'Conditions'

# 细查异常 Pod
kubectl get pod <pod> -n <namespace> -o yaml
kubectl describe pod <pod> -n <namespace>

# 查看 HPA 与扩展行为
kubectl get hpa -A
kubectl describe hpa <hpa-name> -n <namespace>

# 如果使用 metrics-server，还可以检查 API 可用性
kubectl get apiservices | grep metrics

注意：在执行任何可能导致数据丢失或服务中断的操作前，务必确认当前 ReplicaSet 副本数，并确保有最小可用副本的容错机制。

风险控制

1. 不要立即删除有问题的 Node——这可能导致级联重建。
2. 避免全局重启 Pod——使用 kubectl rollout restart 前确保有滚动窗口。
3. 隔离节点：如果某个节点持续不稳定，可以先 kubectl cordon <node>，再逐步驱离 Pod。
4. 临时降低流量：通过服务网格或入口层调整流量分配，减轻压力。
5. 检查和调整 HPA 上下限：防止失控扩展消耗全部节点资源。

回滚

如果事故是因为最近变更导致，回滚优先于大规模重构。

• HPA 变更回滚：将 HPA 的 min/max 恢复到上一个配置，或删除 HPA 以固定副本数。
• 镜像回滚：如果错误配置来自新版本镜像，执行 kubectl rollout undo deployment/<name>。
• 资源配额调整：如果错误修改了 Namespace 的 LimitRange，恢复为该 Namespace 的旧配置。
• 节点维护操作回滚：如果手动驱逐导致中断，重新调度未受影响副本。

验证

恢复后必须验证根因已被修复：

• 节点条件恢复正常（MemoryPressure 消失）。
• kubectl get nodes 全部 Ready。
• 延迟指标恢复至基线，无 503。
• kubectl get events 中不再有新的 Evicted 或 OOMKilling。
• 对 HPA 调节后的扩容曲线进行观察，确保扩展平稳。

何时提交 OpsGlobal 工单

如果以下情况满足，应立即提交 OpsGlobal 工单：

• 事故影响超过 30 分钟，且你仍无法根因定位。
• 节点或 Pod 持续进入 CrashLoopBackOff，无法自行恢复。
• 怀疑是底层基础设施问题，但你没有平台权限。
• 需要 7×24 小时远程 SRE 支持，但当前团队人手不足。

在工单中，附上 kubectl 输出、事件日志和时间线，OpsGlobal 工程师可以快速介入。