A chaos testing method and device for Kubernetes container platform

Abstract

The present invention discloses a chaos testing method and device for a Kubernetes container platform, and relates to the field of chaos engineering testing technology. A specific implementation of the method includes: deploying a corresponding k8s-chaos config map configmap in the namespace where k8s-chaos is to be run, so that k8s-chaos is run as a k8s application in a Kubernetes cluster; during the scheduling process, generating a list of k8s applications that meet the conditions; for the k8s applications in the k8s application list, determining whether the pod of the k8s application should be killed. This implementation can solve the technical problem that conventional testing cannot fully cope with Kubernetes clusters and various applications on clusters running on complex networks and architectures.

Description

Technical Field

[0001] The present invention relates to the field of chaos engineering testing technology, and in particular to a chaos testing method and device for a Kubernetes container platform. Background Art

[0002] As the focus of cloud development shifts to containers, container-related technologies such as Kubernetes have become very popular. As testers, our main goal is to ensure that the product is fully quality tested and delivered with high quality. To achieve these goals, unit testing, interface testing, integration testing, stress testing, etc. are required to detect unexpected behaviors and ensure that the test mode does not cause errors.

[0003] Usually, the Kubernetes platform contains many components at the bottom layer, but unit and integration tests often cannot fully cover these components. Some servers and components may still drag the entire system into the abyss when they fail. At the same time, various failures may occur at any time and anywhere, and many of them are unavoidable, such as a sudden failure of the disk or a sudden loss of network and power in the computer room. These failures may cause the collapse of the Kubernetes system and are difficult to recover.

[0004] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0005] Conventional testing cannot fully handle the various applications running on Kubernetes clusters and clusters based on complex networks and architectures. Summary of the invention

[0006] In view of this, an embodiment of the present invention provides a chaos testing method and device for a Kubernetes container platform to solve the technical problem that conventional testing cannot fully cope with various applications running on a Kubernetes cluster and cluster based on a complex network and architecture.

[0007] To achieve the above object, according to one aspect of an embodiment of the present invention, a chaos testing method for a Kubernetes container platform is provided, comprising:

[0008] Deploy the corresponding k8s-chaos config mapconfigmap in the namespace where you want to run k8s-chaos, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster;

[0009] During the scheduling process, a list of k8s applications that meet the conditions is generated;

[0010] For the k8s application in the k8s application list, determine whether the pod of the k8s application should be killed.

[0011] Optionally, the namespace is kube-system.

[0012] Optionally, for a k8s application in the k8s application list, determining whether a pod of the k8s application should be killed includes:

[0013] For a k8s application in the k8s application list, flip a biased coin to determine whether the pod of the k8s application should be killed.

[0014] Optionally, the coin is biased by k8s-chaos / mtbf.

[0015] Optionally, to determine whether the pod of the k8s application should be killed, including:

[0016] Calculate a random time to determine when the pod of the k8s application will be killed.

[0017] Optionally, it also includes:

[0018] When the random time is reached, check whether the k8s application still meets the conditions. If so, check whether the k8s application has updated the kill mode and kill value.

[0019] Optionally, the condition includes at least one of the following:

[0020] Not opted out, blacklisted, or removed from whitelist.

[0021] Optionally, after checking whether the k8s application has updated the kill mode and kill value, it further includes:

[0022] If so, the Pod is executed according to the kill mode and kill value.

[0023] Optionally, the k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml.

[0024] Optionally, before deploying the corresponding k8s-chaos config mapconfigmap in the namespace where you want to run k8s-chaos, also include:

[0025] Create k8s-chaos config map configmap;

[0026] Deploy a Kubernetes cluster.

[0027] In addition, according to another aspect of an embodiment of the present invention, a chaos device for a Kubernetes container platform is provided, including:

[0028] The deployment module is used to deploy the corresponding k8s-chaos configmap configmap in the namespace where k8s-chaos is to be run, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster;

[0029] The scheduling module is used to generate a list of k8s applications that meet the conditions during the scheduling process;

[0030] A determination module is used to determine whether the pod of the k8s application in the k8s application list should be killed.

[0031] Optionally, the namespace is kube-system.

[0032] Optionally, the determining module is further used for:

[0033] For a k8s application in the k8s application list, flip a biased coin to determine whether the pod of the k8s application should be killed.

[0034] Optionally, the coin is biased by k8s-chaos / mtbf.

[0035] Optionally, the determining module is further used for:

