Kubernetes cluster simulation test method, device, equipment, storage medium and product

Abstract

The application discloses a Kubernetes cluster simulation test method, device, equipment, storage medium and product, the method comprises the following steps: in response to a simulation test request, automatically creating a virtual node, and configuring a state-driven controller for the virtual node; wherein the state-driven controller is used for operating a Kubernetes API resource to simulate the life cycle of the virtual node and a workload; in response to a creation event of the virtual node, triggering control plane load interaction simulation; in response to a creation event of a container on the virtual node, triggering cluster plugin pressure simulation. The application introduces automatic node creation, Kubelet behavior simulation and cluster plugin pressure simulation on the basis of the lightweight resource state simulation architecture of KWOK, so that the multi-dimensional load influence of a large-scale Kubernetes cluster on the control plane can be simulated more truly under lower resource overhead.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a Kubernetes cluster simulation testing method, apparatus, device, storage medium, and product. Background Technology

[0002] With the development of cloud computing and artificial intelligence, the scale of Kubernetes (K8s) clusters continues to expand, placing higher demands on the performance and stability of control plane components (such as kube-apiserver, kube-controller-manager, etcd, and kube-scheduler) under high concurrency and large-scale scenarios. Due to the high cost of physical resources, testing and verifying such large-scale Kubernetes solutions using a real cluster environment is extremely difficult. Therefore, testing technologies that simulate large-scale Kubernetes clusters have emerged. Currently, the mainstream Kubernetes simulation technologies in the industry include the HollowNode simulation system represented by Kubemark and the resource state-driven simulation system represented by KWOK (Kubernetes WithOut Kubelet). However, both still have significant shortcomings in terms of scalability, realism, and automation, including high resource overhead, uncontrollable object lifecycles, unrealistic simulated loads, lack of automated node creation mechanisms, and limited resource simulation dimensions. Summary of the Invention

[0003] The purpose of this invention is to provide a Kubernetes cluster simulation testing method, apparatus, device, storage medium, and product. Based on the lightweight resource state simulation architecture of KWOK, it introduces automatic node creation, Kubelet behavior simulation, and cluster plugin stress simulation, thereby more realistically simulating the multi-dimensional load impact of large-scale Kubernetes clusters on the control plane with lower resource overhead.

[0004] To achieve the above objectives, embodiments of the present invention provide a Kubernetes cluster simulation testing method, including: In response to a simulation test request, a virtual node is automatically created, and a state-driven controller is configured for the virtual node; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual node and the workload; In response to the creation event of the virtual node, a control plane load interaction simulation is triggered; In response to the container creation event on the virtual node, cluster plugin stress simulation is triggered.

[0005] As an improvement to the above solution, the step of automatically creating virtual nodes in response to simulation test requests and configuring state-driven controllers for the virtual nodes includes: In response to a simulation test request, a corresponding virtual node is automatically created based on predefined parameters in the simulation test request, and a label is added to the virtual node; wherein the label corresponds to the state-driven controller; Configure the state-driven controller and the filtering rules of the state-driven controller for the virtual node based on the label.

[0006] As an improvement to the above scheme, the state-driven controller includes a node lease controller, a node controller, a container controller, and a phase rule controller.

[0007] As an improvement to the above scheme, the step of triggering control plane load interaction simulation in response to the creation event of the virtual node includes: In response to the creation event of the virtual node, the authentication process and List-Watch listening process of the Kubelet in each virtual node are automatically simulated; wherein, the List-Watch listening process adopts a lightweight event listener that removes caching and queue mechanisms.

[0008] As an improvement to the above scheme, the step of triggering cluster plugin stress simulation in response to the container creation event on the virtual node includes: In response to the container creation event on the virtual node, CNI network allocation behavior and DNS query behavior caused by the container are automatically simulated.

