如何排查GKE部署中HTTP 500内部服务器错误的原因？

1. 查看Pod的应用日志 #

Spring Boot的500错误栈会直接输出到应用日志，这是最直接的排查途径：

• 先列出所有Pod，找到目标应用的Pod名称：kubectl get pods
• 查看Pod日志：kubectl logs <pod-name>，替换<pod-name>为实际名称
• 实时追踪日志：kubectl logs -f <pod-name>
• 查看Pod重启前的历史日志：kubectl logs <pod-name> --previous

2. 检查Pod状态与事件 #

Pod启动异常、资源不足或依赖问题都会引发服务错误，通过describe命令看细节：

• 查看Pod详细信息：kubectl describe pod <pod-name>
• 重点关注Events板块，排查是否有镜像拉取失败、内存/CPU超限、健康检查失败等报错

3. 验证服务与负载均衡配置 #

本地运行正常但集群内报错，可能是端口映射或服务关联问题：

• 查看服务列表：kubectl get svc，确认LoadBalancer的PORT(S)与Pod暴露的端口（比如Spring Boot默认8080）是否匹配，TARGET PORT需指向Pod的正确端口
• 查看服务详情：kubectl describe svc <service-name>，检查Endpoints是否包含正常的Pod IP，确保Pod已被服务正确关联
• 若使用Ingress，检查Ingress规则的路径映射、后端服务是否配置正确

4. 集群内部直接访问Pod验证 #

绕过LoadBalancer，直接在集群内测试Pod的可用性：

• 启动临时测试Pod：kubectl run -it --rm --image=curlimages/curl curl-test
• 在测试Pod内访问目标Pod：curl <pod-ip>:<port>/your-api-path（<pod-ip>可从kubectl get pods -o wide获取）
• 如果这里也返回500，说明问题出在Pod内部的应用；如果正常，问题则在负载均衡或路由层面

5. 配置Google Error Reporting收集错误 #

Error Reporting不会自动捕获所有错误，需按以下步骤配置：

• 确保Spring Boot日志包含完整错误栈，GKE的日志采集器会识别标准Java错误日志格式
• 检查工作负载的服务账号权限：确保其拥有roles/errorreporting.writer角色（默认GKE服务账号通常已具备，若没有需在IAM中添加）
• 触发错误后等待几分钟，查看Cloud Logging中severity=ERROR级别的日志，确认错误已被采集，之后Error Reporting会自动汇总这些错误

6. 排查环境变量与配置差异 #

本地与集群的环境配置不一致是常见问题：

• 查看Pod的环境变量：kubectl exec <pod-name> -- printenv，对比本地docker run时的环境变量，检查是否缺失数据库连接、API密钥等关键配置
• 若使用ConfigMap/Secret，查看配置内容：kubectl get configmap <configmap-name> -o yaml、kubectl get secret <secret-name> -o yaml，确认配置正确

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