启动探针解决什么问题
startupProbe 是 Kubernetes 第三种探针，专门给启动慢的应用用。它未通过之前，liveness 与 readiness 都不执行，kubelet 只在启动探针的失败预算内反复探测；一旦通过就永久退出，之后交给常规探针。这样既不用把 initialDelaySeconds 调得很大，也能让启动期长达几分钟的应用不被 liveness 误杀。
基本信息
| 适用平台 | Kubernetes 1.16 起支持，1.18 转为正式可用，由 kubelet 执行 |
|---|---|
| 探测方式 | exec、httpGet、tcpSocket、grpc（1.24+） |
| 关键字段 | failureThreshold、periodSeconds、timeoutSeconds、initialDelaySeconds |
| 容忍上限 | 约等于 failureThreshold × periodSeconds |
| 生效顺序 | 启动阶段只跑 startupProbe，通过后才开始 liveness 计时 |
典型使用场景
- Java/Spring 容器冷启动一到三分钟，用启动探针覆盖整个启动窗口，不再猜 initialDelaySeconds
- 数据库、消息中间件容器首次启动要回放日志或重建索引，启动耗时随数据量变化
- 模型推理、数据服务首次加载大文件到内存，耗时不可预测
- 存量应用迁移上云时只想兜住启动阶段，暂时不改 readiness 参数
- 做成两段式判定：启动期宽松、运行期严格，避免两种诉求互相妥协
启动探针配置片段
启动探针配置片段
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30 # 最多失败 30 次
periodSeconds: 10 # 每 10 秒探测一次
timeoutSeconds: 2 # 单次探测超时时间
livenessProbe: # 启动探针通过后才开始计时
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
failureThreshold: 3参数逐项读法
| 字段 | 含义 | 经验取值 |
|---|---|---|
| failureThreshold | 启动期允许的失败次数 | 按最慢一次启动耗时预留余量，别按平均值算 |
| periodSeconds | 探测间隔 | 5-10 秒；过密会放大 kubelet 与业务负担 |
| timeoutSeconds | 单次探测超时 | 要大于健康接口的最慢响应，默认 1 秒对慢接口偏紧 |
| initialDelaySeconds | 首次探测延迟 | 已有启动探针时通常留 0，避免两种机制叠加 |
容忍上限大致是 failureThreshold × periodSeconds。这个预算不只用于集群首次启动，滚动升级时新 Pod 的首次启动同样计时，所以取值要按「升级后首次启动」的最坏情况算。
启动探针最好只反映进程自身状态。如果它探测的接口依赖外部数据库或配置中心，外部故障会被判定成启动失败，容器反复重启反而加重故障。