A cloud-native testing method and device, electronic equipment and storage medium

Abstract

The application provides a cloud-native testing method and device, electronic equipment and storage medium, which comprises the following steps: deploying a basic environment and a test sandbox management platform, creating at least one test sandbox on the deployed test sandbox management platform; deploying a first target business in the namespace of the test sandbox, performing business arrangement and business verification on the first target business, and performing operation processing on the test sandbox after completing the business verification on the first target business; for backup processing, exiting the test sandbox, packaging and backing up the test sandbox to determine a backup test sandbox, destroying the original test sandbox, and uploading the backup test sandbox to a shared object storage library, so that the backup test sandbox continues to test the first target business. The isolation granularity of resources is improved, and the use rate of physical resources is effectively improved, which can effectively reduce the cost overhead.

Description

TECHNICAL FIELD

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

[0002] With the development of cloud native technology, the use of kubernetes platform tends to be routine, and namespace is often used for resource isolation in business development and testing. However, the isolation capability of namespace is very limited, and part of the cluster granularity resources will directly cause resource usage conflict, 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 dramatic 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 some business systems are to be migrated from the test environment to the quasi-production environment, a cumbersome, repetitive and time-consuming deployment process is unavoidable. Therefore, how to improve the efficiency of cloud native business development and the utilization rate of resources has become a technical problem that cannot be ignored. SUMMARY

[0003] Therefore, the present application aims to provide a cloud native testing method and device, electronic equipment and storage medium, which can quickly and easily deploy the business from the test environment to the production environment, improve the isolation granularity of resources and effectively improve the utilization rate of physical resources, effectively reduce the cost overhead, and effectively improve the efficiency of cloud native business development.

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

[0005] Deploying a basic Kubernetes environment and a test sandbox management platform, 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 sandboxes are isolated from the Kubernetes clusters in the basic Kubernetes environment;

[0006] 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;

[0007] For the backup processing, the test sandbox exits the test sandbox to package the test sandbox to determine a backup test sandbox, destroys the original test sandbox, and uploads the backup test sandbox to a shared object storage to continue testing the first target service based on the backup test sandbox.

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

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

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

[0011] A resource synchronizer, a resource controller, a resource access portal, a service of a test internal resource data storage, a coreDNS service, and a test sandbox backup service in the standard Kubernetes control plane are set.

[0012] The resource synchronizer is configured to synchronize resources in the test sandbox to a Kubernetes cluster, the resource controller is configured to maintain resource definitions of the test sandbox, the resource access portal is configured to serve as an access portal of virtual k8s resources in the test sandbox, the service of the test internal resource data storage is configured to store resource data in the test sandbox, and the coreDNS service is configured to complete domain name access between services in the test sandbox.

[0013] In one possible implementation, the uploading of the backup test sandbox to the shared object storage includes:

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

[0015] In one possible implementation, after the destruction of the original test sandbox and the uploading of the backup test sandbox to the shared object storage, the cloud-native testing method further includes:

[0016] download the backup test sandbox from the shared object storage, obtain a second target service in a helm repository and a mirror repository;

[0017] obtain the second target service based on a resource access entry of the backup test sandbox, and perform new service orchestration processing and new service verification processing on the second target service in a namespace of the backup test sandbox.

[0018] In a possible implementation, after the test sandbox is destroyed and the backup test sandbox is uploaded to the shared object storage, the cloud-native testing method further includes:

[0019] detect whether the Kubernetes cluster runs the destroyed test sandbox of another Kubernetes cluster;

[0020] if yes, determine whether the Kubernetes cluster and the other Kubernetes cluster interface with the same shared object storage;

[0021] if the same shared object storage is interfaced, restore the destroyed test sandbox from the shared object storage, and perform test running based on the restored test sandbox.

[0022] In a possible implementation, for the suspension processing, the operation processing is performed on the test sandbox after the service verification processing on the first target service is completed, including:

[0023] if the test sandbox is not used for testing within a preset time interval, set the test sandbox in a state of suspension processing;

[0024] when it is detected that the test processing based on the test sandbox is continued, the state of the suspension processing is converted to a state of running processing.

[0025] Embodiments of the present application also provide a cloud-native testing device, which includes:

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

[0027] The first processing module is configured to deploy a first target service in a 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; the operation processing includes pause processing, destruction processing, and backup processing.

