排查顺序是什么
把排查固化成固定顺序能显著缩短定位时间：先界定现象范围，再定位到具体对象，然后读事件、读日志，最后对齐最近发生的变更。顺序的意义在于每一步都在缩小范围，而不是靠猜。跳步的典型表现是一上来就重启，重启把重启计数、事件与上一个实例的日志这些证据一并清掉。
为什么最后一步是变更
大多数故障不是凭空出现的：某次发布、某次配置修改、某次证书轮换或节点操作往往就是根因。先看清现象再去问「最近改了什么」，用时间线对齐事件与变更，能快速验证或排除猜测。反过来先假设原因再找证据，容易被无关细节带偏。
基本信息
| 适用对象 | 工作负载、服务、网络与节点类问题均可套用 |
|---|---|
| 第一步 | 界定范围：影响面是单个实例、整组实例还是整个命名空间 |
| 第二步 | 定位对象：找到真正异常的那个资源 |
| 第三步 | 读事件：拿具体原因而非结果状态 |
| 第四步 | 读日志：含上一个实例的输出 |
| 第五步 | 对齐变更：发布时间线，找最近改动 |
典型使用场景
- 服务不可用：先确认是全挂还是部分实例异常，再逐层下钻
- 发布后异常：把发布时间与事件时间对齐，判断是否与本次发布相关
- 间歇性失败：通过多个实例的状态分布判断是节点、网络还是应用问题
- 跨命名空间问题：用全集群视角确认影响范围，避免只盯着一个命名空间
- 容量类问题：结合用量与调度事件判断是资源不足还是约束过紧
- 复盘与交接：按固定顺序记录证据，便于他人接手
排查模板
排查模板
kubectl get pods -A -o wide | grep -v -E 'Running|Completed' # 先找异常对象
kubectl get pods -A -o wide --sort-by=.spec.nodeName # 看是否集中在某节点
kubectl describe pod <名称> | sed -n '/Events:/,$p' # 读事件
kubectl logs <名称> --previous --tail=200 # 读上一个实例日志
kubectl get events -A --sort-by=.lastTimestamp | tail -20 # 全局事件时间线
kubectl rollout history deploy/<名称> # 最近发布记录每步要回答的问题
| 步骤 | 回答的问题 | 常见误区 |
|---|---|---|
| 界定范围 | 影响面有多大 | 只在一个命名空间里找原因 |
| 定位对象 | 到底哪个资源异常 | 被大量相似名称的对象干扰 |
| 读事件 | 具体原因是什么 | 只看状态结论不看事件文本 |
| 读日志 | 应用自己说了什么 | 只看当前实例，忽略上一个 |
| 对齐变更 | 最近动过什么 | 不做时间线对照 |
重启往往会清掉重启计数、事件与上一个实例的日志，没有取到证据之前尽量避免重启对象。
节点级与控制器级问题常在多个命名空间同时表现，全局视角能更快确认相关性。