[0009] As an improvement to the above solution, the method further includes: The frequency of DNS queries to be initiated is dynamically calculated based on the number of virtual nodes managed by the state-driven controller and the number of containers running on all managed virtual nodes.

[0010] This invention also provides a Kubernetes cluster simulation testing device, comprising: A virtual node creation module is used to automatically create virtual nodes in response to simulation test requests and configure state-driven controllers for the virtual nodes; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual nodes and workloads; The control plane interaction simulation module is used to trigger control plane load interaction simulation in response to the creation event of the virtual node; The cluster plugin stress simulation module is used to trigger cluster plugin stress simulation in response to the container creation event on the virtual node.

[0011] This invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the Kubernetes cluster simulation test method described in any of the preceding embodiments.

[0012] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the Kubernetes cluster simulation test method described above.

[0013] This invention also provides a computer program product, which includes a computer program or computer instructions, wherein the computer program or computer instructions, when executed by a processor, implement the Kubernetes cluster simulation test method described above.

[0014] Compared to existing technologies, the beneficial effects of the Kubernetes cluster simulation testing method, apparatus, device, storage medium, and product provided in this invention are as follows: Virtual nodes are automatically created in response to simulation test requests, and state-driven controllers are configured for the virtual nodes; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual nodes and workloads; control plane load interaction simulation is triggered in response to the creation event of the virtual node; and cluster plugin stress simulation is triggered in response to the creation event of containers on the virtual node. Based on the lightweight resource state simulation architecture of KWOK, this invention introduces automatic node creation, Kubelet behavior simulation, and cluster plugin stress simulation, thereby more realistically simulating the multi-dimensional load impact of large-scale Kubernetes clusters on the control plane with lower resource overhead. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a preferred embodiment of a Kubernetes cluster simulation testing method provided by the present invention; Figure 2 This is a schematic diagram of the Kubernetes cluster simulation architecture in a Kubernetes cluster simulation testing method provided by the present invention; Figure 3 This is a schematic diagram illustrating the automated creation of virtual nodes in a Kubernetes cluster simulation testing method provided by this invention; Figure 4 This is a schematic diagram of control plane load interaction simulation in a Kubernetes cluster simulation testing method provided by the present invention; Figure 5 This is a schematic diagram illustrating the stress simulation of cluster plugins in a Kubernetes cluster simulation testing method provided by the present invention; Figure 6 This is a schematic diagram of a preferred embodiment of a Kubernetes cluster simulation testing device provided by the present invention; Figure 7 This is a schematic diagram of a preferred embodiment of a terminal device provided by the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Please see Figure 1 , Figure 1 This is a flowchart illustrating a preferred embodiment of a Kubernetes cluster simulation testing method provided by the present invention. The Kubernetes cluster simulation testing method includes: S1, in response to a simulation test request, automatically create a virtual node and configure a state-driven controller for the virtual node; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual node and the workload; S2, in response to the creation event of the virtual node, trigger control plane load interaction simulation; S3, in response to the container creation event on the virtual node, triggers cluster plugin stress simulation.

[0018] It's important to note that Kubemark is an early simulation tool provided by Kubernetes, designed to test the performance limits of the Kubernetes control plane without actually scheduling and running container workloads. Its core idea is to run control plane components (such as kube-apiserver, controller-manager, scheduler, etcd) on a real Kubernetes Master node; and to simulate thousands of nodes using one or more special "HollowNode" Pods. These HollowNodes are not real worker nodes but run a simplified version of Kubelet (called HollowKubelet). HollowKubelet contains all the functional modules of a full Kubelet, simulating real node list-watching and periodically reporting node status, Pod creation status, and responding to probes to the kube-apiserver, simulating the behavior of real nodes but not performing actual container, network, or storage operations. However, Kubemark runs as Pods, and each Pod can only simulate one node. Therefore, when simulating large-scale Kubernetes clusters, the number of real nodes is still limited by the number of Pods that can run on a single Kubernetes node.

