Container state recovery method and device, computer device, and storage medium

Abstract

The application relates to a container state recovery method and device, computer equipment, a storage medium and a software robot. The method comprises the following steps: detecting, in real time, a container state of a target container running in a business environment and resource usage of the business environment; when the container state is abnormal, accessing a pre-configured self-recovery environment in the business environment, and performing state self-recovery on the target container according to the resource usage; using state data of the target container to pull up a standby container corresponding to the target container in the self-recovery environment, and transferring traffic of the target container to the standby container for processing; continuously detecting the container state of the target container, and when the container state returns to normal, re-registering the target container in the business environment, and distributing traffic to the target container for processing. The method can intelligently realize self-recovery of a fault container while ensuring continuous traffic service, thereby reducing operation and maintenance labor costs and improving container state recovery efficiency.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology, and in particular to a method, apparatus, computer equipment, storage medium and software robot for restoring the state of a container. Background Technology

[0002] As companies across various industries advance their digital transformation, resources are increasingly pooled, and applications are increasingly cloud-based. Traditional IT operations and maintenance (O&M) models can no longer meet the demands of the scaled O&M growth brought about by digital transformation. Therefore, AIOps, an intelligent O&M technology powered by new technologies such as big data, cloud computing, and artificial intelligence, has emerged. AIOps, short for Artificial Intelligence for IT Operations, is a technology that combines artificial intelligence capabilities with O&M and uses machine learning methods to improve O&M efficiency.

[0003] Currently, enterprise operations and deployment teams can leverage AIOps technology to achieve semi-manual container status monitoring and operations: AIOps enables cloud deployment of microservices and real-time monitoring of microservice alarm status. Operations personnel then manually assess the health of microservice containers based on alarm status and intervene to handle faults. However, due to the large number of microservices, emergency handling of sudden failures still requires significant manpower. Summary of the Invention

[0004] Therefore, it is necessary to provide an intelligent method, device, computer equipment, computer-readable storage medium, and software robot for restoring the state of containers to address the aforementioned technical problems, thereby reducing the manpower costs of operation and maintenance.

[0005] Firstly, this application provides a method for restoring the state of a container, the method comprising:

[0006] Real-time monitoring of the container status of the target container running in the business environment, as well as the resource usage of the business environment;

[0007] When the container is in an abnormal state, a pre-configured self-healing environment is accessed in the business environment, and the target container is self-recovered according to the resource usage.

[0008] Using the status data of the target container, a backup container corresponding to the target container is launched in the self-healing environment, and the traffic of the target container is transferred to the backup container for processing;

[0009] The container status of the target container is continuously monitored. When the container status returns to normal, the target container is re-registered in the business environment, and the traffic is allocated to the target container for processing.

[0010] In one embodiment, when the container state is abnormal, accessing a pre-configured self-healing environment in the business environment and performing state self-recovery of the target container based on the resource usage includes:

[0011] When the container status is abnormal, the cause of the target container failure is determined based on the resource usage. The cause of failure includes any one or more of the following: insufficient host resources, insufficient container instances, network circuit breaker rate limiting, or abnormal service demand.

[0012] The target container is self-recovered based on the self-healing strategy corresponding to the cause of the failure stored in the self-healing environment.

[0013] In one embodiment, the step of using the state data of the target container to launch a backup container corresponding to the target container in the self-healing environment and transferring the traffic of the target container to the backup container for processing includes:

[0014] Using the state data of the target container, create image information corresponding to the target container;

[0015] Based on the image information, the backup container is launched in the self-healing environment, and the container resources in the self-healing environment are allocated to the backup container.

[0016] The traffic of the target container is divided using a preset service mesh strategy to obtain the traffic division result;

[0017] The traffic is transferred to the backup container, which instructs the backup container to allocate corresponding container resources to the traffic for processing according to the partitioning result.

[0018] In one embodiment, the method further includes:

[0019] Detect the load status of host resources in the business environment and the self-healing environment;

