凌晨两点二十三分告警电话把我从睡梦里拽了出来。某生产集群里一个核心服务的Pod进入了CrashLoopBackOff业务侧已经在群里刷屏。我抓起电脑第一件事下意识地敲了kubectl logs结果日志里全是正常启动的打印完全没有报错。等你把日志翻完、Pod又重启了七八回你才会意识到一件事Kubernetes容器环境故障排查跟传统排障完全不是一回事。它最大的陷阱不是问题本身复杂而是现象和根因之间隔着一层编排系统你盯着应用日志看往往什么都看不出来。这篇文章我不会去罗列所有组件的源码级原理而是把我在多个集群里摸爬滚打总结出来的排障框架、具体步骤和踩坑经验分享出来。适合正在维护Kubernetes集群的运维、SRE也适合刚接触容器编排、对Pod状态一头雾水的后端开发。核心就一句话在Kubernetes里排障先看状态再看事件最后才看日志。顺序错了效率至少差三倍。1. 先建立排障的坐标系分清现象与根因1.1 为什么Kubernetes排障特别容易卡壳传统服务器排障的路径很直接——进程挂了看日志端口不通看防火墙磁盘满了看空间。Kubernetes把这些统统包了一层你看到的不是进程而是PodPod背后有ReplicaSetReplicaSet有DeploymentDeployment的调度要经过Scheduler节点的状态要靠kubelet上报网络要经过Service、kube-proxy、CNI插件存储要经过PV、PVC、StorageClass。任何一个环节出问题表现都可能是同一个——Pod不正常业务不可用。所以在Kubernetes里最错误的排障姿势就是一上来狂翻应用日志。日志只是最下游的“结果”之一而且容器崩溃时日志可能根本没有、或停留在上一次正常启动的旧输出里。真正有价值的是两个我们经常忽略的东西Pod的Events和对象的状态字段。Events记录了调度器、kubelet、控制器对你这个对象做过什么决策比如“为什么没有调度成功”“为什么探针失败”“为什么镜像拉不下来”。这些信息是Kubernetes自己记录的排障时比日志可信得多。还有一层容易让人迷惑的是“现象会漂移”。同样一个服务访问不通有时候是Service的selector写错有时候是后端Pod的网络命名空间异常有时候是节点上的iptables规则被污染。表现一模一样根因完全不同。所以你需要一套固定的排查坐标系碰到问题先定位坐标再深入根因。我总结了三个坐标轴纵向坐标从下往上节点层 → Pod层 → Service层 → Ingress/DNS层。问题在哪一层就在哪一层解决。横向坐标按对象看同一个层的多个对象比如多个Pod副本是否健康状况一致不一致时对比差异。时间坐标看事件发生的时间序列谁先异常谁后异常是同时爆发还是逐级扩散。1.2 一套可复用的三层排查顺序不管什么故障类型我建议你都先跑一遍通用三层排查顺序再做深入分析。这三层是第一层集群和节点的健康状态。先看节点是不是Ready资源是否紧张kubelet和容器运行时是否正常有没有大规模驱逐或节点重启。用下面这几条命令一分钟内就能确认集群底层有没有出大问题kubectl get nodes -o wide kubectl get events -A --sort-by.lastTimestamp | tail -50 kubectl top nodes第二层工作负载的运行状态。看所有相关命名空间里的Pod状态分布找出异常Pod再用describe查看详细事件和状态条件。异常Pod一般集中在Pending、CrashLoopBackOff、ImagePullBackOff、Evicted、Terminating这几种状态里。kubectl get pods -n namespace -o wide kubectl describe pod pod-name -n namespace第三层依赖资源的状态。很多Pod本身看着正常但问题出在它依赖的东西上ConfigMap/Secret是否挂载成功、PVC是否Bound、Service的Endpoints是否有地址、Ingress后端的Service是否存在。别急着进Pod里折腾先用下面这组命令把依赖链路捋一遍kubectl get svc,ep -n namespace kubectl get pvc -n namespace kubectl get configmap,secret -n namespace这三层走完大部分故障的层级定位就完成了。接下来的章节我会按故障类别展开具体的排查链路。2. Pod生命周期异常从Pending到CrashLoopBackOff的完整排查链路2.1 Pending状态的常见隐藏原因Pod停在Pending说明它还没有被调度到任何节点上。很多人的第一反应是“资源不够”其实资源不足只是原因之一而且往往不是真正的原因。我用kubectl describe pod查看Events时最常遇到的Pending原因有这么几类调度器无法匹配节点。要么是节点上有污点Taints而Pod没有对应的容忍度Tolerations要么是Pod有nodeSelector或节点亲和性但集群里找不到满足条件的节点。这种问题在Events里会明确出现FailedScheduling后面跟着具体原因比如0/5 nodes are available: 5 node(s) didnt match node selector。这里有个容易忽略的点节点上的污点分NoSchedule、NoExecute和PreferNoSchedule三种其中NoExecute不仅影响调度还会把节点上已有的Pod赶走。如果你发现某个节点上的Pod集体消失大概率是被人加了NoExecute污点或者节点触发了NotReady状态连锁驱逐。资源请求大于可分配量。注意我说的是“请求”requests而不是“使用量”。Kubernetes调度只看Pod声明的requests如果这个值比节点可分配的多无论实际负载多低Pod都调度不上去。集群里常见的坑是有人把requests写得跟limits一样大甚至比极限值还高。碰到这种情况我会先用下面的命令看节点剩余可分配资源kubectl describe node node-name | grep -A 5 Allocated resources再结合kubectl get pods -A -o wide看看哪些Pod占了大量requests。这里有个经验不要只看一条命令的输出就说资源不足因为节点上的系统保留资源kube-reserved、system-reserved也会吃掉一部分可分配额度Requests的总和看似很充裕实际可分配量已经见底了。存储关联导致调度失败。Kubernetes的调度器在调度时还会检查Pod使用的PVC是否可以挂载。有一个非常隐蔽的场景多个Pod共用一个ReadWriteOnce的云盘当这些Pod被调度到不同节点时第二个Pod就会一直PendingEvents提示node(s) didnt find available persistent volumes to bind或者FailedScheduling。这个坑在StatefulSet扩容时特别常见一张表太好用了。Pod自身有异常约束比如端口冲突、hostPort占用、Pod anti-affinity的label不满足。这类问题Events里通常会有明确的调度失败信息按提示走就行。遇到Pending我的建议是先跑一遍以下命令组合把调度器和节点的信息都拉出来kubectl get pod pod-name -n namespace -o yaml | grep -i nodeSelector\|affinity\|tolerations kubectl describe pod pod-name -n namespace | grep -A 20 Events kubectl describe node | grep -B 2 -A 5 Taints2.2 CrashLoopBackOff与ImagePullBackOff的完整处理链路CrashLoopBackOff可能是大家最熟悉的异常状态Pod启动后立刻崩溃被kubelet反复拉起间隔时间逐渐拉长。很多教程会告诉你“看日志”但真正的排查链路应该是这样走的第一步确认退出码。kubectl describe pod里能看到容器上次退出的原因和退出码。不同退出码对应完全不同的方向退出码通常含义下一步排查方向137进程被OOM Kill或外部SIGKILL查看内存limit、检查dmesg里的OOM记录143进程收到SIGTERM后退出看是否被滚动更新、探针失败后的正常终止1应用自身报错退出深入看应用日志和启动参数2通常是命令或参数错误检查Dockerfile的ENTRYPOINT/CMD126/127权限问题或命令不存在检查镜像里的可执行文件和运行用户权限退出码是定位的“码表”我处理过最典型的137Pod的内存limit设成512Mi但JVM堆内存按宿主机内存比例配置结果在节点内存大的机器上启动时JVM申请了远超limit的内存直接被打死。把JVM参数换成显式指定堆大小后问题才解决。这类问题和应用代码无关全是启动配置的锅。第二步看前一次日志。如果容器是“启动后立刻崩溃”型当前pod的日志往往为空或者只有崩溃前最后一刻的输出。这时候要加--previous参数kubectl logs pod-name -n namespace --previous --tail200这个命令拉取的是上一次容器实例的日志。别小看这个参数很多人在崩溃循环里只看到空日志就是因为没加它。如果--previous也没有日志大概率是容器根本没跑到应用启动那一步问题出在启动命令、环境变量、挂载卷或依赖的ConfigMap/Secret上。第三步看探针和依赖服务。CrashLoopBackOff还有个常被忽视的来源存活探针livenessProbe配置不合理。应用明明起来了但探针的请求路径返回超时或非2xxkubelet反复杀掉容器重启。典型症状是pod日志显示应用已成功启动但describe里的Events写着Liveness probe failed。这里我建议先用kubectl exec进容器手动请求探针地址看返回结果再对照探针配置里的initialDelaySeconds和timeoutSeconds。启动慢的应用initialDelay太短几乎必炸。至于ImagePullBackOff处理路径更直接。先用kubectl describe pod看Events里的具体错误比如Failed to pull image xxx:latest: image not found—— 镜像tag不存在或拼写错误。pull access denied—— 私有镜像仓库鉴权失败需要检查Secret和imagePullSecrets配置。context deadline exceeded—— 镜像仓库网络不通或拉取超时检查节点到仓库的连通性。遇到私有仓库的鉴权问题有一个细节特别容易漏imagePullSecrets必须定义在Pod所在命名空间并且Deployment的模板里要显式引用它。即使Default服务账号已经绑定了Secret如果Deployment没有在spec.template.spec.imagePullSecrets里写引用照样拉不下来。我曾在某个环境里反复排查这个问题最后发现就是模板里漏了这行配置改完后立刻正常。3. 网络与服务通信故障从Service到DNS的逐层穿透3.1 Service无法访问时先确认后端端点在Kubernetes里遇到“服务访问不通”最容易翻车的点是把精力都花在Service的yaml上反复看selector。其实这不是第一步第一步应该先确认后端是否真正挂到了Service下面。方法很简单kubectl get svc service-name -n namespace kubectl get endpoints service-name -n namespace如果Endpoints里有IP地址说明后端的Pod满足了selector条件并已经关联上Service如果Endpoints列表为空说明Service的selector没有匹配到任何Pod。这时候优先排查Deployment/StatefulSet的Pod是否全部Ready如果部分未ReadyService不会把未就绪的Pod挂进Endpoints除非设置了publishNotReadyAddresses。Service的selector与Pod的labels是否完全一致包括大小写和空格。是否存在多个同名Service在不同命名空间导致访问时地址解析错误。Endpoints正常但访问仍不通问题就往下沉了一级。我会用kubectl port-forward直接访问后端Pod判断是后端Pod本身的问题还是中间组件的问题kubectl port-forward pod-name -n namespace 8080:8080 curl http://localhost:8080/health如果port-forward访问正常说明应用没问题问题出在Service到Pod之间或者Service本身。接下来按Kubernetes网络的基本模式——从Service到Pod中间通常要经过kube-proxy维护的负载均衡规则iptables/IPVS以及CNI插件的数据路径。常见原因有这么几类kube-proxy组件异常导致Service的ClusterIP对应的转发规则没生效或规则错乱。可以通过在集群内任意节点上检查iptables规则或者IPVS规则也可以直接看kube-proxy的Pod日志。CNI插件问题比如VXLAN/Overlay网络的路由表漂移、网络策略拒绝连接。检查方式是在Pod所在节点执行kubectl get pods -n kube-system | grep -i cni查看CNI控制器状态并检查NetworkPolicy是否误伤。Service的type与外部访问方式不匹配ClusterIP只能在集群内访问NodePort需要注意端口范围和防火墙LoadBalancer需要云厂商组件正常协调。这里我想多说一句NodePort的坑。NodePort暴露的端口是每个节点都监听的但如果你在云环境里只给部分节点配置了安全组规则你从公司网络访问这台节点没问题访问另一台节点就超时现象特别像“Service随机不可用”。检查的时候一定要把所有节点的NodePort都测一遍不要只测一个节点就下结论。3.2 DNS解析失败的排查细节DNS问题在Kubernetes里是出了名的“看起来简单、查起来要命”。最典型的场景Pod里用服务名访问另一个服务时通时不通或者全部解析失败。我的排查顺序是这样的第一步确认CoreDNS本身是否健康kubectl get pods -n kube-system -l k8s-appkube-dns -o wide kubectl get svc -n kube-system kube-dnsCoreDNS一旦出现CrashLoopBackOff整个集群的业务都会受影响。如果CoreDNS Pod状态正常再用kubectl exec进业务Pod跑一下nslookup或者dig测试解析。第二步解析失败要看是“服务解析失败”还是“外部域名解析失败”。服务解析失败时优先检查目标Service是否真的存在命名空间是否写对了。跨命名空间访问时需要写成服务名.命名空间.svc.cluster.local这种FQDN形式只写服务名只能解析当前命名空间下的Service。CoreDNS的配置是否被改动过比如kubectl get configmap -n kube-system coredns -o yaml检查forward .和kubernetes插件段落。外部域名解析失败的排查路径不一样通常要从Pod里先解析一次再跑到集群外部解析一次对比结果。如果Pod里解析失败但集群外正常大概率是CoreDNS的forward插件配置、上游DNS服务器、或者节点上的防火墙规则出了问题。还有一个容易被忽略的细节Pod里的/etc/resolv.conf的search domain配置。很多基础镜像自带的resolv.conf格式特殊如果配置不当会造成域名解析的额外超时表现为第一次访问慢、后续访问正常。第三步检查网络策略NetworkPolicy是否限制了DNS流量。这个问题极其隐蔽Pod明明运行正常CoreDNS也在线但业务Pod执行nslookup一直超时。原因是有些团队出于“安全加固”目的给业务Pod加了NetworkPolicy只放行特定端口却忘了放行53端口的出方向流量。结果是应用能互相访问但DNS全部超时。遇到这类问题我会先看业务Pod所在的命名空间有没有NetworkPolicy再看规则里是否允许访问CoreDNS所在的kube-system命名空间的53端口。DNS排障我建议有一个“时间盒”不要超过10分钟。如果10分钟内定位不到具体原因直接启用集群内一个临时的debug Pod绑定不同的DNS配置做对比用差异法来收敛范围。比如开一个不继承业务Pod DNS策略的Pod作为对照如果它解析正常说明问题出在业务Pod的DNS配置或网络策略上。4. 存储与持久化问题PV/PVC挂载失败的实操复盘4.1 为什么PVC一直Pending在Kubernetes里PVC本身就是一种“声明”它不会自己去创建真正的存储而是依赖StorageClass动态供给或者依赖管理员预创建的PV二者配合。PVC一直Pending的排查思路其实很清楚先看它的选中结果再看供给方的状态。kubectl describe pvc pvc-name -n namespace kubectl get pv kubectl get storageclasskubectl describe pvc的Events里如果没有WaitForFirstConsumer之类的提示而是直接报failed to provision volume with StorageClass那问题基本锁定在StorageClass及其provisioner上。流程是Pod引用PVC → PV控制器发现PVC需要动态供给 → 调用对应provisioner创建真正的云磁盘或存储资源 → 生成PV并绑定PVC。其中任何一个环节失败PVC都会Pending。常见的隐藏坑包括StorageClass里写的provisioner名称与实际部署的provisioner不一致。使用自建存储类时镜像里provisioner的名字、StorageClass里的provisioner字段、以及外部控制器里配置的名字三处必须完全一致。StorageClass的reclaimPolicy或volumeBindingMode配置与存储后端不兼容。比如WaitForFirstConsumer模式下PVC会一直等到被Pod调度后才真正创建卷如果Pod本身也Pending就会形成“你等我我等你”的僵局。AccessModes不匹配。一个节点上已经挂载了ReadWriteOnce的卷另一个Pod想在不同节点上挂载同一个PVC就会被阻塞。云账号的配额限制、磁盘类型不可用等底层资源问题在events里会有体现但要对照云平台里实际资源状态排查。我实际处理过这样一个案例某个StatefulSet扩容新Pod一直Pendingdescribe看到PVC的VolumeBinding通过、StorageClass也存在但节点上没有调度过去。最后发现是多个副本共享同一个ReadWriteOnce的PVC调度器无法重复挂载。改成每个副本一个独立PVC 无头服务Headless Service的StatefulSet方案后问题解决。这个案例告诉我的经验是PVC一直Pending时不要只盯着PVC看要把引用它的Pod调度状态一起看。存储和调度是联动的不能割裂排查。4.2 挂载成功但写入失败的处理经验更折磨人的场景是PVC已经BoundPod也正常启动但容器内往挂载目录写入时Permission Denied或者写入后容器重启数据丢失。这类问题通常涉及三件事权限、所有权、文件系统类型。先说权限。大量基础镜像以root用户运行容器或者以非root用户运行但挂载目录的属主、属组不对。云盘类存储挂载到Pod里后目录的所有权往往继承自存储本身而不是你Dockerfile里写的USER。解决办法有两种一是在Pod的securityContext里设置fsGroup让kubelet在挂载卷时自动递归修改卷的属组二是在启动命令里增加初始化容器先chown目录再交给主容器。securityContext: fsGroup: 1000 runAsUser: 1000我见过很多开发者在Dockerfile里写USER却忘了Kubernetes侧还有runAsUser和fsGroup导致容器起来后写不了挂载目录。这里建议多做一个验证步骤在容器里执行id和ls -l确认当前用户和目录属主。再说挂载类型。NFS、CephFS这类文件系统在并发写入、文件锁上各有各的限制。有时候Pod能挂载但应用高并发写入时出现Stale File Handle错误。这类问题和应用自身的IO模式强相关。我的经验是如果应用对文件锁和一致性要求很高优先选择块存储云盘而非共享文件系统。共享文件系统更适合大规模读多写少的场景。还有一个非常容易被忽略的坑PVC的回收策略与备份机制。集群里如果配了自动快照或者备份任务偶尔会因为快照锁导致云盘无法解挂、Pod一直在Terminating。这种问题在Pod侧看是“Terminating超过几分钟”在存储侧看其实是云盘的挂载计数被锁住。排障时需要登录底层宿主机确认挂载点没有占用再在云平台侧强制解挂。5. 节点层隐患从NotReady到资源挤压的连锁反应5.1 节点NotReady的定位步骤节点NotReady是一个“大症状”背后原因千差万别。最简单的定位方法kubectl describe node node-name看Conditions列表里的具体内容kubectl describe node node-name | sed -n /Conditions:/,/Addresses:/pConditions里Ready为Unknown时通常是kubelet与API Server之间心跳断了网络分区或kubelet异常Ready为False时通常是kubelet明确上报检查失败比如容器运行时不可用、磁盘压力过大。用下面的命令查看kubelet日志journalctl -u kubelet -f --no-pager -n 300kubelet日志里最常见的两类信息PLEG is not healthy和Failed to update node status。PLEGPod Lifecycle Event Generator是kubelet内部用来同步容器状态的组件PLEG不健康kubelet就无法及时感知容器变化。造成PLEG故障的原因通常是容器运行时containerd或docker响应超时比如镜像拉取过多、运行时僵死、磁盘IO卡顿。此时光重启kubelet是治标不治本要把底层容器运行时的状态一并检查crictl ps -a crictl imagescrictl命令如果卡住或者列出容器状态时出现大量错误基本就是容器运行时本身有问题。常见的有磁盘空间满导致containerd无法写数据、容器数量过多导致运行时目录膨胀、以及节点上的systemd单元资源限制导致运行时进程被冻结。节点NotReady的应急措施大家都懂——先cordon节点、驱逐上面的Pod避免调度到这台故障节点。但有一件事我必须在实践里强烈建议在驱逐前先搞清楚节点问题的性质。如果是磁盘IO卡死导致PLEG异常强制驱逐Pod会让所有容器在节点上被停掉业务影响面反而扩大。很多情况下先给节点加临时磁盘空余空间或者在低峰期重启kubelet与容器运行时可以避免一半以上不必要的驱逐。5.2 资源配额与驱逐机制造成的“莫名”故障有一种故障特别让人抓狂Pod运行着业务没报错突然一个或多个Pod被杀掉日志里没有明显异常。这种“莫名消失”多半和节点压力驱逐eviction有关。kubernetes的kubelet会根据节点上的内存、磁盘、文件系统inode等指标进行压力判断一旦超过阈值就开始驱逐优先级最低的Pod。被驱逐的Pod在describe里能看到Reason: Evicted。排查这类问题不要只看业务Pod先看节点上的压力指标kubectl describe node node-name | grep -A 10 Pressure kubectl top node node-name df -h /var/lib/containerd df -i /var/lib/containerd很多人只关注内存压力忽略了inode耗尽和容器日志文件占满磁盘这两个杀手。容器默认的日志文件如果没配置轮转几天的量就能把磁盘写满。磁盘一满节点上的镜像、容器层都写不进去kubelet会立刻进入驱逐状态。解决办法是在配置里加日志轮转参数例如容器运行时配置max-size50Mi和max-file5。另一个隐蔽的坑是QoS等级与驱逐顺序的关联。Kubernetes驱逐Pod的顺序是BestEffort最先Burstable其次Guaranteed最后。如果业务Pod没有设置resources字段它属于BestEffort在大规模节点故障时会被优先驱逐。很多业务方以为“不设置limits更灵活”实际上恰恰是把Pod推到了最容易被驱逐的位置。如果业务对稳定性要求高请务必显式设置requests和limits保持Guaranteed QoS。节点层面还有一个容易被误解的问题资源请求膨胀导致大量Pod挤在部分节点上。原因是单个Pod的requests设置过高、副本数过多而节点的可分配资源被系统保留吃掉了一部分。这种情况下节点没有压力但调度器调度不上去或者已经运行的Pod因为节点上总requests超限在滚动更新时无法发起新Pod。排查手段是看各Pod实际的requests总和与节点可分配额kubectl describe node node-name | grep -E Allocated resources|kube-reserved|system-reserved6. 几个容易忽视的坑与最后一条建议6.1 一套顺手到极致的排障命令组合Kubernetes排障本身不复杂复杂的是在多个对象、多个时间点之间建立关联。我把自己常用的命令组合整理成了一份“应急清单”遇到故障直接按顺序跑基本能覆盖九成场景排查目标命令作用集群整体kubectl get nodes -o wide kubectl get events -A --sort-by.lastTimestamp快速判断是否有节点级或全局事件工作负载kubectl get pods -A -o wide | grep -v Running找出所有非Running状态的Pod单Pod细节kubectl describe pod pod -n ns看调度决策、挂载细节、探针结果、Events崩溃容器日志kubectl logs pod -n ns --previous --tail200拉出崩溃前一次生命周期日志依赖资源kubectl get ep svc -n ns kubectl get pvc -n ns确认后端Pod关联关系与存储绑定状态节点压力kubectl describe node node | sed -n /Conditions/,/Addresses/p查看内存/磁盘/inode压力情况运行时状态crictl ps -a和crictl events --tail20容器运行时完整视图和事件流DNS链路kubectl get pods -n kube-system -l k8s-appkube-dns -o wideCoreDNS实例状态检查应急清单里有一件事我们要特别小心不要在业务高峰期的生产环境里轻易执行删除或驱逐命令。即使你已经确认了问题也要先评估影响面。Kubernetes最大的武器是自愈和冗余但如果集群整体已经处于过载状态盲目删除一个Pod可能导致更大规模的重新调度风暴。稳健的做法是先扩容有冗余容灾能力的副本或者在集群负载较低时再做操作。6.2 排障工具箱之外的个人经验最后分享三条我这些年排障下来最值钱的体会。第一条看Events永远比看日志先一步。Events是Kubernetes自己记录的“系统日志”日志是应用自己的输出。系统日志告诉你系统做了什么决策应用日志往往只告诉你应用内部发生了什么。两者叠加才构成完整视图只看后者就是瞎子摸象。第二条时间同步问题会造成大量假象。如果集群里大部分节点的时钟偏差超过几十秒你会看到非常奇怪的现象Pod的Events时间戳乱序、滚动更新异常、证书验证失败、甚至日志收集时间错乱。碰到一次特别诡异的故障尽量先检查集群所有节点的时间和NTP同步状态。第三条排障文档的价值不在于“记录答案”而在于“记录排查链路”。每次解决完问题后我都习惯把当时的命令、输出片段、判断逻辑记在一个私有笔记里。下次再遇到类似故障直接翻笔记就能按顺序验证而不是又从零开始摸索。很多人觉得这浪费时间但真正处理过几十上百次故障后你就会发现Kubernetes的故障很少是全新类型大多是新瓶装旧酒。如果你正准备在自己的集群里实践这套排障流程我建议先从“三层排查顺序”开始刻意练习。遇到任何异常先压制住直接看日志的冲动按 节点健康 → 工作负载状态 → 依赖资源 的顺序走一遍再用Events的输出去验证判断。坚持几次之后你会发现排障效率有了质的提升。曾经要花一晚上的Case现在通常能在十五分钟内完成定位。这就是建立排障坐标系的回报。