[0019] KWOK is a next-generation Kubernetes simulator open-sourced by the CNCF, designed to simulate the behavior of Kubernetes Nodes and Pods in a lightweight, flexible, and configurable manner, offering enhanced scalability and controllability. Its core design philosophy is complete independence from Kubelet, Container Runtime, and real container environments. KWOK implements a "simulated Kubelet," not a "simplified version" of kubemark. It simulates Kubelet behavior by manipulating resources such as Nodes, Leases, and Pods through the Kubernetes API, making it appear to users, from the perspective of the Kube-APIServer, as if a corresponding worker node exists within the cluster. KWOK allows users to define object state transitions through Stage rules, defining the complete lifecycle of a certain type of object through multiple Stage rules. Unlike Kubemark, a single KWOK instance supports simulating multiple nodes, multiple Pods, and multiple state transitions. Essentially, it acts as a Stage controller, simulating resource lifecycles according to user-defined Stage rules, consuming virtually no CPU or memory resources, and capable of simulating clusters with hundreds of thousands of nodes. Although KWOK is essentially a controller, it has "distributed" simulation capabilities. Multiple KWOK instances can be deployed in DaemonSet mode, with each instance controlling an independent set of nodes, supporting large-scale distributed simulation.

[0020] However, both still have significant shortcomings in terms of scalability, realism, and automation. For example, Kubemark suffers from high resource overhead and uncontrollable object lifecycles. Each HollowNode is simulated by a Pod, and due to Kubelet performance limitations, each node can only run 100-200 Pods, thus requiring a large amount of resources to simulate large-scale clusters. It cannot flexibly control the state changes of Pods, Nodes, and other objects, making it unsuitable for constructing customized test scenarios. KWOK suffers from unrealistic load simulation, a lack of automated node creation mechanisms, and limited resource simulation dimensions. KWOK does not contain real Kubelet logic, making it difficult to reproduce the real load under high-concurrency control plane scenarios. This is mainly reflected in the lack of List-Watch behavior with Kube-APIServer, making it impossible to reproduce the access pressure of Kube-APIServer; and the lack of Kubelet certificate rotation and authentication processes, making it impossible to reproduce the actual pressure of the NodeAuthorization authentication module in Kube-APIServer. Unlike Kubemark, which can automatically register virtual Nodes, KWOK currently requires users to manually create virtual nodes and configure management, resulting in a cumbersome deployment process. The resource interaction pressure of key system components, such as DNS query pressure and IPAM resource consumption of CNI plugins, is not covered.

[0021] Based on this, this invention, building upon KWOK's lightweight resource state simulation architecture, designs and implements an enhanced Kubernetes cluster simulation system, introducing automatic node creation, Kubelet behavior simulation, and cluster plugin stress simulation. For details, please refer to... Figure 2 , Figure 2This is a schematic diagram of the Kubernetes cluster simulation architecture in a Kubernetes cluster simulation testing method provided by this invention. In this embodiment, the Kubernetes cluster simulation architecture introduces three modules on top of KWOK: FakeNodeFactory, KubeletSimulator, and AddonsPressureEmulator. In response to a simulation test request, virtual nodes are automatically created through FakeNodeFactory, and a state-driven controller is configured for each virtual node, i.e., the KWOK controller is configured. The state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of virtual nodes and workloads. After configuring the state-driven controller, it is started to simulate the Kubelet behavior of the virtual nodes. In Kubernetes, Kubelet is the core proxy component on worker nodes (Nodes), responsible for managing containerized applications on the nodes. Its core behaviors include the following key functions: command listening and execution: continuously listening to commands from the Kube-APIServer (such as Pod creation, update, or deletion requests); and driving container runtime (such as containerd or Docker) to perform operations based on commands: downloading container images, starting / stopping containers, and managing container lifecycles. Status Monitoring and Reporting: Real-time monitoring of the status of Pods and containers running on nodes (e.g., CPU / memory usage, process health); periodic reporting of node and Pod status (including Ready / NotReady, resource utilization, etc.) to the Kube-APIServer; execution of health check probes (e.g., livenessProbe and readinessProbe); automatic restart of faulty containers. Resource Management: Enforcing resource limits (CPU, memory quotas) for Pods via cgroups; managing local storage volumes (e.g., emptyDir) and network namespace isolation. Certificate and Security Interaction: Handling Bootstrap Token authentication during node registration; periodically rotating kubelet client certificates to ensure secure communication with the Kube-APIServer. In response to virtual node creation events, triggering the KubeletSimulator for control plane load interaction simulation. In response to container creation events on virtual nodes, triggering the AddonsPressureEmulator for cluster plugin stress simulation, thereby achieving a more realistic simulation of the multi-dimensional load impact of ultra-large-scale Kubernetes clusters on the control plane with lower resource overhead.

