Cloud native test method and device, electronic equipment and storage medium

Abstract

The invention provides a cloud native test method and device, electronic equipment and a storage medium, and the method comprises the steps: deploying a basic environment and a test sandbox management platform, and creating at least one test sandbox on the deployed test sandbox management platform; deploying the first target service in the namespace of the test sandbox, performing service arrangement and service verification on the first target service, and performing operation processing on the test sandbox after completing the service verification on the first target service; and aiming at the backup processing, quitting the test sandbox, packaging and backing up the test sandbox to determine a backup test sandbox, carrying out sandbox destruction processing on the original test sandbox, and uploading the backup test sandbox to the shared object storage library, so that the first target business is continuously tested based on the backup test sandbox. The isolation granularity of resources is improved, the utilization rate of physical resources is effectively improved, and the cost can be effectively reduced.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a cloud native testing method, device, electronic device and storage medium. Background Art

[0002] With the development of cloud-native technology, the use of kubernetes platform has gradually become a daily routine. Namespaces are often used for resource isolation in business development and testing. However, the isolation capability of namespaces is very limited. Some cluster-sized resources will directly cause resource usage conflicts. This requires the use of multiple physical clusters to meet daily use. However, deploying multiple physical clusters will inevitably cause a large waste of resources and increase costs. With the sharp increase in business volume, a company will often deploy multiple kubernetes clusters necessary for development, testing, and quasi-production according to core development and testing scenarios. If you want to migrate some business systems from the test environment to quasi-production, you have to face a cumbersome, repetitive, time-consuming and labor-intensive deployment process. Therefore, how to improve the efficiency of cloud-native development business and the utilization rate of resources has become a technical issue that cannot be underestimated. Summary of the invention

[0003] In view of this, the purpose of this application is to provide a cloud-native testing method, device, electronic device and storage medium, which utilizes the test sandbox to achieve quick and easy deployment when the business is migrated from the test environment to the production, thereby improving the isolation granularity of resources and effectively improving the utilization rate of physical resources, which can effectively reduce cost expenditure and effectively improve the efficiency of cloud-native business development.

[0004] The present application provides a cloud-native testing method, which includes:

[0005] Deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment;

[0006] Deploy the first target service in the namespace of the test sandbox, perform service orchestration processing and service verification processing on the first target service, and perform operation processing on the test sandbox after completing the service verification processing on the first target service; wherein the operation processing includes suspension processing, destruction processing and backup processing;

[0007] For the backup processing, exit the test sandbox, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so that the first target business can continue to be tested based on the backup test sandbox.

[0008] In a possible implementation manner, at least one test sandbox is created on the deployed test sandbox management platform in the following manner:

[0009] On the deployed test sandbox management platform, a micro virtual cluster is encapsulated inside the test sandbox based on a pod, at least one namespace is set inside the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

[0010] In a possible implementation, the creation of the standard Kubernetes control plane for the test sandbox includes:

[0011] Set up the resource synchronizer, resource controller, resource access portal, test internal resource data storage service, coreDNS service, and test sandbox backup service in the standard Kubernetes control plane;

[0012] Among them, the resource synchronizer is used to synchronize the resources inside the test sandbox to the Kubernetes cluster, the resource controller is used to maintain the resource definition of the test sandbox, the resource access portal is used as the portal for accessing the virtual k8s resources inside the test sandbox, the test internal resource data storage service is used to store the resource data inside the test sandbox, and the coreDNS service is used to complete the work of accessing the internal services of the test sandbox through domain names.

[0013] In a possible implementation manner, uploading the backup test sandbox to a shared object repository includes:

[0014] The namespace on the Kubernetes cluster where the backup test sandbox is located is packaged, the data of the first target business of the backup test sandbox is packaged, and the packaged namespace and the data of the first target business are uploaded to the shared object repository together.

