【架构实战】Kubernetes故障排查全景图：从Pod起不来到底层雪崩的诊断手册

【架构实战】Kubernetes故障排查全景图从Pod起不来到底层雪崩的诊断手册应用上了Kubernetes最怕的不是没部署而是部署了却跑不起来或者跑得好好的突然雪崩。新手一遇到Pod起不来就到处乱试老手则有一套从现象到底层的排查漏斗。上一篇讲了安全加固这一篇把Kubernetes的故障排查体系拆成一张全景图给你一套能直接上手的诊断手册。一、先建立三层漏斗思维遇到故障千万别一头扎进去看日志那样只会越看越乱。先把问题定位到对应层级再逐层下钻现象层Pod状态Pod是Pending、CrashLoopBackOff还是Running但没流量这是最外层的信号。资源层配置与依赖镜像、配置、PVC、资源配额、亲和性是不是没满足条件基础设施层节点与集群kubelet、CNI、etcd、控制面是不是出了问题口诀是先看Phase定大方向再看Events找直接原因最后看底层组件排查根因。下面所有排查都遵循这个顺序。二、Pod生命周期与状态机排查之前先认清楚Pod能处于哪些状态Phase含义典型触发Pending已接受但还没调度/起容器资源不足、PVC未绑定、调度失败Running至少一个容器在运行正常态但可能假活Succeeded所有容器正常退出Job/CronJob完成Failed至少一个容器非正常退出主进程退出码非0Unknown节点失联状态拿不到kubelet心跳丢失注意Pod Running ≠ 业务正常。容器起来了但反复OOM、或探针一直失败被重启都是假活。三、Pod起不来的经典五连3.1 ImagePullBackOff / ErrImagePull现象Pod一直拉不下来镜像。根因镜像名写错、tag不存在、私有仓库没配imagePullSecret、节点网络不通仓库。排查kubectl describe podpod|grep-A5Events# 看具体拉取错误kubectl get events --sort-by.lastTimestamp# 全局事件按时间排序解决核对镜像地址与tag私有仓库补imagePullSecrets节点执行crictl pull image验证网络可达。3.2 CrashLoopBackOff现象容器反复重启间隔越来越长。根因应用启动即崩溃配置错误、依赖未就绪、端口被占、健康检查配置过严、资源limit太小触发OOM。排查kubectl logspod--previous# 看上一次崩溃前的日志kubectl logspod-ccontainerkubectl describe podpod|grep-iback-off\|exit解决先用--previous拿到崩溃日志把liveness探针初始延迟initialDelaySeconds调大确认resources.limits足够若是依赖未就绪改用readinessProbe重试而非直接崩溃。3.3 CreateContainerConfigError现象容器创建失败提示config错误。根因引用了不存在的ConfigMap/Secret、envFrom的键缺失、挂载路径冲突。排查kubectl describe podpod|grep-iconfigmap\|secret\|createcontainerkubectl get configmapname-nns-oyaml解决确认引用的ConfigMap/Secret名称和key存在用kubectl get cm -n ns核对命名空间。3.4 OOMKilled现象容器被kill状态码137重启循环。根因内存使用超过resources.limits.memory被cgroup杀掉。排查kubectl get podpod-ojsonpath{.status.containerStatuses[0].lastState.terminated.reason}kubectltoppodpod# 看实际内存占用解决调大memory limit排查内存泄漏设置合理的requests让调度更精准。3.5 Pending调度失败现象Pod一直Pending不分配节点。根因资源不足、节点有taint而Pod无toleration、nodeSelector/亲和性不匹配、PVC未绑定。排查kubectl describe podpod|grep-ifailedscheduling\|insufficient\|taintkubectl get nodes-owide# 看节点资源与taint解决缩容/扩容节点加tolerations放宽nodeSelector确认PVC能绑定到PV。四、必备排查工具箱命令用途kubectl describe pod看事件、状态、挂载、探针kubectl logs --previous看崩溃前日志kubectl get events --sort-by.lastTimestamp集群级时间线kubectl exec -it pod -- sh进容器排查需容器在跑kubectl debug pod -it --imagebusybox临时调试容器不影响原Podkubectl top pod/node实时资源占用需装metrics-servercrictl ps/pods/logs节点侧直接操作容器运行时kubectl debug是神器当原容器没有shell或已崩溃无法exec时用临时容器挂载同一PID/网络命名空间进去看现场。五、网络故障排查网络问题是Kubernetes里最磨人的一类。按由内到外逐段排查5.1 Pod到Pod不通先看CNI插件状态kubectl get pods -n kube-system | grep -i cni节点上crictl确认网络插件容器在跑。跨节点不通先确认节点间路由和防火墙如Calico的BGP、Flannel的VXLAN端口4789。5.2 Service访问失败Service是VIPiptables/IPVS规则。排查顺序kubectl get endpointssvc# 看endpoint是否真的有后端Podkubectl get svcsvc-oyaml# 看selector和端口iptables-tnat-L|grepsvc# 确认规则存在iptables模式最常见原因是Label selector对不上导致endpoint为空请求被丢弃。5.3 DNS解析失败Pod内nslookup失败多半是CoreDNS问题kubectl get pods-nkube-system-lk8s-appkube-dns kubectl logs-nkube-system-lk8s-appkube-dns若NodeLocalDNS或CoreDNS Pod异常整个集群解析都会挂表现为间歇性的偶发超时。5.4 Ingress 502/504Ingress Controller本身没问题但后端Service的readiness探针没过流量就不会转发过去。先看后端endpoint再看Ingress Controller日志里的upstream超时。六、存储故障现象根因排查PVC一直Pending没有匹配PV或SC未配置kubectl describe pvc看StorageClass是否存在、provisioner是否就绪挂载失败节点没装对应CSI驱动节点上crictl images看driver镜像查kubelet日志FailedMountReadWriteOnce冲突单节点卷被多Pod争用改用RWX存储类或确保Pod调度到同一节点数据盘满PV所在磁盘写满节点df -h清理或扩容动态供给失败往往是StorageClass的provisioner Pod如csi-resizer、external-provisioner异常单独看这些sidecar的日志最准。七、节点与集群级雪崩7.1 Node NotReady节点状态NotReady通常是kubelet失联或节点资源压力触发了Conditionkubectl getnodenode-oyaml|grep-A10Conditions看MemoryPressure/DiskPressure/PIDPressure。磁盘满尤其是container runtime的imagefs会触发kubelet驱逐把节点上Pod全赶走。7.2 集群雪崩级联故障最危险的场景节点磁盘/内存压力 → kubelet大规模驱逐Pod → 被驱逐的Pod重新调度到别的节点 → 新节点也压力升高 → 调度风暴 → API Server请求激增 → etcd写入延迟 → 更多超时与重试。识别kubectl get pods-A|grep-cEvicted# 驱逐数量异常kubectl get--raw/metrics|grepapiserver_request_duration_seconds# API延迟ETCDCTL_API3etcdctl endpoint health# etcd健康止血临时cordon/隔离问题节点先停止非关键负载给控制面喘息空间再逐节点排查根因而不是盲目扩容加剧风暴。八、故障排查SOP清单症状第一条命令大概率根因Pod一直Pendingdescribe看FailedScheduling资源/taint/亲和性反复重启logs --previous启动崩溃/探针过严镜像拉取失败describe看Events镜像名/密钥/网络Service不通get endpointsselector不匹配DNS超时查CoreDNS PodCoreDNS异常PVC挂不上describe pvcSC/provisioner节点NotReadyget node -o yamlConditions资源压力/磁盘满大面积Evictedget pods -Agrep Evicted九、小结监控优先于排查最好的故障排查是让问题在用户感知之前就暴露。三件事要做到位可观测性前置metrics-server Prometheus采集节点/Pod资源配好告警CPU、内存、磁盘、驱逐数别等雪崩才看。探针配置合理liveness防假活、readiness控流量初始延迟和阈值要给足别把探针变成自杀开关。建立SOP与文化把上面的清单固化成团队runbook故障演练chaos常态化让排查变成肌肉记忆而非临场发挥。记住Kubernetes的故障从来不是突然发生而是早有征兆。会看Events、会看指标、会顺着三层漏斗下钻你就能从救火队员变成防火工程师。下一篇预告Kubernetes多集群管理实战——从单集群到联邦调度的演进之路。