Kubernetes 事件响应：诊断和解决集群可靠性问题

场景

某生产 Kubernetes 集群中，多个 Pod 反复崩溃并进入 CrashLoopBackOff 状态，导致服务降级。

症状

• kubectl get pods 显示大量 CrashLoopBackOff
• kubectl describe pod 中的 Last State 为 Error 或 OOMKilled
• 节点 NotReady 或内存/CPU 压力大（kubectl top nodes）

诊断

1. 检查节点健康：kubectl get nodes -o wide 查看状态，journalctl -u kubelet 检查 kubelet 日志。
2. 查看事件：kubectl get events --sort-by=.metadata.creationTimestamp 定位时间线。
3. 分析 Pod 日志：kubectl logs <pod> --previous 获取上次崩溃的日志。
4. 检查资源配额：kubectl describe quota 验证是否超标。

命令示例

# 获取所有命名空间中的崩溃 Pod
kubectl get pods --all-namespaces | grep -E 'CrashLoop|Error|OOM'

# 查看特定 Pod 的详细事件
kubectl describe pod my-app-5d8c9b7f6-abcde -n production

# 检查节点资源
kubectl top nodes

# 查看节点上的 Pod 资源
kubectl describe node worker-node-1 | grep -A 5 'Non-terminated Pods'

风险控制

• 在修改资源前，先通过 kubectl cordon <node> 将节点标记为不可调度，避免新 Pod 调度到故障节点。
• 使用 kubectl drain <node> --ignore-daemonsets --delete-local-data 安全排空节点。
• 增加资源请求/限制前，确认节点有足够资源。

回滚

如果问题由最近的配置变更引起： - 回滚 Deployment：kubectl rollout undo deployment/my-app - 使用特定版本：kubectl rollout undo deployment/my-app --to-revision=2 - 确认回滚：kubectl rollout status deployment/my-app

验证

• 检查 Pod 状态：kubectl get pods -o wide 确认 Running
• 确认服务端点：kubectl get endpoints <service> 显示正确的 IP
• 应用级健康检查：发起 HTTP 请求验证响应正常
• 监控指标：查看集群监控面板（如 Prometheus）确认 CPU/内存恢复正常

何时提交 OpsGlobal 工单

• 节点完全不可用且无法排空
• 持久卷故障导致数据不可用
• 控制平面组件异常（etcd、apiserver）
• 需要紧急补丁但缺乏内部 expertise
• 24 小时内无法恢复的复杂网络问题