[0015] In a possible implementation manner, after destroying the original test sandbox and uploading the backup test sandbox to a shared object repository, the cloud native testing method further includes:

[0016] Download the backup test sandbox from the shared object repository, and obtain the second target business in the helm repository and the image repository;

[0017] The second target service is acquired based on the resource access entry of the backup test sandbox, and new service orchestration processing and new service verification processing are performed on the second target service in the namespace of the backup test sandbox.

[0018] In a possible implementation manner, after destroying the test sandbox and uploading the backup test sandbox to a shared object repository, the cloud native testing method further includes:

[0019] Detecting whether a Kubernetes cluster is running the destroyed test sandbox of another Kubernetes cluster;

[0020] If yes, determining whether the Kubernetes cluster and another Kubernetes cluster are connected to the same shared object repository;

[0021] If the same shared object repository is connected, the destroyed test sandbox is restored from the shared object repository, and the test is run based on the restored test sandbox.

[0022] In a possible implementation manner, with respect to the suspension processing, after completing the service verification processing for the first target service, operating processing is performed on the test sandbox, including:

[0023] If the test sandbox is not used for testing within a preset time interval, setting the test sandbox to a suspended processing state;

[0024] When it is detected that the test process continues to be performed based on the test sandbox, the state of the suspended process is converted to the state of the running process.

[0025] The embodiment of the present application also provides a cloud native testing device, the cloud native testing device comprising:

[0026] A deployment module, used to deploy a basic Kubernetes environment and a test sandbox management platform, and at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other and from the Kubernetes cluster in the basic Kubernetes environment;

[0027] A first processing module, configured to deploy a first target service in the namespace of the test sandbox, perform service orchestration processing and service verification processing on the first target service, and perform operation processing on the test sandbox after completing the service verification processing on the first target service; wherein the operation processing includes suspension processing, destruction processing and backup processing;

[0028] The second processing module is used to exit the test sandbox for the backup processing, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so as to continue to test the first target business based on the backup test sandbox.

[0029] An embodiment of the present application also provides an electronic device, including: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the memory communicate through the bus, and when the machine-readable instructions are executed by the processor, the steps of the cloud-native testing method as described above are performed.

[0030] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the cloud-native testing method as described above are executed.

[0031] The embodiments of the present application provide a cloud-native testing method, device, electronic device and storage medium, the cloud-native testing method comprising: deploying a basic Kubernetes environment and a test sandbox management platform, and creating at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment; deploying a first target business in the namespace of the test sandbox, performing business orchestration processing and business verification processing on the first target business, and performing operation processing on the test sandbox after completing the business verification processing on the first target business; wherein the operation processing includes suspension processing, destruction processing and backup processing; for the backup processing, exiting the test sandbox, packaging and backing up the test sandbox to determine a backup test sandbox, then destroying the original test sandbox, and uploading the backup test sandbox to a shared object repository, so that the first target business can continue to be tested based on the backup test sandbox. The test sandbox enables quick and easy deployment when migrating services from the test environment to the production environment, improves the isolation granularity of resources, and effectively increases the utilization rate of physical resources, which can effectively reduce costs.

[0032] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0034] Figure 1 A flowchart of a cloud native testing method provided in an embodiment of the present application;

[0035] Figure 2 A schematic diagram of creating a test sandbox provided in an embodiment of the present application;

[0036] Figure 3 A schematic diagram of a cloud native testing method provided in an embodiment of the present application;

[0037] Figure 4 One of the structural schematic diagrams of a cloud native testing device provided in an embodiment of the present application;

[0038] Figure 5 The second structural diagram of a cloud native testing device provided in an embodiment of the present application;

[0039] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0041] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0042] In order to enable those skilled in the art to use the contents of this application, the following implementation method is given in combination with the specific application scenario of "testing cloud native". For those skilled in the art, the general principles defined here can be applied to other embodiments and application scenarios without departing from the spirit and scope of this application.

