A service grid hosting method and system based on cloud native platform

Abstract

The present application provides a service grid hosting method and system based on a cloud native platform. A virtual cluster is run in a first managed cluster; the control plane component of the service grid running in the first managed cluster stores the obtained service information, namespace information, and resource objects corresponding to the service grid in the virtual cluster; the control plane component of the service grid reads the service information, namespace information, and resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster. In this way, the service information, namespace information, and resource objects corresponding to the service grid of all managed clusters are uniformly stored in a virtual cluster in a certain managed cluster, which can be isolated from the data information of the managed cluster itself and aggregated for the data information of all managed clusters, so that the control plane component of the service grid can uniformly govern the services in all managed clusters.

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a service grid hosting method, system, computer-readable storage medium, and electronic device based on a cloud native platform. Background Art

[0002] A service mesh is an infrastructure layer that handles inter-service communication. It consists of a control plane and a data plane. The data plane, primarily composed of a large number of sidecars, processes and observes traffic between all services. The control plane manages the execution of the data plane. The control plane is the brains of the service mesh and provides users with a public API to easily manipulate the behavior of the service network.

[0003] After deploying a service mesh in a single cluster, cluster administrators can use control plane components to uniformly manage traffic between all services deployed in the cluster.

[0004] In a multi-cluster scenario, if a service mesh is deployed independently in each cluster, in order to uniformly manage the traffic between all services deployed in multiple clusters through a unified control plane component, the data plane configuration of all clusters needs to be uniformly governed by the control plane component in a certain cluster. In other words, the management of the service mesh in all clusters must be entrusted to a unified control plane component.

[0005] In related technologies, when managing a service mesh across multiple clusters, there are two approaches to hosting the data plane of the service mesh within the managed cluster. The first approach involves directly deploying unified control plane components in a single cluster, but this can pollute the data of the cluster where the control plane components are deployed. The second approach involves setting up a dedicated cluster outside of all clusters to deploy unified control plane components, but this requires additional hardware and increases costs.

[0006] Therefore, it is necessary to provide an improved technical solution to the above-mentioned deficiencies in the prior art. Summary of the Invention

[0007] The purpose of this application is to provide a service grid hosting method, system, computer-readable storage medium and electronic device based on a cloud native platform to solve or alleviate the problems existing in the above-mentioned prior art.

[0008] In order to achieve the above objectives, this application provides the following technical solutions:

[0009] The present application provides a service grid hosting method based on a cloud native platform, wherein a control plane component of the service grid is deployed in a first managed cluster, where the first managed cluster is any one of multiple managed clusters managed by the control plane component of the service grid. The method includes:

[0010] running a virtual cluster in the first managed cluster;

[0011] The control plane component of the service grid obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster;

[0012] In response to monitoring that a resource object corresponding to the service grid is created, the control plane component of the service grid stores the resource object corresponding to the service grid in the virtual cluster;

[0013] The control plane component of the service grid reads the service information, the namespace information, and the resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster.

[0014] In the above technical solution, the running of the virtual cluster in the first managed cluster is specifically:

[0015] Creating a container group in the first managed cluster; the container group includes a plurality of containers, and the containers are used to simulate nodes in the virtual cluster;

[0016] A system initialization process is run in the container; the system initialization process is used to host the Kubelet component and container runtime in the node, and the Kubelet component is used to run components in the virtual cluster.

[0017] In the above technical solution, the components in the virtual cluster include a unified access interface and a distributed key-value pair storage database. The control plane component of the service grid stores the resource objects corresponding to the service grid in the virtual cluster, specifically:

[0018] The control plane component of the service grid persistently stores the resource objects corresponding to the service grid in the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster.

[0019] In the above technical solution, the resource object corresponding to the service grid includes a governance policy resource object; the governance policy resource object is used to define the service governance rules of the service grid;

[0020] Correspondingly, the control plane component of the service grid reads the service information, the namespace information, and the resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster, specifically:

[0021] The control plane component of the service grid reads the service information, the namespace information and the service governance rules of the service grid from the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster;

[0022] The control plane component of the service grid directly sends the service information, the namespace information, and the service governance rules of the service grid to all service grid sidecars in the first managed cluster, and sends them to all service grid sidecars in the second managed cluster through the proxy component in the second managed cluster.

[0023] In the above technical solution, storing the obtained service information and namespace information in the virtual cluster includes:

[0024] In response to both the first managed cluster and the second managed cluster including a first namespace, aggregating service information in the first namespace in the first managed cluster and the first namespace in the second managed cluster;

[0025] In response to the first namespace in the first managed cluster and the first namespace in the second managed cluster both including a first service, aggregating service information corresponding to the first service;

[0026] The service information and namespace information corresponding to the aggregated first service are stored in the virtual cluster.

[0027] In the above technical solution, the service grid's service governance rules include routing rules for the first service. The control plane component of the service grid distributes the service information, the namespace information, and the service grid's service governance rules to all service grid sidecars in the first managed cluster and the second managed cluster, including:

[0028] Send the service information and namespace information corresponding to the first service to all service mesh sidecars in the first managed cluster and the second managed cluster;

[0029] The routing rules of the first service are distributed to the service mesh sidecars of all service instances corresponding to the first service in the first managed cluster and the second managed cluster.

[0030] In the above technical solution, the method further includes:

[0031] The control plane component of the service grid monitors changes in the service information and the namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively;

[0032] In response to monitoring a change in the service information or the namespace information, updating the service information or the namespace information stored in the virtual cluster;

[0033] In response to monitoring a change in a resource object corresponding to the service grid, the control plane component of the service grid updates the resource object corresponding to the service grid stored in the virtual cluster;

[0034] The control plane component of the service grid sends the updated service information, the namespace information, or the resource object corresponding to the service grid to all service grid sidecars in the first managed cluster and the second managed cluster.

[0035] An embodiment of the present application further provides a service grid hosting system based on a cloud native platform, wherein a control plane component of the service grid is deployed in a first managed cluster, and the first managed cluster is any one of multiple managed clusters managed by the control plane component of the service grid. The system includes:

[0036] an operating unit configured to operate a virtual cluster in the first managed cluster;

[0037] a first storage unit configured as a control plane component of the service grid to obtain service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and store the obtained service information and namespace information in the virtual cluster;

[0038] a second storage unit, configured to, in response to monitoring that a resource object corresponding to a service grid is created, store the resource object corresponding to the service grid in the virtual cluster by the control plane component of the service grid;

