Containerized Applications

Constraints

• When the disk usage of an edge node exceeds 70%, the image reclamation mechanism is started to reclaim the disk space occupied by the container image. In this case, if you deploy a containerized application, the application container will take a long time to start. Therefore, properly plan the disk space of the edge node before deploying the containerized application.
• When you create a containerized application, the edge node needs to pull an image from SWR. If the image size is too large and the download bandwidth of the edge node is small, the container image fails to be pulled. In this case, a message will be displayed on the IEF console, indicating that the containerized application fails to be created. However, the image pull will not be interrupted. After the container image is pulled successfully, the containerized application will be automatically created. To prevent such a problem, you can pull the container image to the edge node and then create a containerized application.
• The architecture of the container image to be used must be the same as that of the edge node on which a containerized application is to be deployed. For example, if the edge node uses x86, the container image must also use x86.

Creating an Edge Application

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Containerized Applications. Then, click Create Containerized Application in the upper right corner.
3. Specify basic information.
   • Name: name of a containerized application.
   • Instances: number of instances of a containerized application. Only one instance is allowed.
   • Configuration Method
     • Custom: Configure the application step by step. For details, see 4 to 6.
     • Application template: Select a predefined application template and modify it based on your requirements. This method reduces repeated operations. The configurations in a template are the same as those set in 4 to 6. For details on how to create a template, see Application Templates.
   • Description: description of the containerized application.
   • Tags: Tags can be used to classify resources, facilitating resource management.
   Figure 1 Basic information
   

4. Configure containers.
   Click Use Image under the image to be used to deploy the application.

   • My Images: Displays all the images you have created in SWR.
   • Shared Images: Displays images shared by other users. Shared images are managed and maintained in SWR. For details, see Sharing a Private Image.

   After selecting an image, specify container configurations.

   • Image Version: Select the version of the image to be used to deploy the application.
     

     Do not use version latest when deploying containers in the production environment. Because this will make it difficult to determine the version of the running image and to roll back the application properly.

   • Container Specifications: Specify CPU, memory, Ascend AI accelerator card, and GPU quotas.
   • Ascend AI accelerator card: The AI accelerator card configuration of the containerized application must be the same as that of the edge node actually deployed. Otherwise, the application will fail to be created. For details, see how to configure the AI accelerator card during edge node registration.
     

     For NPUs after virtualization partition, only one virtualized NPU can be mounted to a container. The virtualized NPU can be allocated to another container only after the original container quits.

     The following table lists the NPU types supported by Ascend AI accelerator cards.

     Table 1 NPU types

     Type	Description
     Ascend 310	Ascend 310 chips
     Ascend 310B	Ascend 310B chips

     Figure 2 Container configuration
     

   You can also configure the following advanced settings for the container:

   • Command

     A container image has metadata that stores image details. If lifecycle commands and arguments are not set, IEF runs the default commands and arguments provided during image creation, that is, ENTRYPOINT and CMD in the Dockerfile.

     If the commands and arguments used to run a container are set during application creation, the default commands ENTRYPOINT and CMD are overwritten during image building. The rules are as follows:

     Table 2 Commands and arguments used to run a container

     Image ENTRYPOINT	Image CMD	Command to Run a Container	Arguments to Run a Container	Command Executed
     [touch]	[/root/test]	Not set	Not set	[touch /root/test]
     [touch]	[/root/test]	[mkdir]	Not set	[mkdir]
     [touch]	[/root/test]	Not set	[/opt/test]	[touch /opt/test]
     [touch]	[/root/test]	[mkdir]	[/opt/test]	[mkdir /opt/test]

     Figure 3 Command
     
     • Command

       Enter an executable command, for example, /run/start.

       If there are multiple commands, separate them with spaces. If the command contains a space, enclose the command in quotation marks ("").

       

       In the case of multiple commands, you are advised to run /bin/sh or other shell commands. Other commands are used as arguments.

     • Arguments

       Enter the argument that controls the container running command, for example, --port=8080.

       If there are multiple arguments, separate them with line breaks.

   • Security Options
     • You can enable Privileged Mode to grant root permissions to the container for accessing host devices (such as GPUs and FPGAs).
     • RunAsUser Switch

       By default, IEF runs the container as the user defined during image building.

       You can specify a user to run the container by turning this switch on, and entering the user ID (an integer ranging from 0 to 65534) in the text box displayed. If the OS of the image does not contain the specified user ID, the application fails to be started.

   • Environment Variables

     An environment variable affects the way a running container will behave. Variables can be modified after workload deployment. Currently, environment variables can be manually added, imported from secrets or ConfigMaps, or referenced from hostIP.

     • Added manually: Customize a variable name and value.
     • Added from Secret: You can customize a variable name. The variable value is referenced from secret configuration data. For details on how to create a secret, see Secrets.
     • Added from ConfigMap: You can customize a variable name. The variable value is referenced from ConfigMap configuration data. For details on how to create a ConfigMap, see ConfigMaps.
     • Variable reference: The variable value is referenced from hostIP, that is, the IP address of an edge node.
     

     IEF does not encrypt the environment variables you entered. If the environment variables you attempt to configure contain sensitive information, you need to encrypt them before entering them and also need to decrypt them when using them.

     IEF does not provide any encryption and decryption tools. If you need to configure cypher text, choose your own encryption and decryption tools.

   • Data Storage

     You can define a local volume and mount the local storage directory of the edge node to the container for persistent data storage.

     Currently, the following four types of local volumes are supported:

     • hostPath: used for mounting a host directory to the container. hostPath is a persistent volume. After an application is deleted, the data in hostPath still exists in the local disk directory of the edge node. If the application is re-created later, previously written data can still be read after the directory is mounted.

       You can mount the application log directory to the var/IEF/app/log/{appName} directory of the host. In the directory name, {appName} indicates the application name. The edge node will upload the .log and .trace files in the /var/IEF/app/log/{appName} directory to AOM.

       The mount directory is the log path of the application in the container. For example, the default log path of the Nginx application is /var/log/nginx. The permission must be set to Read/Write.

       Figure 4 Log volume mounting
       
     • emptyDir: a simple empty directory used for storing transient data. It can be created in hard disks or memory. emptyDir is an empty directory after being mounted. The application can read files from and write files into the directory. emptyDir has the same lifecycle as the application. If the application is deleted, the data in emptyDir is deleted along with it.
     • configMap: a type of resources that store configuration details required by the application. For details on how to create a ConfigMap, see ConfigMaps.
     • secret: a type of resources that store sensitive data, such as authentication, certificate, and key details. For details on how to create a secret, see Secrets.
     

     • The container path cannot be a system directory, such as / or /var/run. Otherwise, an exception occurs. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, making it impossible for the container to be properly started. As a result, the application creation will fail.
     • If the container is mounted into a high-risk directory, you are advised to use an account with minimum permissions to start the container. Otherwise, high-risk files on the host machine may be damaged.
   • Health Check

     Health check regularly checks the status of containers or workloads.

     • Liveness Probe: The system executes the probe to check if a container is still alive, and restarts the instance if the probe fails. Currently, the system probes a container by HTTP request or command and determines whether the container is alive based on the response from the container.
     • Readiness Probe: The system invokes the probe to determine whether the instance is ready. If the instance is not ready, the system does not forward requests to the instance.

     For details, see Health Check Configuration.

