GKE部署Magento时使用LoadBalancer暴露nginx出现80端口连接超时问题

对应报错：dial tcp IP:80: connect: operation timed out

优先核查Service本身的配置匹配问题 #

执行完kubectl expose deployment nginx --port=80 --type=LoadBalancer后，第一时间核对生成的Service配置：

• 执行kubectl get svc nginx -o yaml，重点检查两个核心配置段：
  • 端口映射：确认targetPort值和Deployment里nginx容器声明的containerPort: 80完全一致。命令行自动生成Service时经常出现端口识别错配，把流量转发到非nginx监听的端口上，直接导致连接超时。
  • 标签选择器：确认selector段的标签和nginx Pod模板的标签完全对齐，也就是要同时匹配app: nginx、tier: backend两个标签。如果标签匹配不上，Service根本找不到后端的可用Pod。
• 执行kubectl get endpoints nginx核查后端绑定状态：如果ENDPOINTS列是空值，基本可以确定是标签选择器匹配错误，需要修正Service的selector配置。

核查GKE云网络层的规则连通性 #

这类超时往往不是K8s本身的配置问题，而是云侧网络规则拦截了流量：

• 先确认LoadBalancer的External IP分配状态：执行kubectl get svc nginx，如果EXTERNAL-IP一直处于<pending>状态，说明GKE的云负载均衡器创建失败，常见原因是VPC子网IP段不足、GCP配额超限。
• 核对负载均衡关联的防火墙规则：GKE创建LoadBalancer服务时，会自动生成入站规则，把外部流量转发到节点上随机分配的NodePort高位端口。如果之前手动调整过VPC防火墙、或者集群开启了私有网络限制，就可能出现外部流量能到云负载均衡层，但是被节点的防火墙拦截、无法转发到后端Pod的情况。
  操作时可以先拿到nginx服务对应的NodePort端口值（形式为3xxxx的高位端口），核对集群节点所在子网的入站规则，确认该NodePort端口的流量没有被防火墙拦截。
• 如果使用的是私有集群，还要核查节点路由、主节点授权网络的限制，确认公网到负载均衡的流量路径没有被网络策略拦截。

核查nginx Pod本身的运行状态 #

排除网络和Service配置问题后，确认Pod本身是否正常提供服务：

• 执行kubectl get pods -l app=nginx，确认nginx Pod处于Running状态，没有出现CrashLoopBackOff、启动失败的情况。
• 本地验证Pod内的端口连通性：执行kubectl exec -it <对应nginx Pod名称> -- curl localhost:80，如果本地回环访问都失败，说明nginx本身的配置有问题——比如挂载的ConfigMap里的site.conf存在语法错误，导致nginx启动后没有正常监听80端口，或者根本没有成功启动。
• 执行kubectl logs <对应nginx Pod名称>，排查Pod启动阶段的报错，确认配置加载、端口绑定环节是否有异常。

避坑提示 #

• 依赖kubectl expose命令自动生成Service的方式容易出现配置错配，更稳妥的方式是手动编写独立的Service配置清单，显式声明选择器和端口映射关系，避免自动匹配出错：

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: LoadBalancer
  selector:
    app: nginx
    tier: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

• 如果集群启用了NetworkPolicy，要确认配置的规则允许LoadBalancer来源的流量访问nginx的80端口。之前如果是通过Ingress暴露nginx服务，NetworkPolicy往往只放行了Ingress控制器的访问权限，直接切换为LoadBalancer对外暴露时，新的流量来源不在策略允许范围内，就会被直接拦截导致超时。

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