Configuring application probes

The containerized applications can become unhealthy due to issues such as temporary connectivity loss, configuration errors, or application errors. You can edit the pre-configured probes to better monitor the applications.

A probe is a Kubernetes action that periodically gathers diagnostics on a running container. Probes can be configured by using either the kubectl command-line client (CLI) or the OpenShift® web console. Three types of probes can be configured: the startup probe, the liveness probe and the readiness probe.

Startup probes

A startup probes is used to know when a container application has started. Liveness and readiness probes do not start until the startup probe succeeds, making sure those probes don't interfere with the application startup. You can edit a startup probe by configuring the startup parameters in the custom resource of a deployment.

Liveness probes

A liveness probe determines whether an application that is running in a container is in a healthy state. If the liveness probe detects an unhealthy state, Kubernetes deletes the pod and tries to redeploy it again. You can edit a liveness probe by configuring the livenessprobe parameters in the custom resource of a deployment.

Readiness probes

A readiness probe determines whether a container is ready to serve requests. If the readiness probe returns a failed state, Kubernetes removes the IP address of that container from the endpoints of all services. Use readiness probes to signal to Kubernetes that even though a container is running, it cannot receive any traffic from a proxy. You can edit a readiness probe by configuring the readinessprobe parameters in the custom resource of a deployment.

You can use the live editor to edit the period_seconds, success_threshold, failure_threshold, and a few other options. The following example shows the probes for Content Platform Engine:

cpe:
  probe:
    startup:
      initial_delay_seconds: 120
      period_seconds: 30
      timeout_seconds: 10
      failure_threshold: 16
    readiness:
      period_seconds: 30
      timeout_seconds: 10
      failure_threshold: 6
    liveness:
      period_seconds: 30
      timeout_seconds: 5
      failure_threshold: 6

The period_seconds value of 30 seconds specifies that the Kubernetes runs a liveness probe every 30 seconds. The initial_delay_seconds value of 120 seconds tells Kubernetes that it needs to wait 2 minutes before it runs the first probe. To run a probe, Kubernetes sends a request to the server that is running in the container. If the server returns a success code, Kubernetes considers the container to be alive and working correctly. If the server returns a failure code, Kubernetes deletes the container and restarts it.

The timeout_seconds value of 10 seconds is the time Kubernetes waits for the probe to finish. If this time is exceeded and the probe is not finished, Kubernetes concludes that the probe failed.

The failure_threshold value of 6 is the minimum consecutive failures for the probe to be considered failed after it succeeded.

You can configure the values of both these probes to make sure that traffic does not reach a container that is not ready for it. The probes help Kubernetes detect containers that are not working correctly, so they can be restarted.