优雅下线需分三步：先用readinessprobe精准控制服务可见性，再通过prestop+terminationgraceperiodseconds保障收尾时间，最后协同ingress/slb实现灰度引流，并兼顾会话与状态迁移。
业务下线时实现优雅流量引流，核心不是“一刀切”停服务，而是让旧服务逐步退场、新路径平滑承接，确保用户无感知、请求不丢失、会话不中断。关键不在技术堆砌，而在对生命周期、探测机制和路由协同的精准控制。
用 readinessProbe 控制服务可见性
Service 是否把 Pod 加入后端列表，完全取决于 readinessProbe 的结果。下线前必须确保该探测能真实反映应用是否还能处理新请求。
- 探测路径要指向业务就绪状态，比如 /healthz?ready=true，而非单纯检查进程存活
- initialDelaySeconds 要大于应用冷启动时间，避免 Pod 启动一半就被加入流量池
- failureThreshold 建议设为 2～3，避免偶发抖动误判导致反复摘除
- 下线操作前，可先手动触发一次探测失败（如临时返回 503），验证 Service 是否及时剔除该 Pod
靠 preStop + terminationGracePeriodSeconds 留出处理窗口
Pod 收到终止信号后，默认立刻杀进程，但此时可能还有长连接、未完成事务或正在写日志。必须给它留出“收尾时间”。
- terminationGracePeriodSeconds 至少设为 30 秒，给应用缓冲空间
- preStop 推荐用 exec 执行 sleep 或调用关闭接口，例如：sleep 15 && curl -X POST http://localhost:8080/shutdown
- 应用内部需监听 SIGTERM，在 preStop 执行期间主动拒绝新请求、完成积压任务、关闭连接池
配合 Ingress/SLB 实现分阶段灰度下线
单靠 Kubernetes 原生机制不够，尤其在南北向流量场景中，Ingress 或云厂商 SLB 的更新延迟常是断流主因。
- 下线前先将 Ingress 的对应 path 或 host 指向一个维护页服务，或配置 302 跳转到新地址
- 若使用 Nginx Ingress，可通过 annotation 动态设置 nginx.ingress.kubernetes.io/configuration-snippet 注入限流或降级逻辑
- 云 SLB（如阿里云 ALB、腾讯云 CLB）支持权重灰度，可把旧实例权重逐步调至 0，比直接删 Endpoints 更可控
补充：会话与状态迁移不可忽略
有状态服务下线时，光保连接不丢不够，还要保数据不丢、会话不断。
- 若依赖 Redis 存 session，确保新旧服务共用同一套 session store，且 key 格式兼容
- 长连接网关（如 WebSocket）需支持连接迁移或优雅广播下线通知，引导客户端重连新节点
- 数据库读写分离场景，下线前确认只读副本已同步完毕，避免主库切走后从库延迟导致脏读
