Kubernetes 生产排障：先看事件，再看日志

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 或配置错误。

四、工程边界：别把所有问题都怪 K8s

K8s 只是把问题暴露得更明显。探针写错会导致重启，资源限制太小会 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 问题，根因其实在应用设计。