A KVM and Kubernetes cooperative isolation software test platform deployment system

Abstract

The application provides a KVM and Kubernetes cooperative isolation software test platform deployment system, comprising: a KVM virtualization layer, used for creating and managing a plurality of virtual machine clusters through KVM; a Kubernetes multi-environment logical isolation layer, used for dividing logical environments through namespaces in a public K8s cluster virtual machine, and performing resource and network isolation based on resource quotas, network policies and role-based access control rules of the Kubernetes; physically isolating a production environment K8s cluster virtual machine from other environment; and an automated construction and delivery pipeline module, used for listening to code changes and triggering a parameterized pipeline, and selecting a corresponding individual K8s cluster virtual machine or a public K8s cluster virtual machine and a namespace through preconfigured connection information according to a deployment target parameter. Based on this, a good balance between isolation, individual flexibility and resource efficiency is achieved.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and cloud-native system architecture technology, specifically to a software testing platform deployment system that uses KVM (Kernel-based Virtual Machine) and Kubernetes in a collaborative and isolated manner. Background Technology

[0002] In recent years, with the popularization of cloud computing and microservice architectures, building unified development, testing, and production environments using containerization and container orchestration technologies has become mainstream practice. Kubernetes, as the de facto standard for container orchestration, significantly simplifies the deployment and operation of distributed applications through its declarative API (Application Programming Interface) and elastic scaling services, supporting agile development and continuous delivery. Against this backdrop, providing efficient, reliable, and resource-efficient environments for multi-team collaborative development has become crucial for improving R&D efficiency. However, in actual Kubernetes-based development systems, challenges such as insufficient environment isolation, lack of personal debugging environments, high risks in delivery processes, and difficulty in ensuring environment consistency are still prevalent, hindering further improvements in efficiency and reliability.

[0003] To address the aforementioned issues, existing technical solutions primarily rely on the capabilities of the Kubernetes platform itself. The closest existing solution is to leverage Kubernetes namespaces to achieve logical isolation of multi-tenant resources, and combine this with RBAC (Role-Based Access Control), resource quotas, and network policies for permission and resource management. Simultaneously, to ensure environmental consistency, it is common practice to package the application and its complete dependencies into a standard containerized platform Docker image, and automate deployment through CI / CD (Continuous Integration and Continuous Deployment / Delivery) toolchains (such as Jenkins), aiming to achieve "build once, run anywhere." For scenarios requiring strong isolation, there is also a "one tenant, one cluster" model, where each tenant independently deploys a Kubernetes cluster to provide physical or virtual machine-level hardware isolation.

[0004] However, existing solutions have significant limitations. First, standardized container images struggle to support the personalized customization and debugging needs of different developers. Second, in shared clusters, even with namespace isolation, different tenant workloads still share underlying node resources, making it impossible to completely avoid performance interference from "noisy neighbors." Third, solutions typically lack convenient, on-demand dedicated personal development and debugging environments, easily leading to development conflicts and mutual interference during debugging. Furthermore, mainstream CI / CD processes are often tightly coupled with the production environment, lacking sufficient buffering and posing a risk of misoperation. Finally, existing solutions face a dilemma between isolation and efficiency: insufficient isolation in container sharing, coupled with the "one tenant, one cluster" model resulting in low resource utilization and high costs, makes a good balance difficult to achieve. Summary of the Invention

[0005] To address the aforementioned problems in the existing technology, this invention provides a software testing platform deployment system that integrates KVM and Kubernetes in a collaborative and isolated manner.

