Cross-cluster application access method, gateway apparatus, and related product

Abstract

The present application provides a cross-cluster application access method, a gateway apparatus, and a related product, capable of realizing communication between cross-cluster applications and reducing the resource occupation of a network proxy component in a cluster. The method is applied to a multi-cluster system, the multi-cluster system comprises an application layer gateway, a first K8s cluster and a second K8s cluster, the first K8s cluster comprises a network proxy component and a first application, and the second K8s cluster comprises a second application. Specifically, the network proxy component intercepts an access request sent by the first application, and forwards the access request on the basis of a routing rule matching the request. When the routing rule instructs to perform application layer processing on the access request, the access request is sent to the application layer gateway, so that the application layer gateway performs application layer processing on the access request, and forwards the processed access request to the second application. When the routing rule instructs to perform transport layer processing on the access request, the access request is sent to the second application.

Description

A method for cross-cluster application access, a gateway device, and related products

[0001] This application claims priority to Chinese Patent Application No. 202411595027.X, filed on November 8, 2024, entitled "A method for cross-cluster application access, gateway device and related products", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of cloud computing technology, and in particular to a cross-cluster application access method, gateway device, and related products. Background Technology

[0003] In cloud computing scenarios, enterprises typically use Kubernetes (K8s) clusters to deploy applications. When different applications are deployed on different clusters, there may be a need for cross-cluster access of applications.

[0004] Currently, cross-cluster access for applications can be achieved using Istio. The following example illustrates the existing solution, using application A in cluster A wanting to access application B in cluster B: When application A wants to access application B, the access request from application A can reach application B via application A's network proxy component (Envoy) and application B's Envoy. Since one Envoy is dedicated to communication for one application, this solution requires configuring one Envoy for each application running on the cluster. Understandably, the more applications running on the cluster, the more Envoys need to be configured, leading to a significant amount of cluster resources being consumed by Envoys. Summary of the Invention

[0005] This application provides a cross-cluster application access method, gateway device, and related products, which can realize communication between cross-cluster applications and reduce the resource consumption of network proxy components in K8s clusters.

[0006] Firstly, this application provides a method for cross-cluster application access. This method can be applied to a multi-cluster system, which includes an application-layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. A first application runs on the first Kubernetes cluster, and a second application runs on the second Kubernetes cluster. The first Kubernetes cluster also includes a network proxy component. Specifically, the network proxy component intercepts access requests from the first application and then forwards the access request according to a target routing rule matching the access request. Specifically, when the target routing rule indicates that application-layer processing should be performed on the access request, the network proxy component sends the access request to the application-layer gateway, so that the application-layer gateway performs application-layer processing on the access request and forwards the processed access request to the second application. When the target routing rule indicates that transport-layer processing should be performed on the access request, the network proxy component sends the access request to the second application. Here, application-layer processing refers to the processing performed on the access request at the application layer, and transport-layer processing refers to forwarding the access request to the second application based on a transport-layer protocol.

[0007] In the technical solution provided in this application, the network proxy component can intercept access requests issued by a local first application and forward the access requests. During the forwarding process, the network proxy component can determine the forwarding method of the access request based on the target routing rules matching the access request. Specifically, if application-layer processing of the access request is required, the network proxy component needs to send the access request to the application-layer gateway, which then performs application-layer processing and forwards the access request to the second application. If only the access request needs to be transmitted to the second application, the network proxy component can directly send the access request to the second application. It can be seen that in the above solution, the network proxy component can proxy Layer 4 traffic, and the application-layer gateway can proxy Layer 7 traffic. This means that the resources consumed by the network proxy component in the Kubernetes cluster are reduced.

[0008] In one possible implementation, the network proxy component also intercepts and forwards access requests from a third application running on the first Kubernetes cluster.

[0009] Through the above implementation, the network proxy component can achieve Layer 4 traffic proxy for multiple applications (including the first application and the third application) on the first Kubernetes cluster. In other words, using the above solution, it is not necessary to deploy a network proxy component for each application running on the first Kubernetes cluster, thus reducing the resource consumption of the network proxy component in the first Kubernetes cluster.

[0010] In one possible implementation, the multi-cluster system further includes a control component, and the first Kubernetes cluster further includes a control proxy component. Before the network proxy component forwards the access request according to the target routing rule matching the access request, the control proxy component receives at least one routing rule pushed by the control component and sends the at least one routing rule, including the target routing rule, to the network proxy component. Therefore, the network proxy component forwards the access request according to the target routing rule matching the access request, including the following steps: the network proxy component determines the target routing rule from the at least one routing rule based on the destination Internet Protocol (IP) address of the access request, wherein the target routing rule includes the destination IP address.

[0011] In one possible implementation, before the network proxy component sends the access request to the second application, the control proxy component receives service information of the second application pushed by the control component and sends this service information to the network proxy component. The service information of the second application includes the IP address and port information of the container application deployment unit (Pod) where the second application resides. Therefore, the network proxy component sends the access request to the second application by means of the following steps: the network proxy component sends the access request to the second application based on the IP address and port information of the Pod where the second application resides.

[0012] Through the above implementation, the network proxy component can directly deliver access requests from the first application to the second application in the second Kubernetes cluster, reducing the number of network address translation (NAT) operations in the second Kubernetes cluster, thereby reducing the switching between user mode and kernel mode. Therefore, it can improve the forwarding efficiency of access requests and reduce access latency.

[0013] In one possible implementation, when the target routing rule indicates that application-layer processing should be performed on the access request, the application-layer gateway also receives the target routing rule pushed by the control component. Therefore, the application-layer gateway performs application-layer processing on the access request, including the following steps: the application-layer gateway performs application-layer processing on the access request according to the target routing rule.

