Container fault recovery method, device and electronic equipment

Abstract

The present invention discloses a container fault recovery method, device, and electronic device. Relating to the field of cloud computing technology or other related fields, the method comprises: inspecting a container to be diagnosed based on a fault diagnosis container to obtain inspection data; analyzing the inspection data using a fault diagnosis tool within the fault diagnosis container to obtain a diagnosis result; when the diagnosis result indicates an abnormality in the container to be diagnosed, determining a target recovery strategy corresponding to the diagnosis result; and performing fault recovery on the container to be diagnosed based on the target recovery strategy. This invention addresses the technical problems of the prior art, such as the inability to achieve automatic recovery of container faults and the low troubleshooting efficiency.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology or other related fields, and in particular to a container fault recovery method, device, and electronic device. Background Art

[0002] With the continued advancement and implementation of cloud native, containerizing applications and deploying them within containers has become a common technology approach. The core concept of container technology is a single container, single application, and lightweight design. Therefore, when building container images, they must be streamlined, installing only the components necessary for application runtime. While streamlined images offer the advantage of lightweight design, they also create difficulties in diagnosing container failures.

[0003] Conventional methods for diagnosing faulty containers utilize command-line tools provided by Docker or the Kubernetes container orchestration tool to access the faulty container and perform fault diagnosis. However, due to the simplicity of container images, many common fault diagnosis tools, such as iftop, drill, and tcpdump, are not included. This significantly complicates troubleshooting faulty containers. Furthermore, due to the isolation inherent in container technology, troubleshooting on the host machine is also difficult. Furthermore, repeated container restarts can make access to the container unstable or impossible for troubleshooting.

[0004] In addition, in the existing technology, the automatic recovery of faulty containers is achieved by checking and restarting the container through the default health check probe inside the container. However, when the container has abnormalities such as CPU / memory usage and parameter configuration, it is impossible to achieve the fully automatic operation and maintenance capabilities of the container application from fault inspection, fault diagnosis to fault recovery.

[0005] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0006] Embodiments of the present invention provide a container fault recovery method, device, and electronic device to at least solve the technical problems in the prior art of being unable to achieve automatic recovery of container faults and having low troubleshooting efficiency.

[0007] According to one aspect of an embodiment of the present invention, a method for fault recovery of a container is provided, comprising: inspecting a container to be diagnosed based on a fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that includes an operating environment when an application is running, and there is a binding relationship between the fault diagnosis container and the container to be diagnosed, and the fault diagnosis container is a container created based on a fault diagnosis container image, and the fault diagnosis container image includes a fault diagnosis tool for detecting faults of the container to be diagnosed and inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic; analyzing the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnostic result; when the diagnostic result indicates that the container to be diagnosed is abnormal, determining a target recovery strategy corresponding to the diagnostic result; and performing fault recovery on the container to be diagnosed based on the target recovery strategy.

[0008] Furthermore, before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining the inspection data, the method also includes: receiving a container diagnosis request; responding to the container diagnosis request, querying the interface of the container cluster corresponding to the target application, and determining whether there is a container to be diagnosed in the container cluster, wherein the container cluster is composed of multiple containers and at least one container corresponds to a node; if there is a container to be diagnosed in the container cluster, obtaining the node information of the node where the container to be diagnosed is located.

[0009] Furthermore, after obtaining the node information of the node where the container to be diagnosed is located, the method also includes: creating a diagnostic tool server based on the node information, wherein the diagnostic tool server is located in the node where the container to be diagnosed is located, and the diagnostic tool server is used to create a fault diagnosis container; detecting whether the creation time of the diagnostic tool server is less than the preset time; if the creation time is less than the preset time, establishing a long connection between the diagnostic tool server and the diagnostic tool client, wherein the diagnostic tool client is a client that receives the container diagnosis request.

[0010] Furthermore, before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining inspection data, the method also includes: detecting whether the current time is within a preset time period; if the current time is within the preset time period, triggering a fault inspection instruction; executing the fault inspection instruction to inspect the container to be diagnosed.

[0011] Furthermore, after performing fault recovery on the container to be diagnosed based on the target recovery strategy, the method also includes: triggering a container diagnosis termination instruction; executing the container diagnosis termination instruction, clearing the fault diagnosis container, and sending a reminder message to the diagnostic tool client that the fault diagnosis container has been cleared; and controlling the diagnostic tool client to clear the diagnostic tool server based on the reminder message.

