Service governance method and apparatus, and computer-readable storage medium

Abstract

Provided in the present application are a service governance method and apparatus, and a computer-readable storage medium. The method is applied to a management node for managing virtual private clouds of a plurality of tenants, wherein clusters are deployed in the virtual private clouds, and services are deployed in the clusters; and the management node receives and manages a managed cluster of a target tenant, and a target service is deployed in the managed cluster. The method comprises: determining service information corresponding to a target tenant, wherein the service information indicates information of a service instance of a target service in a managed cluster; creating a gateway corresponding to the target tenant, wherein the gateway comprises a traffic monitoring rule; determining a traffic processing rule corresponding to the target service, wherein the traffic processing rule is associated with a target monitoring rule in the traffic monitoring rule; and sending the service information, the target monitoring rule and the traffic processing rule to a traffic agent in a virtual private cloud of the target tenant, such that the traffic agent performs service governance on the target service. A service governance rule of a tenant is sent to an agent in a virtual private cloud of the tenant, such that data isolation is implemented, so as to improve data security.

Description

Service management method, device and computer-readable storage medium

[0001] This application claims priority to the Chinese patent applications filed with the State Intellectual Property Office of China on July 7, 2023, with application number 202310834268.4 and application name “Service Management Method and Device”, and filed with the State Intellectual Property Office of China on September 18, 2023, with application number 202311207362.3 and application name “Service Governance Method, Device and Computer-readable Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of service governance technology, and in particular to a service governance method, device, and computer-readable storage medium. Background Art

[0003] Kubernetes (k8s) is the de facto standard for container orchestration, solving the orchestration and management issues of container clusters. However, k8s does not provide an automated solution for inter-cluster access or north-south traffic from outside a cluster to services within k8s. Manual configuration is required, which is complex and error-prone. The open source service mesh project, istio, a microservices governance platform, provides excellent support for k8s. It can serve as a gateway for access outside k8s and enable cross-cluster access.

[0004] Istio-based cloud-native gateway solutions include a single control plane and multiple data planes. However, in multi-tenant scenarios, Istio considers identical services in different Kubernetes clusters to be identical services, even if those clusters belong to different tenants. Data isolation is not performed, resulting in lower data security.

[0005] The information disclosed in this background technology section is only intended to enhance the understanding of the overall background of the application and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to a person skilled in the art.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a service governance method, device and computer-readable storage medium, in which a single control plane creates gateways for different tenants, and different tenants independently configure service governance rules; when performing service governance, the tenant's service governance rules are sent to the agent in the tenant's virtual private cloud, thereby achieving data isolation and improving data security.

[0008] In a first aspect, an embodiment of the present application provides a service governance method, which is applied to a management node, wherein the management node manages a virtual private cloud of multiple tenants, wherein a cluster is deployed in the virtual private cloud, and a service is deployed in the cluster; the management node manages a managed cluster of a target tenant among the multiple tenants, and the managed cluster deploys a target service. The method includes:

[0009] Determine the service information corresponding to the target tenant, where the service information indicates the information of the service instance of the target service in the managed cluster; create a gateway corresponding to the target tenant; the gateway includes traffic monitoring rules; determine the traffic processing rules corresponding to the target service; the traffic processing rules are associated with the target monitoring rules in the traffic monitoring rules; the service information, target monitoring rules, and traffic processing rules are sent to the traffic agent in the virtual private cloud of the target tenant; the traffic agent is used to perform service governance on the target service based on the service information, traffic monitoring rules, and target monitoring rules.

[0010] In this solution, a single control plane creates gateways for different tenants, and different tenants independently configure service governance rules. During service governance, the tenant's service governance rules are sent to the agent in the tenant's virtual private cloud, thereby achieving data isolation and improving data security.

[0011] In one possible implementation, the target service is located in a first namespace in the managed cluster; the target service is located in a second namespace in the management node; when the managed clusters of different target tenants include target services located in the first namespace, the target services of different target tenants in the management node are located in different second namespaces.

[0012] In this solution, the control plane implements tenant-level service isolation through namespaces.

[0013] In a possible implementation, the method further includes: creating a second namespace, and mapping the target service to the second namespace. Exemplarily, information in the service information located in the first namespace is mapped to the second namespace.

[0014] In a possible implementation, creating the second namespace includes: installing a cluster synchronizer in a managed cluster of the target tenant; and creating the second namespace in response to control of the cluster synchronizer.

[0015] It should be noted that the cluster synchronizer can also synchronize service information to the management node.

[0016] In one possible implementation, the traffic proxy is used to manage multiple managed clusters of a target tenant; under the condition that each of the multiple managed clusters includes a target service located in a first namespace, the traffic proxy is used to perform service governance on the target services in the multiple managed clusters based on service information, traffic monitoring rules, and target monitoring rules.

[0017] In a possible implementation, the traffic monitoring rule includes configuration for a listener resource. Exemplarily, the configuration for the listener resource at least indicates a listener corresponding to the traffic proxy.

[0018] In one possible implementation, the traffic processing rule includes a configuration for a routing resource. Exemplarily, the configuration for the routing resource at least indicates a rule for routing to a service instance of a target service.

[0019] In one possible implementation, service governance is performed on the target service based on service information, traffic monitoring rules, and target monitoring rules, including: forwarding requests entering the gateway to the target service based on service information, traffic monitoring rules, and target monitoring rules, and / or forwarding requests issued by the target service through the gateway to an external or another managed cluster of the target tenant.

[0020] In a second aspect, an embodiment of the present application provides a service governance device, which includes several modules, each of which is used to perform each step of the service governance method provided in the first aspect of the embodiment of the present application. The division of modules is not limited here. The specific functions performed by each module of the service governance device and the beneficial effects achieved can be referred to the functions of each step of the service governance method provided in the first aspect of the embodiment of the present application, and will not be repeated here.

[0021] For example, the service governance device is applied to a management node, which manages virtual private clouds of multiple tenants, wherein clusters are deployed in the virtual private clouds, and services are deployed in the clusters; the management node manages a managed cluster of a target tenant among the multiple tenants, and the managed cluster deploys a target service. The device includes:

[0022] A service information determination module is used to determine the service information corresponding to the target tenant, where the service information indicates information about the service instance of the target service in the managed cluster;

[0023] The gateway creation module is used to create a gateway corresponding to the target tenant; the gateway includes traffic monitoring rules;

[0024] A rule determination module is used to determine the traffic processing rules corresponding to the target service; the traffic processing rules are associated with the target monitoring rules in the traffic monitoring rules;

[0025] The delivery module is used to send service information, target monitoring rules, and traffic processing rules to the traffic agent in the target tenant's virtual private cloud; the traffic agent is used to manage the target service based on the service information, traffic monitoring rules, and target monitoring rules.

[0026] In one possible implementation, the target service is located in a first namespace in the managed cluster; the target service is located in a second namespace in the management node; when the managed clusters of different target tenants include target services located in the first namespace, the target services of different target tenants in the management node are located in different second namespaces.

[0027] In a possible implementation, the apparatus further includes:

[0028] The isolation module is configured to create a second namespace and map the target service to the second namespace. For example, the service information in the first namespace is mapped to the second namespace. It should be noted that the cluster synchronizer can also synchronize service information to the management node.

[0029] In a possible implementation, the isolation module is configured to install a cluster synchronizer in the managed cluster of the target tenant; and create a second namespace in response to control of the cluster synchronizer.

[0030] In one possible implementation, the traffic proxy is used to manage multiple managed clusters of a target tenant; under the condition that each of the multiple managed clusters includes a target service located in a first namespace, the traffic proxy is used to perform service governance on the target services in the multiple managed clusters based on service information, traffic monitoring rules, and target monitoring rules.

[0031] In a possible implementation, the traffic monitoring rule includes configuration for a listener resource. Exemplarily, the configuration for the listener resource at least indicates a listener corresponding to the traffic proxy.

[0032] In one possible implementation, the traffic processing rule includes a configuration for a routing resource. Exemplarily, the configuration for the routing resource at least indicates a rule for routing to a service instance of a target service.

[0033] In one possible implementation, the traffic proxy is used to forward requests entering the gateway to the target service based on service information, traffic monitoring rules, and target monitoring rules, and / or forward requests issued by the target service through the gateway to an external or another managed cluster of the target tenant.

[0034] In the third aspect, an embodiment of the present application provides a service governance device, comprising: at least one memory for storing programs; at least one processor for executing the programs stored in the memory, and when the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect.

[0035] In a fourth aspect, an embodiment of the present application provides a service management device, characterized in that the device runs computer program instructions to execute the method provided in the first aspect. Exemplarily, the device can be a chip or a processor.

[0036] In one example, the apparatus may include a processor, which may be coupled to a memory, read instructions from the memory, and execute the method provided in the first aspect according to the instructions. The memory may be integrated into a chip or processor, or may be independent of the chip or processor.

[0037] In a fifth aspect, an embodiment of the present application provides a computer storage medium, in which instructions are stored. When the instructions are executed on a computer, the computer executes the method provided in the first aspect.

[0038] In a sixth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method provided in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] FIG1a is a schematic diagram of a scenario of a single control plane and multiple data planes provided in the related art;

[0040] FIG1b is a schematic diagram of a scenario of multiple control planes and multiple data planes provided in the related art;

[0041] FIG2 is a schematic diagram of the architecture of a service system provided in an embodiment of the present application;

[0042] FIG3 is a flow chart of a service management method provided in an embodiment of the present application;

[0043] FIG4a is a schematic diagram of the working principle of Envoy provided in an embodiment of the present application;

[0044] FIG4 b is a schematic diagram of a request processing scenario for a single tenant under the method provided in FIG3 ;

[0045] FIG4 c is a schematic diagram 1 of request processing scenarios of different tenants under the method provided in FIG3 ;

[0046] FIG4 d is a second schematic diagram of request processing scenarios of different tenants under the method provided in FIG3 ;

[0047] FIG4e is a schematic diagram of a scenario under the method provided in FIG3 ;

[0048] FIG5 is a schematic diagram of the process of step 302 in FIG3 ;

