生产环境Docker平滑升级核心是“先摘流、再停、后切流”，需应用层（如http.Server.Shutdown）、编排层（如Swarm preStop+readinessProbe+terminationGracePeriodSeconds）、负载均衡器（如Nginx健康检查+动态上游）三方协同，缺一不可。
生产环境做 Docker 平滑升级，核心不是“先停再启”，而是“先摘流、再停、后切流”。单纯靠 docker stop 或滚动更新命令无法保证请求不中断，必须让负载均衡器提前感知并停止转发新请求——这需要应用层、容器编排层和负载均衡器三方协同。
Swarm 环境：用 readinessProbe + preStop + terminationGracePeriodSeconds 闭环控制
Swarm 自带 Ingress 路由网格，但默认不会等待应用真正处理完请求就发 SIGTERM。关键要让它“等一等”：
- 配置
readinessProbe（如 HTTP GET /health/ready），让 Swarm 认定服务“不可读”后，自动从 IPVS 后端列表中剔除该实例 - 在 service 定义中添加
preStop生命周期钩子，例如执行curl -X POST http://localhost:8080/health/ready?down=true，主动触发应用置为不可就绪 - 设置
terminationGracePeriodSeconds（建议 ≥ 30s），确保有足够时间等最后一批请求结束、server.close() 完成后再终止容器
Nginx / HAProxy 反向代理：主动健康检查 + 动态上游管理
当用 Nginx 或 HAProxy 做前置 LB 时，不能只靠静态 upstream 列表。必须让它能“动态发现”和“及时剔除”：
- 开启主动健康检查：
health_check interval=5s fails=2 passes=2，一旦探测失败，立刻从 upstream 摘除节点 - 配合 DNS 轮询（如
resolver 127.0.0.11 valid=5s;）或基于 Docker API 的动态配置工具（如 nginx-upsync-module），实现容器 IP 变更后 upstream 自动刷新 - 升级前可手动触发一次
curl -X POST http://nginx-admin/api/upstream/down?server=172.20.0.10:8080（需集成 admin API），提前隔离目标实例
Kubernetes 场景：Endpoint 控制器与 Pod 状态联动
K8s 的 Service + Endpoint 机制天然支持平滑摘流，但前提是 Pod 必须正确响应：
- Pod 的 readinessGate 或 readinessProbe 必须真实反映业务就绪状态；升级时，先让 probe 返回失败，Endpoint 控制器约 1–3 秒内将对应 IP 从 Endpoints 对象中移除
- 确保应用监听
SIGTERM后，关闭 HTTP server 并等待server.close()（Node.js）或http.Server.Shutdown()（Go）完成，再退出进程 - 避免使用
livenessProbe替代 readinessProbe——存活探针失败会直接重启 Pod，反而造成流量中断
自建 Consul / Etcd 注册中心：下线前主动反注册
如果用 Consul + Registrator 管理服务注册，容器退出时默认不会自动注销，容易导致客户端缓存旧地址：
- 在容器的
entrypoint或preStop中调用curl -X PUT http://consul:8500/v1/agent/service/deregister/web-001 - 反注册后加
sleep 2，给客户端（如 Consul Template、Envoy xDS）留出刷新缓存的时间窗口 - 配合健康检查接口（如
/health返回 503），让上游网关同步判断是否路由该实例