[0036] Calculate a random time to determine when the pod of the k8s application will be killed.

[0037] Optionally, the determining module is further used for:

[0038] When the random time is reached, check whether the k8s application still meets the conditions. If so, check whether the k8s application has updated the kill mode and kill value.

[0039] Optionally, the condition includes at least one of the following:

[0040] Not opted out, blacklisted, or removed from whitelist.

[0041] Optionally, the determining module is further used for:

[0042] After checking whether the k8s application has updated the kill mode and kill value, if so, execute the Pod according to the kill mode and kill value.

[0043] Optionally, the k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml.

[0044] Optionally, the deployment module is further used to:

[0045] Create the k8s-chaos config map configmap before deploying the corresponding k8s-chaos config map configmap in the namespace where you want to run k8s-chaos;

[0046] Deploy a Kubernetes cluster.

[0047] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, including:

[0048] one or more processors;

[0049] a storage device for storing one or more programs,

[0050] When the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any one of the above embodiments.

[0051] According to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described in any one of the above embodiments is implemented.

[0052] An embodiment of the above invention has the following advantages or beneficial effects: because the corresponding k8s-chaos config map configmap is deployed in the namespace where k8s-chaos is to be run, so that k8s-chaos is run in the Kubernetes cluster as a k8s application, a list of qualified k8s applications is generated during the scheduling process, and for the k8s applications in the k8s application list, a technical means is used to determine whether the pod of the k8s application should be killed, so the conventional test in the prior art cannot fully cope with the technical problem of various applications on Kubernetes clusters and clusters running on complex networks and architectures. Testers can effectively obtain the changes of various resources in the cluster operation and the reasons for the occurrence directly from the front end. K8s-chaos is a tool that follows the principles of chaos engineering, which can randomly delete Kubernetes pods, check whether the service has anti-failure capabilities and help maintain the healthy operation of related systems. K8s-chaos can also be configured via yaml files, and yaml files can not only terminate specified applications, but also determine the execution time of recovery strategies.

[0053] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0055] Figure 1 It is a schematic diagram of the main process of the chaos testing method for the Kubernetes container platform according to an embodiment of the present invention;

[0056] Figure 2 is a schematic diagram of a config.toml file of k8s-chaos according to an embodiment of the present invention;

[0057] Figure 3 is a schematic diagram of the environment variables of k8s-chaos according to an embodiment of the present invention;

[0058] Figure 4 is a flowchart of the k8s-chaos solution according to an embodiment of the present invention;

[0059] Figure 5 is a schematic diagram of the opt-in mode of k8s-chaos according to an embodiment of the present invention;

[0060] Figure 6is a schematic diagram of main modules of a chaos device for a Kubernetes container platform according to an embodiment of the present invention;

[0061] Figure 7 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0062] Figure 8 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0063] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0064] Figure 1 Schematic diagram of the main process of the chaos testing method for Kubernetes container platform according to an embodiment of the present invention. Figure 1 As shown, the chaos testing method for the Kubernetes container platform may include:

[0065] Step 101, deploy the corresponding k8s-chaos config mapconfigmap in the namespace where k8s-chaos is to run, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster.

[0066] Optionally, the namespace is kube-system. First, deploy the corresponding k8s-chaos config map configmap in the namespace (e.g., kube-system) where k8s-chaos is to be run, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster. It should be noted that in this step, make sure to define keyname as config.toml.

[0067] Kubernetes is a container orchestration platform widely used in microservice deployment. Chaos engineering practices help build resilient systems. In order to more conveniently and comprehensively verify the tolerance of the Kubernetes system platform to various faults, the Kubernetes-based chaos test k8s-chaos came into being.

[0068] Optionally, before step 101, it also includes: creating a k8s-chaos config map configmap; deploying a Kubernetes cluster. Regarding the configuration of k8s-chaos, k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml, and the configmap should be created before kubemonkey deployment. Configuration keys and instructions can be found in config / param / param.go. The sample config.toml file is as follows: Figure 2 As shown, the environment variable examples are as follows Figure 3 shown.

[0069] In an embodiment of the present invention, a user can create or update a Chaos object to a Kubernetes API Server through a YAML file or a Kubernetes client. k8s-chaos creates, updates, or deletes events of Chaos objects in the watch API Server to maintain the operation and life cycle of a specific Chaos experiment. In this process, controller-manager, chaos-daemon, and sidecar containers work together to provide error injection capabilities. Admission-webhooks is an HTTP callback service for receiving admission requests. When a Pod creation request is received, the Pod object to be created will be dynamically modified, such as Figure 4 shown.