[0014] In one possible implementation, when the target routing rule instructs application-layer processing to be performed on the access request, the application-layer gateway also receives service information of a second application pushed by the control component. Therefore, the application-layer gateway forwards the processed access request to the second application, including the following steps: the application-layer gateway sends the access request to the second application based on the IP address and port information of the Pod where the second application resides.

[0015] Secondly, this application provides a gateway device. This gateway device is applied to a multi-cluster system, which includes an application-layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. A first application runs on the first Kubernetes cluster, and a second application runs on the second Kubernetes cluster. The first Kubernetes cluster also includes a network proxy component. Specifically, the network proxy component intercepts access requests from the first application and then forwards the access requests according to a target routing rule matching the access request. Specifically, when the target routing rule indicates that application-layer processing should be performed on the access request, the network proxy component sends the access request to the application-layer gateway, so that the application-layer gateway performs application-layer processing on the access request and forwards the processed access request to the second application. When the target routing rule indicates that transport-layer processing should be performed on the access request, the network proxy component sends the access request to the second application. Here, application-layer processing refers to the processing performed on the access request at the application layer, and transport-layer processing refers to forwarding the access request to the second application based on a transport-layer protocol.

[0016] In one possible implementation, the network proxy component is also used to intercept access requests from a third application and forward those requests, wherein the third application runs on the first Kubernetes cluster.

[0017] In one possible implementation, the multi-cluster system further includes a control component, and the aforementioned gateway device further includes a control proxy component, which is deployed on the first Kubernetes cluster. The control proxy component receives at least one routing rule pushed by the control component and sends the at least one routing rule to the network proxy component, wherein the at least one routing rule includes a target routing rule. The network proxy component determines the target routing rule from the at least one routing rule based on the destination IP address of the access request, wherein the target routing rule includes the destination IP address.

[0018] In one possible implementation, the control proxy component is further configured to receive service information of the second application pushed by the control component, and send the service information of the second application to the network proxy component. The service information of the second application includes the IP address and port information of the Pod where the second application resides. The network proxy component then sends access requests to the second application based on the IP address and port information of the Pod where the second application resides.

[0019] In one possible implementation, when the target routing rule indicates that application-layer processing should be performed on the access request, the application-layer gateway is used to receive the target routing rule pushed by the control component and perform application-layer processing on the access request according to the target routing rule.

[0020] In one possible implementation, when the target routing rule instructs that application-layer processing be performed on the access request, the application-layer gateway receives service information of the second application pushed by the control component, and sends the access request to the second application based on the IP address and port information of the Pod where the second application resides.

[0021] Thirdly, this application provides a multi-cluster system. The multi-cluster system includes an application layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. A first application runs on the first Kubernetes cluster, and a second application runs on the second Kubernetes cluster. The first Kubernetes cluster also includes a network proxy component. The network proxy component intercepts access requests issued by the first application and forwards the access requests according to a target routing rule matching the access request. Specifically, when the target routing rule indicates that application layer processing should be performed on the access request, the network proxy component sends the access request to the application layer gateway, so that the application layer gateway performs application layer processing on the access request and forwards the processed access request to the second application. When the target routing rule indicates that transport layer processing should be performed on the access request, the network proxy component sends the access request to the second application. Application layer processing refers to the processing performed on the access request at the application layer, and transport layer processing refers to forwarding the access request to the second application based on a transport layer protocol.

[0022] Fourthly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, causing the computing device cluster to perform some or all of the methods described in the first aspect and any implementation thereof.

[0023] Fifthly, this application provides a computer program product containing instructions. This computer program product may be a software or program product containing instructions that can run on a computing device or be stored on any usable medium. When the computer program product is run on a computing device, it causes the computing device to perform some or all of the methods described in the first aspect and any implementation thereof.

[0024] Sixthly, this application provides a computer-readable storage medium. The computer storage medium includes computer program instructions that, when executed by a computing device, cause the computing device to perform some or all of the methods described in the first aspect and any implementation thereof. Attached Figure Description

[0025] Figure 1 is a schematic diagram of the structure of a multi-cluster system provided in this application;

[0026] Figure 2 is a flowchart illustrating a cross-cluster application access method provided in this application;

[0027] Figure 3 is a flowchart illustrating the process of a network proxy component forwarding access requests provided in this application;

[0028] Figure 4 is a flowchart illustrating the process of another network proxy component providing this application forwarding access requests;

[0029] Figure 5 is a schematic diagram of a gateway device provided in this application;

[0030] Figure 6 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0031] Figure 7 is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0032] To address the issue of excessive resource consumption by network proxy components in Kubernetes clusters during cross-cluster application access scenarios, this application provides a cross-cluster application access method. This method can be applied to multi-cluster systems. A multi-cluster system includes multiple Kubernetes clusters, each with a network proxy component deployed on its compute nodes. This network proxy component performs Layer 4 traffic proxying for applications. The multi-cluster system also includes an application-layer gateway, which performs Layer 7 traffic proxying for applications. Specifically, when an application in one Kubernetes cluster (let's say cluster A) wants to access an application in another Kubernetes cluster (let's say cluster B), if only traffic forwarding is required, the access request from the application in cluster A can be directly forwarded to the application in cluster B via the network proxy component in cluster A. However, if application-layer processing is required, the network proxy component in cluster A, after intercepting the access request, must first forward it to the application-layer gateway for processing, and then the application-layer gateway forwards the processed access request to the application in cluster B. As can be seen, the above solution decouples Layer 4 and Layer 7 traffic governance. Specifically, the network proxy component in the Kubernetes cluster only needs to implement Layer 4 traffic governance, reducing its resource consumption. Furthermore, since each compute node in the Kubernetes cluster is configured with one network proxy component, applications running in all Pods on that compute node can use that network proxy component for Layer 4 traffic governance, reducing the number of network proxy components in the Kubernetes cluster and consequently reducing their resource consumption.

