A micro-service governance testing method and system based on a container cloud platform

Abstract

The application provides a micro-service governance test method and system based on a container cloud platform, the method comprising: obtaining a plug-in name of a micro-service to be tested; starting service governance according to identity information of the current micro-service, and matching components for the current micro-service according to service labels, and injecting label agent configuration information into the matched components; in response to a service configuration information acquisition command, identifying a returned service name, in response to a component identification information acquisition command, acquiring returned label agent configuration information, and testing the success of the underlying injection of the label agent configuration information and the success of the underlying service injection when the service governance is started. The application can cover multiple complex test processes in different scenarios and different roles, reduce the limitations of human resources and time and space, and ensure consistency and reusability through automatic testing, so that the data accuracy and comprehensiveness are ensured through multi-role and multi-angle testing.

Description

Technical Field

[0001] This invention relates to the field of container cloud platform technology, and in particular to a microservice governance testing method and system based on a container cloud platform. Background Technology

[0002] Kubernetes, or Kubernetes for short, is a portable container orchestration and management tool designed for container services. More and more companies are embracing Kubernetes, and it has already taken the lead in cloud business processes, promoting the popularization and implementation of popular technologies such as microservice architecture. It is developing rapidly, and more and more systems are based on the Kubernetes platform to extend or run their own businesses.

[0003] The powerful load capacity of the Kubernetes platform has given rise to many complex business application scenarios. As an important organization that provides service governance functions such as canary release, traffic management, service tracing, traffic monitoring, and tracing, microservice governance will inevitably consume huge human resources and make human oversights inevitable when there are new version requirements or multi-user and regression tests.

[0004] When the Kubernetes platform has new requirements for development or new version plans, the existing microservice governance functions must undergo corresponding assurance testing along with the testing plan. This requires manually covering dozens of tedious tests for different scenarios and roles, and also necessitates extensive data preparation before testing, which is time-consuming and the accuracy of the data is uncertain. When conducting large-scale validation or regression testing, repetitive testing may lead to testers developing fixed mindsets or human oversights, resulting in the omission of test issues. Summary of the Invention

[0005] This invention provides a microservice governance testing method and system based on a container cloud platform, which solves the problem that existing container cloud platform serviceless testing requires a lot of manual intervention and has high testing costs.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] The first aspect of this invention provides a microservice governance testing method based on a container cloud platform, the method comprising the following steps:

[0008] Obtain the plugin name of the microservice to be tested. If the plugin name exists in the container cloud platform plugin list and the microservice plugin status is normal, proceed to the next step.

[0009] Based on the identity information of the current microservice, enable service governance, match components for the current microservice based on service tags, and inject tag proxy configuration information into the matching components;

[0010] In response to the command to retrieve service configuration information, identify the returned service name. If the name of the current microservice exists, the underlying service injection service governance is successful when service governance is enabled.

[0011] In response to the component's identification information retrieval command, the returned tag proxy configuration information is obtained and compared with the injected tag proxy configuration information. If the comparison is consistent, the underlying component successfully injected the tag proxy configuration information when service governance is enabled.

[0012] Furthermore, enabling service governance based on the current microservice's identity information specifically involves:

[0013] Create application instances and services, lock the services based on service ID and name, generate parameter proxy configuration information, and enable service governance.

[0014] Furthermore, the application and service information that have enabled service governance are obtained through the front-end interface and compared with the parameter proxy configuration information. If the comparison is consistent, the interface data display is normal after enabling service governance.

[0015] Furthermore, after verifying the successful execution of the service start command, the testing method further includes the following steps:

[0016] The service tracking list is compared with the corresponding request information. If they match, the UI service tracking data is normal.

[0017] Furthermore, enabling service governance includes creating mesh policies, virtual services, target rules, and authentication policies, as well as adding tagging information to the application routes corresponding to the services.

[0018] Furthermore, when the matching component is a new component, the method includes:

[0019] Bind the service tag to the new component;

