Fault management method for containers based on embedded real-time operating systems

Abstract

The present invention's fault management method for containers based on an embedded real-time operating system is implemented through two components: an application fault management component and an application fault collection component. The application management component, present in all containers, is responsible for acquiring and recording fault information for each container and performing fault management actions. The application fault collection component, present in the container engine, collects fault information that causes container status changes and manages the container status based on this information. This ensures that when a node agent requests container status feedback from the container engine, the container engine can provide timely updated container status information.

Description

Technical Field

[0001] The present invention relates to the technical field of computer system software, and in particular to a fault management method for a container based on an embedded real-time operating system. Background Art

[0002] The essence of container technology is a virtualization technology that can provide lightweight virtualization to isolate processes and resources, effectively dividing resources managed by a single operating system into different containers. This allows container users to obtain resource isolation at the container view level and resolve conflicts in resource usage.

[0003] Compared to traditional embedded virtual machines, container technology virtualizes individual applications. Therefore, running the same number of applications using container technology consumes fewer resources and offers higher performance than using virtual machines alone. Therefore, when embedded hardware platforms face resource constraints and overall performance limitations, using container technology based on embedded real-time operating systems (RTOSs) allows for lightweight isolation while also enabling resource sharing between containers and the host machine.

[0004] Container technology based on an embedded real-time operating system, combined with an orchestration and scheduling system, enables global, unified management of multi-node resources, coordinated global task deployment, and service-oriented governance. As the actual executor of tasks, the container's execution status affects resource allocation and task scheduling across the entire system. If a container fails, both immediate repair attempts and prompt notification to the orchestration and scheduling system are necessary. A management approach was designed based on these requirements. Summary of the Invention

[0005] In view of this, the present invention provides a fault management method for a container based on an embedded real-time operating system, which is used by a container engine to collect fault information that causes changes in the container state and manage the container state based on the fault information, so that when a node agent requests the container engine to feedback the container state, the container engine can feedback the container state information in a timely manner.

[0006] A fault management method for a container based on an embedded real-time operating system is applicable to an embedded real-time operating system using a container environment. The container environment runs on the embedded real-time operating system and includes a container engine with a node management function and a container for running user applications. The container for running user applications is used as an application container. The method includes:

[0007] When a fault occurs in each container, the fault information is obtained and the fault management action corresponding to the fault information is executed. The fault management action is a user-defined hook.

[0008] When a user-defined fault management action changes the state of a container, the corresponding fault is reported to the container engine, and the container engine and the container running the user application communicate through the Socket interface;

[0009] The container application fault collection task in the container engine is used as the server side, waiting to receive faults reported by the container application. When the fault information is received, log processing is first performed, and then the status file of the application container is modified so that the external node agent can perceive the status of the application container in time when sending a heartbeat request. When the node agent perceives that the status of the application container is "CONTAINER_EXITED", the application container is deleted and the container engine is notified to restart a container with the same name and image.

[0010] Beneficial effects

[0011] The container technology based on the embedded real-time operating system is combined with the orchestration and scheduling system to achieve global unified management of multi-node resources, global task coordination deployment and service-oriented governance. As the actual executor of the task, the execution status of the container will affect the resource allocation and task scheduling of the entire system. Once a container fails, on the one hand, it is necessary to try to repair the failure in a timely manner, and on the other hand, it is necessary to let the orchestration and scheduling system know about it in a timely manner. The present invention accomplishes this through two components: an application fault management component and an application fault collection component. The application management component is responsible for executing the fault information acquisition record and fault management actions of each container. This component exists in all containers; the application fault collection component exists in the container engine and is used by the container engine to collect fault information that causes container status changes, and perform container status management based on the fault information, so that when the node agent requests the container engine to feedback the container status, the container engine can feedback the updated container status information in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 Schematic diagram of the architecture of the method of the present invention. DETAILED DESCRIPTION

[0014] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0015] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0016] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this apparatus and / or practice this method.

[0017] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The illustrations only show components related to the present disclosure and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0018] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, one skilled in the art will appreciate that aspects may be practiced without these specific details.

