nginx 与容器调度器协同关键在于解决动态伸缩下的服务发现与地址变更问题，需解耦静态地址、支持自动发现、具备健康感知、平滑应对实例上下线。
使用动态服务发现替代硬编码 IP
容器环境里，后端服务通常通过服务名（如 app-service）在集群内 DNS 解析，而非固定 IP。Nginx 原生不支持动态 DNS 刷新，但可通过以下方式解决：
-
用
resolver+ 变量域名实现有限刷新：在upstream外定义变量，在proxy_pass中引用，并配合resolver和valid参数定期重查 DNS（适用于服务名解析稳定、更新频率低的场景） -
借助第三方模块
nginx-upstream-dynamic或nginx-plus的 API 动态更新 upstream；开源版更常用的是用外部工具（如consul-template、confd或自研脚本）监听容器注册中心（Consul/Etcd/K8s API），生成并热重载 Nginx 配置 - 在 Kubernetes 中，直接用 Ingress Controller（如 nginx-ingress）替代手写 Nginx 配置：它原生监听 Service/Endpoint 变化，自动同步 upstream，无需手动维护
配置健壮的健康检查机制
容器可能瞬间启停或就绪慢，仅靠 TCP 连通性检测不够。应在 upstream 中启用主动健康检查（需 nginx-plus 或开源版搭配 nginx-module-vts 等模块），或至少强化被动检查逻辑：
- 设置
max_fails=3 fail_timeout=30s，避免单次超时误判下线 - 配合
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，在后端返回异常状态或超时时自动转发到下一节点 - 若容器提供
/healthz接口，可在上游服务前加一层轻量探测代理（如 Envoy sidecar），或由外部巡检系统统一管理
适配容器网络与请求透传
容器内部常依赖真实客户端 IP、协议类型等信息。Nginx 必须正确传递这些字段，否则后端日志、限流、鉴权会出错：
- 始终设置
proxy_set_header X-Real-IP $remote_addr和X-Forwarded-For $proxy_add_x_forwarded_for - 添加
proxy_set_header X-Forwarded-Proto $scheme，确保后端识别 HTTPS 请求 - 若容器运行在桥接网络或 Overlay 网络中，确认 Nginx 所在节点能直连容器 IP 或服务 VIP；否则应将 Nginx 部署为容器，并加入同一用户定义网络（如 Docker 自定义 bridge 或 macvlan）
处理会话与有状态流量
多数容器应用设计为无状态，但若存在粘性需求（如未接入共享 Session 存储），需谨慎选择调度策略：
-
ip_hash适合简单场景，但容器重启或客户端 NAT 后 IP 可能漂移，稳定性有限 -
hash $cookie_sessionid更可靠，前提是后端已种下该 Cookie 且路径一致 - 更推荐方式是：**从架构上消除粘性依赖**——用 Redis/Memcached 集中式管理 Session，让任意容器实例都能读写，Nginx 回归纯轮询或 least_conn
