Gcloud Kubernetes集群Pod公网访问失败，求助排查原因

咱们一步步来拆解你遇到的问题，先从核心关联和基础配置入手，逐个排查可能的遗漏点：

1. 验证服务与Pod的Selector匹配是否正常 #

这是最容易踩坑的点，先确认服务真的关联到了你的Pod：

• 执行kubectl describe service <你的服务名称>，查看Endpoints字段，如果是空的，说明Selector没匹配上
• 再执行kubectl get pod myapp --show-labels，确认Pod的label里确实有app=myapp（注意大小写、拼写，别打错字）
• 如果Endpoints里已经有Pod的IP，说明关联没问题，继续往下查

2. 检查防火墙规则的配置细节 #

你创建的MY-RULE大概率缺了关键参数，导致规则没应用到GKE节点上：

• GKE节点默认带有专属标签（比如gke-<集群名>-<节点池名>-<随机后缀>），你创建规则时必须指定--target-tags把规则绑定到节点上，否则规则不会生效
• 正确的创建命令应该是：

  gcloud compute firewall-rules create MY-RULE \
    --allow tcp:8500-8501 \
    --target-tags=gke-<你的集群名称>-<节点池名称>-<后缀> \
    --source-ranges=0.0.0.0/0
  

  不知道节点标签的话，用gcloud compute instances list查看节点的Tags字段即可。另外--source-ranges=0.0.0.0/0是允许所有公网IP访问，别漏掉这个参数。

3. LoadBalancer服务的深层排查 #

如果LB已经拿到公网IP但还是访问不了，重点看这两点：

• 执行kubectl get service <LB服务名>，确认EXTERNAL-IP是有效的公网IP（不是<pending>），如果是pending，可能是GCP负载均衡器配额不足，或者集群权限有问题
• 查看后端健康检查状态：GCP会自动为LB配置健康检查，如果你的应用没有提供健康检查路径，或者健康检查失败，LB会切断流量。可以通过GCP控制台的负载均衡器页面查看健康检查状态，或者执行kubectl describe service <LB服务名>看Events里的提示
• 确认服务的targetPort和Pod的containerPort完全一致，别把8500写成8501了

4. NodePort服务的注意事项 #

NodePort的坑主要在端口范围：

• GKE默认NodePort的端口范围是30000-32767，你创建服务时如果没指定nodePort，kubectl会自动分配一个端口，你需要用kubectl get service <NodePort服务名>找到这个自动分配的端口，然后用节点公网IP:分配的NodePort访问（比如1.2.3.4:30850），而不是直接用8500
• 同时要确保防火墙规则开放了这个分配的NodePort端口，或者直接开放整个30000-32767范围（生产环境建议只开放用到的端口）

5. HostPort的限制与替代方案 #

HostPort在GKE里不推荐用，因为每个节点上同一个HostPort只能被一个Pod占用，而且调度限制多。如果一定要用，除了防火墙规则，还要确认：

• Pod被调度到的节点上8500、8501端口没有被其他进程占用
• Pod的hostPort配置和containerPort一致，而且Pod已经成功调度到节点上

6. 关键验证：Pod内应用的监听地址 #

最后一定要确认你的应用是不是监听了0.0.0.0，而不是127.0.0.1：

• 执行kubectl exec -it myapp -- netstat -tulpn（如果容器里没有netstat，用ss -tulpn），查看8500、8501端口的监听地址，如果是127.0.0.1，那只有容器内部能访问，公网肯定连不上，需要修改应用的启动参数，让它监听0.0.0.0

按照这个顺序排查，应该能找到问题所在。

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