Container testing method, system and device and storage medium

Abstract

The invention discloses a container testing method, system and device and a storage medium. The method comprises the following steps: receiving test scene information; based on the test scene information, a target container is determined on the node, the target container and an actuator executing fault injection processing are deployed on the node, the node is a host machine used for deploying the container, and the actuator is configured to have a cross-container interaction permission on the node; and executing fault injection processing on the target container by adopting an actuator to obtain fault performance information. According to the invention, the problem that the fault injection test precision is not ideal in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and more particularly, to a container testing method, system, device, and storage medium. Background Art

[0002] The fault injection test of containerized applications relies on manual configuration and execution. This method is not only time-consuming and laborious, but also has limited accuracy. Testers need to set fault scenarios based on experience and then execute fault injection one by one. This process is difficult to accurately simulate the complex faults that may be encountered in actual operation, resulting in inaccurate test results and unable to comprehensively evaluate the robustness of the application. Especially in an environment with multiple containers and multiple namespaces, the limitations of manual testing are more obvious, it is difficult to cover all possible interaction faults, and there is a risk of test omission. In addition, there is a lack of an effective mechanism in the prior art to automatically optimize the self-healing strategy according to the test results, so that the recovery ability of the container when encountering a fault is limited. Therefore, the existing container testing methods have problems such as unsatisfactory test accuracy, incomplete coverage of fault scenarios, and insufficient optimization of self-healing strategies.

[0003] Regarding the problem of unsatisfactory accuracy of fault injection testing in the related art, no effective solution has been proposed yet. Summary of the Invention

[0004] The main purpose of this application is to provide a container testing method to solve the problem of unsatisfactory accuracy of fault injection testing in the related art.

[0005] To achieve the above objective, according to one aspect of this application, a container testing method is provided. The method includes: receiving test scenario information; based on the test scenario information, determining a target container on a node, where the target container and an executor for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the executor is configured with cross-container interaction permissions on the node; using the executor to perform fault injection processing on the target container to obtain fault manifestation information.

[0006] Optionally, the determining a target container on a node based on the test scenario information includes: parsing the test scenario information to obtain a namespace to be tested; determining a target namespace that matches the namespace to be tested among M candidate namespaces deployed on the node, where the M candidate namespaces are isolated running environments and M is a positive integer; determining N containers deployed by the target namespace on the node as the target container, where N is a positive integer.

[0007] Optionally, performing fault injection processing on the target container by using the actuator to obtain fault manifestation information, including: determining a fault type and fault parameters based on the test scenario information; entering the operating environment of the target container according to the cross-container interaction permission of the actuator; performing fault injection processing in the operating environment based on the fault type and the fault parameters to obtain the fault manifestation information.

[0008] Optionally, the determining a fault type and fault parameters based on the test scenario information includes: when the test scenario information indicates that the fault type is an application-level fault, determining that the fault parameters include at least one of the following: an application connection exception parameter of the internal application layer of the target container, an application call exception parameter; when the test scenario information indicates that the fault type is a network-level fault, determining that the fault parameters include at least one of the following: a network delay parameter, a packet loss parameter, a network connection parameter of the internal network layer of the target container; when the test scenario information indicates that the fault type is a system-level fault, determining that the fault parameters include at least one of the following: a disk fault parameter, a memory overflow parameter, a central processing unit exception parameter of the internal system of the target container.

[0009] Optionally, the method further includes: obtaining a test requirement in natural language; processing the test requirement by using a target model to generate a test instruction set in the natural language, where the target model is trained based on historical test requirements and historical test instruction sets; and in response to a confirmation process for the test instruction set, converting the test instruction set into the test scenario information in a target language.

[0010] Optionally, after performing fault injection processing on the target container by using the actuator to obtain fault manifestation information, the method further includes: determining self-healing manifestation information of the target container within a predetermined time window based on the fault manifestation information; and adjusting an initial self-healing policy configured for the target container based on the self-healing manifestation information to obtain a target self-healing policy.

[0011] Optionally, the actuator is used to perform fault injection processing on the target container to obtain fault manifestation information, including: performing fault injection processing on the target container based on an initial injection policy configured by the actuator to obtain initial manifestation information; determining an adjustment instruction corresponding to the predetermined drive event when the initial manifestation information indicates that the target container has a predetermined drive event; processing the initial injection policy with the adjustment instruction to obtain an updated injection policy; performing fault injection processing on the target container again according to the updated injection policy to obtain updated manifestation information; and obtaining the fault manifestation information based on the initial manifestation information and the updated manifestation information.

[0012] To achieve the above object, according to another aspect of the present application, a container testing device is provided. The device includes: a first receiving module, configured to receive test scenario information; a target determination module, configured to determine a target container on a node based on the test scenario information, where the target container and an actuator for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the actuator is configured to have cross-container interaction permissions on the node; and a fault injection module, which uses the actuator to perform fault injection processing on the target container to obtain fault manifestation information.

[0013] Optionally, the target determination module includes: a parsing module, configured to parse the test scenario information to obtain a namespace to be tested; a namespace determination module, configured to determine a target namespace that matches the namespace to be tested from M candidate namespaces deployed on the node, where the M candidate namespaces are isolated running environments, and M is a positive integer; and a first determination module, configured to determine N containers deployed by the target namespace on the node as the target containers, where N is a positive integer.