[0006] The technical problem to be solved by this invention is achieved through the following technical solution: This invention provides a software testing platform deployment system that coordinates and isolates KVM and Kubernetes, including: a KVM virtualization layer, a Kubernetes multi-environment logical isolation layer, and an automated build and delivery pipeline module; The KVM virtualization layer is deployed on physical servers and is used to create and manage various types of virtual machine clusters through KVM. These virtual machine clusters include: public K8s cluster virtual machines, production environment K8s cluster virtual machines, and personal K8s cluster virtual machines. The Kubernetes multi-environment logical isolation layer is deployed on multiple types of virtual machine clusters. It is used to divide logical environments within a public K8s cluster virtual machine by namespace and to isolate resources and networks based on Kubernetes resource quotas, network policies, and role-based access control rules. It physically isolates the production environment K8s cluster virtual machine from other environments and provides each developer with a complete K8s cluster environment in their own dedicated personal K8s cluster virtual machine. The automated build and delivery pipeline module connects to the code repository, the private image repository, and each Kubernetes cluster in the Kubernetes multi-environment logical isolation layer. It is used to monitor code changes and trigger parameterized pipelines to automatically build application images and push them to the private image repository. Based on the deployment target parameters, it selects the corresponding personal Kubernetes cluster virtual machine or public Kubernetes cluster virtual machine and namespace through pre-configured connection information. In the target environment, it sequentially performs admission checks, pulls the image, executes deployment and verification, and triggers resource reclamation after the personal environment has been idle for a timeout.

[0007] This invention provides a software testing platform deployment system for collaborative isolation of KVM and Kubernetes, comprising: a KVM virtualization layer, a Kubernetes multi-environment logical isolation layer, and an automated build and delivery pipeline module; the KVM virtualization layer is deployed on a physical server and is used to create and manage multiple types of virtual machine clusters through KVM; the multiple types of virtual machine clusters include: public Kubernetes cluster virtual machines, production environment Kubernetes cluster virtual machines, and personal Kubernetes cluster virtual machines; the Kubernetes multi-environment logical isolation layer is deployed on the multiple types of virtual machine clusters and is used to divide logical environments within the public Kubernetes cluster virtual machines through namespaces, and to perform access control based on Kubernetes resource quotas, network policies, and role-based access control rules. Resource and network isolation: The production environment Kubernetes cluster virtual machine is physically isolated from other environments, providing each developer with a complete Kubernetes cluster environment in their own dedicated personal Kubernetes cluster virtual machine. An automated build and delivery pipeline module connects to the code repository, private image repository, and each Kubernetes cluster in the Kubernetes multi-environment logical isolation layer. This module monitors code changes and triggers a parameterized pipeline to automatically build application images and push them to the private image repository. Based on deployment target parameters, it selects the corresponding personal or public Kubernetes cluster virtual machine and namespace using pre-configured connection information. In the target environment, it sequentially performs admission checks, pulls the image, executes deployment and verification, and triggers resource reclamation after the personal environment times out. In this invention, firstly, by providing each developer with a dedicated personal Kubernetes cluster virtual machine, the problem of standardized container images failing to support personalized customization and debugging needs is solved, and conflicts during development and debugging are avoided. Then, by implementing physical isolation (independent virtual machines in the production environment) and logical isolation (namespace isolation within the public cluster) through the KVM virtualization layer, the performance interference problem caused by "noisy neighbors" in the shared cluster is solved, ensuring resource and network isolation between environments. Finally, through an automated build and delivery pipeline module, parameterized deployment to personal or public environments is supported, and an idle timeout resource reclamation mechanism is introduced to solve the risk of misoperation caused by the tight coupling of CI / CD processes and the production environment. At the same time, by providing and reclaiming resources on demand, utilization is improved and the high cost dilemma of the "one tenant, one cluster" model is reduced. In summary, this invention achieves a good balance between isolation, personalized flexibility, and resource efficiency through the collaboration of KVM and Kubernetes, providing a secure, customizable, and efficient deployment system for the testing platform.

[0008] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the structure of a software testing platform deployment system that uses KVM and Kubernetes in a collaborative and isolated manner, as provided in an embodiment of the present invention. Figure 2 A schematic diagram illustrating the virtual machine creation process based on Libvirt and QEMU / KVM provided in this embodiment of the invention; Figure 3 This is a schematic diagram of the XML configuration file configuration process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the Kubernetes cluster deployment process provided in an embodiment of the present invention; Figure 5 An exemplary schematic diagram illustrates the process of automating the build and deployment of a CI / CD pipeline. Detailed Implementation

