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

The kubelet client uses liveness probes to determine when to restart a container.
Note 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 client restarts the container so that the application can continue to run, even with bugs.
The kubelet client uses readiness probes to determine whether a container is ready to accept traffic.
Note The kubelet clients considers that an ECI is ready only when all containers in the ECI are ready. Readiness probes determine which ECIs are used as the backends of services. ECIs that are not ready are deleted from the load balancers of services.

Liveness probe

Many applications eventually enter the broken state after running for a long period of time, and cannot recover unless they are restarted. Kubernetes allows you to use liveness probes to detect and fix such an issue.

Readiness probe

Sometimes, an application may be temporarily unable to serve external traffic, for example, when the application needs to load a large amount of data or configurations files during startup. In this case, you may not want to kill the application or send any requests to it. Kubernetes allows you to use readiness probes to detect and avoid such an issue. Containers in an ECI can report that they are not ready, so that the ECI can stop to receive traffic from Kubernetes.

Example

This section takes a container that runs the Nginx application as an example to demonstrate the usage of liveness probes and readiness probes.

First, create an ECI by using the Nginx image. The code snippets related to the liveness probe and readiness probe are as follows. For more information about the complete code, click here.

// After the container is running for 5 seconds, the kubelet client runs a liveness probe and a readiness probe on port 80 every 3 seconds. The timeout period of each probe is set to 10 seconds. The number of consecutive successes for a probe to be considered successful is set to 3, and the number of consecutive failures for a probe to considered failed is also set to 3.
CreateContainerGroupRequest.Container.ContainerProbe livenessProbe = new CreateContainerGroupRequest.Container.ContainerProbe();
livenessProbe.setTcpSocketPort(80);
livenessProbe.setInitialDelaySeconds(5);
livenessProbe.setPeriodSeconds(3);
livenessProbe.setFailureThreshold(3);
livenessProbe.setSuccessThreshold(1);
livenessProbe.setTimeoutSeconds(10);

CreateContainerGroupRequest.Container.ContainerProbe readinessProbe = new CreateContainerGroupRequest.Container.ContainerProbe();
readinessProbe.setTcpSocketPort(80);
readinessProbe.setInitialDelaySeconds(5);
readinessProbe.setPeriodSeconds(3);
readinessProbe.setFailureThreshold(3);
readinessProbe.setSuccessThreshold(3);
readinessProbe.setTimeoutSeconds(10);

After the ECI is created, log on to the ECI console. In the ECI console, you can view the events of the ECI. The events shown in the following figure indicate that the ECI is running properly.

Change the Nginx listening port of the target container in the configuration file to simulate a service exception.

About 10 seconds later, the container is restarted. The following figure shows the events occurred. During this period, three failures of liveness probes and readiness probes occurred respectively and then the container was automatically restarted.