[0014] Optionally, the fault injection module includes: a second determination module, configured to determine a fault type and fault parameters based on the test scenario information; a running environment determination module, configured to enter the running environment of the target container according to the cross-container interaction permissions of the actuator; and a fault manifestation information acquisition module, configured to perform fault injection processing in the running environment based on the fault type and the fault parameters to obtain the fault manifestation information.

[0015] Optionally, the fault injection module includes: a third determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is an application-level fault: application connection exception parameters of the internal application layer of the target container, application call exception parameters; a fourth determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is a network-level fault: network delay parameters, packet loss parameters, network connection parameters of the internal network layer of the target container; a fifth determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is a system-level fault: disk fault parameters, memory overflow parameters, central processing unit exception parameters of the internal system of the target container.

[0016] Optionally, the first receiving module includes: a test requirement acquisition module, configured to acquire test requirements in natural language; a test instruction set generation module, configured to process the test requirements by using a target model to generate a test instruction set in the natural language; wherein, the target model is trained based on historical test requirements and historical test instruction sets. A scenario information generation module, configured to convert the test instruction set into the test scenario information in a target language in response to a confirmation process for the test instruction set.

[0017] Optionally, the fault injection module includes: a self-healing performance information acquisition module, configured to determine self-healing performance information of the target container within a predetermined time window based on the fault performance information; a policy determination module, configured to adjust an initial self-healing policy configured for the target container based on the self-healing performance information to obtain a target self-healing policy.

[0018] Optionally, the fault injection module includes: a first information acquisition module, configured to perform a fault injection process on the target container based on an initial injection policy configured by the actuator to obtain initial performance information; an instruction adjustment module, configured to determine an adjustment instruction corresponding to the predetermined drive event when the initial performance information indicates that the target container has a predetermined drive event; a policy update module, configured to process the initial injection policy by using the adjustment instruction to obtain an updated injection policy; a second information acquisition module, configured to perform a fault injection process on the target container again according to the updated injection policy to obtain updated performance information; a third information acquisition module, configured to obtain the fault performance information based on the initial performance information and the updated performance information.

[0019] To achieve the above object, according to another aspect of the present application, there is provided an electronic device, including: a memory storing an executable program; a processor for running the program, wherein when the program runs, it executes any one of the container testing methods.

[0020] To achieve the above object, according to another aspect of the present application, there is provided a computer-readable storage medium, which includes a stored executable program, wherein when the executable program runs, it controls the device where the computer-readable storage medium is located to execute any one of the container testing methods.

[0021] In the embodiments of the present application, a container testing method is adopted. By receiving test scenario information; based on the test scenario information, a target container is determined on a node, where the target container and an actuator for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the actuator is configured to have cross-container interaction permissions on the node; the actuator is used to perform fault injection processing on the target container to obtain fault manifestation information, achieving the purpose of fault injection at the container level, thereby realizing the technical effect of improving the accuracy of fault injection testing, and further solving the technical problem of low efficiency of fault injection testing. Description of the Drawings

[0022] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0023] Figure 1 A hardware structure block diagram of a computer terminal for implementing the container testing method is shown;

[0024] Figure 2 It is a flowchart of the container testing method provided by the embodiments of the present application;

[0025] Figure 3 It is a first schematic diagram of the container testing method provided by the embodiments of the present application;

[0026] Figure 4 It is a second schematic diagram of the container testing method provided by the embodiments of the present application;

[0027] Figure 5 It is a schematic diagram of the container testing device provided by the embodiments of the present application;

[0028] Figure 6 It is a structure block diagram of an electronic device according to an embodiment of the present application. Detailed Embodiments

[0029] To enable those skilled in the art to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the scope of protection of this application.

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

[0031] First, some nouns or terms that appear during the description of the embodiments of this application are applicable to the following explanations:

[0032] CI / CD is the abbreviation of Continuous Integration and Continuous Delivery / Deployment. CI / CD practices improve the speed and quality of software development through automated build, test, and deployment processes, ensure that software can be quickly and reliably delivered to the production environment at any time, and at the same time reduce errors and delays caused by manual operations.

[0033] It should be noted that the information (including but not limited to test scenario information, fault manifestation information, etc.) and data (including but not limited to data for display, data for analysis, etc.) collected in this application are information and data authorized by the user or fully authorized by all parties. And the processing of relevant data, such as collection, storage, use, processing, transmission, provision, disclosure, and application, all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good customs, and provide corresponding operation entrances for users to choose to authorize or refuse. For example, there is an interface between this system and relevant users or institutions to provide users with corresponding operation entrances to choose to agree or refuse the automated decision-making results; if the user chooses to refuse, the expert decision-making process will be entered.

[0034] Embodiment 1