[0020] When there are idle host resources in the business environment, the corresponding idle host resources are configured in the self-healing environment.

[0021] When there are host resources in the self-healing environment that are overloaded, the corresponding overloaded host resources are separated from the self-healing environment.

[0022] In one embodiment, the method further includes:

[0023] When the container state returns to normal, the container resources in the self-healing environment are reclaimed.

[0024] In one embodiment, the method further includes:

[0025] When the container is in an abnormal state, in response to the triggering operation of the node switch, the processing node corresponding to the node switch is restarted in the business environment to perform state self-recovery of the target container.

[0026] Secondly, this application also provides a container state restoration device, comprising:

[0027] The monitoring module is used to detect the container status of the target container running in the business environment in real time, as well as the resource usage of the business environment.

[0028] The self-healing module is used to access a pre-configured self-healing environment in the business environment when the container is in an abnormal state, and to perform self-recovery of the target container's state according to the resource usage. It also uses the target container's state data to launch a backup container corresponding to the target container in the self-healing environment and transfers the traffic of the target container to the backup container for processing.

[0029] The recovery module is used to continuously monitor the container status of the target container. When the container status returns to normal, the target container is re-registered in the business environment, and the traffic is allocated to the target container for processing.

[0030] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the container state restoration method described in any of the embodiments of the first aspect.

[0031] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the container state restoration method described in any of the embodiments of the first aspect.

[0032] Fifthly, this application also provides a software robot. The software robot includes a computer program that, when executed by a processor, implements the container state restoration method described in any of the embodiments of the first aspect.

[0033] The aforementioned container state recovery method, apparatus, computer equipment, storage medium, and software robot monitor the container state of the target container running in the business environment in real time, as well as the resource usage of the business environment. When the container state is abnormal, a pre-configured self-healing environment is accessed in the business environment, and the target container's state is self-recovered based on resource usage. Using the target container's state data, a backup container corresponding to the target container is launched in the self-healing environment, and the traffic of the target container is transferred to the backup container for processing. The container state of the target container is continuously monitored, and when the container state returns to normal, the target container is re-registered in the business environment, and traffic is allocated to the target container for processing. This enables intelligent self-recovery of faulty containers while ensuring uninterrupted traffic services, thereby reducing maintenance manpower costs, improving container state recovery efficiency, and meeting the needs for 24 / 7 real-time container monitoring and anomaly self-healing. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is an application environment diagram of a container state recovery method in one embodiment;

[0036] Figure 2 This is a flowchart illustrating a method for restoring the state of a container in one embodiment;

[0037] Figure 3 This is a flowchart illustrating the traffic transfer steps in one embodiment;

[0038] Figure 4 This is a flowchart illustrating the dynamic scaling steps of host resources in one embodiment;

[0039] Figure 5 This is a flowchart illustrating a method for restoring the state of a container in another embodiment;

[0040] Figure 6 This is a structural block diagram of a container state restoration device 600 in one embodiment;

[0041] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0042] While cloud deployment of microservices provides a clear relational architecture for business products, it also creates significant pressure on production assurance. For example, due to the large number of microservices, most enterprises still require considerable manpower and time costs for continuous monitoring of the operational status of cloud-based microservices and for handling emergencies. Because different microservice architectures differ, it is difficult to develop unified solutions for common production resource-related problems within microservices. Furthermore, during off-peak hours, it is difficult to organize personnel for a timely response should an emergency occur in a microservice.