[0010] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0011] To achieve a good balance between isolation, personalization flexibility and resource efficiency, and to provide a secure, customizable and efficient deployment system for the testing platform, this invention provides a software testing platform deployment system that uses KVM and Kubernetes for collaborative isolation. Figure 1 This is a schematic diagram of the structure of a software testing platform deployment system that uses KVM and Kubernetes in a collaborative and isolated manner, as provided in an embodiment of the present invention. Figure 1 As shown, it includes: a KVM virtualization layer, a Kubernetes multi-environment logical isolation layer, and an automated build and delivery pipeline module.

[0012] The KVM virtualization layer is deployed on physical servers and is used to create and manage various types of virtual machine clusters through KVM. These virtual machine clusters include: public K8s cluster virtual machines, production environment K8s cluster virtual machines, and personal K8s cluster virtual machines.

[0013] Optionally, in the KVM virtualization layer, individual K8s cluster virtual machines exist as resource pools, dynamically generated on demand by the reserved computing resources of the physical server, and exclusively used by each developer.

[0014] It should be noted that in this invention, public Kubernetes cluster virtual machines are used to host shared development and testing environments; production environment Kubernetes cluster virtual machines are used to host pre-production and demonstration environments; and personal Kubernetes cluster virtual machine pools are dynamically allocated to different teams as needed. Different teams can build independent personal debugging environments in their own virtual machine pools according to the needs of developers.

[0015] Optionally, the KVM virtualization layer is also used to monitor the overall resource utilization of physical servers; When the resource pool level of a personal Kubernetes cluster virtual machine falls below a preset threshold, the resource pool is expanded; when a personal Kubernetes cluster virtual machine is detected to be reclaimed, the resource pool is automatically shrunk.

[0016] It should be noted that in some other implementations, the system can also be configured with different levels of collaborative isolation schemes based on the importance of the environment: For production environment K8s cluster virtual machines, a collaborative dual isolation system is adopted, combining physical isolation at the KVM virtual machine level with logical isolation at the Kubernetes namespace level. For public Kubernetes cluster virtual machines, they provide shared underlying KVM virtual machine resources for public and testing environments, and are logically isolated within the Kubernetes cluster through namespaces. These shared KVM virtual machine resources are physically isolated from the KVM virtual machine resources of production and personal environments. For individual Kubernetes cluster virtual machines, each developer is provided with dedicated physical isolation at the KVM virtual machine level, and can further configure logical isolation at the Kubernetes namespace level within the cluster as needed.

[0017] The Kubernetes multi-environment logical isolation layer is deployed on multiple types of virtual machine clusters. It is used to divide logical environments within a public K8s cluster virtual machine by namespace and to isolate resources and networks based on Kubernetes resource quotas, network policies, and role-based access control rules. It physically isolates the production environment K8s cluster virtual machine from other environments and provides each developer with a complete K8s cluster environment in their own dedicated personal K8s cluster virtual machine.

[0018] It should be noted that, in this embodiment, other environments can be the various namespace environments within a public K8s cluster virtual machine and the personal K8s cluster virtual machine environments of each developer.

[0019] Alternatively, the production environment Kubernetes cluster virtual machines run in independent virtual machines created by the KVM virtualization layer, which are physically isolated from public Kubernetes cluster virtual machines and personal Kubernetes cluster virtual machines.

[0020] Optionally, the Kubernetes multi-environment logical isolation layer creates independent namespaces for different logical environments and configures computing resource quotas, network policies, and access control rules based on the namespaces to isolate resources and networks.

[0021] The automated build and delivery pipeline module connects to the code repository, the private image repository, and each Kubernetes cluster in the Kubernetes multi-environment logical isolation layer. It is used to monitor code changes and trigger parameterized pipelines to automatically build application images and push them to the private image repository. Based on the deployment target parameters, it selects the corresponding personal Kubernetes cluster virtual machine or public Kubernetes cluster virtual machine and namespace through pre-configured connection information. In the target environment, it sequentially performs admission checks, pulls the image, executes deployment and verification, and triggers resource reclamation after the personal environment has been idle for a timeout.

[0022] It should be noted that the target environment refers to the specific Kubernetes runtime environment in which the automated build and delivery pipeline module will ultimately deploy the application; specifically, it is a two-dimensional address jointly defined by the cluster and namespace.

