Kubernetes中startupProbe成功后readinessProbe初始延迟计时异常咨询

核心原因 #

你对initialDelaySeconds的计时逻辑存在误解，这是Kubernetes的默认行为：

当配置了startupProbe时，kubelet会在startupProbe成功前暂停livenessProbe和readinessProbe的执行，但**readinessProbe的initialDelaySeconds是从容器启动时刻开始计算，而非startupProbe成功的时间点**。

对应你的场景：

• 容器启动时间设为0秒，startupProbe在30-35秒完成并成功
• 你配置的readinessProbe.initialDelaySeconds=130，意味着kubelet会在容器启动后第130秒启动readinessProbe（只要此时startupProbe已成功）
• 由于startupProbe在30秒就成功了，早于130秒的时间节点，所以到容器启动130秒时，kubelet立即执行探针，此时服务已就绪，探针直接成功，因此你看到的就绪时间是130秒左右，而非预期的160秒。

佐证信息 #

从你提供的Pod状态输出可以验证这一点：

Readiness:  http-get http://:9080/health delay=100s timeout=5s period=5s #success=1 #failure=3

这里的delay=100s是kubelet计算的容器启动后的剩余等待时间，而非startupProbe成功后的剩余延迟，进一步说明计时起点是容器启动时间。

实现需求的正确配置 #

如果要实现readinessProbe在startupProbe成功后延迟固定时间再就绪的效果，需要移除readinessProbe的initialDelaySeconds，通过failureThreshold和periodSeconds的组合来实现：
例如，要在startupProbe成功后延迟130秒，可配置：

readinessProbe:
  failureThreshold: 26  # 26 * 5秒 = 130秒
  httpGet:
    path: /health
    port: 9080
    scheme: HTTP
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 5

逻辑是：startupProbe成功后，kubelet立即开始执行readinessProbe，前26次探针即使失败也不会标记Pod未就绪（达到failureThreshold才会标记），直到连续成功1次后，Pod才会被标记为就绪，从而实现startupProbe成功后延迟130秒接收流量的目的。

内容的提问来源于stack exchange，提问作者Luan Gashi