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.

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…