[0023] In summary, this invention creates a dedicated KVM virtual machine for each developer as needed, and deploys a lightweight Kubernetes cluster within it, forming a personal private development cluster. This achieves a highly isolated personal development environment, avoiding configuration conflicts, port contention, and accidental operations that could affect others; it also supports rapid creation / destruction, improving debugging freedom and efficiency.

[0024] Secondly, on the shared physical resource pool, multiple types of virtual machines are partitioned using KVM. Each developer is provided with a dedicated virtual machine and a complete Kubernetes cluster deployed there, achieving strong physical isolation. Simultaneously, a shared Kubernetes cluster virtual machine is provided, with logically isolated environments for multiple teams within it via namespaces. This dual isolation mechanism of the IaaS layer (KVM) and the PaaS layer (Kubernetes) preserves the flexibility of container orchestration while achieving virtual machine-level security boundaries, effectively preventing cross-tenant performance and security interference.

[0025] Finally, an intermediate isolation layer is introduced: the CI / CD pipeline first deploys the application to a developer's / team's dedicated KVM-K8s environment for verification; only after passing quality gates is it synchronized to the production cluster through a controlled process. This decoupling of the deployment process forms a secure pipeline of "development → verification → integration → production," significantly reducing the risk of misoperation and escalation. The deployment mode (shared namespace / dedicated VM-K8s) can also be dynamically selected based on the team's security level and application sensitivity, achieving policy-driven elastic isolation. On-demand, tiered isolation balances cost, efficiency, and security, adapting to diverse business scenarios.

[0026] Optionally, the deployment target parameters include at least a type parameter for identifying the target environment; the automated build and delivery pipeline module has pre-configured K8s cluster connection configurations corresponding to different deployment target parameters; The parameterized pipeline connects to the corresponding personal or public K8s cluster virtual machine and namespace using the corresponding K8s cluster connection configuration based on the type parameters.

[0027] Optionally, the admission check includes image security scanning of the application images built by the parameterized pipeline and compliance verification of the Kubernetes deployment description file that defines the deployment rules of the application images; the verification includes health checks of the application services deployed in the namespace.

[0028] Optionally, resource reclamation includes deleting the namespace corresponding to the personal environment and destroying the underlying virtual machine resources that host the personal environment.

[0029] Optionally, the automated build and delivery pipeline module can automatically trigger a resource reclamation process for a personal Kubernetes cluster virtual machine when it detects that the virtual machine has no access activity within a preset time period.

[0030] This invention provides a software testing platform deployment system that uses KVM and Kubernetes for collaborative isolation. First, by providing each developer with a dedicated personal Kubernetes cluster virtual machine, it solves the problem of standardized container images failing to support personalized customization and debugging needs, and avoids conflicts during development and debugging. Second, by implementing physical isolation (independent virtual machines in the production environment) through the KVM virtualization layer and logical isolation through the Kubernetes layer (namespace isolation within the public cluster), it solves the performance interference problem caused by "noisy neighbors" in shared clusters, ensuring resource and network isolation between environments. Finally, through an automated build and delivery pipeline module, it supports parameterized deployment to personal or public environments and introduces an idle timeout resource reclamation mechanism, mitigating the risk of misoperation due to the tight coupling of CI / CD processes with the production environment. Simultaneously, by providing and reclaiming resources on demand, it improves utilization and reduces the high cost of the "one tenant, one cluster" model. In summary, this invention achieves a good balance between isolation, personalized flexibility, and resource efficiency through the collaboration of KVM and Kubernetes, providing a secure, customizable, and efficient deployment system for testing platforms.

[0031] Based on the above solutions, the configuration process of the test platform deployment system of this invention will be described in detail below.

[0032] I. Environmental Preparation: At the hardware level, a high-performance ARM architecture server based on the openEuler operating system is deployed. This server is configured with two Hygon x86 processors (128 physical cores in total) and approximately 1TB of memory, providing ample computing resources. For storage, it is equipped with over 400GB of local high-speed storage and mounted with over 50TB of high-availability network storage to support virtual machine images and persistent data. This hardware and OS combination lays a high-efficiency, high-concurrency, and self-controllable foundation for subsequent virtualization and containerization platforms.

