Service management method and device and computer readable storage medium

Abstract

The invention provides a service governance method and device and a computer readable storage medium. The method is applied to a management node for managing a virtual private cloud of a plurality of tenants, a cluster is deployed in the virtual private cloud, and services are deployed in the cluster; a management cluster manages a managed cluster (deployed with a target service) of a target tenant, and the method comprises the following steps: determining service information corresponding to the target tenant, the service information indicating information of a service instance of the target service in the managed cluster; creating a gateway corresponding to the target tenant; the gateway comprises a flow monitoring rule; determining a traffic processing rule corresponding to the target service; the traffic processing rule is associated with a target monitoring rule in the traffic monitoring rules; 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, so that the traffic agent carries out service management on the target service. And the service governance rule of the tenant is sent to the agent in the virtual private cloud of the tenant, so that data isolation is realized and data security is improved.

Description

Technical Field

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

[0002] Kubernetes (k8s for short) is the de facto standard in the field of container orchestration, solving the orchestration and management problems of container clusters. However, k8s does not provide an automated solution for inter-cluster access or north-south traffic outside the cluster to access services within k8s. It can only be configured manually, which is complex and prone to errors. The open source service mesh project istio, as a microservice governance platform, supports k8s very well and can be used as a gateway for access outside k8s to support inter-cluster access.

[0003] The cloud native gateway solution based on istio includes a single control plane and multiple data planes. However, for multi-tenant scenarios, in the single control plane and multiple data plane solution, istio will consider the same services in different k8s clusters as the same services, and will not perform data isolation even if these k8s clusters belong to different tenants, resulting in low data security.

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

[0005] 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.

[0006] 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, and the method includes:

[0007] 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; 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 based on the service information, traffic monitoring rules, and target monitoring rules.

[0008] In this solution, 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.

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

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

[0011] 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 that is located in the first namespace is mapped to the second namespace.

[0012] 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.

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

[0014] In one possible implementation, 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 a target service located in the first namespace, the traffic proxy is used to perform service governance on the target services in the multiple managed clusters according to service information, traffic monitoring rules, and target monitoring rules.

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

[0016] In a 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.

[0017] 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.

[0018] In the second aspect, an embodiment of the present invention provides a service governance device, which includes several modules, each of which is used to execute each step in the service governance method provided in the first aspect of the embodiment of the present invention, and the division of modules is not limited here. For the specific functions performed by each module of the service governance device and the beneficial effects achieved, please refer to the functions of each step of the service governance method provided in the first aspect of the embodiment of the present invention, which will not be repeated here.

[0019] For example, the service governance device is 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, and the device includes:

[0020] A service information determination module, 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;

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

[0022] A rule determination module is 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;

[0023] The sending module is used to send 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 manage the target service based on the service information, traffic monitoring rules, and target monitoring rules.

[0024] In a 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 second namespaces where the target services of different target tenants in the management node are located are different

[0025] In a possible implementation, the device further includes:

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

[0027] In a possible implementation manner, the isolation 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.

[0028] In one possible implementation, 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 a target service located in the first namespace, the traffic proxy is used to perform service governance on the target services in the multiple managed clusters according to service information, traffic monitoring rules, and target monitoring rules.

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

[0030] In a 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.

[0031] 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.

[0032] 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, when the program stored in the memory is executed, the processor is used to execute the method provided in the first aspect.

[0033] 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.

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

[0035] 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.

[0036] 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

[0037] Figure 1a It is a schematic diagram of a scenario of a single control plane and multiple data planes provided in the related art;

[0038] Figure 1b It is a schematic diagram of a scenario of multiple control planes and multiple data planes provided in the related art;

[0039] Figure 2 It is a schematic diagram of the architecture of a service system provided by an embodiment of the present application;

[0040] Figure 3 It is a flow chart of a service management method provided by an embodiment of the present application;

[0041] Figure 4a It is a schematic diagram of the working principle of Envoy provided in an embodiment of the present application;

[0042] Figure 4b yes Figure 3 Schematic diagram of the request processing scenario for a single tenant under the provided method;

[0043] Figure 4c yes Figure 3 Schematic diagram 1 of the request processing scenarios of different tenants under the provided method;

[0044] Figure 4d yes Figure 3 Illustration of request processing scenarios for different tenants under the provided methods Figure 2 ;

[0045] Figure 4e yes Figure 3 Schematic diagram of the scenario under the provided method;

[0046] Figure 5 yes Figure 3 Schematic diagram of the process of step 302;

[0047] Figure 6a yes Figure 5 Schematic diagram of request processing scenarios for different tenants under the provided method;

[0048] Figure 6b yes Figure 5 Schematic diagram of request processing scenarios for different tenants under the provided method;

[0049] Figure 7 This is a scenario example diagram of a service governance method provided in an embodiment of the present application;

[0050] Figure 8 This is a structural example diagram of a service management device provided in an embodiment of the present application;

[0051] Fig. 9 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0052] Fig.10 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0053] Fig.11 yes Fig.10 A schematic diagram of a cluster of computing devices is provided. DETAILED DESCRIPTION

[0054] 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 in conjunction with the accompanying drawings.

