Nginx在云原生中仅作边缘网关，upstream指向云LB DNS，由云LB负责自动扩缩容与健康检查；需配置DNS动态解析、合理超时及禁用重复健康检查。
在云原生环境中，Nginx 本身不执行扩缩容动作，但可以作为边缘反向代理，与云厂商负载均衡器（如 AWS ALB/NLB、阿里云 SLB、腾讯云 CLB）协同实现弹性伸缩。关键在于职责分离：云 LB 负责后端实例的自动增减与健康探测，Nginx 聚焦于七层路由、SSL 终止、请求改写等精细化流量治理。
明确 Nginx 的定位：只做边缘网关，不直连后端 Pod/VM
将 Nginx 部署在集群边缘（例如独立 ECS 或 EKS 节点），其 upstream 指向云厂商的负载均衡器 DNS 名称，而非具体后端 IP：
- 配置示例：
upstream backend { server my-alb-123456789.us-west-2.elb.amazonaws.com; } - 这样 Nginx 完全不感知后端实例数量变化——扩容新 Pod 或 VM 后，只要它们注册到云 LB 的目标组（Target Group），流量就会自动被云 LB 分发过去
- 避免在 Nginx 中配置
server 10.0.1.10:8080这类静态地址，否则无法响应伸缩
云 LB 承担自动伸缩与健康调度核心能力
云厂商负载均衡器天然集成自动伸缩组（ASG）或 Kubernetes 自动伸缩机制：
- AWS 场景：ALB 后接 Auto Scaling Group，根据 CPU、请求率或自定义 CloudWatch 指标触发扩容；新 EC2 实例启动后自动加入目标组，ALB 立即开始转发流量
- Kubernetes 场景：Service 类型设为
LoadBalancer，云平台自动创建外部 LB，并将其后端绑定到该 Service 对应的 EndpointSlice；HPA 扩容 Pod 后，EndpointSlice 自动更新，云 LB 几秒内完成节点纳管 - 所有健康检查（HTTP 200 / TCP 端口探测）、连接 draining、权重动态调整均由云 LB 完成，Nginx 无需参与
增强 Nginx 层可观测性与安全控制
虽然不管理后端生命周期，Nginx 仍可提供云 LB 不具备的能力：
- 启用
nginx_status并通过 Prometheus 抓取，监控Active connections、Requests/sec、Upstream response time，用于判断是否需调整云 LB 的监听规则或后端容量水位 - 在 Nginx 层终止 TLS，卸载 SSL 计算压力，统一管理证书与 HSTS、CSP 等安全头
- 基于 Host、URI、Header 做细粒度路由（如
location /api/v2/转发至新版 LB，/legacy转发至旧版），支持灰度发布与版本分流
注意事项：避免常见断点
这种架构下容易忽略但影响弹性的细节：
- DNS 缓存问题：Nginx 默认对 upstream 域名只解析一次。必须配置
resolver+valid=10s，并使用变量引用域名（如set $backend "my-alb..."; proxy_pass http://$backend;），确保每 10 秒刷新 IP 列表 - 超时设置要匹配云 LB：Nginx 的
proxy_read_timeout应大于云 LB 的空闲超时（如 ALB 默认 60s），否则长连接可能被单侧中断 - 禁止在 Nginx 中开启
health_check或max_fails：云 LB 已承担健康探测职责，重复检查反而导致误剔除
