nginx 在 kubernetes 中实现 least_conn 的关键是动态同步就绪 pod 列表并热重载配置；官方推荐使用 ingress-nginx 控制器自动完成监听 endpoints、生成 least_conn upstream 和 reload；自建 nginx 需配合 endpoint 监听工具与模板渲染。
Nginx 的 least_conn 是 upstream 模块内置的负载均衡算法，它本身**不直接感知 Kubernetes Pod 的实际连接数或健康状态**，也不能自动发现、监听或动态更新 Pod 列表。因此，Nginx 要在 Kubernetes 环境中“实现” least_conn 调度，必须借助外部机制将 Pod 的网络端点（IP:Port）以符合 Nginx 语法的方式动态注入其 upstream 配置，并确保该配置能实时反映 Pod 的增删与就绪状态。
核心前提：Nginx 无法原生对接 Kubernetes API
Nginx 开源版（包括主流的 nginx-ingress-controller 的旧架构）不内置 Kubernetes 客户端。它的 upstream 块是静态配置，写死在 nginx.conf 中。若手动写死 Pod 地址，既不可扩展，也无法应对滚动更新、扩缩容或 Pod 重启——这会导致 502 或流量打到已终止的容器。
所以，“实现 least_conn” 的关键不是改算法，而是解决：如何让 Nginx upstream 的 server 列表始终等于当前 Ready 的 Pod IP 列表，并支持热重载。
主流可行方案：使用 nginx-ingress-controller（官方推荐）
Kubernetes 社区维护的 ingress-nginx 控制器，底层就是 Nginx + 自定义 Go 控制器。它天然完成三件事：
- 监听 Kubernetes API，实时获取 Service 关联的 Endpoints（即就绪 Pod 的 IP:Port）
- 按需生成 Nginx 配置（含 upstream 块），默认使用
least_conn作为后端负载策略（无需额外配置） - 调用
nginx -s reload热更新配置，不中断现有连接
你只需部署 ingress-nginx 并创建 Ingress 资源，它会自动为对应 Service 生成带 least_conn 的 upstream。例如：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
upstream default-myapp-8080 {
least_conn;
server 10.244.1.12:8080 max_fails=1 fail_timeout=10s;
server 10.244.2.7:8080 max_fails=1 fail_timeout=10s;
}
自建 Nginx（非 Ingress）：需配合配置同步工具
如果你坚持用独立部署的 Nginx（比如作为边缘网关或 Service Mesh 边车），可采用以下组合：
-
Endpoint Watcher + 模板引擎：如 k8s-endpoint-watcher 或自研脚本，监听 Endpoints 变更，渲染 Nginx 配置模板（如用 Go template 或 Jinja2），生成含
least_conn的 upstream 块 -
配置热重载：新配置写入临时文件后，执行
nginx -t && nginx -s reload。注意确保pid文件路径正确且 Nginx 主进程有权限读取 -
健康检查增强（可选）：在 upstream 中为每个 server 添加
max_fails=1 fail_timeout=10s，配合 Nginx 自身的被动健康检查，避免将请求发给短暂失联的 Pod
重要注意事项
least_conn 不等于“最空闲”：它只统计 Nginx 与后端建立的活跃连接数（即尚未关闭的 TCP 连接），不感知应用层处理耗时、内存占用或 CPU 使用率。若后端处理时间极不均匀，least_conn 效果可能不如 ip_hash 或基于指标的智能调度（如 K8s 的 Topology Aware Hints + 外部服务网格）。
StatefulSet / Headless Service 场景需谨慎：若直接解析 Headless Service 的 DNS（如 myapp.default.svc.cluster.local），Nginx 的 resolver 默认仅做一次 DNS 查询并缓存，无法感知 Pod 变更。此时必须禁用 DNS 缓存（resolver ... valid=1s;）或彻底放弃 DNS 方式，改用上述 Endpoint 同步方案。
不要在 location 块里硬编码 upstream：务必把 least_conn 定义在 upstream { ... } 块中，再在 proxy_pass 中引用名称。否则 Nginx 会报错或退化为轮询。
