云原生运维必看｜K8S全场景故障排查手册

作为云原生运维工程师，咱们日常工作中最头疼的事，莫过于K8S集群突然“罢工”,可能是Pod起不来，可能是Service访问不通，也可能是Node节点失联，一个小故障就可能导致业务雪崩，半夜被告警叫醒更是家常便饭。

其实K8S故障排查有章可循，核心思路就两点：

• 从底层到上层排查（Node→Pod→Service→Ingress）

• 从现象到本质定位（日志→配置→资源→网络）。

今天就结合我多年踩坑经验，把K8S全场景常见故障、排查命令、解决思路一次性讲透，收藏这篇，下次排查故障

一、先明确排查总则（新手必看）不用再翻零散笔记！

咱们做运维的，排查故障最忌“瞎忙活”,上来就重启服务、重启节点，不仅可能掩盖问题，还可能扩大故障影响。记住这3个原则，效率翻倍：

1. 先定范围：确认故障是单个Pod、单个Node、整个集群，还是仅外部访问异常（缩小排查边界）；

2. 先查基础：Node节点是否正常、K8S核心服务是否运行、网络是否连通（底层异常会导致上层全挂）；

3. 善用工具：kubectl核心命令+日志排查+网络工具（telnet、curl、nslookup），拒绝“凭感觉”排查

   核心排查命令提前收藏：kubectl get（查状态）、kubectl describe（查详情）、kubectl logs（查日志）、kubectl exec（进容器排查），这四个命令能解决80%的基础故障。

   二、K8S核心服务故障（集群“大脑”出问题，全盘皆输）

K8S集群的核心服务的是apiserver、etcd、controller-manager、scheduler，这四个服务只要有一个异常，整个集群就会出现问题，也是最致命的故障类型。

1.常见现象 kubectl命令执行超时/失败（比如“the server could not find the requested resource”）、集群内Pod无法调度、节点状态异常、新Pod无法创建。

2. 排查步骤

检查核心服务运行状态（以systemd管理为例）：

查看服务日志（定位具体错误原因）：

核心故障定位与解决（踩过的坑）：

• apiserver故障：

  大概率是端口占用（6443端口）、配置文件错误（/etc/kubernetes/manifests/kube-apiserver.yaml），检查配置文件中的etcd连接地址是否正确，重启apiserver即可。

• etcd故障：

  最常见的是数据损坏（比如集群强制重启），可以通过etcdctl检查集群健康状态（etcdctl endpoint health），若数据损坏，需恢复备份（新手谨慎操作，避免彻底崩掉）；

  另外注意etcd节点之间的通信是否正常（2379、2380端口）。

1. 运维提醒

   etcd一定要做备份！一定要做备份！一定要做备份！重要的事说三遍，集群崩溃后，etcd备份是唯一的救命稻草，日常可以写个定时脚本自动备份。

三、Node节点故障（集群“手脚”失灵，Pod无处可去）

Node节点是Pod的运行载体，节点故障会导致其上的Pod全部不可用，若节点状态异常，新Pod也无法调度到该节点，属于高频故障类型。

1. 常见现象 • kubectl get nodes 查看节点状态为NotReady • 节点状态Ready但Pod无法调度 • 节点上的Pod全部Crash、节点失联。

2. 排查步骤 • 查看节点状态和详情，快速定位异常：

登录异常Node节点，检查核心组件（kubelet、kube-proxy）

检查节点资源（最容易被忽略的点）：

常见故障定位与解决：

• 节点NotReady：

  网络问题，检查节点的容器网络插件（calico、flannel等）是否运行正常，比如calico-node Pod是否正常，重启网络插件即可。

• kubelet启动失败：

  大概率是配置文件错误（/etc/kubernetes/kubelet.conf）、节点时间同步异常（时间差太大导致证书失效），检查时间同步（ntpdate），重启kubelet。

• 资源耗尽：

  CPU/内存满了，清理无用进程或Pod；磁盘满了，删除无用镜像、日志（/var/log目录），或者扩展磁盘。

• 节点失联：

  检查节点网络是否连通（ping节点IP）、防火墙是否放行K8S相关端口，若节点彻底宕机，需重启节点，待节点恢复后，Pod会自动重新调度（前提是Pod配置了重启策略）。

1. 运维提醒

   日常要监控Node节点的资源使用情况，设置资源告警（比如CPU使用率超过80%、磁盘占用超过90%告警），避免因资源耗尽导致节点故障；另外，容器网络插件是节点网络的核心，要重点监控。

四、Pod故障（业务“载体”出问题，最直接影响业务

Pod是K8S最小的部署单元，也是和业务最相关的组件，Pod故障是运维中最常遇到的问题，比如启动失败、运行中Crash、日志异常、资源不足等，排查时要围绕“Pod生命周期”展开。