[0043] First, the application scenarios to which this application is applicable are introduced. This application can be applied to the field of cloud native technology.

[0044] Research has found that with the development of cloud-native technology, the use of the kubernetes platform has gradually become a daily routine. Namespaces are often used for resource isolation in business development and testing. However, the isolation capability of namespaces is very limited. Some cluster-sized resources will directly cause resource usage conflicts, which requires the use of multiple physical clusters to meet daily use. However, deploying multiple physical clusters will inevitably cause a large waste of resources and increase costs. With the sharp increase in business volume, a company will often deploy multiple kubernetes clusters necessary for development, testing, and quasi-production based on core development and testing. If you want to migrate some business systems from the test environment to quasi-production, you have to face a cumbersome, repetitive, time-consuming and labor-intensive deployment process. Therefore, how to improve the efficiency of cloud-native development business and the utilization rate of resources has become a technical issue that cannot be underestimated.

[0045] Based on this, the embodiment of the present application provides a cloud-native testing method, which uses a test sandbox to enable quick and easy deployment when migrating services from a test environment to production, thereby improving the isolation granularity of resources and effectively improving the utilization rate of physical resources, which can effectively reduce cost overhead and effectively improve the efficiency of cloud-native business development.

[0046] See also Figure 1 , Figure 1 A flowchart of a cloud native testing method provided in an embodiment of the present application. Figure 1 As shown in , the cloud native testing method provided by the embodiment of the present application includes:

[0047] S101: Deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment.

[0048] In this step, the basic Kubernetes environment and the test sandbox management platform are deployed, at least one test sandbox is created on the deployed test sandbox management platform, and the object storage service is connected.

[0049] The test sandbox is used as a carrier for running services. The test sandboxes are isolated from each other and from the Kubernetes cluster, thereby preventing the Kubernetes cluster from failing when the test sandbox fails.

[0050] In a possible implementation manner, at least one test sandbox is created on the deployed test sandbox management platform in the following manner:

[0051] On the deployed test sandbox management platform, a micro virtual cluster is encapsulated inside the test sandbox based on a pod, at least one namespace is set inside the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

[0052] Here, on the deployed test sandbox management platform, a micro virtual cluster is encapsulated inside the test sandbox according to a sandbox entity pod, at least one namespace is set inside the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

[0053] Among them, pod is the smallest operation unit of k8s. Pod is also a container with an independent sandbox environment. One or more containers can be encapsulated inside the pod.

[0054] There are many types of controllers in kubernetes, such as replicasets controller, replicationcontrollers controller, deployment controller, daemonsets controller and statefulsets controller. Since the core concept of cloud native test sandbox is k8s in k8s, the instance of the test sandbox is to encapsulate a fully functional lightweight k8s (k0s, k3s, k8s) inside a pod, and the sandbox body is run in a namespace of the host machine as a statefulsets controller, and some resources inside the sandbox are also encapsulated into the same namespace of the host machine through the resource synchronizer. The test sandbox has its own independent api interface (apiserver) and data storage, and can achieve good isolation and security through an independent control plane.

[0055] In a possible implementation, the creation of the standard Kubernetes control plane for the test sandbox includes:

[0056] The resource synchronizer, resource controller, resource access portal, test internal resource data storage service, coreDNS service and test sandbox backup service in the standard Kubernetes control plane are set; wherein the resource synchronizer is used to synchronize the resources inside the test sandbox to the Kubernetes cluster, the resource controller is used to maintain the resource definition of the test sandbox, the resource access portal is used as the portal for accessing the virtual k8s resources inside the test sandbox, the test internal resource data storage service is used to store the resource data inside the test sandbox, and the coreDNS service is used to complete the work of accessing the internal services of the test sandbox through domain names.

[0057] Among them, the CoreDNS service is a modern, modular DNS server that is particularly suitable for containerized environments such as Kubernetes. It provides a high degree of flexibility and customization through a plug-in system, allowing users to expand functions according to their needs. Compared with traditional DNS, CoreDNS provides higher performance and flexibility to meet the needs of modern Internet architecture.

