Nginx不负责服务编排，仅执行负载均衡；它依赖编排系统（如Kubernetes）提供动态后端地址，通过静态配置更新、DNS SRV解析或前置网关三种方式实现服务发现，核心是分工明确、各司其职。
Nginx 本身不负责服务编排，但它能很好地承接编排系统输出的动态服务发现结果，实现容器集群的负载均衡。关键在于把“谁在运行、在哪运行、是否健康”这些编排层的信息，实时同步给 Nginx，让它知道该把请求转发到哪些容器实例上。
服务编排与 Nginx 的协作边界要清楚
服务编排（如 Docker Swarm、Kubernetes、Nomad）管的是容器生命周期：启停、扩缩容、健康检查、网络发现、服务注册。Nginx 不参与这些，它只做一件事：按规则把流量分发到已知的后端地址。所以两者不是替代关系，而是上下游配合——编排系统“告诉”Nginx 后端列表，Nginx “执行”转发逻辑。
让 Nginx 感知容器动态变化的三种主流方式
静态配置 + 外部工具更新（适合中小规模）
编排平台通过脚本或插件（如 consul-template、nginx-upstream-conf）监听服务注册中心（Consul、etcd）的变化，自动生成upstream块并重载 Nginx 配置。例如：当 Kubernetes 中 Pod 新增/销毁时，脚本解析 Endpoints 或 Service IP，写入/etc/nginx/conf.d/backend.conf，再执行nginx -s reload。优点是轻量、可控；缺点是重载有毫秒级抖动，不适用于秒级扩缩场景。Nginx Plus 或 OpenResty + 动态 resolver（支持 DNS SRV）
利用 Nginx 的resolver指令配合上游服务的 DNS SRV 记录（如 Kubernetes Headless Service），让 Nginx 主动轮询 DNS 获取后端地址。配合proxy_pass http://service-name直接使用服务名，Nginx 会自动解析并负载均衡。需注意：普通开源 Nginx 仅支持 A/AAAA 记录轮询，SRV 支持需 Nginx Plus 或 OpenResty + lua-resty-resolver 模块。反向代理网关前置（推荐用于生产环境）
不直接让 Nginx 管理容器后端，而是将 Nginx 作为边缘入口，后端统一接入一个具备服务发现能力的网关（如 Traefik、Envoy、API7）。这类网关原生集成 Kubernetes Service、Docker Swarm 网络或 Consul，能实时订阅实例变更，并将流量按策略路由。Nginx 在此角色中退为 TLS 终结、WAF 或静态资源缓存层，专注自身强项，避免承担复杂的服务发现逻辑。
配置要点不能忽略
-
upstream块里每个server应配置max_fails=3 fail_timeout=30s，让 Nginx 主动探测失败并临时剔除异常容器； - 使用
keepalive 32提升长连接复用率，减少容器侧 TIME_WAIT 压力； - 若用
ip_hash或sticky session，需确认容器应用本身支持会话亲和，且编排层未强制滚动更新导致 IP 频繁变动； - 日志中建议记录
$upstream_addr，便于追踪请求实际落到哪个容器 IP 和端口。
本质上，Nginx 是负载均衡的执行者，不是决策者。它靠编排系统喂数据，靠合理配置保稳定。把发现交给编排，把转发交给 Nginx，分工明确，系统才容易维护和扩容。
