Kubernetes 事件流分析器

要解决什么问题

一次 Pod 反复重启的事故里，最耗时的往往不是修复，而是搞清楚到底发生了什么。kubectl describe 和滚动日志要反复切换，事件流里的 BackOff、Killing、OOMKilling 混在一起，容易漏掉真正先发生的那条。手动翻 Metrics Server 里的 CPU/内存曲线更是费时。这个技能针对的就是这段「从现象到根因」的排查成本。

它如何工作

核心思路是把两条原本要分开看的信息源拉到一起：

• 事件侧：通过 Kubernetes 的 Watch API 持续监听集群事件流，拿到 Pod 生命周期中的调度、拉取镜像、启动、终止等事件，而不是等事件过期后再去查历史。
• 指标侧：从 Metrics Server 读取对应 Pod 的资源指标，尤其是内存使用趋势。
• 关联与判定：在时间线上把 Pod 生命周期事件和资源指标对齐，从而识别两类典型故障模式：

- CrashLoopBackOff：容器反复启动失败、被退避重试的模式；
- OOMKilled：容器因超出内存限制被杀掉的信号，配合内存指标可以进一步确认是否真的撞上了 limits.memory。

最终目标是让常见的 Pod 异常能被自动 triage，把「先看事件、再看指标、再对照时间线」这套流程交给技能完成。

适用边界与注意点

• 事件是实时流语义：它覆盖的是 Watch 期间发生的事件，历史事件仍需依赖持久化存储或事后查询，不做离线回放。
• OOMKilled 的判断依赖 Metrics Server 提供指标，指标缺失或延迟会削弱关联结论的可信度。
• 运行环境需要一个可用的 Docker 环境，不是裸机直跑。
• 识别的是模式而非根因：它能指出「这是 CrashLoopBackOff」或「这次终止是 OOM」，具体是配置、依赖、探针还是代码问题，仍需人工进一步定位。