[0058] Here, the resource synchronizer: as a core component, can synchronize the low-level resources inside the sandbox to the host cluster, reuse the computing and storage capabilities of the host, avoid performance loss, and can also synchronize some host resources to the sandbox, complete the communication between the services in the sandbox and the host services, and ensure the consistency of the host resources with the resources inside the sandbox. Resource controller (Controller manager): mainly responsible for maintaining the deployments, statefulsets, CRD and other resources inside the sandbox. Resource access portal (Apiserver): The independent kubernetes apiserver inside the test sandbox is used to manage various k8s resources inside the test sandbox. Since each sandbox has an independent api interface, it can easily achieve isolation from the host cluster resources, and can also achieve resource isolation between sandboxes. The service (Datastore) for storing internal resource data in the test is mainly used to store resource data inside the test sandbox, and can support SQLite, etcd, MySQL, and PostgreSQL. oreDNS: realize service discovery inside the sandbox. Test sandbox backup service: mainly provides complete packaging of a test sandbox and then backs it up. After the backup, it can be quickly restored after the original sandbox is deleted, and can also complete cross-cluster sandbox recovery.

[0059] For further information, see Figure 2 , Figure 2 This is a schematic diagram of creating a test sandbox provided in an embodiment of the present application. Figure 2As shown in the figure, users can create cloud-native test sandboxes through the test sandbox management platform, create the namespace of the test sandbox and the standard Kubernetes control plane on the test sandbox management platform, and generate a corresponding sandbox instance after the test sandbox is created. The implementation of the sandbox instance uses k8s in The concept of k8s is to use a pod to encapsulate a k3s (k0s, k8s) micro virtual cluster inside the sandbox, and all the services running inside the sandbox will be isolated in a namespace of the host machine; the sandbox has the complete capabilities of a standard Kubernetes control plane, and uses an independent apiserver as the entrance to access the virtual k8s resources inside the sandbox, and has independent data storage. Through these two parts, resource isolation between sandboxes and isolation between sandboxes and host cluster resources can be achieved; a resource synchronizer is also running inside the sandbox, which is a key component to ensure that the test sandbox synchronizes resources such as pod and storage to the host cluster. The physical resources of the host cluster can be reused through the resource synchronizer, thereby realizing that only the data of the control plane inside the sandbox is maintained, and the data plane data will reuse the capabilities of the host cluster, thereby avoiding the performance loss caused by sandbox encapsulation, and achieving the same experience of running services inside the sandbox as running services on the host; an independent controller is run inside the test sandbox Manager is mainly used to maintain various internal k8s resource definitions and maintain resource consistency within the sandbox through the internal manager. The coreDNS running inside the sandbox completes the work of accessing services within the sandbox through domain names, giving full play to its value in resource isolation and resource consumption.

[0060] S102: Deploy the first target business in the namespace of the test sandbox, perform business orchestration processing and business verification processing on the first target business, and perform operation processing on the test sandbox after completing the business verification processing on the first target business; wherein the operation processing includes suspension processing, destruction processing and backup processing.

[0061] In this step, after the creation of the test sandbox is completed, a corresponding test sandbox instance will be generated. The test sandbox is accessed according to the kubeconfig connection information provided by the test sandbox instance. The test sandbox obtains the first target business, deploys the first target business in the namespace of the test sandbox, performs business orchestration and business verification on the first target business, and operates the test sandbox after completing the business verification of the first target business.

[0062] After the sandbox instance is built, you can access the sandbox through the kubeconfig connection information provided by the instance. After access, you can complete the same usage experience as the physical k8s cluster inside the sandbox, create various business resources, complete the development and testing of business functions, and even combine with devops processes to achieve automatic execution.

[0063] Here, the operation process includes a suspension process, a destruction process, and a backup process.