[0035] According to an embodiment of the present application, an embodiment of a method for container testing is further provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0036] The method embodiment provided by Embodiment 1 of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing the container testing method is shown. As Figure 1 shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b,..., 102n in the figure) (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may further include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply, and / or a camera. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 may further include more or fewer components than those Figure 1 shown, or have a different configuration from that Figure 1 shown.

[0037] It should be noted that the above one or more processors 102 and / or other data processing circuits are generally referred to as "data processing circuits" in this article. The data processing circuit can be embodied as software, hardware, firmware or any combination thereof in whole or in part. In addition, the data processing circuit can be a single independent processing module, or be incorporated in whole or in part into any one of the other elements in the computer terminal 10 (or mobile device). As involved in the embodiment of the present application, the data processing circuit is used for processor control (such as the selection of a variable resistor terminal path connected to an interface).

[0038] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the container testing method in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implements the above-mentioned container testing method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories can be connected to the computer terminal 10 through a network. Examples of the above network include but are not limited to the Internet, intranet, local area network, mobile communication network, and combinations thereof.

[0039] The transmission device 106 is used to receive or send data via a network. Specific examples of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station and thus communicate with the Internet. In one instance, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0040] The display can be, for example, a touch-screen liquid crystal display (LCD), and the liquid crystal display enables a user to interact with the user interface of the computer terminal 10 (or mobile device).

[0041] Under the above operating environment, the present application provides a container testing method as Figure 2 shown. Figure 2 It is a flowchart of the container testing method according to Embodiment 1 of the present application.

[0042] Step S202, receiving test scenario information;

[0043] It can be understood that receiving test scenario information is the core starting step. Detailed test scenario descriptions can be collected from testers or automated test processes, including key information such as the environmental configuration of the container to be tested, the expected failure types, and specific failure parameters, ensuring the pertinence and effectiveness of subsequent fault injection, enabling the test to accurately simulate the expected fault scenario, and thus precisely evaluating the robustness and self-recovery ability of the containerized application.