[0055] 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 interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a concrete way.

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

[0057] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0058] Hereinafter, some terms used in this embodiment are explained. It should be noted that these explanations are for the convenience of understanding by those skilled in the art and do not constitute a limitation on the scope of protection claimed by the present invention.

[0059] 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.

[0060] Microservice: refers to a small service composed of a single application. Each microservice has its own process, which can communicate with other microservices through lightweight communication mechanisms, such as application programming interface (API) based on hypertext transfer protocol (HTTP).

[0061] Microservice architecture: A service-oriented architecture (SOA) that divides a complex system into multiple small services or applications. These small services or applications can be called microservices. Each microservice is responsible for implementing an independent business logic. Microservices are built around business functions and can be deployed independently. Microservices can provide a range of functions by relying on each other. Microservices are easy to understand and modify, and bring flexibility in language and framework selection.

[0062] Service governance: It is the process of handling the relationship between service calls in a distributed service framework. Service governance can be divided into the following levels: service registration and discovery, load balancing, fault handling and recovery (current limiting, circuit breaking, timeout, retry), grayscale release, and service tracking. In the microservice architecture, service governance is also called SOA governance (service oriented architecture governance, SOA governance), which is the process used to manage the adoption and implementation of the microservice architecture.

[0063] Virtual Private Cloud (VPC): is a set of logically isolated virtual network environments built for instances, which are configured and managed by users themselves. It aims to improve the security of user resources and simplify user network deployment. Users can freely select IP address ranges, create multiple subnets, customize security groups, and configure routing tables and gateways in VPC, which facilitates network management and configuration, and makes safe and fast network changes.

[0064] Traffic: The amount of data transmitted in a network. In simple terms, it is the amount of data transmitted in a network. The size of network traffic can be measured by the number of packets or the size of the data.

[0065] North-south traffic: traffic from the public network into the VPC and traffic from the VPC out to the public network. It mainly refers to traffic that crosses the VPC boundary, including: external clients accessing services within the VPC, and services within the VPC accessing external services or applications.

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

[0067] Token: In computer authentication, it means a token (temporary), and in lexical analysis, it means a tag. It is generally used for invitations and login systems.

[0068] Kubernetes (k8s) cluster: 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 node (Node) is similar and will not be repeated. For example, Figure 2 As shown, the k8s cluster includes one or more Master-Node C11 and N nodes: W11, ..., W1N.

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

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

[0071] Container: A virtualization technology in computer operating systems. This technology allows processes to run in a relatively independent and isolated environment (including independent file systems, namespaces, resource views, etc.), thereby simplifying the software deployment process, enhancing software portability and security, and improving system resource utilization. Container technology is widely used in service-oriented scenarios in the field of cloud computing.

[0072] Container Group (Pod): is the smallest deployable computing unit that can be created and managed in Kubernetes. Pod contains a group of (one or more) containers; these containers share storage, network, and declarations on how to run these containers. The contents of a Pod always coexist and are scheduled together, running in a shared context. Pod models an application-specific "logical host" that contains one or more application containers that are relatively tightly coupled together.

[0073] Endpoint: It is a resource object in the k8s cluster, which is used to record the access addresses of all pods corresponding to a service. It can be understood as a specific "application instance".

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

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

[0076] Istio: is an open platform for service governance in the form of Service Mesh. The "ServiceMesh form" can be understood as Istio implementing Service Mesh; "Service" can be simply understood as microservices or single applications, which are the objects of Istio governance, and "governance" is exactly the function provided by Istio, including service traffic management, security and observability. 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, which can 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, discover and solve problems.

[0077] 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. Among them, the Envoy proxy is a high-performance proxy developed in C++ that is used to mediate inbound and outbound traffic for all services in the service mesh.

[0078] Cluster: 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 KubernetesService 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 sake of ease of description and distinction, Cluster can be referred to as an application cluster.

[0079] 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.

[0080] Route: It is used to decide which Cluster to send the data to for processing.

[0081] Filter: Add more integration features without changing the core functionality of Envoy. Currently, Envoy already includes multiple listener filters.

[0082] Httproute: indicates the HTTP routing rules, such as the requested domain name, which rules the Path meets, and which Cluster it is forwarded to.

[0083] XDS (X Discovery Service): The communication protocol between the control plane and the data plane of Istio. Specifically, in the Istio architecture, the XDS protocol provides a standard control plane specification and uses it to pass information to the data plane. X indicates that it does not refer to a specific protocol, but is a general term for a group of service discovery protocols based on different data sources. It can also be understood that XDS is a general term for a series of services, mainly including Listener Discovery Service LDS (Listener DS), Router Discovery Service RDS (Router DS), Cluster Discovery Service CDS (Cluster DS), Endpoint Discovery Service EDS (Endpoint DS), etc. The API of the XDS communication protocol was proposed by Envoy to implement its dynamic configuration to cope with the ever-changing infrastructure. In Envoy, XDS is called the data plane API and serves as the communication protocol between the control plane and the data plane. At the same time, these APIs can also be used by other proxies in specific scenarios. Through these APIs, Envoy can dynamically obtain the configuration of resources such as Cluster (application cluster), Endpoint (cluster member), Listener (listener) and Route (route) from the control plane.