[0064] Among them, the business orchestration processing and business verification processing of the first target business include: after the business orchestration of the first target business, verifying the first target business after the business orchestration, detecting whether the first target business after the business orchestration meets the business requirements, if so, completing the business verification of the first target business, if not, continuing to orchestrate the first target business until the business verification is met.

[0065] In this application, the test sandbox can be paused, destroyed, or backed up after use. The purpose of backing up the sandbox is to quickly restore the sandbox later. If different environments need to reuse the test sandbox, cross-cluster migration (restore to different physical clusters) can be performed, but each physical cluster needs to be connected to the same object storage service.

[0066] S103: For the backup processing, exit the test sandbox, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so as to continue to test the first target business based on the backup test sandbox.

[0067] In this step, for the backup processing, exit the test sandbox and package the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so that the first target business can continue to be tested and processed according to the backup test sandbox, thereby effectively improving the utilization rate of physical resources and effectively reducing cost expenditure.

[0068] In a possible implementation manner, uploading the backup test sandbox to a shared object repository includes:

[0069] The namespace on the Kubernetes cluster where the backup test sandbox is located is packaged, the data of the first target business of the backup test sandbox is packaged, and the packaged namespace and the data of the first target business are uploaded to the shared object repository together.

[0070] Here, the namespace on the Kubernetes cluster where the backup test sandbox is located is packaged, and the business data inside the sandbox is also packaged, and the packaged namespace and the data of the first target business are uploaded to the shared object repository together.

[0071] In a possible implementation manner, after destroying the original test sandbox and uploading the backup test sandbox to a shared object repository, the cloud native testing method further includes:

[0072] A: Download the backup test sandbox from the shared object repository, and obtain the second target business in the helm repository and the image repository.

[0073] Here, the backup test sandbox is downloaded from the shared object repository, and the second target business is obtained from the helm repository and the image repository.

[0074] Among them, the helm warehouse is the package manager of k8s, which manages the local Chart warehouse, manages the interaction with the Chart Tiller server, sends Charts, instance installation, query, uninstallation and other operations. B: Based on the resource access entry of the backup test sandbox, the second target business is acquired, and the new business orchestration and new business verification processing are performed on the second target business in the namespace of the backup test sandbox.

[0075] Here, the second target business is acquired according to the resource access entry of the backup test sandbox, and new business orchestration processing and new business verification processing are performed on the second target business in the namespace of the backup test sandbox, so that the new business orchestration processing and new business verification processing are completed by using the backup test sandbox, avoiding waste of resources.

[0076] In a possible implementation manner, after destroying the test sandbox and uploading the backup test sandbox to a shared object repository, the cloud native testing method further includes:

[0077] a: Detect whether a Kubernetes cluster is running the destroyed test sandbox of another Kubernetes cluster.

[0078] Here, it is detected whether the Kubernetes cluster is running against the destroyed test sandbox of another Kubernetes cluster.

[0079] b: If yes, determine whether the Kubernetes cluster and another Kubernetes cluster are connected to the same shared object repository.

[0080] Here, if yes, it is determined whether the Kubernetes cluster and another Kubernetes cluster are connected to the same shared object repository.

[0081] c: If the same shared object repository is connected, the destroyed test sandbox is restored from the shared object repository, and the test is run based on the restored test sandbox.

[0082] Here, if the same shared object repository is connected, the destroyed test sandbox is restored from the shared object repository, and the test is run according to the restored test sandbox.

[0083] In a possible implementation manner, with respect to the suspension processing, after completing the service verification processing for the first target service, operating processing is performed on the test sandbox, including:

[0084] (1): If the test sandbox is not used for testing within a preset time interval, the test sandbox is set to a suspended processing state.

[0085] Here, if the test sandbox is not used for testing within a preset time interval, the test sandbox is set to be in a suspended processing state.