[0039] A sending unit is configured as a control plane component of the service grid to read the service information, the namespace information, and the resource object corresponding to the service grid from the virtual cluster, and send it to all service grid sidecars in the first managed cluster and the second managed cluster.

[0040] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program is a service grid hosting method based on a cloud-native platform as described above.

[0041] An embodiment of the present application also provides an electronic device, comprising: a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the service grid hosting method based on a cloud-native platform as described above is implemented.

[0042] Beneficial effects:

[0043] In the technical solution of the present application, the control plane component of the service grid is deployed in the first managed cluster, wherein the first managed cluster is any one of the multiple managed clusters managed by the control plane component of the service grid. The technical solution first runs a virtual cluster in the first managed cluster, and then the control plane component of the service grid obtains the service information and namespace information of each cluster through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster; by monitoring the event that the resource object corresponding to the service grid is created, the resource object corresponding to the created service grid is stored in the virtual cluster. In this way, the service information, namespace information and resource objects corresponding to the service grid of all managed clusters are uniformly stored in the virtual cluster in a certain managed cluster, so that the data information stored in the virtual cluster is isolated from the data information of the managed cluster itself, avoiding pollution of the data information of the managed cluster itself.

[0044] Compared to setting up a dedicated cluster to deploy unified control plane components, deploying the control plane components of the service mesh in a virtual cluster within a managed cluster eliminates the need for additional hardware equipment for deploying the control plane components of the service mesh, thus reducing costs.

[0045] In addition, the control plane component of the service grid aggregates the data information of all managed clusters and stores it in the virtual cluster. When the service grids of all managed clusters are uniformly governed, the control plane component reads the above content stored in the virtual cluster and sends it to all service grid sidecars in all managed clusters, thereby realizing the unified management of multi-cluster service grids, reducing the workload of service grid operation and maintenance, and improving the work efficiency of multi-cluster administrators. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The drawings and descriptions that constitute part of this application are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. Among them:

[0047] Figure 1 A logical diagram of a multi-control plane and multi-cluster deployment of a service mesh control plane component in related technologies;

[0048] Figure 2 A logical diagram of a single control plane multi-cluster deployment of a service mesh control plane component in related technologies;

[0049] Figure 3 A logical diagram of a service grid hosting method based on a cloud native platform provided for some embodiments of the present application;

[0050] Figure 4A flowchart of a service grid hosting method based on a cloud native platform provided for some embodiments of the present application;

[0051] Figure 5 A schematic diagram of the structure of a service grid hosting system based on a cloud native platform provided for some embodiments of the present application;

[0052] Figure 6 A schematic structural diagram of an electronic device provided according to some embodiments of the present application;

[0053] Figure 7 A hardware structure diagram of an electronic device provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0054] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with the embodiments. Each example is provided by way of explanation of the present application and does not limit the present application. In fact, it will be clear to those skilled in the art that modifications and variations can be made in the present application without departing from the scope or spirit of the present application. For example, a feature shown or described as part of one embodiment can be used in another embodiment to produce yet another embodiment. Therefore, it is expected that the present application includes such modifications and variations within the scope of the appended claims and their equivalents.

[0055] In the following description, the terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that "first / second / third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0056] In order to facilitate understanding of the technical solution of this application, some technical terms and related technologies involved in this application are introduced below.

[0057] A microservice is a small service consisting of a single application. Each microservice has its own process and can communicate with other microservices through lightweight communication mechanisms, such as an Application Programming Interface (API) based on the Hypertext Transfer Protocol (HTTP).

[0058] A microservice architecture is one that breaks down applications (especially large applications, such as e-commerce systems) into several microservices. In some examples, this can include classic architectures like Spring Cloud and Dubbo, which are less invasive. Compared to traditional monolithic architectures that centralize all functional services in a single container, a microservice architecture achieves business decoupling by breaking down functionality into discrete services. In a microservice architecture, each business team maintains the microservices corresponding to their business, reducing maintenance complexity and improving efficiency. Furthermore, if a single microservice fails, other microservices can continue to function, improving system stability.

[0059] In some cases, multiple microservices within an application can call each other. For example, in an e-commerce system, a product system microservice can call a review system microservice to display historical user reviews of a product when displaying product details. Service governance is the process of managing the call relationships between services within a distributed service framework. Service governance can be broken down into the following aspects: service registration and discovery, load balancing, fault handling and recovery (throttling, circuit breaking, timeouts, retries), phased releases, and service tracking.

[0060] Currently, microservice architecture applications primarily utilize service meshes for service governance. A service mesh is an infrastructure layer that handles communication between services (including microservices), consisting of both a control plane and a data plane. One implementation of a service mesh involves assigning a separate proxy, also known as a sidecar, to each microservice instance. This proxy handles inter-service communication, monitoring, and security-related tasks, thereby providing functionality such as service discovery, load balancing, encryption, authentication, authorization, and circuit breaking. Microservices themselves are no longer responsible for the specific logic of processing service requests, such as request-based balancing, but instead focus solely on completing service processing. The sidecars comprise the service mesh's data plane, while the management components responsible for executing the data plane comprise the control plane. The control plane is the brains of the service mesh and provides users with a public API for easily manipulating the behavior of the service network.

[0061] In the microservice architecture, service governance, also known as SOA governance (Service Oriented Architecture governance, SOA governance), is the decision-making and management of services, including handling the relationship between service calls, service publishing and discovery, service monitoring, reliability assurance, and other aspects.

[0062] After deploying a service mesh in a single cluster, cluster administrators can centrally manage traffic between all services deployed in the cluster through the control plane component. Specifically, this is done by creating a CRD (CustomResourceDefinition) resource object on the control plane node to configure service governance rules for the control plane of the service mesh in order to govern the data plane of the service mesh. The CRD resource object can define the service governance rules of the service mesh. The control plane of the service mesh sends the service governance rules defined by the CRD resource object to the data plane of the service mesh, which is the sidecar in the service mesh. The sidecar implements functions such as service discovery, load balancing, encryption, identity authentication, authorization, and circuit breaking.

[0063] In a multi-cluster scenario, if a deployment method similar to that in a single-cluster scenario is adopted, that is, the control plane and data plane of the service grid are independently deployed in each cluster, that is, a multi-control-plane multi-cluster deployment method, the cluster administrator needs to create a CRD resource object on the node where the control plane of each service grid is located to configure service governance rules for each service grid's control plane separately, so as to govern the data plane of the service grid in each cluster separately. It is impossible to achieve unified management of traffic between all services deployed in all clusters.