[0012] Furthermore, before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining inspection data, the method also includes: detecting whether the fault diagnosis container is successfully bound to the container to be diagnosed; when the fault diagnosis container fails to bind to the container to be diagnosed, copying the container to be diagnosed; obtaining a resource description file of the storage set where the container to be diagnosed is located, wherein the storage set contains at least one container to be diagnosed; obtaining a label field of the container to be diagnosed based on the resource description file; deleting the label field and the inspection probe of the container to be diagnosed, and modifying the startup command of the container to be diagnosed in the resource description file to create a new container to be diagnosed, wherein the inspection probe is used to perform fault diagnosis on the container to be diagnosed; and performing fault inspection, fault diagnosis, and fault recovery on the new container to be diagnosed.

[0013] Furthermore, fault recovery is performed on the container to be diagnosed based on the target recovery strategy, including: detecting whether the memory usage of the container to be diagnosed is within a preset range; if the memory usage of the container to be diagnosed is outside the preset range, switching the container to be diagnosed to a spare application container.

[0014] Furthermore, fault recovery is performed on the container to be diagnosed based on the target recovery strategy, including: detecting whether the configuration parameters of the container to be diagnosed are default parameters; if the configuration parameters of the container to be diagnosed are not default parameters, restoring the configuration parameters to default parameters.

[0015] Furthermore, the container to be diagnosed is recovered based on the target recovery strategy, including restarting the container to be diagnosed.

[0016] According to another aspect of an embodiment of the present invention, a fault recovery device for a container is also provided, including: an inspection module, which is used to inspect the container to be diagnosed based on the fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that includes the operating environment when the application is running, and there is a binding relationship between the fault diagnosis container and the container to be diagnosed, and the fault diagnosis container is a container created based on the fault diagnosis container image, and the fault diagnosis container image includes a fault diagnosis tool for detecting faults of the container to be diagnosed and an inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic; a diagnosis module, which is used to analyze the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result; a determination module, which is used to determine a target recovery strategy corresponding to the diagnosis result when the diagnosis result indicates that the container to be diagnosed has an abnormality; and a recovery module, which is used to perform fault recovery on the container to be diagnosed based on the target recovery strategy.

[0017] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the above-mentioned container failure recovery method when running.

[0018] According to another aspect of an embodiment of the present invention, an electronic device is further provided, comprising one or more processors; a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are enabled to run the programs, wherein the programs are configured to execute the above-mentioned container failure recovery method during runtime.

[0019] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program / instruction, which implements the above-mentioned container failure recovery method when the computer program / instruction is executed by a processor.

[0020] In an embodiment of the present invention, a fault diagnosis container is used to inspect a container to be diagnosed to obtain inspection data, and then the inspection data is analyzed according to a fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result; when the diagnosis result indicates that the container to be diagnosed has an abnormality, a target recovery strategy corresponding to the diagnosis result is determined; finally, the container to be diagnosed is recovered based on the target recovery strategy, wherein the container to be diagnosed is a process that includes an operating environment when an application is running, and there is a binding relationship between the fault diagnosis container and the container to be diagnosed, and the fault diagnosis container is a container created based on a fault diagnosis container image, and the fault diagnosis container image includes a fault diagnosis tool for detecting faults in the container to be diagnosed and an inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic.

[0021] In the above process, first, the fault diagnosis container is used to perform fault inspection and fault diagnosis on the container to be diagnosed. The fault diagnosis container is a container created based on the fault diagnosis tools and inspection logic included in the fault diagnosis container image. It can be seen that the fault diagnosis container created by the customized diagnostic tools and inspection logic in the fault diagnosis container image greatly enriches the means of container troubleshooting and improves the efficiency of container troubleshooting; secondly, when there is an abnormality in the container to be diagnosed, by determining the target recovery strategy corresponding to the diagnosis result, the container to be diagnosed automatically recovers the fault based on the target recovery strategy. Therefore, the fully automatic operation and maintenance capability of the container application from fault inspection, fault diagnosis to fault recovery is realized.