[0084] Gateway: It encapsulates multiple microservices within the business system and provides a unified access portal. All requests entering and exiting a cluster, such as a k8s cluster, must pass through the gateway to achieve unified management and monitoring of cross-cluster requests. The gateway also provides service security authentication, request authentication, and supports multiple communication protocols and message formats.

[0085] Namespace: It is a form of code organization used by many programming languages. Namespaces are used to classify and distinguish different code functions to avoid 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.

[0086] Classless Inter-Domain Routing (CIDR) is a method of creating additional addresses on the Internet. These addresses are provided to service providers (ISPs) and then allocated to customers by ISPs. CIDR centralizes routing so that one IP address represents thousands of IP addresses served by major backbone providers, thereby reducing the burden on Internet routers. Without CIDR, routers would not be able to support the increase in Internet websites. CIDR uses 13 to 27-bit variable network IDs instead of the fixed 7, 14, and 21 bits used by ABC network IDs.

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

[0088] In one possible scenario, a single control plane with multiple data planes can be deployed. Take the k8s cluster as an example. Figure 1a As shown in the figure, a k8s cluster (also called k8s-cluster) deploys an Envoy, and all k8s clusters share an Istio control plane. As the only entry point for issuing flow control rules, the single control plane will check the services (Sevice) of all k8s clusters. The Envoy of the data plane of all k8s clusters will connect to the control plane to obtain the information generated by xds.

[0089] In Istio's single control plane and multiple data planes 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, Figure 1a As shown in the figure, 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 that the service Service1 of tenant 1 and tenant 2 is the same service.

[0090] In another possible situation, multiple control planes and multiple data planes can be deployed. Take the k8s cluster as an example. Figure 1bAs shown in the figure, one Envoy is deployed in one k8s cluster, and all k8s clusters have an independent Istio control plane, each of which is deployed on a different node; services in different k8s clusters belonging to different tenants can be isolated; however, Istio will not actively open up service access between k8s clusters, and users need to actively register service entries for inter-k8s cluster access. For example, Figure 1b As shown in the figure, assuming that Istio's control plane 1 manages tenant 1's k8s-cluster1, 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 tenant 2's k8s-cluster3, k8s-cluster2 includes namespace namespace1, namespace1 includes service Service1, at this time, Istio will consider tenant 1's and tenant 2's service Service1 to be different services.

[0091] In Istio's multi-control plane and multi-data plane solution, although services in different k8s clusters can be isolated, an Istio control plane needs to be assigned to each k8s cluster, which consumes a lot of resources. When a tenant has multiple k8s clusters, the same Service under the same namespace in multiple k8s clusters under the tenant will also be considered as different services, and service governance cannot be performed according to tenant granularity.

[0092] In order to facilitate understanding of the technical solution provided in the embodiment of the present application, the service system to which the service governance method provided in the embodiment of the present invention may be applied is first introduced. Figure 2 The embodiment of the present invention provides a service governance method which can be applied to Figure 2 As shown in the system architecture diagram. Figure 2 As shown, the service system includes multiple computing devices 110 and terminal devices 120 .

[0093] Among them, the terminal device 120 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. Exemplary embodiments of the terminal devices involved in this solution include, but are not limited to, electronic devices equipped with iOS, Android, Windows, Harmony OS, or other operating systems. The embodiments of the present invention do not specifically limit the type of electronic devices.

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

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

[0096] A service management system is deployed on multiple computing devices 110, and the service management system includes a management node 111 and N tenants' virtual private clouds (VPCs) 112. For example, Figure 2 Two tenants' VPCs are shown, which are labeled Tenant1-VPC and Tenant2-VPC for ease of description and distinction.

[0097] 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 embedded in a virtualized environment. For example, the server involved in this solution can be a virtual machine executed on a hardware server including one or more other virtual machines. The node (Node) is similar and will not be repeated. For example, Figure 2 As shown, the cluster includes 1 management node (Master-Node) C11 and N nodes (Node): W11,...

[0098] For each node, there are one or more container groups. Each container group can be composed of one or more containers. For example, Figure 2 As shown in the figure, a container group can refer to a Pod in a k8s cluster. Each container group can deploy one service, and the container group of each node can deploy the same service or different services. For example, Figure 2As shown, multiple Pods of NodeW11 are deployed with N+1 services (Service0 to ServiceN). Each service can be set or run in several container groups. A service can implement an independent business logic, for example, 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. A service can send requests to or receive requests from the outside.

[0099] 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.

[0100] 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.

[0101] 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 separately for the same service based on their actual needs. 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-groups of a single control plane, which can solve the deployment resource problem to a certain extent.

[0102] For example, if 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; wherein, 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, and the control plane of Istio obtains the information of Server0 of managed cluster 00 for tenant 0, and configures the service governance rule 00 of Server0 based on xds, and sends it to Envoy00; the control plane of Istio obtains the information of Server0 of managed cluster 10 for tenant 1, and configures the service governance rule 01 of Server0 based on xds and sends it to Envoy10.