[0019] See also Figure 1 The fault management method of the container based on the embedded real-time operating system is applicable to the embedded real-time operating system using the container environment. The container environment runs on the embedded real-time operating system and includes a container engine with node management function and a container running user applications. The container running the user application is used as an application container. The method includes:

[0020] When a failure occurs in each container, the fault information is obtained and the corresponding fault management action is executed. The fault management action is a user-defined hook.

[0021] When a user-defined fault management action changes the state of a container (for example, stopping a container), the corresponding fault is reported to the container engine. The container engine and the container running the user application communicate through the socket interface.

[0022] The container application fault collection task in the container engine is used as the server side, waiting to receive faults reported by the container application. When receiving fault information, log processing is performed first, and then the status file of the application container is modified so that the external node agent can perceive the status of the application container in time when sending a heartbeat request. When the node agent perceives that the status of the application container is "CONTAINER_EXITED", the application container is deleted and the container engine is notified to restart a container with the same name and image.

[0023] As a specific implementation method provided in this case, the application fault management component (used by all containers) and the application fault collection component (only in the container engine) are used to manage the faults of all containers, wherein:

[0024] The application fault management component is used to perform fault information acquisition, recording, and fault management actions for all containers (referring to the container engine for node management functions and containers running user applications).

[0025] The application fault collection component is used by the container engine to collect fault information that causes changes in the application container status, and manage the container status based on the fault information, so that when the node agent requests the container engine to feedback the status of the application container, it can feedback the updated application container status information.

[0026] Furthermore, the workflow of the application fault management component includes,

[0027] a) When all containers are initialized, a fault action table is created to map different faults to different fault handling actions.

[0028] b) When a fault occurs, obtain the fault site information and call the container's fault injection interface to inject the fault. The fault site information includes the file name, function name, code line number, and fault type where the fault occurred.

[0029] c) Generate a log based on the injected fault site information and record it in a designated location within the container;

[0030] d) After the log is generated, the fault action table is queried to determine whether an action corresponding to the fault type is enabled. If so, the corresponding action is executed, and a determination is made as to whether the fault management action changes the state of the container. If so, the fault is reported to the container engine; otherwise, no additional action is performed; in other words, the default action (nothing) is executed.

[0031] The workflow of the application fault collection component includes:

[0032] a) When the container engine is initialized, the container application fault collection task is started as a server to wait for faults reported by the container application;

[0033] b) When the container application fault collection task receives a reported fault, it first processes the logs and then modifies the application container's status file so that the node agent can promptly detect the application container's status when sending a heartbeat request. The purpose is that when the node agent detects that the container status is CONTAINER_EXITED, it deletes the container and restarts a container with the same name and image.

[0034] When all containers fail, users can view the failure logs to locate the failure and find the cause of the failure.

[0035] In the method of the present invention, container fault handling actions are primarily accomplished through logging and user-attached fault handling actions. Container fault management is divided into fault management of the container engine and fault management of general container applications. Container fault management is primarily accomplished through two components: an application fault management component and an application fault collection component. The application management component is responsible for performing fault information acquisition and fault management actions for each container and exists in all containers (including the special container, the container engine). The application fault collection component is primarily used by the container engine to collect fault information that causes container status changes. This component then manages the container status based on the fault information, ensuring that when the node agent requests feedback from the container engine on the container status, the container engine can provide timely updated container status information.

[0036] When a fault occurs, the fault handling process is as follows:

[0037] 1. When the container is initialized, user-defined fault management actions are attached. Different faults can correspond to different actions (for fault types, refer to the basic fault types specified in 653);

[0038] 2. When a fault occurs, obtain the fault site information and call the container's fault injection interface to inject the fault. The fault site information includes: the file name, function name, code line number, and fault type where the fault occurred;

[0039] 3. Generate a log based on the injected fault scene information and record it in the specified location of the directory mounted on the container;

[0040] 4. After the log is generated, check the fault action table to see if there is an action enabled corresponding to the fault type (empty by default). If not, execute the corresponding action;

[0041] 5. If the fault management action affects the container status (such as stopping the container), the fault needs to be reported to the container engine. Containers communicate with each other through the socket interface.

[0042] 6. The application fault collection component in the container engine will start the container application fault collection task when the container engine is initialized, and will wait for the server to receive faults reported by the container application.