[0049] FIG6 a is a schematic diagram of request processing scenarios of different tenants under the method provided in FIG5 ;

[0050] FIG6 b is a schematic diagram of request processing scenarios of different tenants under the method provided in FIG5 ;

[0051] FIG7 is a diagram illustrating a scenario of a service governance method provided in an embodiment of the present application;

[0052] FIG8 is a structural diagram of a service management device provided in an embodiment of the present application;

[0053] FIG9 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0054] FIG10 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0055] FIG. 11 is a schematic diagram of the computing device cluster provided in FIG. 10 . DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0057] In the description of the embodiments of the present application, words such as "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of the present application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0058] In the description of the embodiments of this application, the term "and / or" is simply a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone, B exists alone, and A and B exist at the same time. In addition, unless otherwise specified, the term "plurality" means two or more. For example, "multiple systems" refers to two or more systems, and "multiple terminals" refers to two or more terminals.

[0059] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly identifying the technical features being referred to. Thus, features specified as "first" or "second" may explicitly or implicitly include one or more of such features. The terms "include," "comprising," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0060] The following is an explanation of some of the terms used in this embodiment. It should be noted that these explanations are for the purpose of facilitating understanding by those skilled in the art and are not intended to limit the scope of protection claimed in this application.

[0061] Application Programming Interface (API): The main purpose is to provide applications and developers with the ability to access a set of routines without having to access the source code or understand the details of the internal working mechanism.

[0062] Microservices are small services comprised of a single application. Each microservice has its own process and can communicate with other microservices through lightweight communication mechanisms, such as an application programming interface (API) based on the Hypertext Transfer Protocol (HTTP).

[0063] Microservice architecture (microservice architecture): A service-oriented architecture (SOA) that divides complex systems into multiple small services or applications. These small services or applications are called microservices. Each microservice implements a separate piece of business logic. Microservices are built around business functionality and can be deployed independently. Microservices rely on each other to provide a range of functionality. Microservices are easy to understand and modify, providing flexibility in language and framework selection.

[0064] Service governance manages the relationships between service calls within a distributed service framework. This includes service registration and discovery, load balancing, fault handling and recovery (such as rate limiting, circuit breaking, timeouts, and retries), phased releases, and service tracing. In a microservices architecture, service governance, also known as SOA (service-oriented architecture) governance, is the process used to manage the adoption and implementation of a microservices architecture.

[0065] Virtual Private Cloud (VPC): A logically isolated, user-configured and managed virtual network environment built for instances. It aims to improve the security of user resources and simplify network deployment. Within a VPC, users can freely select IP address ranges, create multiple subnets, customize security groups, and configure routing tables and gateways. This allows for convenient network management and configuration, making network changes secure and fast.

[0066] Traffic: The amount of data transmitted on a network. Simply put, it is the amount of data transmitted on a network. The size of network traffic can be measured by the number of packets or the size of the data.

[0067] North-South traffic: Traffic entering the VPC from the public network and traffic leaving the VPC from the public network. This primarily refers to traffic crossing the VPC boundary, including external clients accessing services within the VPC and services within the VPC accessing external services or applications.

[0068] East-West Traffic: Traffic within a VPC, primarily refers to traffic between different areas within the same VPC, such as traffic between different subnets or traffic between different microservices.

[0069] Token: In computer authentication, it means a temporary token. In lexical analysis, it means a tag. It is commonly used for invitations and login systems.

[0070] Kubernetes (k8s) cluster: It is an open source platform for automated container operations. Based on Docker technology, it provides a series of complete functions such as deployment and operation, resource scheduling, service discovery and dynamic scaling for containerized applications, which improves the convenience of large-scale container cluster management. It is a distributed cluster consisting of management nodes (Master-Node) and nodes (Node). The k8s cluster consists of Master-Node and Node nodes. Among them, the Master-Node can be a hardware server or implanted in a virtualized environment. For example, the server involved in this solution can be a virtual machine executed on a hardware server that includes one or more other virtual machines. The nodes (Node) are similar and will not be repeated here. For example, as shown in Figure 2, the k8s cluster includes one or more Master-Node C11 and N nodes (Node): W11,..., W1N.

[0071] Apiserver: API gateway for the k8s cluster control plane.

[0072] Container Networking Interface (CNI): It is actually an interface that abstracts the implementation of k8s network operations.

[0073] Container: A virtualization technology used in computer operating systems. This technology allows processes to run in relatively independent and isolated environments (including independent file systems, namespaces, and resource views). This simplifies software deployment, enhances software portability and security, and improves system resource utilization. Container technology is widely used in service-oriented scenarios in cloud computing.

[0074] A pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A pod contains a group of one or more containers that share storage, networking, and declarations about how to run them. Pod contents always coexist and are scheduled together, running in a shared context. A pod models an application-specific "logical host" containing one or more application containers that are relatively tightly coupled together.

[0075] Endpoint: A resource object in a k8s cluster that records the access addresses of all pods corresponding to a service. It can be understood as a specific "application instance."

[0076] EndpointSlices: It provides a scalable and extensible alternative to the Endpoint API. EndpointSlices track the IP address, port, readiness, and topology of the Service's Pods.

[0077] Service mesh technology: Discovery and routing between services are no longer directly based on IP addresses, but based on service metadata information (including but not limited to service name, version, etc.).

[0078] Istio: It is an open platform for service governance in the form of a Service Mesh. The "Service Mesh form" can be understood as Istio implementing a Service Mesh; "service" can be simply understood as a microservice or a single application, which is the object of Istio governance, and "governance" is precisely the function provided by Istio, including traffic management, security, and observability of services. Traffic management: Istio can control the traffic and API calls between services through simple rule configuration and traffic routing. Security: Istio manages the authentication mechanism, channel encryption service, and access authorization for communication between services to ensure the security of service communication, and all these functions do not require changes to the application; Observability: Istio has powerful link tracking, monitoring, and logging capabilities, which makes it easy to understand the operation status of the service and discover and solve problems.

[0079] Envoy: is an open-source edge and service proxy designed for cloud-native applications. The Envoy proxy can forward traffic to external websites, forward traffic to Docker containers, and perform path-based routing to control traffic destinations. Istio includes a control plane and a data plane. The data plane is composed of Envoy proxies, which provide service discovery, traffic management for intelligent routing, and elasticity. The Envoy proxy is a high-performance proxy developed in C++ that mediates inbound and outbound traffic for all services in the service mesh.

[0080] Cluster: It is a group of logically similar upstream hosts that Envoy is connected to, which can also be understood as an "application cluster", which corresponds to one or more Endpoints that provide the same service. Cluster is similar to the concept of Service in Kubernetes, that is, a Kubernetes Service corresponds to one or more Pods that are started with the same image and provide the same service. Envoy can determine the health status of the Endpoint (cluster member) through active health checks. How Envoy routes requests to the Endpoint (cluster member) is determined by the load balancing strategy. In the embodiments of the present application, for the convenience of description and distinction, Cluster can be referred to as an application cluster.

[0081] Listener: is a service (program) listener, which is a named network location (for example, port, unix domain socket, etc.) that can be connected by downstream clients. Envoy exposes one or more listeners connected by downstream hosts. Any number of Listeners can be started, and each listener is independently configured with a certain number of (L3 / L4) network filters.

[0082] Route: Used to decide which Cluster to send the data to for processing.

[0083] Filter: Add more integrated functions without changing the core functions of Envoy. Currently, Envoy already includes multiple listener filters.

[0084] Httproute: Indicates HTTP routing rules, such as the requested domain name, which rules the path meets, and which cluster it is forwarded to.

[0085] XDS (X Discovery Service): The communication protocol between Istio's control and data planes. Specifically, within the Istio architecture, the XDS protocol provides a standard control plane specification for communicating information to the data plane. The "X" here refers to a set of service discovery protocols based on different data sources, rather than a specific protocol. XDS can also be understood as a generic term for a series of services, including Listener Discovery Service (LDS), Router Discovery Service (RDS), Cluster Discovery Service (CDS), and Endpoint Discovery Service (EDS). Envoy introduced the XDS communication protocol API to enable dynamic configuration to adapt to changing infrastructure. In Envoy, XDS is referred to as the data plane API and serves as the communication protocol between the control and data planes. These APIs can also be used by other proxies in specific scenarios. Envoy uses these APIs to dynamically obtain configuration information for resources such as clusters, endpoints, listeners, and routes from the control plane.

[0086] Gateway: Encapsulates multiple microservices within a business system and provides a unified access point. All requests entering and exiting a cluster, such as a Kubernetes cluster, must pass through the gateway, enabling unified management and monitoring of cross-cluster requests. The gateway also provides service security authentication, request authorization, and support for multiple communication protocols and message formats.

[0087] Namespace: It is a form of code organization used by many programming languages. Namespaces are used to classify and distinguish different code functions, avoiding conflicts caused by the same variable names when different code snippets (usually used by different people to work together or call existing code snippets) are used at the same time.

[0088] Classless Inter-Domain Routing (CIDR) is a method for creating additional addresses on the Internet. These addresses are provided to service providers (ISPs), who then allocate them to their customers. CIDR centralizes routing, allowing a single IP address to represent thousands of IP addresses served by major backbone providers, thus reducing the burden on Internet routers. Without CIDR, routers would not be able to support the proliferation of Internet websites. CIDR uses variable network IDs of 13 to 27 bits, rather than the fixed 7, 14, and 21 bits used by Class ABC network IDs.

[0089] In related technologies, Istio controls cluster traffic by deploying Gateway at the edge of the cluster.

[0090] In one possible scenario, a single control plane with multiple data planes can be deployed. For example, in a Kubernetes cluster (also called a Kubernetes cluster), as shown in Figure 1a, one Envoy is deployed per Kubernetes cluster (also called a Kubernetes cluster). All Kubernetes clusters share a single Istio control plane. This single control plane, serving as the sole entry point for issuing flow control rules, monitors all Kubernetes cluster services. Envoys on the data planes of all Kubernetes clusters connect to this control plane to obtain information generated by XDS.