[0103] In some possible implementations, taking the control plane of Istio and the traffic proxy of envoy as an example, the control plane senses the xds information for the service, and sends the xds information only to the Envoy corresponding to the tenant to achieve service governance. Among them, the control plane sends the xds information only to the Envoy corresponding to the tenant in the following ways: the control plane uniformly manages the address of Envoy, creates a unique Envoy for each tenant under their respective VPC112 as needed, and the addresses of Envoys of different tenants are different; in addition, a unique Gateway is created for each tenant, and the Gateway is associated with the tenant's Envoy, so that the xds information of the corresponding service will only be sent to the tenant's Envoy associated with the tenant's Gateway.

[0104] In addition, in the embodiment of the present application, the service governance rules can be understood as the configuration of resources in Envoy. Among them, Envoy has a lot of resources. Resources themselves are very abstract concepts. The so-called resources here refer to entities with certain specific functions or purposes created by Envoy according to 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), which is used to implement complex service governance such as dynamic routing, fuses, current limiting, and call chain tracing.

[0105] 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 in 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).

[0106] For example, in Envoy, there are four core resources: Listener, Router, Cluster, and Filter. Correspondingly, the service governance rules include the configuration parameters of XDS.

[0107] Among them, Listener is a listening port opened by Envoy to receive connections from Downstream (client). Envoy can support multiple Listeners. Almost all configurations between multiple Listeners are isolated. The core of Listener configuration includes listening address, Filter chain, etc. Among them, Filter chain can be understood as multiple filters with a sequence. For the same listening address, after intercepting the request, the Filter chain processes the intercepted request according to the sequence of filters in the Filter chain.

[0108] The configuration / resource discovery service corresponding to the Listener is called LDS. LDS is the basis for the normal operation of Envoy. Without LDS, Envoy cannot implement port monitoring, and all other xDS services are also useless. For the Listener Discovery Service (LDS), Envoy can discover all Listeners at runtime, including all filter stacks such as L3 and L4 filters, and perform various proxy tasks such as authentication, Transmission Control Protocol (TCP) proxy, and Http proxy.

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

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

[0111] 2. Listening 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 are used to describe the address of envoy.

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

[0113] Cluster is an abstraction of upstream services. In Envoy, each upstream service is abstracted into a Cluster. Cluster contains the connection pool, timeout, endpoints address, port, type (the type determines the specific endpoint method that Envoy can access for the Cluster), etc.

[0114] The configuration / resource discovery service corresponding to the Cluster is called CDS. For the Cluster Discovery Service (CDS), Envoy uses it to discover the upstream Cluster when routing. Envoy usually adds, updates, and deletes Clusters. When routing HTTP requests, request forwarding can be achieved by adding Cluster information in the HTTP request header.

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

[0116] 1.Cluster name, unique identifier;

[0117] 2. Protocol type: specify the protocol type used by the Cluster, such as Http, TCP, etc.

[0118] 3. Strategy: health check strategy, connection strategy, and load balancing strategy for backend nodes (Endpoint). ;

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

[0120] Another service closely related to CDS is called EDS. The configuration / resource discovery service corresponding to Endpoints is called EDS. Envoy can dynamically obtain upstream Endpoints through EDS.

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

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

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

[0124] It should be noted that CDS focuses on configuring and managing the information of the entire cluster, while EDS focuses on the specific address and health status of the backend nodes in the specified cluster. CDS and EDS can work together. CDS is responsible for managing and configuring the cluster, and EDS is responsible for providing backend node information for Envoy routing and load balancing. Therefore, CDS does not contain specific information about EDS, but usually the configuration of CDS will reference the cluster name in EDS to specify the backend nodes to be managed.

[0125] Among them, Router is the bridge between upstream and downstream, which can be understood as the rules and resource set that bridge Listener and backend services. In Envoy, Listener can receive connections from Downstream (client), Cluster can send traffic to specific upstream services, and Router determines which Cluster the Listener should hand over data to after receiving downstream connections and data. It defines the rules for data distribution. Currently, Envoy supports routing of multiple protocols, such as HTTP, TCP, etc.

[0126] The configuration / resource discovery service corresponding to Route is called RDS. The core configuration of Router includes request matching rules and rules for routing to Cluster. In addition, it may also include retry, diversion, current limiting, etc. For example, for the route discovery service (RDS), Envoy can be used to obtain the complete route configuration for the HTTP connection management filter at runtime, such as HTTP header modification.

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

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

[0129] 2. Routing configuration: Rules for processing requests, which can 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 multiple matching rules to be configured. 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.

[0130] Among them, Filter is generally referred to as a plug-in. Through the Filter mechanism, Envoy provides extremely powerful scalability. In Envoy, many core functions are implemented using Filter. For example, the management of Http traffic and services relies on two plug-ins: HttpConnectionManager (NetworkFilter, responsible for protocol parsing) and Router (responsible for traffic distribution). Using the Filter mechanism, Envoy can theoretically support any protocol and convert between protocols, and can modify and customize request traffic in an all-round way.

