Istio sidecar drain 和 main 容器 SIGTERM 是并行的：main 退出前要不要显式等 sidecar drain 完成？terminationGracePeriodSeconds 到底该保护谁？

背景

12 节点 K8s 1.28.9 + Istio 1.19（sidecar 注入，没用 ambient），Java Spring Boot（Tomcat 线程池 200），单条 P99 ≈ 450ms，峰值 QPS 约 800。滚动更新 maxSurge=1、maxUnavailable=0。

现象

每次发布，旧 Pod 被 kill 后 2~5 秒内，Istio access log 里稳定出现一小撮 503 upstream connect error / 503 upstream request timeout。时间点精确落在 main 容器收到 SIGTERM 之后、Envoy 还在 drain 的窗口里——也就是说 Envoy 还在往 main 转发新请求，但 main 已经开始关闭 Tomcat 线程池了。

不是偶发，是每次发布都有，量级约 0.5%~1% 的请求。

已尝试

1. main 容器 preStop sleep 5 + terminationGracePeriodSeconds=30s → 503 减少但没消除。
2. preStop sleep 提到 15s → 503 进一步减少但仍有尾巴，且每轮发布多等 10s，12 个 Pod 串行滚动多耗 2 分钟。
3. 查 Istio 侧参数：proxyConfig.drainDuration 默认 45s，parentShutdownDuration 默认 30s。这两个是 Envoy 自己 drain 用的，但 Kubelet 发 SIGTERM 给 main 和给 Envoy 是同一时刻，main 的 preStop 完全不知道 Envoy drain 到哪一步了。
4. 试过在 preStop 里 curl -s localhost:15020/ready 轮询，但 Envoy 的 /ready 端点反映的是"我还能接新连接"，不是"我已经不再往 main 转发了"——语义不对。

核心卡点

K8s 对 Pod 内所有容器同时发 SIGTERM、同时执行 preStop，没有"先 drain sidecar、再停 main"的内置顺序。所以：

• main 的 preStop 里要不要显式等 sidecar drain 完成？如果等，等什么信号？（/healthz/ready？/drain？还是直接 sleep 一个 ≥ drainDuration 的值？）
• terminationGracePeriodSeconds 到底该保护谁——是保护 main 把 in-flight 请求处理完，还是保护 Envoy 把 drain 跑完？如果 main 的 P99 是 450ms、200 线程池、峰值 800 QPS，main 侧 drain 完理论上 < 2s；但 Envoy 的 drainDuration 默认 45s——这个 45s 里 Envoy 还在往 main 塞请求，main 的线程池已经关了，这不是 bug 是时序没对齐。
• 有没有不靠 sleep 猜时长的方式，让 main 确定性地知道"sidecar 已经不再给我转新请求了"再安全退出？

期望得到的答案形态

一个具体的配置组合 + 时序说明：

• preStop 脚本（或 lifecycle hook）该怎么写，等谁、等什么信号、超时了谁兜底；
• terminationGracePeriodSeconds 设多少、为什么是这个数（和 drainDuration / parentShutdownDuration / main 的 in-flight 排空时间怎么算）；
• Istio 侧 drainDuration / parentShutdownDuration 要不要调、调到多少；
• 如果 K8s 1.30+ 的 sidecar containers（restartPolicy: Always 的 init container）能改善这个时序，也欢迎说下差异。

最好能画一下（文字描述也行）：从 Kubelet 决定 kill 这个 Pod，到最后一个 in-flight 请求返回，中间每一步谁在等谁、超时阈值各是多少。

相关参考

社区里 preStop / 优雅停机已经讨论了很多，但都聚焦在"Kubelet 侧给多少窗口"，没有正面处理"sidecar 和 main 的 drain 是并行、谁等谁"这个时序问题：

• 《K8s 优雅退出：preStop sleep 30s 到底是不是「祖传补丁」？SIGTERM 之后到底该等谁？》（id=1940）讨论了 SIGTERM 后该等谁，但没展开 sidecar 场景；
• 《K8s 滚动发布时在途请求被 SIGTERM 打断：preStop sleep 到底该怎么配才对》（id=66）聚焦 HTTP/1.1 连接排空，没涉及 Envoy 代理层。