You can configure the PostStart and PreStop lifecycle hooks in the Enterprise Distributed Application Service (EDAS) console so that you can add code to customize operations when applications are running. You can also configure the Liveness and Readiness probes in the EDAS console to detect the liveness and readiness of containers. This topic describes how to configure the lifecycle hooks of applications and the Liveness and Readiness probes of containers.

Background information

In general, some operations are performed before and after an application is started or stopped. For example, you can deploy resources before you start an application, and gracefully unpublish the application or notify other services or applications before you stop the application. EDAS integrates the lifecycle hook feature based on Kubernetes. This feature allows you to configure the PostStart and PreStop hooks for containers.

To deploy an application to a Kubernetes cluster, you must check whether the pods are alive and ready to provide services. EDAS integrates the pod probe configuration feature based on Kubernetes. This feature allows you to configure the Liveness probe to determine the time to restart containers and configure the Readiness probe to determine whether containers are ready to receive traffic.

Configure application lifecycle hooks and probes when you create an application

  1. Log on to the EDAS console.
  2. In the left-side navigation pane, click Applications. In the top navigation bar, select a region. On the Applications page, select a namespace in the upper part and click Create Application in the upper-left corner.
  3. In the Basic Information step, specify Cluster Type and Application Runtime Environment, and click Next.
    Parameter Description
    Cluster Type Select Kubernetes Clusters.
    Application Runtime Environment Select an application runtime environment based on the type of the hosted application.
    • Java
      • Custom: Select this option if you want to use a custom image to deploy the application in a Kubernetes cluster.
      • Java: Select this option if you want to use a universal JAR package to deploy the application as a Dubbo or a Spring Boot application. You can specify the Java Environment parameter after you select this option.
      • Tomcat: Select this option if you want to use a universal WAR package to deploy the application as a Dubbo or a Spring application. You can specify the Java Environment and Container Version parameters after you select this option.
      • EDAS-Container (HSF): Select this option if you want to use a WAR or FatJar package to deploy the application as a High-Speed Service Framework (HSF) application. You can specify the Java Environment, Pandora Version, and Ali-Tomcat Version parameters after you select this option.
    • PHP: Select this option if you want to run this application as a PHP application on Apache HTTP Server.
    • Node.js, C ++, Go, and Other Languages: Select this option if you want to use a custom image to deploy the application in a Kubernetes cluster. The configuration process for multi-language applications is not described in this topic. For more information, see Use images to deploy microservice-based multi-language in Kubernetes clusters.
  4. In the Configurations step, configure the environment information, basic information, deployment method, and resource parameters for the application, and click Next.
  5. In the Advanced Settings step, click Application Life Cycle Management and configure the hooks and probes that are described in the following table.
    Parameter Description
    PostStart A container hook. The hook is immediately triggered after a container is created. The hook notifies the container that the hook is created. The hook does not pass parameters to the corresponding hook handler. If the corresponding hook handler fails to run, the container is stopped and the restart policy of the container is used to determine whether to restart the container. For more information, see Container Lifecycle Hooks.
    PreStop A container hook. The hook is triggered before a container is deleted. The corresponding hook handler must be run before the request to delete the container is sent to the Docker daemon. The Docker daemon sends a SIGTERM signal to itself to delete the container, regardless of the result after the corresponding hook handler is run. For more information, see Container Lifecycle Hooks.
    Liveness A probe that monitors your container status. The probe detects whether your applications are healthy. If an application is unhealthy, its corresponding container is deleted and recreated. For more information, see Pod Lifecycle.
    Readiness A probe that monitors your container status. The probe detects whether your applications have been started and are running as expected. If an application is not running as expected, the container status is updated. For more information, see Pod Lifecycle.
  6. Click Create Application.
  7. In the Creation Completed step, confirm the settings in Basic Information, Configurations, and Advanced Settings, and click Create Application.
    In the upper part of the Application Overview page, click View Details. On the Change List page, you can view the change process. Wait a few minutes until the application is deployed. After the change process is complete, view the running status of the instances in the Basic Information section of the Application Overview page. If the pod that runs the application is in the running state, the application is deployed.

Configure application lifecycle hooks and probes when you update an application