[0091] In Istio's single control plane and multiple data plane solution, Istio considers the same Service under the same namespace in different k8s clusters to be the same service. Even if the two k8s clusters belong to different tenants, they will not be isolated, and it is impossible to formulate a separate service governance plan for a certain tenant. For example, as shown in Figure 1a, assuming that the control plane of Istio manages k8s-cluster1 of tenant 1 and k8s-cluster1 of tenant 2, k8s-cluster1 includes namespace namespace1, namespace1 includes service Service1, k8s-cluster2 includes namespace namespace1, namespace1 includes service Service1, at this time, Istio will consider the service Service1 of tenant 1 and tenant 2 to be the same service.

[0092] In another possible scenario, multiple control planes and multiple data planes can be deployed. Taking the k8s cluster as an example, as shown in Figure 1b, one k8s cluster deploys one Envoy, and all k8s clusters have an independent Istio control plane, each deployed on a different node. Services belonging to different k8s clusters of different tenants can be isolated. However, Istio does not actively open up service access between k8s clusters. Users need to actively register service entries for mutual access between k8s clusters. For example, as shown in Figure 1b, assuming that Istio's control plane 1 manages tenant 1's k8s-cluster1, and control plane 2 manages k8s-cluster2, k8s-cluster1 includes namespace namespace1, namespace1 includes service Service1, k8s-cluster2 includes namespace namespace1, namespace1 includes service Service1, at this time, Istio will consider tenant 1's k8s-cluster1 and k8s-cluster2's service Service1 to be different services. Control plane 3 manages k8s-cluster 3 of tenant 2. k8s-cluster 2 includes namespace namespace 1, which includes service Service 1. At this point, Istio considers the Service 1 of tenant 1 and tenant 2 to be different services.

[0093] Istio's multi-control-plane, multi-data-plane solution can isolate services in different Kubernetes clusters, but it requires assigning an Istio control plane to each cluster, which consumes a lot of resources. If a tenant has multiple Kubernetes clusters, the same service in the same namespace across multiple Kubernetes clusters within the tenant will be considered different services, making it impossible to manage services at the tenant level.

[0094] In order to facilitate understanding of the technical solutions provided by the embodiments of the present application, the service system to which the service governance method provided by the embodiments of the present application may be applied is first introduced. FIG2 shows an example diagram of the architecture of a service system provided by the embodiments of the present application. The embodiments of the present application provide a service governance method that can be applied to the system architecture diagram shown in FIG2. As shown in FIG2, the service system includes multiple computing devices 110 and terminal devices 120.

[0095] The terminal device 120 may be, but is not limited to, various personal computers, laptops, smartphones, tablet computers, and portable wearable devices. Exemplary embodiments of the terminal devices involved in this solution include, but are not limited to, electronic devices running iOS, Android, Windows, Harmony OS, or other operating systems. The embodiments of this application do not specifically limit the type of electronic device.

[0096] The computing device 110 may be a terminal, a computer, or a server. In one example, the server in this solution may be used to provide cloud services. It may be a server or a hyperterminal that can establish communication connections with other devices and provide computing and / or storage functions for other devices. The server in this solution may be a hardware server, which may deploy a virtual server.

[0097] The terminal device 120 communicates with multiple computing devices 110 through a network.

[0098] A service governance system is deployed on multiple computing devices 110 and includes one management node 111 and N tenant virtual private clouds (VPCs) 112. For example, Figure 2 shows two tenant VPCs, designated Tenant1-VPC and Tenant2-VPC for ease of description and distinction.

[0099] Among them, a cluster is deployed in VPC112, such as a k8s cluster. The cluster includes multiple nodes (Node), and the multiple nodes are divided into management nodes (Master-Node) and nodes (Node). Among them, the management node (Master-Node) can be a hardware server, or it can be implanted in a virtualized environment. For example, the server involved in this solution can be a virtual machine executed on a hardware server that includes one or more other virtual machines. The nodes (Node) are similar and will not be repeated here. For example, as shown in Figure 2, the cluster includes 1 management node (Master-Node) C11 and N nodes (Node): W11,...

[0100] For each node (Node), there are one or more container groups. Each container group can be composed of one or more containers (container). For example, as shown in Figure 2, the container group can refer to the Pod in the k8s cluster. Each container group can deploy one service, and the container group of each node (Node) can deploy the same service or different services; for example, as shown in Figure 2, the multiple Pods of NodeW11 are deployed with N+1 services (Service0 to ServiceN). Among them, each service can be set up or run in several container groups. A service can implement an independent business logic, for example, it can be a microservice. Multiple services can provide corresponding business functions through calling and being called relationships. A service can generate access requests to call other services or applications. Among them, a service can send requests to the outside or receive requests from the outside.

[0101] It should be noted that the management node 111 is deployed with the Istio control plane, which can be understood as a process running in the management node 111; or, it can be a program or module running on the management node 111 with control and management functions.

[0102] In order to solve the above problems, the technical ideas of the service governance method provided in the embodiment of the present application are as follows.

[0103] The management node 111 deploys a single control plane, which isolates services at the tenant level. In this way, the same services of different tenants will be identified as different services. When performing service governance, different tenants can configure service governance rules for the same service based on the actual needs of the tenants. In this way, different tenants can have different service governance rules for the same service, and the tenant's service governance rules can be sent to the tenant's traffic agent such as Envoy, thereby realizing logical multi-grouping of a single control plane, which can solve the deployment resource problem to a certain extent.

[0104] For example, as shown in Figure 2, assume that the VPC of tenant 0 is recorded as Tenant0-VPC, and the VPC of tenant 1 is recorded as Tenant1-VPC. Tenant0-VPC includes Envoy00 and managed cluster 00, and Tenant1-VPC includes Envoy10 and managed cluster 10. Among them, managed cluster 00 deploys services Server0, Server1, ..., ServerN, and performs traffic management through Envoy00; managed cluster 10 deploys services Server0, Server1, ..., ServerN, and performs traffic management through Envoy10; tenant 0 and tenant 1 publish Server0 by operating terminal device 120. For tenant 0, the Istio control plane obtains the information of Server0 of managed cluster 00, and based on xds, configures the service governance rule 00 of Server0 and sends it to Envoy00; for tenant 1, the Istio control plane obtains the information of Server0 of managed cluster 10, and based on xds, configures the service governance rule 01 of Server0 and sends it to Envoy10.

[0105] In some possible implementations, for example, using Istio as the control plane and Envoy as the traffic proxy, the control plane perceives the XDS information for a service and sends it only to the tenant's corresponding Envoy, thereby implementing service governance. The control plane can send XDS information only to the tenant's corresponding Envoy by: centrally managing the Envoy address, creating a unique Envoy for each tenant under their respective VPC 112 as needed, with different Envoy addresses for different tenants; and creating a unique Gateway for each tenant, which is associated with the tenant's Envoy. In this way, XDS information for the corresponding service is only sent to the tenant's Envoy associated with the tenant's Gateway.

[0106] In addition, in the embodiments of the present application, service governance rules can be understood as configurations for resources in Envoy. Among them, Envoy has many resources. Resources themselves are very abstract concepts. The so-called resources here refer to entities with certain specific functions or purposes created by Envoy based on relevant configurations; in addition, resources can also be understood as a custom resource object, which is created by the administrator through the interface provided by the control plane component of the service grid (such as the Istioctl tool provided by Istio or a graphical user interface provided by a third party), and is used to implement complex service governance such as dynamic routing, circuit breaking, current limiting, and call chain tracing.

[0107] In an embodiment of the present application, the management node 111 can uniformly manage the traffic between all services deployed in the cluster through the control plane component. Specifically, a custom resource definition (CRD) resource object is created on the management node 111 where the control plane is located to configure service governance rules for the control plane to govern the data plane (Envoy). The CRD resource object can define the service governance rules of the service grid, and the control plane of the service grid sends the service governance rules defined by the CRD resource object to the data plane (Envoy).

[0108] For example, Envoy has four core resources: Listener, Router, Cluster, and Filter. Corresponding service governance rules include XDS configuration parameters.

[0109] A Listener is a listening port opened by Envoy to receive connections from downstream (clients). Envoy supports multiple Listeners. Almost all configurations between multiple Listeners are isolated. The core of the Listener configuration includes the listening address and the Filter chain. The Filter chain can be understood as multiple filters with a sequence. After intercepting a request for the same listening address, the Filter chain processes the intercepted request according to the sequence of the filters in the Filter chain.

[0110] The configuration / resource discovery service for Listeners is called LDS. LDS is fundamental to Envoy's proper operation. Without LDS, Envoy cannot implement port listening, and all other xDS services are ineffective. The Listener Discovery Service (LDS) enables Envoy to discover all Listeners at runtime, including all filter stacks such as L3 and L4 filters, and thus perform various proxy tasks such as authentication, Transmission Control Protocol (TCP) proxying, and HTTP proxying.

[0111] Exemplarily, the service governance rules include configuration parameters of LDS. The configuration parameters of LSD may include:

[0112] 1. Listener name: Each listener has a unique name, which is used to identify and reference the listener; it corresponds to the listener name field in Gateway;

[0113] 2. Listener address and port: Specify the IP address and port where the listener receives incoming requests. This corresponds to the address and port fields in Gateway, which specify the address of Envoy.

[0114] 3. The filter chain performs various processing and conversions on incoming requests.

[0115] A Cluster is an abstraction of an upstream service. In Envoy, each upstream service is abstracted into a Cluster. The Cluster contains the service's connection pool, timeout, endpoint address, port, and type (the type determines the specific endpoint method Envoy can access for that Cluster).

[0116] The configuration / resource discovery service for clusters is called CDS. Envoy uses the CDS to discover upstream clusters during routing. Envoy typically adds, updates, and deletes clusters. When routing HTTP requests, it adds cluster information to the HTTP request header to enable request forwarding.

[0117] Exemplarily, the service governance rules include configuration parameters of CDS. The configuration parameters of CSD may include:

[0118] 1.Cluster name, unique identifier;