[0022] It can be seen that the solution provided by this application achieves the purpose of automatically recovering container faults based on fault diagnosis containers, thereby realizing the technical effect of fully automatic operation and maintenance capabilities of container applications from fault inspection, fault diagnosis to fault recovery, improving the efficiency of container troubleshooting, and thus solving the technical problems in the existing technology that cannot achieve automatic recovery of container faults and low troubleshooting efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0024] Figure 1 is a schematic diagram of an optional container failure recovery method according to an embodiment of the present invention;

[0025] Figure 2 is a schematic diagram of an optional container failure recovery method according to an embodiment of the present invention;

[0026] Figure 3 A schematic diagram of an optional container failure recovery method according to an embodiment of the present invention;

[0027] Figure 4 A schematic diagram of an optional container fault recovery device according to an embodiment of the present invention;

[0028] Figure 5 A schematic diagram of an optional electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display and analysis, etc.) involved in the present invention are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set up between this system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain the relevant information after receiving the consent information fed back by the aforementioned user or organization.

[0032] Example 1

[0033] According to an embodiment of the present invention, an embodiment of a container fault recovery method is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Moreover, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown.

[0034] Figure 1 FIG. 1 is a schematic diagram of a container failure recovery method according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0035] Step S101: perform an inspection on the container to be diagnosed based on the fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that includes the operating environment when the application is running. There is a binding relationship between the fault diagnosis container and the container to be diagnosed. The fault diagnosis container is a container created based on the fault diagnosis container image. The fault diagnosis container image includes a fault diagnosis tool for detecting faults in the container to be diagnosed and an inspection logic for inspecting the container to be diagnosed. Different fault diagnosis container images correspond to different diagnostic tools and inspection logic.

[0036] In step S101, the fault diagnosis container of the system, server, electronic device, etc. can be used to inspect the container to be diagnosed to obtain inspection data. In this embodiment, the system fault diagnosis container can be used to inspect the container to be diagnosed to obtain inspection data.

[0037] Optionally, the container to be diagnosed includes the process of the operating environment when the application is running, and the system can specify the container to be diagnosed based on the container diagnosis request; optionally, the fault diagnosis container is a container created by the system based on the fault diagnosis container image, which can perform fault inspection and fault diagnosis on the container to be diagnosed. The system adds the fault diagnosis container to the container to be diagnosed and establishes a connection with the fault diagnosis container. Based on the inspection logic in the fault diagnosis container, the container to be diagnosed is inspected for faults and inspection data is obtained.

[0038] Optionally, the inspection data can include the container's CPU / memory usage, disk read / write rate, parameter configuration, service interface availability, and other data.

[0039] Optionally, the fault diagnosis container image includes a fault diagnosis tool for detecting faults in the container to be diagnosed and inspection logic for inspecting the container to be diagnosed. Different fault diagnosis container images can be created according to different user needs. Different fault diagnosis container images correspond to different diagnostic tools and inspection logic, such as network troubleshooting tool images, disk IO troubleshooting tool images, etc. The created fault diagnosis container image can be stored in the container image tool library. When the diagnostic tool server creates a fault diagnosis container based on a diagnostic request, it can obtain the target fault diagnosis container image from the container image tool library.

[0040] It should be noted that by inspecting the container to be diagnosed through the fault diagnosis container and obtaining inspection data, different container fault inspections can be performed according to different user needs. In addition, the customized diagnostic tools and inspection logic in the diagnostic container image greatly enrich the means of container troubleshooting and improve the efficiency of container troubleshooting.

[0041] Step S102 : analyzing the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result.

[0042] In step S102, the system analyzes the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain at least one diagnostic result, such as sequentially analyzing the CPU / memory usage and disk read / write rate of the container. When the CPU / memory usage of the container is greater than the preset range, it is determined that the container has a fault. At this time, the system stops data analysis, matches the target recovery strategy based on the CPU / memory usage fault of the container, and performs fault recovery. The system can also simultaneously analyze the CPU / memory usage and disk read / write rate of the container. When the CPU / memory usage and disk read / write rate of the container are both greater than the preset range, it is determined that the container has a fault, matches the target recovery strategy based on the CPU / memory usage and disk read / write rate of the container, and performs fault recovery.

[0043] It should be noted that by analyzing the inspection data through the fault diagnosis tool in the fault diagnosis container, the fault in the container can be diagnosed and at least one diagnosis result can be obtained, thereby improving the efficiency of fault diagnosis.

[0044] Step S103 : When the diagnosis result indicates that the container to be diagnosed is abnormal, a target recovery strategy corresponding to the diagnosis result is determined.

