关键是要将NodePort作为稳定入口，由Nginx反向代理统一接入并轮询多个节点IP:nodePort，依赖kube-proxy实现后端负载均衡，避免单点故障和冗余跳转。
要让反向代理（如 Nginx）无缝对接 K8s 的 NodePort 服务，关键不是直接代理 Pod IP，而是把 NodePort 当作稳定入口，再通过 kube-proxy 的转发能力间接实现负载均衡。NodePort 本身已具备跨节点分发能力，反向代理只需面向它做一层统一接入，无需感知后端拓扑变化。
明确 NodePort 的流量路径
NodePort 的本质是：客户端 → 任意节点 IP:nodePort → kube-proxy（iptables 或 IPVS）→ 后端 Pod。这意味着只要集群任一节点可达，请求就能被正确路由。因此反向代理只需固定指向一个或多个节点的 NodePort 地址，无需维护 Endpoint 列表。
- 确认你的 Service 已设 type: NodePort，并指定了 nodePort（如 30080），且 targetPort 匹配 Pod 实际监听端口（如 8080）
- 确保节点防火墙放行该端口（如
firewall-cmd --permanent --add-port=30080/tcp） - 验证从反向代理所在机器能 curl 通任一节点 IP + nodePort（例如
curl http://192.168.45.135:30080）
用 Nginx 做轻量级反向代理层
将 Nginx 部署在集群外部（或边缘节点），作为统一入口，把流量轮询或按权重分发到多个 NodePort 地址上，实现更高可用性和横向扩展能力。
- 在 nginx.conf 的 upstream 块中列出所有工作节点的 IP 和 nodePort，例如：
upstream k8s-nodeport {<br> server 192.168.45.135:30080;<br> server 192.168.45.136:30080;<br> server 192.168.45.137:30080;<br>} - server 块中 proxy_pass 指向该 upstream，保持 Host 和真实客户端 IP：
location / {<br> proxy_pass http://k8s-nodeport;<br> proxy_set_header Host $host;<br> proxy_set_header X-Real-IP $remote_addr;<br>} - 若需会话保持，可启用
ip_hash或基于 cookie 的 sticky session（需后端配合）
避免常见配置陷阱
NodePort 不是传统意义上的“服务实例”，它的高可用依赖 kube-proxy 和节点健康状态。配置反向代理时容易忽略底层机制，导致单点故障或转发失效。
- 不要只写一个节点 IP —— 单节点宕机即中断；至少配置 2 个以上健康节点，Nginx 自动跳过不可达节点（需开启
max_fails=1 fail_timeout=10s） - 不要把 nodePort 当作后端服务端口硬编码进应用逻辑 —— 它只是访问通道，真正的 service 名称和 ClusterIP 应由内部 DNS 解析
- 不建议在集群内再起一个 Nginx Pod 去代理 NodePort —— 这属于冗余跳转，增加延迟；应优先用 Ingress 或直接暴露 LoadBalancer
替代方案：何时该换 Ingress 或 LoadBalancer
如果业务需要 HTTPS、域名路由、路径匹配、WAF 集成等能力，NodePort + 外部 Nginx 就显得笨重。此时应升级为标准方案：
- Ingress 控制器（如 nginx-ingress 或 Traefik）：自动监听 Service 变更，动态生成 upstream，支持 annotation 灵活控制路由策略
- 云厂商 LoadBalancer 类型 Service：自动创建 SLB/ALB，绑定健康检查与 TLS 终止，运维成本最低
- 裸金属环境可部署 MetalLB + Ingress，实现类似云上体验
