nodeport+upstream轮询是最轻量零新增组件方案：改ingress controller为nodeport，nginx代理节点固定端口，k8s内核自动转发至存活pod；关键在于nginx不感知pod ip。
用 NodePort + upstream 轮询节点池绕过 Pod IP 变化
最轻量、零新增组件的方案：把 Ingress Controller 的 Service 改为 NodePort，再让外部 Nginx 代理所有工作节点的固定端口。Pod 怎么漂移都不影响，因为请求先打到节点 IP:Port，K8s 内核自动转发到当前存活的 Pod。
关键点在于避免让 Nginx 直接感知 Pod IP —— 它根本不需要知道。
kubectl patch svc ingress-nginx-controller -p '{"spec":{"type":"NodePort","ports":[{"port":80,"targetPort":80,"nodePort":30080},{"port":443,"targetPort":443,"nodePort":30443}]}}'- 确保所有工作节点防火墙放行
30080和30443 - Nginx upstream 块里只写节点 IP，不写 Pod IP：
upstream ingress_backend { server 192.168.1.10:30080; server 192.168.1.11:30080; server 192.168.1.12:30080; } - 配合
proxy_next_upstream error timeout http_502，单个节点故障时自动切下一节点
用 nginx-upsync-module 对接 Consul 实现无 reload 更新
当你必须精确控制每个后端服务实例（比如非 K8s 环境、多集群混合部署），且不能接受任何 reload，nginx-upsync-module 是目前最稳定的开源选择。它把 Consul 当作配置数据库，worker 进程直接从共享内存读取实时列表，变更秒级生效。
注意它不兼容 queue 指令，但支持 weight、max_fails、fail_timeout 等常用参数。
- Consul 中写入 JSON 列表到 key
/upstreams/api-backend：[{"server":"10.20.30.10:8000","weight":3},{"server":"10.20.30.11:8000","weight":3}] - Nginx 配置中启用 upsync：
upstream api_backend { upsync consul.example.com:8500/v1/health/service/api-backend upsync_timeout=6m upsync_interval=3s upsync_type=consul_health; upsync_dump_path /var/run/nginx/upstream_api_backend.conf; } -
upsync_dump_path是兜底文件，etcd/Consul 不可用时仍能从本地恢复上一次成功同步的列表 - 必须搭配
health_check使用，否则下线节点不会被自动剔除
用 resolver + proxy_pass 直接解析 DNS 名称（适合简单场景）
如果后端服务已注册到支持 SRV 记录或定期 TTL 刷新的 DNS（如 CoreDNS、Consul DNS 接口），可以用 Nginx 原生命令实现最小改动的动态发现。但它只适用于后端数量少、变更不频繁、且 DNS 解析足够可靠的场景。
风险在于：Nginx 默认只解析一次域名，不刷新；必须显式配置 resolver 和 valid 才能触发周期性重查。
- 在
http块顶部声明 resolver：resolver 10.96.0.10 valid=5s;
- location 中用变量承接动态域名：
set $backend "api-service.default.svc.cluster.local"; proxy_pass http://$backend;
- 不能写成
proxy_pass http://api-service.default.svc.cluster.local—— 那样只会解析一次，后续变更完全无效 - DNS 返回多个 A 记录时，Nginx 默认 round-robin，但不支持权重、健康检查或连接复用控制
OpenResty + Lua 主动拉取 Nacos/Consul API（高定制需求）
当你要做灰度路由、按 Header 动态选集群、或需要和内部权限系统联动时，balancer_by_lua* 是唯一可行路径。它绕过 Nginx upstream 静态结构，在每次请求阶段用 Lua 构建目标地址，自由度最高，但也最易出错。
别低估 shared dict 缓存 TTL 和错误降级逻辑的复杂度 —— 一次 Consul 网络超时若没兜住，整个 upstream 就会瘫痪。
- 用
resty.http请求 Nacos 实例列表：local httpc = require "resty.http".new() local res, err = httpc:request_uri("http://nacos:8848/nacos/v1/ns/instances?serviceName=order", { method = "GET" }) - 结果解析后调用
balancer.set_current_peer(ip, port)，必须在balancer_by_lua_block内完成 - 务必设置
lua_shared_dict discovery_cache 10m;并加锁+TTL，避免每请求都刷 API - 失败时 fallback 到本地缓存或预设兜底地址，否则
proxy_pass会直接报502 Bad Gateway
upsync 或 resolver 只管地址更新，不负责探测存活；漏掉 health_check 或 Lua 层的主动探活，就等于把流量持续打向已宕机的节点。