[0045] Step S104: Perform fault recovery on the container to be diagnosed based on the target recovery strategy.

[0046] In steps S103-S104, the system matches at least one target recovery strategy for the container to be diagnosed based on the preset diagnosis results and corresponding recovery strategies, and performs fault recovery on the container to be diagnosed based on the target recovery strategy.

[0047] Optionally, the target recovery strategy includes: switching traffic, restarting containers, restoring configurations, and other operations.

[0048] Based on the scheme defined in the above steps S101 to S104, it can be learned that the container to be diagnosed is inspected through a fault diagnosis container to obtain inspection data, and then the inspection data is analyzed according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result; when the diagnosis result indicates that there is an abnormality in the container to be diagnosed, the target recovery strategy corresponding to the diagnosis result is determined; finally, the container to be diagnosed is recovered based on the target recovery strategy, wherein the container to be diagnosed is a process that includes the operating environment when the application is running, and there is a binding relationship between the fault diagnosis container and the container to be diagnosed, and the fault diagnosis container is a container created based on the fault diagnosis container image, and the fault diagnosis container image includes a fault diagnosis tool for detecting faults in the container to be diagnosed and an inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic.

[0049] It is easy to notice that in the above process, first, the fault diagnosis container is used to perform fault inspection and fault diagnosis on the container to be diagnosed. The fault diagnosis container is a container created based on the fault diagnosis tools and inspection logic included in the fault diagnosis container image. It can be seen that the fault diagnosis container created by the customized diagnostic tools and inspection logic in the fault diagnosis container image greatly enriches the means of container troubleshooting and improves the efficiency of container troubleshooting; secondly, when there is an abnormality in the container to be diagnosed, by determining the target recovery strategy corresponding to the diagnosis result, the container to be diagnosed automatically recovers the fault based on the target recovery strategy. Therefore, the fully automatic operation and maintenance capability of the container application from fault inspection, fault diagnosis to fault recovery is realized.

[0050] It can be seen that the solution provided by this application achieves the purpose of automatically recovering container faults based on fault diagnosis containers, thereby realizing the technical effect of fully automatic operation and maintenance capabilities of container applications from fault inspection, fault diagnosis to fault recovery, improving the efficiency of container troubleshooting, and thus solving the technical problems in the existing technology that cannot achieve automatic recovery of container faults and low troubleshooting efficiency.

[0051] In an optional embodiment, before the system inspects the container to be diagnosed based on the fault diagnosis container and obtains the inspection data, it receives a container diagnosis request and responds to the container diagnosis request to query the interface of the container cluster corresponding to the target application to determine whether there is a container to be diagnosed in the container cluster, wherein the container cluster consists of multiple containers and at least one container corresponds to one node; if there is a container to be diagnosed in the container cluster, the node information of the node where the container to be diagnosed is located is obtained.

[0052] Optionally, when a user initiates a container diagnostic request to the diagnostic tool client, such as Figure 2 As shown, the system's diagnostic tool client receives the container diagnosis request and queries the kube-apiserver interface of the k8s cluster where the container to be diagnosed is located to see whether the container to be diagnosed exists. If it does not exist, an error is reported and the request is returned; if it exists, the node information of the Node node where the target container is located is obtained.

[0053] Optionally, the k8s cluster is a container orchestration engine that supports automated container deployment, large-scale scaling, and application container management.

[0054] Furthermore, first, after obtaining the node information of the node where the container to be diagnosed is located, the system creates a diagnostic tool server based on the node information, wherein the diagnostic tool server is located in the node where the container to be diagnosed is located, and the diagnostic tool server is used to create a fault diagnosis container; secondly, it detects whether the creation time of the diagnostic tool server is less than the preset time; if the creation time is less than the preset time, a long connection is established between the diagnostic tool server and the diagnostic tool client, wherein the diagnostic tool client is the client that receives the container diagnosis request.

[0055] Optionally, the system's diagnostic tool client obtains the Node information where the diagnostic container is located, such as Figure 2 As shown, a diagnostic tool server is created on the Node and waits for it to become ready. Optionally, the preset duration is set by the developer. If the diagnostic tool server is not created successfully within the timeout period, an error message is reported and the request is returned. If the diagnostic tool server is successfully created within the preset time, the diagnostic tool client initiates a diagnostic request to the diagnostic tool server and establishes a persistent connection with the diagnostic tool server.