[0070] k8s-chaos adopts the opt-in mode, such as Figure 5 As shown, Kubernetes (k8s) applications that agree to have their pods terminated by k8s-chaos will be scheduled for termination. Opting in is done by setting the following label on the k8s application:

[0071] k8s-chaos / enabled: Set to "enabled" to opt-in to k8s-chaos

[0072] k8s-chaos / mtbf: mean time between failures (days)

[0073] k8s-chaos / identifier: Unique identifier of the k8s application. Used to identify pods belonging to the k8s application. Since pods inherit labels from their k8s applications, if k8s-chaos detects that app foo has registered as a victim, k8s-chaos will look for all pods with the label k8s-chaos / identifier:foo to determine which pods may be killed. It is recommended to set this value to the same as the application name.

[0074] k8s-chaos / kill mode: The default behavior is for k8s-chaos to kill only one pod of your application. This behavior can be overridden by setting the value to the following:

[0075] "kill-all" If you want k8s-chaso to kill all pods in the current kubernetes cluster, regardless of the pod status. You do not need to set kill-value, but be sure to use this tag with caution

[0076] Fixed can kill a specific number of running pods with a kill value. If overspecified, all running pods will be killed and a warning will be issued.

[0077] random max percent specifies the maximum percentage, including the termination value, that can be terminated. Once the scheduled time is reached, the uniformly randomly specified % of running Pods will be terminated.

[0078] fixed percent specifies a fixed percentage whose kill value can be terminated. At the scheduled time, the specified fixed % of running Pods will be terminated.

[0079] k8s-chaos runs on weekdays at pre-configured hours (runtime hours, default is 8am) and builds deployments that will face random Pod deaths at some point in the same day. The time range of random deaths in a day is configurable and defaults to 10am to 4pm. k8s-chaos can be configured with a list of namespaces to blacklist (any deployments in the blacklisted namespaces will not be touched) To disable blacklisting, provide [""] in the blacklisted namespace config.param.

[0080] Step 102, during the scheduling process, generate a list of k8s applications that meet the conditions.

[0081] During the working day, a schedule is arranged every day, and the Termination schedule for the day is generated. During the scheduling process, k8s-chaos will generate a list of eligible k8s applications, such as k8s applications that have opted in and are not blacklisted.

[0082] Step 103, for the k8s application in the k8s application list, determine whether the pod of the k8s application should be killed.

[0083] Optionally, step 103 may include: for a k8s application in the k8s application list, flipping a biased coin to determine whether the pod of the k8s application should be killed. Optionally, the coin is biased by k8s-chaos / mtbf. Optionally, to determine whether the pod of the k8s application should be killed, including: calculating a random time to determine when the pod of the k8s application will be killed.

[0084] For eligible k8s applications, flip a biased coin (bias determined by k8s-chaos / mtbf) to determine whether the pod of the k8s application should be killed. For each target object, a random time is calculated to determine when the pod will be killed. Optionally, the condition includes at least one of the following: not opting out, being blacklisted, or being removed from the whitelist.

[0085] Optionally, it also includes: when the random time is reached, checking whether the k8s application still meets the conditions, and if so, checking whether the k8s application has updated the kill mode and kill value. Optionally, after checking whether the k8s application has updated the kill mode and kill value, it also includes: if so, executing the Pod according to the kill mode and kill value.

[0086] Termination time: This is a randomly generated time, when a Pod in the target k8s application will be killed on a certain day. When the termination time comes, k8s-chaos checks whether the k8s application still meets the conditions (after scheduling, it has not chosen to exit or been blacklisted or deleted from the whitelist), and checks whether the k8s application has updated the kill mode and kill value. If so, execute the Pod according to the kill mode and kill value.

[0087] According to the various embodiments described above, it can be seen that the embodiment of the present invention deploys the corresponding k8s-chaos config map configmap in the namespace where k8s-chaos is to be run, so that k8s-chaos is run in the Kubernetes cluster as a k8s application. During the scheduling process, a list of k8s applications that meet the conditions is generated. For the k8s applications in the k8s application list, the technical means for determining whether the pod of the k8s application should be killed solves the technical problem that conventional tests in the prior art cannot fully cope with the various applications running on the Kubernetes cluster and the cluster based on complex networks and architectures. Testers can effectively obtain the changes in various resources and the reasons for the occurrence of the changes in the cluster operation directly from the front end. K8s-chaos is a tool that follows the principles of chaos engineering, which can randomly delete Kubernetes pods, check whether the service has anti-failure capabilities and help maintain the healthy operation of related systems. K8s-chaos can also be configured via yaml files, and yaml files can not only terminate the specified application, but also determine the execution time of the recovery strategy.