[0119] 2. Protocol type: Specify the protocol type used by the cluster, such as Http, TCP, etc.

[0120] 3. Policy: health check policy, connection policy, and load balancing policy for backend nodes (Endpoint).

[0121] 4. Endpoint: Specifies the address, port, and weight of each endpoint in the cluster; Envoy uses this information to load balance requests.

[0122] Another service closely related to CDS is called EDS. The configuration / resource discovery service for endpoints is called EDS. Envoy can dynamically obtain upstream endpoints through EDS.

[0123] Exemplarily, the service governance rules include EDS configuration parameters. The ESD configuration parameters may include:

[0124] 1. Cluster name (Cluster_name): Specify the name of the cluster to be configured and managed.

[0125] 2. Endpoints: defines the address, port, weight, and other information of the backend nodes in the cluster.

[0126] It's important to note that CDS focuses on configuring and managing the entire cluster, while EDS focuses on the specific addresses and health status of backend nodes within a given cluster. CDS and EDS work together, with CDS managing and configuring the cluster and EDS providing backend node information for Envoy routing and load balancing. Therefore, CDS doesn't contain specific EDS information, but CDS configuration typically references the cluster name in EDS to specify the backend nodes it manages.

[0127] The Router acts as a bridge between upstream and downstream, and can be understood as a collection of rules and resources that bridge Listeners and backend services. In Envoy, Listeners can receive connections from downstream clients, and Clusters can route traffic to specific upstream services. The Router determines which Cluster to direct the Listener to after receiving downstream connections and data. It defines the rules for data distribution. Currently, Envoy supports routing for multiple protocols, such as HTTP and TCP.

[0128] The configuration / resource discovery service for Routes is called RDS. The core configuration of Routers includes request matching rules and routing to clusters. It may also include retry, traffic diversion, and rate limiting. For example, the Route Discovery Service (RDS) allows Envoy to retrieve the complete route configuration for HTTP connection management filters at runtime, such as HTTP header modifications.

[0129] Exemplarily, the service governance rules include RDS configuration parameters. The RSD configuration parameters may include:

[0130] 1. Route name (name): A unique name used to identify and reference a route.

[0131] 2. Routing configuration: Rules for processing requests, which may include matching and routing to the Cluster. For example, it can correspond to match, backendrefs, and filter in Httproute. Among them, Matches is used to specify the conditions for request matching. Requests can be matched using a variety of conditions, such as the request method, target path, request header, etc. The Matches field allows the configuration of multiple matching rules. Filters are used to route requests. BackendRefs is used to specify the backend service to which the request should be routed. It specifies the name or other identifier of the backend service, and can configure the load balancing algorithm (used to indicate the load balancing strategy for the Endpoint), TLS settings, etc.

[0132] Filters, in layman's terms, are plug-ins. Through the Filter mechanism, Envoy provides extremely powerful scalability. Many core functions in Envoy are implemented using Filters. For example, the management of HTTP traffic and services relies on two plug-ins: the HttpConnectionManager (Network Filter, responsible for protocol parsing) and the Router (responsible for traffic distribution). Leveraging the Filter mechanism, Envoy can theoretically support any protocol and convert between them, enabling comprehensive modification and customization of request traffic.

[0133] The filter itself does not have a dedicated xDS service to discover configurations. All filter configurations are embedded in LDS, RDS, and CDS. For example, the net filters configured in LDS are Http connection managers that will traverse the configured Http filters and execute the logic in the filter one by one. Among them, Http filters correspond to the RDS filters configuration information. RDS filters are composed of two parts: the match conditions and the route side will specify which CDS is the corresponding one. Load balancing, current limiting, and circuit breaking all belong to the CDS level.

[0134] It should be noted that in the specific implementation, for the published services, the management node 111 will push the relevant configuration to Envoy when it finds that a new xds service has been created or the configuration parameters of the old service have been changed. After Envoy receives the relevant configuration and verifies that it is correct, it will dynamically update the runtime configuration, use the new configuration to update the configuration of related resources, and determine the new service governance rules. For example, taking the Pilot in Istio, the cluster is a k8s cluster as an example. When the Pilot finds that a new service or routing rule has been created (by monitoring specific CRD resource changes in the k8s cluster, or discovering Consul service registration and configuration changes), the Pilot will push the relevant configuration to Envoy through the Google Remote Procedure Call (gRPC) flow that has been established between it and Envoy. After Envoy receives the relevant configuration and verifies that it is correct, it will dynamically update the runtime configuration, use the new configuration to update the configuration of related resources, and obtain new service governance rules.

[0135] Next, in conjunction with the service system provided above, a service governance method provided by an embodiment of this application is described in detail. This application will use Envoy as an example of a traffic proxy to illustrate the solution of this application. The k8s cluster is only used as an example and does not constitute a specific limitation.

[0136] Figure 3 is a flow chart of a service management method provided by an embodiment of the present application. This embodiment can be applied to electronic devices, specifically servers or general computers.

[0137] As shown in FIG3 , the service governance method provided in the embodiment of the present application includes at least the following steps:

[0138] Step 301: The management node 111 manages a managed cluster of a target tenant, where the managed cluster includes a target service.

[0139] It should be noted that the management node 111 is configured with Istio control plane components, such as pilot, monitoring and other components.

[0140] In some possible implementations, the management node 111 manages the managed cluster based on the access address of the managed cluster.