[0086] (2): When it is detected that the test process continues to be performed based on the test sandbox, the state of the suspended process is converted to the state of the running process.

[0087] Here, when it is detected that the test process is continued according to the test sandbox, the state of suspending the process is converted to the state of running the process.

[0088] In a specific embodiment, after completing the test of the business in the test sandbox instance, you can choose to exit the test sandbox. If you do not use it for a long time, you can choose to pause the sandbox. After pausing, the sandbox will not consume running resources. You can also choose to back up the test sandbox and delete the test sandbox after the backup. The backed-up test sandbox will package the namespace on the physical cluster where the test sandbox is located as a whole, and also package the business data inside the sandbox, and store the packaged data in a remote object storage. If you need to restore the test scenario later, you can perform a one-click recovery. After the recovery, the resource scenario will be completely restored, and new business can continue to be deployed. If you want to run existing test sandboxes in other physical clusters, you can also connect an object storage through multiple clusters to complete the cross-cluster recovery of the test sandbox.

[0089] For further information, see Figure 3 , Figure 3 A schematic diagram of a cloud native testing method provided in an embodiment of the present application. Figure 3As shown in , the user creates a sandbox on the test sandbox management platform, connects to the test sandbox after the creation is complete, obtains the chart package from the helm warehouse, and obtains the business image from the image warehouse, uses the test sandbox instance to perform business orchestration processing on the chart package and the business image, performs business verification processing after the business orchestration processing is completed, exits the sandbox when the business verification requirements are met, packages the entire test sandbox to obtain a backup test sandbox, deletes the original test sandbox, uploads the packaged files and business data of the backup test sandbox to the shared object storage, and needs to download the backup test sandbox from the shared object storage when restoring / migrating the sandbox, uses the backup test sandbox to continue to verify the original business, or uses the backup test sandbox to perform new business orchestration and business verification, exits the sandbox when the original business verification or business verification is completed, and destroys the downloaded backup test sandbox.

[0090] An embodiment of the present application provides a cloud-native testing method, which includes: deploying a basic Kubernetes environment and a test sandbox management platform, and creating a test sandbox on the deployed test sandbox management platform; wherein each of the test sandboxes is isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment; deploying a first target business in the namespace of the test sandbox, performing business orchestration processing and business verification processing on the first target business, and performing operation processing on the test sandbox after completing the business verification processing on the first target business; wherein the operation processing includes suspension processing, destruction processing and backup processing; for the backup processing, exiting the test sandbox, packaging and backing up the test sandbox to determine a backup test sandbox, then destroying the original test sandbox, and uploading the backup test sandbox to a shared object repository, so that the first target business can continue to be tested based on the backup test sandbox. The test sandbox enables quick and easy deployment when migrating services from the test environment to the production environment, improves the isolation granularity of resources, and effectively increases the utilization rate of physical resources, which can effectively reduce costs.

[0091] See also Figure 4 , Figure 5 , Figure 4 One of the structural schematic diagrams of a cloud native testing device provided in an embodiment of the present application; Figure 5 This is a second structural diagram of a cloud native testing device provided in an embodiment of the present application. Figure 4 As shown in , the cloud native testing device 400 includes:

[0092] A deployment module 410 is used to deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment;

[0093] A first processing module 420 is used to deploy a first target service in the namespace of the test sandbox, perform service orchestration processing and service verification processing on the first target service, and perform operation processing on the test sandbox after completing the service verification processing on the first target service; wherein the operation processing includes suspension processing, destruction processing and backup processing;

[0094] The second processing module 430 is used to exit the test sandbox for the backup processing, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so as to continue to test the first target business based on the backup test sandbox.

[0095] Further, the deployment module 410 creates at least one test sandbox on the deployed test sandbox management platform in the following manner:

[0096] On the deployed test sandbox management platform, a micro virtual cluster is encapsulated inside the test sandbox based on a pod, at least one namespace is set inside the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

