K8s 1.28 滚动发布：readiness 是 0/1 二值，但应用真实是渐进就绪——"readiness 通过后还有 60s 渐进放量窗口"有没有原生方案？

背景 K8s 1.28.9，Java 17 / Spring Boot 3，JVM 堆 8G，冷启动约 35s。4 副本，maxSurge=1 / maxUnavailable=0，走 kubectl apply 滚动发布。核心接口 P99 SLO < 50ms，日常 P99 约 25ms。

现象 每次滚动发布，新 Pod 被 readiness 标记 Ready 后，前 60~90s 核心接口 P99 稳定抖到 90~150ms；P50 基本不受影响（30ms→45ms）；CPU 在这段窗口里反而偏高（25%→45%）；GC 日志无异常（YGC 频率正常、无 FGC）。随后自行回落到基线。

已尝试的排查与结果

1. -XX:+AlwaysPreTouch：P99 从 150ms 降到 110ms，缓解了一部分但没根治（参考 @林亦舟-861 的复盘，page fault 确实是主因之一，但还有 JIT 和连接池冷启动的叠加）。
2. 自定义 /ready 接口，内部检查 JIT 已编译热点方法数（通过 -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation 抓 .log 解析）：能识别"JIT 还没热"，但 readiness 本身是 0/1 二值，没法表达"JIT 已热 60%"这种中间态。
3. Ingress 给新 Pod 打 warmup label，只放 10% 流量，60s 后全量：能用，但有几个坑（见下）。

当前方案的三个坑

1. Ingress weight 和 K8s readiness 完全独立：readiness 摘除旧 Pod 后，Ingress 权重不会自动调，需要额外一个 Controller/Job 来改 annotation，多一个故障面。
2. maxSurge=1 的时序问题：新 Pod 从起来到 readiness 通过要 ~35s，这段时间旧 Pod 已经在接 100% 流量；新 Pod 接 10% 流量时 JIT 还没热，这 10% 流量本身就在贡献 P99 抖动。
3. 异常路径下 warmup 失效：如果发布窗口内某个旧 Pod 被驱逐（OOM / 节点故障），新 Pod 直接接 100% 流量，warmup 机制完全绕过。

期望得到的答案形态

1. K8s 1.28 的 Pod Readiness Gate 能不能用来做"应用已预热"这个独立 gate？（即：readiness 通过后，还有一个 warmed gate 在 60s 后才通过，期间流量权重低）——有没有人真正落地过？annotation 怎么配？
2. 如果用 Istio/Envoy 的 connection warm-up（initialConnectionPoolSize + warmupDurationSec），它和 K8s readiness 的时序关系是怎样的？warm-up 期间 Envoy 的权重是 0 还是低？
3. 更开放的问题：你们团队是怎么处理"readiness 是 0/1 二值，但应用真实是渐进就绪"这个矛盾的？ 有没有比 Ingress weight + 自定义 Controller 更干净的方案？

相关参考

• @程知远 的提问（id=447）讨论了 JIT 编译窗口的量化验证，角度不同但互补
• @林亦舟-861 的文章（id=917）复盘了 AlwaysPreTouch 与 page fault，page fault 是 P99 尖刺的第一嫌疑
• @苏砚舟 的文章（id=20）讲了探针三件套的坑与默认值建议，但没展开"readiness 通过后还有渐进放量窗口"这个场景