[0141] Exemplarily, a tenant can access the configuration interface through a terminal device 120, which displays a cluster configuration interface. The cluster configuration interface includes the access address of the managed cluster that the user needs to configure. Exemplarily, the managed cluster has a unified access interface (which is the only entry point for resource operations provided by the cloud native platform to the outside world). The access address can be understood as the address of the unified access interface. Taking the k8s cluster as an example, the API-Server component serves as the unified access interface for resource operations. The first access address can include the address and token of the k8s cluster's API-server. Furthermore, in some possible cases, the access address can also include the managed cluster's network information (indicating the managed cluster's network). Exemplarily, taking the k8s cluster as an example, the network information can include the k8s cluster's PodCIDR (the subnet segment of the k8s cluster CIDR), NodeID, and CNI. The tenant configures the cluster in the cluster configuration interface, obtains the access address of the managed cluster, and sends it to the management node 301. The management node 301 manages the managed cluster. Management can be understood as the management node 301 having access to manage the managed cluster.

[0142] In some possible implementations, a cluster deploys multiple services, but typically only some of these services require service governance. These services are called target services, and tenants typically proactively publish them. In other cases, the target services can be all services deployed in the cluster.

[0143] For example, a tenant can access the configuration interface through terminal device 120, which displays a service publishing interface that includes services to be published and requires user configuration. In a specific implementation, after the management node 111 manages the managed cluster, the services deployed by the managed cluster can be viewed. Correspondingly, the user can view all services deployed by the managed cluster through the service publishing interface and then select a target service for publication. The tenant publishes the target service in the configuration interface and sends the obtained target service information to the management node 301.

[0144] Step 302: The management node 111 obtains service information corresponding to the target service from the managed cluster of the target tenant. The service information at least indicates information of a service instance of the target service deployed by the managed cluster.

[0145] The service information may include the identifier of the target service and information about the service instance of the target service. For example, a cluster includes nodes, nodes deploy Pods, Pods deploy services, and Pods associated with services are managed through Endpoints or EndpointSiles. Accordingly, the service instance information of the target service may indicate the Pod associated with the target service, the Endpoint or EndpointSiles associated with the target service, and may further include the network address of the Pod associated with the target service. For example, the network address of the Pod may include the IP address and port number of the Pod. Here, the identifier of the target service can be understood as the identifier used by the cluster to distinguish different services. Generally speaking, a service identifier can be a logical address or descriptive information, not the network address of a specific microservice or application, or the network address of the container group running the microservice or application. A service identifier can be used to describe or identify a service. Alternatively, a service identifier can be used to describe or indicate the service requested by the access request. In one example, the service identifier can include the service name and / or service version number. In one example, the service identifier can be pre-set information used to declare or indicate that the access request requires service governance.

[0146] In some possible implementations, step 306 may include the following: the management node 111 sends a synchronization instruction to the managed cluster of the target tenant; the managed cluster of the target tenant sends service information of the target service to the management node 111; and the management node 111 receives the service information of the target service.

[0147] It should be noted that the synchronization instruction is used to request the managed cluster to synchronize information related to the target service to the management node 111. The synchronization instruction may include the access address of the managed cluster of the target tenant and the identifier of the target service.

[0148] Step 303: The management node 111 sends an Envoy creation instruction to the target tenant's VPC 112.

[0149] In actual applications, once the managed cluster's access address is registered with management node 111, management node 111 can create an Envoy instance in the target tenant's VPC 112. For example, management node 111 includes a configuration center. After adding the managed cluster's access address to the configuration center, the managed cluster can synchronize some of its management information with the configuration center. When management node 111 detects from the configuration center that the target tenant's managed cluster needs to be managed, it sends an Envoy creation instruction to the target tenant's VPC 112.

[0150] Step 304 : The target tenant's VPC 112 creates Envoy based on the Envoy creation instruction; the Envoy communicates with the service instance of the target service of the managed cluster.

[0151] In a specific implementation, the management node 111 can deploy a cluster controller; for the target tenant, the cluster controller creates a virtual machine in the virtual private cloud (VPC112) in the target tenant, deploys Envoy in the virtual machine, and allocates an IP address to the virtual machine. It should be noted that if the IP addresses of multiple virtual machines of the target tenant are the same, SocketOptions are bound to the multiple virtual machines as a distinction to ensure that the multiple Envoys of the target tenant are different. In addition, Envoy can be deployed within or outside the managed cluster. This embodiment of the present application does not specifically limit this, and the specific design can be combined with actual needs.

[0152] Subsequently, the management node 111 can determine the network information of the target tenant's managed cluster based on the access address of the target tenant's managed cluster. For example, when the managed cluster is a k8s cluster, the network information may include podCIDR, NodeIP, and CNI. Then, the management node 111 will establish a channel between the Envoy of the target tenant's VPC112 and the service instance of the managed cluster (when the cluster is a k8s cluster, the service instance can be a pod) based on the network information of the managed cluster. For example, based on the CNI of the managed cluster, the cluster controller adds a route or a virtual extensible local area network (vxlan) to the Node in the managed cluster in the virtual machine where the Envoy in the target tenant's VPC112 is located, thereby opening up a data channel between the Envoy and the service instance (such as a Pod) in the managed cluster.

[0153] There are multiple ways for the management node 111 to determine the network information of the managed cluster of the target tenant based on the access address of the managed cluster of the target tenant.

[0154] Implementation method 1: The access address includes the network information of the managed cluster, and the management node 111 parses the access address to obtain the network information of the managed cluster.

[0155] Implementation Method 2: Management node 111 can access the managed cluster based on the managed cluster's access address and obtain the managed cluster's network information. For example, management node 111 includes a configuration center that stores various configuration information for the managed cluster. Based on the managed cluster's access address, management node 111 can access the managed cluster's configuration information from the configuration center and obtain the managed cluster's network information.

[0156] Step 305: The management node 111 creates a gateway, and the gateway is associated with the Envoy of the target tenant. The gateway includes traffic monitoring rules.

[0157] In the embodiment of the present application, the traffic monitoring rules are used to illustrate some rules for traffic monitoring, such as the listening address and the rules for request processing. The listening address is used to illustrate the address of envoy, which is generally an IP address and a port. The listening address is configured with a domain name. After the gateway receives the request, it needs to match the domain name. If it matches, the request is considered to be a request that envoy needs to process; the request processing rules are used to illustrate the method of processing the request, such as some initial processing such as protocol conversion. It should be noted that the traffic monitoring rules can be understood as the configuration of the listener (Listener) resources. In the specific implementation, the gateway is configured with a listener (Listener), and the listener is configured with a listening address and a Filter chain (used to process requests, which may not be present in some possible cases). It should be noted that the Envoy associated with the network trunk can be the default, such as all associations, or it can be tenant-configured.

[0158] In some possible implementations, the management node 111 may create a gateway according to the default gateway configuration without user configuration.

[0159] In some other possible implementations, the configuration of the gateway can be set by the user. For example, the tenant can access the configuration interface through the terminal device 120, and the terminal device 120 displays the gateway creation interface. The gateway creation interface includes the configuration parameters of the gateway that need to be configured by the user, such as the name of the gateway, namespace, listening address, listening port, listening protocol, host name or domain name to be listened, and other parameters. These parameters are only examples and do not constitute specific limitations. They can be flexibly designed in combination with actual needs. For example, you can also configure labels, applications or services that need to be forwarded (distinguished by labels), and further include security certificates, number of links, etc. After the user operates the gateway creation interface, an instruction to create a gateway for the target tenant can be sent to the management node 111. The instruction includes the parameter values ​​of the configuration parameters of the gateway; correspondingly, the management node 111 can create an instruction for the gateway of the target tenant and create a gateway.

[0160] It should be noted that the target tenant can have multiple managed clusters, and multiple managed clusters can be managed by multiple Envoys. In this case, the target tenant's gateway is associated with multiple Envoys.

[0161] Exemplarily, the management node 111 includes a gateway controller, which can create a Loadbalance service for the target tenant. The Loadbalance service can run through a pod, and the IP of the virtual machine where the target tenant's Envoy is located is filled in the pod IP of the Loadbalance service (a service that distributes requests to multiple Envoys). When there are multiple Envoys, all Envoy IPs need to be filled in; in this way, accessing the target tenant's Loadbalance service will access the target tenant's exclusive Envoy; then, a Gateway is created, and the Gateway is associated with the target tenant's Loadbalance service, thereby associated with the target tenant's Envoy. It should be noted that if the target tenant has multiple managed clusters, and multiple managed clusters are managed by multiple Envoys, then the Loadbalance service is associated with multiple Envoys, so that the gateway is associated with multiple Envoys.

[0162] Step 306: The management node 111 determines a traffic processing rule corresponding to the target service, and the traffic processing rule is associated with the target monitoring rule in the traffic monitoring rule.

[0163] Among them, the traffic processing rules can indicate the routing rules for matching, modifying, and forwarding traffic to the target service. For example, the traffic processing rules can be understood as the configuration for the routing Router. It should be noted that since the configuration for the routing Router includes the domain name associated with the target service (which can be the domain name in the gateway or the subdomain name under the domain name in the gateway), the domain name is located under the listener (Listener). Therefore, the traffic processing rules are associated with the listening rules of the listener (Listener) (referred to as target listening rules in the embodiment of this application). The target listening rules are the listening addresses and Filters in the listener (Listener) that match the domain name in the traffic processing rules.

[0164] In some possible implementations, without user configuration, the management node 111 may use a default traffic processing rule as the traffic processing rule for the target service.

[0165] In some other possible implementations, traffic processing rules can be set by the user. Exemplarily, the tenant can access the configuration interface through the terminal device 120, and the terminal device 120 displays the processing rule configuration interface, which includes the configuration for the routing Router. For example, the specific parameters that can be configured can be the domain name associated with the target service (which can be the domain name in the gateway or the subdomain name under the domain name in the gateway), the rules for request filtering, matching and / or modification, the routing rules for forwarding requests to the target service, the load balancing algorithm, etc. Exemplarily, the routing rule can be that 90% of the traffic accesses the v1 version of the target service, 10% of the traffic accesses the v2 version of the target service, or the traffic distribution of the master and backup nodes. Taking the cluster as a k8s cluster as an example, the load balancing algorithm indicates the strategy of balancing requests to the Endpoint or Endpointslnce; after the user operates the processing rule configuration interface, the traffic processing rules configured by the target tenant can be sent to the management node 111.

[0166] For example, the processing rule configuration interface is used to convert the Service resources of the Kubernetes cluster into Istio's VirtualService resources. Among them, VirtualService is a core configuration of Istio traffic governance. VirtualService defines a set of traffic rules for the target service, which formally represents a virtual service, and forwards all traffic that meets the conditions to the corresponding service backend, which can be a service. Through the configuration of VirtualService, when the application accesses the target service, it only needs to specify the address of the target service. In the actual request, the backend with which characteristics the traffic is routed to is based on the routing rules configured in the VirtualService. In addition, the processing rule configuration interface can also configure the Gateway to be associated, indicating that the traffic processing rules defined on this VirtualService will be executed for the traffic coming in from the Gateway.

[0167] Step 307 : The management node 111 sends service information, traffic monitoring rules, and traffic processing rules to the Envoy in the target tenant's VPC 112 .

[0168] In the specific implementation, there is a special communication protocol between the management node 111 and Envoy, such as xds. Therefore, when issuing service information, traffic monitoring rules, and traffic processing rules, these information need to be processed according to the communication protocol before being issued.

[0169] In specific implementation, the management node 111 generates LDS according to the traffic monitoring rules and xds protocol in the gateway; generates RDS according to the traffic processing rules of the target service; generates CDS and EDS according to the service information; among which CDS and EDS can be understood as service instance discovery rules.

[0170] It should be noted that the embodiments of this application do not intend to limit the order in which service information, traffic monitoring rules, and traffic processing rules are issued. Traffic monitoring rules can be issued after the gateway is created; service information can be issued after the service information is obtained; and traffic processing rules can be issued after the traffic processing rules are obtained. Of course, service information, traffic monitoring rules, and traffic processing rules can be sent together or separately, and this embodiment of the application does not specifically limit this.

[0171] It is worth noting that after the traffic monitoring rules are issued, there is no need to issue the traffic monitoring rules again if the traffic monitoring rules have not changed; the traffic processing rules and service information of different target services are different. Therefore, for different target services, the traffic processing rules and service information of the target service need to be issued.

[0172] In step 308, Envoy in VPC 112 performs service governance on the target service according to the service governance rules. The service governance rules indicate service information, target monitoring rules, and traffic processing rules.

[0173] In the embodiment of the present application, the service instance discovery rules, target monitoring rules, and traffic processing rules corresponding to the target service are collectively referred to as service governance rules.

[0174] In one possible scenario, Envoy is used to forward north-south traffic sent by the gateway to the service instance of the target service based on the service governance rules of the target service.

[0175] It should be noted that the gateway here can be understood as an ingress gateway. Ingress refers to the traffic management of ingress requests to services within the cluster. Ingress refers to traffic originating from outside the local network and directed to endpoints in the local cluster network. This traffic is first routed to public entry points to confirm which traffic is allowed to enter by executing some local network rules and policies. If the traffic does not pass through these entry points, it cannot connect to any service within the cluster. If the entry point allows the traffic to enter, it is proxied to the appropriate node in the local network. Therefore, the Ingress Gateway is used to manage traffic entering the edge of the mesh.

[0176] In the specific implementation, as shown in Figure 4a, when the management node 111 is performing service governance on the target service, Envoy can first go through Listners for the request sent by the gateway. Listners include multiple Listners, each Listner contains ListerFilters and FilterChain, so as to process the request through various Filters such as L3 / L4 / L7 Filter; then the request is routed to the specified Cluster according to the Router (route), and the target address of the Endpoint is determined through the Load Balancing service (Loadbalance, LB), and finally the request is sent to the Endpoint, and the Endpoint sends the request to the managed Pod.

[0177] For example, taking HTTP request processing as an example, Envoy includes an HTTP router filter that can be installed to perform advanced routing tasks. During HTTP request processing, the listener in Envoy first accepts the request and passes it to the HTTP router filter. After processing, the HTTP router filter passes the request to the application cluster discovered by CDS based on the routing rules determined by RDS. The endpoint in the application cluster actually processes the request and sends it to the Pod.

[0178] It should be noted that the Endpoint processing request is only an example and does not constitute a specific limitation. In some possible implementations, the EndpointSilce processing request may also be used.

[0179] In another possible scenario, Envoy is used to send the request generated by the target service to the gateway based on the service governance rules of the target service (service instance discovery rules, target listening rules, and traffic processing rules). The gateway sends the request to the outside of the service mesh, or to another managed cluster of the target tenant.

[0180] It should be noted that when a gateway sends requests to the outside of a service mesh, it can be understood as an egress gateway. Egress Gateway is a symmetric concept to ingress gateway. It defines the egress of a service mesh, allowing Istio features (such as monitoring and routing rules) to be applied to outbound traffic of the service mesh, allowing services within the service mesh to access the outside.

[0181] When a gateway sends a request to another managed cluster of the target tenant, the gateway can be understood as an east-west gateway.

[0182] In some cases, services in multiple clusters of a target tenant may call each other. In this embodiment, a gateway is used to enable communication between services in different clusters. For example, for clusters 01 and 02 of a target tenant, service A in cluster 01 and service B in cluster 02 cannot communicate directly and need to be exposed to each other through the east-west gateway.

[0183] For example, as shown in Figure 4b, Tenant0-VPC (Tenant 0's VPC) includes Envoy00, Envoy01, Managed Cluster 00, and Managed Cluster 01. Managed Cluster 00 deploys three services: Server0, Server1, and Server2, managed by Envoy00. Managed Cluster 01 deploys three services: Server3, Server4, and Server5, managed by Envoy01. Tenant 0 only publishes Server0, Server1, and Server2 deployed by Managed Cluster 00, and Server3 deployed by Managed Cluster 01. Envoy00 then manages the services for Server0, Server1, and Server2, while Envoy01 manages the services for Server3. There is no need to manage the services for Server4 and Server5. Gateway0 (Tenant 0's gateway) is deployed in Istio, along with the service governance rules for Server0, Server1, Server2, and Server3. Then, Envoy00 can obtain the service governance rules of Server0, Server1, and Server2, and Envoy01 can obtain the service governance rules of Server3.

[0184] Then, in the process of service governance, when a user outside the cluster calls Server0, Gateway0 forwards request 1 to Envoy00 after determining that request 1 can enter. After Envoy00 processes request 1 according to the service governance rules of Server0, it forwards request 1 to the service instance (Pod) where Server0 is located in the managed cluster 00.

[0185] When Server1 in managed cluster 00 accesses the cluster's external services, Server1 initiates request 2. Envoy00 processes request 2 according to Server1's service governance rules and forwards request 2 to Gateway0. After Gateway0 determines that it can exit the station, it forwards request 2 to the external service.

[0186] When Server2 in managed cluster 00 accesses Server3 in managed cluster 01, Server2 initiates request 3. After Envoy00 processes it according to Server2's service governance rules, it forwards request 3 to Gateway0. After Gateway0 determines that request 3 can enter, it forwards request 3 to Envoy01. After Envoy01 processes it according to Server3's service governance rules, it forwards request 3 to the service instance (Pod) where Server3 is located in managed cluster 01.

[0187] It should be noted that, in the embodiment of the present application, for different tenants, requests are transferred to the envoy in the tenant's VPC112 through the gateway of different tenants.

[0188] For example, as shown in Figure 4c, Tenant0-VPC (VPC of tenant 0) includes Envoy00 and managed cluster 00, and Tenant1-VPC (VPC of tenant 1) includes Envoy10 and managed cluster 10; among them, managed cluster 00 deploys services Server0, Server1,..., and performs traffic management through Envoy00; managed cluster 10 deploys services Server0, Server1,..., and performs traffic management through Envoy10.

[0189] Tenant 0 and Tenant 1 have released Server0. For Tenant 0, Istio's control plane deploys Gateway0, a gateway for Tenant 0, configures service governance rule 00 for Server0, and delivers it to Envoy00. For Tenant 1, Istio deploys Gateway1, a gateway for Tenant 1, configures service governance rule 01 for Server0, and delivers it to Envoy10. Subsequently, traffic related to Tenant 0 is managed through Gateway0, and traffic related to Tenant 1 is managed through Gateway1.

[0190] When a user outside the cluster calls Server0 of managed cluster 00, Gateway0 forwards request 1 to Envoy00 after confirming that request 1 can enter. After Envoy00 processes request 1 through Server0's service governance rule 00, it forwards request 1 to the service instance (Pod) where Server0 in managed cluster 00 is located.

[0191] When a user outside the cluster calls Server0 of managed cluster 10, Gateway1 forwards request 2 to Envoy10 after confirming that request 2 can enter. After Envoy10 processes request 2 through Server0's service governance rule 01, it forwards request 2 to the service instance (Pod) where Server0 is located in managed cluster 10.

[0192] In the embodiment of the present application, it should be noted that if the target tenant has multiple managed clusters, and the multiple managed clusters are managed by multiple Envoys, the target tenant's gateway is associated with multiple Envoys; if multiple managed clusters deploy the target service, then the service governance rules of the target service will be sent to the gateway to associate with multiple Envoys. In the specific implementation, the gateway can determine an Envoy from multiple Envoys through load balancing and forward the request to the Envoy. Alternatively, the gateway can forward the request to multiple Envoys. The embodiment of the present application does not impose specific restrictions on this. The specific rules for forwarding to Envoy can be determined in combination with actual needs.

[0193] For example, as shown in Figure 4d, the difference from Figure 4c is that Tenant0-VPC (Tenant 0's VPC) also includes Envoy01 and Managed Cluster 01. Managed Cluster 01 deploys services Server0, Server1, ..., and uses Envoy01 for traffic management. Managed Cluster 10 deploys services Server0, Server1, ..., and uses Envoy10 for traffic management. Because Server0 is deployed in Managed Cluster 00 and Managed Cluster 01, Service Governance Rule 00 for Server0 is distributed to Envoy00 and Envoy01.

[0194] When a user outside the cluster calls Server0 of managed cluster 00, Gateway0 can perform load balancing (for example, through the Loadbalance service associated with Gateway0) after confirming that request 1 can enter, and select Envoy00 or Envoy01 to forward the request. Assuming Envoy00 is selected, request 1 is forwarded to Envoy00. After processing through the service governance rule 00 of Server0, Envoy00 forwards request 1 to the service instance (Pod) where Server0 in managed cluster 00 is located.

[0195] In this solution, a single control plane isolates services at the tenant level. This way, the same services of different tenants are identified as different services. During service governance, the tenant's service governance rules are delivered to the tenant's traffic proxy, Envoy, thereby implementing logical multi-grouping on a single control plane, which can solve the deployment resource problem to a certain extent.

[0196] Based on the service governance method provided above, the specific application of the service governance method is described. Figure 4e is a flow chart of a specific application of a service governance method provided by the present application. As shown in Figure 4e, assuming that the VPC of Tenant 0 is recorded as Tenant0-VPC and the VPC of Tenant 1 is recorded as Tenant1-VPC, the specific contents include:

[0197] Tenant 0 displays the configuration interface through a computer. The configuration interface includes interfaces for managing clusters, creating gateways, publishing services, and configuring traffic processing rules. Then, Tenant 1 operates the configuration interface to determine the configuration information and stores it in Istio's configuration center. In this way, Istio's control plane components monitor the configuration center, thereby treating cluster 00 in Tenant0-VPC as managed cluster 00. It should be noted that after managing cluster 00, the configuration center can include service information of the target service for managed cluster 00. Istio's control plane components create Envoy00 in Tenant0-VPC, create a gateway for Tenant 0: Gateway0, and determine the service governance rule 00 for Tenant 0's target service based on the configuration parameters of LDS, RDS, CDS, and EDS and the service information of the target service for managed cluster 00, and send it to Envoy00.

[0198] Tenant 1 displays the configuration interface on a computer; then, Tenant 1 operates the configuration interface to determine the configuration information, which is stored in Istio's configuration center. After the cluster is managed, the configuration center can include the service information of the target service. In this way, Istio's control plane component monitors the configuration center, thereby treating cluster 10 in Tenant1-VPC as a managed cluster 10. After cluster 10 is managed, the configuration center can include the service information of the target service for the managed cluster 10. Istio's control plane component creates Envoy00 in Tenant1-VPC; creates Tenant 1's gateway: Gateway1, and determines Tenant 1's service governance rule 01 based on the configuration parameters of LDS, RDS, CDS, and EDS and the service information of the target service for the managed cluster 10, and sends it to Envoy10.

[0199] In the embodiment of the present application, the control plane will perform service isolation at the tenant level for the target service. In the embodiment of the present application, the target service has an isolation identifier, which can be understood as the management node 111 used to distinguish the same service of different tenants, so that the same service of different tenants is identified as different services.

[0200] In the embodiment of the present application, different tenants are isolated for the same service, and isolation is currently achieved mainly through two methods.

[0201] One possible approach is to isolate services through service labels. The isolation identifier is the service label. Specifically, when configuring a gateway, the target tenant can configure the target service label. Because different tenants have different gateways, services with the same label configured on different gateways will be considered different services by the control plane.

[0202] In one possible approach, service isolation can be achieved through namespaces, where the isolation identifier can be the name of the namespace. When isolating services through namespaces, the control plane must map the target service to a tenant-level namespace to achieve service isolation, so that the control plane considers the service to be a tenant-specific service. For example, the tenant-level namespace can be based on the tenant's identifier and the identifier of the namespace where the service resides, thereby achieving tenant-level service isolation. In this way, the control plane will consider the same service to be a different service if the service is located in different VPCs 112.

[0203] In the scenario where tenant-level namespaces are used for differentiation, generally, in the process of synchronizing the service information of the service to the management node, the service is mapped to the tenant-level namespace to achieve service isolation. In a specific implementation, the process of synchronizing the service information of the service to the management node can be: after the management node 111 manages the tenant's managed cluster, it installs a cluster synchronizer in the tenant's managed cluster. Exemplarily, the management node 111 can access the managed cluster based on the access address of the managed cluster and install the cluster synchronizer in the managed cluster; assuming that the namespace of the service in the managed cluster is the first namespace, the cluster synchronizer can control the management node 111 to create a new namespace corresponding to the first namespace (used to achieve tenant-level service isolation, for the sake of ease of description and distinction, it can be called the second namespace), map the service to the second namespace, such as synchronizing the information of the service in the first namespace to the second namespace. Exemplarily, as shown in Figure 5, based on the embodiment shown in Figure 3 above, in an embodiment of the present application, step 302 includes the following steps:

[0204] Step 3021: The management node 111 sends a synchronization instruction to the managed cluster of the target tenant.

[0205] Step 3022: The managed cluster of the target tenant creates a cluster synchronizer based on the synchronization instruction.

[0206] Step 3023 : The managed cluster of the target tenant sends the namespace creation instruction determined by the cluster synchronizer to the management node 111 .

[0207] Step 3024: The management node 111 creates a second namespace based on the namespace creation instruction; the target service is located in the first namespace of the managed cluster.

[0208] For example, the name of the second namespace can include the identifier of the target tenant and the identifier, such as the name, of the first namespace where the target service resides. Correspondingly, the namespace creation instruction includes the identifier of the first namespace. This way, different target tenants have different second namespaces, thereby achieving service isolation at the tenant level.

[0209] Step 3025: The managed cluster of the target tenant sends the service information determined by the cluster synchronizer to the management node 111, where the service information includes information that the target service is located in the first namespace.

[0210] Step 3026: The management node 111 receives the service information and maps the target service information in the first namespace to the second namespace.

[0211] It is worth noting that for the same service, the first namespace of the service for different tenants can be the same, but the second namespace is different, thereby achieving service isolation; since the second namespaces of services of different tenants are different, the management node 111 will consider them to be different services, and subsequently obtain service governance rules for different services.

[0212] It should be noted that the namespace provides a resource isolation mechanism. Resource names within the same namespace need to be unique, but resource names in different namespaces can be the same. In addition, for the management node 111, the namespace needs to be unique within a single cluster, but the same namespace can be created in different clusters. In a single-tenant multi-cluster scenario, by creating namespaces with the same name in different clusters and deploying service instances corresponding to the same service in multiple namespaces with the same name, different service instances corresponding to the same service can be deployed in different clusters. When a single cluster fails, the normal response of the service is not affected, thereby improving the availability of the service.

[0213] For example, the target tenant has M (greater than or equal to 2) managed clusters, and the M managed clusters have the same namespace N1. Information of service A is deployed in all namespaces N1, and the M managed clusters have published service A. Then, namespace n1 is created in the management node 111, and the information of service A in the M managed clusters will be mapped to namespace n1. In this way, the management node 111 can know the service instances of service A in the M managed clusters under the target tenant through namespace n1, so that the service governance rules of service A in the M managed clusters are the same.

[0214] In this scenario, multiple managed clusters for a tenant can be managed by multiple Envoys. The tenant's gateway is then associated with multiple Envoys. If the target service is deployed in multiple managed clusters, the target service's service governance rules are sent to the multiple Envoys associated with the gateway. During the service governance process, the gateway uses the load balancing service to determine an Envoy from among the multiple Envoys and forward the request to that Envoy.

[0215] The following is an example of service governance in this scenario.

[0216] As shown in Figure 6a, Tenant0-VPC (VPC of Tenant 0) includes Envoy00 and managed cluster 00, and VPC1 of Tenant1-VPC (VPC of Tenant 1) includes Envoy10 and managed cluster 10. Among them, managed cluster 00 deploys services Server0, Server1, ..., services Server0, Server1, ... are located in namespace1, and traffic management is performed by Envoy00. Managed cluster 10 deploys services Server0, Server1, ..., services Server0, Server1, ... are located in namespace1, and traffic management is performed by Envoy10.

[0217] Tenant 0 and Tenant 1 published Server0.

[0218] For tenant 0, Istio's control plane creates cluster synchronizer 00 in managed cluster 00. Cluster synchronizer 00 controls Istio's control plane to create a namespace for tenant 0's namespace1: Tenant0-namespace1, and maps the information of Server0 in managed cluster 00 to Tenant0-namespace1. Istio's control plane deploys tenant 0's gateway: Gateway0, configures Server0's service governance rule 00, and sends it to Envoy00.

[0219] For tenant 1, Istio's control plane creates cluster synchronizer 10 in managed cluster 10. Cluster synchronizer 10 controls Istio's control plane to create a namespace for tenant 1's namespace1: Tenant1-namespace1, and maps the information of Server0 in managed cluster 10 to Tenant1-namespace1. Istio's control plane deploys Gateway1, a gateway for tenant 1, configures service governance rule 01 for Server0, and sends it to Envoy 10.

[0220] Subsequently, the traffic related to tenant 0 is managed through Gateway0, and the traffic related to tenant 1 is managed through Gateway1.

[0221] When a user outside the cluster calls Server0 of the managed cluster 00, Gateway0 processes request 1 after confirming that it can enter and then forwards it to Envoy00. After processing it through the service governance rule 00 of Server0, Envoy00 forwards request 1 to the service instance (Pod) where Server0 in the managed cluster 00 is located.

[0222] When a user outside the cluster calls Server0 of managed cluster 10, Gateway1 determines that request 2 can enter, processes request 2, and then forwards request 2 to Envoy10. After processing through Server0's service governance rule 01, Envoy10 forwards request 2 to the service instance (Pod) where Server0 is located in managed cluster 10.

[0223] It should be noted that, in the related art, if the namespaces in the managed clusters of different tenants are the same and the same services are deployed in the namespaces, the control plane of Istio will consider these to be the same services and will adopt the same service governance rules, and tenant-level service governance cannot be achieved; however, in the embodiment of the present application, for the same services deployed in the managed clusters of different tenants, different namespaces can be created for different tenants in the control plane of Istio, and the services deployed in the tenant's managed cluster can be mapped to the tenant's namespace, thereby achieving service isolation at the tenant level.

[0224] In this scenario, for different tenants' managed clusters, each managed cluster uses one Envoy proxy. If different tenants' managed clusters deploy target services, then for each tenant, the tenant's service governance rules for the target service will be sent to the Envoy in the tenant's VPC112. During the service governance process, the gateway can forward related requests to the Envoy.

[0225] For example, as shown in FIG6b , the differences relative to FIG6a are as follows:

[0226] Tenant0-VPC (VPC of tenant 0) also includes Envoy01 and managed cluster 01. Managed cluster 01 deploys services Server0, Server1, ..., which are located in namespace1 and use Envoy01 for traffic management.

[0227] For tenant 0, Istio's control plane creates cluster synchronizer 01 in managed cluster 01. Cluster synchronizer 00 controls Istio's control plane to create a namespace for tenant 0's namespace1: Tenant0-namespace1, and maps the information of Server0 in managed cluster 00 to Tenant0-namespace1. Cluster synchronizer 01 maps the information of Server0 in managed cluster 01 to Tenant0-namespace1. Istio's control plane sends Server0's service governance rule 00 to Envoy00 and Envoy01.

[0228] Subsequently, the traffic related to tenant 0 will be managed through Gateway 0.

[0229] When a user outside the cluster calls Server0 of managed cluster 00, Gateway0 determines that request 1 can enter, processes request 1, and performs load balancing (through the Loadbalance service associated with Gateway0). It selects Envoy00 or Envoy01 to forward the request. Assuming Envoy00 is selected, request 1 is forwarded to Envoy00. After processing through the service governance rule 00 of Server0, Envoy00 forwards request 1 to the service instance (Pod) where Server0 in managed cluster 00 is located.

[0230] Based on the service governance method provided above, the specific application of the service governance method is described. Figure 7 is a flowchart of a specific application of a service governance method provided by this application. As shown in Figure 7, it is assumed that the VPC of Tenant 0 is recorded as Tenant0-VPC and the VPC of Tenant 1 is recorded as Tenant1-VPC; the specific contents include:

[0231] Tenant 0 operates through terminal device 120, publishes Server0 (located in namespace1), manages cluster 00, and creates gateway and routing rules. Correspondingly, Istio's control plane manages cluster 00 in Tenant0-VPC for Tenant 0, uses cluster 00 in Tenant0-VPC as managed cluster 00, creates Envoy00 in Tenant0-VPC (to communicate with service instances in managed cluster 00), and creates cluster synchronizer 00 in managed cluster 00. Cluster synchronizer 00 controls Istio's control plane to create a namespace for Tenant 0's namespace1: Tenant0-namespace1, and maps the information of Server0 in namespace1 of managed cluster 00 to Tenant0-namespace1. In nt0-namespace1, Istio's control plane creates a gateway for tenant 0: Gateway0 and a load balancing service: Loadbalance0. Gateway0 and Loadbalance0 are associated, and routing rule route0 for Server0 (associated with Gateway0) is configured. For example, it can be Httproute. Based on the information of Server0 in Gateway0, route0, and Tenant0-namespace1, there may also be additional Server0 information (not shown in the figure, such as the Endpoint and Pod associated with Server0). The service governance rule 00 for Server0 is determined and sent to Envoy00 in Tenant0-VPC.

[0232] Tenant 1 operates through terminal device 120, publishes Server0 (located in namespace1), manages cluster 10, and creates gateway and routing rules. Correspondingly, Istio's control plane manages cluster 10 in Tenant1-VPC for Tenant 1, uses cluster 10 in Tenant1-VPC as managed cluster 10, creates Envoy 10 in Tenant1-VPC (to communicate with service instances in managed cluster 10), and creates cluster synchronizer 10 in managed cluster 10. Cluster synchronizer 10 controls Istio's control plane to create a namespace for Tenant 1's namespace1: Tenant1-namespace1, and maps the information of Server0 in namespace1 of managed cluster 10 to Tenant. In t1-namespace1, Istio's control plane creates a gateway for tenant 1: Gateway1 and a load balancing service: Loadbalance1. Gateway1 and Loadbalance1 are associated, and the routing rule route1 for Server0 (associated with Gateway1) is configured. For example, it can be Httproute. Based on the information of Server0 in Gateway1, route1, and Tenant1-namespace1, there may also be additional Server0 information (not shown in the figure, such as the Endpoint and Pod associated with Server0). The service governance rule 01 for Server0 is determined and sent to Envoy10 in Tenant1-VPC.

[0233] This application also provides a service management device, as shown in Figure 8, including:

[0234] A service information determination module, configured to determine service information corresponding to the target tenant, wherein the service information indicates information about a service instance of the target service in the managed cluster;

[0235] A gateway creation module, configured to create a gateway corresponding to the target tenant; the gateway includes traffic monitoring rules;

[0236] A rule determination module, configured to determine a traffic processing rule corresponding to the target service; the traffic processing rule is associated with a target monitoring rule in the traffic monitoring rule;

[0237] The sending module is used to send the service information, target monitoring rules, and traffic processing rules to the traffic agent in the virtual private cloud of the target tenant; the traffic agent is used to perform service governance on the target service according to the service governance rules; the service governance rules indicate the service information, traffic monitoring rules, and target monitoring rules.

[0238] The service information determination module, gateway creation module, rule determination module, and delivery module can all be implemented via software or hardware. For example, the implementation of the service information determination module will be described below using the service information determination module as an example. Similarly, the implementation of the gateway creation module, rule determination module, and delivery module can refer to the implementation of the service information determination module.

[0239] As an example of a software functional unit, a module for determining service information may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the module for determining service information may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0240] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0241] As an example of a hardware functional unit, the service information determination module may include at least one computing device, such as a server. Alternatively, the service information determination module may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0242] The multiple computing devices included in the service information determination module can be distributed in the same region or in different regions. The multiple computing devices included in the service information determination module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the service information determination module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0243] It should be noted that, in other embodiments, the service information determination module can be used to execute any step in the service governance method, the gateway creation module can be used to execute any step in the service governance method, the rule determination module can be used to execute any step in the service governance method, and the issuance module can be used to execute any step in the service governance method. The steps that the service information determination module, gateway creation module, rule determination module and issuance module are responsible for implementing can be specified as needed. The full functions of the service governance device are realized by respectively implementing different steps in the service governance method through the service information determination module, gateway creation module, rule determination module and issuance module.