[0033] II. Deploying virtual machines based on KVM: Install the KVM virtualization environment on the prepared server. The core components are QEMU (responsible for hardware emulation and virtual machine operation) and libvirt (providing a unified management interface). First, download or create a virtual machine image file using the qemu-img tool. Next, configure network devices such as Linux bridges to ensure the virtual machines have external communication capabilities. Then, prepare the UEFI or BIOS boot firmware and write a LibvirtXML configuration file describing the virtual machine specifications (CPU, memory, disk, network card, etc.). Finally, use tools such as virsh to create and start the virtual machines. For example, create four virtual machines as a public Kubernetes cluster and reserve a resource pool for creating personal Kubernetes cluster virtual machines as needed later. It is necessary to understand and manage the various states of virtual machines (such as shut down, running, paused, etc.).

[0034] Libvirt is an open-source API, daemon, and management toolset. It doesn't emulate hardware itself, but rather manages QEMU-KVM. Its functions include: 1. Unified management interface: It provides a standard "language" (API) so that upper-layer tools (such as virsh, virt-manager, and OpenStack) don't need to know whether the underlying system is QEMU or something else; they only need to communicate with Libvirt. 2. Lifecycle management: It handles virtual machine startup, stopping, pausing, migration, and destruction. 3. Resource configuration: It manages the virtual machine's network (bridging, NAT), storage (disk imaging), memory, and CPU allocation.

[0035] Virtual machine images can be downloaded from the official website or pre-installed image files can be used. When using pre-installed images, the qemu-img package needs to be installed, and the image file is created using qemu-img.

[0036] Configuring virtual machine networking is essential for enabling virtual machines to communicate with the outside world. KVM supports various types of bridges, such as Linux bridges and Open vSwitch bridges.

[0037] The virtual machine configuration process is as follows: Figure 2 As shown, Figure 2 This is a schematic diagram of the virtual machine creation process based on Libvirt and QEMU / KVM provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the process begins with the user issuing an initialization command through the Libvirt tool. Libvirt then parses the command and generates a standard XML configuration file. Next, Libvirt calls the underlying driver, and finally, QEMU / KVM simulates the hardware and runs the virtual machine.

[0038] The data transmission path is: Virtual Machine -> Virtual Network Adapter -> Bridge -> Physical Network Adapter. Creating a bridge, besides configuring a virtual network adapter for the virtual machine, is crucial for connecting the virtual machine network.

[0039] After configuring the virtual machine network as described above, starting the virtual machine requires preparing the boot firmware and virtual machine configuration. Different architectures require different boot methods. Common methods include BIOS boot and UEFI boot. Choose the appropriate boot method based on your actual architecture. For virtual machine configuration, the Libvirt tool uses an XML file to describe a virtual machine's characteristics, including the virtual machine name, CPU, memory, disk, network card, mouse, keyboard, and other information. Users can manage virtual machines by modifying the configuration file.

[0040] Figure 3 This is a schematic diagram of the XML configuration file configuration process provided in an embodiment of the present invention, such as... Figure 3 As shown, the process first creates an XML configuration file with the root element "domain". Then, it uses the tag name and specifies a unique virtual machine name according to the naming rules. Next, it configures system resources such as virtual CPU and virtual memory. Then, it configures virtual devices (including storage devices, network devices, peripheral bus structures and external devices such as mice) in sequence. Finally, it saves the XML configuration file.

[0041] After preparation, you can begin creating virtual machines, such as four VMs of any size (size determined by specific needs) as a public Kubernetes cluster; a reserved resource pool is used for dynamically creating individual Kubernetes VMs (each XCXG, size determined by specific needs). To better utilize hardware resources and reduce costs, users need to manage virtual machines effectively. Virtual machines can have the following states: Undefined: The virtual machine is not defined or created, meaning libvirt considers the virtual machine to not exist.

[0042] Shut-off state: The virtual machine has been defined but is not running, or the virtual machine has been terminated.