[0043] Therefore, to address the problems in the prior art, this application provides a method for restoring the state of a container. To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description, in conjunction with the accompanying drawings and embodiments, is provided. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0045] The container state recovery method provided in this application embodiment can be applied to, for example, Figure 1The application environment is shown. Terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. Specifically, server 104 can monitor the container status of the target container running in the business environment of terminal 102 in real time, as well as the resource usage of the business environment in terminal 102. When the container status of the target container is abnormal, a self-healing environment pre-configured by server 104 is accessed in the business environment of terminal 102, and the target container's status is self-recovered based on resource usage. Using the target container's status data, a backup container corresponding to the target container is launched in the self-healing environment, and the traffic of the target container is transferred to the backup container for processing. The container status of the target container in terminal 102 is continuously monitored. When it is determined that the target container's container status has returned to normal, the target container is re-registered in the business environment of terminal 102, and traffic is allocated to the target container for processing. The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle systems. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0046] In one exemplary embodiment, such as Figure 2 As shown, a method for restoring the state of a container is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps S202 to S208. Wherein:

[0047] Step S202: Real-time detection of the container status of the target container running in the business environment, as well as the resource usage of the business environment.

[0048] The target container can be used to represent a software package that provides the complete runtime environment required to run microservices. It can store, but is not limited to, the application code, configuration files, libraries, and dependencies required for the microservices to run.

[0049] Resource usage information can be used to identify the usage of central processing unit (CPU) resources, memory resources, network resources, etc. in the business environment.

[0050] For example, servers can use continuous service mesh health probing to detect the container status of target containers running in the business environment in real time. Collectors (such as Exporten) are used to gather resource usage information for host physical resources, network resources, and other resources that need to be monitored in the business environment, and this information is stored in an open-source system monitoring and alerting system (such as Prometheus) according to the collection time.

[0051] Step S204: When the container state is abnormal, access the pre-configured self-healing environment in the business environment, and perform self-recovery of the target container state according to the resource usage.

[0052] For example, an alarm module (such as AlertManager) can be deployed on the server. Upon receiving alarm information from an open-source system monitoring and alarm system (i.e., abnormal resource usage, such as resource usage fluctuating significantly within a short period, or resource usage falling below or exceeding a preset threshold), the alarm module determines that the target container's container state is abnormal. When the target container's container state is abnormal, a pre-configured self-healing environment based on a cloud-native architecture (cloud-based application architecture) is accessed in the business environment. Based on resource usage, corresponding policies (such as restart policies, re-registration policies, etc.) are executed to self-recover the target container's state.

[0053] Step S206: Using the state data of the target container, start up the backup container corresponding to the target container in the self-healing environment, and transfer the traffic of the target container to the backup container for processing.

[0054] The status data may include, but is not limited to, any one or more of the following: traffic allocation, canary deployment strategy, environment variables, service version, related dependencies, configuration, etc.

[0055] For example, the server can persistently store the target container's state data during real-time monitoring of the target container. Using this state data, a backup container corresponding to the target container is launched in a self-healing environment; that is, the backup container's state data is identical to the target container's. Traffic destined for the target container in the business environment is then transferred to the currently launched backup container for processing.

[0056] Step S208: Continuously monitor the container status of the target container. When the container status returns to normal, re-register the target container in the business environment and allocate traffic to the target container for processing.

[0057] For example, the server can refer to the operation in step S202 to continuously monitor the container status of the target container. When it is determined that the container status has returned to normal, the target container is re-registered in the network topology of the business environment to resume operation of the target container in the business environment. The traffic transferred to the standby container in step S206 is then redistributed to the target container for processing.

[0058] The above-mentioned container state recovery method involves real-time monitoring of the target container's state and resource usage in the business environment. When a container's state is abnormal, a pre-configured self-healing environment is accessed in the business environment, and the target container's state is self-recovered based on resource usage. The target container's state data is used to launch a backup container corresponding to the target container in the self-healing environment, and the traffic of the target container is transferred to the backup container for processing. The target container's state is continuously monitored, and when the container's state returns to normal, the target container is re-registered in the business environment, and traffic is allocated to the target container for processing. This method intelligently achieves self-recovery of faulty containers while ensuring uninterrupted traffic services, thereby reducing maintenance manpower costs, improving container state recovery efficiency, and meeting the needs for 24 / 7 real-time container monitoring and anomaly self-healing.

