• Cloud Container Engine

cce
  1. Help Center
  2. Cloud Container Engine
  3. User Guide 2.0
  4. Application Management
  5. Checking the Health of Containers

Checking the Health of Containers

Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect service exceptions or automatically restart the service to restore it. This will result in a situation where the pod status is normal but the service in the pod is abnormal.

CCE provides following health check methods:

  • Application Liveness Probe: checks whether a container exists. It is similar to the ps command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed. If the liveness check of a container fails, the cluster restarts the container.
  • Application Service Probe: checks whether a container is ready to process user requests. It may take a long time for some applications to start up before they can provide services. For example, loading disk data or relying on startup of an external module. In this case, the application process is running, but the application cannot provide services. This check method is useful in this scenario. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed.

Health Check Mode

  • HTTP request mode

    This health check mode is applicable to containers that provide HTTP/HTTPS services. The cluster periodically initiates an HTTP/HTTPS GET request to such containers. If the return code of the HTTP/HTTPS response is within 200–399, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port and an HTTP/HTTPS request path.

    For example, if you have an HTTP service container, after you specify port 80 for container listening and the HTTP request path /health-check, the cluster periodically initiates the GET http://containerIP:80/health-check request to the container.

  • TCP port mode

    For a container that provides TCP communication services, the cluster periodically establishes a TCP connection to the container. If the connection is successful, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port. For example, if you have an Nginx container with service port 80, after you configure TCP port probe for the container and specify port 80 for the probe, the cluster periodically initiates a TCP connection to port 80 of the container. If the connection is successful, the probe is successful. Otherwise, the probe fails.

  • CLI mode

    The CLI mode is an efficient health check mode. In this mode, you must specify an executable command in a container. The cluster will periodically execute the command in the container. If the command output is 0, the health check is successful. Otherwise, the health check fails.

    The CLI mode can be used to replace the following modes:

    • TCP Link Setup Mode: Write a program script to connect to a container port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
    • HttpGet Request Mode: Write a program script to run the wget command for a container.

      wget http://127.0.0.1:80/health-check

      Check the return code of the response. If the return code is within 200–399, the script returns 0. Otherwise, the script returns –1.

      • Put the program to be executed in the container image so that the program can be executed.
      • If the command to be executed is a shell script, do not directly specify the script as the command, but add a script interpreter. For example, if the script is /data/scripts/health_check.sh, you must specify sh/data/scripts/health_check.sh for command execution. The reason is that the cluster is not in the terminal environment when executing programs in a container.

Common Parameter Description

Table 1 Common parameter description

Parameter

Description

Delay Time (s)

Interval between two health checks. Unit: second.

For example, if the parameter is set to 10, the health check interval is 10s.

Timeout Time

Timeout duration. Unit: second.

For example, if this parameter is set to 10, the timeout wait time for performing a health check is 10s. If the wait time elapses, the health check is regarded as a failure. If the parameter is left blank or set to 0, the default timeout time is 1s.