<p>I have seen many posts set <code>livenessProbe</code> to health endpoint for java web application. Take springboot as an example:</p>

<pre><code>livenessProbe:
            httpGet:
              path: /actuator/health
              port: http
</code></pre>

<p>But as I know the following command which is the last line of the dockerfile already guarantees the same as livenessProbe implicitly.</p>

<p><code>CMD ["-c", "/usr/bin/java ${DOCKER_JAVA_OPTS} -jar YOUR_JAR.jar"]</code></p>

<p>That said, if java application crashes, a new pod will be created, and therefore, it's no need to set <code>livenessProbe</code> for java application?</p>

<p>For me it also makes no sense to set <code>readinesProbe</code> the same as <code>livenessProbe</code>, because when livenessProbe passes, <code>readinessProbe</code> will pass for sure, and <code>readinessProbe</code> is more useful because after the container runs, the application has to initialize some connections for example, and waiting for the initialization is necessary.</p>

<p>one example I saw is many posts use both <code>livenessProbe</code> and <code>readinessProbe</code>, and both call the same health endpoint.</p>

<pre><code>        livenessProbe:
            httpGet:
              path: /actuator/health
              port: http
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: http
</code></pre>

<p>Kubernetes will only restart the pod if the main container process ends, not when it for example stops being responsive or hangs. The livenessProbe is intended to restart unresponsive containers.</p>

<p>I would not advise to have readinessProbe and livenessProbe exactly the same. You should at least use different values for initialDelay (with the delay less than your startup time for the readinessProbe and more than your startup time for the livenessProbe). If the delay your livenessProbe is too short, your application will get killed and restarted before it manages to fully start.</p>

<p>The readinessProbe should indicate whether your container is ready to respond to requests. Failure of the livenessProbe should indicate that the application hangs and should be restarted. For a lot of simple application that do not have complicated health checks, this situation is the same and hence they use the same tests. If you have more fine-grained health checks, you could have a different test for both probes. Another example of a difference could be in the case that you know your health check will occasionally fail due to some intermittent issue that resolves on its own. In that case I would advise you to increase the failureThreshold of the livenessProbe.</p>

<p>So in general, I would make readinessProbe more strict than the livenessProbe. This way, you ensure that requests only get sent to pods that respond, but avoid unnecessary restarts. Obviously, you need to take the specifics of your application into account.</p>