[0131] 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, netfilters are configured in LDS. Net filters are Http connectionmanager, which will traverse the configured Http filters and execute the logic in the filter one by one. Among them, Http filters correspond to RDS filters configuration information. RDS filters are composed of two parts, namely the match conditions and the route side, which specifies the corresponding CDS. Load balancing, current limiting, and circuit breaking all belong to the CDS level.

[0132] It should be noted that in the specific implementation, for the published services, when the management node 111 finds that a new service of xds is created or the configuration parameters of the old service are changed, the relevant configuration will be pushed to Envoy. After Envoy receives the relevant configuration and verifies it, 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 Pilot finds that a new service or routing rule is created (by monitoring specific CRD resource changes in the k8s cluster, or discovering Consul service registration and configuration changes), 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 it, it will dynamically update the runtime configuration, use the new configuration to update the configuration of related resources, and obtain new service governance rules.

[0133] Next, in combination with the service system provided above, a service governance method provided by an embodiment of the present invention is introduced in detail. This application will take 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.

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

[0135] like Figure 3 As shown, the service governance method provided in the embodiment of the present application includes at least the following steps:

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

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

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

[0139] Exemplarily, the tenant can access the configuration interface through the terminal device 120, and the terminal device 120 displays the cluster configuration interface. The cluster configuration interface includes the access address of the managed cluster that needs to be configured by the user; Exemplarily, the managed cluster has a unified access interface (the only entrance for resource operations provided by the cloud native platform to the outside world), and 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; then the first access address may include the address and token of the api-server of the k8s cluster. Further, in some possible cases, the access address may also include the network information of the managed cluster (indicating the network of the managed cluster); Exemplarily, taking the k8s cluster as an example, the network information may include the PodCIDR (subnet segment of the k8s cluster CIDR), NodeID, and CNI of the k8s cluster. The tenant configures 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, and management can be understood as the management node 301 having the authority to access and manage the managed cluster.

[0140] In some possible implementations, a cluster deploys multiple services, but generally only some services require service governance. The services that require service governance are called target services, and target services generally require tenants to actively publish them. In other possible situations, the target services can also be all services deployed in the cluster.

[0141] Exemplarily, the tenant can access the configuration interface through the terminal device 120, and the terminal device 120 displays the service publishing interface, which includes the services that need to be published and need to be configured by the user. In 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 the target service for publishing; the tenant publishes the target service in the configuration interface, and sends the target service information to the management node 301 after obtaining it.

[0142] 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.

[0143] Among them, the service information may include the identifier of the target service and the information of the service instance of the target service. Exemplarily, the cluster includes nodes, the nodes deploy PODs, the PODs deploy services, and the Pods associated with the services are managed through Endpoints or EndpointSilce. Correspondingly, the information of the service instance of the target service may indicate the Pod associated with the target service, the Endpoint or EndpointSilce associated with the target service, and further, may include the network address of the Pod associated with the target service, etc. Exemplarily, the network address of the Pod may include the IP address and port number of the Pod. Here, the identifier of the target service may be understood as the identifier used by the cluster to distinguish different services. Generally speaking, the identifier of the service may be a logical address or description information, which is not the network address of a specific microservice or application, or it is not the network address of the container group running the microservice or application. The identifier of the service can be used to describe or identify a service. In other words, the identifier of the service is used to describe or indicate the service requested by the access request in which it is located. In one example, the identifier of the service may include the service name and / or the service version number, etc. In one example, the identifier of the service may be pre-set information for declaring or indicating that the access request requires service governance.

[0144] In some possible implementations, step 306 may include the following contents: 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.

[0145] 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.

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

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

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

[0149] 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 to the virtual machine. It should be noted that if the IPs of multiple virtual machines of the target tenant are the same, SocketOption is 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 a managed cluster or outside a managed cluster. The embodiments of the present application do not make specific limitations on this, and the specific design can be combined with actual needs.

[0150] Subsequently, the management node 111 can 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. 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 may be a pod) according to the network information of the managed cluster. For example, the cluster controller adds the route of the Node in the managed cluster or the Virtual Extensible Local Area Network (vxlan) to the virtual machine where the Envoy in the VPC112 of the target tenant is located based on the CNI of the managed cluster, and opens the data channel between Envoy and the service instance (such as Pod) in the managed cluster.

[0151] 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.

[0152] 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.

[0153] Implementation method 2: The management node 111 can access the managed cluster based on the access address of the managed cluster and obtain the network information of the managed cluster. For example, the management node 111 includes a configuration center, and the configuration center stores various configuration information of the managed cluster; then the management node 111 can access the configuration information of the managed cluster from the configuration center based on the access address of the managed cluster and obtain the network information of the managed cluster.

[0154] 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.

[0155] In the embodiment of the present application, the traffic monitoring rules are used to illustrate some rules for traffic monitoring, such as the rules for monitoring addresses and request processing. The monitoring address is used to illustrate the address of envoy, which is generally an IP address and a port. The monitoring 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 for the listener (Listener) resource. In the specific implementation, a listener (Listener) is configured in the gateway, and the listener is configured with a monitoring address and a Filter chain (used to process requests, which may not be available in some possible situations). 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.

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