[0064] Figure 1 An example of multi-control plane multi-cluster deployment is shown. Figure 1 As shown, multiple clusters (including but not limited to cluster 01 and cluster 02 shown in the figure) are deployed with service grids to manage traffic between services in the clusters. Each cluster has a control plane (i.e. Figure 1 The control plane of the service mesh only needs to obtain service information and namespace information from the unified access interface of the cluster (such as the API-Server component of Kubernetes). The configured service governance rules only affect the service mesh sidecar in the cluster. In addition, if cluster 01 and cluster 02 are located in different networks, such as network 01 and network 02 respectively, then service A in cluster 01 and service B in cluster 02 cannot communicate directly. They need to expose services to each other through the east-west traffic gateway.

[0065] The advantage of this deployment method is that it is simple and direct. The control plane of the service grid in each cluster independently manages the traffic between all services deployed in the cluster. However, the control plane of the service grid in each cluster needs to configure service governance rules separately. It is impossible to uniformly configure service governance rules for all clusters and it is impossible to uniformly manage the traffic between all services deployed in all clusters.

[0066] In order to uniformly manage the traffic between all services deployed in all clusters through a unified control plane component, it is necessary to govern the data plane configuration of the service grids in all clusters by a unified control plane component. In other words, the management of the service grids in all clusters is hosted in a unified control plane component. Therefore, the cluster where the data plane of the deployed service grid is hosted in a unified control plane component can be called a managed cluster.

[0067] In the related art, when the service grids of multiple managed clusters are uniformly governed, there are two ways to host the data plane of the service grids in the managed clusters: the first way is to directly select a cluster from all clusters to deploy a unified control plane component, and the unified control plane component directly manages the data plane of the service grids in all managed clusters. However, this method requires that the data information of all managed clusters be stored in the cluster where the control plane component is deployed so that the control plane component can be called during runtime, which will pollute the data information of the cluster itself where the control plane component is deployed.

[0068] Figure 2 An example of a single control plane multi-cluster deployment is shown. Figure 2 As shown, multiple managed clusters (including but not limited to cluster 01 and cluster 02 shown in the figure) are deployed with the data plane of the service grid, and the unified control plane component (i.e. Figure 2 The mesh control plane (in Kubernetes) is deployed in Cluster 01, and the data planes of the service meshes deployed in other managed clusters are hosted in a unified control plane component. To manage services across all managed clusters, the unified control plane component needs to obtain service information and namespace information from each managed cluster's unified access interface (such as the Kubernetes API-Server component), store this data in Cluster 01, and then distribute service governance rules to all managed clusters. However, this approach, storing data from all managed clusters in Cluster 01, inevitably pollutes the data in Cluster 01 itself.

[0069] In addition, similar to the aforementioned example of multiple control planes and multiple clusters, if cluster 01 and cluster 02 are located in different networks, such as network 01 and network 02 respectively, then service A in cluster 01 and service B in cluster 02 cannot communicate directly. They need to expose services to each other through the east-west traffic gateway, and the east-west traffic gateway needs to be used in cluster 01 to expose the unified control plane components, which increases the risk of the unified control plane components being intruded.

[0070] The second method is to set up a dedicated cluster outside of all clusters to deploy unified control plane components, but this requires additional hardware equipment, which increases costs.

[0071] The dedicated cluster is used only to run the unified control plane component. The data plane of the service mesh deployed in all managed clusters can be accessed and hosted by the unified control plane component. While this approach enables unified governance of the data plane of the service mesh deployed in all managed clusters, it requires additional hardware and increases costs.

[0072] After an in-depth analysis of the operating mechanisms of relevant technologies for unified governance of service grids of multiple managed clusters, the applicant found that in a multi-cluster scenario, in order to achieve unified governance of all services deployed in all clusters, it is necessary to aggregate the data information of all clusters, so as to bring together the service instances corresponding to the same service deployed in different clusters, and uniformly configure service governance rules for all service instances corresponding to the same service.

[0073] For example, if namespace N1 is set up in multiple managed clusters, and service instances corresponding to service A are deployed in all namespaces N1, then in order for a unified control plane component to uniformly govern the service instances corresponding to service A in all managed clusters, it is necessary to obtain the namespace information and service information of the managed clusters, and determine all service instances corresponding to service A in all managed clusters based on the namespace information and service information. Only then can the unified control plane component distribute the governance policy of service A to all service mesh sidecars corresponding to service A. In other words, in order for the unified control plane component to find the service instances corresponding to service A in all managed clusters, each service instance corresponding to service A will be deployed in namespace N1. The unified control plane component only needs to find all corresponding service instances in all namespaces N1 based on the identification information of service A, and can distribute the governance policy of service A to all service mesh sidecars corresponding to service A.

[0074] Therefore, there will be a namespace N1 in each managed cluster where a service instance corresponding to service A is deployed. After aggregating the data information of all managed clusters, the information of namespace N1 can be found from all namespace information, and then all service instances corresponding to service A can be found from all service instances in namespace N1. Then, all service instances corresponding to service A can be brought together, so that service governance rules can be uniformly configured for all service instances corresponding to service A.

[0075] However, after aggregating the data information of all managed clusters, the aggregated data information needs to be uniformly stored in a storage area accessible to a unified control plane component, so that when the service governance rules change, there is no need to repeatedly collect and aggregate the data information of all managed clusters. The unified control plane component can directly use the stored data information to uniformly update the service governance rules for all service instances corresponding to the relevant services.

[0076] To this end, the applicant provides a service grid hosting method, system, computer-readable storage medium and electronic device based on a cloud-native platform. By running a virtual cluster in a first managed cluster, the service grid control plane component deployed in the first managed cluster obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and then stores the obtained service information, namespace information, and resource objects corresponding to the service grid created by the user into the virtual cluster, thereby realizing the unified storage of service information, namespace information and resource objects corresponding to the service grid of all managed clusters into a virtual cluster in a certain managed cluster, which can be isolated from the data information of the managed cluster itself and aggregated for the data information of all managed clusters, so that the control plane component of the service grid can uniformly govern the services in all managed clusters.

[0077] Exemplary Methods

[0078] The present application embodiment provides a service grid hosting method based on a cloud native platform, such as Figure 3 As shown, the control plane component of the service grid is deployed in a first managed cluster, and the first managed cluster is any one of the multiple managed clusters managed by the control plane component of the service grid. Figure 4 As shown in the figure, the cloud-native platform-based service mesh hosting method includes:

[0079] Step S101: Run a virtual cluster in a first managed cluster.

[0080] As mentioned earlier, a service mesh is an infrastructure layer that handles inter-service communication. Logically, it can be divided into two parts: the control plane and the data plane. Taking Istio as an example, Istio's control plane components include Mixer, Pilot, and Citadel. The data plane components use Envoy as a traffic proxy, injected into the target container of the service as a sidecar, and perform communication proxy, traffic control, and balancing for the related services.

[0081] When the data plane of the service grid in multiple clusters is uniformly governed, the control plane components of the service grid can be deployed in a dedicated cluster or in a managed cluster. In order to reduce costs, the embodiment of the present application adopts a solution of deploying the control plane components of the service grid in a managed cluster, and the managed cluster where the control plane components of the service grid are located is called the first managed cluster. The first managed cluster is any one of the multiple managed clusters managed by the control plane components of the service grid. In practice, a cluster can be randomly selected from multiple managed clusters as the first managed cluster, or each managed cluster can be scored according to the resource usage of the managed cluster, and a managed cluster with relatively sufficient resources can be selected as the first managed cluster. The first managed cluster can also be determined based on other parameters of the managed cluster.

[0082] To avoid contaminating the data and information of the first managed cluster itself, an embodiment of the present application runs a virtual cluster within the first managed cluster. The virtual cluster runs on top of the first managed cluster. Compared to a real cluster composed of physical nodes, the virtual cluster consists of virtual nodes and does not contain any physical nodes. Instead, it uses the resources of the first managed cluster to simulate nodes in the virtual cluster and manages these virtual nodes through the control plane components of the virtual cluster. This is a method of resource isolation within the first managed cluster. The use of a virtual cluster isolates the data and information managed by the control plane components of the service grid from the data and information of the first managed cluster itself, avoiding contamination of the data and information of the first managed cluster itself.

[0083] In order to be able to run the virtual cluster in the first managed cluster, in some embodiments, running the virtual cluster in the first managed cluster is specifically as follows: creating a container group (Pod) in the first managed cluster; the container group includes multiple containers (Container), and the containers are used to simulate nodes in the virtual cluster; running the system initialization process in the container; the system initialization process is used to host the Kubelet component and container runtime in the node, and the Kubelet component is used to run the components in the virtual cluster.

[0084] It should be noted that a container group is the smallest deployable computing unit created and managed in a cloud-native platform. In the embodiments of this application, a container group contains multiple containers, which share underlying resources such as storage and network. A single container can simulate a node in a virtual cluster, so the entire virtual cluster can be simulated through the container group.

[0085] In a cloud-native platform, each node in the cluster needs to run one or more node components to manage and monitor the node, such as regularly receiving management instructions for the node, monitoring and reporting the node's operating status.

[0086] Taking the Kubernetes cluster as an example, the Kubelet component is the agent component of each node in the Kubernetes cluster. It is a component deployed on each node (including control nodes and worker nodes) in the Kubernetes cluster to maintain running container groups and provide the Kubernetes operating environment for the container groups. It is one of the most important node components.

[0087] The Kubelet component is used to maintain the running container group and provide the Kubernetes runtime environment. For example, it is responsible for maintaining the life cycle of the container and is also responsible for managing storage volumes (CVI) and networks (CNI).

[0088] In addition, node components also include container runtime components, such as Containerd. Container runtime components are responsible for image management and providing the actual operating environment for container groups and containers, that is, providing the Container Runtime Interface (CRI).

[0089] To host the Kubelet and container runtime on the node, a system initialization process must run in the container. This process is an initialization daemon (init system) that enables the parallel startup of the Kubelet and container runtime during system initialization of the virtual cluster. It automatically restarts these components if any exceptions occur, maintaining the proper operation of the Kubelet and container runtime. In some implementations, this initialization daemon can be the Systemd process in Linux.

[0090] In this embodiment of the application, multiple containers are used to simulate nodes in a virtual cluster, and by running the system initialization process in the container, a virtual cluster is created and run in the container group. The container group is the basic unit for management and scheduling of the cloud native platform, and different container groups are independent of each other.

[0091] Step S102: The control plane component of the service grid obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster.

[0092] The second managed cluster is any one of multiple managed clusters managed by the service grid other than the first managed cluster. The data plane of the service grid deployed in the second managed cluster is hosted on the control plane component of the service grid deployed in the first managed cluster. The service information obtained includes, but is not limited to, the service name, the service's virtual IP (Cluster IP) address, and the corresponding service instance information. Namespace information includes, but is not limited to, the namespace name.

[0093] It's important to note that cloud-native platforms abstract everything they manage into resources. For example, services are a type of resource. Namespaces divide resources within a cluster into isolated groups. Resource names within the same namespace must be unique, but resource names in different namespaces can be the same.

[0094] In an embodiment of the present application, both the first managed cluster and the second managed cluster include a unified access interface. The unified access interface is the only entrance for resource operations provided by the cloud native platform to the outside world. The control plane component of the service grid can obtain resource-related information of the cloud native platform, such as service information and namespace information, by sending resource operation instructions to the unified access interfaces of the first managed cluster and the second managed cluster respectively.

[0095] Taking the Kubernetes cluster as an example, the Kubernetes cluster uses the API-Server component as the unified access interface for resource operations. The control plane components of the service mesh can initiate resource operation requests to the API-Server component to obtain service information and namespace information in the Kubernetes cluster.

[0096] In some implementations, it also includes: the control plane component of the service grid obtains service information and namespace information from the first managed cluster and the second managed cluster, and converts them into custom resources required for service grid management, such as converting the Service resources of the Kubernetes cluster into Istio's VirtualService resources, and storing them in the virtual cluster by calling the unified access interface.

[0097] This embodiment uses a virtual cluster to isolate the data information of the first managed cluster itself from the service information, namespace information, and resource objects corresponding to the service grid obtained by the control plane component of the service grid, thereby avoiding pollution of the data information of the first managed cluster itself.

[0098] Specifically, the acquired service information and namespace information are stored in the virtual cluster, including: in response to the first managed cluster and the second managed cluster both containing the first namespace, the service information in the first namespace in the first managed cluster and the first namespace in the second managed cluster are aggregating; in response to the first namespace in the first managed cluster and the first namespace in the second managed cluster both containing the first service, the service information corresponding to the first service is aggregating; and the aggregated service information and namespace information corresponding to the first service are stored in the virtual cluster.

[0099] As mentioned earlier, namespaces provide a resource isolation mechanism for clusters. Resource names within the same namespace must be unique, but resource names across different namespaces can be the same. Furthermore, from a cluster perspective, namespaces must be unique within a single cluster, but the same namespace can be created in different clusters. In multi-cluster scenarios, 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. This improves service availability by preserving the normal responsiveness of the service in the event of a single cluster failure.

[0100] Since different service instances corresponding to the same service may be deployed in different clusters, in order to use service grid technology to uniformly manage different service instances corresponding to the same service, it is necessary to break through the isolation between clusters and uniformly set corresponding functions for all service instances corresponding to the same service. Therefore, before storing the obtained service information and namespace information in the virtual cluster, it should also be determined whether the services from different clusters are different service instances corresponding to the same service. Specifically, when the first managed cluster and the second managed cluster both contain the same first namespace, the service information in the first namespace of the first managed cluster and the first namespace of the second managed cluster should be aggregated so that the service information in the first namespace of the first managed cluster and the service information in the first namespace of the second managed cluster are both merged into the first namespace of the service grid. When it is determined that the first namespace in the first managed cluster and the first namespace in the second managed cluster both contain the same first service, that is, the first managed cluster and the second managed cluster respectively manage different service instances of the first service, it is necessary to aggregate the service information corresponding to the first service in the service grid to establish a mapping relationship between the above-mentioned different service instances and the first service in the service grid, so that the service grid can uniformly manage different service instances corresponding to the same service.

[0101] Step S103: In response to monitoring that a resource object corresponding to the service grid is created, the control plane component of the service grid stores the resource object corresponding to the service grid in the virtual cluster.

[0102] In an embodiment of the present application, the resource object corresponding to the service grid is a custom resource object, which is created by the administrator through the interface provided by the control plane component of the service grid (such as the Istioctl tool provided by Istio or a graphical user interface provided by a third party), and is used to implement complex service governance such as dynamic routing, circuit breaking, current limiting, and call chain tracing.

[0103] In an embodiment of the present application, the control plane component of the service grid continuously monitors changes in the resource objects corresponding to the service grid. When it is detected that the resource objects corresponding to the service grid are created, the resource objects corresponding to the service grid are stored in the virtual cluster.

[0104] Specifically, the control plane component of the service mesh can continuously monitor resource changes corresponding to the service mesh through the unified access interface of the first and second managed clusters. For example, it can monitor changes to resource objects corresponding to the service mesh in the Kubernetes cluster through the List / Watch API provided by the API-Server component in the Kubernetes cluster. When it detects that a resource object corresponding to the service mesh has been created, it stores the resource object corresponding to the service mesh in the virtual cluster.

[0105] Based on the above description, it can be seen that the virtual cluster has an independent control plane component. The control plane component in the virtual cluster can manage the virtual nodes in the virtual cluster and accept access and requests like the control plane component of a real cluster. In order to store the obtained service information and namespace information, as well as the resource objects corresponding to the service grid in the virtual cluster, in some embodiments, the components in the virtual cluster include a unified access interface and a distributed key-value pair storage database. The control plane component of the service grid stores the service information and namespace information corresponding to the aggregated first service in the virtual cluster. Specifically, the control plane component of the service grid accesses the unified access interface of the virtual cluster and persistently stores the service information and namespace information corresponding to the aggregated first service in the distributed key-value pair storage database of the virtual cluster. Similarly, the control plane component of the service grid stores the resource objects corresponding to the service grid in the virtual cluster. Specifically, the control plane component of the service grid accesses the unified access interface of the virtual cluster and persistently stores the resource objects corresponding to the service grid in the distributed key-value pair storage database of the virtual cluster.

[0106] The unified access interface in the virtual cluster is used to interact with the control plane component of the service mesh, receive operation instructions sent by the control plane component to the virtual cluster, such as storage instructions and read instructions, and respond to such instructions. Specifically, the control plane component of the service mesh can send operation instructions to the virtual cluster through command-line tools (such as Istioctl of Istio) or corresponding configuration files to drive the virtual cluster to perform corresponding storage or read operations.

[0107] The distributed key-value storage database in the virtual cluster is used to persistently store all resource configurations and status information of resource objects in the service grid.

[0108] For example, using Istio as the service mesh and a virtual Kubernetes cluster as the virtual cluster, the API-Server component of the virtual Kubernetes cluster provides a unified access interface. The ETCD component, acting as a distributed key-value storage database, can be used to store service information, namespace information, and resource objects. Istio, deployed in the first managed cluster, can obtain all service and namespace information by accessing the API-Server components of the first and second managed clusters, respectively, through its control plane component, the Pilot. It can also aggregate information about multiple services with the same name in multiple namespaces with the same name in the first and second managed clusters, and persistently store the aggregated service and namespace information in the ETCD component of the virtual cluster. It can also continuously monitor the API-Server component of the first managed cluster. Upon detecting the creation of a resource object corresponding to the service mesh, it can access the API-Server component of the virtual cluster and persistently store the corresponding resource object in the ETCD component of the virtual cluster.

[0109] In an embodiment of the present application, by deploying a unified access interface and a distributed key-value storage database in a virtual cluster, and persistently storing the service information and namespace information of each cluster managed by the service grid and the resource objects corresponding to the service grid in the distributed key-value storage database, the mutual isolation of the service grid resources and the resources of the first managed cluster is achieved, thereby reducing the intrusion into the first managed cluster.

[0110] Step S104: The control plane component of the service grid reads the service information, namespace information, and resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster.

[0111] Based on the above description, it can be seen that the service mesh consists of two parts: the control plane component and the data plane component. The control plane component is deployed in the first acceptance cluster and is used to obtain and configure the management objects of the service mesh and the resource objects corresponding to the service mesh. The data plane component is deployed in the container group of each managed cluster in the form of a sidecar to implement the corresponding functions. Therefore, after storing the service information, namespace information, and resource objects corresponding to the service mesh in the virtual cluster, the control plane component of the service mesh reads the service information, namespace information, and resource objects corresponding to the service mesh from the virtual cluster and distributes them to all service mesh sidecars in the first and second managed clusters, so that the traffic agents in the sidecars can implement the corresponding functions.

[0112] Taking Istio as the service mesh and a virtual Kubernetes cluster as the virtual cluster as an example, Istio deployed in the first managed cluster accesses the API-Server component of the virtual cluster through its control plane component Pilot, obtains the aggregated service information and namespace information stored in the ETCD component of the virtual cluster, and the resource objects corresponding to the service mesh, and sends them to all service mesh sidecars in the first and second managed clusters.

[0113] In some embodiments, the resource objects corresponding to the service grid include governance policy resource objects; the governance policy resource objects are used to define the service governance rules of the service grid; correspondingly, the control plane component of the service grid reads the service information, namespace information and resource objects corresponding to the service grid from the virtual cluster, and distributes them to all service grid side cars in the first managed cluster and the second managed cluster, specifically: the control plane component of the service grid reads the service information, namespace information and service grid service governance rules from the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster; the control plane component of the service grid directly distributes the service information, namespace information and service grid service governance rules to all service grid side cars in the first managed cluster, and distributes them to all service grid side cars in the second managed cluster through the proxy component in the second managed cluster.

[0114] It should be understood that there may be multiple resource objects corresponding to the service grid in the embodiment of the present application. The governance policy resource object is a resource object used to define the service governance rules of the service grid. In addition, it may also include resource objects used to record the access methods and access rights of all managed clusters. The embodiment of the present application does not limit this.

[0115] A service mesh's service governance rules are the rules used by the service mesh's control plane to uniformly manage and configure all services. Once configured, the service mesh's control plane distributes these rules to each service mesh sidecar, which then executes them when processing traffic, enabling capabilities like load balancing, circuit breaking, rate limiting, call chain tracing, and fault injection.

[0116] It should be noted that after the control plane components of the service mesh are deployed in the first managed cluster, the control plane components of the service mesh can directly distribute service governance rules to the service mesh sidecar in the first managed cluster to manage the service mesh sidecar in the first managed cluster. If other clusters outside the first managed cluster (such as the second managed cluster) want to host the data plane of the deployed service mesh to the control plane components of the service mesh deployed in the first managed cluster, they must first perform a series of settings to enable communication with the underlying network of the first managed cluster. For example, they must deploy east-west traffic gateways (such as EgressGateway and IngressGateway components) in the second managed cluster or the first managed cluster and set mutual access permissions. Then, they must make corresponding settings in the service mesh configuration file of the second managed cluster, such as specifying the service mesh identifier and IP address of the second managed cluster, so that the control plane components of the service mesh in the first managed cluster can determine the access path of the second managed cluster. Subsequently, they must deploy a proxy component in the second managed cluster to interact with the control plane components of the service mesh in the first managed cluster through the proxy component.

[0117] The proxy component is an agent of the control plane component of the service mesh in the managed cluster. It runs in each managed cluster outside the first managed cluster (such as the second managed cluster) and is responsible for receiving the governance policy from the service mesh control plane component of the first managed cluster and distributing it to all service mesh sidecars in the managed cluster so that the distributed governance policy can be executed by the service mesh sidecars. It should be noted that in the scenario where the data plane of the service mesh deployed in the second managed cluster is hosted by the control plane component of the service mesh deployed in the first managed cluster, even if the control plane component and service governance rules of the service mesh are deployed in the second managed cluster, the service mesh sidecar in the second managed cluster will not be managed by the control plane component of the service mesh in the second managed cluster. It only executes the service governance rules issued by the control plane component of the service mesh in the first managed cluster through the proxy component.

[0118] Based on this, for the first managed cluster, since the control plane component of the service grid is deployed in the first managed cluster, it can access the unified access interface of the virtual cluster to read the service information, namespace information and service grid service governance rules from the distributed key-value pair storage database of the virtual cluster, and directly send the read service information, namespace information and service grid service governance rules to all service grid side cars in the first managed cluster; for the second managed cluster, the service information, namespace information and service grid service governance rules stored in the distributed key-value pair storage database of the virtual cluster cannot be directly sent by the service grid control plane component to the service grid side car in the second managed cluster, but are first sent to the proxy component of the second managed cluster, and then sent to all service grid side cars in the second managed cluster through the proxy component in the second managed cluster.

[0119] Furthermore, the service governance rules of the service grid include routing rules for the first service. The control plane component of the service grid sends the service information, namespace information and service governance rules of the service grid to all service grid sidecars in the first managed cluster and the second managed cluster, including: sending the service information and namespace information corresponding to the first service to all service grid sidecars in the first managed cluster and the second managed cluster; sending the routing rules of the first service to the service grid sidecars of all service instances corresponding to the first service in the first managed cluster and the second managed cluster.

[0120] It's important to note that in cloud-native platforms, a service is a resource that provides a single, unchanging access point for a group of functionally identical containers. When a container group has a label specified by a service selector, it becomes a member of the service, and the application instances running within the container group are referred to as service instances. When a service is created, the selector in the service configuration file determines the relationship between the service and the container group. Since service instances run within container groups, once the relationship between the service and the container group is established, the relationship between the service and the service instance is also determined.

[0121] In an embodiment of the present application, the first service is any service managed by the service grid, and the service grid control plane component sends the service information and namespace information corresponding to the first service to all service grid sidecars in the first managed cluster and the second managed cluster, so that all access requests for the first service can be routed to all service instances corresponding to the first service in the first managed cluster and the second managed cluster. On this basis, the service grid also supports setting special service governance rules for the first service, that is, the service governance rules of the service grid include routing rules for the first service, and by sending the routing rules of the first service to the service grid sidecars of all service instances corresponding to the first service in the first managed cluster and the second managed cluster, the service grid can further refine the access traffic of the first service, for example, enable access authentication for the first service, so that the first service only allows designated services to initiate access to it, and processes access requests from other services other than the designated service, including intercepting, discarding, or forwarding them to a designated location.

[0122] In an embodiment of the present application, by including the routing rules of the first service in the service governance rules of the service grid, the service grid can perform customized management of its traffic based on the special business needs of the first service, thereby improving the flexibility and applicability of service grid governance.

[0123] In practice, the status of services and namespaces in each managed cluster, as well as the resource objects corresponding to the service grid, will continue to change with the operation of the business system. To this end, in some embodiments, the method also includes: the control plane component of the service grid monitors changes in service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively; in response to monitoring changes in service information or namespace information, the service information or namespace information stored in the virtual cluster is updated; in response to monitoring changes in resource objects corresponding to the service grid, the control plane component of the service grid updates the resource objects corresponding to the service grid stored in the virtual cluster; the control plane component of the service grid sends the updated service information, namespace information or resource objects corresponding to the service grid to all service grid sidecars in the first managed cluster and the second managed cluster.

[0124] In an embodiment of the present application, the control plane component of the service grid can continuously monitor changes in service information and namespace information, as well as changes in resource objects corresponding to the service grid, from the unified access interface of each managed cluster. When changes in service information or namespace information are monitored, the control plane component of the service grid updates the service information or namespace information stored in the virtual cluster to achieve real-time synchronization of service information or namespace information in the first managed cluster and the second managed cluster in the virtual cluster; when it is monitored that the administrator has made changes to the resource objects corresponding to the service grid through the unified access interface, the control plane component of the service grid updates the resource objects corresponding to the service grid stored in the virtual cluster accordingly, and sends the updated service information, namespace information or resource objects in the virtual cluster to all service grid sidecars of each managed cluster.

[0125] Taking the example of Istio as the service mesh and a virtual Kubernetes cluster as the virtual cluster, Istio deployed in the first managed cluster can monitor changes in the API-Server component of the first and second managed clusters, as well as Istio's corresponding resource objects, through its control plane component, the Pilot. These changes include the addition, deletion, or modification of services, namespaces, and resource objects. Upon detecting changes in services or namespaces in the first and second managed clusters, the Pilot accesses the API-Server component of the virtual cluster to update the aggregated service or namespace information persistently stored in the ETCD component of the virtual cluster. Upon detecting changes in resource objects corresponding to the service mesh, the Pilot accesses the API-Server component of the virtual cluster to update the Istio corresponding resource objects persistently stored in the ETCD component of the virtual cluster. It should be understood that regardless of whether service information, namespace information, or resource objects are updated, the Pilot must distribute the updated service information, namespace information, or resource objects to all service mesh sidecars.

[0126] In this way, the updated service information, namespace information or service governance rules of the service grid are automatically and timely synchronized to the service grid sidecar, which enhances the availability of the service grid and avoids access errors caused by asynchronous service governance rules.

[0127] In summary, in the technical solution of the present application, the control plane component of the service grid is first deployed in the first managed cluster, wherein the first managed cluster is any one of the multiple managed clusters managed by the control plane component of the service grid. Subsequently, a virtual cluster is run in the first managed cluster. Then, the control plane component of the service grid obtains the service information and namespace information of each cluster through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster. By monitoring the event that the resource object corresponding to the service grid is created, the resource object corresponding to the created service grid is stored in the virtual cluster. In this way, the service information, namespace information and resource objects corresponding to the service grid of all managed clusters are uniformly stored in the virtual cluster of a certain managed cluster, so that the data information stored in the virtual cluster is isolated from the data information of the managed cluster itself, avoiding pollution of the data information of the managed cluster itself.

[0128] In addition, the control plane component of the service grid aggregates the data information of all managed clusters and stores it in the virtual cluster. When the service grids of all managed clusters are uniformly governed, the control plane component reads the above content stored in the virtual cluster and sends it to all service grid sidecars in all managed clusters, thereby realizing the unified management of multi-cluster service grids, reducing the workload of service grid operation and maintenance, and improving the work efficiency of multi-cluster administrators.

[0129] In this application, since the service information and namespace information managed by the service grid and the corresponding resource objects of the service grid are isolated in the virtual cluster, the control plane components of the service grid can freely manage the data plane of the service grid deployed in clusters of different cloud environments, thereby realizing unified management of multi-cloud environment and multi-cluster service grids.

[0130] In the technical solution of the present application, the virtual cluster is run in the first managed cluster. Users do not need to add additional hardware equipment for the deployment of the control plane components of the service grid, and can achieve unified management of the data plane of the multi-cloud environment and multi-cluster service grid, thereby reducing costs.

[0131] Exemplary Systems

[0132] The present application also provides a service grid hosting system based on a cloud native platform, such as Figure 3 、 Figure 5 As shown, the control plane component of the service grid is deployed in a first managed cluster, which is any one of multiple managed clusters managed by the control plane component of the service grid. The system includes: an operation unit 501, a first storage unit 502, a second storage unit 503, and a sending unit 504.

[0133] The running unit 501 is configured to run a virtual cluster in a first managed cluster.

[0134] The first storage unit 502 is configured as a control plane component of the service grid to obtain service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and store the obtained service information and namespace information in the virtual cluster.

[0135] The second storage unit 503 is configured to, in response to monitoring that a resource object corresponding to the service grid is created, store the resource object corresponding to the service grid in the virtual cluster by the control plane component of the service grid.

[0136] The sending unit 504 is configured as a control plane component of the service grid to read service information, namespace information and resource objects corresponding to the service grid from the virtual cluster, and send them to all service grid sidecars in the first managed cluster and the second managed cluster.

[0137] The service grid hosting system based on a cloud-native platform provided in the embodiments of the present application can implement the processes and steps of the service grid hosting method based on a cloud-native platform provided in any of the above embodiments and achieve the same technical effects, which will not be repeated here.

[0138] Exemplary devices

[0139] Figure 6 Schematic diagram of the structure of an electronic device according to some embodiments of the present application; Figure 6 As shown, the electronic device includes:

[0140] One or more processors 601;

[0141] The computer-readable medium can be configured to store one or more programs 602. When one or more processors 601 execute the one or more programs 602, the following steps are implemented: a virtual cluster is run in the first managed cluster; the control plane component of the service grid obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster; in response to monitoring that the resource object corresponding to the service grid is created, the control plane component of the service grid stores the resource object corresponding to the service grid in the virtual cluster; the control plane component of the service grid reads the service information, namespace information and the resource object corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster.

[0142] Figure 7 The hardware structure of the electronic device provided according to some embodiments of the present application; Figure 7As shown, the hardware structure of the electronic device may include: a processor 701 , a communication interface 702 , a computer-readable medium 703 and a communication bus 704 .

[0143] The processor 701 , the communication interface 702 , and the computer-readable storage medium 703 communicate with each other via a communication bus 704 .

[0144] Optionally, the communication interface 702 may be an interface of a communication module, such as an interface of a GSM module.

[0145] Among them, the processor 701 can be specifically configured to: run a virtual cluster in the first managed cluster; the control plane component of the service grid obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster; in response to monitoring that the resource object corresponding to the service grid is created, the control plane component of the service grid stores the resource object corresponding to the service grid in the virtual cluster; the control plane component of the service grid reads the service information, namespace information and the resource object corresponding to the service grid from the virtual cluster, and sends it to all service grid sidecars in the first managed cluster and the second managed cluster.

[0146] The processor 701 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., and may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of this application may be implemented or executed. The general-purpose processor may be a microprocessor or any conventional processor.

[0147] The electronic devices of the embodiments of the present application exist in various forms, including but not limited to:

[0148] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and are primarily designed to provide voice and data communications. These terminals include smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones.

[0149] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0150] (3) Portable entertainment devices: These devices can display and play multimedia content. These devices include audio and video players (e.g., iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0151] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0152] (5) Other electronic devices with data interaction functions.