[0022] In a preferred embodiment, step S1, in response to a simulation test request, automatically creates a virtual node and configures a state-driven controller for the virtual node, including: S11, in response to a simulation test request, automatically create a corresponding virtual node according to the predefined parameters in the simulation test request, and add a label to the virtual node; wherein, the label corresponds to the state-driven controller; S12, Configure the state-driven controller and the filtering rules of the state-driven controller for the virtual node based on the label.

[0023] For details, please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating the automated creation of virtual nodes in a Kubernetes cluster simulation testing method provided by this invention. This embodiment of the invention replaces the manual virtual node creation process with the FakeNodeFactory module. When each KWOK Controller instance starts, FakeNodeFactory reads user-defined parameters, such as the number of virtual nodes to be created and node templates, renders the Node template, and automatically creates virtual Node resources in batches. Furthermore, FakeNodeFactory adds specific tags to these virtual Nodes to distinguish which KWOK Controller created them. Then, using these specific tags, FakeNodeFactory configures the state-driven controller, i.e., the KWOK Controller, and the filtering rules for all controllers within the KWOK Controller, ensuring that subsequent controllers only manage these automatically created virtual Nodes and the resources on those Nodes after startup. This mechanism significantly improves deployment efficiency and supports the needs of multi-instance distributed simulation in DaemonSet mode, enhancing the system's scalability and cluster-scale simulation capabilities.

[0024] In another preferred embodiment, the state-driven controller includes a node lease controller, a node controller, a container controller, and a phase rule controller.

[0025] Specifically, in this embodiment of the invention, the state-driven controller, i.e., the KWOK Controller, includes a Node Lease Controller, a Node Controller, a Pod Controller, and a Stage Controller. The Node Lease Controller maintains the Ready state of virtual nodes by periodically updating Lease resources to simulate node heartbeats, replacing the NodeStatus update behavior of a real Kubelet. The Node Controller manages the entire lifecycle of virtual nodes, such as creation, deletion, and status changes, simulating node registration, resource allocation, and fault injection. The Pod Controller listens for Pod events, such as creation and deletion, and triggers the AddonsPressureEmulator to simulate CNIIP allocation and DNS query load. The Stage Controller parses user-defined Stage rules (YAML) and dynamically modifies resource states, such as updating the Pod status from Pending to Running.

[0026] In yet another preferred embodiment, step S2, in response to the creation event of the virtual node, triggers a control plane load interaction simulation, including: S21, in response to the creation event of the virtual node, automatically simulate the authentication process and List-Watch listening process of the Kubelet in each virtual node; wherein, the List-Watch listening process adopts a lightweight event listener that removes caching and queue mechanisms.

