场景

凌晨 3 点 14 分，你的传呼机响了。生产集群运行着面向客户的电商业务，正在降级。用户看到 503 错误，SRE 仪表盘显示被驱逐的 Pod 激增。你在 ubuntu-west1-a 有 3 个节点，ubuntu-west1-b 有 2 个，周围没有其他人。这是经典的 Kubernetes 可靠性事件：节点压力、无法调度的负载、级联故障。

症状

• Pod 不断重启或一直 Pending。
• 节点出现 Pressure 条件（MemoryPressure、DiskPressure 或 PIDPressure）。
• kubectl get events 中出现驱逐失败的记录。
• API server 延迟增加。
• kubectl top nodes 可能显示 CPU 很低但内存很高。

诊断

先快速界定范围，不要轻易变更。先运行状态检查：

• kubectl get nodes -o wide – 观察节点状态和污点。
• kubectl describe node <node> – 检查 Conditions 部分，如果 MemoryPressure=True 或 DiskPressure=True，就是节点压力。
• kubectl top node – 查看谁在消耗资源。
• kubectl get pods --all-namespaces -o wide – 查看哪些 Pod 在哪个节点，哪些处于 Error 或 OOMKilled 状态。

然后聚焦一个受影响的 Pod：

• kubectl get pod <pod> -n <ns> -o yaml – 查看 lastState.terminated.reason（通常是 OOMKilled 或 Evicted）。
• kubectl logs <pod> -n <ns> --previous – 查看崩溃前的应用日志。

止血命令

不要惊慌，不要乱删。用以下命令稳定局势：

# 1. Cordon 不健康的节点，阻止新 Pod 调度上去
kubectl cordon <node>

# 2. Drain 节点安全驱逐 Pod（会尊重 PDB）
#    如果有 DaemonSet（如日志收集器），加 --ignore-daemonsets
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

Drain 会驱逐 Pod，但如果 PodDisruptionBudget 配置不当，可能会卡住。可以加超时：--grace-period=120。

如果是内存压力，可以缩减非关键负载的副本数：

kubectl scale deploy <non-critical-deploy> --replicas=0 -n <ns>

风险控制

• 永远不要在存在 DaemonSet 的情况下不带 --ignore-daemonsets 就 drain 节点。
• 只有确定 Pod 不依赖 emptyDir 数据，才使用 --delete-emptydir-data。
• 使用 PodDisruptionBudget (PDB) 保证 drain 期间最低可用性。
• 强制删除前，检查 Pod 是否属于 StatefulSet。删除 PVC 支持的 Pod 可能安全，但会丢失本地磁盘数据。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: frontend-pdb
  namespace: prod
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: frontend

回滚

如果最近一次部署触发了事件，先回滚再深入排查：

kubectl rollout undo deployment/<deployment> -n <namespace>

如果集群已经处于恶劣状态（多个节点离线），使用集群的灾备方案。对于 kubeadm 或托管集群，不修复容器运行时就不能让现有 worker 节点安全重新加入。

验证

完成 cordon/drain/回滚后：

kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide | grep -v Running
kubectl get evictions -n <ns>

从外部测试应用端点：

curl -I https://app.example.com/healthz

检查监控中的错误率和延迟。至少保持集群稳定运行 10-15 分钟，再认为事件已结束。

何时应提交 OpsGlobal 工单

很多事件你可以独自处理，但出现以下情况时请请 OpsGlobal 专家介入：

• 多个节点不可用，你不确定哪个服务是根因。
• 驱逐后磁盘仍然满，或 Docker overlay 复用失败。
• 集群的 kubelet 配置不是你自己写的，是自定义配置。
• 需要恢复 etcd 备份或重建控制平面。
• 积极调试 60 分钟后，事件原因仍不明确。

我们的工程师会 15 分钟内响应，帮你审查资源请求、监控和压测，避免再次发生。