[0033] Referring to Figure 1, Figure 1 shows a schematic diagram of the structure of a multi-cluster system provided in this application. As shown in Figure 1, the system includes a control component 100 and multiple clusters 200. For ease of description, only two clusters 200 are shown in Figure 1 (displayed as cluster 200A and cluster 200B). Optionally, this scenario may also include an application layer gateway 300. These components are described in detail below.

[0034] (1) Control component 100

[0035] The control component 100 is connected to both the cluster 200 and the application layer gateway 300 via a network, which can be a wide area network (WAN) or a local area network (LAN). The control component 100 is used to discover applications running on the cluster 200 and manage traffic between applications in different clusters 200, enabling applications in different clusters 200 to discover and access each other. Specifically, the control component 100 can be deployed on a single computing device or a cluster of computing devices, where the computing device can be a server or a virtual machine.

[0036] As one possible implementation, the control component 100 can be implemented using Istio's control plane components, where Istio's control plane components refer to the components in Istio's control plane used for service discovery and traffic management functions.

[0037] (2) Cluster 200

[0038] Cluster 200 is a Kubernetes cluster used to manage and run applications. Cluster 200 includes a control node 210 and compute nodes 220, with multiple compute nodes 220 typically present. In practice, the control node 210 and compute nodes 220 can be servers or virtual machines.

[0039] Control node 210 is used to control and manage the scheduling of resources and the execution of tasks in cluster 200, such as managing resources on compute node 220 and allocating applications to the node based on the resource usage on compute node 220.

[0040] The control node 210 may include an API service component 211. The API service component 211 is a component that provides a management interface (i.e., a REST interface) to the outside world for the cluster 200. As shown in Figure 1, the API service component 211 interfaces with the control component 100. The API service component 211 can obtain service information of the applications running on the compute node 220 and provide the service information of the applications running on the compute node 220 to the control component 100.

[0041] Compute node 220 includes one or more Pods 221. For ease of description, only one Pod 221 is shown in Figure 1. Pod 221 encapsulates one or more containers, storage resources, an independent network IP, and policy options for managing and controlling how the containers run. One or more applications can run on the containers in Pod 221. For ease of description, only one application is shown in Figure 1.

[0042] Compute node 220 also includes a control proxy component 222. As shown in Figure 1, the control proxy component 222 interfaces with the control component 100. The control component 100 can push service information of applications running on other clusters 200, as well as the routing rules associated with these applications, to the control proxy component 222. As one possible implementation, the control proxy component 222 can be implemented using an Istio control plane proxy component. This Istio control plane proxy component refers to a component in the Istio control plane used to collaborate with the control plane component to obtain service information and routing rules of applications running on other clusters.

[0043] The compute node 220 also includes a network proxy component 223. The network proxy component 223 is used to implement transport layer traffic proxying for applications. Specifically, when a local application wants to access an application in another cluster 200, the network proxy component 223 can intercept the access request issued by the local application and forward the access request to the desired application in another cluster 200 according to the routing rules obtained from the control proxy component 222, or forward it to the desired application in another cluster 200 via the application layer gateway 300.

[0044] (3) Application Layer Gateway 300

[0045] The application layer gateway 300 is used to perform application layer processing and forwarding of traffic between cross-cluster applications. In specific implementations, the application layer gateway 300 can be deployed on a single computing device or a cluster of computing devices consisting of multiple computing devices, which can be servers or virtual machines.

[0046] Application layer gateway 300 may include control proxy component 310. As shown in Figure 1, control proxy component 310 interfaces with control component 100, and control component 100 can push application service information and application-related routing rules to control proxy component 310. As a possible implementation, similar to control proxy component 222, control proxy component 310 can also be implemented using Istio's control proxy component.

[0047] The application layer gateway 300 also includes a network proxy component 320. The network proxy component 320 is used to proxy application layer traffic for applications. Specifically, the network proxy component 320 can receive access requests sent by the network proxy component 223, perform application layer processing on the access requests (such as load balancing, security authentication, circuit breaking, rate limiting, etc.), and forward the access requests to applications in other clusters 200. As one possible implementation, the network proxy component 320 can be implemented using Istio's Envoy component.

[0048] Optionally, the application layer gateway 300 may also include multiple virtual routing forwarding (VRF) instances 330. The VRF instances 330 are used to isolate traffic from different clusters 200. Specifically, traffic from clusters 200A and 200B can reach the network proxy component 320 for processing and forwarding via different VRF instances 330.

[0049] Next, taking the example of an application in cluster 200A (hereinafter referred to as "Application A") accessing an application in cluster 200B (hereinafter referred to as "Application B"), the cross-cluster application access method provided in this application will be described in detail. See Figure 2 for details. As shown in Figure 2, Application A can access Application B through the following steps:

[0050] Step 101: Control component 100 obtains service information of application B through API service component 211 (hereinafter referred to as "API service component 211B") in cluster 200B.

[0051] Application B's service information refers to information related to the services provided by application B, which may include the name, IP address, and port information of the services provided by application B, as well as the name, IP address, and port information of the Pod 221 where application B resides.

