Liveness Probe — monitors the availability of an application while it is running. If a liveness probe fails, Kubernetes will restart your pod. This could be useful to catch deadlocks, infinite loops, or just a “stuck” application.

readiness probe - monitors when your application becomes available. If a readiness probe fails, Kubernetes will not send any traffic to the unready pods and the endpoint controller removes the pod from all services. This is useful if your application has to go through some configuration before it becomes available, or if your application has become overloaded but is recovering from the additional load. By having a readiness probe fail, your application will temporarily not get any more traffic…  

 a liveness probe tells Kubernetes if a Pod needs to be replaced and a readiness probe tells Kubernetes if its Pod is ready to accept requests. To simplify this work, Spring Boot has added support for implementing liveness and readiness probes. The probes are exposed on the URLs /actuator/health/liveness and /actuator/health/readiness. They can either be declared by configuration or implementation in source code, if increased control is required compared to what configuration gives. When declaring the probes by configuration, a health group can be declared for each probe specifying what existing health indicators it should include. For example, a readiness probe should report DOWN if a microservice can't access its MongoDB database. In this case, the health group for the readiness probe should include the mongo health indicator

The probes are by default disabled, since not all deployments are using probes.

The probes are based on HTTP GET requests sent to the endpoints exposed by Spring Boot, as described in the section Using Spring Boot's support for graceful shutdown and probes for liveness and readiness above.

As long as the endpoint responds with a 2xx or a 3xx response code, the probe is considered to be successful

The probes can be configured using the following parameters:

initialDelaySeconds specifies how long Kubernetes waits to probe a container after it's started up.

periodSeconds specifies the time between probe requests sent by Kubernetes.

timeoutSeconds specifies how long Kubernetes waits on a response before it treats the probe as failed.

failureThreshold specifies how many failed attempts Kubernetes makes before giving up. In the case of a liveness probe, this means restarting the Pod. In the case of a readiness probe, it means that Kubernetes will not send any more requests to the container until the readiness probes are successful again.

successThreshold specifies the number of successful attempts that are required for a probe to be considered successful again after a failure. This only applies to readiness probes, since it must be set to 1 if specified for liveness probes.