startup → liveness/readiness顺序

kubelet 对同一个容器的三种探针（startup → liveness/readiness）的实际执行顺序如下：

1. startupProbe（如果配置了）
   在容器启动后先只做它，连续成功次数达到 successThreshold 之前，kubelet 不会执行任何 liveness/readiness 探针。
   一旦 startupProbe 成功，kubelet 立即把该探针“毕业”，以后不再运行。
2. livenessProbe 与 readinessProbe 同时启动
   startupProbe 成功（或根本没配）后，kubelet 会同时开始两条独立的定时器：
   • 按 livenessProbe.periodSeconds 的节奏做 liveness 检查；
   • 按 readinessProbe.periodSeconds 的节奏做 readiness 检查。
     它们之间没有任何先后依赖，谁先谁后只取决于各自的 initialDelaySeconds 和周期。
3. 结果各自生效
   • liveness 失败 → kubelet 重启容器；
   • readiness 失败 → 把 Pod 从对应 Service 的 Endpoints 里摘掉，不影响容器运行。

所以：

• 没有 startupProbe 时，liveness 和 readiness 是并行启动、并行探测；
• 有 startupProbe 时，先等 startupProbe 成功，然后 liveness/readiness 一起开始探测，谁也不等谁。

readiness 初始等待时间 ≤ liveness 是更合理的默认值；把 readiness 设得比 liveness 还长，只会拖慢流量接入，几乎得不到额外收益。

1. 真正需要“超长预热”的场景，用 startupProbe 而不是把 readiness 的 initialDelaySeconds 拉得很长。

readinessProbe:
  initialDelaySeconds: 0    # 或 5~10 s
  periodSeconds: 5
livenessProbe:
  initialDelaySeconds: 30   # 比 readiness 晚一些
  periodSeconds: 10