[0052] In a specific implementation, the control component 100 can instruct the API service component 211B to monitor changes in applications on the control node 210 in the cluster 200B, such as application creation, deletion, or updates, and send the identified changes to the control component 100. Therefore, when the API service component 211B detects the creation of application B, it will send the service information of application B to the control component 100, thereby enabling the control component 100 to obtain the service information of application B.

[0053] Step 102: Control component 100 obtains the target routing rules.

[0054] The destination routing rule describes how to access application B. The destination routing rule can include the name of the service provided by application B, the destination IP address, and the destination port information. The destination IP address refers to the IP address used to indicate where traffic will reach application B in a cross-cluster access scenario, and the destination port information refers to the port information used to indicate where traffic will reach application B in a cross-cluster access scenario. In other words, application B can be accessed across clusters based on the destination IP address and destination port information.

[0055] Destination routing rules may also include identification information, which indicates the type of the destination routing rule. Destination routing rules can be of two types: transport layer routing rules and application layer routing rules. Specifically:

[0056] Transport layer routing rules are routing rules defined at the transport layer, used to instruct traffic accessing application B to undergo transport layer processing. Transport layer processing refers to forwarding traffic accessing application B to application B based on a transport layer protocol (such as Transmission Control Protocol (TCP)). Therefore, for scenarios where only traffic accessing application B needs to be forwarded to application B (such as database queries, file transfers, etc.), the target routing rule can be configured as a transport layer routing rule.

[0057] Application-layer routing rules are routing rules defined at the application layer to instruct application-layer processing to be performed on traffic accessing application B. Application-layer processing refers to the actions taken at the application layer to process traffic accessing application B. Specifically, application-layer routing rules can be used to parse request content related to application-layer protocols (such as Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), and Remote Procedure Call (RPC)) from traffic accessing application B, and then perform application-layer processing and forwarding on the parsed request content. Therefore, for scenarios requiring application-layer processing based on traffic accessing application B (such as security protection and high-concurrency access scenarios), the target routing rule can be configured as an application-layer routing rule.

[0058] In addition to the content described above (i.e., the name of the service provided by application B, the target IP address, and the target port information), application layer routing rules can also include service certificates and application layer processing rules. A service certificate is a digital certificate used to ensure secure communication between applications (such as a Transport Layer Security (TLS) certificate). Application layer processing rules are rules used to process the request content of application layer protocols, and may include one or more of the following: TLS termination rules, rate limiting rules, authentication rules, circuit breaking rules, timeout retry rules, and load balancing rules.

[0059] In specific implementation, the control component 100 can obtain the target routing rules through any of the following methods:

[0060] Method (1): Control component 100 receives the target routing rules configured by the user.

[0061] Specifically, the control component 100 can provide an access interface, which can be implemented through an API or a graphical user interface (GUI). Users can provide target routing rules to the control component 100 through this access interface. The control component 100 can then obtain the target routing rules.

[0062] Method (2): Control component 100 generates target routing rules.

[0063] Specifically, the control component 100 can provide a configuration page to the user, which displays configuration options related to the target routing rule. These options may include the name of the service provided by the application associated with the target routing rule, allowing the user to input the name of the service provided by application B; and the type of target routing rule, allowing the user to input the type of target routing rule. Furthermore, when the user selects an application-layer routing rule, the configuration page can also display specific application-layer processing rules for the user to choose from. After receiving the user's configuration, the control component 100 dynamically generates the target IP address and target port information, and then, combined with the name of the service provided by application B and the type of target routing rule, generates the target routing rule.

[0064] Step 103: Control component 100 pushes target routing rules and service information of application B.

[0065] In specific implementation, control component 100 can push target routing rules and application B service information based on the identification information of the target routing rule. Specifically, when the identification information of the target routing rule indicates that the target routing rule is a transport layer routing rule, control component 100 pushes the target routing rule and application B service information to control proxy component 222 (hereinafter referred to as "control proxy component 222A") in cluster 200A. When the identification information of the target routing rule indicates that the target routing rule is an application layer routing rule, control component 100 pushes the target routing rule and application B service information to control proxy component 222A and control proxy component 310 in application layer gateway 300, respectively.

[0066] More specifically, both control agent component 222A and control agent component 310 can connect to control component 100 via gRPC. Furthermore, control agent component 222A and control component 100, as well as control agent component 310 and control component 100, can communicate based on the x discovery service (xDS) protocol. The xDS protocol is a general term for a set of service discovery protocols based on different data sources, which may specifically include listener discovery service (LDS), cluster discovery service (CDS), and endpoint discovery service (EDS). Therefore, when the target routing rule is a transport layer routing rule, based on the xDS protocol, control component 100 can push the target routing rule and application B service information to control agent component 222A via gRPC. When the target routing rule is an application layer routing rule, based on the xDS protocol, control component 100 can push the target routing rule and application B service information to control agent components 222A and 310 via gRPC.

[0067] Step 104: Application A generates an access request and sends the access request.

[0068] In the specific implementation, the storage resources in the Pod where application A resides pre-store the target IP address, target port information, and the IP address and port information of the Pod where application A resides. Specifically, the target IP address and target port information can be obtained from the storage resources in the Pod where application A resides through the following method: Control component 100 allows users to view the target IP address and target port information in the target routing rules. Therefore, users can obtain the target IP address and target port information through control component 100, and then provide the target IP address and target port information to API service component 211 (hereinafter referred to as "API service component 211A") in cluster 200A via an access interface (such as API or GUI). Afterwards, API service component 211A stores the target IP address and target port information in the storage component (such as ETCD) in control node 210, and the storage component then synchronizes the target IP address and target port information to the storage resources in the Pod where application A resides.

