避免业务中断，K8s节点故障排查攻略，速来围观！

Kubernetes故障排查方法论

网络诊断：

• 连通性测试：使用 ping、nc、telnet 等工具测试 Pod 间的网络连通性，或通过 curl 检查服务端口是否可达。

• NetworkPolicy 检查：确认 NetworkPolicy 规则是否过于严格导致通信阻断，使用 kubectl get netpol 查看并分析现有策略。

• CNI 插件排查：检查 CNI 插件（如 Calico、Flannel 等）的日志，排查网络配置或插件自身问题。

存储问题排查：

• PVC/PV 状态检查：使用 kubectl get pvc,pv 查看 PersistentVolumeClaim 和 PersistentVolume 的绑定状态与容量，确认是否存在未绑定、容量不足等问题。

• 存储日志与事件：检查存储插件（如 Local Volume、CSI Driver 等）日志，以及 PVC/PV 的事件信息，查找存储访问异常。

• 数据完整性验证：必要时，直接在宿主机上挂载存储卷，检查数据完整性和一致性。

资源调度与亲和性问题：

• 节点资源分析：使用 kubectl top nodes 查看节点资源使用情况，判断是否存在资源瓶颈。

• 调度策略检查：确认 Deployments、StatefulSets 等资源的 .spec.template.spec.nodeSelector、.spec.affinity、.spec.tolerations 等调度相关字段配置，看是否限制了 Pod 的调度范围。

• kube-scheduler 日志：分析 kube-scheduler 日志，了解调度决策过程，找出影响调度的因素。

认证授权与访问控制：

• RBAC 规则审查：使用 kubectl get rolebindings,clusterrolebindings 检查角色绑定关系，确保用户或服务账户具有正确的 API 访问权限。

• API Server 访问日志：分析 kube-apiserver-audit.log，跟踪特定用户或账户的 API 请求与响应，排查授权问题。

• 网络代理与认证配置：检查 kubeconfig 文件、API Server 配置及网络代理（如 kube-proxy、ingress-nginx 等）的认证设置，确保访问路径无误。

不管是否初学者，大家一般都可以从现象识别到问题定位，再到深入排查与解决方案制定，形成一套完整的问题解决闭环。随着实践经验的积累，排查效率与解决问题的能力将不断提升。

三、K8S 常见故障案例

下面再给大家来些经典的故障案例及其排查方法：

故障案例1：服务间网络通信异常，表现为超时或连接失败

问题点：Kubernetes 集群内不同服务之间的网络通信出现异常，表现为请求超时、连接失败或响应缓慢。

影响范围：

• 直接影响：服务间依赖关系中断，导致依赖服务的功能不可用或性能下降。

• 间接影响：可能波及整个微服务架构，引发连锁反应，造成系统整体不稳定。

排查方法：

1. 验证服务状态：使用 kubectl get svc 和 kubectl get po 确认涉及的服务和 Pod 是否正常运行。

2. 测试网络连通性：在出现问题的 Pod 内使用 ping、nc 或 curl 等工具测试与目标服务的网络连通性，包括 ClusterIP、NodePort 或 Headless Service 的 DNS 解析。

3. 检查 NetworkPolicy 规则：使用 kubectl get netpol 查看是否有 NetworkPolicy 规则限制了服务间的通信。

4. 检查网络插件日志：检查网络插件（如 Calico、Flannel 等）的日志，寻找可能的网络异常或配置问题。

5. 排查 DNS 解析问题：如果通过服务名访问出现问题，检查内部 DNS 服务（如 CoreDNS）日志，确认服务 DNS 记录是否正确。

故障案例2：Pod 无法启动，状态持续为 ImagePullBackOff

问题点：Pod 在创建过程中无法成功拉取指定的容器镜像，状态持续显示为 ImagePullBackOff。

影响范围：

• 直接影响：该 Pod 无法启动，对应的服务或应用无法正常运行。

排查方法：

1. 查看 Pod 事件：使用 kubectl describe pod <pod-name> 查看 Pod 的详细状态和事件列表，定位到与镜像拉取相关的事件，通常会包含具体的错误信息。

2. 验证镜像名称与仓库：确认提交的 Pod 定义（如 Deployment、StatefulSet 等）中使用的镜像名称、标签和仓库地址是否正确无误，且与实际存在的镜像匹配。

3. 检查私有仓库访问：如果镜像位于私有仓库，确认 Deployment 的 imagePullSecrets 是否已正确配置了仓库访问凭据，以及网络是否允许 Pod 访问仓库。

4. 测试镜像拉取：在集群内其他节点或同一节点上的另一个容器中尝试手动拉取镜像，以排除网络或仓库临时问题。