[0044] Optionally, the above test scenario information can be in the form of YAML (YAML Ain't Markup Language), which is a data serialization format used in scenarios such as configuration files, data transmission, and storage. YAML files usually have the extensions.yaml or.yml. In the field of containerization, YAML is widely used to define and describe container configurations, services, deployment strategies, etc. Through YAML files, information such as container images, environment variables, resource limits, and port mappings can be specified explicitly, making the deployment and management of containers more flexible and configurable.

[0045] Optionally, in the container testing method provided in the embodiments of the present application, the method further includes: obtaining a test requirement in natural language; processing the test requirement by using a target model to generate a test instruction set in natural language; wherein, the target model is trained based on historical test requirements and historical test instruction sets. In response to the confirmation processing of the test instruction set, the test instruction set is converted into test scenario information in a target language.

[0046] It can be understood that obtaining a test requirement expressed in natural language and using a target model trained through deep learning to automatically convert the test requirement in natural language into a structured test instruction set. The target model is trained on a large number of historical test requirements and corresponding test instruction sets, and has the ability to understand diverse test requirements and accurately generate corresponding test instructions. Once the test instruction set is confirmed by the user, the system will convert it into a specific target language to generate detailed test scenario information, preparing for subsequent automated fault injection testing. Through natural language processing technology and deep learning models, the automation level and accuracy of the testing process are improved. The system can directly understand and convert test requirements described in human daily language, avoiding errors caused by manual translation of instructions.

[0047] Optionally, a user interface is provided to allow testers to describe the fault scenarios or test requirements they want to simulate in natural language. For example, a tester may describe "I want to test the response time and data integrity of a certain service under memory pressure". By internally integrating an NLP (Natural Language Processing) module to perform natural language recognition processing and semantic analysis based on a deep learning model to understand the tester's intention. The NLP module is trained on a large number of historical test requirements and instruction set data sets, and can identify and understand common test scenarios and convert them into structured instruction sets, such as "In the namespace named db, perform a memory pressure test on a certain container (or a specific application in the container), set the pressure threshold to 90%, and detect changes in response time and data integrity".

[0048] The generated test instruction set will be presented to the testers for confirmation to ensure that the requirements understood by the model are consistent with the actual requirements. Testers can edit or adjust the instructions until they are satisfied. Testers do not need to write test instructions in detail. They only need to describe the test scenario in natural language, and the system will automatically complete the subsequent conversion, saving a lot of time and effort.

[0049] Step S204: Based on the test scenario information, determine a target container on the node. Among them, the target container and the executor for performing the fault injection process are deployed on the node. The node is a host for deploying containers, and the executor is configured to have cross-container interaction permissions on the node.

[0050] It can be understood that based on the received test scenario information, the target container that needs to be tested for fault injection is intelligently determined on the host node. The target container and the executor for performing the fault injection process are deployed on the node, and cross-container interaction permissions are configured. By determining the target container and using the executor with cross-container interaction permissions, the high pertinence and security of fault injection are achieved.

[0051] It should be noted that the above node can be a virtual machine or a physical machine, which realizes the function of a host for providing running resources for containers.

[0052] Optionally, in the container testing method provided in the embodiments of the present application, determining a target container on the node based on the test scenario information includes: parsing the test scenario information to obtain the namespace to be tested; among the M candidate namespaces deployed on the node, determining the target namespace that matches the namespace to be tested, where the M candidate namespaces are isolated running environments, and M is a positive integer; determining the N containers deployed by the target namespace on the node as the target containers, where N is a positive integer.

[0053] It can be understood that the test scenario information is deeply parsed to extract the namespace to be tested. Subsequently, among the M candidate namespaces deployed on the host, the target namespace that meets the test requirements is intelligently matched. The candidate namespaces are isolated running environments, thus ensuring the purity of the test environment and the independence of fault injection. Determine the N containers deployed under this target namespace as the target containers for fault injection. By parsing the test scenario information and intelligently matching the target namespace, the complexity and error caused by manual selection are avoided. Due to the isolation of the namespace, the fault injection during the test process will not interfere with other containers, ensuring the security of the test and the stability of the host.

[0054] Optionally, if no specific container is specified in the test scenario information, the target container can be dynamically selected according to the status and resource usage of the container, or the resource allocation of the container can be adjusted according to the test requirements.

[0055] Step S206: Use an actuator to perform fault injection processing on the target container to obtain fault manifestation information.

[0056] It can be understood that the actuator performs precise fault injection processing on the target container according to the fault type and parameters specified in the test scenario information. The actuator can record the state changes, exception information, and recovery situation of the container during the fault injection process, and can summarize the above various information to form fault manifestation information, providing a detailed data basis for subsequent analysis and self-healing strategy adjustment. The actuator realizes the automated and controllable simulation of container faults, which not only improves the test efficiency but also ensures the accuracy and safety of fault injection.

[0057] Optionally, in the container testing method provided in the embodiments of the present application, using an actuator to perform fault injection processing on the target container to obtain fault manifestation information includes: determining the fault type and fault parameters based on the test scenario information; entering the running environment of the target container according to the cross-container interaction permission of the actuator; and performing fault injection processing in the running environment based on the fault type and fault parameters to obtain fault manifestation information.

[0058] It can be understood that based on the received test scenario information, the fault type to be simulated and the specific fault parameters are accurately parsed and determined, ensuring the pertinence and controllability of fault injection. The actuator uses its configured cross-container interaction permission to safely access the running environment of the target container. The actuator accurately performs the fault injection operation in the running environment of the target container according to the determined fault type and parameters, and collects the behavior data of the container in the fault state in real time to obtain fault manifestation information. Deeply revealing the true performance of containerized applications under various fault conditions helps to identify and repair potential system vulnerabilities and optimize the application architecture.

[0059] Optionally, the parsed fault parameters are standardized to ensure compliance with the specifications of the containerized environment. For non-destructive tests, the fault parameters need to be verified to ensure they are within a reasonable range to avoid irreversible damage to the container.

[0060] Optionally, while performing fault injection, the actuator should start real-time detection to collect key indicators of the container in the fault state, such as CPU usage, memory occupancy, network traffic, service response time, etc. Analyze the collected data to generate fault manifestation information, including the comparison of the system state before and after the fault, the scope of the fault impact, and the self-recovery ability of the container, which is beneficial to evaluating the robustness of the containerized application and optimizing the application architecture.

[0061] Optionally, in the container testing method provided in the embodiments of the present application, based on the test scenario information, the fault type and fault parameters are determined, including: when the test scenario information indicates that the fault type is an application-level fault, it is determined that the fault parameters include at least one of the following: the application connection exception parameter of the internal application layer of the target container, the application call exception parameter; when the test scenario information indicates that the fault type is a network-level fault, it is determined that the fault parameters include at least one of the following: the network delay parameter, the packet loss parameter, the network connection parameter of the internal network layer of the target container; when the test scenario information indicates that the fault type is a system-level fault, it is determined that the fault parameters include at least one of the following: the disk fault parameter, the memory overflow parameter, the central processing unit exception parameter of the internal system of the target container.

[0062] It can be understood that when the test scenario information indicates that the fault type is application-level, network-level, or system-level, the system can specifically determine detailed fault parameters. For application-level faults, the fault parameters may involve application connection exceptions or application call exceptions, and these parameters can help the test system simulate the fault states inside the application program; for network-level faults, the system will focus on parameters such as network delay, packet loss rate, or network connection exceptions to simulate instability or errors at the network level; while system-level faults prompt the system to focus on key indicators such as disk faults, memory overflows, or central processing unit exceptions inside the container, and these indicators are related to the running health and stability of the container bottom layer. The hierarchical fault parameter determination mechanism can not only cover common fault types but also penetrate into the internal operation mechanism of the container to carefully evaluate the robustness, fault recovery ability, and performance of containerized applications.

[0063] Optionally, the multi-level fault injection at least includes: network-level fault injection, simulating network faults such as packet loss, delay, and disconnection at the container network level. System-level fault injection, simulating system-level faults such as disk faults, memory overflows, and CPU (Central Processing Unit) overloads. Application-level fault injection, directly injecting specific faults at the application level, such as database connection failures and API (Application Programming Interface) call exceptions.

[0064] Optionally, in the container testing method provided in the embodiments of the present application, after using an actuator to perform fault injection processing on the target container to obtain fault manifestation information, the method further includes: determining the self-healing manifestation information of the target container within a predetermined time window based on the fault manifestation information; adjusting the initial self-healing strategy configured for the target container based on the self-healing manifestation information to obtain the target self-healing strategy.

[0065] It can be understood that after performing fault injection processing and collecting fault manifestation information, the self-healing performance of the target container within a predetermined time window is further analyzed. By detecting how the container responds to faults, the system can obtain detailed self-healing performance information, including the recovery speed, recovery effect, and whether it has fully recovered to the normal operating state. Based on the in-depth analysis of the self-healing performance information, the initial self-healing strategy of the target container is intelligently adjusted, the fault recovery mechanism is optimized, and finally a more efficient and accurate target self-healing strategy is formed, significantly enhancing the self-repair ability of containerized applications and improving the overall stability and availability of the system.

[0066] Optionally, in the container testing method provided in the embodiments of the present application, an actuator is used to perform fault injection processing on the target container to obtain fault manifestation information, including: performing fault injection processing on the target container based on the initial injection strategy configured by the actuator to obtain initial manifestation information; determining an adjustment instruction corresponding to the predetermined drive event when the initial manifestation information indicates that the target container has a predetermined drive event; processing the initial injection strategy with the adjustment instruction to obtain an updated injection strategy; performing fault injection processing on the target container again according to the updated injection strategy to obtain updated manifestation information; and obtaining fault manifestation information based on the initial manifestation information and the updated manifestation information.

[0067] It can be understood that the actuator performs the first fault injection on the target container based on the configured initial injection strategy to obtain the initial manifestation information of the container under this strategy. Analyzing the initial manifestation information, when it is detected that a predetermined drive event is triggered inside the container, such as abnormal behavior or a specific fault response, this event is intelligently identified, and the corresponding adjustment instruction is automatically generated according to the preset rules or algorithms to optimize or adjust the initial injection strategy of the actuator, generating an updated injection strategy. Then, the actuator performs fault injection processing on the target container again according to the updated strategy to collect the updated manifestation information of the container. By comparing and analyzing the initial manifestation information and the updated manifestation information, the fault manifestation of the container under different injection strategies is comprehensively evaluated to generate fault manifestation information. By dynamically adjusting the fault injection strategy, the accuracy and coverage of the test are improved, and according to the actual response of the container and automatically optimizing the fault injection strategy, it is ensured that the test can more realistically simulate various fault scenarios that may be encountered in actual operation.

[0068] Optionally, according to the test scenario information, the actuator configures the initial injection strategy, including the fault type, parameters, duration, etc. For example, the initial strategy can be "simulate a 5ms network delay on the target container for 30 seconds". The actuator performs fault injection processing on the target container according to the initial injection strategy and collects key metrics of the container in the fault state in real time, such as the response time of the service, resource consumption, error logs, etc. Before the test, a series of predefined driving events need to be defined, which may be abnormal behaviors triggered by fault injection, such as service unresponsiveness, memory overflow, sudden increase in CPU usage, etc. The actuator analyzes the initially collected performance information to detect whether a predefined driving event has occurred. If detected, it will trigger the subsequent policy adjustment process. Once a predefined driving event is detected, the actuator automatically generates adjustment instructions according to preset rules or algorithms, including optimizing injection parameters, changing the fault duration, introducing new fault types, etc., to more accurately simulate the fault scenarios in actual operation.

[0069] The actuator optimizes or adjusts the initial injection strategy according to the adjustment instructions. For example, if the target container performs normally under low latency, the updated strategy may increase the latency time to test the behavior of the container under more adverse conditions. The actuator performs fault injection processing on the target container again according to the updated injection strategy and collects the updated performance information of the container under the new strategy. By comparing the initial performance information and the updated performance information, the actuator can evaluate the performance differences of the container under different fault injection strategies, identify the sensitive points and robustness of the container. Based on the results of the comparative analysis, the actuator comprehensively generates detailed fault performance information, including changes in the system state before and after the fault, the self-recovery ability of the container, the continuity and stability of the service, etc. The actuator feeds back the fault performance information to the test system for optimizing the test strategy, adjusting the container configuration or optimizing the software code, forming a closed-loop test optimization process.

[0070] It should be noted that for the container testing method provided in the embodiments of the present application, in step S202, by receiving the test scenario information; in step S204, based on the test scenario information, the target container is determined on the node, where the target container and the actuator for performing the fault injection processing are deployed on the node, the node is the host for deploying the container, and the actuator is configured with cross-container interaction permissions on the node; in step S206, the actuator is used to perform fault injection processing on the target container to obtain the fault performance information, which solves the problem of unsatisfactory fault injection test accuracy in the related art. Thus, the effect of improving the fault injection test accuracy is achieved.

[0071] Based on the above embodiments and alternative embodiments, the present application proposes an alternative implementation manner, the containerized testing method is as Figure 3 , Figure 3It is the first schematic diagram of the container testing method provided by the embodiments of the present application. The namespace1 for performing fault injection is designed into two major parts: the controller and the executor daemonset. The two parts work together to achieve the purpose of performing fault injection testing on the containerized cluster. The controller serves as the command center of the entire testing system. The controller is responsible for parsing the test scenario description input by the user (usually in YAML format), and extracting the fault types, parameters, and the attributes of the target containers to be executed, such as the namespace and the labels of the containers. The controller can be set in the form of a container pod, and is also responsible for scheduling and managing the entire testing process, including determining when to start fault injection, when to end, and controlling the activities of the executor. Communicate with the executor, issue fault injection instructions, detect the status of the executor, and adjust the behavior of the executor when necessary.

[0072] The executor is deployed on each node of the container cluster and can perform fault injection operations on specific containers or a group of containers (such as containers in the same namespace namespace2 or namespace3). According to the instructions issued by the controller, the executor can accurately find the target containers and simulate various faults at the container level, such as network latency, disk I / O latency, forced container stop, etc. The executor interferes with specific network devices, file systems, container status, etc. by invading the target container pod and namespace.

[0073] Figure 4 It is the second schematic diagram of the container testing method provided by the embodiments of the present application, as Figure 4 shown, Figure 4 is the implementation process of the container testing.

[0074] Step S1, the user inputs the YAML of the required test scenario (i.e., test scenario information); the controller receives the YAML of the required test scenario and parses it into the specific content that needs to be fault injected (i.e., fault types and fault parameters). Design a multi-layer fault injection framework that allows users to specify fault types and parameters at different levels in the YAML file. For example:

[0075] Container level: containerFailure:{type:"networkDelay",delay:"10ms",target:"abc"}.

[0076] Network level: networkFailure:{type:"packetLoss",lossRate:"5%",targetPods:["pod1","pod2"]}.

[0077] System level: systemFailure: {type: "memoryPressure", threshold: "90%"}.

[0078] Application level: applicationFailure: {type: "dbConnectionDrop", duration: "10s"}.

[0079] containerFailure is a container-level failure, which means injecting a failure directly inside a specific container to evaluate the container's response and recovery capabilities when facing internal problems. type: "networkDelay" represents a container-level failure simulating network delay, delay: "10ms" specifies the duration of the delay, which is 10 milliseconds, and target: "abc" indicates that the target of the failure injection is the container named "abc", which can be used for simulating delays related to database services.

[0080] networkFailure is a network-level failure used to test the robustness of containerized applications at the network level, especially how container-to-container communication copes with network problems. type: "packetLoss" means simulating network packet loss, lossRate: "5%" specifies the proportion of packet loss, which is 5%, and targetPods: ["pod1", "pod2"] lists the affected containers or Pods, here referring to "pod1" and "pod2", and these two containers will undergo tests for network packet loss.

[0081] systemFailure is a system-level failure that focuses on the underlying system resources of containerized applications, such as CPU, memory, or disk. type: "memoryPressure" simulates memory pressure, threshold: "90%" defines that when the memory usage reaches 90%, failure injection is triggered, which helps evaluate the performance of the container under high memory load, including whether it can effectively manage resources to maintain the operation of basic services.

[0082] applicationFailure is an application-level failure that directly injects failures into the application programs running inside the container to test the stability and failure recovery capabilities of the application. type: "dbConnectionDrop" represents a failure simulating a database connection interruption, duration: "10s" indicates the duration of the connection interruption, which is 10 seconds, and this kind of test helps identify the processing logic of the application when the database connection is unavailable and its ability to restore the connection.

[0083] Step S2: The actuator injects a fault into pods with the same label under a specific namespace to complete the fault injection. For example, if we need to inject a 10 - ms network delay into a pod with the label "abc", we can find its corresponding port through that pod and then increase the port delay.

[0084] Introduce a dynamic fault injection mechanism that allows dynamic adjustment of fault types and parameters during testing. Use event - driven fault injection so that fault injection can respond to specific events (such as load changes, system resource status). For example, add an event listener to detect the status and events of the container cluster, such as CPU usage, memory usage, network traffic, etc. Design a configurable rule engine to dynamically trigger fault injection based on the detected events and rules. Integrate with the detection system to adjust the fault injection strategy based on real - time detection data.

[0085] Introduce a fault recovery time window to observe the system's recovery performance after fault injection. Add recovery logic to the fault injection framework. For example, wait for a period of time after injecting the fault to automatically restore the normal state of the container. Design a recovery strategy, such as restarting the container, restoring network configuration, cleaning up temporary files, etc. Record the system state before and after fault injection and compare and analyze the system performance and stability.

[0086] It can also be integrated with the continuous integration / continuous deployment (CI / CD) pipeline, taking the fault injection test as part of the CI / CD pipeline to ensure that fault injection tests are carried out before each deployment. Integrate with the automated test framework to automatically trigger fault injection tests. For example, develop a CI / CD plugin that can read the fault injection test configuration and automatically execute the test. Integrate with the build and deployment phases of the CI / CD tool to automatically insert fault injection tests at specific stages. Record the test results and summarize them with the results of other stages of the CI / CD to provide a comprehensive test report.

[0087] Step S3: The impact of fault injection on the application pod can be detected and viewed.

[0088] Set up a user - friendly interface and API. Provide a graphical user interface (GUI) that allows users to more intuitively configure and detect fault injection tests, enabling fault injection tests to be called and controlled by external systems. For example, design a user interface where users can input parameters for the fault test, such as fault type, delay time, trigger conditions, etc. Implement an API interface through which external systems can request to configure and trigger fault injection tests. Record and display the test results, and users can obtain detailed test reports through the interface or API.

[0089] The above optional embodiments achieve at least the following effects: improving the accuracy and efficiency of the destructive testing of the container cluster. By acting on pods with the same label in a specific namespace, the tool for fault injection solves the technical problem that the fault injection simulation can only be performed at the physical machine level and cannot be used in specific applications at the container level.

[0090] It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions. And, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0091] Embodiment 2