[0069] Therefore, when application A wants to access application B, application A can obtain the target IP address, target port information, and the IP address and port information of the Pod where application A resides from the storage resources in its Pod. Then, based on the obtained information, it generates an access request and issues the aforementioned access request. This access request is for accessing application B and specifically includes the target IP address, target port information, and the IP address and port information of the Pod where application A resides. The target IP address indicates the destination IP address of the access request, the target port information indicates the destination port information of the access request, the IP address of the Pod where application A resides indicates the source IP address of the access request, and the port information of the Pod where application A resides indicates the source port information of the access request.

[0070] Step 105: The network proxy component 223 (hereinafter referred to as "network proxy component 223A") in the computing node 220 where application A is located intercepts the access request issued by application A.

[0071] In the specific implementation, since application A issues access requests by calling the operating system interface, the operating system receives the access requests from application A. After receiving the access requests, the operating system processes them. In this application, the operating system's processing flow for access requests includes the processing flow of the network proxy component 223A. Therefore, during the operating system's processing of the access requests, the network proxy component 223A is triggered to intercept the access requests. In other words, the network proxy component 223A can intercept the access requests issued by application A on the kernel path.

[0072] Step 106: Network proxy component 223A forwards the access request according to the target routing rule. When the target routing rule is a transport layer routing rule, network proxy component 223A forwards the access request to application B. When the target routing rule is an application layer routing rule, network proxy component 223A forwards the access request to application B via application layer gateway 300.

[0073] In its implementation, network proxy component 223A pre-caches at least one routing rule. This routing rule describes how to access an application in other clusters 200. Notably, the routing rules cached in network proxy component 223A can include transport layer routing rules or application layer routing rules. The aforementioned at least one routing rule includes a target routing rule. For ease of description, the process of network proxy component 223A obtaining the aforementioned at least one routing rule is described below using the target routing rule as an example: As mentioned earlier, by executing step 103, control proxy component 222A can obtain the target routing rule. Subsequently, network proxy component 223A can obtain the target routing rule from control proxy component 222A through an inter-process communication socket (Unix domain socket, UDS).

[0074] Therefore, after the network proxy component 223A intercepts the access request sent by application A, it can filter out the target routing rule from at least one pre-cached routing rule according to the target IP address in the access request, then determine the type of the target routing rule according to the identification information in the target routing rule, and then process and forward the access request according to the type of the target routing rule.

[0075] To facilitate understanding, the following will use "the target routing rule is a transport layer routing rule" and "the target routing rule is an application layer routing rule" as examples to introduce the implementation process of "the network proxy component 223A processes and forwards the above access requests according to the type of the target routing rule".

[0076] (1) When the target routing rule is a transport layer routing rule, the network proxy component 223A can process and forward the above access request through the following steps, as shown in Figure 3.

[0077] Step 1: Network proxy component 223A modifies the target IP address in the access request to the IP address of the Pod where application B is located, and modifies the target port information to the port information of the Pod where application B is located.

[0078] Specifically, network proxy component 223A pre-caches service information of applications in at least one other cluster 200. It is worth noting that the routing rules associated with the service information of the applications cached in network proxy component 223A can include transport layer routing rules or application layer routing rules. The service information of the aforementioned applications in at least one other cluster 200 includes the service information of application B. For ease of description, the process of network proxy component 223A obtaining the service information of the aforementioned applications in at least one other cluster 200 is described below using the service information of application B as an example: As mentioned above, by executing step 103, control proxy component 222A can obtain the service information of application B. Afterwards, network proxy component 223A can obtain the service information of application B from control proxy component 222A through UDS.

[0079] Therefore, when network proxy component 223A determines that the target routing rule is a transport layer routing rule, it filters the service information of application B from the pre-cached service information of at least one application in another cluster 200 based on the name of the service provided by application B in the target routing rule, thereby obtaining the IP address and port information of the Pod where application B resides. Then, network proxy component 223A modifies the target IP address in the access request to the IP address of the Pod where application B resides, and modifies the target port information to the port information of the Pod where application B resides.

[0080] Step 2: Network proxy component 223A sends the access request to application B based on the IP address and port information of the Pod where application B resides, carried in the access request. Correspondingly, application B receives the access request sent by network proxy component 223A.

[0081] (2) When the target routing rule is an application layer routing rule, the network proxy component 223A can process and forward the above access request through the following steps, as shown in Figure 4.

[0082] Step 1: Network proxy component 223A modifies the target IP address in the access request to the IP address of application layer gateway 300.

[0083] Specifically, network proxy component 223A pre-caches the IP address of application layer gateway 300. Network proxy component 223A obtains the IP address of application layer gateway 300 in the following manner: application layer gateway 300 sends its IP address to control component 100; control component 100 then pushes the IP address of application layer gateway 300 to control proxy component 222A; subsequently, network proxy component 223A obtains the IP address of application layer gateway 300 from control proxy component 222A.

[0084] Therefore, when the network proxy component 223A determines that the target routing rule is an application layer routing rule, the network proxy component 223A will modify the target IP address in the access request to the IP address of the application layer gateway 300.

[0085] Step 2: Network proxy component 223A sends the access request to application layer gateway 300 based on the IP address and target port information of application layer gateway 300 carried in the access request. Correspondingly, application layer gateway 300 receives the access request sent by network proxy component 223A.

[0086] As can be seen from step 103 above, when the target routing rule is an application layer routing rule, the control component 100 will push the target routing rule to the application layer gateway 300. After obtaining the target routing rule, the application layer gateway 300 can configure its local port according to the target port information in the target routing rule. Therefore, the network proxy component 223A sends the access request to the application layer gateway 300 according to the IP address and target port information of the application layer gateway 300 carried in the access request.