[0157] In some other possible implementations, the configuration of the gateway 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 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, etc. These parameters are only used as 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.

[0158] 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.

[0159] 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, it is necessary to fill in the IPs of all Envoys; in this way, accessing the target tenant's Loadbalance service will access the target tenant's exclusive Envoy; then, create a Gateway, 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, the Loadbalance service is associated with multiple Envoys, so that the gateway is associated with multiple Envoys.

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

[0161] Among them, the traffic processing rules can indicate the routing rules for matching, modifying, and forwarding traffic to the target service. Exemplarily, 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 the present 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.

[0162] 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.

[0163] In some other possible implementations, traffic processing rules can be set by users. Exemplarily, a 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 configurable parameters 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 90% of the traffic accessing the v1 version of the target service, 10% of the traffic accessing the v2 version of the target service, or the traffic distribution of the master and standby 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.

[0164] Exemplarily, the processing rule configuration interface is used to convert the Service resources of the Kubernetes cluster into the VirtualService resources of Istio. Among them, VirtualService is a core configuration of Istio traffic management. VirtualService defines a set of traffic rules for the target service, which formally represents a virtual service, forwarding 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 are executed for the traffic coming in from the Gateway.

[0165] Step 307 , the management node 111 sends service information, traffic monitoring rules, and traffic processing rules to the Envoy in the VPC 112 of the target tenant.

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

[0167] In the 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; wherein CDS and EDS can be understood as service instance discovery rules.

[0168] It should be noted that the embodiments of the present 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 the embodiments of the present application do not make specific limitations on this.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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.

[0173] It should be noted that here, the gateway can be understood as the ingress gateway (Ingress Gateway). Among them, 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 pointing to endpoints in the local cluster network. This traffic is first routed to the public entry point 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.

[0174] In the specific implementation, Figure 4a As shown, in the process of service governance of the target service by the management node 111, Envoy can first go through Listners for the request sent by the gateway. Listners include multiple Listners, each Listner contains Lister Filters 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), 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.

[0175] For example, taking the processing of HTTP requests as an example, Envoy contains an Http router filter, which can be installed to perform advanced routing tasks. In the process of processing HTTP requests, the listener in Envoy first accepts the request and hands it over to the HTTP router filter. After the HTTP router filter processes it, it hands the request over to the application cluster discovered by CDS according to the routing rules determined by RDS. The Endpoint in the application cluster actually processes the request and sends it to the Pod.

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

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

[0178] It should be noted that when the gateway sends requests to the outside of the service mesh, the gateway can be understood as an egress gateway (EgressGateway). Egress Gateway is a concept symmetrical to Ingress Gateway. It defines the egress of the service mesh, allows Istio functions (for example, monitoring and routing rules) to be applied to the outbound traffic of the service mesh, and allows services inside the service mesh to access the outside.

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

[0180] In some cases, there may be a mutual calling relationship between services in multiple clusters of the target tenant. The embodiment of the present application implements communication between services in different clusters through a gateway. For example, for clusters 01 and 02 of the target tenant, service A in cluster 01 and service B in cluster 02 cannot communicate directly, and need to expose services to each other through the east-west gateway.

[0181] For example, Figure 4bAs shown in the figure, Tenant0-VPC (VPC of tenant 0) includes Envoy00, Envoy01, managed cluster 00, and managed cluster 01; managed cluster 00 deploys three services, Server0, Server1, and Server2, and manages them through Envoy00; managed cluster 01 deploys three services, Server3, Server4, and Server5, and manages them through Envoy01; tenant 0 only publishes Servery0, Server1, and Server2 deployed by managed cluster 00 and Server3 deployed by managed cluster 01; Envoy00 performs service governance on Server0, Server1, and Server2, and Envoy01 performs service governance on Server3, and there is no need to perform service governance on Server4 and Server5. Gateway0 (gateway of tenant 0) is deployed in Istio, and the corresponding service governance rules for Server0, Server1, Server2, and Server3 are deployed. Then, Envoy00 can obtain the service management rules of Server0, Server1, and Server2, and Envoy01 can obtain the service management rules of Server3.

[0182] Next, 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 through the service governance rules of Server0, it forwards request 1 to the service instance (Pod) where Server0 is located in the managed cluster 00.

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

[0184] When Server2 in managed cluster 00 accesses Server3 in managed cluster 01, Server2 initiates request 3. After Envoy00 processes it according to the service governance rules of Server2, 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 the service governance rules of Server3, it forwards request 3 to the service instance (Pod) where Server3 in managed cluster 01 is located.

[0185] 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 gateways of different tenants.

[0186] For example, if Figure 4c As shown, 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; wherein, 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.

[0187] Tenant 0 and Tenant 1 have released Server0. For Tenant 0, Istio's control plane deploys Gateway0, configures Server0's service governance rule 00, and sends it to Envoy00. For Tenant 1, Istio deploys Gateway1, configures Server0's service governance rule 01, and sends it to Envoy10. Subsequently, the relevant traffic of Tenant 0 is managed through Gateway0, and the relevant traffic of Tenant 1 is managed through Gateway1.

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

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