[0088] Figure 6 is a schematic diagram of main modules of a chaos device for a Kubernetes container platform according to an embodiment of the present invention, such as Figure 6 As shown, the chaos device 600 for the Kubernetes container platform includes a deployment module 601, a scheduling module 602 and a determination module 603; wherein the deployment module 601 is used to deploy the corresponding k8s-chaos config map configmap in the namespace where k8s-chaos is to be run, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster; the scheduling module 602 is used to generate a list of k8s applications that meet the conditions during the scheduling process; the determination module 603 is used to determine whether the pod of the k8s application in the k8s application list should be killed.

[0089] Optionally, the namespace is kube-system.

[0090] Optionally, the determining module 603 is further configured to:

[0091] For a k8s application in the k8s application list, flip a biased coin to determine whether the pod of the k8s application should be killed.

[0092] Optionally, the coin is biased by k8s-chaos / mtbf.

[0093] Optionally, the determining module 603 is further configured to:

[0094] Calculate a random time to determine when the pod of the k8s application will be killed.

[0095] Optionally, the determining module 603 is further configured to:

[0096] When the random time is reached, check whether the k8s application still meets the conditions. If so, check whether the k8s application has updated the kill mode and kill value.

[0097] Optionally, the condition includes at least one of the following:

[0098] Not opted out, blacklisted, or removed from whitelist.

[0099] Optionally, the determining module 603 is further configured to:

[0100] After checking whether the k8s application has updated the kill mode and kill value, if so, execute the Pod according to the kill mode and kill value.

[0101] Optionally, the k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml.

[0102] Optionally, the deployment module 601 is further used to:

[0103] Create the k8s-chaos config map configmap before deploying the corresponding k8s-chaos config map configmap in the namespace where you want to run k8s-chaos;

[0104] Deploy a Kubernetes cluster.

[0105] According to the various embodiments described above, it can be seen that the embodiment of the present invention deploys the corresponding k8s-chaos config map configmap in the namespace where k8s-chaos is to be run, so that k8s-chaos is run in the Kubernetes cluster as a k8s application. During the scheduling process, a list of k8s applications that meet the conditions is generated. For the k8s applications in the k8s application list, the technical means for determining whether the pod of the k8s application should be killed solves the technical problem that conventional tests in the prior art cannot fully cope with the various applications running on the Kubernetes cluster and the cluster based on complex networks and architectures. Testers can effectively obtain the changes in various resources and the reasons for the occurrence of the changes in the cluster operation directly from the front end. K8s-chaos is a tool that follows the principles of chaos engineering, which can randomly delete Kubernetes pods, check whether the service has anti-failure capabilities and help maintain the healthy operation of related systems. K8s-chaos can also be configured via yaml files, and yaml files can not only terminate the specified application, but also determine the execution time of the recovery strategy.

[0106] It should be noted that the specific implementation content of the chaos device for the Kubernetes container platform described in the present invention has been described in detail in the chaos testing method for the Kubernetes container platform described above, so the repeated content will not be described here.

[0107] Figure 7 An exemplary system architecture 700 is shown to which a chaos testing method for a Kubernetes container platform or a chaos device for a Kubernetes container platform according to an embodiment of the present invention can be applied.

[0108] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, 703, network 704 and server 705. Network 704 is used to provide a medium for communication links between terminal devices 701, 702, 703 and server 705. Network 704 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0109] Users can use terminal devices 701, 702, and 703 to interact with server 705 through network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0110] The terminal devices 701 , 702 , and 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0111] Server 705 may be a server that provides various services, such as a backend management server (for example only) that provides support for shopping websites browsed by users using terminal devices 701, 702, and 703. The backend management server may analyze and process the received data such as item information query requests, and feed back the processing results to the terminal device.

[0112] It should be noted that the chaos testing method for the Kubernetes container platform provided in the embodiment of the present invention is generally executed by the server 705. Accordingly, the chaos device for the Kubernetes container platform is generally set in the server 705.

