问TKE 滚动更新时，如何让 CLB 摘流与长请求结束可靠衔接？

正在梳理 TKE 上 HTTP 服务滚动更新的优雅终止方案，想确认 CLB 到 Pod 的摘流时序。这是上线前的设计问题，不是已复现的故障，目前没有错误日志。 拟定环境：Deployment 两个副本，通过 LoadBalancer 类型 Service 暴露服务，使用 CLB 直连 Pod 模式。普通请求在 1 秒内完成，但少量导出请求持续约 60 秒；客户端使用 HTTP keep-alive，不涉及 WebSocket。计划设置 maxUnavailable=0、maxSurge=1，应用收到 SIGTERM 后停止接收新请求并等待已有请求完成。 已经在方案层面对比两种处理方式，尚未在线上验证：一种是在 preStop 中固定等待一段时间后退出；另一种是先让应用进入 draining 状态，再等待存量请求清空。固定等待无法证明 CLB 已完成后端摘除；而 draining 如果直接拒绝请求，又担心传播窗口内仍有请求到达。仅配置 readinessProbe 似乎也不能说明云侧转发何时停止。 想请教三个具体问题： 1. 在 CLB 直连 Pod 模式下，Pod 进入 Terminating、EndpointSlice 更新与 CLB 后端解绑之间，哪些环节是异步的？有什么可观测事件或指标能确认摘流完成，而不是只看 Pod 的 Ready 状态？ 2. 对已经建立的 HTTP keep-alive 连接，摘除后端后是否还可能有新请求到达该 Pod？应用的 draining 阶段应继续服务还是关闭空闲连接，才能避免滚动更新产生可见失败？ 3. preStop、应用收到 SIGTERM 后的等待时长、terminationGracePeriodSeconds 应怎样配合，既覆盖 60 秒的存量请求，又不把一个固定 sleep 当成摘流完成的保证？如果行为依赖 TKE 网络模式、控制器版本或 CLB 配置，希望指出具体需要核对的条件。