HPA 扩容后那 30 秒冷启动窗口，P99 抖动到底该谁兜底

【背景】 做了 8 年嵌入式，近两年把主要精力放在容器化和 K8s 运维。最近一次流量突增复盘里，我盯着一个很别扭的现象：HPA 在 40 秒内把副本从 6 拉到 18，扩容本身没出错、没 OOMKilled、探针也都绿了，但 P99 在扩容后的头 30 秒里从 15ms 飙到 220ms，比不扩容还难堪。查下来根因是典型的"就绪≠能扛"：新 Pod 的 JVM 还在预热、连接池还没建立、本地缓存是空的，readiness 只验证了"进程活着能返回 200"，没验证"这个实例现在能正常服务"。

【常见分歧 / 几种做法】 社区里我看到至少三种流派：

1. 纯靠探针派：把 startupProbe 窗口拉大、readiness 挂个"健康检查端点"，认为绿了就能接流量。简单，但正如我这次踩的坑——健康≠快。
2. 预热派：在 readiness 里加"预热门"，比如要求缓存命中率或首 N 个请求延迟达标后才返回 ready，或用 init 阶段跑一段 warmup 逻辑。更稳，但 readiness 探针的超时/间隔参数很难和真实预热时长对齐，配错反而拖慢扩容。
3. 流量旁路派：扩容出的新实例先接一小部分流量灰度，确认延迟正常再全量放开（类似 service mesh 的 warmup / gradual rollout）。最贴近真实，但引入了 mesh 依赖和更复杂的发布面。

【我的倾向与理由】 我倾向"探针兜底健康 + 预热门兜底性能 + 关键服务上 warmup 流量"分层来做，而不是押注单一手段。理由很务实：探针解决的是"会不会把流量打到死实例上"的底线问题，预热门解决的是"实例能不能立刻正常服务"的均值问题，而 P99 这种长尾本质上是分布问题，只有让新实例"先慢后快"地接流量，才能避免它成为整个服务 P99 的最大毛刺。嵌入式那边我常说一句话：上电那一刻和稳态是两种工况，别用一个稳态指标去判上电。K8s 的冷启动窗口就是这个"上电瞬间"。

【想听大家怎么选】 具体想请教三个点：

1. 你们线上 readiness 探针，是只判"进程活着"，还是真的挂了性能/预热条件？
2. 用 JVM 的服务，你们 warmup 是放 init 容器、应用内自预热，还是靠 mesh 的 traffic warmup？各自的坑是什么？
3. 批处理 / 任务型负载（Spark、批跑）你们还管冷启动窗口吗，还是直接不管 P99？

欢迎贴你们的探针 YAML 片段、warmup 参数、或者踩过的坑，尤其是"配错了反而把扩容拖慢"的案例。我先说：这个话题我判断没有标准答案，只有"在你这个负载形态下哪种代价最小"的取舍。