5. Click Next.

   Select a deployment object and specify an edge node.

   Figure 5 Specifying an edge node
   

   You can also configure the following advanced settings for the container:

   • Restart Policy
     • Always restart: The system restarts the container regardless of whether it had quit normally or unexpectedly.
     • Restart upon failure: The system restarts the container only if it had previously quit unexpectedly.
     • Do not restart: The system does not restart the container regardless of whether it had quit normally or unexpectedly.
     

     You are allowed to upgrade a containerized application and modify its access configuration only after you select Always restart.

   • Host PID

     Enabling this function allows containers to share the PID namespace with the host where the edge node resides. In this way, you can perform container operations on the edge node, for example, starting and stopping a container. Similarly, you can perform operations related to the edge node in containers, for example, starting and stopping a process of the edge node.

     This function can only be enabled on edge nodes running software v2.8.0 or later.

6. Click Next.

   Container access supports bridged network and host network.

   

   If the ports of containers deployed on the same edge node conflict, the containers will fail to be started.

   • Bridged network

     The container uses an independent virtual network. A mapping between container and host ports needs to be configured to enable the external communication. After port mapping is configured, traffic destined for a host port is distributed to the mapping container port. For example, if container port 80 is mapped to host port 8080, the traffic destined for host port 8080 will be directed to container port 80.

     You can select a host NIC to enable the port bound to this NIC to communicate with the container port. Note that port mapping does not support NICs with IPv6 addresses.

     Figure 6 Bridged network
     
   • Host network

     The network of the host (edge node) is used. To be specific, the container and the host use the same IP address, and network isolation is not required between them.

7. Click Next to confirm the specifications of the containerized application. If the specifications are correct, select I have read and agree to the Huawei Cloud Service Level Agreement and click Create.

Querying Application O&M Information

After an application is deployed, you can view the CPU and memory information of the application on the IEF console. You can also go to the Container Monitoring page on the AOM console to view additional metrics, or Alarm Center on the AOM console to add or view alarms.

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Containerized Applications. Then, click an application name.
3. Click the Monitoring tab to view the monitoring details for the application.
   Figure 7 Application monitoring details
   

Upgrading an Application

After an application is deployed, you can upgrade it. Rolling upgrades are used. That is, a new application instance is created first, and then the old application instance is deleted.

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Containerized Applications. Then, click an application name.
3. Click the Upgrade tab and modify the container configurations. The parameter settings are the same as those in 4.
   Figure 8 Upgrading an application
   

4. Click Submit.

Modifying Access Settings

After an application is deployed, you can modify the access settings of the application.

1. Log in to the IEF console.
2. In the navigation pane, choose Edge Applications > Containerized Applications. Then, click an application name.
3. Click the Access Settings tab and modify the configurations. The parameter settings are the same as those in 6.
   Figure 9 Modifying access settings
   

4. Click Submit.