Kubernetes 事件应急手册

为什么需要它

Kubernetes 集群出故障时，第一现场通常是乱的：某个 Deployment 的 Pod 陷入 CrashLoopBackOff，kubectl describe pod 输出几十页；OOMKilled 的退出码和 Limit 设置混在一起，很难快速判断到底是配额太紧还是代码有内存泄漏；节点压力带来的问题更隐蔽，Pod 反复被驱逐却没人去看 Node 的水位。运维者往往要在 kubectl、metrics 和事件流之间来回切换，靠临场经验拼凑一个能用的排查路径。

这份技能要解决的就是这件事：把集群事件响应做成结构化流程，而不是依赖个人经验。

它如何工作

技能围绕三个工具展开，按固定顺序推进排查：

• kubectl：读取集群资源当前状态与描述信息，确认 Pod、ReplicaSet、Node 的实际表现；
• kube-state-metrics：提供工作负载与资源指标，佐证资源消耗的变化；
• Kubernetes Events API：拉取事件流，按时间线还原故障发生的先后顺序。

在此之上，技能固化了三类高频场景的处置程序：

• Pod 崩溃诊断：从 CrashLoopBackOff、ImagePullBackOff 等常见状态入手，结合描述与事件定位根因；
• OOMKill 分析：区分节点内存压力与容器 Limit 触发的 OOM，判断该调配额还是改代码；
• 节点压力分流：识别 Node 资源压力导致的驱逐与调度失败，先缓解压力再修复业务。

每个场景都遵循「先收集证据、再分类、后处置」的流程，避免上来就重启或扩副本这类会掩盖问题的快速操作。

适用边界

• 需要可用的 Docker 环境（上游要求）；
• 流程依据来自 Kubernetes 上游公开文档（kubernetes/kubernetes 的 README），未覆盖的故障类型仍需结合集群实际情况人工判断；
• 技能聚焦诊断与分流环节，处置方案落地前请先确认对当前集群版本与配置的适用性。