[0020] The grid policy controller listens for service update events and injects tag proxy configuration information into the new component.

[0021] Furthermore, after injecting the tag proxy configuration information into the current new component, the method further includes the step of:

[0022] The component controller listens for component update events, creates mesh policies, virtual services, target rules, and authentication policies for the services corresponding to the new components, and adds tagging information to the application routes corresponding to the services.

[0023] A second aspect of the present invention provides a microservice governance testing system based on a container cloud platform, the system comprising:

[0024] The resource provisioning unit is used to obtain the plugin name of the microservice to be tested. If the plugin name exists in the container cloud platform plugin list and the microservice plugin status is normal, the next step is executed.

[0025] The Service Governance Unit is used to enable service governance based on the identity information of the current microservice, match components for the current microservice based on service tags, and inject tag proxy configuration information into the matched components.

[0026] The underlying service injection test unit responds to the command to obtain service configuration information, identifies the returned service name, and if the name of the current microservice exists, then the underlying service injection service governance is successful when service governance is enabled.

[0027] The underlying component injects a test unit, responds to the component's identification information retrieval command, obtains the returned tag proxy configuration information, compares it with the injected tag proxy configuration information, and if the comparison is consistent, the underlying component successfully injects the tag proxy configuration information when service governance is enabled.

[0028] Furthermore, the system also includes:

[0029] The data display test unit obtains the application and service information that has enabled service governance through the front-end interface and compares it with the parameter transmission proxy configuration information. If the comparison is consistent, the interface data display is normal after enabling service governance.

[0030] The data tracing test unit tracks the list information of the service and compares the list information with the corresponding request information. If the two match, the interface service tracing data is normal.

[0031] A third aspect of the present invention provides a computer storage medium storing computer instructions, which, when executed on the system, cause the system to perform the steps of the method.

[0032] The microservice governance testing system of the second aspect of the present invention can implement the methods in the first aspect and its various implementations, and achieve the same effect.

[0033] The effects described in the invention are merely those of the embodiments, and not all the effects of the invention. One of the above technical solutions has the following advantages or beneficial effects:

[0034] This invention addresses the identity information of the microservice under test, initiates service governance, configures service and component information, and then verifies the configuration information. It also verifies the success or failure of injecting service governance and component injection markers when service governance is enabled. Furthermore, it tests the display and tracking of interface data after service startup. This covers multiple tedious testing processes for different scenarios and roles, reducing limitations in human resources, time, and space. Automated testing ensures consistency and reusability, and multi-role, multi-angle testing guarantees data accuracy and comprehensiveness while saving labor costs. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a flowchart illustrating an embodiment of the method described in this invention;

[0037] Figure 2 This is a structural schematic diagram of an embodiment of the system described in this invention. Detailed Implementation

[0038] To clearly illustrate the technical features of this solution, the invention will be described in detail below through specific embodiments and in conjunction with the accompanying drawings. The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure of the invention, components and arrangements of specific examples are described below. Furthermore, reference numerals and / or letters may be repeated in different examples. This repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. It should be noted that the components illustrated in the drawings are not necessarily drawn to scale. Descriptions of well-known components, processing techniques, and processes are omitted in this invention to avoid unnecessarily limiting the invention.