[0097] Furthermore, when the deployment module 410 is used to create the standard Kubernetes control plane for the test sandbox, the deployment module 410 is specifically used to:

[0098] Set up the resource synchronizer, resource controller, resource access portal, test internal resource data storage service, coreDNS service, and test sandbox backup service in the standard Kubernetes control plane;

[0099] Among them, the resource synchronizer is used to synchronize the resources inside the test sandbox to the Kubernetes cluster, the resource controller is used to maintain the resource definition of the test sandbox, the resource access portal is used as the portal for accessing the virtual k8s resources inside the test sandbox, the test internal resource data storage service is used to store the resource data inside the test sandbox, and the coreDNS service is used to complete the work of accessing the internal services of the test sandbox through domain names.

[0100] Furthermore, when the second processing module 430 is used to upload the backup test sandbox to the shared object repository, the second processing module 430 is specifically used to:

[0101] The namespace on the Kubernetes cluster where the backup test sandbox is located is packaged, the data of the first target business of the backup test sandbox is packaged, and the packaged namespace and the data of the first target business are uploaded to the shared object repository together.

[0102] Further, such as Figure 5 As shown, the cloud native testing device 400 further includes a third processing module 440, and the third processing module 440 is used to:

[0103] Download the backup test sandbox from the shared object repository, and obtain the second target business in the helm repository and the image repository;

[0104] The second target service is acquired based on the resource access entry of the backup test sandbox, and new service orchestration processing and new service verification processing are performed on the second target service in the namespace of the backup test sandbox.

[0105] Furthermore, the third processing module 440 is further configured to:

[0106] Detecting whether a Kubernetes cluster is running the destroyed test sandbox of another Kubernetes cluster;

[0107] If yes, determining whether the Kubernetes cluster and another Kubernetes cluster are connected to the same shared object repository;

[0108] If the same shared object repository is connected, the destroyed test sandbox is restored from the shared object repository, and the test is run based on the restored test sandbox.

[0109] Furthermore, the third processing module 440 is further configured to:

[0110] If the test sandbox is not used for testing within a preset time interval, setting the test sandbox to a suspended processing state;

[0111] When it is detected that the test process continues to be performed based on the test sandbox, the state of the suspended process is converted to the state of the running process.

[0112] An embodiment of the present application provides a cloud-native testing device, which includes: a deployment module, which is used to deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment; a first processing module, which is used to deploy a first target business in the namespace of the test sandbox, perform business orchestration processing and business verification processing on the first target business, and perform operation processing on the test sandbox after completing the business verification processing on the first target business; wherein the operation processing includes suspension processing, destruction processing and backup processing; a second processing module, which is used to exit the test sandbox for the backup processing, package and back up the test sandbox to determine a backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to a shared object repository, so that the first target business can continue to be tested based on the backup test sandbox. The test sandbox enables quick and easy deployment when migrating services from the test environment to the production environment, improves the isolation granularity of resources, and effectively increases the utilization rate of physical resources, which can effectively reduce costs.

[0113] See also Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 6 As shown in , the electronic device 600 includes a processor 610 , a memory 620 and a bus 630 .

[0114] The memory 620 stores machine-readable instructions executable by the processor 610. When the electronic device 600 is running, the processor 610 communicates with the memory 620 via the bus 630. When the machine-readable instructions are executed by the processor 610, the above-mentioned Figure 1 as well as Figure 3 The steps of the cloud-native testing method in the method embodiment shown, the specific implementation method can be found in the method embodiment, and will not be repeated here.

[0115] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the computer program can execute the above-mentioned Figure 1 as well as Figure 3 The steps of the cloud-native testing method in the method embodiment shown, the specific implementation method can be found in the method embodiment, and will not be repeated here.

[0116] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0117] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

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

