启动探针是什么
startupProbe 是 Kubernetes 为启动耗时长的应用设计的探针：在它成功之前，存活探针（livenessProbe）与就绪探针（readinessProbe）都不会执行；成功一次后启动探针不再运行，控制权交给存活与就绪探针。这让慢启动应用（JVM 预热、模型加载、数据校验）获得充足的启动预算，而不必为了怕被杀掉而给存活探针设巨大的 initialDelay。预算计算口径：failureThreshold × periodSeconds 约等于允许的启动时限，按 P99 启动时间加余量配置。
基本信息
| 预算计算 | failureThreshold × periodSeconds ≈ 启动时限 |
|---|---|
| 成功条件 | 成功一次即移交就绪/存活探针 |
| 适用 | JVM 预热、模型加载、数据校验类启动 |
| 调优 | 预算按 P99 启动时间加余量 |
典型使用场景
- JVM 应用冷启动：Spring 等框架启动数十秒，给足预算避免误杀。
- 模型服务：加载大模型权重耗时数分钟，启动探针兜住这段窗口。
- 数据校验启动：启动时扫描数据完整性，耗时不定。
- 滚动更新加速：就绪判定与启动解耦后，慢启动实例不再拖垮整个发布。
- 崩溃循环排查：反复无法通过启动探针，说明启动本身有问题，看日志而不是放宽阈值掩盖。
启动探针
启动探针
startupProbe:
httpGet: {path: /startup, port: 8080}
failureThreshold: 60
periodSeconds: 5 # 启动预算 300 秒
readinessProbe:
httpGet: {path: /ready, port: 8080}
periodSeconds: 5三探针分工
| 探针 | 回答问题 | 失败后果 |
|---|---|---|
| startupProbe | 还没启动完？ | 继续等待，到达预算才重启 |
| readinessProbe | 能接流量吗？ | 从服务端点摘除 |
| livenessProbe | 还活着吗？ | 重启容器 |
有了启动探针，存活探针的 initialDelay 可以收紧，不必为了慢启动放宽容错。
启动探针与就绪探针要区分职责：启动完成不等于可以接流量，两个探针各自配置。
minReadySeconds 是另一层保险：要求 Pod 就绪后持续 N 秒才计入可用副本，适合「就绪完成仍要预热」的应用，它按秒拉长滚动更新节奏。
探针端点优先 httpGet 或 tcpSocket：exec 探针依赖容器内工具（curl、wget），精简镜像里命令缺失会让启动探针在启动期直接失败。