[0039] This invention leverages the uniqueness of plugin names within the same container platform. It queries a list via a plugin instance interface, extracts and encapsulates the plugin names into a list, iterates through the microservice's plugin name list, and if a plugin name exists in the list, proceeds to the next step. It creates an application instance or service, obtaining information such as the application name, application type, status, and resource pool of the application instance returned by the interface. Simultaneously, it obtains the returned service name, service ID, internal access address, and external access address. Based on the uniqueness of the service ID and name, it identifies the service, passes proxy configuration information to enable service governance, and creates a meshpolicy policy at the container platform's underlying layer. The system queries the names of services under this policy that have enabled service governance. Then, the underlying service layer creates virtualservice, destinationrule, and peerauthentication resources. The service's corresponding ID... The `ngress` function adds annotation information, and the `workload` function injects annotation information. Underlying information is verified via command query, and the names of services with enabled service governance are displayed in the returned data by traversing the list. After successful verification of the underlying service and component information, the system logs into the front-end interface and retrieves information about applications and services with enabled service governance through an API. This information is then encapsulated into a list, along with a list of pre-configured resources and parameters passed during service governance activation. The application and service lists are compared one-to-one with the parameter lists. If the comparison between the enabled application and service information and the pre-configured information is successful, the system proceeds to the next step; otherwise, an exception is thrown to the service governance interface data display, and the fields where the comparison failed are printed. After successful activation, service tracing and canary deployments are performed, and the service tracing and canary deployment data are verified. The test then ends. The following is a detailed explanation with reference to the attached diagram.

[0040] like Figure 1 As shown, this embodiment of the invention provides a microservice governance testing method based on a container cloud platform, including the following steps:

[0041] S1. Obtain the plugin name of the microservice to be tested. If the plugin name exists in the container cloud platform plugin list and the microservice plugin status is normal, proceed to the next step.

[0042] S2, based on the identity information of the current microservice, enable service governance, and match components for the current microservice according to the service tags, and inject tag proxy configuration information into the matching components;

[0043] S3 responds to the command to obtain service configuration information, identifies the returned service name, and if the name of the current microservice exists, the underlying service injection service governance is successful when service governance is enabled;

[0044] S4, responding to the component's identification information retrieval command, retrieves the returned tag proxy configuration information and compares it with the injected tag proxy configuration information. If the comparison matches, the underlying component successfully injects the tag proxy configuration information when service governance is enabled.

[0045] In step S1, the plugin name for microservice governance is used as the keyword. The uniqueness of the plugin name within the same container platform is checked to see if the plugin exists. If it exists, the plugin status is checked to see if it is normal. If it is normal, an application instance or service resource is created. Otherwise, the test is exited with a message indicating that the plugin does not exist or an error occurs.

[0046] In step S2, enabling service governance based on the current microservice's identity information specifically involves:

[0047] Create application instances and services, lock the services based on service ID and name, generate parameter proxy configuration information, and enable service governance.

[0048] Enabling service governance includes creating a mesh policy (primarily agent configuration information, CPU, memory, MTLS authentication mode, etc.). Successful creation can be verified using the command: `#kubectl get meshpolicies.imesh.icks.inspur.com -n`. The Istio database includes several service names (namespace name, which displays the names of services with created meshpolicies), virtual services (a crucial resource in Istio that defines a series of traffic routing rules for a specific service; each rule matches a specific protocol; if traffic matches these characteristics, it is sent to the target service, a subset or version of the target service, in the service registry), destination rules (implementing load balancing, service discovery, fault handling, and fault injection for the target service), peer authentication policies (PeerAuthentication is used to configure the mTLS mode for service communication, used for service-to-service authentication to verify the client making the connection. Istio provides bidirectional TLS as a full-stack solution for transport authentication. For bidirectional TLS, Istio automatically upgrades all traffic between two PEPs to bidirectional TLS), and annotation information added to the application route ingress corresponding to the service: nginx.ingress.kubernetes.io / upstream-vhost:service_name.namespace_name.svc.cluster.local.

[0049] In step S3, the system logs into the underlying layer via a script and uses commands to retrieve the service's vs, dr, and pa information, where vs, dr, and pa represent the virtual service, destination rule, and authentication policy, respectively. The information retrieval commands are as follows:

[0050] #kubectl get vs -n namespace_name;

[0051] #kubectl get dr–n namespace name;

[0052] #kubectl get pa -n namespace_name;

[0053] The returned service names are encapsulated into a list. By traversing the list, it is verified that the service names with service governance enabled are displayed in the query returned data. If the underlying service successfully injects service governance-related information, proceed to the next step; otherwise, an exception is thrown: the underlying service failed to inject service governance-related information when enabling service governance.