[0244] This application also provides a computing device 110. As shown in Figure 9, computing device 110 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. Processor 104, memory 106, and communication interface 108 communicate with each other via bus 102. Computing device 110 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 110.

[0245] Bus 102 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG9 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 102 may include a path for transmitting information between various components of computing device 110 (e.g., memory 106, processor 104, and communication interface 108).

[0246] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0247] The memory 106 may include volatile memory, such as random access memory (RAM). The processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0248] Memory 106 stores executable program code, which processor 104 executes to implement the aforementioned functions of the service information determination module, gateway creation module, rule determination module, and delivery module, thereby implementing the service governance method. Specifically, memory 106 stores instructions for executing the service governance method.

[0249] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 110 and other devices or a communication network.

[0250] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0251] As shown in Figure 10, the computing device cluster includes at least one computing device 110. The memory 106 of one or more computing devices 110 in the computing device cluster may store the same instructions for executing the service governance method.

[0252] In some possible implementations, the memory 106 of one or more computing devices 110 in the computing device cluster may also store partial instructions for executing the service governance method. In other words, the combination of one or more computing devices 110 can jointly execute the instructions for executing the service governance method.

[0253] It should be noted that the memory 106 in different computing devices 110 in the computing device cluster can store different instructions, each for executing a portion of the functions of the service management apparatus. In other words, the instructions stored in the memory 106 in different computing devices 110 can implement the functions of one or more of the service information determination module, gateway creation module, rule determination module, and delivery module.