[0059] In an exemplary embodiment, step S204, when the container state is abnormal, accesses a pre-configured self-healing environment in the business environment and performs state self-recovery of the target container according to resource usage, including: when the container state is abnormal, determining the cause of the target container's failure according to resource usage, the cause of failure includes any one or more of insufficient host resources, insufficient container instances, network circuit breaker rate limiting, or abnormal service demand; and performing state self-recovery of the target container according to the self-healing policy corresponding to the cause of failure stored in the self-healing environment.

[0060] For example, the server can pre-store alarm judgment policies derived from the correlation analysis of a large amount of container status telemetry data and container operation and maintenance log data acquired in the early data collection phase based on AIOps technology. When the real-time detected container status of the target container or the resource usage of the business environment meets the alarm judgment policy, the container status is determined to be abnormal. Based on the real-time resource usage matching the content of the alarm judgment policy, the cause of the current target container failure is determined.

[0061] Optionally, in some implementations, when the usage of host physical resources is less than the amount of data in the traffic sent to the target container, the cause of the current target container failure can be determined to be insufficient host resources. When the usage of host memory resources is less than the number of instances required to process the traffic, the cause of the current target container failure can be determined to be insufficient container instances. When the usage of host network resources exceeds a preset threshold, the cause of the current target container failure can be determined to be network circuit breaking and rate limiting. When resource usage does not meet the service demand threshold (which can be determined based on the extended service requirements that the microservice itself needs to develop), the cause of the current target container failure can be determined to be abnormal service demand.

[0062] In a stable self-healing environment, the target container's state is self-recovered using a self-healing strategy stored in the environment that corresponds to the cause of the current target container's failure. Optionally, in some implementations, when the failure cause is insufficient host resources, the corresponding self-healing strategy may be to incorporate currently available host resources in real time. When the failure cause is insufficient container instances, the corresponding self-healing strategy may be to deploy new instances. When the failure cause is network circuit breaker / rate limiting, the corresponding self-healing strategy may be to restart the network connection. When the failure cause is abnormal service demand, the corresponding self-healing strategy may be to redeploy container nodes.

[0063] In this embodiment, by determining the cause of the target container's failure, a self-healing strategy corresponding to the cause of the failure is adopted to restore the target container's state. Compared with the semi-manual container state detection and maintenance methods of the traditional operation and maintenance team, which rely on the alarm status of microservices to manually determine the health status of microservice containers and manually intervene to handle failures, this not only greatly improves the self-recovery efficiency of the target container, but also enables flexible expansion of the target container's self-healing scenario. It is not only applicable to container self-healing scenarios with insufficient host resources, insufficient container instances, network circuit breaking and rate limiting, etc., but also applicable to open self-healing scenarios after accessing different cloud microservices.

[0064] In one exemplary embodiment, such as Figure 3 As shown, step S206, which utilizes the target container's status data to launch a backup container corresponding to the target container in a self-healing environment and transfers the traffic of the target container to the backup container for processing, may include the following steps S302 to S308. Wherein:

[0065] Step S302: Using the state data of the target container, create image information corresponding to the target container.

[0066] Optionally, in some implementations, the server can create the image information corresponding to the target container by replication on a node within the same region as the target container, or on a node outside the same region as the target container.

[0067] Step S304: Launch the standby container in the self-healing environment according to the image information, and allocate the container resources in the self-healing environment to the standby container.

[0068] Container resources can include, but are not limited to, any one or more of the following: central processing unit resources (i.e., CPU resources), memory resources, disk resources, etc.

[0069] For example, the server can use image information to launch a backup container in a self-healing environment. That is, the image information is used to configure the backup container's traffic allocation, canary deployment strategy, environment variables, service version, related dependencies, configuration and other status parameters so that the backup container can provide the same functional services as the failed target container. Container resources in the self-healing environment are then allocated to the backup container.

[0070] Step S306: The traffic of the target container is divided using a preset service mesh strategy to obtain the traffic division result.