1.常见现象

Pod状态为Pending、CrashLoopBackOff、ImagePullBackOff、Error、Running但业务不可用。

2. 排查步骤（通用思路）

查看异常Pod的详情，重点看Events（事件）和Status（状态）：

查看Pod日志（定位业务或容器内部错误）：

• 进入Pod容器内部，手动排查（比如检查配置文件、命令执行情况）：

1. 常见Pod故障定位与解决（高频场景）

• ImagePullBackOff（镜像拉取失败，最常见）

  原因：镜像地址错误、镜像不存在、私有镜像未配置拉取密钥、网络无法访问镜像仓库（比如外网镜像仓库被墙）。

  解决：检查Pod配置中的image字段是否正确；确认镜像在仓库中存在；私有镜像需创建secret，并在Pod配置中指定imagePullSecrets；内网环境可搭建私有镜像仓库（比如Harbor），避免外网依赖。

• Pending（Pod处于挂起状态，无法调度）

  原因：Node节点资源不足（CPU、内存不够）、节点亲和性/污点容忍配置错误、Pod请求的资源超过Node可用资源、没有符合条件的Node节点。

  解决：通过kubectl describe pod查看Events，确认是否是资源不足；调整Pod的resources.requests配置（降低请求资源）；检查节点亲和性、污点配置，修改为符合条件的配置；新增Node节点，补充集群资源。

• CrashLoopBackOff（Pod反复启动又崩溃）

  原因：容器内部命令执行失败、业务程序报错、配置文件错误、端口占用、健康检查失败。

  解决：查看Pod日志，定位业务报错原因；检查容器启动命令（command字段）是否正确；检查业务配置文件是否挂载成功；若端口占用，修改Pod的端口配置；调整健康检查（livenessProbe、readinessProbe）参数，避免误判。

• Running但业务不可用

  原因：容器内部业务未正常启动、端口映射错误、网络配置错误、健康检查配置错误（readinessProbe未通过，导致Pod无法提供服务）。

  解决：进入容器内部，检查业务进程是否正常运行（ps -ef）；检查Pod的端口配置（containerPort）是否和业务端口一致；通过kubectl exec在容器内部访问业务接口，确认业务本身是否正常。

运维提醒

给Pod配置合理的健康检查（livenessProbe、readinessProbe），避免Pod“假Running”；配置资源限制（resources.limits），防止单个Pod耗尽节点资源；Pod的重启策略（restartPolicy）要根据业务需求配置，避免故障Pod无法自动恢复。

五、Service故障（Pod“入口”出问题，业务无法访问

Service负责将Pod暴露出去，提供稳定的访问入口，Service故障会导致外部无法访问Pod内的业务，常见问题集中在 endpoints、端口映射、网络策略上。

1. 常见现象 通过Service IP无法访问业务、Service端口无法访问、Service的EXTERNAL-IP异常、 endpoints为空。

2. 排查步骤 • 查看Service状态和详情：

重点检查endpoints（Service的核心，关联Pod）：

测试Service访问（从集群内节点或其他Pod测试）：

常见故障定位与解决

• endpoints为空：

  Service的selector配置错误，导致无法匹配到Pod；

  检查Service的selector和Pod的labels是否一致（大小写敏感），修改后endpoints会自动更新。

• Service IP无法访问：

  检查kube-proxy是否正常运行（Node节点上）；

  检查Service的端口映射是否正确（targetPort是否和Pod的containerPort一致）；

  检查Pod是否正常运行（Running状态，且readinessProbe通过）。

• NodePort类型Service无法访问：

  检查节点防火墙是否放行NodePort端口；

  检查Service的externalTrafficPolicy配置（若为Local，只能访问运行Pod的Node节点的NodePort）；

  检查云平台安全组（若为云环境，需放行NodePort端口）。

• LoadBalancer类型Service无法获取EXTERNAL-IP：

  需确认集群已集成云平台负载均衡（比如AWS ELB、阿里云SLB），若为自建集群，需部署metalLB等负载均衡组件，否则EXTERNAL-IP会一直处于pending状态。

六、Ingress故障（外部“入口”出问题，用户无法访问业务）

Ingress负责将外部请求转发到集群内部的Service，相当于集群的“网关”，Ingress故障会导致外部用户无法访问业务，常见问题集中在规则配置、Ingress控制器、域名解析上。

常见现象 域名无法访问（404、502、503错误）、Ingress规则不生效、Ingress状态异常、外部请求无法转发到Service

排查步骤

• 查看Ingress状态和详情：

检查Ingress控制器（必查！Ingress依赖控制器才能生效，比如nginx-ingress、traefik）：

检查域名解析和Ingress规则：

