Kubernetes 生产故障排查路线

Kubernetes 故障排查应先判断影响范围，再沿“入口—Service—Pod—节点—依赖”建立证据链。不要一看到异常就重启 Pod；重启可能暂时恢复业务，也可能清除最关键的现场。

一、先回答四个问题

是单个请求、单个 Pod、一个节点、一个可用区还是整个集群？
从什么时间开始，是否与发布、扩容、证书或基础设施变更重合？
用户看到的是超时、错误码、连接失败、数据错误还是性能下降？
当前首要目标是止损、恢复还是根因定位？

先保存时间线、告警、事件、对象 YAML 和相关日志，再执行可能改变现场的操作。

二、第一层：对象与事件

kubectl get pods -A -o wide
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl describe pod POD -n NAMESPACE
kubectl get pod POD -n NAMESPACE -o yaml
kubectl logs POD -n NAMESPACE --all-containers --tail=200
kubectl logs POD -n NAMESPACE --previous --tail=200

Pending 先看调度事件、资源、污点、亲和性和存储；CrashLoopBackOff 看当前与上一次容器日志、退出码和探针；ImagePullBackOff 看镜像地址、凭据、DNS 和仓库连通性。

三、第二层：Service 与入口

kubectl get svc,endpoints,endpointslices -n NAMESPACE
kubectl describe ingress -n NAMESPACE
kubectl get networkpolicy -A

检查 Service Selector 是否匹配 Pod 标签、Endpoint 是否为空、端口名称和目标端口是否一致。入口返回 502/504 时，还要区分是 Ingress 到 Service、Service 到 Pod，还是应用依赖超时。

四、第三层：资源与探针

CPU 限流会表现为延迟上升，不一定出现 OOM。
内存超限可能得到退出码 137，仍需结合节点和容器事件确认。
Readiness 失败只会摘除流量，Liveness 失败会重启容器，错误配置可能造成重启风暴。
Requests 影响调度，Limits 影响运行时上限，两者不能只按经验模板填写。

kubectl top pod -A
kubectl top node
kubectl describe node NODE

五、第四层：节点与运行时

检查节点条件、磁盘压力、PID 压力、时间、kubelet、容器运行时、CNI 和 CSI。节点 NotReady 时，不要只重启 kubelet，应保留日志并确认网络、证书、磁盘和控制面连通性。

当容器镜像没有 Shell 或调试工具时，可在权限允许的前提下使用 kubectl debug 临时调试容器；生产环境应记录镜像来源、权限和清理步骤。

六、控制面与依赖

若多个命名空间或节点同时异常，再检查 API Server、etcd、调度器、控制器、DNS 和证书。业务应用还可能依赖数据库、缓存、消息队列、对象存储或外部 API；Pod 正常不等于依赖正常。

七、快速止损原则

回滚最近发布前先确认旧版本与当前数据兼容。
扩容前确认瓶颈不是数据库、限额或下游。
驱逐节点前检查副本、PDB、存储和剩余容量。
放宽 NetworkPolicy 或安全组时必须限制范围和有效期。
变更探针时记录原值，并在恢复后重新评估。

八、复盘输出

复盘至少包含：影响范围、开始与恢复时间、发现方式、关键证据、根因、放大因素、止损措施、为什么监控没有更早发现，以及负责人和截止日期。不要把“某人误操作”当作最终根因，应继续追问为何缺少审核、验证或保护。

Kubernetes生产故障排查路线