[0153] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0154] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as computer code originally stored in a remote recording medium or a non-temporary machine storage medium downloaded via a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the service grid hosting method based on a cloud native platform described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0155] Those skilled in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of this application.

[0156] It should be noted that the various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device and system embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant parts, refer to the descriptions of the method embodiments.

[0157] The device and system embodiments described above are merely illustrative. Units described as separate components may or may not be physically separate, and components described as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of these modules may be selected based on actual needs to achieve the objectives of the present embodiments. Persons of ordinary skill in the art will be able to understand and implement the present embodiments without inventive effort.

[0158] The foregoing description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are readily apparent to those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A service grid hosting method based on a cloud native platform, characterized in that: The control plane component of the service grid is deployed in a first managed cluster, where the first managed cluster is any one of a plurality of managed clusters managed by the control plane component of the service grid, and the method includes: running a virtual cluster in the first managed cluster; The control plane component of the service grid obtains service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and stores the obtained service information and namespace information in the virtual cluster; In response to monitoring that a resource object corresponding to the service grid is created, the control plane component of the service grid stores the resource object corresponding to the service grid in the virtual cluster; The control plane component of the service grid reads the service information, the namespace information, and the resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster; The running of the virtual cluster in the first managed cluster specifically includes: Creating a container group in the first managed cluster; the container group includes a plurality of containers, and the containers are used to simulate nodes in the virtual cluster; Running a system initialization process in the container; the system initialization process is used to host the Kubelet component and container runtime in the node, and the Kubelet component is used to run components in the virtual cluster; The components in the virtual cluster include a unified access interface and a distributed key-value pair storage database. The control plane component of the service grid stores the resource objects corresponding to the service grid in the virtual cluster, specifically: The control plane component of the service grid persistently stores the resource objects corresponding to the service grid in the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster.

