滚动升级中连接重置导致瞬时流量暴露，本质是新容器接入负载均衡但未完成初始化、或旧容器连接未优雅关闭所致；需通过应用层健康检查、足够start_period、优雅关闭机制及动态服务发现协同解决。
滚动升级中连接重置导致的瞬时流量暴露，本质是新容器已接入负载均衡、但尚未完成初始化或旧容器连接未优雅关闭造成的请求失败。这不是配置缺失，而是生命周期管理与网络调度未对齐的结果。
确保新容器真正就绪后再接收流量
仅靠容器进程启动（如 Nginx 启动成功）不等于应用就绪。Nextcloud、Spring Boot 等应用常需加载缓存、连接数据库、执行迁移脚本——这些耗时操作必须在健康检查通过前完成。
- 在 healthcheck 中调用应用层真实端点（如
/health或/status），而非仅检测端口连通性 - 设置足够长的 start_period（建议 30–60 秒），覆盖冷启动最差情况
- 若使用
docker-entrypoint.sh执行升级逻辑（如 Nextcloud 的occ upgrade），需确保该脚本在 healthcheck 开始前执行完毕
强制旧容器等待连接释放再退出
默认情况下，Docker 在发送 SIGTERM 后立即终止容器，但正在处理的 HTTP 长连接、数据库事务可能被粗暴中断，造成客户端收到 RST 包。
- 在应用中实现优雅关闭：监听 SIGTERM，停止接收新请求，等待活跃连接超时或主动关闭（如 Nginx 的
worker_shutdown_timeout） - Docker Compose 中配置 stop_grace_period（如
stop_grace_period: 30s），给容器留出缓冲时间 - Swarm/K8s 中启用 preStop hook（K8s）或 stop_signal + 自定义 shutdown 脚本（Swarm），确保反向代理已将其从上游摘除
让负载均衡器感知连接状态变化
即使容器健康检查通过，若反向代理（如 Traefik、HAProxy、Nginx）未及时更新后端状态，仍会把请求打到正在退出的实例上。
- 使用支持动态服务发现的代理（如 Traefik v2+、Consul Template），避免静态 upstream 配置
- 为新容器设置独立的就绪探针（readiness probe），与存活探针（liveness probe）分离：就绪探针仅在应用完全可服务时返回成功
- 在 Swarm 中启用 endpoint_mode: dnsrr 并配合 DNS TTL 缩短，加速客户端本地缓存失效；K8s 中确保 Service 的
sessionAffinity不干扰滚动过程
验证与压测关键窗口期
瞬时暴露往往发生在“新实例就绪 → 旧实例摘除”之间的几秒内，需针对性验证：
- 用
curl -v或ab持续发请求，同时触发滚动更新，观察是否出现Connection reset by peer - 在更新过程中抓包（
tcpdump -i any port 80），确认 RST 包是否来自即将退出的旧容器 - 检查应用日志中是否有 “shutting down”, “graceful stop started”, “active connections: X” 等关键线索