[0056] Furthermore, before the system inspects the container to be diagnosed based on the fault diagnosis container and obtains the inspection data, it detects whether the current time is within a preset time period; if the current time is within the preset time period, the fault inspection instruction is triggered; and the fault inspection instruction is executed to inspect the container to be diagnosed.

[0057] Optionally, the system can set a fixed time and initiate an inspection task regularly through the diagnostic tool client. For example, at 13:00:00 every day and 14:00:00 every Monday, the system initiates an inspection task to inspect the container to be diagnosed.

[0058] Optionally, the inspection task initiated by the system can inspect one container to be diagnosed, or can inspect multiple containers to be diagnosed at the same time.

[0059] It should be noted that through the scheduled inspection tasks set by the system, there is no need to manually initiate diagnostic requests, which improves the efficiency of container diagnosis, and can timely grasp the container operation status, perform container failure recovery in time, and reduce system operation anomalies caused by container failures.

[0060] Furthermore, after the system recovers the fault of the container to be diagnosed based on the target recovery strategy, it triggers the container diagnosis termination instruction; executes the container diagnosis termination instruction, then clears the fault diagnosis container, and sends a reminder message to the diagnostic tool client that the fault diagnosis container has been cleared; finally, it controls the diagnostic tool client to clear the diagnostic tool server based on the reminder message.

[0061] Optionally, after the diagnosis is complete, the system's diagnostic tool client sends a termination request to the diagnostic tool server. The diagnostic tool server clears the diagnostic container and notifies the client that the container has been cleared. After receiving the diagnostic container clearing request, the server clears the server and completes the termination request.

[0062] Furthermore, the system inspects the container to be diagnosed based on the fault diagnosis container and before obtaining the inspection data, checks whether the fault diagnosis container is successfully bound to the container to be diagnosed; when the fault diagnosis container fails to bind to the container to be diagnosed, copies the container to be diagnosed; then obtains the resource description file of the storage set where the container to be diagnosed is located, wherein the storage set contains at least one container to be diagnosed; and based on the resource description file, obtains the label field of the container to be diagnosed, deletes the label field and the inspection probe of the container to be diagnosed, and modifies the startup command of the container to be diagnosed in the resource description file to create a new container to be diagnosed, wherein the inspection probe is used to perform fault diagnosis on the container to be diagnosed; and performs fault inspection, fault diagnosis and fault recovery on the new container to be diagnosed.

[0063] Optionally, when a container fails due to repeated restarts and it is impossible to enter the container for troubleshooting, the fault diagnosis container cannot be successfully bound to the container to be diagnosed. At this time, it is necessary to copy the container to be diagnosed, modify the resource description file and startup command of the container to be diagnosed, create a new container to be diagnosed, and perform fault inspection, fault diagnosis and fault recovery based on the new container to be diagnosed.

[0064] It should be noted that by copying the container to be diagnosed and creating a new container to be diagnosed based on the copied container to be diagnosed, repeated restarts of the container are avoided, and the fault diagnosis tool can enter the container to be diagnosed to perform fault inspection, fault diagnosis and fault recovery, thereby solving the technical problem of being unable to perform fault diagnosis due to repeated restarts of the container to be diagnosed.

[0065] Furthermore, when the system performs fault recovery on the container to be diagnosed based on the target recovery strategy, it detects whether the memory usage of the container to be diagnosed is within a preset range; if the memory usage of the container to be diagnosed is outside the preset range, the container to be diagnosed is switched to a backup application container.

[0066] Optionally, when the system detects that the container's memory usage is outside the preset range, such as Figure 3 As shown, based on the diagnostic results and recovery strategies preset in the diagnostic tool server, the system automatically matches the target recovery strategy for traffic switching and switches the container to be diagnosed to the standby application container.

[0067] It should be noted that by detecting that the memory usage of the container is outside the preset range, it is determined that the container to be diagnosed has an abnormal memory usage fault. The system automatically matches the fault recovery strategy to achieve the ability to automatically recover from the container fault.

[0068] Furthermore, when the system performs fault recovery on the container to be diagnosed based on the target recovery strategy, it detects whether the configuration parameters of the container to be diagnosed are default parameters; if the configuration parameters of the container to be diagnosed are not default parameters, the configuration parameters are restored to the default parameters.