[0071] Step S308: Transfer the traffic to the standby container to instruct the standby container to allocate the corresponding container resources to the traffic for processing according to the partitioning result.

[0072] Service mesh policies, or policies applied to the service mesh, define the distribution paths for traffic requests. A service mesh is an infrastructure layer that transparently manages and controls communication between services, reliably delivering requests across complex service topologies containing modern cloud-native applications. Service meshes are typically implemented using a set of lightweight network proxies deployed alongside the application code, without needing to be aware of the application itself.

[0073] For example, the server may store a preset service mesh policy. Using the preset service mesh policy and the microservices that the target container's traffic needs to invoke, the distribution path of the target container's traffic within the service topology is determined. Based on the different distribution paths, the target container's traffic is divided, resulting in traffic partitioning. The target container's traffic is then transferred to a backup container, instructing the backup container to allocate its available container resources to different traffic streams for processing according to the traffic partitioning results.

[0074] In this embodiment, by using the state data of the target container to create image information corresponding to the target container, and launching a backup container identical to the target container in a self-healing environment based on the image information, the traffic of the target container is divided using a preset service mesh strategy, and the traffic of the target container is transferred to the backup container for processing. This instructs the backup container to allocate corresponding container resources to different traffic based on the traffic division results, thereby ensuring that the traffic request service is processed continuously without interruption, and providing the relevant product teams with sufficient time to troubleshoot and repair the target container.

[0075] In one exemplary embodiment, such as Figure 4 As shown, the container state restoration method provided in this application may further include steps S402 to S406. Wherein:

[0076] Step S402: Detect the load status of host resources in the business environment and self-healing environment.

[0077] For example, servers can utilize the host scheduling capabilities of cloud-native architectures to monitor in real-time any one or more of the following load parameters of host resources in both business and self-healing environments: CPU processing power, CPU utilization, CPU ready queue length, available disk and memory space, and process response time. Based on a comparison of these load parameters with preset thresholds, the load status of the host resources is determined. For instance, if multiple load parameters exceed the preset thresholds, the load status is determined to be overloaded. If all load parameters are below the preset thresholds, the load status is determined to be idle.

[0078] Step S404: When there are idle host resources in the business environment, configure the corresponding idle host resources in the self-healing environment.

[0079] For example, when the server determines that there are idle host resources in the business environment, the corresponding idle host resources in the business environment can be configured in the self-healing environment so that the standby container in the self-healing environment can use the idle host resources to process traffic requests.

[0080] Step S406: When there are host resources in the self-healing environment that are overloaded, the corresponding overloaded host resources are separated from the self-healing environment.

[0081] For example, when the server determines that there are host resources in the self-healing environment that are overloaded, it can separate the corresponding overloaded host resources from the self-healing environment so that the traffic requests that the backup container needs to process will not be distributed to the overloaded host resources for processing.

[0082] In this embodiment, by utilizing the host scheduling capabilities of cloud-native architecture, idle host resources in the business environment are incorporated into the self-healing environment, and overloaded host resources in the self-healing environment are released. This improves the utilization rate of self-healing environment resources, enables dynamic expansion and contraction of self-healing environment resources, and ensures efficient utilization of self-healing environment resources and continuous stability of the self-healing environment.

[0083] In an exemplary embodiment, the container state recovery method provided in this application may further include: when the container state returns to normal, reclaiming container resources in the self-healing environment.

[0084] For example, when the server detects that the container state of the target container has returned to normal, it can reclaim the container resources in the self-healing environment to release the spare container, thereby ensuring the continuous availability of resources in the self-healing environment.

[0085] In an exemplary embodiment, the container state recovery method provided in this application may further include: when the container state is abnormal, in response to the triggering operation of the node switch, restarting the processing node corresponding to the node switch in the business environment to perform state self-recovery of the target container.