[0043] Running: The virtual machine is in a running state.

[0044] Paused: The virtual machine is suspended, and its running state is temporarily saved in memory. It can be resumed to its running state.

[0045] Saved: Similar to the paused state, its running state is saved in persistent storage media and can be restored to the running state.

[0046] Crash: This usually occurs when a virtual machine crashes due to an internal error and cannot be recovered to its running state. Different states can transition between each other.

[0047] III. Deploying a Kubernetes cluster: The process for deploying a Kubernetes cluster on a pre-created virtual machine is as follows: 1. Basic configuration: Set the hostname, configure local DNS resolution ( / etc / hosts), disable the firewall and SELinux, and synchronize the time. 2. Install container runtime: Install Docker and its CRI adapter plugin (cri-docker), or directly install containerd. 3. Install Kubernetes components: Install kubelet, kubeadm, and kubectl. 4. Deploy a private image repository: Set up an intranet Docker Registry to accelerate the pulling of core images and the storage of business images. 5. Initialize the cluster: Execute kubeadminit on the Master node to generate certificates and configure the cluster. 6. Install network plugins: Deploy CNI plugins such as Calico and Flannel to enable Pod network communication. 7. Add worker nodes: Execute the kubeadmjoin command on each worker node to join the cluster. 8. Deploy a visualization panel: Install tools such as Kuboard to provide a graphical management interface.

[0048] Figure 4 This is a schematic diagram of the Kubernetes cluster deployment process provided in an embodiment of the present invention, such as... Figure 4 As shown, the process first prepares the installation environment by installing Docker, cri-docker, and kublet / kubeadm / kubectl in sequence. Then, it deploys a private Docker repository and initializes the K8s cluster. Next, it installs the CNI network plugin and adds slave nodes to the cluster. Finally, it installs the control panel Kuboard.

[0049] IV. Public Kubernetes Environment Configuration: On the deployed public Kubernetes cluster virtual machine, configure multi-tenant logical isolation. First, create namespaces representing different testing phases, such as dev (development environment) and sit (system integration testing environment). Then, configure ResourceQuota for each namespace, such as limiting its total CPU and memory (e.g., CPU: 8 cores, Memory: 32 GiB), to ensure fair resource allocation and prevent a single environment from exhausting cluster resources. Furthermore, network isolation and access control can be further implemented by combining NetworkPolicy and RBAC (Role-Based Access Control).

[0050] V. Application and Supply of Personalized K8s Environments: To meet developers' needs for dedicated, isolated environments, a "personal Kubernetes cluster virtual machine" is dynamically provisioned using the KVM layer. When a developer requests a personal environment, the system quickly creates an independent virtual machine from the reserved resource pool using libvirt, and automatically deploys a complete Kubernetes cluster within this virtual machine (steps are the same as in Part 3). This virtual machine cluster is exclusively used by the developer and is physically isolated from public clusters and other personal clusters. Within the cluster, namespaces can be partitioned for different projects or components, and independent service access ports can be pre-planned, ensuring that the developer's debugging activities are completely autonomous and do not interfere with each other.

[0051] VI. CI / CD Pipeline Automated Build and Deployment (Automated Build and Delivery Pipeline Module): The entire build and deployment process is automated by the Jenkins pipeline. Figure 5 An exemplary diagram illustrates the process of automating the build and deployment of a CI / CD pipeline, such as... Figure 5 As shown, the process is as follows: 1. Triggering phase: Developers submit code to GitLab, and Jenkins listens for code change events. 2. Build phase: The pipeline is triggered, and multiple Docker images are built in parallel according to microservice partitioning (e.g., backend, frontend, middleware). 3. Push phase: Jenkins logs into the private image repository, pushes the successfully built application image into the repository, and packages the runtime dependencies, configuration files, and application code of the test platform into a unified image to ensure environment consistency. 4. Deployment phase: The pipeline determines the deployment target environment (a namespace in a public environment or the address of a personal Kubernetes cluster) based on preset parameters (e.g., DEPLOY_TARGET), connects to the corresponding cluster via kubectl, pulls the new image, and performs rolling updates to complete application deployment and basic verification.