You can configure application lifecycle hooks and probes when you create an application, or configure or update the hooks and probes when you deploy an application.

  1. Log on to the EDAS console.
  2. In the left-side navigation pane, click Applications. In the top navigation bar, select a region. On the Applications page, select a namespace in the upper part, and select Container Service or Serverless Kubernetes Cluster from the Cluster Type drop-down list. Then, find the application that you want to deploy, and click the application name.
  3. On the Application Overview or Basic Information page, choose Deploy > Deploy in the upper-right corner.
  4. On the Select Deployment Mode page, select a deployment mode and click Start Deployment in the upper-right corner of the specified deployment mode section.
  5. Set the parameters for the application environment and deployment package, click Application Life Cycle Management, complete the configuration as needed, and then click OK.
    Parameter Description
    PostStart A container hook. The hook is immediately triggered after a container is created. The hook notifies the container that the hook is created. The hook does not pass parameters to the corresponding hook handler. If the corresponding hook handler fails to run, the container is stopped and the restart policy of the container is used to determine whether to restart the container. For more information, see Container Lifecycle Hooks.
    PreStop A container hook. The hook is triggered before a container is deleted. The corresponding hook handler must be run before the request to delete the container is sent to the Docker daemon. The Docker daemon sends a SIGTERM signal to itself to delete the container, regardless of the result after the corresponding hook handler is run. For more information, see Container Lifecycle Hooks.
    Liveness A probe that monitors your container status. The probe detects whether your applications are healthy. If an application is unhealthy, its corresponding container is deleted and recreated. For more information, see Pod Lifecycle.
    Readiness A probe that monitors your container status. The probe detects whether your applications have been started and are running as expected. If an application is not running as expected, the container status is updated. For more information, see Pod Lifecycle.
    Notice The application is restarted after you click OK. We recommend that you perform this operation during off-peak hours.

Set configurations for application lifecycle management

Configure the PostStart and PreStop hooks

The configuration methods for the PostStart and PreStop hooks are the same. You can configure the hooks in the following modes:
  • Exec: runs a specific command in a container. If 0 is returned after the command is run, the command execution is successful.

  • HttpGet: sends an HTTP GET request to a specific container endpoint. If a status code that is greater than or equal to 200 but less than 400 is returned, the request is successful.

The following examples show you how to configure the PostStart hook in Exec and HttpGet modes in EDAS:

  • Exec mode

    For example, you want to run the following command after a container is created:

    echo "container started"
    You can configure the PostStart hook by using the following methods in EDAS:
    • Method 1: Split the command into different parameters.

      You can use this method if the command is short and contains a few parameters.

    • Method 2: Start a shell and run the command in the shell.

      You can use this method if the command is long and contains many parameters.

  • HttpGet mode

    In HttpGet mode, you need to set the following parameters:
    • Host: the host address of the HTTP request. If you leave this parameter empty, the IP address of the pod is used.
    • Path: the path of the HTTP request. Default value: /.
    • Port :the port number of the HTTP request.
    • Scheme: the protocol type. HTTP and HTTPS protocols are supported. By default, the HTTP protocol is used.
    • HttpHeaders: the custom HTTP request header.
    Note

    If the PostStart or PreStop hook fails to be run, the container is automatically restarted. You can query the information about execution failures of the PostStart or PreStop hook in the application change records.

Configure the Liveness and Readiness probes

EDAS supports the following two types of Kubernetes container probes:
  • LivenessProbe: detects whether a container is alive. If the detection fails, Kubernetes automatically terminates the container, and then restarts the container based on the restart policy.

  • ReadinessProbe: detects whether a container is ready to receive traffic. If the detection is successful, Kubernetes adds the pod to the service list to which the pod belongs so that the pod starts to receive traffic.

The Liveness and Readiness probes can be configured in the following modes:
  • Exec: runs a specific command in a container. If 0 is returned after the command is run, the detection is successful.

  • HttpGet: sends an HTTP GET request to a specific container endpoint. If a status code that is greater than or equal to 200 but less than 400 is returned, the detection is successful.

  • TcpSocket: checks whether the specified TCP port corresponding to the IP address of the container is enabled. If the port is enabled, the detection is successful.

In the preceding modes, you need to set the following parameters for the Liveness or Readiness probe:
  • InitialDelaySeconds: the delay from the start of the container to the first detection of the probe. Unit: seconds. Minimum value: 1. Maximum value: 1000.

  • PeriodSeconds: the interval at which detections are carried out. Unit: seconds. Minimum value: 1. Maximum value: 1000.

  • SuccessThreshold: the number of consecutive successful detections that must occur following a failed detection before the probe is declared successful. Minimum value: 1. Maximum value: 1000. For the Liveness probe, the value is set to 1.

  • TimeoutSeconds: the timeout period of a detection. Unit: seconds. Minimum value: 1. Maximum value: 1000.

  • FailureThreshold: the number of consecutive detection failures that must occur following a successful detection before the probe is declared a failure. Minimum value: 1. Maximum value: 1000.

Verify the result

After you configure an application lifecycle hook, you can perform the following steps to verify the configuration:

For example, configure the write script Hello from the postStart handler before you start an application.

After you deploy the application, use a web shell to check whether the Hello from the postStart handler script exists. If the script exists, the configuration is successful. Lifecycle configured

DingTalk group for Container Service for Kubernetes and Serverless Kubernetes clusters in EDAS

If you have questions or suggestions when you use Container Service for Kubernetes and Serverless Kubernetes clusters in EDAS, submit a ticket. To give feedback, you can also join the DingTalk group by searching for the DingTalk group ID 23197114.