[0092] The embodiments of the present application also provide a container testing device. It should be noted that the container testing device of the embodiments of the present application can be used to execute the container testing method provided by the embodiments of the present application. The following introduces the container testing device provided by the embodiments of the present application.

[0093] According to the embodiments of the present application, there is also provided a device for implementing the above container testing method, as Figure 5 shown. The device includes: a first receiving module 502 for receiving test scenario information; a target determination module 504 for determining a target container on a node based on the test scenario information, where the target container and an actuator for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the actuator is configured to have cross-container interaction permissions on the node; a fault injection module 506 for using the actuator to perform fault injection processing on the target container to obtain fault manifestation information.

[0094] Optionally, in the container testing device provided by the embodiments of the present application, the target determination module includes: a parsing module for parsing the test scenario information to obtain a namespace to be tested; a namespace determination module for determining a target namespace that matches the namespace to be tested among M candidate namespaces deployed on the node, where the M candidate namespaces are isolated running environments and M is a positive integer; a first determination module for determining N containers deployed by the target namespace on the node as the target containers, where N is a positive integer.

[0095] Optionally, in the container testing device provided by the embodiments of the present application, the fault injection module includes: a second determination module for determining a fault type and fault parameters based on the test scenario information; a running environment determination module for entering the running environment of the target container according to the cross-container interaction permissions of the actuator; a fault manifestation information acquisition module for performing fault injection processing in the running environment based on the fault type and fault parameters to obtain fault manifestation information.