[0028] The second processing module is configured to, for the backup processing, exit the test sandbox to determine a backup test sandbox by packing and backing up the test sandbox, perform destruction sandbox processing on the original test sandbox, and upload the backup test sandbox to a shared object storage repository, so as to continue testing the first target service based on the backup test sandbox.

[0029] The embodiment of the application further provides an electronic device, including a processor, a memory, and a bus, 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 perform the steps of the cloud native testing method as described above.

[0030] The embodiment of the application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the steps of the cloud native testing method as described above.

[0031] The embodiment of the application provides a cloud native testing method, device, electronic device, and storage medium, the cloud native testing method includes: deploying a basic Kubernetes environment and a test sandbox management platform, creating at least one test sandbox on the test sandbox management platform after deployment; the test sandboxes are isolated from each other, and the test sandboxes are isolated from a Kubernetes cluster in the basic Kubernetes environment; deploying a first target service in a namespace of the test sandbox, performing service orchestration processing and service verification processing on the first target service, and performing operation processing on the test sandbox after completing the service verification processing on the first target service; the operation processing includes pause processing, destruction processing, and backup processing; for the backup processing, exiting the test sandbox to determine a backup test sandbox by packing and backing up the test sandbox, performing destruction sandbox processing on the original test sandbox, and uploading the backup test sandbox to a shared object storage repository, so as to continue testing the first target service based on the backup test sandbox. The test sandbox is used to realize quick and simple deployment of service migration from a test environment to production, improve the isolation granularity of resources, and effectively improve the utilization rate of physical resources, thereby effectively reducing cost overhead.

[0032] In order to make the above objectives, characteristics and advantages of the present application more apparent, more comprehensible, the following will specifically describe a preferred embodiment in conjunction with the accompanying drawings, and a detailed description is as follows. BRIEF DESCRIPTION OF DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0034] Figure 1 A flow chart of a cloud-native testing method provided by an embodiment of the present application;

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

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

[0037] Figure 4 A structural schematic diagram of a cloud-native testing device provided by an embodiment of the present application;

[0038] Figure 5 A structural schematic diagram of a cloud-native testing device provided by an embodiment of the present application;

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

[0040] In order to make the objectives, technical solutions and advantages of the embodiments of the present application more apparent, the following will clearly and completely describe the technical solutions in the embodiments of the present application 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 illustration and description, and are not used to limit the protection scope of the present application. In addition, it should be understood that the schematic drawings are not drawn according to the actual proportions. The flow chart shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow chart can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flow chart or removed from the flow chart under the guidance of the content of the present application by those skilled in the art.

[0041] In addition, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different 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 claimed present application, but only represents 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 creative labor fall within the scope of protection of the present application.

[0042] In order for those skilled in the art to use the content of the present application, the following implementation is given in combination with a specific application scenario "testing cloud native", and those skilled in the art can apply the general principles defined herein to other embodiments and application scenarios without departing from the spirit and scope of the present application.

[0043] First, the application scenarios applicable to the present application are introduced. The present application can be applied to the field of cloud native technology.

[0044] It is found through research that, with the development of cloud native technology, the use of kubernetes platform tends to be routine, and namespace is often used for resource isolation in business development and testing. However, the isolation capability of namespace is very limited, and part of the cluster granularity resources will directly cause resource use conflict, which requires the use of multiple physical clusters to meet the daily use. However, deploying multiple physical clusters will inevitably cause a large waste of resources and increase costs; with the dramatic 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; if you want to migrate some business systems from the test environment to the quasi-production, you will have to face a tedious, repetitive and time-consuming deployment process. Therefore, how to improve the efficiency of cloud native business development and the utilization rate of resources has become a technical problem that cannot be underestimated.

[0045] Based on this, the embodiments of the present application provide a cloud native testing method, which realizes the rapid and simple deployment of business migration from test environment to production by using test sandbox, improves the isolation granularity of resources and effectively improves the utilization rate of physical resources, can effectively reduce the cost overhead, and effectively improve the efficiency of cloud native business development.

[0046] Please refer to Figure 1 , Figure 1 The flowchart of a cloud native testing method provided by the embodiments of the present application. As shown in Figure 1 The cloud native testing method provided by the embodiments of the present application comprises:

