K8s 应用故障排查：常见问题及解决思路汇总

花笺墨韵

于 2025-03-15 16:19:25 发布

阅读量998

点赞数 23

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/wdfdgygg77/article/details/146281139

版权

${"type":"load_by_key","key":"banner_image_0","image_type":"search"}$

一、引言

在 Kubernetes（K8s）环境中部署和运行应用时，难免会遇到各种故障。快速准确地排查并解决这些故障，对于保障应用的稳定运行、减少业务中断时间至关重要。K8s 的分布式特性以及复杂的组件交互，使得故障排查工作具有一定挑战性。本文将汇总 K8s 应用常见的故障问题，并提供系统的解决思路与排查方法。

二、Pod 启动失败问题

（一）镜像拉取失败

问题表现：Pod 长时间处于Pending状态，描述信息中显示ImagePullBackOff。例如，执行kubectl describe pod <pod - name>命令后，在Events部分看到类似Failed to pull image "<image - name>": rpc error: code = Unknown desc = Error response from daemon: manifest for <image - name> not found的错误信息。

解决思路：

- 检查镜像仓库连接：确认镜像仓库地址是否可达，可尝试从集群节点使用curl命令访问仓库地址。如果无法访问，可能是网络配置问题，检查防火墙设置、网络代理配置等。例如，若使用私有镜像仓库，需确保节点能访问到仓库的 IP 地址和端口。

- 验证镜像名称和标签：检查镜像名称是否正确，标签是否存在于仓库中。镜像名称应包含仓库地址、镜像名及标签，如registry.example.com/your - image:latest。若标签错误，可能导致镜像拉取失败。

- 检查认证信息：若镜像仓库需要认证，需确保 K8s 中已正确配置认证信息。可以通过创建Secret资源，并在 Pod 的spec.imagePullSecrets字段中引用该Secret来解决认证问题。

（二）容器启动命令错误

问题表现：Pod 进入CrashLoopBackOff状态，容器不断重启。查看容器日志（使用kubectl logs <pod - name>命令），发现报错信息与容器启动命令相关，如executable file not found in $PATH。

解决思路：

- 检查 Dockerfile 或容器启动脚本：确认容器启动命令是否正确。若使用自定义启动脚本，需确保脚本路径正确且有可执行权限。例如，在 Dockerfile 中，CMD或ENTRYPOINT指令定义的命令应准确无误。若启动脚本需要依赖某些环境变量，需确保这些环境变量在容器中已正确设置。

- 验证基础镜像：基础镜像中应包含容器启动所需的依赖和工具。如果基础镜像缺少必要的命令或库，可能导致容器启动失败。可以尝试在本地运行基础镜像，执行相关启动命令，检查是否正常。

三、网络通信问题

（一）Pod 间通信失败

问题表现：一个 Pod 无法访问另一个 Pod 提供的服务，使用ping或应用层面的请求都无法成功。例如，在 Pod 内执行ping <target - pod - ip>命令，显示Request timeout。

解决思路：

- 检查网络插件配置：K8s 使用网络插件（如 Flannel、Calico 等）来实现 Pod 间通信。确认网络插件配置正确，相关组件正常运行。例如，检查 Flannel 的kube - flannel.yml配置文件，确保网络地址段设置合理，且kube - flannel Pod 处于Running状态。

- 验证 Pod 网络配置：检查源 Pod 和目标 Pod 的网络配置，包括 IP 地址、端口等。确保目标 Pod 的服务端口已正确暴露，并且源 Pod 的请求能正确到达目标 Pod。可以通过查看 Pod 的spec.containers.ports字段来确认端口配置。

- 排查网络策略：K8s 的网络策略可能限制了 Pod 间的通信。检查是否存在相关网络策略阻止了源 Pod 对目标 Pod 的访问。使用kubectl get networkpolicy命令查看网络策略，并分析其规则。

（二）Service 访问异常

问题表现：通过 Service 的 IP 和端口无法访问后端的 Pod 服务，浏览器访问显示连接超时或服务不可用。

解决思路：

- 检查 Service 配置：确认 Service 的spec.selector字段与后端 Pod 的标签匹配，确保 Service 能正确选择后端 Pod。同时，检查spec.ports字段的配置，包括port（Service 对外暴露的端口）和targetPort（后端 Pod 实际监听的端口）是否正确。

- 验证后端 Pod 健康状态：使用kubectl get pods命令查看后端 Pod 的状态，确保 Pod 处于Running且健康状态。若 Pod 存在问题，可能导致 Service 无法正常转发请求。例如，Pod 可能因为资源不足或应用程序错误而无法提供服务。

- 检查 kube - proxy 运行情况：kube - proxy 负责将 Service 的流量转发到后端 Pod。检查 kube - proxy 组件在各个节点上是否正常运行，其日志中是否有相关错误信息。在节点上执行systemctl status kube - proxy命令查看其运行状态。

四、资源不足问题

（一）CPU 和内存资源不足

问题表现：Pod 运行缓慢，出现卡顿现象，或者被 K8s 驱逐（Evicted状态）。使用kubectl top pods命令查看 Pod 的资源使用情况，发现 CPU 或内存使用率持续高于 Pod 定义的limits。

解决思路：

- 优化应用程序：检查应用程序代码，看是否存在资源消耗过高的代码逻辑，如内存泄漏、死循环等。对应用程序进行性能优化，减少不必要的资源占用。

- 调整资源请求和限制：根据应用实际的资源需求，合理调整 Pod 的resources.requests和resources.limits。例如，如果应用在高负载下需要更多内存，可以适当增加limits.memory的值，但同时要确保节点有足够的资源可供分配。

- 扩缩容集群：若集群整体资源不足，考虑增加节点数量或升级节点的硬件配置。使用 K8s 的自动扩缩容功能（如 Horizontal Pod Autoscaler，HPA），根据资源指标自动调整 Pod 副本数量。

（二）存储资源不足

问题表现：Pod 因无法挂载存储卷而启动失败，或者在运行过程中出现磁盘空间不足的错误。例如，应用程序写入文件时提示磁盘已满。

解决思路：

- 清理无用数据：检查存储卷中的数据，删除不必要的文件或日志。对于日志文件，可以设置定期清理策略。例如，使用logrotate工具对日志文件进行管理。

- 扩展存储卷：如果是持久化卷（PV），可以尝试扩展其容量。不同的存储后端有不同的扩展方法，如在 AWS EBS 卷中，可以在控制台直接扩展卷的大小，然后在 K8s 中更新 PersistentVolumeClaim（PVC）以使用扩展后的容量。

- 调整存储策略：评估应用对存储的需求，考虑使用更高效的存储策略。例如，对于一些读写频繁但对数据持久性要求不高的应用，可以使用EmptyDir存储卷，它基于节点的内存或磁盘临时存储数据，不会占用持久化存储资源。

五、总结

K8s 应用故障排查需要对 K8s 的各个组件和运行机制有深入理解。通过对 Pod 启动失败、网络通信问题、资源不足等常见故障的分类排查，结合具体的错误信息和排查方法，能够逐步定位并解决问题。在实际工作中，建立完善的监控体系和故障排查流程，有助于更快速地应对和解决 K8s 应用故障，保障业务的连续性和稳定性。