用启动探针救下慢启动容器

目标

liveness 探针的存在是为了重启挂死的进程，但它分不清“挂死”与“还在启动”。JVM 或跑迁移的应用需要一分钟才能应答，默认 liveness 预算会把这变成无限重启循环。startup 探针修正语义：它没通过之前其他探针不运行；它通过之后，liveness 才对一个本应响应的进程执行严格预算。

步骤要点

1. 从 –previous 日志统计真实启动时长（如约 80 秒），确认远超默认探针预算。
2. 加 startupProbe：period 5s × failureThreshold 30 = 150 秒启动预算，启动期内 liveness/readiness 全部抑制。
3. 启动通过后 liveness 保持严格（10s×3），真挂死的进程 30 秒内仍会被重启。
4. readiness 独立指向 /readyz：活着但暂时不能服务的 Pod 被摘出端点而不是被重启。
5. rollout status 与 RESTARTS 列复核：Pod 一次启动成功、重启数为零。

排错提示

启动预算仍被超时说明应用真卡死（如等待必需依赖），应让应用快速失败或用 initContainer 等依赖就绪，而不是无限放宽探针；长请求期间 liveness 被杀是探针与业务共用线程，把健康检查放到独立处理器；探针路径早期 404 就先返回 200 或改用 tcpSocket 探测直到路由注册。

适用边界

宽松的启动预算会掩盖启动变慢的真实回归，要把启动时长做成指标持续观察；探针本身无法区分慢与卡，健康端点必须由应用诚实实现。

代码示例

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 30   # 150-second boot budget

livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3