[0096] Optionally, in the container testing device provided in the embodiments of the present application, the fault injection module includes: a third determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is an application-level fault: application connection exception parameters of the internal application layer of the target container, application call exception parameters; a fourth determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is a network-level fault: network delay parameters, packet loss parameters, network connection parameters of the internal network layer of the target container; a fifth determination module, configured to determine that the fault parameters include at least one of the following when the test scenario information indicates that the fault type is a system-level fault: disk fault parameters, memory overflow parameters, central processing unit exception parameters of the internal system of the target container.

[0097] Optionally, in the container testing device provided in the embodiments of the present application, the first receiving module includes: a test requirement acquisition module, configured to acquire test requirements in natural language; a test instruction set generation module, configured to process the test requirements by using a target model to generate a test instruction set in natural language; wherein, the target model is trained based on historical test requirements and historical test instruction sets. A scenario information generation module, configured to convert the test instruction set into test scenario information in a target language in response to the confirmation process of the test instruction set.

[0098] Optionally, in the container testing device provided in the embodiments of the present application, the fault injection module includes: a self-healing performance information acquisition module, configured to determine the self-healing performance information of the target container within a predetermined time window based on the fault performance information; a policy determination module, configured to adjust the initial self-healing policy configured for the target container based on the self-healing performance information to obtain a target self-healing policy.

