Use probes to perform health checks on containers - Elastic Container Instance

Liveness probes and readiness probes are mechanisms that are used to check the status of containers. Liveness probes are used to check whether containers are running as expected, and readiness probes are used to check whether containers are ready. This topic describes how to configure liveness probes and readiness probes to perform health checks on containers. This way, Elastic Container Instance can better monitor and manage the running status of containers and ensure the high availability and stability of services.

Feature description

Elastic Container Instance allows you to use liveness probes and readiness probes to check the condition and running status of containers.

Probe	Description	Scenario
Liveness probe	Liveness probes are used to check whether a container is working as expected. If the check succeeds, the container is working as expected. If the check fails, the system determines whether to restart the container based on the configured container restart policy. By default, if a liveness probe is not configured, the container is considered to be working as expected all the time.	When an application is running but no further operations can be performed on it, liveness probes can capture the deadlock. The system then restarts the container to make the application still run as expected despite bugs. After applications run for a long period of time, they may eventually transition to the broken state. If you want to restore the applications, you must restart them. You can use liveness probes to detect and remedy such situations.
Readiness probe	Readiness probes are used to check whether a container is ready to serve requests. If the check succeeds, the container is ready to receive business requests. If the check fails, the container is not ready and the system does not send requests to the container until the recheck succeeds.	An application may be temporarily unable to serve external requests when it loads a large amount of data or configuration files during startup. In this case, if you do not want to terminate the application or send requests to the application, you can use readiness probes to detect and mitigate such situations.

Configuration description

OpenAPI

When you create an elastic container instance by calling the CreateContainerGroup operation, you can use the LivenessProbe and ReadinessProbe parameters to configure liveness probes and readiness probes. The following table describes the parameters. For more information, see CreateContainerGroup.

LivenessProbe-related parameters

Important

When you configure LivenessProbe-related parameters, you can select only one of the HttpGet, Exec, and TcpSocket check methods.

Parameter	Type	Example	Description
Container.N.LivenessProbe.HttpGet.Path	string	/healthyz	The path to which HTTP GET requests are sent when you use HTTP requests to perform health checks.
Container.N.LivenessProbe.HttpGet.Port	integer	8888	The port to which HTTP GET requests are sent when you use HTTP requests to perform health checks.
Container.N.LivenessProbe.HttpGet.Scheme	string	HTTP	The protocol type of HTTP GET requests when you use HTTP requests to perform health checks. Valid values: HTTP HTTPS
Container.N.LivenessProbe.Exec.Command.N	array	cat /tmp/healthy	Command N to be executed in the container when you use the CLI to perform health checks.
Container.N.LivenessProbe.TcpSocket.Port	integer	8000	The port to which Transmission Control Protocol (TCP) socket requests are sent when you use TCP sockets to perform health checks.
Container.N.LivenessProbe.InitialDelaySeconds	integer	5	The number of seconds between the time when the startup of the container ends and the time when the check starts.
Container.N.LivenessProbe.PeriodSeconds	integer	1	The interval at which the container is checked. Default value: 10. Minimum value: 1. Unit: seconds.
Container.N.LivenessProbe.SuccessThreshold	integer	1	The minimum number of consecutive successes that must occur for the check to be considered successful. Default value: 1. Set the value to 1.
Container.N.LivenessProbe.FailureThreshold	integer	3	The minimum number of consecutive failures that must occur for the check to be considered failed. Default value: 3.
Container.N.LivenessProbe.TimeoutSeconds	integer	1	The timeout period of the health check. Default value: 1. Minimum value: 1. Unit: seconds.

ReadinessProbe-related parameters

Important

When you configure ReadinessProbe-related parameters, you can select only one of the HttpGet, Exec, and TcpSocket check methods.