5. 检查镜像仓库状态：如果镜像仓库位于外部，检查仓库服务的运行状态和日志，确保服务正常且镜像可供下载。

故障案例3：节点资源压力告警，触发 MemoryPressure 或 DiskPressure

问题点：Kubernetes 节点报告内存或磁盘资源压力，标记节点状态为 NotReady 或应用 MemoryPressure、DiskPressure 污点，导致调度器不再将新 Pod 调度到该节点。

影响范围：

• 直接影响：节点上的现有 Pod 可能因资源不足而性能下降或被系统强制终止。

• 间接影响：集群的整体资源利用率降低，新部署或扩缩容的操作受阻，可能导致服务容量不足或响应延迟。

排查方法：

1. 查看节点状态：使用 kubectl get node 查看所有节点状态，重点关注 Conditions 列中的 MemoryPressure 和 DiskPressure 状态。

2. 检查资源使用情况：使用 kubectl top nodes 查看节点的实时资源使用率，对比节点的总资源容量，判断是否存在过度消耗。

3. 分析资源消耗大户：使用 kubectl top pods --all-namespaces --sort-by=memory 或 --sort-by=cpu 查找占用资源最多的 Pod，分析其资源使用合理性。

4. 检查磁盘使用情况：对于 DiskPressure，使用 df -h 或 du -sh /*（在节点上执行）查看磁盘空间使用情况，定位占用空间大的目录。

5. 清理资源或调整策略：根据分析结果，可能需要清理无用数据、优化 Pod 资源请求/限制、调整日志留存策略、迁移部分工作负载到其他节点等。

故障案例4：Ingress 资源更新后，外部访问未按预期生效

问题点：修改或新增 Ingress 资源后，外部客户端通过 Ingress 的域名访问服务时，路由规则、TLS 配置等未按预期更新。

影响范围：

• 直接影响：外部客户端无法访问到最新部署的服务，或访问行为不符合更新后的 Ingress 规则。

• 间接影响：可能影响用户体验、业务流程或数据一致性，特别是在进行版本升级、功能切换等重要变更时。

排查方法：

1. 确认 Ingress 更新状态：使用 kubectl get ingress <ingress-name> -o yaml 查看 Ingress 资源的最新配置，确认更新已生效。

2. 检查 Ingress Controller 日志：查看负责处理 Ingress 的控制器（如 Nginx Ingress Controller、Traefik 等）的日志，查找与 Ingress 更新相关的事件和错误。

3. 测试内部服务访问：使用 kubectl exec 进入集群内其他 Pod，通过 ClusterIP 或 NodePort 直接访问服务，验证服务本身是否正常。

4. 清理缓存或等待传播：如果涉及 DNS 缓存问题，可能需要等待 DNS 记录在全球范围内更新，或者在客户端手动清理 DNS 缓存后再试。

5. 检查负载均衡器配置：对于云服务商托管的 LoadBalancer 类型 Ingress，检查云平台控制台中负载均衡器的配置是否已同步更新。

故障案例5：Kubernetes API 服务器响应变慢或不可用

问题点：Kubernetes API 服务器响应时间明显增加，或出现无法连接、请求超时、返回错误等情况。

影响范围：

• 直接影响：所有依赖 Kubernetes API 的操作（如 kubectl 命令、CI/CD 流程、集群自动化管理等）都将受到影响。

• 间接影响：可能导致集群管理困难、应用部署延迟、监控数据丢失、故障响应不及时等问题，严重时可能影响整个系统的稳定运行。

排查方法：

1. 检查 API 服务器日志：查看 API 服务器（kube-apiserver）的日志，查找异常消息、错误或警告，定位可能的问题根源。

2. 监控 API 服务器性能指标：监视 API 服务器的 CPU、内存使用率、请求数、错误率等性能指标，判断是否存在资源瓶颈或异常波动。

3. 检查 etcd 状态：API 服务器依赖于 etcd 存储集群状态，使用 etcdctl 工具检查 etcd 集群的健康状况和响应时间。

4. 排查网络问题：检查 API 服务器所在节点的网络连接，确认与其他节点及客户端的网络通信是否正常。

5. 审查近期变更：回顾最近对集群进行的配置更改、版本升级、RBAC 规则调整等操作，判断是否引入了导致 API 性能下降的因素。

故障案例6：Pod 间网络通信时断时续

问题点：Kubernetes 集群内不同 Pod 之间的网络通信出现间歇性中断或延迟严重，时好时坏，无明显规律。

影响范围：

• 直接影响：依赖网络通信的服务或应用可能出现短暂不可用、数据传输失败、请求超时等问题。

• 间接影响：可能导致业务流程中断、数据不一致、用户体验下降，严重时影响整个系统的稳定性和可用性。

排查方案：

1. 监控网络流量与延迟：使用网络监控工具（如 Prometheus + Grafana、Netdata 等）监控 Pod 间的网络流量、丢包率和延迟，观察是否存在周期性波动或异常峰值。

2. 深入抓包分析：在受影响的 Pod 内使用 tcpdump 或 wireshark 抓取网络包进行分析，查找是否存在重传、乱序、RST 包等异常现象。

3. 检查网络插件及底层网络设备：查看网络插件（如 Calico、Flannel 等）的日志，以及宿主机网络设备（如网卡、交换机、路由器等）的状态和日志，排查可能的网络设备故障或配置问题。

4. 分析网络拓扑与策略：使用 kubectl get netpol 查看 NetworkPolicy 规则，确认是否存在过于严格的策略导致网络中断。检查网络拓扑结构，看是否存在可能导致路由不稳定的设计问题（如多路径、浮动 IP 等）。

5. 排查外部干扰因素：考虑是否存在外部网络环境变化（如云服务商网络调整、DDoS 攻击、网络维护等）影响集群内通信。如果可能，尝试更换网络环境或时间段观察问题是否重现。

故障案例7：Kubernetes 控制平面组件间通信异常

问题点：Kubernetes 控制平面组件（如 API 服务器、etcd、控制器管理器、调度器等）之间通信异常，导致集群管理功能受限或失效。

影响范围：

• 直接影响：集群管理功能受限，如无法创建/更新资源、Pod 无法调度、状态更新延迟等。

• 间接影响：可能导致整个集群的稳定性下降，应用无法正常部署、扩展或恢复，数据一致性问题，严重的甚至可能导致集群完全不可用。

排查方案：

1. 检查控制平面组件状态：使用 kubectl get componentstatuses 查看控制平面各组件的状态，关注是否有 Unhealthy 或 Unknown 的组件。

2. 查看控制平面日志：分别检查 API 服务器、etcd、控制器管理器、调度器等组件的日志，查找与通信异常相关的错误或警告。

3. 检查 etcd 集群健康状况：使用 etcdctl 工具检查 etcd 集群的健康状况、成员列表、领导者选举状态等，确认各成员间通信是否正常。

4. 检查控制平面网络连接：使用 netstat、ss 或 telnet 等工具检查控制平面组件之间的网络连接，确认端口是否可达、TCP 连接是否正常。

5. 审查控制平面配置：检查控制平面组件的配置文件（如 /etc/kubernetes/manifests 下的静态 Pod 清单），确认 API 服务器的 --etcd-servers、控制器管理器和调度器的 --master 参数等是否正确。

故障案例8：StatefulSet 中 Pod 无法完成初始化或滚动更新

问题点：StatefulSet 中的 Pod 在创建或滚动更新过程中无法完成初始化，始终处于 Pending 或 ContainerCreating 状态，或反复重启。

影响范围：

• 直接影响：对应 StatefulSet 的服务无法按预期提供完整功能，数据一致性或可用性可能受到影响。

排查方案：

1. 查看 Pod 事件与状态：使用 kubectl describe pod <pod-name> 查看 Pod 详细状态和事件列表，定位问题发生的具体阶段和原因。

2. 检查存储卷关联与状态：使用 kubectl get pvc 查看 PersistentVolumeClaim（PVC）的状态，确认 PVC 是否已绑定到合适的 PersistentVolume（PV），PV 是否正常。检查 PV 的详细信息，确认其状态、容量、访问模式等是否满足 StatefulSet 的要求。

3. 检查存储服务日志与状态：如果使用的是云服务商提供的存储服务（如 OSS、S3、Disk、NAS等），检查其控制台或日志，确认存储服务本身无异常。

4. 检查应用初始化脚本：如果 StatefulSet 中的 Pod 在启动时执行了自定义的初始化脚本（如 initContainers），检查这些脚本的逻辑和输出，确认无误。

5. 验证存储卷数据完整性：如果怀疑存储卷数据损坏或不一致导致问题，尝试在其他节点上挂载该 PV，检查数据是否正确。必要时，从备份恢复数据。

故障案例9：Helm 升级应用后部分功能异常

问题点：使用 Helm 升级 Kubernetes 应用后，部分功能出现异常，如服务不可用、接口返回错误、数据不一致等。

影响范围：

• 直接影响：升级后的应用无法正常提供全部功能，可能影响用户访问、数据处理、业务流程等。

• 间接影响：可能导致信任度下降、运维复杂度增加、回滚成本增大。

排查方案：

1. 对比旧版与新版资源定义：使用 helm get values <release-name> 和 helm get manifest <release-name> 获取升级前后的资源定义和配置值，对比差异，看是否有误删、误改的关键配置。

2. 检查滚动更新策略：使用 helm get all <release-name> 查看 Helm Release 的详细信息，确认滚动更新策略（如 maxUnavailable、maxSurge）是否合理，是否可能导致服务中断。

3. 检查应用日志与状态：使用 kubectl logs 和 kubectl describe 查看升级后 Pod 的日志和状态，定位具体出错的服务或组件。

4. 验证数据迁移或迁移脚本：如果升级涉及数据迁移，检查迁移脚本或工具的执行结果，确认数据是否正确迁移。对于有状态应用，确认新旧版本能否正确共享存储。

5. 回滚并逐步升级验证：如果问题难以定位，可先回滚到旧版本，然后逐步升级部分组件或功能，观察问题是否重现，缩小排查范围。

故障案例10：Kubernetes 集群频繁出现节点 NotReady

问题点：Kubernetes 集群中的节点频繁出现 NotReady 状态，即使自动恢复后不久又再次变为 NotReady。

影响范围：

• 直接影响：节点上运行的 Pod 可能被驱逐，导致服务中断、数据丢失或处理延迟。

• 间接影响：频繁的节点状态变化可能导致调度压力增大、资源利用率降低，影响集群整体稳定性和性能。

排查方案：

1. 监控节点资源使用：使用 kubectl top nodes 和第三方监控工具（如 Prometheus + Grafana）持续监控节点的 CPU、内存、磁盘、网络等资源使用情况，查找是否有资源耗尽的迹象。

2. 检查节点日志与系统状态：登录到问题节点，检查系统日志（如 /var/log/messages、/var/log/syslog 等）、Docker（或 Containerd）日志、kubelet 日志，查找与节点状态变化相关的错误或警告。

3. 排查硬件故障或网络问题：检查节点的硬件状态（如 CPU、内存、磁盘健康状况），以及网络设备（如网卡、交换机）的状态和日志，看是否存在硬件故障或网络问题。

4. 检查节点配置与污点：使用 kubectl describe node <node-name> 查看节点详细信息，确认节点配置（如标签、Taints）是否合理，是否被正确调度。

5. 排查系统级软件问题：检查节点的操作系统、内核、kubelet、Docker（或 Containerd）、CNI 插件等软件版本和配置，确认无已知问题或冲突。必要时，升级到稳定版本或重新安装。

1、步骤一：检查节点状态

首先，通过以下命令检查节点的整体状态：

kubectl get nodes

执行上述命令，输入结果如下图：

确认所有节点都处于Ready状态。如果有节点处于NotReady状态，可以运行以下命令查看详细信息：

kubectl describe node <node-name>

例如，现在要查看node01节点详细信息，如下图：

2、步骤二：查看事件

使用以下命令查看集群中的事件，以了解任何异常情况：

kubectl get events

执行上述命令，输入结果如下图：

3、步骤三：系统资源检查

确保节点上的系统资源（CPU、内存、磁盘空间）足够。可以通过以下命令检查：

kubectl describe node <node-name> | grep Allocated -A 5

执行上述命令，输入结果如下图：

4步骤四：网络排查

确认网络插件状态

检查网络插件是否正常运行。常见的网络插件有Flannel、Calico等。使用以下命令检查：

kubectl get pods -n kube-system

执行上述命令，输入结果如下图：

检查节点之间的网络连通性

确认节点之间的网络通信是否正常。使用工具如ping、traceroute等检查节点间的连通性。例如，下图是从node01节点ping控制节点controlplane

5、步骤五：检查容器运行时状态

如果使用Docker作为容器运行时，请检查Docker容器的状态：

docker ps
docker logs <container-id>

如果使用了containerd为容器运行时，请检查containerd容器的状态，如下图：

6、步骤六：检查kubelet服务状态

确保kubelet服务在节点上正常运行。运行以下命令：

systemctl status kubelet

检查输出以确保kubelet服务处于激活（active）状态。如果kubelet服务未激活，运行以下命令重启kubelet服务：

sudo systemctl restart kubelet

7、步骤七：重启故障节点

在确保不影响生产负载的情况下，可以尝试重启故障的节点。使用以下命令：

kubectl drain <node-name> --ignore-daemonsets
kubectl delete node <node-name>

8、结论

通过以上步骤，您应该能够诊断并解决Kubernetes节点故障的常见问题。请注意，在进行操作之前，确保已经了解操作的潜在风险，并在非生产环境中进行测试。保持对K8S集群的定期监控，以及学习并熟练使用K8S提供的工具，将有助于更好地管理和维护您的容器化应用程序。