[0099] Optionally, in the container testing device provided in the embodiments of the present application, the fault injection module includes: a first information acquisition module, configured to perform a fault injection process on the target container based on an initial injection policy configured by an actuator to obtain initial performance information; an instruction adjustment module, configured to determine an adjustment instruction corresponding to a predetermined driving event when the initial performance information indicates that the target container has a predetermined driving event; a policy update module, configured to process the initial injection policy by using the adjustment instruction to obtain an updated injection policy; a second information acquisition module, configured to perform a fault injection process on the target container again according to the updated injection policy to obtain updated performance information; a third information acquisition module, configured to obtain fault performance information based on the initial performance information and the updated performance information.

[0100] The container testing device provided by the embodiment of the present application includes a first receiving module 502 for receiving test scenario information, a target determination module 504 for determining a target container on a node based on the test scenario information, where the target container and an actuator for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the actuator is configured to have cross-container interaction permissions on the node; and a fault injection module 506 that uses the actuator to perform fault injection processing on the target container to obtain fault manifestation information, solving the problem of unsatisfactory fault injection test accuracy in the related art. Furthermore, the effect of improving the fault injection test accuracy is achieved.

[0101] It should be noted here that the above-mentioned first receiving module 502, target determination module 504, and fault injection module 506 correspond to steps S102 to S106 in Embodiment 1. The instances and application scenarios implemented by the three modules and the corresponding steps are the same, but are not limited to the content disclosed in the above-mentioned Embodiment 1. It should be noted that the above-mentioned modules or units can be hardware components or software components stored in a memory (for example, memory 104) and processed by one or more processors (for example, processors 102a, 102b,..., 102n). The above-mentioned modules can also be part of the device and can run in the computer terminal 10 provided in Embodiment 1.

[0102] Embodiment 3

[0103] An embodiment of the present application can provide an electronic device. Figure 6 It is a structural block diagram of an electronic device according to an embodiment of the present application. As Figure 6 shown, the electronic device may include: one or more ( Figure 6 only one is shown in the figure) processors 602, a memory 604, a storage controller, and a peripheral interface, where the peripheral interface is connected to a radio frequency module, an audio module, and a display.

[0104] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implements the above-mentioned methods. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory may further include a memory remotely set relative to the processor, and these remote memories can be connected to the terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, enterprise intranets, local area networks, mobile communication networks, and their combinations.

[0105] The processor can call the information and application programs stored in the memory through the transmission device to execute the following steps: receiving test scenario information;

[0106] The processor can also call the information and application programs stored in the memory through the transmission device to execute the following steps: based on the test scenario information, determine a target container on the node, where the target container and the executor for performing the fault injection process are deployed on the node, the node is a host for deploying containers, and the executor is configured to have cross-container interaction permissions on the node;

[0107] The processor can also call the information and application programs stored in the memory through the transmission device to execute the following steps: use the executor to perform a fault injection process on the target container to obtain fault manifestation information.