[0254] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG11 shows a possible implementation. As shown in FIG11 , two computing devices 110A and 110B are connected via a network. Specifically, the connection to the network is made via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 110A stores instructions for executing the functions of the service information determination module. At the same time, the memory 106 in the computing device 110B stores instructions for executing the functions of the gateway creation module, the rule determination module, and the delivery module.

[0255] The connection method between the computing device clusters shown in Figure 11 can be based on the fact that the service governance method provided in this application needs to consider the storage of user-configured information. Therefore, the service information determination module, gateway creation module, and rule determination module are considered to be executed by the computing device 100A, and the functions implemented by the sending module are handed over to the computing device 100B for execution. It should be understood that the functions of the computing device 100A shown in Figure 11 can also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B can also be completed by multiple computing devices 100. In addition, in order to save deployment resources, the service information determination module, gateway creation module, rule determination module, and sending module can be deployed in one computing device 100.

[0256] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be executed on a computing device or stored in any available medium. When the computer program product is executed on at least one computing device, the at least one computing device executes the service governance method.

[0257] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the service governance method.

[0258] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0259] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0260] The basic principles of the present application have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this application are merely illustrative and not restrictive, and it should not be assumed that these advantages, strengths, and effects are required of each embodiment of the present disclosure. In addition, the specific details disclosed above are merely illustrative and for ease of understanding, and are not restrictive. The above details do not limit the present disclosure to necessarily being implemented using the above specific details.