[0069] Optionally, the default parameters are the initial values ​​of the system configuration parameters. The parameters will change during debugging by developers or when the container is abnormal. At this time, the system will automatically restore the default parameters when it detects that the configuration parameters of the container to be diagnosed are not the default parameters.

[0070] It should be noted that the fault of abnormal parameter configuration of the container to be diagnosed is determined by whether the configuration parameters of the container to be diagnosed are default parameters, such as Figure 3 As shown, the system will automatically match the configured fault recovery strategy to achieve the ability to automatically recover from container failures.

[0071] Furthermore, when the system recovers the container to be diagnosed based on the target recovery strategy, it also includes restarting the container to be diagnosed.

[0072] Optional, such as Figure 3 As shown, the system can recover from the fault by restarting the container to be diagnosed.

[0073] It can be seen that the present invention provides a new method for fault recovery of containers. This method uses a fault diagnosis container to perform fault inspection and fault diagnosis on the container to be diagnosed, thereby solving the problem of low troubleshooting efficiency caused by the lack of diagnostic tools in the container. The method also greatly enriches the means of container troubleshooting and improves the efficiency of container troubleshooting through customized diagnostic tools and inspection logic in the diagnostic container image. By duplicating the container to be diagnosed and creating a new container to be diagnosed based on the duplicated container to be diagnosed, the container is avoided from being restarted repeatedly, solving the problem of difficulty in diagnosis when the container is inaccessible. By duplicating the fault container, a way to diagnose the inaccessible fault container is provided. When the diagnostic result indicates that the container to be diagnosed has an abnormality, the target recovery strategy corresponding to the diagnostic result is determined. Based on the target recovery strategy, the container to be diagnosed is restored, thereby realizing the automation of container fault recovery and solving the technical problem that the existing technology cannot realize automatic recovery of container faults.

[0074] Example 2

[0075] According to an embodiment of the present invention, an embodiment of a container fault recovery device is provided, wherein: Figure 4 A schematic diagram of an optional container fault recovery device according to an embodiment of the present invention is shown in FIG. Figure 4 As shown, the device includes:

[0076] The inspection module 401 is used to inspect the container to be diagnosed based on the fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that contains the operating environment when the application is running, and there is a binding relationship between the fault diagnosis container and the container to be diagnosed. The fault diagnosis container is a container created based on the fault diagnosis container image. The fault diagnosis container image includes a fault diagnosis tool for detecting faults in the container to be diagnosed and an inspection logic for inspecting the container to be diagnosed. Different fault diagnosis container images correspond to different diagnostic tools and inspection logic; the diagnosis module 402 is used to analyze the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result; the determination module 403 is used to determine the target recovery strategy corresponding to the diagnosis result when the diagnosis result indicates that the container to be diagnosed has an abnormality; the recovery module 404 is used to perform fault recovery on the container to be diagnosed based on the target recovery strategy.

[0077] It should be noted that the above-mentioned inspection module 401, diagnosis module 402, determination module 403 and recovery module 404 correspond to steps S101 to S104 in the above-mentioned embodiment. The examples and application scenarios implemented by the four modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned embodiment 1.

[0078] Optionally, the inspection module also includes: a receiving module, a first determination module and a first acquisition module; the receiving module is used to receive a container diagnosis request; the first determination module is used to respond to the container diagnosis request, query the interface of the container cluster corresponding to the target application, and determine whether there is a container to be diagnosed in the container cluster, wherein the container cluster is composed of multiple containers and at least one container corresponds to a node; the acquisition module is used to obtain the node information of the node where the container to be diagnosed is located when there is a container to be diagnosed in the container cluster.

[0079] Optionally, the acquisition module includes: a first processing module, a first detection module and a second determination module; the first processing module is used to create a diagnostic tool server based on node information, wherein the diagnostic tool server is located in the node where the container to be diagnosed is located, and the diagnostic tool server is used to create a fault diagnosis container; the first detection module is used to detect whether the creation time of the diagnostic tool server is less than the preset time; the second determination module is used to establish a long connection between the diagnostic tool server and the diagnostic tool client if the creation time is less than the preset time, wherein the diagnostic tool client is a client that receives container diagnosis requests.

