Kubernetes 生产排障先看事件再看日志一、K8s 排障别一上来进容器很多人排 Kubernetes 问题第一反应是kubectl exec进容器看日志。不是不行但顺序常常错了。Pod 起不来、反复重启、镜像拉不下来、调度失败这些问题在事件里已经写得很清楚。先看事件少走弯路。K8s 排障要有节奏资源状态、事件、描述、日志、指标、节点。不要像无头苍蝇一样到处敲命令。生产环境里排障速度来自固定路径。二、排障链路从对象状态到节点flowchart TD A[发现异常] -- B[kubectl get] B -- C[kubectl describe] C -- D[查看 Events] D -- E[查看 Logs] E -- F[检查 Node 与资源]Events 能告诉你很多真相FailedScheduling、ImagePullBackOff、BackOff、Unhealthy、Killing。看到这些关键词就能迅速缩小范围。三、命令清单先拿到证据kubectl get pod -n prod -o wide kubectl describe pod ai-infer-xxx -n prod kubectl logs ai-infer-xxx -n prod --previous kubectl get events -n prod --sort-by.lastTimestamp--previous很重要。容器重启后当前日志可能看不到崩溃前信息。上一轮容器日志经常能直接看到 panic、OOM 或配置错误。四、工程边界别把所有问题都怪 K8sK8s 只是把问题暴露得更明显。探针写错会导致重启资源限制太小会 OOM镜像过大导致拉取慢应用启动慢但 readiness 没处理会被提前打流量。很多所谓 K8s 问题本质是应用没有按云原生方式设计。取舍方面探针严格能快速摘除坏实例但误杀风险高探针宽松减少误杀但坏实例可能继续接流量。生产里要根据服务特性设置。AI 服务、JVM 服务、前端 SSR 服务启动时间都不同探针不能复制粘贴。还要保留排障上下文。事故时记录 Pod 状态、事件、最近发布、节点资源和关键日志。恢复后这些信息可能消失。没有证据的复盘只能写“疑似资源抖动”这种复盘没价值。节点层面也不能漏。Pod Pending 可能是资源不足、亲和性规则太窄、污点不可容忍也可能是 PVC 绑定失败。kubectl describe node、节点 allocatable、磁盘压力和镜像缓存都要看。很多排障卡住是因为只盯 Pod不看它落在哪个节点。如果是线上核心服务建议准备固定排障脚本把 get、describe、events、logs、top、recent rollout 一次性收集。事故时人会紧张脚本能保证证据不漏。排障不是临场 freestyle越关键越要有固定鼓点。最后复盘要回到预防。是资源 request 写错就补准入检查是探针误杀就修模板是镜像拉取慢就做预拉取或镜像治理。排障结束不等于问题结束。排障时还要注意时间线。报警什么时候触发发布什么时候发生Pod 什么时候重启节点什么时候出现压力事件顺序能帮助判断因果。不要看到两个现象同时出现就直接认定相关。K8s 现场信息多时间线能把噪声压下去。如果涉及多集群或多命名空间要先确认影响范围。只影响一个 namespace可能是配额或配置影响整个节点池可能是节点资源或网络影响全集群才去看控制面。范围判断越快排障越稳。五、总结Kubernetes 生产排障要先看对象状态和 Events再看日志和节点资源。固定排障路径比临场乱敲命令更可靠。很多 K8s 问题根因其实在应用设计。