Probe examples

Last Updated: Aug 15, 2019

This topic describes how to configure the container liveness and readiness probes.

Kubelets use liveness probes to determine when to restart containers. For example, when an application is running but cannot perform other operations in a container, a deadlock can be detected by liveness probes. In this case, the kubelet restarts the container so that the application can continue to run, even with bugs.

Kubelets use readiness probes to determine whether containers are ready to accept traffic. The kubelet of a pod considers the pod ready only when all containers in the pod are ready. Readiness probes determine which pods run at the service backend. Non-ready pods are deleted from the load balancer of the service.

1. Liveness probe

Many applications enter the broken state after running for a long time, and cannot resume unless they are restarted. Kubernetes provides a liveness probe mechanism to detect and rectify this problem.

The following example uses a BusyBox image to create a container group that contains one container.

The preceding example configures one container for the container group. LivenessProbe.PeriodSeconds specifies that the kubelet should run a liveness probe every 5 seconds. LivenessProbe.InitialDelaySeconds specifies that the kubelet should wait for 5 seconds before running the probe for the first time. The cat /tmp/healthy command is executed in the container to run probes. If the command is executed successfully, 0 is returned. In this case, the kubelet considers that the container is active and healthy. If a non-0 value is returned, the kubelet kills the container and restarts it.

The following command is executed during the startup of the container:

A /tmp/healthy file is generated in the first 30 seconds of the container’s lifecycle. Within the 30 seconds, running the cat /tmp/healthy command returns a success code. After the 30 seconds, running cat /tmp/healthy returns a failure code.

When you view the events of the pod within the first 30 seconds, no failed liveness probe is displayed.

View the events of the pod again 35 seconds later.

You can also see three warnings, because the default value of Container.1.LivenessProbe. FailureThreshold is 3.

2. Readiness probe

Sometimes, an application cannot process external traffic in a short period. For example, the application needs to load a large amount of data or configurations during startup. In this case, you do not want to kill the application or send requests to it. Kubernetes provides a readiness probe mechanism to detect and alleviate the problem. Containers in a pod can report their non-ready states, in which case they cannot process traffic from Kubernetes.

The readiness probe configuration is the same as the liveness probe configuration, except that the command is readinessProbe instead of livenessProbe.

The HTTP and TCP probe settings for readiness probes are the same as those for liveness probes.

Readiness and liveness probes can be used in the same container. They prevent traffic from reaching non-ready containers and enable containers to restart upon failures.