[0080] Optionally, the fault recovery device of the container includes: a second detection module, a first trigger module and a first execution module; the second detection module is used to detect whether the current time is within a preset time period; the first trigger module is used to trigger a fault inspection instruction when the current time is within the preset time period; the first execution module is used to execute the fault inspection instruction to inspect the container to be diagnosed.

[0081] Optionally, the container fault recovery device includes: a second trigger module, a clearing module and a control module; the second trigger module is used to trigger the container diagnosis termination instruction; the clearing module is used to execute the container diagnosis termination instruction, clear the fault diagnosis container, and send a reminder message to the diagnostic tool client that the fault diagnosis container has been cleared; the control module is used to control the diagnostic tool client to clear the diagnostic tool server based on the reminder message.

[0082] Optionally, the container fault recovery device includes: a third detection module, a replication module, a second acquisition module, a third acquisition module, and a second processing module. The third detection module is used to detect whether the fault diagnosis container is successfully bound to the container to be diagnosed; the replication module is used to replicate the container to be diagnosed when the fault diagnosis container fails to bind to the container to be diagnosed; the second acquisition module is used to obtain a resource description file of the storage set where the container to be diagnosed is located, wherein the storage set contains at least one container to be diagnosed; the third acquisition module is used to obtain a label field of the container to be diagnosed based on the resource description file; the second processing module is used to delete the label field and inspection probe of the container to be diagnosed, and modify the startup command of the container to be diagnosed in the resource description file to create a new container to be diagnosed, wherein the inspection probe is used to perform fault diagnosis on the container to be diagnosed; and the new container to be diagnosed is subjected to fault inspection, fault diagnosis, and fault recovery.

[0083] Optionally, the recovery module includes: a fourth detection module and a switching module; the fourth detection module is used to detect whether the memory usage of the container to be diagnosed is within a preset range; the switching module is used to switch the container to be diagnosed to a spare application container when the memory usage of the container to be diagnosed is outside the preset range.

[0084] Optionally, the recovery module includes: a fifth detection module and a reset module; the fifth detection module is used to detect whether the configuration parameters of the container to be diagnosed are default parameters; the reset module is used to restore the configuration parameters to default parameters when the configuration parameters of the container to be diagnosed are not default parameters.

[0085] Optionally, the recovery module includes: a restart module, used to restart the container to be diagnosed.

[0086] Example 3

[0087] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, in which a computer program is stored. The computer program is configured to execute the above-mentioned container failure recovery method when running.

[0088] Example 4

[0089] According to another aspect of an embodiment of the present invention, an electronic device is provided, wherein: Figure 5 is a schematic diagram of an optional electronic device according to an embodiment of the present invention, such as Figure 5 As shown, the electronic device includes one or more processors; a memory for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the above-mentioned container failure recovery method during runtime.

[0090] Example 5

[0091] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program / instruction, which implements the above-mentioned container failure recovery method when the computer program / instruction is executed by a processor.

[0092] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0093] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0094] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0095] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected to achieve the purpose of the present embodiment according to actual needs.

[0096] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0097] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program codes.

[0098] The above are only preferred embodiments of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A container fault recovery method, characterized in that: include: Performing an inspection on the container to be diagnosed based on the fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that includes the operating environment when the application is running, there is a binding relationship between the fault diagnosis container and the container to be diagnosed, the fault diagnosis container is a container that is added to the container to be diagnosed and establishes a connection with the container to be diagnosed, the fault diagnosis container is a container created based on the fault diagnosis container image, the fault diagnosis container image includes a fault diagnosis tool for detecting faults of the container to be diagnosed and inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic; Analyzing the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result, wherein the inspection data includes at least CPU usage, memory usage, and parameter configuration; When the diagnosis result indicates that the container to be diagnosed is abnormal, determining a target recovery strategy corresponding to the diagnosis result, wherein the target recovery strategy includes traffic switching, restarting the container, and restoring the configuration; Fault recovery is performed on the container to be diagnosed based on the target recovery strategy.

2. The method according to claim 1, characterized in that Before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining inspection data, the method further includes: receiving container diagnostic requests; In response to the container diagnosis request, query the interface of the container cluster corresponding to the target application to determine whether the container to be diagnosed exists in the container cluster, wherein the container cluster consists of multiple containers and at least one container corresponds to one node; If the container to be diagnosed exists in the container cluster, node information of the node where the container to be diagnosed is located is obtained.