[0190] In the embodiment of the present application, it should be noted that if there are multiple managed clusters of the target tenant, and the multiple managed clusters are managed by multiple Envoys, then the gateway of the target tenant is associated with multiple Envoys; if multiple managed clusters deploy the target service, at this time, the service governance rules of the target service will be sent to the gateway to associate 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, and the embodiment of the present application does not make specific restrictions on this. The rules for forwarding to the envoy can be determined in combination with actual needs.

[0191] For example, if Figure 4d As shown, the sum Figure 4c The difference is that Tenant0-VPC (VPC of Tenant 0) 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. Since Server0 is deployed in managed cluster 00 and managed cluster 01, the service governance rule 00 of Server0 is sent to Envoy00 and Envoy01.

[0192] When a user outside the cluster calls Server0 of managed cluster 00, Gateway0 can perform load balancing (for example, through the Loadbalnce service associated with Gateway0) after determining 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 Envoy00 processes request 1 through the service governance rule 00 of Server0, it forwards request 1 to the service instance (Pod) where Server0 in managed cluster 00 is located.

[0193] In this solution, a single control plane isolates services at the tenant level, so that the same services of different tenants are identified as different services. When performing service governance, the tenant's service governance rules are sent to the tenant's traffic proxy Envoy, thereby realizing logical multi-grouping of a single control plane, which can solve the deployment resource problem to a certain extent.

[0194] Based on the service governance method provided above, the specific application of the service governance method is explained. Figure 4e A flow chart of a specific application of a service governance method provided for the implementation of the present invention. Figure 4eAs shown in the figure, 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:

[0195] 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 the Istio configuration center. In this way, the control plane component of Istio monitors the configuration center, thereby treating cluster 00 in Tenant0-VPC as a 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. The control plane component of Istio creates Envoy00 in Tenant0-VPC, creates a gateway for Tenant 0: Gateway0, and determines the service governance rule 00 of 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 sends it to Envoy00.

[0196] Tenant 1 displays the configuration interface through a computer; then, Tenant 1 operates the configuration interface to determine the configuration information, which is stored in the configuration center of Istio. After the cluster is managed, the configuration center can include the service information of the target service; in this way, the control plane component of Istio 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; the control plane component of Istio creates Envoy00 in Tenant1-VPC; creates a gateway for Tenant 1: 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.

[0197] 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 services of different tenants, so that the same services of different tenants are identified as different services.

[0198] In the embodiments of the present application, different tenants are isolated for the same service, and currently the isolation is mainly achieved in two ways.

[0199] In one possible way, service isolation can be achieved through service labels. Correspondingly, the isolation identifier is the service label. Specifically, when configuring the gateway, the target tenant can configure the label of the target service. Since different tenants have different gateways, services with the same label configured on different gateways will also be considered as different services by the control plane.

[0200] In one possible way, service isolation can be achieved through namespaces, and the isolation identifier can be the name of the namespace. When isolating services through namespaces, the control plane needs to map the target service to the namespace at the tenant level to achieve service isolation, so that the control plane considers the service to be a service that belongs exclusively to the tenant. For example, the namespace at the tenant level can be based on the tenant's identifier and the identifier of the namespace where the service is located, thereby achieving tenant-level service isolation. In this way, for the same service, if the VPC 112 where the service is located is different, the control plane will be considered as a different service.

[0201] 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 the 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), and map the service to the second namespace, such as synchronizing the service information in the first namespace to the second namespace. Exemplarily, as Figure 5 As shown in the above Figure 3 Based on the embodiment shown, in the embodiment of the present application, step 302 includes the following steps:

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

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

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

[0205] 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.

[0206] Exemplarily, the name of the second namespace may include the identifier of the target tenant and the identifier of the first namespace where the target service is located, such as the name. Correspondingly, the namespace creation instruction includes the identifier of the first namespace. In this way, the second namespaces of different target tenants are different, thereby achieving service isolation at the tenant level.

[0207] 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.

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

[0209] 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 services of different tenants belong to different second namespaces, the management node 111 will consider them to be different services, and subsequently obtain the service governance rules for different services.

[0210] It should be noted that the namespace provides a resource isolation mechanism. The resource names in the same namespace need to be unique, but the 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 it is allowed to create the same namespace 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.

[0211] For example, the target tenant has M (greater than or equal to 2) managed clusters, the M managed clusters have the same namespace N1, the 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.

[0212] In this scenario, multiple managed clusters for a tenant can be managed by multiple Envoys, and the tenant's gateway is associated with multiple Envoys; if multiple managed clusters deploy the target service, the service governance rules of the target service will be sent to the multiple Envoys associated with the gateway. During the service governance process, the gateway can determine an envoy from multiple envoys through the load balancing service and forward the request to the envoy.

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

[0214] like Figure 6a As shown, 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; wherein, managed cluster 00 deploys services Server0, Server1, ..., services Server0, Server1, ... are located in namespace1, and traffic management is performed through Envoy00; managed cluster 10 deploys services Server0, Server1, ...; services Server0, Server1, ... are located in namespace1, and traffic management is performed through Envoy10.