[0087] Step 3: The network proxy component 320 in the application layer gateway 300 performs application layer processing on the above access request according to the target routing rules.

[0088] Specifically, network proxy component 320 pre-caches at least one routing rule, whereby one routing rule describes how to access an application in other clusters 200. It is worth noting that the routing rule cached in network proxy component 223A is an application-layer routing rule. The aforementioned at least one routing rule includes a target routing rule. For ease of description, the process of network proxy component 320 obtaining the aforementioned at least one routing rule is described below using the target routing rule as an example: As mentioned earlier, when the target routing rule is an application-layer routing rule, the control proxy component 310 in the application-layer gateway 300 can obtain the target routing rule. Subsequently, network proxy component 320 can obtain the target routing rule from control proxy component 310 through UDS.

[0089] Therefore, after receiving the access request sent by the network proxy component 223A, the network proxy component 320 can filter out the target routing rule from at least one pre-cached routing rule according to the target IP address in the access request, and then perform application layer processing on the access request according to the target routing rule.

[0090] To facilitate understanding, the following examples illustrate the implementation process of "network proxy component 320 performing application-layer processing on the above access requests according to the target routing rules":

[0091] When the target routing rule includes a TLS termination rule, the network proxy component 320 performs a decryption operation on the access request.

[0092] When the target routing rule includes a rate limiting rule, the network proxy component 320 will determine whether the number of access requests for application B received per second exceeds the threshold. If so, it will decide to suspend sending the access request to application B.

[0093] When the target routing rule includes a security authentication rule, the network proxy component 320 verifies whether the authentication information (such as a token) in the access request is valid. If it is invalid, it determines not to send the access request to application B.

[0094] When the target routing rule includes a circuit breaker rule, the network proxy component 320 will determine whether application B is slow or has timed out. If so, it will decide to suspend sending access requests to application B.

[0095] When the target routing rule includes a timeout retry rule, the network proxy component 320 will determine whether a response from application B is received within a specified time after forwarding the access request to application B. If not, it will determine to re-forward the access request to application B until the maximum number of retries is reached.

[0096] When the target routing rule includes a load balancing rule, the network proxy component 320 will select one Pod from the multiple Pods containing application B for forwarding based on the load balancing rule (such as a weighted round-robin strategy, a least connections strategy, etc.). It should be understood that in practical applications, cluster 200B may have multiple Pods running application B. Based on the load balancing rule, a suitable Pod can be selected from these multiple Pods to enable application B to respond to application A's access more quickly.

[0097] It should be understood that the above examples only list several application layer processing rules that the target routing rule may contain, as well as the corresponding application layer processing methods. In actual applications, the target routing rule also includes other application layer processing rules (such as request modification, response modification, etc.). Accordingly, the network proxy component 320 can also perform other application layer processing on the access request, which is not limited in this application.

[0098] Step 4: The network proxy component 320 modifies the IP address of the application layer gateway 300 in the access request to the IP address of the Pod where application B is located, and modifies the target port information to the port information of the Pod where application B is located.

[0099] Specifically, network proxy component 320 pre-caches service information of applications in at least one other cluster 200. It is worth noting that the routing rules associated with the service information of the applications cached in network proxy component 320 are application-layer routing rules. The service information of the aforementioned applications in at least one other cluster 200 includes the service information of application B. For ease of description, the process of network proxy component 320 obtaining the service information of the aforementioned applications in at least one other cluster 200 is described below using the service information of application B as an example: As mentioned above, when the target routing rule is an application-layer routing rule, control proxy component 310 can obtain the service information of application B. Subsequently, network proxy component 320 can obtain the service information of application B from control proxy component 310 through UDS.

[0100] Therefore, the network proxy component 320 can filter the service information of application B from the pre-cached service information of applications in at least one other cluster 200 based on the name of the service provided by application B in the target routing rule, and thus obtain the IP address and port information of the Pod where application B resides. Then, the network proxy component 320 modifies the IP address of the application layer gateway 300 in the access request to the IP address of the Pod where application B resides, and modifies the target port information to the port information of the Pod where application B resides.

[0101] Step 5: The network proxy component 320 sends the access request to application B based on the IP address and port information of the Pod where application B resides, carried in the access request. Correspondingly, application B receives the access request sent by the network proxy component 320.

[0102] As can be seen from the description of step 106 above, when application A and application B communicate, neither application A nor application B is aware of the processing of access requests issued by application A by network proxy component 223A and application layer gateway 300. Furthermore, through this scheme, access requests from application A do not need to reach network proxy component 223 in cluster 200B, thus eliminating the need for NAT and reducing the switching between user mode and kernel mode. Therefore, it can improve the forwarding efficiency of access requests and reduce access latency.

[0103] As can be seen from the descriptions of steps 101 to 106 above, the cross-cluster application access method provided in this application can achieve the following three points: First, the network proxy component 223 in cluster 200 only needs to implement Layer 4 traffic proxy for the application (Layer 7 traffic proxy for the application is implemented by the application layer gateway 300), and one compute node 220 in cluster 200 only needs to be configured with one network proxy component 223, thus reducing the resource consumption of the network proxy component 223. Second, the multiple network proxy components 223 in cluster 200 are distributed, avoiding dependence on underlying infrastructure (such as equal-cost multi-path routing (ECMP) devices, server load balancing (SLB) devices, etc.), thereby improving flexibility, scalability, and fault tolerance. Third, it can improve the forwarding efficiency of access requests and reduce access latency.