3. The method according to claim 2, characterized in that After obtaining the node information of the node where the container to be diagnosed is located, the method further includes: Based on the node information, a diagnostic tool server is created, wherein the diagnostic tool server is located in the node where the container to be diagnosed is located, and the diagnostic tool server is used to create the fault diagnosis container; Detecting whether the creation time of the diagnostic tool server is less than a preset time; If the creation duration is less than the preset duration, a long connection is established between the diagnostic tool server and the diagnostic tool client, wherein the diagnostic tool client is a client that receives the container diagnosis request.

4. The method according to claim 1, wherein Before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining inspection data, the method further includes: Check whether the current time is within the preset time period; If the current time is within the preset time period, a fault inspection instruction is triggered; The fault inspection instruction is executed to inspect the container to be diagnosed.

5. The method according to claim 3, characterized in that After performing fault recovery on the container to be diagnosed based on the target recovery strategy, the method further includes: Trigger container diagnostic termination instructions; executing the container diagnosis termination instruction, clearing the fault diagnosis container, and sending a reminder message to the diagnostic tool client indicating that the fault diagnosis container has been cleared; The diagnostic tool client is controlled to clear the diagnostic tool server based on the reminder message.

6. The method according to claim 1, characterized in that Before inspecting the container to be diagnosed based on the fault diagnosis container and obtaining inspection data, the method further includes: Detecting whether the fault diagnosis container is successfully bound to the container to be diagnosed; When the fault diagnosis container fails to be bound to the container to be diagnosed, copying the container to be diagnosed; Obtaining a resource description file of the storage set where the container to be diagnosed is located, wherein the storage set contains at least one container to be diagnosed; Obtaining a label field of the container to be diagnosed based on the resource description file; Deleting the label field and the inspection probe of the container to be diagnosed, and modifying the startup command of the container to be diagnosed in the resource description file to create a new container to be diagnosed, wherein the inspection probe is used to perform fault diagnosis on the container to be diagnosed; Perform fault inspection, fault diagnosis and fault recovery on the new container to be diagnosed.

7. The method according to claim 1, characterized in that Performing fault recovery on the container to be diagnosed based on the target recovery strategy includes: Detecting whether the memory usage of the container to be diagnosed is within a preset range; If the memory usage of the container to be diagnosed is outside the preset range, the container to be diagnosed is switched to a spare application container.

8. The method according to claim 1, characterized in that Performing fault recovery on the container to be diagnosed based on the target recovery strategy includes: Detecting whether the configuration parameters of the container to be diagnosed are default parameters; If the configuration parameters of the container to be diagnosed are not the default parameters, the configuration parameters are restored to the default parameters.

9. The method according to claim 1, characterized in that Performing fault recovery on the container to be diagnosed based on the target recovery strategy includes restarting the container to be diagnosed.

10. A container fault recovery device, characterized in that: include: An inspection module is used to inspect the container to be diagnosed based on the fault diagnosis container to obtain inspection data, wherein the container to be diagnosed is a process that includes the operating environment when the application is running, there is a binding relationship between the fault diagnosis container and the container to be diagnosed, the fault diagnosis container is a container that is added to the container to be diagnosed and establishes a connection with the container to be diagnosed, the fault diagnosis container is a container created based on the fault diagnosis container image, the fault diagnosis container image includes a fault diagnosis tool for detecting faults of the container to be diagnosed and inspection logic for inspecting the container to be diagnosed, and different fault diagnosis container images correspond to different diagnostic tools and inspection logic; a diagnosis module, configured to analyze the inspection data according to the fault diagnosis tool in the fault diagnosis container to obtain a diagnosis result, wherein the inspection data includes at least CPU usage, memory usage, and parameter configuration; a determination module, configured to determine a target recovery strategy corresponding to the diagnosis result when the diagnosis result indicates that the container to be diagnosed is abnormal, wherein the target recovery strategy includes traffic switching, restarting the container, and restoring the configuration; A recovery module is configured to perform fault recovery on the container to be diagnosed based on the target recovery strategy.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the container failure recovery method according to any one of claims 1 to 9 when running.

12. An electronic device, characterized in that: The electronic device includes one or more processors; A memory for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to run the programs, wherein the programs are configured to execute the container failure recovery method described in any one of claims 1 to 9 when running.

13. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the failure recovery method for a container according to any one of claims 1 to 9 is implemented.

Images