2. The service grid hosting method based on a cloud native platform according to claim 1, characterized in that: The resource objects corresponding to the service grid include a governance policy resource object; the governance policy resource object is used to define the service governance rules of the service grid; Correspondingly, the control plane component of the service grid reads the service information, the namespace information, and the resource objects corresponding to the service grid from the virtual cluster, and sends them to all service grid sidecars in the first managed cluster and the second managed cluster, specifically: The control plane component of the service grid reads the service information, the namespace information and the service governance rules of the service grid from the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster; The control plane component of the service grid directly sends the service information, the namespace information, and the service governance rules of the service grid to all service grid sidecars in the first managed cluster, and sends them to all service grid sidecars in the second managed cluster through the proxy component in the second managed cluster.

3. The service grid hosting method based on a cloud native platform according to claim 2, characterized in that: The storing the acquired service information and namespace information in the virtual cluster includes: In response to both the first managed cluster and the second managed cluster including a first namespace, aggregating service information in the first namespace in the first managed cluster and the first namespace in the second managed cluster; In response to the first namespace in the first managed cluster and the first namespace in the second managed cluster both including a first service, aggregating service information corresponding to the first service; The service information and namespace information corresponding to the aggregated first service are stored in the virtual cluster.

4. The service grid hosting method based on a cloud native platform according to claim 3, characterized in that: The service governance rules of the service grid include routing rules for the first service. The control plane component of the service grid distributes the service information, the namespace information, and the service governance rules of the service grid to all service grid sidecars in the first managed cluster and the second managed cluster, including: Send the service information and namespace information corresponding to the first service to all service mesh sidecars in the first managed cluster and the second managed cluster; The routing rules of the first service are distributed to the service mesh sidecars of all service instances corresponding to the first service in the first managed cluster and the second managed cluster.