[0104] This application also provides a gateway device. Referring to Figure 5, Figure 5 shows a schematic diagram of the gateway device provided in this application. As shown in Figure 5, the gateway device 400 includes a transport layer gateway 410 and an application layer gateway 420. The transport layer gateway 410 and the application layer gateway 420 will be described in detail below.

[0105] (1) Transport Layer Gateway 410

[0106] The transport layer gateway 410 is used to perform the steps of receiving the target routing rules and service information of application B pushed by the control component 100 (i.e., the steps performed by the control proxy component 222A), as well as the steps performed by the network proxy component 223A in steps 105 and 106 above.

[0107] In practice, the transport layer gateway 410 can be implemented in software or in hardware.

[0108] As an example of a software functional unit, the transport layer gateway 410 may include code running on compute instances. These compute instances may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned compute instances may be one or more. For example, the transport layer gateway 410 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 within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ comprising one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0109] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0110] As an example of a hardware functional unit, the transport layer gateway 410 can be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0111] As one possible implementation, the transport layer gateway 410 is a distributed gateway. Specifically, the transport layer gateway 410 may include multiple control proxy components 411 and multiple network proxy components 412. One control proxy component 411 and one network proxy component 412 can be deployed on each compute node of the Kubernetes cluster, where the control proxy component 411 is equivalent to the control proxy component 222 in Figure 1 above, and the network proxy component 412 is equivalent to the network proxy component 223 in Figure 1 above. The control proxy component 411 and the network proxy component 412 can be implemented in software, for example, including code running on a compute instance, where the compute instance may include a virtual machine or a container. The control proxy component 411 and the network proxy component 412 can also be implemented in hardware, for example, using an ASIC or a PLD.

[0112] (2) Application Layer Gateway 420

[0113] The application layer gateway 420 is used to perform the steps of receiving the target routing rules and service information of application B pushed by the control component 100 (i.e., the steps performed by the control proxy component 310), as well as the steps performed by the network proxy component 320 in step 106 above.

[0114] In practice, the application layer gateway 420 can be implemented in software or in hardware.

[0115] As an example of a software functional unit, the application layer gateway 420 may include code running on compute instances. These compute instances may include at least one of physical hosts (computing devices), virtual machines, and containers. Furthermore, the aforementioned compute instances may be one or more. For example, the application layer gateway 420 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 within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ comprising one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0116] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0117] As an example of a hardware functional unit, the application layer gateway 420 may include at least one computing device, such as a server. Alternatively, the application layer gateway 420 may be a device implemented using an ASIC or PLD.

[0118] The application layer gateway 420 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the application layer gateway 420 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the application layer gateway 420 includes multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0119] As one possible implementation, the application layer gateway 420 is a centralized gateway. The application layer gateway 420 can be further divided into a control proxy component 421 and a network proxy component 422, where the control proxy component 421 is equivalent to the control proxy component 310 in Figure 1 above, and the network proxy component 422 is equivalent to the network proxy component 320 in Figure 1 above. The control proxy component 421 and the network proxy component 422 can be implemented in software, for example, including code running on a computing instance, which may include a virtual machine or a container. The control proxy component 421 and the network proxy component 422 can also be implemented in hardware, for example, using an ASIC or a PLD.

[0120] This application also provides a computing device cluster. The computing device cluster includes at least one computing device, which may 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 in the computing device cluster may also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0121] Figure 6 exemplarily illustrates the structural diagram of the computing device cluster provided in this application. As shown in Figure 6, the computing device cluster 600 includes at least one computing device 500. The computing device 500 includes a bus 510, a communication interface 520, a processor 530, and a memory 540, wherein the communication interface 520, the processor 530, and the memory 540 communicate with each other via the bus 510. It should be understood that this application does not limit the number of processors 530 and memory 540 in the computing device 500.

[0122] Bus 510 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in Figure 6, but this does not mean that the computing device 500 has only one bus or one type of bus. Bus 510 can include pathways for transmitting information between various components of the computing device 500 (e.g., communication interface 520, processor 530, and memory 540).

[0123] The communication interface 520 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 500 and other devices or communication networks.

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

[0125] Memory 540 may include volatile memory, such as random access memory (RAM). Memory 540 may also include non-volatile memory, such as flash memory, read-only memory (ROM), hard disk drive (HDD), or solid state drive (SSD).

[0126] The memory 540 stores executable code. The processor 530 executes the code stored in the memory 540 to implement the functions of the aforementioned transport layer gateway 410 or application layer gateway 420, respectively. That is, the memory 530 stores instructions for implementing the functions of the aforementioned transport layer gateway 410 or application layer gateway 420.

[0127] The memory 540 of one or more computing devices 500 in the computing device cluster 600 may respectively store instructions for implementing some of the functions of the aforementioned gateway device 400. In other words, the combination of one or more computing devices 500 in the computing device cluster 600 can jointly implement all the functions of the gateway device 400.

[0128] In some possible implementations, one or more computing devices 500 in the computing device cluster 600 can be connected via a network, which can be a wide area network (WAN) or a local area network (LAN). Figure 7 illustrates one possible implementation. As shown in Figure 7, computing devices 500A and 500B are connected via a network. Specifically, they are connected to the network through communication interfaces in computing devices 500A and 500B. In this implementation, the memory 540 in computing device 500A stores instructions for implementing the functions of the transport layer gateway 410, and the memory 540 in computing device 500B stores instructions for implementing the functions of the application layer gateway 420. It should be understood that the functions of computing devices 500A and 500B can both be performed by multiple computing devices 500.

[0129] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored on any available medium. When the computer program product runs on a computing device, it causes the computing device to perform the cross-cluster application access method described above.