[0108] By adopting the embodiment of the present application, a container testing solution is provided. By receiving test scenario information; based on the test scenario information, determining a target container on the node, where the target container and the executor for performing the fault injection process are deployed on the node, the node is a host for deploying containers, and the executor is configured to have cross-container interaction permissions on the node; using the executor to perform a fault injection process on the target container to obtain fault manifestation information, the purpose of improving the accuracy of fault injection testing is achieved, and furthermore, the technical problem of unsatisfactory accuracy of fault injection testing caused by manual operation is solved.

[0109] Those of ordinary skill in the art can understand that Figure 6 The structure shown is only schematic, and the electronic device can also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and terminal devices such as Mobile Internet Devices (MID), PAD, etc. Figure 6 It does not limit the structure of the above-mentioned electronic device. For example, the electronic device may further include more or fewer components (such as a network interface, a display device, etc.) than those shown in Figure 6 or have a different configuration from that shown in Figure 6 shown.

[0110] Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware of the terminal device through a program, and the program can be stored in a computer-readable storage medium. The storage medium may include: a flash drive, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disc, etc.

[0111] Embodiment 4

[0112] Embodiments of the present application also provide a storage medium. Optionally, in this embodiment, the above storage medium can be used to store the program code executed by the container testing method provided in the first embodiment above.

[0113] Optionally, in this embodiment, the above storage medium can be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.

[0114] The present application also provides a computer program product, which is adapted to execute a program for the steps of the container testing method when executed on a data processing device.

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

[0116] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0117] In several embodiments provided by the present 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 illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, 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 displayed or discussed mutual coupling or direct coupling or communication connection can be through some interfaces, and the indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0118] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0119] In addition, the functional units in the various embodiments of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0120] When 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 such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of this application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs.

[0121] The above are only the preferred embodiments of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and refinements can still be made, and these improvements and refinements should also be regarded as the protection scope of this application.

Claims

1. A container testing method, characterized in that: include: Receive test scenario information; Based on the test scenario information, determine a target container on a node, wherein the target container and an executor for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the executor is configured to have cross-container interaction permissions on the node; The executor is used to perform fault injection processing on the target container to obtain fault manifestation information.

2. The method according to claim 1, characterized in that The determining a target container on a node based on the test scenario information includes: Parsing the test scenario information to obtain a namespace to be tested; Determine a target namespace that matches the namespace to be tested among M candidate namespaces deployed on the node, wherein the M candidate namespaces are mutually isolated operating environments, and M is a positive integer; Determine N containers of the target namespace deployed on the node as the target containers, where N is a positive integer.

3. The method according to claim 1, characterized in that The adopting the executor to perform fault injection processing on the target container to obtain fault manifestation information includes: Based on the test scenario information, determining the fault type and fault parameters; Entering the operating environment of the target container according to the cross-container interaction permission of the executor; Based on the fault type and the fault parameter, a fault injection process is performed in the operating environment to obtain the fault manifestation information.

4. The method according to claim 3, characterized in that The determining of the fault type and fault parameters based on the test scenario information includes: In the case where the test scenario information indicates that the fault type is an application-level fault, determining that the fault parameter includes at least one of the following: an application connection exception parameter of the internal application layer of the target container, and an application call exception parameter; In the case where the test scenario information indicates that the fault type is a network-level fault, determining that the fault parameter includes at least one of the following: a network delay parameter, a packet loss parameter, and a network connection parameter of an internal network layer of the target container; In the case where the test scenario information indicates that the fault type is a system-level fault, determining the fault parameter includes at least one of the following: a disk fault parameter of the internal system of the target container, a memory overflow parameter, and a central processing unit abnormality parameter.

5. The method according to claim 1, characterized in that The method further comprises: Obtain test requirements using natural language; Using a target model to process the test requirements and generate the test instruction set in natural language, wherein the target model is obtained by training based on historical test requirements and historical test instruction sets; In response to the confirmation process of the test instruction set, the test instruction set is converted into the test scenario information in the target language.

6. The method according to claim 1, characterized in that After the executor is used to perform fault injection processing on the target container to obtain fault manifestation information, the method further includes: Based on the fault performance information, determine self-healing performance information of the target container within a predetermined time window; Based on the self-healing performance information, the initial self-healing strategy configured for the target container is adjusted to obtain a target self-healing strategy.

7. The method according to any one of claims 1 to 6, characterized in that The executor is used to perform fault injection processing on the target container to obtain fault manifestation information, which includes: Based on the initial injection strategy configured by the executor, perform fault injection processing on the target container to obtain initial performance information; When the initial performance information indicates that a predetermined driving event occurs in the target container, determining an adjustment instruction corresponding to the predetermined driving event; Using the adjustment instruction, the initial injection strategy is processed to obtain an updated injection strategy; According to the update injection strategy, the fault injection process is performed again on the target container to obtain update performance information; The fault manifestation information is obtained based on the initial manifestation information and the updated manifestation information.

8. A container testing device, characterized in that: include: A first receiving module, used to receive test scenario information; A target determination module, configured to determine a target container on a node based on the test scenario information, wherein the target container and an executor for performing fault injection processing are deployed on the node, the node is a host for deploying containers, and the executor is configured to have cross-container interaction permissions on the node; The fault injection module uses the executor to perform fault injection processing on the target container to obtain fault manifestation information.

9. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 7 when running.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the container testing method according to any one of claims 1 to 7.

Images