[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 sandboxes are 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 interfaced.

[0049] Wherein, the test sandbox serves as a carrier for running business, and the test sandboxes are isolated from each other and the sandbox is isolated from the Kubernetes cluster, so as to avoid the failure of the Kubernetes cluster when the test sandbox fails.

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

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

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

[0053] Wherein, the pod is the smallest operation unit of k8s, and the pod is also a container with an independent sandbox environment. A container can be encapsulated in the pod, or multiple containers can be encapsulated in the pod.

[0054] Kubernetes has many controller types, including replicasets, replicationcontrollers, deployments, daemonsets, and statefulsets. Since the core concept of the cloud-native test sandbox is k8s-in-k8s, the test sandbox instance encapsulates a fully functional, lightweight k8s (k0s, k3s, k8s) within a pod. The sandbox itself runs as a stateful statefulsets controller within a host namespace, and some resources within the sandbox are also encapsulated within the same host namespace via a resource synchronizer. The test sandbox has its own independent API (apiserver) and data storage, enabling excellent isolation and security through an independent control plane.

[0055] In one possible implementation, creating a 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 between services inside the test sandbox through domain names.

[0057] The CoreDNS service is a modern, modular DNS server ideally suited for containerized environments like Kubernetes. It offers a high degree of flexibility and customization through a plugin system, allowing users to extend functionality based on their needs. Compared to traditional DNS, CoreDNS offers higher performance and flexibility, meeting the demands of modern internet architectures.

[0058] Here, the resource synchronizer: as the core component, can synchronize the low-level resources in the sandbox to the host cluster, reuse the computing and storage capabilities of the host, avoid performance loss, and 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 and the resources in the sandbox. The resource controller (Controller manager): mainly responsible for maintaining the deployments, statefulsets, CRD and other resources in the sandbox. The resource access entrance (Apiserver): the independent kubernetes apiserver in the test sandbox is used to manage various k8s resources in the test sandbox. Since each sandbox has an independent api interface, it can easily isolate the resources from the host cluster and also isolate the resources between sandboxes. The service of the test internal resource data storage (Datastore) is mainly used to store the resource data in the test sandbox, which can support SQLite, etcd, MySQL, PostgreSQL. OREDNS: implements service discovery in the sandbox. The test sandbox backup service: mainly provides complete packaging and backup of a test sandbox. After backup, it can be quickly restored after the original sandbox is deleted, and it can also complete the cross-cluster sandbox recovery.

[0059] Further, please refer to Figure 2 , Figure 2 The schematic diagram of creating a test sandbox provided by the embodiments of the present application. As Figure 2As shown, the user can create a cloud-native test sandbox 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 sandbox instance is implemented based on the concept of k8s in k8s, and a pod is used to encapsulate a k3s (k0s, k8s) micro virtual cluster in the sandbox. All businesses running in the sandbox are also isolated in a namespace of the host machine. The sandbox has the complete capability of a standard Kubernetes control plane, and uses an independent apiserver as the access portal of the virtual k8s resources in the sandbox. At the same time, the sandbox has independent data storage, which can achieve resource isolation between sandboxes and isolation between the sandbox and the host cluster resources. The sandbox also runs a resource synchronizer, which is a key component for ensuring that the test sandbox synchronizes the pod and storage resources to the host cluster. Through the resource synchronizer, the physical resources of the host cluster can be reused, so that the sandbox only needs to maintain the data of the internal control plane, and the data of the data plane can reuse the capabilities of the host cluster, thereby avoiding the performance loss caused by sandbox encapsulation and achieving the same experience as running businesses in the sandbox and the host. The test sandbox runs an independent controller manager, which is mainly used to maintain various k8s resource definitions. The internal manager maintains the consistency of the resources in the sandbox. The coreDNS running in the sandbox completes the work of accessing services between the sandbox through domain names, and fully plays a 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 is generated. According to the kubeconfig connection information provided by the test sandbox instance, the test sandbox is accessed. The test sandbox obtains the first target business, deploys the first target business in the namespace of the test sandbox, performs business orchestration processing and business verification processing on the first target business, and performs operation processing on the test sandbox after completing the business verification processing on the first target business.

[0062] The sandbox instance is built, and the kubeconfig connection information provided by the instance can be used to access the sandbox. After accessing the sandbox, the same use experience as the physical k8s cluster can be achieved in the sandbox, various business resources can be created, and the development, testing, and even automatic execution of business functions can be realized in combination with the devops process.

[0063] Here, the operation processing includes pause processing, destruction processing, and backup processing.

[0064] The business arrangement processing and the business verification processing on the first target business include: after the first target business is arranged, the arranged first target business is verified to detect whether the arranged first target business meets the business requirements. If yes, the business verification of the first target business is completed. If no, the first target business is continuously arranged until the business verification is met.

[0065] After the test sandbox is used in the application, the sandbox can be paused, destroyed, or backed up. 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 (restoration 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, the test sandbox is packaged and backed up to determine a backup test sandbox. The original test sandbox is destroyed, and the backup test sandbox is uploaded to a shared object storage library, so that the first target business is continuously tested based on the backup test sandbox.

[0067] In this step, for the backup processing, the test sandbox is packaged and backed up to determine a backup test sandbox. The original test sandbox is destroyed, and the backup test sandbox is uploaded to a shared object storage library, so that the first target business is continuously tested based on the backup test sandbox. Thus, the use rate of physical resources is effectively improved, and the cost overhead is effectively reduced.

[0068] In a possible implementation, the uploading of the backup test sandbox to the shared object storage library 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 storage library 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 into the shared object storage together.

[0071] In a possible implementation, after the original test sandbox is destroyed and the backup test sandbox is uploaded to the shared object storage, the cloud native test method further includes:

[0072] A: downloading the backup test sandbox from the shared object storage, and obtaining the second target business from the helm repository and the image repository.

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

[0074] The helm repository is a package manager of k8s, manages a local Chart repository, manages Chart Tiller server interaction, and sends Chart, instance installation, query, uninstallation and other operations. B: obtaining the second target business based on the resource access entry of the backup test sandbox, and performing new business orchestration processing and new business verification processing on the second target business in the namespace of the backup test sandbox.

[0075] Here, the second target business is obtained according to the resource access entry of the backup test sandbox, and the new business orchestration processing and the 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 the new business verification processing are completed by using the backup test sandbox, and resource waste is avoided.

[0076] In a possible implementation, after the test sandbox is destroyed and the backup test sandbox is uploaded to the shared object storage, the cloud native test method further includes:

[0077] a: detecting whether the Kubernetes cluster runs the destroyed test sandbox of another Kubernetes cluster.

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

[0079] b: if yes, it is determined whether the Kubernetes cluster and another Kubernetes cluster interface the same shared object storage.

[0080] Here, if yes, it is determined whether the Kubernetes cluster and another Kubernetes cluster interface the same shared object storage.

[0081] c: If interfacing the same shared object storage, the destroyed test sandbox is restored from the shared object storage, and a test run is performed based on the restored test sandbox.

[0082] Here, if interfacing the same shared object storage, the destroyed test sandbox is restored from the shared object storage, and a test run is performed based on the restored test sandbox.

[0083] In one possible implementation, for the suspension processing, after the service verification processing is completed on the first target service, the test sandbox is operated, including:

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

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

[0086] (2) When it is detected that the test processing based on the test sandbox is continued, the state of the suspension processing is converted to a state of running processing.

[0087] Here, when it is detected that the test processing based on the test sandbox is continued, the state of the suspension processing is converted to a state of running processing.

[0088] In specific embodiments, after the test of the service in the test sandbox instance is completed, the test sandbox can be selected to be exited, if not used for a long time, the sandbox can be selected to be suspended, after the suspension, the sandbox will not consume running resources; the test sandbox can also be selected to be backed up, after the backup, the test sandbox is deleted, the backup of the test sandbox packages the namespace on the physical cluster where the test sandbox is located as a whole, and the service data in the sandbox is also packaged, and the packaged data is stored in a remote object storage, if the test scenario needs to be restored in the future, one-key restoration can be performed, after the restoration, the resource scenario is completely restored, and new services can also be deployed; if other physical clusters also want to run the existing test sandbox, the test sandbox can also be restored across clusters by interfacing the object storage through multiple clusters.

[0089] Further, please refer to Figure 3 , Figure 3 A schematic diagram of a cloud-native test method provided by an embodiment of the present application is shown in FIG. 1. Figure 3As shown in the figure, a user creates a sandbox on a test sandbox management platform, accesses the test sandbox after creation, obtains a chart package from a helm repository, and obtains a business image from an image repository. The test sandbox instance is used to perform business orchestration processing on the chart package and the business image. After the business orchestration processing is completed, business verification processing is performed. When the business verification requirement is met, the sandbox is exited, the entire test sandbox is packaged to obtain a backup test sandbox, and the original test sandbox is deleted. The packaging file and business data of the backup test sandbox are uploaded to a shared object storage. When the sandbox needs to be restored / migrated, the backup test sandbox is downloaded from the shared object storage. The backup test sandbox is used to continue the original business verification, or the backup test sandbox is used for new business orchestration and business verification. When the original business verification or the business verification is completed, the sandbox is exited, and the downloaded backup test sandbox is destroyed.

[0090] The cloud native test method provided by the embodiment of the application comprises: deploying a basic Kubernetes environment and a test sandbox management platform, and creating a test sandbox on the test sandbox management platform after deployment; wherein each test sandbox is isolated from each other, and the test sandbox is isolated from a Kubernetes cluster in the basic Kubernetes environment; deploying a first target business in a 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 comprises suspension processing, destruction processing, and backup processing; for the backup processing, the test sandbox is exited, the test sandbox is packaged and backed up to determine a backup test sandbox, the original test sandbox is destroyed, and the backup test sandbox is uploaded to a shared object storage, so that subsequent test processing on the first target business is continued based on the backup test sandbox. The test sandbox is used to realize that the business can be quickly and simply deployed when the business is migrated from a test environment to production, the isolation granularity of resources is improved, and the use rate of physical resources is effectively improved, so that the cost overhead is effectively reduced.

[0091] Please refer to Figure 4 、 Figure 5 , Figure 4 Figure 1 is a structural schematic diagram of a cloud native test device provided by an embodiment of the application. Figure 5 Figure 2 is another structural schematic diagram of a cloud native test device provided by an embodiment of the application. As shown in the figure, the cloud native test device 400 comprises: Figure 4

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

[0093] The first processing module 420 is configured to deploy a first target service in a 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 configured to, for the backup processing, exit the test sandbox, package and backup the test sandbox to determine a backup test sandbox, perform destruction sandbox processing on the original test sandbox, and upload the backup test sandbox to a shared object storage, so as to continue to perform test processing on the first target service based on the backup test sandbox.

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

[0096] An encapsulation of a micro virtual cluster is performed in the test sandbox based on a pod on the test sandbox management platform after deployment, at least one namespace is set in the test sandbox, and a standard Kubernetes control plane of the test sandbox is created to determine the test sandbox.

[0097] Further, the deployment module 410 is configured to, when the standard Kubernetes control plane of the test sandbox is created:

[0098] The resource synchronizer, the resource controller, the resource access entry, the service of the test internal resource data storage, the coreDNS service, and the test sandbox backup service in the standard Kubernetes control plane are set.

[0099] The resource synchronizer is configured to synchronize resources inside the test sandbox to a Kubernetes cluster, the resource controller is configured to maintain resource definitions of the test sandbox, the resource access portal is configured to serve as an access portal for virtual k8s resources inside the test sandbox, the test internal resource data storage service is configured to store resource data inside the test sandbox, and the coreDNS service is configured to complete domain name access between services inside the test sandbox.

[0100] Further, the second processing module 430 is configured to, when uploading the backup test sandbox to a shared object storage:

[0101] pack a namespace on a Kubernetes cluster where the backup test sandbox is located, pack data of a first target service of the backup test sandbox, and upload the packed namespace and the data of the first target service to the shared object storage.

[0102] Further, as shown in Figure 5 the cloud-native testing device 400 further includes a third processing module 440 configured to:

[0103] download the backup test sandbox from the shared object storage, obtain a second target service from a helm repository and an image repository;

[0104] obtain the second target service based on a resource access portal of the backup test sandbox, and perform new service orchestration processing and new service verification processing on the second target service in a namespace of the backup test sandbox.

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

[0106] detect whether a Kubernetes cluster runs a destroyed test sandbox of another Kubernetes cluster;

[0107] if yes, determine whether the Kubernetes cluster and the other Kubernetes cluster interface with a same shared object storage;

[0108] if the interface is with the same shared object storage, restore the destroyed test sandbox from the shared object storage, and perform test running based on the restored test sandbox.

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

[0110] If no test is performed using the test sandbox within a preset time interval, the test sandbox is set in a state of suspension processing;

[0111] When it is detected that the test processing based on the test sandbox is continued, the state of suspension processing is converted to a state of running processing.

[0112] The cloud native testing device provided by the embodiment of the present application comprises a deployment module, which is configured to deploy a basic Kubernetes environment and a test sandbox management platform, and create at least one test sandbox on the test sandbox management platform after deployment; wherein the test sandboxes are isolated from each other, and the test sandboxes are isolated from a Kubernetes cluster in the basic Kubernetes environment; a first processing module, which is configured to deploy a first target service in a 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 comprises suspension processing, destruction processing and backup processing; and a second processing module, which is configured to, for the backup processing, exit the test sandbox, package and backup the test sandbox to determine a backup test sandbox, destroy the original test sandbox, and upload the backup test sandbox to a shared object storage to continue testing the first target service based on the backup test sandbox. The test sandbox is used to realize quick and simple deployment of service migration from a test environment to production, improve the isolation granularity of resources, and effectively improve the use rate of physical resources, thereby effectively reducing cost overhead.

[0113] Please refer to Figure 6 , Figure 6 The structure of an electronic device provided by the embodiment of the present application is shown in FIG. 6. Figure 6 As shown in FIG. 6, the electronic device 600 comprises 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 through the bus 630. The machine readable instructions are executed by the processor 610 to perform the steps of the cloud native testing method in the method embodiment shown in FIG. 1 and FIG. 2. The specific implementation can refer to the method embodiment, which will not be described here. Figure 1 and Figure 3 The specific implementation can refer to the method embodiment, which will not be described here.

[0115] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program. When the computer program is run by a processor, the computer program can execute the cloud native testing method in the method embodiment as described above. Figure 1 and Figure 3 The steps of the cloud native testing method in the method embodiment are shown, and the specific implementation can be referred to the method embodiment, and will not be described here.

[0116] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiment, and will not be described here.

[0117] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented by other ways. The device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, and for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some communication interface, device or unit, and can be electrical, mechanical or other forms.

[0118] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, can be located in one place, or can be distributed on a plurality of network units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

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

[0120] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a nonvolatile computer readable storage medium executable by a processor. Based on this understanding, the technical solutions of the present application essentially or the parts of the prior art that make contributions or parts of the technical solutions can be embodied in the form of software products. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0121] Finally, it should be noted that: the above-described embodiments are only specific embodiments of the present application, which are used to illustrate the technical solutions of the present application, but not to limit them. The protection scope of the present application is not limited thereto. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can make modifications or easily think of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed by the present application, or make equivalent replacements to some of the technical features. The modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to 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 from the Kubernetes cluster in the basic Kubernetes environment; Deploying a first target service in the namespace of the test sandbox, performing service orchestration 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; wherein the operation processing includes suspension processing, destruction processing, and backup processing; For the backup process, exit the test sandbox, 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 the shared object repository, so that the first target business can continue to be tested based on the backup test sandbox; The step of uploading the backup test sandbox to a shared object repository includes: Package the namespace on the Kubernetes cluster where the backup test sandbox is located, package the data of the first target business of the backup test sandbox, and upload the packaged namespace and the data of the first target business to the shared object repository.

2. The cloud native testing method according to claim 1, characterized in that: Create at least one test sandbox 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 between services inside the test sandbox through domain names.

4. 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.

5. 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 so, determining whether the Kubernetes cluster and the other Kubernetes cluster are connected to the same shared object repository; If the two are connected to the same shared object repository, the destroyed test sandbox is restored from the shared object repository, and the test is run based on the restored test sandbox.

6. The cloud native testing method according to claim 1, characterized in that: Regarding the suspension process, after completing the service verification process 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.

7. A cloud-native testing device, characterized in that: The cloud native testing device includes: A deployment module is used to deploy the basic Kubernetes environment and the 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 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 and service verification on the first target service, and perform operation processing on the test sandbox after completing the service verification on the first target service; wherein the operation processing includes suspension processing, destruction processing, and backup processing; a second processing module configured to, with respect to the backup processing, exit the test sandbox, 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 as to continue testing the first target business based on the backup test sandbox; The second processing module is used to upload the backup test sandbox to the shared object repository: Package the namespace on the Kubernetes cluster where the backup test sandbox is located, package the data of the first target business of the backup test sandbox, and upload the packaged namespace and the data of the first target business to the shared object repository.

8. 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 according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the steps of the cloud-native testing method according to any one of claims 1 to 6.

Images