[0119] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0120] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or in other words, the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0121] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A cloud native testing method, characterized in that: The cloud native testing method includes: Deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment; Deploy the first target service in the namespace of the test sandbox, perform service orchestration processing and service verification processing on the first target service, and perform operation processing on the test sandbox after completing the service verification processing on the first target service; wherein the operation processing includes suspension processing, destruction processing and backup processing; For the backup processing, exit the test sandbox, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so that the first target business can continue to be tested based on the backup test sandbox.

2. The cloud native testing method according to claim 1, characterized in that: At least one test sandbox is created on the deployed test sandbox management platform in the following manner: On the deployed test sandbox management platform, a micro virtual cluster is encapsulated inside the test sandbox based on a pod, at least one namespace is set inside the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

3. The cloud native testing method according to claim 1, characterized in that: The creation of the standard Kubernetes control plane for the test sandbox includes: Set up the resource synchronizer, resource controller, resource access portal, test internal resource data storage service, coreDNS service, and test sandbox backup service in the standard Kubernetes control plane; Among them, the resource synchronizer is used to synchronize the resources inside the test sandbox to the Kubernetes cluster, the resource controller is used to maintain the resource definition of the test sandbox, the resource access portal is used as the portal for accessing the virtual k8s resources inside the test sandbox, the test internal resource data storage service is used to store the resource data inside the test sandbox, and the coreDNS service is used to complete the work of accessing the internal services of the test sandbox through domain names.

4. The cloud native testing method according to claim 1, characterized in that: The step of uploading the backup test sandbox to a shared object repository includes: The namespace on the Kubernetes cluster where the backup test sandbox is located is packaged, the data of the first target business of the backup test sandbox is packaged, and the packaged namespace and the data of the first target business are uploaded to the shared object repository together.

5. The cloud native testing method according to claim 1, characterized in that: After destroying the original test sandbox and uploading the backup test sandbox to the shared object repository, the cloud native testing method further includes: Download the backup test sandbox from the shared object repository, and obtain the second target business in the helm repository and the image repository; The second target service is acquired based on the resource access entry of the backup test sandbox, and new service orchestration processing and new service verification processing are performed on the second target service in the namespace of the backup test sandbox.

6. The cloud native testing method according to claim 1, characterized in that: After destroying the test sandbox and uploading the backup test sandbox to a shared object repository, the cloud native testing method further includes: Detecting whether a Kubernetes cluster is running the destroyed test sandbox of another Kubernetes cluster; If yes, determining whether the Kubernetes cluster and another Kubernetes cluster are connected to the same shared object repository; If the same shared object repository is connected, the destroyed test sandbox is restored from the shared object repository, and the test is run based on the restored test sandbox.

7. The cloud native testing method according to claim 1, characterized in that: With respect to the suspension processing, after completing the service verification processing for the first target service, operating the test sandbox includes: If the test sandbox is not used for testing within a preset time interval, setting the test sandbox to a suspended processing state; When it is detected that the test process continues to be performed based on the test sandbox, the state of the suspended process is converted to the state of the running process.

8. A cloud native testing device, characterized in that: The cloud native testing device includes: A deployment module, used to deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the deployed test sandbox management platform; wherein the test sandboxes are isolated from each other, and the test sandbox is isolated from the Kubernetes cluster in the basic Kubernetes environment; A first processing module, configured to deploy a first target service in the namespace of the test sandbox, perform service orchestration processing and service verification processing on the first target service, and perform operation processing on the test sandbox after completing the service verification processing on the first target service; wherein the operation processing includes suspension processing, destruction processing and backup processing; The second processing module is used to exit the test sandbox for the backup processing, package and back up the test sandbox to determine the backup test sandbox, then destroy the original test sandbox, and upload the backup test sandbox to the shared object repository, so as to continue to test the first target business based on the backup test sandbox.

9. An electronic device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate through the bus, and the machine-readable instructions are executed by the processor to execute the steps of the cloud-native testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the cloud-native testing method according to any one of claims 1 to 7 are executed.

Images