[0052] In a further implementation, the following processes will be executed: 5. After deployment, a health check will be automatically performed to verify the operability of the test platform in the target environment; 6. After verification in the public or personal environment without any issues, it will be synchronously deployed to the production environment; 7. The personal environment can be destroyed after idle timeout, releasing KVM resources and enabling the recycling of KVM resources. In addition, the test platform adopts a containerized design, making it easy to integrate with existing DevOps toolchains, while also supporting rapid iteration and customized expansion of the test platform.

[0053] VII. Mechanism for Recycling Idle Resources: To optimize resource utilization and control costs, the system implements an automatic recycling policy. The environment management platform continuously monitors the activity status of personal Kubernetes cluster virtual machines (i.e., personal environments). When the monitoring system detects that a personal environment has not had any access or deployment activity for 7 consecutive days (7x24 hours), it is considered idle. The platform will automatically trigger the recycling process: deleting the entire Kubernetes cluster corresponding to the personal environment and its virtual machines, completely releasing the CPU, memory, and storage resources it occupies, and returning the resources to the KVM resource pool for subsequent reallocation.

[0054] This invention employs a dual architecture of "KVM physical isolation + Kubernetes namespace logical isolation," combined with deep integration of CI / CD pipelines and testing platforms. While achieving efficient resource utilization and standardized process management, it significantly enhances the innovation of the testing platform's construction and operation, primarily in the following aspects: a) Strong isolation: Relying on the dual mechanism of "KVM physical isolation + Kubernetes namespace logical isolation", the stability of the public environment and the freedom of the personal environment are guaranteed to be mutually uninterrupted; the test platform adopts image deployment to further enhance the consistency of the environment and ensure that the software stack running in the personal debugging environment and the public test environment is completely consistent, fundamentally eliminating the problem of environment differences that "can run on my machine". b) Efficient resource utilization: Supports the creation and automatic recycling of personal environments as needed, avoiding long-term idleness and occupation of resources; c) Process standardization: Through a unified CI / CD entry point, all environment deployments are audited and controlled by Jenkins, improving release security; the entire process of building and pushing the test platform is incorporated into pipeline management, realizing full-link automation and traceability from code submission to test environment readiness, ensuring the reliability and compliance of test versions; d) Enhanced development experience: Developers can freely deploy a testing platform containing complete components such as front-end, back-end, and database in their personal Kubernetes environment, supporting the simulation and debugging of complex test scenarios; the testing platform and the application under test share the same technical foundation, promoting deep collaboration between testing tools and the environment; e) Strong compatibility: Based on the open-source technology stack (KVM / Kubernetes / Jenkins), the testing platform adopts a modular design, which is easy to integrate with the existing DevOps toolchain; through image delivery, it can be seamlessly adapted to various infrastructures, whether it is a local data center or a cloud environment, and can be quickly deployed and elastically scaled, with strong environmental adaptability.

[0055] The technical aspects of this invention system are mainly reflected in the following aspects: 1. Key features: Existing technologies typically stack KVM, Kubernetes, and Jenkins as independent toolchains, lacking a hierarchical isolation mechanism based on business scenarios, and failing to organically integrate KVM's strong physical isolation features (for personal exclusive environments) with Kubernetes' lightweight logical isolation features (for public shared environments).

[0056] Therefore, this invention constructs a hybrid isolation architecture for on-demand scheduling. Based on the different needs of "personal debugging" and "public testing," tasks are flexibly distributed to different isolation levels: personal environments are scheduled to dedicated K8s clusters within KVM virtual machines (VM-level physical isolation), while public environments are scheduled to the namespace of a shared K8s cluster (namespace-level logical isolation). This architecture balances environmental purity and resource efficiency within a unified platform, systematically solving the technical challenges of environmental conflicts, resource waste, and cross-environment deployment consistency of the test platform in traditional solutions.

[0057] 2. Significant technical benefits: It solves four major pain points of traditional solutions: "environmental conflicts," "resource waste," "difficulty in individual debugging," and "inconsistent testing environments." A two-layer isolation architecture ensures the stability and flexibility of the testing environment, while image-based deployment enables rapid delivery and version tracking of the testing platform.