[0054] In step S4, the component workload identification information -- YAML information -- is obtained through a command. The proxy configuration information of the annotation in the returned component YAML information is extracted and compared with the proxy configuration information of the annotation passed in during startup, such as CPU, memory, sampling rate, authentication mode, etc. If the comparison is successful, the underlying component successfully injects the proxy information of the annotation and proceeds to the next step; otherwise, an error message is thrown indicating that the underlying component failed to inject the proxy information of the annotation.

[0055] In one implementation of this invention, after the underlying service and component information verification is successful, the system logs into the front-end interface, obtains the application and service information that has enabled service governance through the interface, encapsulates the obtained application and service information into a list, and encapsulates the preset resources and the parameter information passed when enabling service governance into a list. The list information of applications and services is compared one-to-one with the list information of the passed parameters. If the information of applications and services after enabling service governance is successfully compared with the preset information, the system proceeds to the next step; otherwise, an error is thrown indicating that the data display of the service governance interface after enabling service governance is abnormal, and the field information of the comparison failure is printed out.

[0056] In another implementation of this invention, after successful service governance, the user logs into the underlying system and uses the curl command to access the service.

[0057] #curl external access address for the service;

[0058] The service tracing list and request information are obtained through the interface. The service tracing list and request information are compared. If the comparison is successful, the test ends; otherwise, an exception is thrown for the service tracing data in the interface.

[0059] Canary release: After successfully enabling service governance, release the service using canary, blue-green, A / B test, or traffic mirroring methods according to your needs. Once the release is successful and the corresponding components and related configurations are created, check if the component status is normal and if the obtained component parameter information is consistent with the preset data information. If the comparison is successful, the test ends; otherwise, throw a canary release exception and print the exception reason.

[0060] This concludes the microservice governance testing.

[0061] In step S2, when the matching component is a new component, the method includes the following steps: after the service starts service governance, the application adds a new component without starting the service, and binds the new component under the application by editing the label in the service's YAML information. When the Meshpolicy controller listens to the service update event and finds that the component matching the service does not have an annotation, it injects the annotation proxy configuration information into the component workload.

[0062] The underlying layer injects annotations to mark proxy configuration information into components that do not have service governance enabled by editing the component's identification information (YAML information). At this time, the component controller (Workload controller) listens for component update events. If it finds that the service corresponding to the component has not created a mesh policy, it creates the corresponding mesh policy, creates virtualservice and destinationrule, and peerauthentication resources for the service, and adds annotation information to the ingress corresponding to the service: nginx.ingress.kubernetes.io / upstream-vhost:service_name.namespace_name.svc.cluster.local.

[0063] like Figure 2 As shown in the figure, this embodiment of the invention also provides a microservice governance testing system based on a container cloud platform. The system includes a resource pre-provisioning unit 1, a service activation governance unit 2, a bottom-level service injection testing unit 3, a bottom-level component injection testing unit 4, a data display testing unit 5, and a data tracing testing unit 6.

[0064] Resource pre-configuration unit 1 is used to obtain the plugin name of the microservice to be tested. If the plugin name exists in the container cloud platform plugin list and the microservice plugin status is normal, proceed to the next step. Service governance start unit 2 is used to start service governance according to the identity information of the current microservice, and match components for the current microservice according to the service tag, and inject the tag proxy configuration information into the matching component. Underlying service injection test unit 3 responds to the service configuration information acquisition command, identifies the returned service name. If the name of the current microservice exists, the underlying service injection service governance is successful when service governance is started. Underlying component injection test unit 4 responds to the component identification information acquisition command, obtains the returned tag proxy configuration information, and compares it with the injected tag proxy configuration information. If the comparison is consistent, the underlying component tag proxy configuration information injection is successful when service governance is started. Data display test unit 5 obtains the application and service information with service governance started through the front-end interface, and compares it with the parameter proxy configuration information. If the comparison is consistent, the interface data display is normal after service governance is started. Data tracing test unit 6 tracks the service list information, compares the list information with the corresponding request information. If the two match, the interface service tracing data is normal.

