Kubernetes 应急响应：集群可靠性实战指南

场景

某工作节点因硬件故障宕机，导致其上运行的 Pod 被驱逐，服务降级。

症状

• 错误率上升，响应延迟增加
• 部分 Pod 处于 Pending 状态（无可用节点）
• 监控告警触发（如 Node Down、Pod CrashLoopBackOff）

诊断

1. 检查节点状态：kubectl get nodes -o wide 查看 NotReady 节点。
2. 查看节点详情：kubectl describe node <node> 确认条件（Ready=False）及事件。
3. 查看受影响的 Pod：kubectl get pods --all-namespaces --field-selector spec.nodeName=<node> 列出该节点上的 Pod。
4. 检查集群事件：kubectl get events --all-namespaces --sort-by='.lastTimestamp' 查找驱逐记录。
5. 使用 metrics server 或 Prometheus 确认资源压力。

命令

# 标记节点不可调度
kubectl cordon <node>

# 排空节点（安全迁移 Pod）
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

# 若节点彻底故障，无需排空，直接驱逐 Pod
kubectl delete pod <pod> --grace-period=0 --force

# 添加新节点或修复后重新加入集群
kubectl uncordon <node>

风险控制

• 排空前确认 PodDisruptionBudget (PDB) 已配置，避免服务完全中断。
• 使用 --ignore-daemonsets 跳过 DaemonSet。
• 若 Pod 使用 emptyDir，需谨慎 --delete-emptydir-data。
• 避免同时排空过多节点。

回滚

• 若排空失败（例如 PDB 阻止），取消操作：kubectl uncordon <node> 并重新评估。
• 对于因更新导致的故障，使用 kubectl rollout undo deployment/<name> 回滚。
• 若数据丢失，从备份恢复 PersistentVolume 或使用快照。

验证

• 节点恢复后，kubectl get nodes 确认 Ready。
• kubectl get pods --all-namespaces -o wide 检查 Pod 运行状态及所在节点。
• 访问服务端点，测试功能正常。
• 监控指标（错误率、延迟）回归基线。

何时提交 OpsGlobal 工单

• 节点故障涉及存储、网络或持久数据。
• 需要高级调试（如内核、CSI 插件问题）。
• 团队缺乏 24x7 值守能力或 SLA 覆盖不足。
• 事故原因不明确，需专家分析。