如何调试GCP上无法正常对外服务的Kubernetes服务端点？

我之前也踩过类似的坑——本地跑容器功能完全正常，一部署到GCP的K8s LoadBalancer就访问不通，别慌，咱们一步步拆解排查：

1. 先确认Kubernetes内部服务是否正常 #

首先得排除是K8s内部Pod或Service的问题，而非外部负载均衡的故障：

• 检查Pod运行状态：执行kubectl get pods，确保你的subway-explorer-gmaps-proxy Pod处于Running状态，没有CrashLoopBackOff或Error标识。如果有异常，立刻查看Pod日志定位问题：kubectl logs <你的Pod名称>，重点排查是否缺环境变量、配置文件或启动依赖。
• 测试集群内部访问：临时启动一个调试Pod（比如kubectl run -it --rm debug-pod --image=busybox:1.28 -- sh），在这个Pod里用curl访问Service的ClusterIP和端口，比如curl http://<Service的ClusterIP>:<端口号>。如果内部访问都失败，那问题肯定出在Pod或Service配置上——比如检查Service的targetPort是否和Pod暴露的端口完全匹配。

2. 验证LoadBalancer Service的状态与配置 #

• 查看Service详情：执行kubectl describe service <你的Service名称>，重点关注这几点：
  • External IP是否已成功分配（也就是你用的35.224.78.225），如果显示<pending>，说明GCP还在创建负载均衡器，可能需要等待几分钟，或者检查GCP的资源配额是否充足。
  • Type是否为LoadBalancer，Port和TargetPort是否与Pod的监听端口一致。
  • 事件（Events）栏有没有报错，比如“Failed to create load balancer”这类提示。

3. 检查GCP层面的网络配置 #

GCP的LoadBalancer受平台网络规则约束，这部分也不能忽略：

• 防火墙规则验证：确保存在允许外部流量访问LoadBalancer端口的规则。默认情况下K8s会自动创建对应规则，但偶尔会有失效情况。你可以在GCP控制台的「VPC网络>防火墙规则」里，查找k8s-fw-开头的规则，确认它允许0.0.0.0/0访问你的Service端口（比如Service用80端口，规则的目标端口要包含80）。
• 负载均衡器健康检查：GCP的LoadBalancer会定期检测后端Pod的健康状态，如果健康检查失败，流量不会被转发。在GCP控制台的「负载均衡器」页面找到对应的LB，查看后端服务的健康状态。如果检查失败，要确认Deployment里的livenessProbe和readinessProbe配置是否正确——比如健康检查的端口、路径是否和容器实际提供服务的一致。

4. 测试外部访问的网络连通性 #

• 端口连通性测试：在本地机器执行telnet 35.224.78.225 <端口号>或nc -zv 35.224.78.225 <端口号>，看看端口是否能正常连通。如果连不通，大概率是防火墙规则未生效，或者LoadBalancer未正确转发流量。
• 排除本地网络限制：有时候是本地网络（比如公司防火墙）拦截了请求，可以换用手机热点等其他网络环境测试，确认是否是本地网络的问题。

5. 对比本地容器与K8s Pod的配置差异 #

既然本地运行正常，重点对比两者的配置细节：

• 环境变量：本地运行Docker时有没有传入特定环境变量？比如docker run -e KEY=value ...，检查K8s Deployment里是否配置了完全一致的环境变量，可通过kubectl describe deployment <你的Deployment名称>查看。
• 端口映射：本地Docker是否用了-p 80:8080这类端口映射？确认K8s Service的targetPort是容器实际监听的端口（比如本地容器监听8080，那Service的targetPort要设为8080，Port可以设为80）。
• 配置文件：如果容器依赖特定配置文件，本地是挂载了本地文件还是用默认配置？检查K8s里是否用ConfigMap/Secret挂载了正确的配置文件，或者容器是否自带了正确的默认配置。

6. 查看负载均衡器的流量日志 #

如果前面步骤都没找到问题，可以查看GCP负载均衡器的日志：

• 在GCP控制台的「日志查看器」中，选择「Cloud Load Balancing」作为日志来源，过滤你的LoadBalancer的流量日志，查看是否有请求到达，或者有没有4xx/5xx状态码、转发失败等报错信息。

按照这个顺序一步步排查，基本能定位到问题根源。如果某个步骤出现异常，把具体的错误信息贴出来，能更快锁定问题。

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