Parameter	Type	Example	Description
Container.N.ReadinessProbe.HttpGet.Path	string	/healthyz	The path to which HTTP GET requests are sent when you use HTTP requests to perform health checks.
Container.N.ReadinessProbe.HttpGet.Port	integer	8888	The port to which HTTP GET requests are sent when you use HTTP requests to perform health checks.
Container.N.ReadinessProbe.HttpGet.Scheme	string	HTTP	The protocol type of HTTP GET requests when you use HTTP requests to perform health checks. Valid values: HTTP HTTPS
Container.N.ReadinessProbe.Exec.Command.N	array	cat /tmp/healthy	Command N to be executed in the container when you use the CLI to perform health checks.
Container.N.ReadinessProbe.TcpSocket.Port	integer	8000	The port to which TCP socket requests are sent when you use TCP sockets to perform health checks.
Container.N.ReadinessProbe.InitialDelaySeconds	integer	5	The number of seconds between the time when the startup of the container ends and the time when the check starts.
Container.N.ReadinessProbe.PeriodSeconds	integer	1	The interval at which the container is checked. Default value: 10. Minimum value: 1. Unit: seconds.
Container.N.ReadinessProbe.SuccessThreshold	integer	1	The minimum number of consecutive successes that must occur for the check to be considered successful. Default value: 1. Set the value to 1.
Container.N.ReadinessProbe.FailureThreshold	integer	3	The minimum number of consecutive failures that must occur for the check to be considered as failed. Default value: 3.
Container.N.ReadinessProbe.TimeoutSeconds	integer	1	The timeout period of the health check. Default value: 1. Minimum value: 1. Unit: seconds.

Console mode

When you create an elastic container instance on the buy page in the Elastic Container Instance console, you can click Advanced Settings in the Container Configurations section and enable Health Check. The following figure shows the configuration details.

Note

When you configure health checks in the Elastic Container Instance console, only the CLI and HTTP request methods are supported. The TCP socket method is not supported.

健康检查1

The following table describes the parameters.

Parameter	Description
Timeout Period	You must set Waiting Period and Timeout Period. Waiting Period: The number of seconds to wait before the probe performs the first health check. Timeout Period: The timeout period of the check. If a timeout error occurs, the check failed.
Method	Valid values: Script: The probe runs commands in the container and checks the exit code of the command. If the exit code is 0, the check is successful. HTTP Request Method: The probe sends an HTTP request to the container. If the returned status code is greater than or equal to 200 and less than 400, the check is successful.
Script	When you select Script for Method, you must configure the command line script to be executed in the container.
HTTP Request	When you select HTTP Request Method for Method, you must configure the path, port, and protocol for HTTP GET requests.

Configuration examples

In this example, an elastic container instance that has a liveness probe and readiness probe configured is created and contains an NGINX container. Then, service exceptions are simulated to check whether the configured probes take effect.

Create an elastic container instance by using SDK for Java.

Create an elastic container instance by using an NGINX image. The following sample code shows how to configure a liveness probe and a readiness probe:

// Configure a liveness probe. After the container runs for 5 seconds, the kubelet runs the liveness probe on port 80 every 3 seconds. The timeout period of each check is set to 10 seconds. The minimum number of consecutive successes that must occur for the check to be considered as successful is set to 1, and the minimum number of consecutive failures that must occur for the check to be considered as failed is 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);
// Configure a readiness probe. After the container runs for 5 seconds, the kubelet runs the readiness probe on port 80 every 3 seconds. The timeout period of each check is set to 10 seconds. The minimum number of consecutive successes that must occur for the check to be considered as successful is set to 1, and the minimum number of consecutive failures that must occur for the check to be considered as failed is set to 3.
CreateContainerGroupRequest.Container.ContainerProbe readinessProbe = new CreateContainerGroupRequest.Container.ContainerProbe();
readinessProbe.setTcpSocketPort(80);
readinessProbe.setInitialDelaySeconds(5);
readinessProbe.setPeriodSeconds(3);
readinessProbe.setFailureThreshold(3);
readinessProbe.setSuccessThreshold(1);
readinessProbe.setTimeoutSeconds(10);

View the related events after an elastic container instance is created.
After an elastic container instance is created, view events about the instance. You can see that the instance starts as expected.
Change the NGINX listening port in the configuration file to simulate a service exception.
1. Change the NGINX listening port.
```
vi /etc/nginx/conf.d/default.conf
```
  Example:
2. Restart NGINX.
```
nginx -s reload
```
View the effective status of the probe.
A few seconds after you restart NGINX, the container automatically restarts. View events about the instance. You can see that the container is restarted after the liveness probe and readiness probe each have three consecutive failures.