CDN边缘节点容器平滑维护需“摘流→等待→终止”协同：应用层响应SIGTERM停止接新连接、完成请求并切换/readyz为503；LB通过短周期健康检查（如2s间隔）快速剔除；最后docker stop -t 30执行优雅终止。
在容器化 cdn 架构中，单个边缘节点（如 nginx、varnish 或自研缓存服务）通常以 docker 容器形式部署。要对其执行平滑维护（例如升级、配置调整或故障修复），不能直接 docker stop 强制终止——否则正在处理的请求会中断，缓存连接可能重置，客户端出现 502/504 或连接超时。真正可行的方式是让 docker stop 成为“摘流→等待→终止”流程的最后一步，全程需应用、容器、负载均衡与服务发现协同。
应用层必须支持优雅退出与就绪状态切换
CDN 节点容器内的服务（如 Nginx）需能响应 SIGTERM 并完成三件事：
- 立即停止接受新连接（例如 Nginx 中调用
nginx -s stop或通过信号控制 worker 进程不再 accept） - 等待已建立连接上的请求完成（包括长连接、大文件传输、后台刷新任务等），建议设置最大等待时间 ≤ 30 秒
- 同步将就绪探针（如
/readyz）返回状态从 200 切换为 503，通知上游 LB 快速剔除该节点
若使用自研服务，应在代码中监听 SIGTERM，关闭监听端口、清空待写队列、完成 pending 的 cache fill 操作后再退出进程。
负载均衡侧需主动感知并快速摘流
CDN 架构中，上游通常有全局负载均衡器（GSLB）或区域级反向代理（如 LVS + Nginx 集群）。它们必须配置短周期健康检查，并依赖容器暴露的就绪接口：
- Nginx upstream 可配置
max_fails=1 fail_timeout=3s，配合health_check interval=2s fails=1，确保 2～3 秒内将节点标记为down - 若使用 Consul 或 Nacos 做服务发现，应用应在收到 SIGTERM 后主动调用
/v1/agent/service/deregister接口注销自身 - 避免使用基于 DNS 的轮询（如 CoreDNS SRV），除非客户端支持极短 TTL（≤5s）并强制重解析，否则旧 IP 仍可能被缓存数分钟
运维流程：手动或脚本化执行平滑维护
不依赖 Swarm/K8s 时，可按以下顺序对单个 CDN 边缘节点容器执行维护：
- 调用 LB API 或修改 Nginx upstream 配置，将目标容器 IP:port 标记为
down或临时移出 server 列表 - 等待 1～2 个健康检查周期（例如 3 秒 × 2 = 6 秒），确认其已从流量池中完全剔除（可通过日志或
curl http://lb-ip/readyz验证） - 执行
docker stop -t 30 <container-id>：发送 SIGTERM，留足 30 秒让应用完成清理；超时后才发 SIGKILL - 拉取新镜像、启动新容器，并等待其通过健康检查（
/readyz返回 200）后再将流量切回
Docker Compose 场景下的简化实践
若 CDN 边缘节点采用 Compose 管理（如多实例部署在边缘服务器上），可在 docker-compose.yml 中强化控制：
- 定义
healthcheck指向/readyz，间隔 ≤5s，失败阈值设为 1 - 设置
stop_grace_period: 30s，确保 stop 有足够缓冲 - 更新时使用
docker-compose up -d --no-deps --force-recreate <service>，配合start-first策略实现先启新、再停旧
注意：Compose 默认不自动摘流，仍需外部 LB 或脚本配合就绪探针做前置下线动作。
