<p>In kubernetes official docs, I was reading this page (about the <code>container probes</code> and why we should use <code>startup-probe</code>)<br />
<a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe" rel="nofollow noreferrer">when-should-you-use-a-startup probe</a>, they stated like:</p>
<blockquote>
<p>If your container usually starts in more than <code>initialDelaySeconds + failureThreshold × periodSeconds</code>, you should specify a startup probe that checks the same endpoint as the liveness probe. The default for <code>periodSeconds</code> is 10s. You should then set its <code>failureThreshold</code> high enough to allow the container to start, without changing the default values of the liveness probe. This helps to protect against deadlocks.</p>
</blockquote>
<p>I understood the whole things that why we need to use <code>startup probe</code> (what i understood that why we need to use <code>startup probe</code> is that: Startup probes are useful for Pods that have containers that take a long time to come into service. As we know, all other probes are disabled if a startup probe is provided, until it succeeds. So if the container takes longer time to start up then we will use <code>startup probe</code> so that until the container start the other two probes remain disabled).</p>
<p>But here I did not get the scenario of <code>deadlock</code>, where and why the <code>deadlock</code> is happening? can anyone explain the scenario of the <code>deadlock</code> that they are talking about? which <code>deadlock</code> are we preventing by using <code>startup probe</code>?</p>

Sahadat Hossain
<p>The <code>startup probe</code> is designed to be performed only once after container start.</p>
<p><code>Readiness probe</code> and <code>liveness Probe</code> are performed not only the startup.</p>
<blockquote>
<p>If a startup probe exceeds the configured failureThreshold without succeeding, the container is killed and restarted, subject to the pod's restartPolicy, a behavior analogous to the liveness probe.</p>
</blockquote>
<p>Readiness probe may be used by load balancer to determine when it can send traffic.</p>
<h1>Startup probe use-cases</h1>
<p>The example reason to use <code>startup probe</code> is:</p>
<p>Your application is starting for a long time. You can increase <code>delays</code> for <code>readiness probe</code> and <code>liveness probe</code> but you do not know when your container is ready because those probes are not performed for <code>delay</code> time.</p>
<p>So <code>startup probe</code> is used commonly with <code>readines</code> and <code>liveness</code> probes. It is performed until your container is ready(till your <code>startup probe</code> returns the <code>Success</code> status), so you do not need delays anymore.</p>
<h3>External dependencies</h3>
<p>Let's say your application is starting for 1-3 minutes(it may depend on external API, resources, slow network etc.). You can put <code>delays</code> to 190 seconds, but you can waste at least 2 minutes if your container is ready after 60 seconds. To solve that issue <code>startup probe</code> was designed.</p>
<h3>First initialization</h3>
<p>Sometimes, you have to deal with legacy applications that might require an additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The trick is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worse case startup time.</p>
<h1>Your question</h1>
<p>The deadlock is situation, when your container is not ready but <code>liveness probe</code> is performing and it exceed <code>failure treshold</code>, because of too short delay time. In this situation your container keeps restarting. To prevent that you should use <code>startup probe</code> and put your threshold high enough.</p>