[0027] For details, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the control plane load interaction simulation in a Kubernetes cluster simulation testing method provided by this invention. To simulate the interaction pressure between a real Kubelet and the Kube-APIServer, this embodiment of the invention introduces the KubeletSimulator module. After the NodeController detects the creation event of a virtual node, the KubeletSimulator module automatically simulates the Kubelet authentication process and List-Watch listening process for each virtual node. The KubeletSimulator module solves the problem of KWOK's lack of control plane simulation capabilities and can be used to evaluate the performance bottleneck of the Kube-APIServer in scenarios with extremely large numbers of nodes. Furthermore, compared to Kubemark simulation, it significantly reduces resource consumption.

[0028] It should be noted that in a real Kubelet, the List-Watch behavior is implemented using Informer, which requires a large number of queues and caches. However, in this embodiment of the invention, the List-Watch behavior of the KubeletSimulator module is implemented based on the lightweight event listener Reflector, which removes the caching and queue mechanisms. It only retains the core network operations and authentication overhead, thereby truly putting pressure on the Kube-APIServer's Watch manager, authentication component (NodeAuthorization), token management module, etc.

[0029] This invention, through the addition of the FakeNodeFactory and KubeletSimulator modules, enables the automatic creation of virtual nodes and the simulation of key interactions between Kubelet and Kube-APIServer (including bootstrap token registration, certificate rotation, List-Watch, etc.), forming a lightweight simulation path without containers or real Kubelet processes. Compared to the additional resource overhead and scheduling complexity in Kubemark, which relies on a complete HollowNode container to simulate Kubelet behavior, this invention adopts a method of native logic replication combined with simplified network interaction, greatly reducing system resource consumption.

[0030] In yet another preferred embodiment, step S3, in response to a container creation event on the virtual node, triggers cluster plugin stress simulation, including: S31, in response to the container creation event on the virtual node, automatically simulate CNI network allocation behavior and DNS query behavior caused by the container.

[0031] For details, please refer to Figure 5 , Figure 5This is a schematic diagram illustrating cluster plugin stress simulation in a Kubernetes cluster simulation testing method provided by this invention. To further expand the simulation system's impact on the real stress of cluster service components, this embodiment of the invention designs the AddonsPressureEmulator module to simulate the load simulation of other cluster plugins besides the K8s cluster control plane, including CNI IPAM stress simulation and DNS query stress simulation. Specifically, in the CNI IPAM stress simulation: after detecting a Pod creation event, the PodController calls AddonsPressureEmulator to trigger Pod network initialization. This module parses the real CNI configuration file on the host machine and calls the IPAM CNI to execute IP allocation logic to simulate the request pressure on CNI plugins during large-scale Pod startup. Similarly, when the PodController detects a Pod deletion event, it triggers the IP release process, simulating the entire lifecycle. In the DNS query stress simulation: this module dynamically calculates the required DNS query frequency Q based on the KWOK instance, i.e., the number N of virtual nodes managed by the state-driven controller and the number P of Pods running on all managed virtual nodes. An example calculation formula is as follows: ; Here, α is an adjustable parameter, preferably between 0.1 and 0.5, used to adjust the intensity of the DNS query pressure simulation. As the number of nodes and Pods increases, the DNS query volume increases non-linearly. The query domain name is a set of randomly forged and fixed real domain names (e.g., Kubernetes.default.svc.cluster.local). Query latency and failure rate will be recorded in real time and exposed to the outside world in the form of Prometheus monitoring metrics.

[0032] This invention introduces the AddonsPressureEmulator module, which supports triggering real IPAM CNI plugins for IP allocation and release during Pod lifecycle events, simulating CNI pressure during scheduling-intensive periods. It also introduces a DNS concurrent query model that dynamically grows with the number of nodes and Pods to stress the cluster's DNS service components. By introducing the AddonsPressureEmulator module, the limitation of existing KWOK models in simulating the load of plugins (such as DNS and CNI) other than the Kubernetes cluster's own control components is addressed. This allows each component of the cluster system to experience realistic interaction behavior in the simulation, further improving the realism and breadth of the simulation system, thereby enhancing the overall testing accuracy.