[0058] 3. High industrial applicability: It has been implemented in actual DevOps scenarios, and is especially suitable for software development teams that need to deploy and recycle test environments frequently, and has the value for large-scale promotion.

[0059] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described in this specification.

[0060] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings and the disclosure, will understand and implement other variations of the disclosed embodiments in carrying out the claimed invention. In this description, the word "comprising" does not exclude other components or steps, "a" or "an" does not exclude a plurality, and "a plurality" means two or more, unless otherwise explicitly specified. Furthermore, while different embodiments may describe certain measures, this does not mean that these measures cannot be combined to produce good results.

[0061] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the inventive concept, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A software testing platform deployment system that coordinates and isolates KVM and Kubernetes, characterized in that, include: KVM virtualization layer, Kubernetes multi-environment logical isolation layer, and automated build and delivery pipeline module; The KVM virtualization layer is deployed on a physical server and is used to create and manage multiple types of virtual machine clusters through KVM; The various types of virtual machine clusters include: public K8s cluster virtual machines, production environment K8s cluster virtual machines, and personal K8s cluster virtual machines; The Kubernetes multi-environment logical isolation layer is deployed on the various types of virtual machine clusters. It is used to divide logical environments within the public K8s cluster virtual machine by namespace and to isolate resources and networks based on Kubernetes resource quotas, network policies, and role-based access control rules. It physically isolates the production environment K8s cluster virtual machine from other environments and provides each developer with a complete K8s cluster environment in their own dedicated personal K8s cluster virtual machine. The automated build and delivery pipeline module connects to the code repository, the private image repository, and each K8s cluster in the Kubernetes multi-environment logical isolation layer. It is used to monitor code changes and trigger parameterized pipelines to automatically build application images and push them to the private image repository. Based on the deployment target parameters, it selects the corresponding personal K8s cluster virtual machine or public K8s cluster virtual machine and the namespace through pre-configured connection information. In the target environment, it sequentially performs admission checks, pulls the image, executes deployment and verification, and triggers resource reclamation after the personal environment has been idle for a timeout.

2. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, In the KVM virtualization layer, the personal K8s cluster virtual machine exists as a resource pool, dynamically generated on demand by the reserved computing resources of the physical server, and exclusively used by each developer.

3. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, The Kubernetes multi-environment logical isolation layer creates independent namespaces for different logical environments, and configures computing resource quotas, network policies and access control rules based on the namespaces to isolate resources and networks.

4. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, The deployment target parameters include at least a type parameter for identifying the target environment; the automated build and delivery pipeline module is pre-configured with K8s cluster connection configurations corresponding to different deployment target parameters; The parameterized pipeline connects to the corresponding personal K8s cluster virtual machine or public K8s cluster virtual machine and the namespace using the corresponding K8s cluster connection configuration according to the type parameters.

5. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, The access check includes performing a security scan on the application image built by the parameterized pipeline and a compliance check on the Kubernetes deployment description file that defines the deployment rules of the application image; the verification includes performing a health check on the application services deployed in the namespace.

6. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, The resource recycling includes deleting the namespace corresponding to the personal environment and destroying the underlying virtual machine resources that host the personal environment.

7. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, The production environment K8s cluster virtual machine runs in an independent virtual machine created by the KVM virtualization layer, which is physically isolated from the public K8s cluster virtual machine and the personal K8s cluster virtual machine.

8. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 2, characterized in that, The KVM virtualization layer is also used to monitor the overall resource utilization of the physical server; When the resource pool level of the personal Kubernetes cluster virtual machine is lower than a preset threshold, the resource pool is expanded; when it is detected that the personal Kubernetes cluster virtual machine has been reclaimed, the resource pool is automatically shrunk.

9. The software testing platform deployment system for collaborative isolation of KVM and Kubernetes as described in claim 1, characterized in that, When the automated build and delivery pipeline module detects that the personal Kubernetes cluster virtual machine has no access activity within a preset time period, it automatically triggers a resource reclamation process for the personal Kubernetes cluster virtual machine.

Images