nginx 故障转移需与容器编排层联动，核心是可靠同步pod就绪状态并触发后端更新：通过dns轮询、动态upstream或backup server实现自动剔除与灾备，且探针策略须与k8s readiness对齐；推荐将其退为边缘网关，由traefik/envoy等专业网关处理服务发现。
Nginx 本身不感知容器生命周期，故障转移要真正联动容器编排层（如 Kubernetes、Docker Swarm），关键不是让 Nginx “主动发现”容器变化，而是把编排层的调度结果——包括实例增删、就绪状态、健康探针反馈——可靠地同步给 Nginx，并触发其后端列表更新或流量重定向。这种联动不是靠 Nginx 单独完成的，而需分层协作、明确职责。
核心原则：编排层管“状态”，Nginx 管“转发”，中间靠“同步机制”桥接
容器编排层输出健康信号，Nginx 消费并响应
编排系统（如 Kubernetes）通过 Liveness/Readiness 探针持续判断 Pod 是否可服务。当一个 Pod 被标记为 NotReady 或被驱逐时，它会从 Service 的 Endpoints 或 EndpointSlice 中自动移除。Nginx 需要能及时拿到这个变更结果：
- 若使用 Headless Service + DNS SRV 记录（OpenResty 或 Nginx Plus），Nginx 可配置 resolver 并定期轮询 DNS，自动剔除已下线的 A 记录或 SRV 条目，无需人工 reload；
- 若用 静态 upstream + 外部工具（如 nginx-upstream-conf + Kubernetes watch API），工具监听 Endpoint 变更后生成新 upstream 配置，再执行
nginx -s reload——此时故障转移由编排层触发，Nginx 执行剔除动作； - 注意：reload 有毫秒级请求中断风险，生产环境建议启用
worker_shutdown_timeout和平滑 reload，或改用动态 upstream 模块（如lua-resty-upstream）避免 reload。
利用 backup server 实现跨节点灾备级 Failover
当整个应用 Pod 组因节点故障或 namespace 驱逐全部不可用时，仅靠 upstream 内部剔除不够。可在 upstream 中显式定义 backup 实例，指向另一套独立部署的降级服务或灾备集群：
upstream app_backend {
server 10.244.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.244.1.11:8080 max_fails=3 fail_timeout=30s;
server 10.244.2.5:8080 backup max_fails=2 fail_timeout=20s; # 异构集群或离线备用
}
该 backup 不参与日常负载，只在主池全失效时激活，形成编排层无法覆盖时的最后一道防线。
故障转移行为需与编排层探针语义对齐
Nginx 的 max_fails / fail_timeout 是被动检测，依赖真实请求失败；而编排层的 Readiness 探针是主动健康信号。二者应保持策略一致：
- 若 Kubernetes 中 Readiness 探针设为
/healthz，超时 1s、失败 2 次即下线，则 Nginx 的max_fails=2 fail_timeout=10s更贴近实际节奏，避免“已下线但 Nginx 还在转发”的窗口期； - proxy_next_upstream 应至少包含
error timeout http_503，因为 Readiness 失败常导致 503 返回，Nginx 需据此立即重试其他节点。
推荐架构：Nginx 退为边缘网关，交由专业网关处理服务发现
最解耦、最可持续的方式，是让 Nginx 不直接对接容器 IP，而是作为 TLS 终结、WAF 和缓存层，后端统一接入原生支持服务发现的网关（如 Traefik、Envoy、API7）：
- Traefik 原生监听 Kubernetes Ingress、Service、EndpointSlice，自动构建路由和健康节点列表；
- Envoy 通过 xDS 协议实时接收集群变更，支持主动健康检查（HTTP/PING）和精细化熔断；
- Nginx 在此链路中专注做它最擅长的事：HTTPS 卸载、静态资源加速、访问控制 —— 故障转移逻辑完全由上游网关承担，与编排层天然联动。
不复杂但容易忽略
