K
Q

setting kubernetes livenessProbe for java web applcation is useful?

4/4/2019

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

livenessProbe:
            httpGet:
              path: /actuator/health
              port: http

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

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

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

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

one example I saw is many posts use both livenessProbe and readinessProbe, and both call the same health endpoint.

        livenessProbe:
            httpGet:
              path: /actuator/health
              port: http
          readinessProbe:
            httpGet:
              path: /actuator/health
              port: http
-- HungUnicorn
kubernetes

Similar Questions

How to configure VPN connection between 2 Kubernetes clusters
Can't access EKS api server endpoint within VPC when private access is enabled
Trying to get kube-stats-metrics to run in kubernetes cluster v 1.10.11
Kubernetes frequent connection refused error between two nodejs docker containers

2 Answers

4/4/2019
  1. Dont get confused b/w pods with containers. A pod can run multiple containers.

  2. Dont get confused b/w between 'container running' and 'application running'. Your application might be dependent on multiple factors like is DB up? is SSO working?

    As a principle, focus on what is required to be tested for availability from system's perspective rather than developer. Your application might be up but it might be deadlock or throwing DB related errors. So, pod level health checks are recommended than container level checks.

-- Prateek Jain
Source: StackOverflow
4/4/2019

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.

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.

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.

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.

-- HSquirrel
Source: StackOverflow