[0033] This invention, by introducing three modules—FakeNodeFactory, KubeletSimulator, and AddonsPressureEmulator—on top of KWOK, eliminates the need to deploy HollowNode containers compared to the existing Kubemark, resulting in lower resource overhead. It supports larger-scale virtual node simulation, customizable node and Pod lifecycle logic, and offers greater flexibility and richer simulation scenarios. Compared to the existing KWOK, it adds Kubelet behavior simulation, covering realistic interaction processes such as token registration, certificate rotation, and List-Watch, more closely resembling actual cluster load characteristics. It supports automatic creation of virtual nodes and binding to KWOK instances, achieving full automation of the node lifecycle. A new system plugin stress simulation module supports IPAM allocation and large-scale DNS queries, improving plugin performance stress testing capabilities.

[0034] Accordingly, the present invention also provides a Kubernetes cluster simulation testing device, which can implement all the processes of the Kubernetes cluster simulation testing method in the above embodiments.

[0035] Please see Figure 6 , Figure 6 This is a schematic diagram of a preferred embodiment of a Kubernetes cluster simulation testing device provided by the present invention. The Kubernetes cluster simulation testing device includes: The virtual node creation module 601 is used to automatically create virtual nodes in response to simulation test requests and configure state-driven controllers for the virtual nodes; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual nodes and workloads; The control plane interaction simulation module 602 is used to trigger control plane load interaction simulation in response to the creation event of the virtual node; The cluster plugin stress simulation module 603 is used to trigger cluster plugin stress simulation in response to the container creation event on the virtual node.

[0036] Preferably, the virtual node creation module 601 is specifically used for: In response to a simulation test request, a corresponding virtual node is automatically created based on predefined parameters in the simulation test request, and a label is added to the virtual node; wherein the label corresponds to the state-driven controller; Configure the state-driven controller and the filtering rules of the state-driven controller for the virtual node based on the label.

[0037] Preferably, the state-driven controller includes a node lease controller, a node controller, a container controller, and a phase rule controller.

[0038] Preferably, the control plane interaction simulation module 602 is specifically used for: In response to the creation event of the virtual node, the authentication process and List-Watch listening process of the Kubelet in each virtual node are automatically simulated; wherein, the List-Watch listening process adopts a lightweight event listener that removes caching and queue mechanisms.

[0039] Preferably, the cluster plug-in stress simulation module 603 is specifically used for: In response to the container creation event on the virtual node, CNI network allocation behavior and DNS query behavior caused by the container are automatically simulated.

[0040] Preferably, the cluster plug-in stress simulation module 603 is further used for: The frequency of DNS queries to be initiated is dynamically calculated based on the number of virtual nodes managed by the state-driven controller and the number of containers running on all managed virtual nodes.

[0041] In specific implementation, the working principle, control process and technical effects of the Kubernetes cluster simulation test device provided in this embodiment of the invention are the same as those of the Kubernetes cluster simulation test method in the above embodiments, and will not be repeated here.

[0042] Please see Figure 7 , Figure 7 This is a schematic diagram of a preferred embodiment of a terminal device provided by the present invention. The terminal device includes a processor 701, a memory 702, and a computer program stored in the memory 702 and configured to be executed by the processor 701. When the processor 701 executes the computer program, it implements the Kubernetes cluster simulation testing method described in any of the above embodiments.

[0043] Preferably, the computer program can be divided into one or more modules / units (such as computer program 1, computer program 2, ...), and the one or more modules / units are stored in the memory 702 and executed by the processor 701 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.

[0044] The processor 701 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor, or the processor 701 can be any conventional processor. The processor 701 is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0045] The memory 702 mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., and the data storage area can store related data, etc. In addition, the memory 702 can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, and a flash card, etc., or the memory 702 can also be other volatile solid-state storage devices.