[0130] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives). The computer-readable storage medium includes instructions that instruct the computing device to perform the cross-cluster application access method described above.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A method for cross-cluster application access, characterized in that, The multi-cluster system includes an application layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. A first application runs on the first Kubernetes cluster, and a second application runs on the second Kubernetes cluster. The first Kubernetes cluster also includes a network proxy component. The method includes: The network proxy component intercepts the access request sent by the first application; The network proxy component forwards the access request according to the target routing rule matching the access request; wherein... When the target routing rule indicates that application layer processing should be performed on the access request, the network proxy component sends the access request to the application layer gateway, so that the application layer gateway performs application layer processing on the access request and forwards the processed access request to the second application; When the target routing rule instructs that transport layer processing be performed on the access request, the network proxy component sends the access request to the second application.

2. The method according to claim 1, characterized in that, The method further includes: The network proxy component intercepts access requests from a third application and forwards the access requests from the third application, wherein the third application runs on the first Kubernetes cluster.

3. The method according to claim 2, characterized in that, The multi-cluster system includes a control component, and the first Kubernetes cluster includes a control agent component; Before the network proxy component forwards the access request according to the target routing rule matching the access request, the method further includes: The control agent component receives at least one routing rule pushed by the control component, the at least one routing rule including the target routing rule; The control agent component sends the at least one routing rule to the network agent component; The network proxy component forwards the access request according to the target routing rule matching the access request, including: The network proxy component determines the target routing rule from the at least one routing rule based on the destination Internet Protocol (IP) address of the access request, wherein the target routing rule includes the destination IP address.

4. The method according to claim 3, characterized in that, Before the network proxy component sends the access request to the second application, the method further includes: The control agent component receives service information of the second application pushed by the control component; The control proxy component sends the service information of the second application to the network proxy component. The service information of the second application includes the IP address and port information of the Pod where the second application is located. The network proxy component sends the access request to the second application, including: The network proxy component sends the access request to the second application based on the IP address and port information of the Pod where the second application is located.

5. The method according to claim 4, characterized in that, When the target routing rule instructs application-layer processing to be performed on the access request, the method further includes: The application layer gateway receives the target routing rules pushed by the control component; The application layer gateway performs application layer processing on the access request, including: The application layer gateway performs application layer processing on the access request according to the target routing rules.

6. The method according to claim 5, characterized in that, When the target routing rule instructs application-layer processing to be performed on the access request, the method further includes: The application layer gateway receives service information of the second application pushed by the control component; The application layer gateway forwards the processed access request to the second application, including: The application layer gateway sends the access request to the second application based on the IP address and port information of the Pod where the second application is located.

7. A gateway device, characterized in that, The device is applied to a multi-cluster system, which includes an application layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. The first Kubernetes cluster runs a first application, and the second Kubernetes cluster runs a second application. The first Kubernetes cluster further includes a network proxy component. The device comprises: The network proxy component is used to intercept access requests issued by the first application; forward the access request according to a target routing rule matching the access request; wherein, when the target routing rule indicates that application layer processing is performed on the access request, the access request is sent to the application layer gateway; when the target routing rule indicates that transport layer processing is performed on the access request, the access request is sent to the second application. The application layer gateway is used to receive the access request sent by the network proxy component, perform application layer processing on the access request, and forward the processed access request to the second application.

8. The apparatus according to claim 7, characterized in that, The network proxy component is also used to intercept access requests issued by a third application and forward the access requests issued by the third application, wherein the third application runs on the first Kubernetes cluster.

9. The apparatus according to claim 8, characterized in that, The multi-cluster system further includes a control component, and the gateway device further includes a control agent component, which is deployed on the first Kubernetes cluster. The control proxy component is configured to receive at least one routing rule pushed by the control component, the at least one routing rule including the target routing rule; and send the at least one routing rule to the network proxy component. The network proxy component is configured to determine the target routing rule from the at least one routing rule based on the destination Internet Protocol (IP) address of the access request, wherein the target routing rule includes the destination IP address.

10. The apparatus according to claim 9, characterized in that, The control proxy component is further configured to receive service information of the second application pushed by the control component, the service information of the second application including the IP address and port information of the Pod where the second application is located; and send the service information of the second application to the network proxy component. The network proxy component is used to send the access request to the second application based on the IP address and port information of the Pod where the second application is located.

11. The apparatus according to claim 10, characterized in that, When the target routing rule indicates that application layer processing should be performed on the access request, the application layer gateway is used to receive the target routing rule pushed by the control component and perform application layer processing on the access request according to the target routing rule.

12. The apparatus according to claim 11, characterized in that, When the target routing rule indicates that application-layer processing should be performed on the access request, the application-layer gateway is used to receive the service information of the second application pushed by the control component, and send the access request to the second application according to the IP address and port information of the Pod where the second application is located.

13. A multi-cluster system, characterized in that, This includes an application layer gateway, a first Kubernetes cluster, and a second Kubernetes cluster. The first Kubernetes cluster runs a first application, and the second Kubernetes cluster runs a second application. The first Kubernetes cluster also includes a network proxy component. The network proxy component intercepts the access request sent by the first application; The network proxy component forwards the access request according to the target routing rule matching the access request; wherein... When the target routing rule indicates that application layer processing should be performed on the access request, the network proxy component sends the access request to the application layer gateway, so that the application layer gateway performs application layer processing on the access request and forwards the processed access request to the second application; When the target routing rule instructs that transport layer processing be performed on the access request, the network proxy component sends the access request to the second application.

14. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and 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 to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 6.

15. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 6.

16. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 6.

Images