<p>Why do I need 3 different kind of probes in kubernetes:</p>
<ul>
<li>startupProbe</li>
<li>readinessProbe</li>
<li>livenessProbe</li>
</ul>
<p>There are some questions (<a href="https://stackoverflow.com/questions/55423405/k8s-livenessprobe-vs-readinessprobe">k8s - livenessProbe vs readinessProbe</a>, <a href="https://stackoverflow.com/questions/59850959/setting-up-a-readiness-liveness-or-startup-probe">Setting up a readiness, liveness or startup probe</a>) and articles about this topic. But this is not so clear:</p>
<ul>
<li>Why do I need 3 different kind of probes?</li>
<li>What are the use cases?</li>
<li>What are the best practises?</li>
</ul>

Matthias M
<p>These 3 kind of probes have 3 different use cases. That's why we need 3 kind of probes.</p>
<p><em><strong>Liveness Probe</strong></em></p>
<p>If the <em>Liveness Probe</em> fails, the pod will be restarted (read more about failureThreshold).</p>
<p>Use case: Restart pod, if the pod is dead.</p>
<p>Best practices: Only include basic checks in the liveness probe. Never include checks on connections to other services (e.g. database). The check shouldn't take too long to complete.
Always specify a <strong>light</strong> <em>Liveness Probe</em> to make sure that the pod will be restarted, if the pod is <strong>really</strong> dead.</p>
<p><em><strong>Startup Probe</strong></em></p>
<p><em>Startup Probes</em> check, when the pod is available after startup.</p>
<p>Use case: Send traffic to the pod, as soon as the pod is available after startup. <em>Startup probes</em> might take longer to complete, because they are only called on initializing. They might call a warmup task (but also consider init containers for initialization). After the Startup probe succeeds, the liveliness probe is called.</p>
<p>Best practices: Specify a <em>Startup Probe</em>, if the pod takes a long time to start. The Startup and Liveness Probe can use the same endpoint, but the <em>Startup Probe</em> can have a less strict failure threshhold which prevents a failure on startup (s. <a href="https://livebook.manning.com/book/kubernetes-in-action-second-edition/chapter-6/v-6/224" rel="noreferrer">Kubernetes in Action</a>).</p>
<p><em><strong>Readiness Probe</strong></em></p>
<p>In contrast to <em>Startup Probes</em> <em>Readiness Probes</em> check, if the pod is available during the complete lifecycle.
In contrast to <em>Liveness Probes</em> only the traffic to the pod is stopped, if the <em>Readiness probe</em> fails, but there will be no restart.</p>
<p>Use case: Stop sending traffic to the pod, if the pod can not temporarily serve because a connection to another service (e.g. database) fails and the pod will recover later.</p>
<p>Best practices: Include all necessary checks including connections to vital services. Nevertheless the check shouldn't take too long to complete.
Always specify a <em>Readiness Probe</em> to make sure that the pod only gets traffic, if the pod can properly handle incoming requests.</p>
<p><em><strong>Documentation</strong></em></p>
<ul>
<li><a href="https://medium.com/dev-genius/understanding-kubernetes-probes-5daaff67599a" rel="noreferrer">This article</a> explains very well the differences between the 3 kind of probes.</li>
<li>The <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="noreferrer">Official kubernetes documentation</a> gives a good overview about all configuration options.</li>
<li><a href="https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html" rel="noreferrer">Best practises for probes</a>.</li>
<li>The book <a href="https://livebook.manning.com/book/kubernetes-in-action" rel="noreferrer">Kubernetes in Action</a> gives most detailed insights about the best practises.</li>
</ul>
