Kubernetes启动探针：解决慢启动服务的利器

在 Kubernetes 中，健康检查机制是保障服务稳定运行的核心。而在存活探针与就绪探针之外，还有一个更容易被忽略但非常实用的健康检查------启动探针（Startup Probe） 。

如果你在部署过程中遇到过以下问题：

那么，启动探针，可能正是你需要的救星。

一、什么是启动探针？

Startup Probe 是 Kubernetes 1.16+ 引入的健康检查机制，专用于判断"应用是否完成启动" 。

它的主要作用是：在容器刚启动的时候，使用启动探针进行检测，只有在探测成功之前，不执行存活探针。这样，避免了容器"启动慢"被误判为"挂掉"从而被杀掉的情况。

通俗点说：

传统上，我们往往只配置存活探针和就绪探针。但当服务本身"启动慢"（如加载模型、初始化缓存、大量预热任务等），就容易出问题。

某个 Spring Boot 应用在首次启动时会：

整个启动过程可能耗时 1~2 分钟。但如果配置了如下存活探针：

yaml 复制代码

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

那大约 25 秒后（10 + 5*3），探针就会连续失败 3 次，容器被认为"假死"，强制重启。启动又被中断，最终陷入无限重启循环，根本起不来。

这时，使用启动探针就非常合适。

当配置了 startupProbe 后：

yaml 复制代码

startupProbe:
  httpGet:
    path: /healthz/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

这个配置表示：

一旦探测成功，K8s 认为应用启动完成，后续就交给 livenessProbe 和 readinessProbe 来判断。

此时，应使用 startupProbe，设置合理的探测窗口（如 1~3 分钟），防止被错误重启。

如果服务启动时需要：

也推荐用 startupProbe，直到所有准备工作完成才算"启动成功"。

探针类型	触发时间	检查内容	失败后动作
Startup Probe	容器启动期间	是否启动完成	重启容器
Liveness Probe	启动后持续执行	应用是否仍活着	重启容器
Readiness Probe	启动后持续执行	是否可对外提供服务	暂时摘除，不重启容器

⚠️ 注意：一旦 startupProbe 配置后，livenessProbe 会被"推迟"执行，直到 startup 成功为止。

优先配置 startupProbe，而不是盲目增大 livenessProbe 的初始延迟。
yaml 复制代码
```
# 不推荐
livenessProbe:
  initialDelaySeconds: 180  # 等 3 分钟
```
这可能掩盖真实挂死的场景，不如通过 startupProbe 更明确地定义"启动阶段"。
为慢启动服务设置更宽容的 failureThreshold，避免因探针失败导致频繁重启。
保持探针接口轻量可靠，例如：
- 仅返回 "ok" 或状态码；
- 不依赖复杂业务逻辑；
- 避免调用外部依赖导致探针本身阻塞；
分离 startup、liveness、readiness 接口路径，职责清晰更易调试。

Startup Probe 是 Kubernetes 中专门为"启动阶段"健康检查设计的探针。它弥补了传统探针对慢启动服务不友好的缺陷，为应用提供了"容忍启动慢"的缓冲期。

对于初始化复杂、加载重资源、依赖多个外部系统的服务，配置 startupProbe 是保证其成功部署、减少误判重启的关键一环。

如果你在部署中遇到容器反复重启但日志显示"还没启动完"，那么，给你的应用加上 Startup Probe 吧！