结论先行：Spot 实例的「5 分钟回收预警」不是给你 JVM 排空用的，它只保证「收到信号后 5 分钟内你会被 SIGKILL」；而 JVM 从收到 SIGTERM 到进程真正退出，光 shutdown hook 里一个
awaitTermination(30, SECONDS)就能吃掉半分钟。 窗口是固定的，你的停机链路是多长的？这条账没算过，Spot 上跑的 Java 服务迟早要在回收窗口里丢请求。
一、现象：不是发布期 502，而是「整台机器凭空消失」
背景环境：
- 集群：K8s 1.28.9，containerd 1.7.13，40 台 Spot 节点（16C64G），内核 5.10.134；
- 服务：Java 17 / Spring Boot 3.2，
-Xmx2g，每 Pod 平均活跃请求 600–900 条，P99 单请求耗时 450ms； - 业务：一个异步任务网关，上游 SDK 重试策略是「失败后 3s 重试一次，共 2 次」。
事故窗口（一次 Spot 大规模回收，约 25 分钟）：
- 共 17 台 Spot 节点被回收，上面跑着 23 个业务 Pod；
- 12 个 Pod 的容器日志最后一行是
SIGKILL前没有任何「graceful shutdown finished」标记——即在 5 分钟窗口内没排干就被强杀； - 上游重试救回了一部分，但监控里该窗口 5xx 从基线 0.02% 飙到 4.2%，持续 23 分钟；
- 反直觉的对照：同一服务在 20 台按量节点上滚动发布，5xx 基线只有 0.1%——同一个 JVM，换个「死亡方式」就翻 40 倍。
二、根因：三条时钟互相打架
把 Spot 回收的时序摊开看，问题出在「谁在计时、谁在等谁」：
1. 云厂商的 5 分钟是 SIGKILL 倒计时，不是 SIGTERM 后的预算。
Spot 回收流程是：元数据接口（http://100.100.100.200/latest/meta-data/spot/termination）可读到 termination=not → termination=yes，之后 ≤5 分钟内实例被硬停。K8s 侧的事件是 node.kubernetes.io/spot-recalled（或云厂商 webhook 打上的污点），controller 触发 drain。drain 开始的那一刻，5 分钟倒计时已经在跑了——你没有任何「额外缓冲」。
2. preStop 的 sleep 是从 terminationGracePeriodSeconds 里扣的，不是外加的。
我们当时配的是 terminationGracePeriodSeconds: 300，preStop sleep 5。很多人直觉上觉得「300 秒够多了」，但 kubelet 的计时从执行 preStop 就开始，真正留给容器进程处理 SIGTERM 的只有 295s——这条我上一篇复盘写过了（滚动更新 502 尖刺那篇），这次 Spot 场景又踩了一次。
3. JVM 的 shutdown hook 是被动的，而且「排干」的实现决定了它快不快。
我们的 hook 大致是：先摘流（从注册中心下线），再 executor.shutdown()，然后 awaitTermination(30, SECONDS)，最后关连接池。问题在两个地方：
awaitTermination的 30s 是上限不是实际值，实测在 700+ 活跃请求时，平均要 38–42s 才把 in-flight 跑完——超过 30s 后 hook 直接放弃等待，连接池带着未完成的请求一起被 close；- GC 参与：停机过程中 Spring 的
@PreDestroy会触发大量对象存活（缓存 flush、连接池 close），一次 Full GC 实测 1.8s，这在「窗口内每分钟都可能被 SIGKILL」的场景里是实打实的预算损耗。
三条时钟叠加：5 分钟倒计时 − drain 调度延迟（实测 3–8s）− preStop 5s − kubelet 与 runtime 的 stop 握手 − JVM hook 实际 40s+ ≈ 你的有效排空预算。平时按量节点没人抢时间，所以 40s 的 hook 无感；Spot 场景里，它和 5 分钟倒计时正面相撞。
三、具体做法：把「停机预算」显式算出来再配
1. 先测你 JVM 的真实停机时长（不要猜）
在预发节点上模拟：
# 制造 800 条 300ms 的慢请求后，直接给进程发 SIGTERM，计时
curl -s http://localhost:8080/actuator/metrics/jvm.threads.live # 确认 in-flight
time (kill -TERM $(pgrep -f app.jar); while kill -0 $(pgrep -f app.jar) 2>/dev/null; do sleep 0.1; done)
我们实测 P50=38.6s、P99=46.2s。这个数字就是你「停机链路下限」。
2. 显式化 shutdown hook 的预算分配
// 核心：deadline 驱动，而不是各段各自 awaitTermination
long deadline = System.nanoTime() + TimeUnit.SECONDS.toNanos(240); // 总预算 240s，留 60s 给系统
// 1) 摘流（从注册中心下线 + 等 kube-proxy 规则下发）
registry.deregister();
awaitBudget(15_000, deadline); // 摘流预算 15s
// 2) 停接新任务
dispatcher.shutdown();
awaitBudget(120_000, deadline); // in-flight 排干预算 120s（覆盖实测 P99 46s 的 2.5 倍余量）
// 3) 关池前检查还有没有 in-flight，有就主动快速失败而不是挂着等
if (!drained) {
log.warn("drain timeout, {} in-flight will fail-fast", inFlight.get());
failFastAll(); // 让上游 SDK 立刻收到 503，触发它自己的重试
}
pool.close();
关键点：failFastAll 不是可选项。Spot 场景下，与其让请求挂在连接池里等 SIGKILL，不如主动 503 让上游重试到别的节点——上游有重试（我们确认过 SDK 是 2 次、间隔 3s），快速失败是「把损失转移到重试」，比「请求被强杀、上游只能算失败」划算得多。
3. K8s 侧配置：grace 要覆盖「你的停机链路 + drain 延迟」
# 按实测 46s + 余量，而不是拍 30s
terminationGracePeriodSeconds: 120
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 3"] # 只留 3s 等 iptables 规则下发，别贪
注意：grace 120s < 5 分钟 Spot 窗口，这个不等式必须成立。grace 配 300 看起来「更稳」，但 kubelet 在 grace 内没杀掉 Pod 就会走 SIGKILL 强杀路径，而 Spot 的 5 分钟到了是宿主机直接没了——grace 越长，你越可能撞上「hook 还在跑、机器先没了」的窗口。
4. 可观测：把「Spot 回收前 N 秒」做成告警
# 节点侧：读到 Spot 回收信号就告警，给值班留 60s 手动摘流量
- alert: SpotTerminationImminent
expr: node_spot_termination_signal == 1
for: 0s
labels: { severity: page }
配合容器日志里的 shutdown finished / fail-fast triggered 两种终态标记，事后复盘时一眼区分「排干成功」还是「被强杀」。
四、踩过的坑（反直觉之处）
- 「grace period 设大就安全」是错的：在 Spot 场景，grace 上限被 5 分钟窗口硬约束，配大了反而拉长「机器没了但 kubelet 还在等」的悬挂期，其他节点的扩容调度会被拖慢。
awaitTermination(30s)的 30s 不是承诺：实测 P99 46s，超出的部分 hook 直接放弃，请求状态是「未知」而不是「失败」——上游 SDK 的超时判断会因此延迟 15s+，重试窗口被吃掉。- Full GC 会被算进停机预算：一次 1.8s 的 GC 在按量节点上无感，在「每分钟都可能被回收」的 Spot 上，它和 in-flight 排干抢同一份时钟。停机路径上能少 flush 的缓存就别 flush（审计日志可以落盘由另一个进程异步接管）。
- 上游重试是你的安全网，但前提是它存在：我们这次能兜住 4.2% 里的大半，纯粹因为 SDK 有 2 次重试。没有重试的上游，你的优雅停机做得再好也只能救 50% 的请求——这种依赖关系应该写进服务的 SLO 文档里，而不是藏在 SDK 源码里。
五、结论与可复用清单
Spot 实例上跑 Java 服务，优雅停机的本质是一道预算题：
- [ ] 用
time (kill -TERM; wait)实测你 JVM 的停机 P50/P99，别用 30s 这种「看起来合理」的值； - [ ] shutdown hook 改成 deadline 驱动，每段预算显式声明，总预算 < min(你的链路 + 30s, 300s Spot 窗口 − 60s)；
- [ ] drain 超时后 fail-fast，把损失转移给上游重试，而不是让请求悬挂到 SIGKILL；
- [ ]
terminationGracePeriodSeconds覆盖实测停机时长 + 30s 余量，但不要超过 300s； - [ ] preStop sleep 只留 3–5s 等 iptables，别用 sleep 10 赌规则下发；
- [ ] 节点侧部署 Spot 回收信号采集 + 告警，给值班留手动摘流窗口；
- [ ] 确认上游 SDK 的重试策略，把它写进 SLO 文档——优雅停机的另一半在上游手里。
一句话总结：Spot 的 5 分钟是硬约束，你的 JVM 停机链路是软成本，两者相减才是你的真实安全余量。 平时按量节点上这笔账不用算，Spot 上必须算。