[0261] The block diagrams of the devices, devices, equipment, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and can be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and can be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and can be used interchangeably therewith.

[0262] It should also be noted that in the apparatus, device, and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0263] The above description has been provided for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

[0264] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A service governance method, characterized in that: Applied to a management node, the management node manages virtual private clouds of multiple tenants, the virtual private cloud has a cluster deployed therein, and the cluster has a service deployed therein; The management node manages a managed cluster of a target tenant among the multiple tenants, and the managed cluster deploys a target service. The method includes: Determine service information corresponding to the target tenant, where the service information indicates information of a service instance of the target service in the managed cluster; Creating a gateway corresponding to the target tenant; the gateway includes traffic monitoring rules; Determine a traffic processing rule corresponding to the target service; the traffic processing rule is associated with a target monitoring rule in the traffic monitoring rule; The service information, target monitoring rules, and traffic processing rules are sent to a traffic agent in the virtual private cloud of the target tenant; the traffic agent is used to perform service management on the target service according to the service information, traffic monitoring rules, and target monitoring rules.

2. The method according to claim 1, characterized in that The target service is located in a first namespace in the managed cluster; The target service is located in the second namespace in the management node; when the managed clusters of different target tenants include the target service located in the first namespace, the second namespaces where the target services of different target tenants in the management node are located are different.

3. The method according to claim 2, characterized in that The method further comprises: A second namespace is created, and the target service is mapped to the second namespace.

4. The method according to claim 3, characterized in that: The step of creating a second namespace includes: installing a cluster synchronizer in a managed cluster of the target tenant; In response to the control of the cluster synchronizer, a second namespace is created.

5. The method according to claim 2, characterized in that: The traffic proxy is used to manage multiple managed clusters of the target tenant; Under the condition that each of the multiple managed clusters includes the target service located in the first namespace, the traffic agent is used to perform service management on the target services in the multiple managed clusters according to the service information, traffic monitoring rules, and target monitoring rules.

6. The method according to any one of claims 1 to 5, characterized in that: The traffic monitoring rules include configuration for monitor resources; and / or, The traffic processing rules include configuration for routing resources.

7. The method according to any one of claims 1 to 6, characterized in that: The traffic proxy is used to perform service management on the target service according to the service information, the traffic monitoring rule, and the target monitoring rule, including: According to the service information, traffic monitoring rules, and target monitoring rules, the request entering the gateway is forwarded to the target service, and / or the request issued by the target service is forwarded through the gateway to the outside or another managed cluster of the target tenant.

8. The method according to any one of claims 1 to 7, characterized in that: The target service is a portion of services that require service governance among multiple services deployed in the managed cluster.

9. A service management device, characterized in that: Applied to a management node, the management node manages virtual private clouds of multiple tenants, a cluster is deployed in the virtual private cloud, and a service is deployed in the cluster; The management node manages a managed cluster of a target tenant among the multiple tenants, and the managed cluster deploys a target service. The device includes: A service information determination module, configured to determine service information corresponding to the target tenant, wherein the service information indicates information of a service instance of the target service in the managed cluster; A gateway creation module, used to create a gateway corresponding to the target tenant; the gateway includes traffic monitoring rules; A rule determination module, used to determine the traffic processing rule corresponding to the target service; the traffic processing rule is associated with the target monitoring rule in the traffic monitoring rule; The sending module is used to send the service information, target monitoring rules, and traffic processing rules to the traffic agent in the virtual private cloud of the target tenant; the traffic agent is used to perform service management on the target service according to the service information, traffic monitoring rules, and target monitoring rules.

10. The device according to claim 9, characterized in that The target service is located in a first namespace in the managed cluster; The target service is located in the second namespace in the management node; when the managed clusters of different target tenants include the target service located in the first namespace, the second namespaces where the target services of different target tenants in the management node are located are different.

11. The device according to claim 10, characterized in that The device also includes: A mapping module is used to create a second namespace and map the target service to the second namespace.

12. The device according to claim 11, characterized in that The mapping module is used to install a cluster synchronizer in the managed cluster of the target tenant; and create a second namespace in response to control of the cluster synchronizer.

13. The device according to claim 10, characterized in that The traffic proxy is used to manage multiple managed clusters of the target tenant; Under the condition that each of the multiple managed clusters includes the target service located in the first namespace, the traffic agent is used to perform service management on the target services in the multiple managed clusters according to the service information, traffic monitoring rules, and target monitoring rules.

14. The device according to any one of claims 9 to 13, characterized in that: The traffic monitoring rules include configuration for monitor resources; and / or, The traffic processing rules include configuration for routing resources.

15. The device according to any one of claims 9 to 14, characterized in that: The traffic proxy is used to forward the request entering the gateway to the target service according to the service information, traffic monitoring rules, and target monitoring rules, and / or forward the request issued by the target service to the outside or another managed cluster of the target tenant through the gateway.

16. The device according to any one of claims 9 to 15, characterized in that The target service is a portion of services that require service governance among multiple services deployed in the managed cluster.

17. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 8.

18. [Corrected 06.02.2024 in accordance with Rule 26] A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 8.

19. [Corrected 06.02.2024 in accordance with Rule 26] A computer-readable storage medium, characterized in that The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.

20. [Corrected 06.02.2024 in accordance with Rule 26] [Deleted]

Images