Configure health check for containers

You can use the following probes to check container health:

• Liveness probe: determines whether a container is alive. If the liveness probe detects that a container is unhealthy, kubelet stops the container and performs processing based on the restart policy of the container. If the liveness probe detects that a container is healthy, no processing is performed.
• Readiness probe: determines whether a container is ready to receive traffic. Some programs may take a long period of time to start. For example, they can provide Services only after disk data is loaded or an external module has started. During the startup, the programs are in progress, but cannot provide Services. If the readiness probe detects that a container is ready, Services can send traffic to the container. If the readiness probe detects that a container is not ready, the cluster stops sending traffic to the container.

Health check methods

• TCP port-based check

  The cluster periodically initiates a TCP connection to a container that provides a TCP communication Service. If the connection is successfully established, the health check succeeds. Otherwise, the health check fails. In this method, you must specify a detection port for the container. For example, an NGINX container uses a Service port 80, TCP port-based check is configured for the container, and port 80 is configured as the detection port. In this case, the cluster periodically initiates a TCP connection to port 80 of the container. If the connection is successfully established, the health check succeeds. Otherwise, the health check fails.

• HTTP or HTTPS request-based check

  This method is applicable to containers that provide an HTTP or HTTPS Service. The cluster periodically initiates an HTTP or HTTPS GET request to a container that provides an HTTP or HTTPS Service based on the IP address, port number, and path of the container. If the status code in the response ranges from 200 to 400, the container is healthy. Otherwise, the health check fails. For example, a container that provides an HTTP Service uses a Service port 80, and the HTTP health check path is /health. In this case, the cluster periodically initiates the following request to the container: GET http://containerIP:80/health

• Health check command

  You can specify an executable health check command for a container so that the cluster periodically executes the command in the container. If the command response is 0, the health check succeeds. Otherwise, the health check fails.

  For example, you can write health check commands to replace the preceding methods based on TCP ports and HTTP or HTTPS requests:

  • To replace the TCP port-based check method, you can write a command to connect to the port of the container. If the connection succeeds, the command response is 0. Otherwise, the command response is -1.

  • To replace the HTTP or HTTPS request-based check method, you can write a wget command to retrieve content from the container: wget http://containerIP:80/health If the status code in the response ranges from 200 to 399, the command response is 0. Otherwise, the command response is -1.

Notes:

• The command to be executed must be placed in the container image. Otherwise, the execution fails because the command cannot be found.
• If the command to be executed is a shell script, an interpreter must be added to the command because the cluster is not in the terminal environment when the cluster executes the command in the container. For example, if the script is /data/scripts/health.sh, the command for health check is sh /data/scripts/health.sh.

Configure the probes

The probes provide detailed configurations that allow you to accurately control liveness and readiness checks:

• initialDelaySeconds: the initial delay in seconds. This parameter specifies how soon the health check starts after the container starts. For example, if this parameter is set to 30s, the health check starts 30s after the container starts.
• periodSeconds: the health check interval in seconds. This parameter specifies the frequency of health checks. For example, if this parameter is set to 10s, the health check is performed every 10s.
• timeoutSeconds: the response timeout period in seconds. This parameter specifies the health check timeout period, which corresponds to the TCP connection timeout period, HTTP/HTTPS response timeout period, and command execution timeout period in the three health check methods based on TCP ports, HTTP or HTTPS requests, and health check commands.
• successThreshold: the health check success threshold in counts. This parameter specifies the number of consecutive successful health checks for determining that the container is healthy. For example, if this parameter is set to 3, the container is considered healthy only if three consecutive health checks succeed.
• failureThreshold: the health check failure threshold in counts. This parameter specifies the number of consecutive health check failures for determining that the container is unhealthy. For example, if this parameter is set to 3, the container is considered unhealthy only if three consecutive health checks fail.

Note: The successThreshold parameter must be set to 1 for the liveness probe of a container. Any other values are invalid. This is because it can be determined that the container is alive when the liveness check succeeds once.