[0086] For example, node switches can be configured on the management or runtime nodes associated with containers in the service topology. When the server detects an abnormal container status of the target container, it can prompt business personnel whether interventional self-healing is required. In response to the business personnel's triggering operation on the node switch corresponding to the target container, the processing node corresponding to the node switch (i.e., the container's management or runtime node mentioned above) is restarted in the business environment to perform state self-recovery operations such as restarting, re-registering, or reconnecting the target container, thereby achieving manual compensation for the target container.

[0087] Optionally, in some implementations, the container state recovery method provided in this application may further include: pushing the container state of the target container and the resource usage of the business environment to the client and displaying them in the client's visualization interface.

[0088] For example, the server can send the real-time detected container status of the target container and the resource usage of the business environment to the client via message push, and display the container status of the target container and the resource usage requests of the business environment in the client's visual interface.

[0089] When the target container's container status returns to normal, the target container's self-healing operation record can also be sent to the client via message push to provide business personnel with the ability to trace the target container's self-healing history.

[0090] In this embodiment, real-time message push can improve the observability of the target container's self-healing recovery.

[0091] In existing technologies, microservices (i.e., containers as described in this application) at the PaaS (Platform as a Service) layer in the cloud computing field are prone to failure and business interruption due to insufficient external resources (such as CPU resources / memory resources / network resources).

[0092] Therefore, the following embodiments provide a method for restoring container state in scenarios involving business continuity assurance and state self-recovery of microservices on a PaaS (Platform as a Service) platform, as well as an intelligent self-healing platform that implements this recovery method. The intelligent self-healing platform can consist of an access layer, a monitoring layer, a self-healing layer, and a recovery layer developed based on a cloud-native architecture, forming a complete closed loop for container-level monitoring of the PaaS platform, ensuring continuous high availability of containers except for non-business failures.

[0093] In this embodiment, as Figure 5 As shown, a method for restoring the state of a container is also provided, including the following steps S502 to S508. Wherein:

[0094] Step S502: Real-time detection of the container status of the target container running in the business environment, as well as the resource usage of the business environment.

[0095] For example, servers can easily, conveniently, and autonomously connect target containers in the business environment to the intelligent self-healing platform through its access layer, without requiring any modification to the original target containers. The intelligent self-healing platform's monitoring layer performs continuous service mesh monitoring and liveness detection on the target containers. The monitoring layer's exporter monitors the status of host physical and network resources in the business environment, and stores the collected resource usage data in the open-source system monitoring and alerting system (Prometheus).

[0096] Step S504: When the container state is abnormal, access the pre-configured self-healing environment in the business environment, and use the self-healing strategy stored in the self-healing environment to restore the state of the target container according to the cause of the failure corresponding to the resource usage.

[0097] For example, when resource usage triggers a rule in the open-source system monitoring and alerting system (Prometheus), Prometheus sends the resource usage information to the AlertManager in the monitoring layer via an alert message push. The AlertManager then evaluates the received alert message to formulate a comprehensive monitoring strategy for the target container.

[0098] When the AlertManager module in the monitoring layer determines that the target container's state is abnormal, a pre-configured self-healing environment can be accessed in the business environment through a self-healing layer built on top of the monitoring layer. Based on the fault cause corresponding to resource usage determined by the AlertManager module, the target container's state is self-recovered using the self-healing strategy stored in the self-healing environment that corresponds to the fault cause.

[0099] Step S506: In the self-healing environment, start the backup container corresponding to the target container, divide the traffic of the target container using the preset service mesh strategy, and transfer the traffic to the backup container for processing.

[0100] For example, the server can use a self-healing layer to create image information using the target container's state data (such as traffic allocation, canary deployment strategies, environment variables, service versions, related dependencies, configurations, etc.). Using this image information, a backup container corresponding to the target container is launched in the self-healing environment, and container resources in the self-healing environment are allocated to the backup container. A preset service mesh strategy is used to partition the traffic of the target container and transfer that traffic to the backup container for processing, instructing the backup container to allocate corresponding container resources to different traffic flows according to the traffic partitioning results.