[0215] Tenant 0 and Tenant 1 published Server0.

[0216] 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 of tenant 0's namespace1: Tenant0-namespace1, and maps the information of Server0 of 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.

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

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

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

[0220] 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 Envoy10 processes request 2 through service governance rule 01 of Server0, it forwards request 2 to the service instance (Pod) where Server0 is located in managed cluster 10.

[0221] 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 service governance at the tenant level cannot be achieved; however, in the embodiments 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.

[0222] 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.

[0223] For example, Figure 6b As shown, relative to Figure 6a The differences are as follows:

[0224] Tenant0-VPC (VPC of tenant 0) also includes Envoy01 and managed cluster 01; managed cluster 01 deploys services Server0, Server1, ..., and services Server0, Server1, ... are located in namespace1, and traffic management is performed through Envoy01.

[0225] 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 of tenant 0's namespace1: Tenant0-namespace1, and maps the information of Server0 of managed cluster 00 to Tenant0-namespace1. Cluster synchronizer 01 maps the information of Server0 of managed cluster 01 to Tenant0-namespace1. Istio's control plane sends Server0's service governance rule 00 to Envoy00 and Envoy01.

[0226] Subsequently, the traffic related to tenant 0 is managed through Gateway 0.

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

[0228] Based on the service governance method provided above, the specific application of the service governance method is explained. Figure 7 A flow chart of a specific application of a service governance method provided for the implementation of the present invention. Figure 7 As shown in the figure, 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:

[0229] Tenant 0 operates through terminal device 120, publishes Server0 (located in namespace1), manages cluster 00, and creates gateways 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 of 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 the gateway of tenant 0: Gateway0 and the load balancing service: Loadbalance0. Gateway0 and Loadbalance0 are associated, and the routing rule route0 of 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 be additional information of Server0 (not shown in the figure, such as the Endpoint and Pod associated with Server0). The service governance rule 00 of Server0 is determined and sent to Envoy00 in Tenant0-VPC.

[0230] 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 of Tenant 1's namespace1: Tenant1-namespace1, and maps the information of Server0 in namespace1 of managed cluster 10 to Tenan In t1-namespace1, Istio's control plane creates Gateway1 and Loadbalance1 for Tenant 1. Gateway1 and Loadbalance1 are associated, and Server0's routing rule route1 (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 be additional information about Server0 (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.

[0231] This application also provides a service management device, such as Figure 8 As shown, including:

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

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

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

[0235] 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.

[0236] Among them, the service information determination module, the gateway creation module, the rule determination module and the delivery module can all be implemented by software, or can be implemented by hardware. Exemplarily, the service information determination module is taken as an example to introduce the implementation method of the service information determination module. Similarly, the implementation method of the gateway creation module, the rule determination module and the delivery module can refer to the implementation method of the service information determination module.

[0237] As an example of a software functional unit, the service information determination module may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the service information determination module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with close geographical locations. Among them, usually a region may include multiple AZs.

[0238] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

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

[0240] 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 computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0241] 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.

[0242] The present application also provides a computing device 110. Fig. 9 As shown, the computing device 110 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other through the bus 102. The computing device 110 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 110.

[0243] The bus 102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 The bus 102 may include a path for transmitting information between various components of the computing device 110 (eg, the memory 106, the processor 104, and the communication interface 108).

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

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

[0246] The memory 106 stores executable program codes, and the processor 104 executes the executable program codes to respectively implement the functions of the aforementioned service information determination module, gateway creation module, rule determination module, and delivery module, thereby implementing the service governance method. That is, the memory 106 stores instructions for executing the service governance method.

[0247] 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.

[0248] The embodiment of the present application also provides 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 smart phone.

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

[0250] 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 may jointly execute instructions for executing the service governance method.

[0251] It should be noted that the memory 106 in different computing devices 110 in the computing device cluster may store different instructions, which are respectively used to execute part of the functions of the service management device. That is, the instructions stored in the memory 106 in different computing devices 110 may implement the functions of one or more modules among the service information determination module, the gateway creation module, the rule determination module and the delivery module.

[0252] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.11 A possible implementation is shown. Fig.11 As shown, two computing devices 110A and 110B are connected via a network. Specifically, the network is connected 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.

[0253] Fig.11 The connection mode between the computing device clusters shown can be considered that the service governance method provided by this application needs to consider the storage of user-configured information, so 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 delivery module are executed by the computing device 100B. It should be understood that Fig.11The functions of the computing device 100A shown in the figure 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, the gateway creation module, the rule determination module, and the delivery module can be deployed in one computing device 100.

[0254] The embodiment of 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 run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the service governance method.

[0255] The embodiment of 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 containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the service governance method.

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

[0257] It should be understood that the order of execution of the steps in the above embodiment does not necessarily 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 embodiment of the present invention.

[0258] The basic principles of the present application are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present application are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, rather than limitation, and the above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0259] The block diagrams of the devices, apparatuses, equipment, and systems involved in this disclosure are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including," "comprising," "having," and the like are open words, referring to "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.

[0260] 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.

[0261] The above description has been given 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 multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

[0262] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used 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. 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. 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.

Images