5. The service grid hosting method based on a cloud native platform according to any one of claims 1 to 4, characterized in that: The method further comprises: The control plane component of the service grid monitors changes in the service information and the namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively; In response to monitoring a change in the service information or the namespace information, updating the service information or the namespace information stored in the virtual cluster; In response to monitoring a change in a resource object corresponding to the service grid, the control plane component of the service grid updates the resource object corresponding to the service grid stored in the virtual cluster; The control plane component of the service grid sends the updated service information, the namespace information, or the resource object corresponding to the service grid to all service grid sidecars in the first managed cluster and the second managed cluster.

6. A service grid hosting system based on a cloud native platform, characterized in that: The control plane component of the service grid is deployed in a first managed cluster, where the first managed cluster is any one of a plurality of managed clusters managed by the control plane component of the service grid. The system includes: an operating unit configured to operate a virtual cluster in the first managed cluster; a first storage unit configured as a control plane component of the service grid to obtain service information and namespace information through the unified access interface of the first managed cluster and the second managed cluster respectively, and store the obtained service information and namespace information in the virtual cluster; a second storage unit, configured to, in response to monitoring that a resource object corresponding to a service grid is created, store the resource object corresponding to the service grid in the virtual cluster by the control plane component of the service grid; a sending unit, configured as a control plane component of the service grid, reading the service information, the namespace information, and the resource objects corresponding to the service grid from the virtual cluster, and sending the information to all service grid sidecars in the first managed cluster and the second managed cluster; The running of the virtual cluster in the first managed cluster specifically includes: Creating a container group in the first managed cluster; the container group includes a plurality of containers, and the containers are used to simulate nodes in the virtual cluster; Running a system initialization process in the container; the system initialization process is used to host the Kubelet component and container runtime in the node, and the Kubelet component is used to run components in the virtual cluster; The components in the virtual cluster include a unified access interface and a distributed key-value pair storage database. The control plane component of the service grid stores the resource objects corresponding to the service grid in the virtual cluster, specifically: The control plane component of the service grid persistently stores the resource objects corresponding to the service grid in the distributed key-value pair storage database of the virtual cluster by accessing the unified access interface of the virtual cluster.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the service grid hosting method based on a cloud native platform are implemented.

8. An electronic device, characterized in that: include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the service grid hosting method based on a cloud native platform are implemented as described in any one of claims 1 to 5.

Images