检查Ingress转发的Service是否正常：

1. 常见故障定位与解决

• Ingress规则不生效：

  检查Ingress的rules配置（host、path是否正确）；

  path匹配规则是否正确（比如前缀匹配需加/，精确匹配需加=）；

  检查Ingress的annotations配置（比如nginx.ingress.kubernetes.io/rewrite-target，若配置错误会导致转发失败）；

  重启Ingress控制器Pod。

• 域名访问404：

  域名解析错误（未指向Ingress入口IP）；

  Ingress规则中的host与访问域名不匹配；

  Ingress关联的Service无可用Pod（endpoints为空）；

  path配置错误，未匹配到正确的Service。

• 域名访问502：

  Ingress转发的Service无法访问（Service IP或端口错误）；

  Pod内部业务异常（比如业务端口未启动）；

  Ingress控制器与Service之间的网络不通。

• 域名访问503：

  Ingress关联的Service无可用Pod（Pod处于Pending、Crash状态）；

  Service的endpoints为空；Ingress控制器未正常运行。

• Ingress控制器启动失败：

  检查控制器配置文件；检查节点资源是否充足；

  检查容器网络插件是否正常，确保控制器Pod能正常通信。

七、PV/PVC故障（存储“仓库”出问题，Pod无法挂载存储）

PV（持久化存储卷）和PVC（持久化存储声明）负责Pod的持久化存储，故障会导致Pod无法挂载存储，进而启动失败（Pending或Error状态），常见问题集中在绑定失败、存储类配置、权限不足上。

1. 常见现象 PVC状态为Pending（无法绑定PV）、Bound但Pod无法挂载存储、Pod启动报错“failed to mount volume”、PV状态异常。

2. 排查步骤

• 查看PV和PVC状态：

查看Pod日志，定位挂载错误：

检查存储类（StorageClass）配置（若使用动态供给）：

1. 常见故障定位与解决

• PVC Pending（无法绑定PV）：

  没有符合条件的PV（PV的storageClassName、accessModes、容量与PVC不匹配）；

  使用动态供给时，存储类配置错误，无法自动创建PV；PV被标记为Retain，且未释放，无法重新绑定。

  解决：创建符合条件的PV（匹配PVC的storageClassName、accessModes、容量）；检查存储类配置，确保能正常动态创建PV；删除无用的PV（Retain状态的PV需手动删除），释放资源。

• Pod无法挂载存储（报错“failed to mount volume”）：

  PV的存储介质异常（比如NFS服务器宕机、本地存储目录不存在）；

  PV的权限配置错误（比如目录权限不足，导致Pod无法读写）；

  PVC与PV的accessModes不匹配（比如PV是ReadWriteOnce，PVC请求ReadWriteMany）。

  解决：检查PV的存储介质是否正常（比如NFS服务器是否可达）；修改PV的存储目录权限（chmod 777）；确保PVC与PV的accessModes、storageClassName一致。

• 动态供给无法创建PV：

  存储类配置错误（比如provisioner配置错误，未部署对应的存储插件）；

  云平台存储服务异常（若为云环境，比如阿里云OSS、AWS EBS异常）；

  权限不足，存储类无法创建PV。

1. 运维提醒

   PV的回收策略（persistentVolumeReclaimPolicy）要根据业务需求配置，默认是Retain（删除PVC后，PV保留，需手动清理），测试环境可配置为Delete（删除PVC后，PV自动删除），避免资源浪费；另外，存储介质要做好监控，比如NFS服务器的运行状态、磁盘占用。

八、故障排查总结（重中之重）

做K8S运维，故障排查的核心是“ 先定位范围，再排查细节；先底层后上层，先硬件后软件 ”，记住以下几点，能帮你少踩很多坑：

1. 排查顺序：Node节点 → K8S核心服务 → Pod → Service → Ingress → PV/PVC（从底层到上层，逐步缩小范围）；

2. 核心工具：kubectl get/describe/logs/exec 四个命令，搭配journalctl（系统日志）、网络工具（curl、telnet、nslookup）；

3. 重点关注：Events（事件）、日志、资源使用情况，大部分故障都能在这三者中找到原因；

4. 预防大于排查：日常做好监控（节点资源、核心服务、Pod状态、网络）、定时备份（etcd、重要数据）、规范配置（避免配置错误），能减少80%的故障。

最后，K8S故障排查没有捷径，只有多踩坑、多总结，才能快速定位问题、解决问题。咱们做云原生运维的，就是在不断排查故障、优化集群的过程中成长的。

如果你们在日常运维中遇到了奇葩的K8S故障，欢迎在评论区留言交流，一起避坑、一起进步！

关注我，后续持续分享云原生运维干货、K8S进阶技巧，带你轻松搞定云原生运维！