动态增减nginx轮询节点的关键是服务发现替代静态配置：k8s用ingress controller监听endpoints，docker+consul用consul-template生成upstream，dns方式配resolver+resolve指令实现自动识别；reload需exec nginx -s reload且master_process on；配合健康检查、无状态后端与/health探针确保平滑扩缩。
在容器化环境中实现 Nginx 轮询负载均衡的动态增减节点，关键不在于“改算法”，而在于让 upstream 配置能自动响应后端服务实例的变化——轮询本身是默认且稳定的策略，真正要解决的是配置如何“活起来”。
用服务发现替代静态 server 列表
手动在 upstream 块里增删 server 行，在容器环境（如 Docker Swarm、Kubernetes）中不可持续。必须把节点列表交给外部服务发现机制管理：
- Kubernetes 场景：直接使用 Nginx Ingress Controller，它监听 Endpoints 或 EndpointSlices 变化，自动更新 upstream 配置，无需你碰 nginx.conf
- Docker Compose + Consul：通过 consul-template 监听服务注册，自动生成并热重载 upstream 块（例如每次新容器上线，生成含新 IP 的 backend.upstream 文件）
- 通用 DNS 方式：配置 resolver + SRV/A 记录解析，Nginx 定期刷新 DNS，配合 resolve 指令实现自动识别新增节点
示例：
resolver 127.0.0.11 valid=5s; # Docker 内置 DNS
upstream app { server myapp.local resolve; }
确保 reload 真正平滑且无损
即使配置动态生成，最终仍需触发 nginx -s reload 才能生效。这点在容器中尤其要注意：
- 不要用 kill -HUP 或直接替换二进制；标准做法是 exec nginx -s reload（在容器内执行）
- 确认容器启动时以 master_process on; 运行，否则 reload 无效
- 长连接（如 WebSocket、gRPC 流）不受影响，但新连接立即走新 upstream —— 这正是轮询动态分发的基础
- 建议配合健康检查（如 max_fails=3 fail_timeout=30s），避免 reload 后瞬间打到尚未就绪的新容器
后端服务必须无状态 + 健康就绪探针
轮询再灵活，也救不了设计缺陷：
- 会话不能存本地内存（如 Tomcat 的 HttpSession），应统一走 Redis 或 JWT
- 每个容器启动后必须暴露 /health 端点，并返回 200；Nginx 主动探针或 K8s livenessProbe 都依赖这个信号判断是否纳入轮询池
- 新节点上线后，要等探针连续成功几次才参与流量分发（Nginx Plus 支持 slow_start，开源版可用第三方模块模拟）
轮询本身无需额外配置，但别忽略基础健壮性
轮询是默认策略，不用显式写 round-robin，但几个细节决定是否真可靠：
- 所有 server 行建议统一加 max_fails=2 fail_timeout=15s，让故障节点快速剔除
- 避免混用 backup 和 down，它们会干扰自动扩缩逻辑；动态场景下尽量只用健康检查驱动上下线
- 如果容器 IP 经常变动（如 bridge 网络），优先用 host 网络或 Service DNS 名，而非固定 IP
