<p>I have a pod with probes following probes defined:</p>
<pre><code>Liveness:   exec [/liveness-probe-script] delay=0s timeout=10s period=30s success=1 #failure=3
Readiness:  exec [/readiness-probe-script] delay=0s timeout=10s period=30s success=1 #failure=3
Startup:    exec [/startup-probe-script] delay=0s timeout=140s period=10s success=1 #failure=1
</code></pre>
<p>I added some logging to the scripts:</p>
<pre><code>startup probe starting at: 14:57:34
finished at: 14:57:37

readiness probe starting at: 14:57:47
finished at: 14:57:47

liveness probe starting at: 14:57:48
finished at: 14:57:48
</code></pre>
<p>as you can see the readiness and liveness probes start 10s after the startup probe is already finished.</p>
<p>Can something be done about this?
Is this normal behaviour?</p>
<p>EDIT:</p>
<p>For clarification, I understand that the liveness/readiness probes start AFTER the startup probe + initialDelaySeconds if configured. My question is, why is there a 10s gap, sometimes more sometimes less, between the startup probe finishing at 14:57:37 and the readiness probe starting at 14:57:47 without any delays configured? Why does the readiness probe not start at 14:57:38 immediately after the startup probe?</p>

Gabriel Stein
<p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes" rel="nofollow noreferrer">By definition</a>, readiness and liveness probes take place after the container has started. This means after the startup probe is finished.</p>
<p>At the beginning of the doc:</p>
<blockquote>
<p>The kubelet uses startup probes to know when a container application
has started. If such a probe is configured, <strong>it disables liveness and
readiness checks until it succeeds</strong>, making sure those probes don't
interfere with the application startup.</p>
</blockquote>
<p>Then at the <code>initialDelaySeconds</code> parameter definition:</p>
<blockquote>
<p><code>initialDelaySeconds</code>: Number of seconds <strong>after the container has</strong>
<strong>started</strong> before liveness or readiness probes are initiated. Defaults to
0 seconds. Minimum value is 0.</p>
</blockquote>
<p>In case you want to avoid this behaviour, you may be able to do so by <strong>not using a <code>startup probe</code></strong>, if your use case doesn't need it.</p>
