Spring微服务部署Kubernetes遇Pod异常及Eureka连接失败求助

一、Pod异常状态（Evicted/Error/Pending）排查 #

1. Evicted状态 #

• 绝大多数情况是节点资源不足（CPU、内存、磁盘均有可能），执行kubectl describe pod <异常Pod名称>查看事件日志，通常会明确提示The node was low on resource: <具体资源类型>
• 检查节点资源使用情况：执行kubectl top nodes，确认是否有节点CPU/内存使用率接近上限，或磁盘空间不足（可通过kubectl exec -it <节点名称> -- df -h查看，需节点操作权限）
• 临时缓解方案：直接删除Evicted状态的Pod释放资源；长期解决方案包括扩容节点、调整Pod的资源请求/限制配置，或清理节点上的无用镜像、日志文件

2. Pending状态 #

• 常见原因：节点无足够资源调度、存储卷绑定失败、节点亲和性/污点容忍配置冲突、镜像拉取失败
• 执行kubectl describe pod <异常Pod名称>查看Events字段：
  • 若提示FailedScheduling且包含Insufficient cpu/memory，说明资源不足，可调整Pod的resources.requests/limits配置或扩容节点
  • 若提示FailedAttachVolume，检查PVC是否绑定成功、存储类配置是否正常
  • 若提示FailedPullImage，排查镜像仓库地址、拉取权限、镜像标签是否正确

3. Error状态 #

• 先查看崩溃前的容器日志：kubectl logs <异常Pod名称> --previous
• 常见诱因：容器启动命令错误、依赖服务不可达、配置文件缺失、权限不足（如非root用户访问受限目录）
• 结合kubectl describe pod <异常Pod名称>的Events信息，确认是启动阶段失败还是运行中崩溃

二、NoHttpResponseException: springboot:30002 failed to respond报错排查 #

该报错表示调用springboot:30002时对方无响应，结合你的Eureka+Gateway+Kafka架构，从以下方向排查：

1. 服务发现与网络连通性 #

• 确认springboot服务在Eureka Server上正常注册：登录Eureka控制台查看实例状态，或在Gateway Pod内执行curl http://eureka-server:8761/eureka/apps/springboot（替换为你的Eureka地址），检查能否获取实例列表
• 在报错的命令服务Pod内测试连通性：
  • 解析域名：nslookup springboot，确认能否解析到正确的Pod IP
  • 测试端口：telnet springboot 30002或nc -zv springboot 30002，检查能否建立连接
  • 若无法连通，排查Kubernetes Service配置：确认springboot的Service是否关联正确的Pod标签、端口映射是否为30002、Service类型是否为ClusterIP（集群内访问默认使用该类型）

2. 目标服务状态 #

• 检查springboot服务的Pod状态：kubectl get pods -l app=springboot（替换为你的Pod标签），查看是否存在CrashLoopBackOff等异常
• 查看springboot服务的容器日志，确认是否存在启动失败、端口未监听、内部错误导致无法处理请求的情况
• 检查健康检查配置：若配置了livenessProbe/readinessProbe，确认探针是否正常，是否因探针失败导致Pod被重启或标记为未就绪

3. 网关转发问题 #

• 若请求通过Spring Cloud Gateway转发，检查Gateway的路由配置：确认路由规则是否正确指向springboot服务，路径匹配、断言配置是否无误
• 查看Gateway的日志，确认请求是否到达Gateway，转发过程中是否出现错误
• 调整Gateway连接池配置：默认HTTP连接池可能因超时、连接耗尽导致无响应，可修改spring.cloud.gateway.httpclient.*相关参数（如连接超时时间、最大连接数）

4. Kafka相关影响 #

• 确认命令服务部署到K8s后能否正常访问本地非容器化Kafka：检查命令服务的Kafka配置（bootstrap.servers）是否正确，能否连通Kafka端口
• 若Kafka连接异常导致命令服务阻塞，可能间接引发服务无响应，进而导致其他服务调用时出现NoHttpResponseException，需确认Kafka的网络可达性（如是否在同一网络、是否有防火墙/安全组限制）

三、整体排查建议 #

1. 优先解决Pod异常状态问题，恢复可用服务实例后，再处理具体的调用报错
2. 针对每个异常Pod，通过kubectl describe和kubectl logs收集详细信息，精准定位原因
3. 逐层验证网络连通性：从Pod到Service、Service到后端Pod、服务到Eureka、服务到Kafka，逐步排查

内容的提问来源于stack exchange，提问作者Rafael Souza