[0043] 7. Once the container application fault collection task receives a reported fault, it first processes the log and then modifies the application container status file so that the node agent can promptly detect the container status when sending a heartbeat request.

[0044] 8. Once the node agent detects that the container status is EXITED, it will delete the container and restart a container with the same name and image.

[0045] For example, the node agent and container engine of the node are run on the embedded platform based on the embedded real-time operating system. The container engine creates container application A. When container application A fails, the fault handling process is as follows: Figure 1 As shown, specifically:

[0046] 1. When container application A is initialized, a user-defined fault management action is attached. Fault management actions are implemented by creating a fault action table when the container is created. Different fault types correspond to different actions (fault types refer to the basic fault types specified in 653).

[0047] 2. When a data anomaly occurs, obtain the fault site information and call the container's fault injection interface to inject the fault. The fault site information includes: the file name, function name, code line number, and fault type where the fault occurred;

[0048] 3. Generate a log based on the injected fault scene information and record it in the specified location " / log" of the directory mounted on container A;

[0049] 4. After the log is generated, check the fault action table to see if the action corresponding to the data anomaly is enabled. Assume that the fault management action corresponding to the data anomaly is to stop and delete the container.

[0050] 5. Since the container state changes from CONTAINER_RUNNING to CONTAINER_EXITED, the fault is reported to the container engine through the socket interface;

[0051] 6. The container application fault collection task in the container engine, acting as the server, receives the fault reported by the container application.

[0052] 7. The container application fault collection task processes logs and changes the running status of container A in the application container status file to CONTAINER_EXITED;

[0053] 8. When the node agent finds that the container status is CONTAINER_EXITED, it deletes the container and restarts a container with the same name and image.

[0054] The above are only specific embodiments of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A fault management method for a container based on an embedded real-time operating system, applicable to an embedded real-time operating system using a container environment, wherein the container environment runs on the embedded real-time operating system, characterized in that: The method includes a container engine with a node management function and a container for running user applications, wherein the container for running user applications is used as an application container, and the fault management method includes: When a fault occurs in each container, the fault information is obtained and the fault management action corresponding to the fault information is executed. The fault management action is a user-defined hook. When a user-defined fault management action changes the state of a container, the corresponding fault is reported to the container engine, and the container engine and the container running the user application communicate through the Socket interface; The container application fault collection task in the container engine is used as the server side to wait for the faults reported by the container application. When the fault information is received, log processing is first performed, and then the status file of the application container is modified so that the external node agent can timely perceive the status of the application container when sending a heartbeat request. When the node agent perceives that the status of the application container is "CONTAINER_EXITED", the application container is deleted and the container engine is notified to restart a container with the same name and image; An application fault management component and an application fault collection component are used to perform fault management on all containers. The application fault management component is used to obtain, record, and perform fault management actions on all containers. The application fault collection component is used by the container engine to collect fault information that causes changes in the application container state, and to manage the container state based on the fault information, so that when the node agent requests the container engine to feedback the application container state, the updated application container state information is fed back. The workflow of the application fault management component includes: a) When all containers are initialized, a fault action table is created to map different faults to different fault handling actions. b) When a fault occurs, obtain fault site information and call the container's fault injection interface to inject the fault. The fault site information includes the file name, function name, code line number, and fault type where the fault occurred. c) generating a log based on the injected fault site information and recording it in a designated location within the container; d) After the log is generated, the fault action table is searched to determine whether an action corresponding to the fault type is enabled. If so, the corresponding action is executed, and the fault management action is determined to determine whether it changes the state of the container. If so, the fault is reported to the container engine; if not, the fault is not reported. If not, no additional action is performed.

2. The fault management method according to claim 1, characterized in that: The workflow of the application fault collection component, include, a) When the container engine is initialized, the container application fault collection task is started as a server to wait for faults reported by the container application; b) When the container application fault collection task receives a reported fault, it first processes the log and then modifies the status file of the application container so that the node agent can perceive the status of the application container in a timely manner when sending a heartbeat request.

3. The fault management method according to claim 2, characterized in that: The workflow of the application fault collection component also includes: When all containers fail, users can view the failure logs to locate the failure and find the cause of the failure.

Images