Kubernetes服务架构下NGINX流量分发配置问题求助

你的核心实现思路是对的——在Kubernetes集群里，用NGINX Pod通过upstream指向Service的ClusterIP来转发流量是完全可行的方案。不过没成功的话，大概率是几个细节没做到位，我帮你梳理下：

• 补全NGINX的完整配置
  你只定义了upstream块，但NGINX需要对应的server块来处理 incoming 请求并转发到上游服务。举个完整的配置例子：

  upstream website {
      server 10.27.246.107:8000;
  }
  
  server {
      listen 80;
      server_name _; # 匹配所有请求，也可以指定你的业务域名
  
      location / {
          proxy_pass http://website;
          # 转发必要的请求头，避免后端服务获取不到正确的请求信息
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }
  }
  

  没有server块的话，NGINX根本不知道该如何处理进来的流量，自然不会完成转发。

• 验证NGINX Pod到website-service的连通性
  先排查最基础的网络问题：进入NGINX Pod内部，测试能不能访问目标Service的地址：

  kubectl exec -it <你的NGINX Pod名称> -- curl http://10.27.246.107:8000
  

  如果curl失败，可能的原因包括：

  • 集群配置了NetworkPolicy，限制了NGINX Pod访问website-service的权限
  • website-service的端点（Endpoints）没有正确关联到website Pod，用kubectl get endpoints website-service检查是否有对应的Pod IP
  • website Pod本身未正常启动，或者容器内的8000端口没有在监听（可以进入website Pod用netstat -tulpn验证）

• 推荐用Service DNS名称代替硬编码ClusterIP
  在Kubernetes里，Service的ClusterIP可能会在重建时变化，硬编码IP会导致后续维护问题。更可靠的方式是用Service的DNS名称：
  如果website-service和NGINX Pod在同一个命名空间（比如default），直接用服务名即可：

  upstream website {
      server website-service:8000;
  }
  

  跨命名空间的话，用完整的DNS名：website-service.<命名空间>.svc.cluster.local，这样NGINX能通过Kubernetes的CoreDNS自动解析到正确的ClusterIP。

• 确认http-service与NGINX Pod的关联正确性
  你提到http-service是LoadBalancer类型，要确保它的selector能正确匹配到NGINX Pod的标签。比如如果NGINX Pod的标签是app: nginx-proxy，那http-service的spec里应该有：

  selector:
    app: nginx-proxy
  

  只有这样，外部流量才能通过LoadBalancer转发到NGINX Pod上。

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