[0113] It should be understood that Figure 7 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0114] Reference below Figure 8 , which shows a schematic diagram of the structure of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0115] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0116] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, etc.; an output section 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage section 808 as needed.

[0117] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are executed.

[0118] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0119] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0120] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes a deployment module, a scheduling module and a determination module, wherein the names of these modules do not constitute a limitation on the modules themselves in some cases.

[0121] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device implements the following method: deploy the corresponding k8s-chaos config mapconfigmap in the namespace where k8s-chaos is to be run, so that k8s-chaos is run as a k8s application in the Kubernetes cluster; during the scheduling process, generate a list of k8s applications that meet the conditions; for the k8s applications in the k8s application list, determine whether the pod of the k8s application should be killed.

[0122] According to the technical solution of the embodiment of the present invention, because the corresponding k8s-chaos config map configmap is deployed in the namespace where k8s-chaos is to be run, so that k8s-chaos is run in the Kubernetes cluster as a k8s application, a list of qualified k8s applications is generated during the scheduling process, and for the k8s applications in the k8s application list, a technical means is used to determine whether the pod of the k8s application should be killed, so the conventional test in the prior art cannot fully cope with the technical problem of various applications on the Kubernetes cluster and the cluster running on the basis of complex network and architecture. Testers can effectively obtain the changes of various resources in the cluster operation and the reasons for the occurrence directly from the front end. K8s-chaos is a tool that follows the principles of chaos engineering, which can randomly delete Kubernetes pods, check whether the service has the ability to resist failure and help maintain the healthy operation of related systems. K8s-chaos can also be configured via yaml files, and yaml files can not only terminate the specified application, but also determine the execution time of the recovery strategy.

[0123] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A chaos testing method for Kubernetes container platform, characterized in that: include: Deploy the corresponding k8s-chaos config map configmap in the namespace where you want to run k8s-chaos, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster; the k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml, and the configmap is created before kubemonkey is deployed; k8s-chaos uses opt-in mode, and will schedule a termination time for k8s applications that agree to have their pods terminated by k8s-chaos; During the scheduling process, a list of k8s applications that meet the conditions is generated; For a k8s application in the k8s application list, determine whether the pod of the k8s application should be killed; For a k8s application in the k8s application list, determining whether the pod of the k8s application should be killed includes: For a k8s application in the k8s application list, flip a biased coin to determine whether the pod of the k8s application should be killed; the coin is biased by k8s-chaos / mtbf; To determine whether the pod of the k8s application should be killed, including: Calculate a random time to determine when the pod of the k8s application will be killed; Also includes: When the random time is reached, check whether the k8s application still meets the conditions, and if so, check whether the k8s application has updated the kill mode and kill value; After checking whether the k8s application has updated the kill mode and kill value, it also includes: If so, the Pod is executed according to the kill mode and kill value.

2. The method according to claim 1, characterized in that The namespace is kube-system.

3. The method according to claim 1, characterized in that The conditions include at least one of the following: Not opted out, blacklisted, or removed from whitelist.

4. The method according to claim 1, characterized in that: Before deploying the corresponding k8s-chaos config map configmap in the namespace where you want to run k8s-chaos, also include: Create k8s-chaos config map configmap; Deploy a Kubernetes cluster.

5. A chaos device for Kubernetes container platform, characterized in that: include: The deployment module is used to deploy the corresponding k8s-chaos config mapconfigmap in the namespace where k8s-chaos is to be run, so that k8s-chaos can be run as a k8s application in the Kubernetes cluster; the k8s-chaos is configured by environment variables or a toml file located at / etc / k8s-chaos / config.toml, and the configmap is created before the kubemonkey deployment; k8s-chaos uses the opt-in mode, and will schedule the termination time for k8s applications that agree to have their pods terminated by k8s-chaos; The scheduling module is used to generate a list of k8s applications that meet the conditions during the scheduling process; A determination module is used to determine whether the pod of the k8s application in the k8s application list should be killed; The determining module is also used for: For a k8s application in the k8s application list, flip a biased coin to determine whether the pod of the k8s application should be killed; the coin is biased by k8s-chaos / mtbf; The determining module is also used for: Calculate a random time to determine when the pod of the k8s application will be killed; The determining module is also used for: When the random time is reached, check whether the k8s application still meets the conditions, and if so, check whether the k8s application has updated the kill mode and kill value; The determining module is also used for: After checking whether the k8s application has updated the kill mode and kill value, if so, execute the Pod according to the kill mode and kill value.

6. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 4.

7. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

Images