Nginx故障转移怎么实现容器化环境下Pod宕机的Nginx转移-Nginx-PHP中文网

ingress controller 是独立部署的七层流量网关，监听 ingress 等资源变化，动态生成代理配置（如 nginx），实现基于域名/路径的路由、tls 终止与负载均衡，依赖 service 作为唯一后端。

nginx故障转移怎么实现容器化环境下pod宕机的nginx转移

Nginx 本身不直接处理 Pod 宕机后的“转移”，它作为反向代理或负载均衡器，只负责把请求转发给后端服务。真正实现“Pod 宕机后自动转移流量”的，是容器编排平台（如 Kubernetes）+ Nginx（或 Ingress Controller）协同完成的。

关键不在 Nginx 单独怎么做，而在于整个链路如何设计：让 Nginx 始终只连健康 Pod，且当 Pod 消失时，上游自动更新、下游无感切换。

下面分三部分讲清楚怎么落地：

Nginx 自身不主动探活，必须靠外部机制提供“动态健康列表”。常见方式有两种：

通过 Kubernetes Service + Endpoints 自动同步
Service 是虚拟 IP，背后绑定一组 Pod 的 Endpoint。只要 Pod 处于 Running + Ready 状态，就会被自动加入 Endpoints；一旦 Pod 崩溃或就绪探针失败，Kubernetes 会秒级将其从 Endpoints 中剔除。
Nginx（尤其是用作 Ingress Controller 时）监听 Endpoints 变化，实时更新 upstream 列表。无需手动 reload，也无 DNS 缓存问题。
配合主动健康检查（可选增强）
若使用自建 Nginx（非 Ingress），可在 upstream 中开启被动健康检查：
```
upstream 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;
    keepalive 32;
}
```
max_fails 和 fail_timeout 让 Nginx 在连续失败后临时摘除节点——但这只是兜底，不能替代 Kubernetes 的 Ready 探针。

这是容器层的核心能力，依赖两个机制：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

Liveness + Readiness 探针定义“是否真挂了”
- Liveness 探针失败 → Kubernetes 杀掉并重启容器（解决僵死进程）
- Readiness 探针失败 → 立即从 Service 的 Endpoints 中移除该 Pod（这才是“对 Nginx 不可见”的关键）
示例配置：
```
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 10
```
Deployment 控制器自动拉起新实例
只要 Pod 因任何原因退出（包括被 OOM Kill、探针失败、节点宕机），Deployment 就会按 replicas 数量补足。新 Pod 启动后，若 Readiness 探针通过，几秒内就进入 Endpoints，Nginx 自动开始转发流量。