[0101] Step S508: Continuously monitor the container status of the target container. When the container status returns to normal, reclaim the container resources in the self-healing environment, re-register the target container in the business environment, and allocate traffic to the target container for processing.

[0102] For example, the server can continuously monitor the container status of the target container through the monitoring layer. When it determines that the target container's container status has returned to normal, it pushes a message indicating that the target container has recovered from the fault to the self-healing layer and the recovery layer built on top of the self-healing layer and the monitoring layer. The self-healing layer reclaims container resources in the self-healing environment. The recovery layer re-registers the target container in the business environment to restore its operation in the business environment and reallocates traffic back to the recovered target container.

[0103] In this embodiment, a cloud-native architecture-based intelligent self-healing platform provides a comprehensive self-healing service for target containers in the business environment, encompassing four processes: "access," "monitoring," "self-healing," and "recovery." This service enables real-time monitoring of the overall operation of the target container using methods such as container status detection, host physical resource status monitoring, and host network resource monitoring, without requiring modifications to the existing microservices. Furthermore, when a target container fails, a backup container in the same state is launched in a stable self-healing environment. This ensures the continuity of business processing for traffic requests in the business environment, providing sufficient time for repairing business-related faults in the target container, or enabling self-recovery from non-business-related faults.

[0104] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0105] Based on the same inventive concept, this application also provides a container state restoration apparatus for implementing the container state restoration method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the container state restoration apparatus provided below can be found in the limitations of the container state restoration method described above, and will not be repeated here.

[0106] In one exemplary embodiment, such as Figure 6 As shown, a container state recovery device 600 is provided, including: a monitoring module 602, a self-healing module 604, and a recovery module 606, wherein:

[0107] The monitoring module 602 is used to detect the container status of the target container running in the business environment and the resource usage of the business environment in real time.

[0108] The self-healing module 604 is used to access a pre-configured self-healing environment in the business environment when the container is in an abnormal state, and to perform self-recovery of the target container's state based on resource usage. It uses the target container's state data to start up a backup container corresponding to the target container in the self-healing environment and transfers the traffic of the target container to the backup container for processing.

[0109] Recovery module 606 is used to continuously monitor the container status of the target container. When the container status returns to normal, the target container is re-registered in the business environment and traffic is allocated to the target container for processing.

[0110] In an exemplary embodiment, the self-healing module 604 is further configured to determine the cause of failure of the target container based on resource usage when the container state is abnormal. The cause of failure may include any one or more of the following: insufficient host resources, insufficient container instances, network circuit breaker rate limiting, or abnormal service demand; and perform state self-recovery of the target container according to the self-healing strategy corresponding to the cause of failure stored in the self-healing environment.

[0111] In an exemplary embodiment, the self-healing module 604 is further configured to: utilize the state data of the target container to create image information corresponding to the target container; launch a standby container in the self-healing environment according to the image information and allocate container resources in the self-healing environment to the standby container; divide the traffic of the target container using a preset service mesh strategy to obtain the traffic division result; and transfer the traffic to the standby container to instruct the standby container to allocate corresponding container resources to the traffic for processing according to the division result.

[0112] In an exemplary embodiment, the container state recovery device 600 further includes: a dynamic scaling module, used to detect the load status of host resources in the business environment and the self-healing environment; when there are idle host resources in the business environment, the corresponding idle host resources are configured in the self-healing environment; when there are overloaded host resources in the self-healing environment, the corresponding overloaded host resources are separated from the self-healing environment.

[0113] In one exemplary embodiment, the recovery module 606 is further configured to reclaim container resources in the self-healing environment when the container state returns to normal.

[0114] In an exemplary embodiment, the container state recovery device 600 further includes an intervention self-healing module, which, in response to a triggering operation on a node switch, restarts the processing node corresponding to the node switch in the business environment when the container state is abnormal, so as to perform state self-recovery of the target container.

