首先要执行kubectl get events -n 查看指定命名空间下全部事件，重点排查type为warning或error、reason含failedscheduling等关键词的行，并务必添加--sort-by=.metadata.creationtimestamp确保按时间倒序显示最新事件。
排查Kubernetes集群中某个命名空间下的异常行为，首先要聚焦该命名空间内发生的全部事件——Events是K8s调度、拉取镜像、挂载存储、健康检查等关键动作的原始日志，错误几乎都藏在其中。
查看指定命名空间下的所有Events
执行命令：kubectl get events -n <namespace></namespace>。例如命名空间叫prod-api，就运行kubectl get events -n prod-api。
这条命令会输出一个表格，包含NAMESPACE、LAST SEEN、TYPE、REASON、OBJECT、MESSAGE六列。重点盯住TYPE为Warning或Error的行，以及REASON列里的关键词，比如FailedScheduling、ImagePullBackOff、FailedMount。
按时间倒序查看最新事件
默认输出不保证时间顺序，容易漏掉刚发生的报错。必须加--sort-by=.metadata.creationTimestamp参数强制倒序：
kubectl get events -n prod-api --sort-by=.metadata.creationTimestamp
这一步不能省——很多故障（如PVC Pending、Pod卡在ContainerCreating）的根因事件就发生在最近10秒内，正序排列时它可能沉在几百行底部。
筛选特定资源关联的Events
当已知问题Pod名为auth-service-7f8d9c4b5-xvq2r，可精准过滤其事件：
方法一：用field-selector精确匹配
kubectl get events -n prod-api --field-selector involvedObject.name=auth-service-7f8d9c4b5-xvq2r
方法二：结合grep快速定位（适合终端快速扫视）
kubectl get events -n prod-api | grep auth-service-7f8d9c4b5
【注意】field-selector方式更可靠，grep可能误匹配到MESSAGE里的字符串，导致漏判或误判。
深入查看Events详情与上下文
第一步：先用describe命令展开目标Pod的完整描述，Events块自动置顶显示
kubectl describe pod auth-service-7f8d9c4b5-xvq2r -n prod-api
第二步：若Events区域信息过简，需手动查调度器日志确认是否被截断
kubectl logs kube-scheduler -n kube-system --since=5m | grep "auth-service-7f8d9c4b5"
这一步能捕获describe未展示的中间调度决策细节，比如节点筛选被某条污点规则静默拒绝，而Events里只写“0/3 nodes are available”。