[0065] This invention also provides a computer storage medium storing computer instructions, which, when executed on the system, cause the system to perform the steps of the method.

[0066] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for microservice governance testing based on a container cloud platform, characterized in that, The method comprises the following steps: Obtain the plug-in name of the microservice to be tested. If the plug-in name exists in the container cloud platform plug-in list and the microservice plug-in state is normal, the next step is performed. According to the identity information of the current microservice, the service governance is started, and the components matching the current microservice are matched according to the service label. The matching components are injected with label agent configuration information. In response to the service configuration information acquisition command, the returned service name is identified. If the name of the current microservice exists, the underlying service injection service governance is successful when the service governance is started. In response to the component identification information acquisition command, the returned label agent configuration information is acquired. If the comparison is consistent, the underlying component injection label agent configuration information is successful when the service governance is started.

2. The microservice governance testing method based on the container cloud platform according to claim 1, characterized in that, The service governance is started according to the identity information of the current microservice, and the specific process is as follows: Create an application instance and a service, lock the service according to the service ID and name, form a parameter passing agent configuration information, and start the service governance.

3. The microservice governance testing method based on the container cloud platform according to claim 2, characterized in that, Through the foreground interface, the application and service information of the started service governance are acquired, and the parameter passing agent configuration information is compared. If the comparison is consistent, the interface data display after the service governance is started is normal.

4. The microservice governance testing method based on the container cloud platform of claim 1, wherein, The test method further comprises the following steps after verifying the success of the service starting instruction: Track the list information of the service, and compare the list information with the corresponding request information. If the two are matched, the interface service tracking data is normal.

5. The method of claim 1, wherein the method further comprises: Starting service governance includes creating grid policy, virtual service, target rule and authentication policy, and adding label information to the application route corresponding to the service.

6. The method of claim 1, wherein the method further comprises: When the matching component is a new component, the method comprises the following steps: Bind the service label to the new component. The grid policy controller listens to the service update event, and injects the label agent configuration information into the current new component.

7. The method of claim 6, wherein the method further comprises: After the label agent configuration information is injected into the current new component, the method further comprises the following steps: The component controller listens to the update event of the component, creates grid policy, virtual service, target rule and authentication policy for the service corresponding to the new component, and adds label information to the application route corresponding to the service. 8.A microservice governance testing system based on a container cloud platform, characterized in that, The system comprises: A resource preset unit is configured to obtain the plug-in name of the microservice to be tested. If the plug-in name exists in the container cloud platform plug-in list and the microservice plug-in state is normal, the next step is performed. A service governance starting unit is configured to start the service governance according to the identity information of the current microservice, and match the components matching the current microservice according to the service label. The matching components are injected with label agent configuration information. A bottom service injection test unit is configured to identify the returned service name in response to the service configuration information acquisition command. If the name of the current microservice exists, the underlying service injection service governance is successful when the service governance is started. A bottom component injection test unit is configured to acquire the returned label agent configuration information in response to the component identification information acquisition command. If the comparison is consistent, the underlying component injection label agent configuration information is successful when the service governance is started.

9. The microservice governance testing system based on the container cloud platform according to claim 8, characterized in that, The system further comprises: The data display test unit obtains the application and service information of the application with the service management started through the foreground interface, compares with the parameter passing agent configuration information, and if the comparison is consistent, the interface data display is normal after the service management is started. The data tracking test unit tracks the list information of the service, and compares the list information with the corresponding request information, and if the two are matched, the interface service tracking data is normal.

10. A computer storage medium having stored computer instructions, wherein the computer instructions comprise the steps of: The computer instructions, when running on the system of claim 8 or 9, make the system perform the steps of the method of any one of claims 1-7.

Images