[0046] It should be noted that the aforementioned terminal devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 7 The structural diagram is merely an example of the terminal device described above and does not constitute a limitation on the terminal device described above. It may include more or fewer components than shown in the diagram, or combine certain components, or use different components.

[0047] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the Kubernetes cluster simulation test method described in any of the above embodiments.

[0048] This invention also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the Kubernetes cluster simulation testing method described in any of the above embodiments.

[0049] This invention provides a Kubernetes cluster simulation testing method, apparatus, device, storage medium, and product. In response to a simulation test request, it automatically creates virtual nodes and configures a state-driven controller for each virtual node. The state-driven controller operates Kubernetes API resources to simulate the lifecycle of the virtual node and its workload. In response to the creation event of the virtual node, it triggers control plane load interaction simulation; and in response to the creation event of a container on the virtual node, it triggers cluster plugin stress simulation. Based on KWOK's lightweight resource state simulation architecture, this invention introduces automatic node creation, Kubelet behavior simulation, and cluster plugin stress simulation, thereby more realistically simulating the multi-dimensional load impact of a large-scale Kubernetes cluster on the control plane with lower resource overhead.

[0050] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0051] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for simulating and testing a Kubernetes cluster, characterized in that, include: In response to a simulation test request, a virtual node is automatically created, and a state-driven controller is configured for the virtual node; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual node and the workload; In response to the creation event of the virtual node, a control plane load interaction simulation is triggered; In response to the container creation event on the virtual node, cluster plugin stress simulation is triggered.

2. The Kubernetes cluster simulation testing method as described in claim 1, characterized in that, The step of automatically creating virtual nodes in response to a simulation test request and configuring a state-driven controller for the virtual nodes includes: In response to a simulation test request, a corresponding virtual node is automatically created based on predefined parameters in the simulation test request, and a label is added to the virtual node; wherein the label corresponds to the state-driven controller; Configure the state-driven controller and the filtering rules of the state-driven controller for the virtual node based on the label.

3. The Kubernetes cluster simulation testing method as described in claim 2, characterized in that, The state-driven controller includes a node lease controller, a node controller, a container controller, and a phase rule controller.

4. The Kubernetes cluster simulation testing method as described in claim 3, characterized in that, The response to the creation event of the virtual node, triggering the control plane load interaction simulation, includes: In response to the creation event of the virtual node, the authentication process and List-Watch listening process of the Kubelet in each virtual node are automatically simulated; wherein, the List-Watch listening process adopts a lightweight event listener that removes caching and queue mechanisms.

5. The Kubernetes cluster simulation testing method as described in claim 4, characterized in that, The response to the container creation event on the virtual node, triggering cluster plugin stress simulation, includes: In response to the container creation event on the virtual node, CNI network allocation behavior and DNS query behavior caused by the container are automatically simulated.

6. The Kubernetes cluster simulation testing method as described in claim 5, characterized in that, The method further includes: The frequency of DNS queries to be initiated is dynamically calculated based on the number of virtual nodes managed by the state-driven controller and the number of containers running on all managed virtual nodes.

7. A Kubernetes cluster simulation testing device, characterized in that, include: A virtual node creation module is used to automatically create virtual nodes in response to simulation test requests and configure state-driven controllers for the virtual nodes; wherein, the state-driven controller is used to operate Kubernetes API resources to simulate the lifecycle of the virtual nodes and workloads; The control plane interaction simulation module is used to trigger control plane load interaction simulation in response to the creation event of the virtual node; The cluster plugin stress simulation module is used to trigger cluster plugin stress simulation in response to the container creation event on the virtual node.

8. A terminal device, characterized in that, The device includes a processor and a memory, the memory storing a computer program configured to be executed by the processor, wherein the processor, when executing the computer program, implements the Kubernetes cluster simulation test method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the device containing the computer-readable storage medium executes the computer program, it implements the Kubernetes cluster simulation test method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the Kubernetes cluster simulation test method as described in any one of claims 1 to 6.

Images