[0115] Each module in the aforementioned container state restoration device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0116] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs in the non-volatile storage media to run. The database stores data such as the container state of the target container, resource usage of the business environment, configuration information of the self-healing environment, and the status data of the target container. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for restoring the state of a container.

[0117] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0118] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0119] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0120] In one exemplary embodiment, a software robot is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0121] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0122] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0123] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for restoring the state of a container, characterized in that, The method includes: Real-time monitoring of the container status of the target container running in the terminal's business environment, as well as the resource usage of the business environment; When the container is in an abnormal state, the self-healing environment pre-configured by the server is accessed in the business environment, and the cause of the failure of the target container is determined according to the resource usage. The cause of failure includes any one or more of the following: insufficient host resources, insufficient container instances, network circuit breaker rate limiting, or abnormal service demand. The target container is self-recovered according to the self-healing strategy stored in the self-healing environment corresponding to the cause of failure. Using the state data of the target container, create image information corresponding to the target container, launch a backup container corresponding to the target container in the self-healing environment according to the image information, allocate container resources in the self-healing environment to the backup container, and transfer the traffic of the target container to the backup container for processing. The container status of the target container is continuously monitored. When the container status returns to normal, the target container is re-registered in the business environment, and the traffic is allocated to the target container for processing. The container resources in the self-healing environment are reclaimed. Detect the load status of host resources in the business environment and the self-healing environment; When there are idle host resources in the business environment, the corresponding idle host resources are configured in the self-healing environment. When there are host resources in the self-healing environment that are overloaded, the corresponding overloaded host resources are separated from the self-healing environment.

2. The method according to claim 1, characterized in that, The process of transferring the traffic from the target container to the backup container includes: The traffic of the target container is divided using a preset service mesh strategy to obtain the traffic division result; The traffic is transferred to the backup container, which instructs the backup container to allocate corresponding container resources to the traffic for processing according to the partitioning result.

3. The method according to any one of claims 1 to 2, characterized in that, The method further includes: When the container is in an abnormal state, in response to the triggering operation of the node switch, the processing node corresponding to the node switch is restarted in the business environment to perform state self-recovery of the target container.

4. A device for restoring the state of a container, characterized in that, The device includes: The monitoring module is used to detect in real time the container status of the target container running in the terminal's business environment, as well as the resource usage of the business environment; The self-healing module is used to access a pre-configured self-healing environment on the server in the business environment when the container is in an abnormal state. It determines the cause of the target container's failure based on the resource usage. The cause of failure includes any one or more of the following: insufficient host resources, insufficient container instances, network circuit breaker rate limiting, or abnormal service demand. Based on the self-healing policy stored in the self-healing environment corresponding to the cause of failure, it performs self-recovery of the target container's state. Using the state data of the target container, it creates image information corresponding to the target container. Based on the image information, it launches a backup container corresponding to the target container in the self-healing environment, allocates the container resources in the self-healing environment to the backup container, and transfers the traffic of the target container to the backup container for processing. The recovery module is used to continuously monitor the container status of the target container. When the container status returns to normal, the target container is re-registered in the business environment, the traffic is allocated to the target container for processing, and the container resources in the self-healing environment are reclaimed. The dynamic scaling module is used to detect the load status of host resources in the business environment and the self-healing environment; when there are idle host resources in the business environment, the corresponding idle host resources are configured in the self-healing environment; when there are overloaded host resources in the self-healing environment, the corresponding overloaded host resources are separated from the self-healing environment.

5. The apparatus according to claim 4, characterized in that, The self-healing module is further configured to divide the traffic of the target container using a preset service mesh strategy to obtain the traffic division result; and transfer the traffic to the backup container to instruct the backup container to allocate corresponding container resources to the traffic for processing according to the division result.

6. The apparatus according to claim 4 or 5, characterized in that, The device further includes: The self-healing module is used to restart the processing node corresponding to the node switch in the business environment in response to the triggering operation of the node switch when the container state is abnormal, so as to perform state self-recovery of the target container.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 3.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 3.

Images