Container traffic management method, apparatus, device and system of serverless architecture

Abstract

The application discloses a container traffic management method, device, equipment and system of a serverless architecture, relates to the technical field of cloud computing, and comprises the following steps: a center gateway node of a meta-cluster acquires a cross-domain data packet sent by a source container in a first container providing end; according to global routing information and identification information of a target container in the cross-domain data packet, a second container providing end is determined; the cross-domain data packet is sent to the second container providing end, so that the second container providing end sends the cross-domain data packet to the target container; the application constructs a star network topology with the centralized meta-cluster as a network hub, and accesses different capacity providing ends as radiation nodes, so that a unified and flat Pod covering network can be constructed on the physically isolated and network heterogeneous capacity providing ends; the center gateway node of the meta-cluster is used for forwarding the cross-domain data packet, so that direct communication between Pods deployed on different capacity providing ends under the serverless architecture is conveniently realized.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a method, apparatus, device and system for managing container traffic in a serverless architecture. Background Technology

[0002] With the continuous development of cloud computing technology, Kubernetes (K8S, a container orchestration engine) has become a widely used container orchestration technology in the industry due to its simple yet powerful network model. In a native K8S cluster, a flat overlay network is typically built for Pods (the smallest basic unit in K8S, consisting of one or more containers) through container network interface plugins. This allows a Pod on any node to directly access Pods on any other node through its unique IP address, without the need for Network Address Translation (NAT). The basis for this network model is that the networks of all nodes in the cluster are interconnected, and data packets can be directly routed between nodes.

[0003] However, in a serverless Kubernetes architecture, computing resources are provided by multiple independent capacity providers. These providers may be serverless container instances from cloud vendors, such as Elastic Container Instances (ECIs), user-built edge clusters, or individual edge nodes. These capacity providers are physically and network-isolated; their nodes or virtual nodes belong to different VPCs (Virtual Private Clouds), subnets, or physical locations, lacking direct Layer 2 or Layer 3 network connectivity and potentially even overlapping IP (Internet Protocol) segments. This makes the native Kubernetes network model unsuitable for such heterogeneous serverless Kubernetes environments. Therefore, how to easily enable direct communication between Pods deployed on different capacity providers in a serverless architecture is a pressing issue that needs to be addressed. Summary of the Invention

[0004] The purpose of this invention is to provide a method, apparatus, device, and system for container traffic management in a serverless architecture, so as to facilitate direct communication between Pods deployed on different capacity providers in a serverless architecture.

[0005] To address the aforementioned technical problems, this invention provides a serverless container traffic management method, comprising: The central gateway node of the meta cluster obtains cross-domain data packets sent by the source container in the first container provider. Based on global routing information and the identifier information of the target container in the cross-domain data packet, a second container provider is determined; wherein, the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers of the meta-cluster communication connection; the type of the container provider of the meta-cluster communication connection includes at least one of standard cluster type, serverless virtual private cloud type, and independent edge node type; The cross-domain data packet is sent to the second container provider so that the second container provider sends the cross-domain data packet to the target container.

[0006] On the other hand, when the type of the second container provider is the standard cluster type, sending the cross-domain data packet to the second container provider includes: The cross-domain data packet is sent to the local gateway node in the second container provider through a first encrypted tunnel, so that the local gateway node sends the cross-domain data packet to the target container in the target node; wherein, the first encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the second container provider and the central gateway node; the local gateway node is a local node in a standard cluster-type container provider; the target node is the node in the second container provider where the target container is located; When the first container provider is of the standard cluster type, the central gateway node of the meta-cluster obtains cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the local gateway node in the first container provider through a second encrypted tunnel; wherein, the second encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the first container provider and the central gateway node; when the node where the source container is located is not the local gateway node in the first container provider, the node where the source container is located is used to send the cross-domain data packets to the local gateway node in the first container provider, so that the local gateway node in the first container provider can forward them to the central gateway node.

[0007] On the other hand, when the type of the first container provider is the serverless virtual private cloud type, the central gateway node of the meta-cluster obtains the cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the first container provider through a preset communication link; wherein, the preset communication link is a virtual private cloud peer-to-peer connection or a virtual private network gateway.

[0008] On the other hand, when the type of the first container provider is the independent edge node type, the central gateway node of the meta-cluster obtains the cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the edge network agent in the first container provider through a preset tunnel connection; wherein, the preset tunnel connection is a tunnel connection established between the edge network agent and the central gateway node, and the edge network agent is used to forward cross-domain data packets of each container in the first container provider.

[0009] On the other hand, the method also includes: The routing information is used as a proxy to store and synchronize the global routing information to the container providing the meta-cluster communication connection.

[0010] On the other hand, the first container provider is of a different type than the second container provider.

[0011] On the other hand, the method also includes: The central gateway node receives external request traffic; Based on the Uniform Resource Locator (URL) information and preset routing rules of the external request traffic, the external request traffic is routed to the containers in their respective container providers.

[0012] This invention also provides a serverless container traffic management device applied to the central gateway node of a meta cluster, comprising: The acquisition module is used to acquire cross-domain data packets sent by the source container in the first container provider. The determination module is used to determine the second container provider based on global routing information and the identification information of the target container in the cross-domain data packet; wherein, the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers of the meta-cluster communication connection; the type of the container provider of the meta-cluster communication connection includes at least one of standard cluster type, serverless virtual private cloud type and independent edge node type; The forwarding module is used to send the cross-domain data packet to the second container provider, so that the second container provider sends the cross-domain data packet to the target container.

[0013] The present invention also provides a serverless container traffic management device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of the serverless architecture container traffic management method as described above when executing the computer program.

[0014] Furthermore, the present invention also provides a serverless container traffic management system, comprising: a meta-cluster and at least two container providers communicatively connected to the meta-cluster; the container providers are of at least one of the following types: standard cluster type, serverless virtual private cloud type, and independent edge node type. The meta-cluster includes a central gateway node; the central gateway node is a container traffic management device with a serverless architecture as described above.

[0015] The present invention provides a serverless container traffic management method, comprising: a central gateway node of a meta-cluster acquiring cross-domain data packets sent by a source container in a first container provider; determining a second container provider based on global routing information and the identifier information of a target container in the cross-domain data packets; wherein the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers connected to the meta-cluster communication; the type of container provider connected to the meta-cluster communication includes at least one of standard cluster type, serverless virtual private cloud type, and independent edge node type; and sending the cross-domain data packets to the second container provider so that the second container provider sends the cross-domain data packets to the target container.

[0016] As can be seen, this invention constructs a star network topology using a centralized meta-cluster as the network hub, connecting different capacity providers as radiating nodes. This enables the construction of a unified and flat Pod coverage network over physically isolated and heterogeneous capacity providers. By utilizing the central gateway node of the meta-cluster to forward cross-domain data packets, direct communication between Pods deployed on different capacity providers in a serverless architecture is conveniently achieved, reducing operational load. Furthermore, this invention also provides a serverless container traffic management device, equipment, and system, which also possesses the aforementioned beneficial effects. Attached Figure Description

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

[0018] Figure 1 A flowchart illustrating a serverless container traffic management method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall logical architecture of a serverless container traffic management system provided in an embodiment of the present invention. Figure 3A schematic diagram of the system logic layering of another serverless container traffic management system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a north-south traffic management process provided in an embodiment of the present invention; Figure 5 This is a technical implementation architecture diagram of another serverless container traffic management system provided in an embodiment of the present invention; Figure 6 A schematic diagram of the component architecture of a quasi-cluster-type capacity provider network access scheme provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the network interconnection between a meta-cluster and two standard cluster-type capacity providers provided in an embodiment of the present invention. Figure 8 This is a schematic diagram illustrating how traffic from a cross-type capacity provider is relayed through a meta-cluster, as provided in an embodiment of the present invention. Figure 9 A schematic diagram of the component architecture of a network access scheme for an independent edge node type capacity provider provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a serverless container traffic management device provided in an embodiment of the present invention; Figure 11 This is a schematic diagram of a serverless container traffic management device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a serverless container traffic management method provided in an embodiment of the present invention. The method may include: Step 101: The central gateway node of the meta cluster obtains the cross-domain data packets sent by the source container in the first container provider.

[0021] It is understood that the meta-cluster in this embodiment can be a centralized system used for managing and orchestrating various capacity providers (or capacity providers) under a serverless architecture (i.e., Serverless Kubernetes architecture). In this embodiment, the centralized meta-cluster can serve as a hub for the aggregation and relay of all cross-domain network traffic, connecting all heterogeneous capacity providers as radiating nodes, thereby forming a unified, flattened overlay network. The central gateway node in this embodiment can be a node set up in the meta-cluster to relay all east-west traffic (i.e., cross-domain data packets) across capacity providers; for example, the central gateway node can be a publicly accessible node.

[0022] Correspondingly, in this embodiment, the first container provider and the second container provider can be two different container providers connected to the meta-cluster communication, i.e., container providers accessing the meta-cluster. The source container in this embodiment can be a Pod (one or more containers combined) initiating cross-domain data packets in the first container provider, i.e., a Pod that needs to send cross-domain traffic to other container providers (such as the second container provider). In this embodiment, the container providers connected to the meta-cluster communication can be abstracted into different types, and corresponding network access models are adopted to connect their Pod networks to a unified coverage network centered on the meta-cluster, enabling east-west traffic interconnection between all Pods, thereby allowing east-west traffic to be relayed according to the corresponding type. For example, the container providers that the meta-cluster can communicate with can be abstracted into three types: standard cluster type, serverless virtual private cloud type, and independent edge node type.

[0023] Correspondingly, for a standard cluster-type container provider (i.e., a standard cluster container provider), a local gateway node can be elected internally, and this node establishes a secure tunnel (i.e., an encrypted communication tunnel) with the central gateway node of the meta-cluster. A centralized routing information broker (Broker, such as a routing information broker component) in the meta-cluster is used to publish and synchronize the Pod network routing information (i.e., global routing information) of all connected capacity providers. A routing broker is deployed on each compute node within the container provider's cluster. This broker obtains the global routing table from the routing information broker and configures routing rules in the local node's operating system, directing the next hop of all cross-domain traffic (such as cross-domain packets) that needs to be sent to other capacity providers or resources to the local gateway node.

[0024] For serverless virtual private cloud container providers, such as VPC-type capacity providers without underlying nodes, represented by serverless container instances, network layer technologies such as VPC peering or VPN (Virtual Private Network) gateways can be used to establish Layer 3 network reachability (cross-network segment communication via IP routing) between the VPC where the capacity provider is located and the VPC where the meta cluster is located. An exit routing policy can be configured in the VPC routing table of the capacity provider to uniformly direct all traffic with destination addresses outside the VPC network segment to the central gateway node of the meta cluster as the next hop.

[0025] For container providers with independent edge nodes, an edge network proxy can be deployed on each edge node. This proxy is responsible for establishing a lightweight tunnel with the network service deployed in the meta cluster. All cross-domain traffic originating from this edge node is forwarded by the edge network proxy through the tunnel to the central gateway node of the meta cluster for unified routing.

[0026] It's important to note that in traditional Kubernetes clusters, the network model (such as cross-host communication based on host-gw) relies on the interconnectivity of the underlying network interfaces of all nodes. Nodes can configure static routes (ip routes) to directly route traffic destined for a peer Pod's network segment to the peer node's IP address. However, in a Serverless Kubernetes architecture, computing resources consist of isolated capacity providers, rendering the underlying network connectivity nonexistent. This embodiment addresses this network connectivity issue by utilizing the central gateway node of the meta-cluster to forward cross-domain data packets.

[0027] Correspondingly, the method provided in this embodiment may also include a meta-cluster construction process. For example... Figure 2 As shown, this embodiment can construct a system architecture with a centralized metacluster and three types of capacity providers. The metacluster is deployed in the cloud, serving as the control plane and network hub for the entire platform. The capacity providers, as the actual units carrying computing resources, can include three types: independent edge node capacity providers (Tenant Edge Node), standard cluster capacity providers (ZhiQuanCluster Node), and serverless virtual private cloud capacity providers (AlibabaECI Virtual Node). The definition and management of services (Service A-1, B-1, C-1, etc.) for all Pods deployed on these capacity providers are completed within the metacluster; for example... Figure 3 As shown, the entire system logically forms a hierarchical structure between the meta-cluster and each capacity provider.

[0028] The specific method by which the central gateway node of the meta-cluster obtains cross-domain data packets sent by the source container in the first container provider during this step can be set by the designer according to the practical scenario and user needs. For example, it can be set according to the type of the first container provider. For instance, when the type of the first container provider is a standard cluster, the central gateway node in this step can receive the cross-domain data packets of the source container sent by the local gateway node in the first container provider through the second encrypted tunnel. The second encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the first container provider and the central gateway node. When the node where the source container is located is not the local gateway node in the first container provider, the node where the source container is located is used to send the cross-domain data packets to the local gateway node in the first container provider, so that the local gateway node in the first container provider can forward them to the central gateway node. The local gateway node in the first container provider can be a local node elected by the first container provider.

[0029] Correspondingly, when the first container provider is a serverless virtual private cloud, the central gateway node in this step can receive cross-domain data packets from the source container sent by the first container provider through a preset communication link; wherein, the preset communication link is a virtual private cloud (VPC) peering connection or a virtual private network (VPN) gateway, such as an IPsec VPN (a type of secure virtual private network) gateway. When the first container provider is an independent edge node, the central gateway node in this step can receive cross-domain data packets from the source container sent by the edge network agent in the first container provider through a preset tunnel connection; wherein, the preset tunnel connection can be a tunnel connection established between the edge network agent and the central gateway node, and the edge network agent is used to forward cross-domain data packets from each container in the first container provider; the preset tunnel connection can also be a tunnel connection established between the edge network agent and a network server other than the central gateway node in the meta-cluster, and the central gateway node communicates with the network server. As long as the central gateway node can obtain the cross-domain data packets sent by the source container in the first container provider, this embodiment does not impose any restrictions on this.

[0030] Step 102: Determine the second container provider based on the global routing information and the target container identification information in the cross-domain data packet; wherein, the second container provider is the container provider where the target container is located.

[0031] Among them, the first container provider and the second container provider are different container providers for the meta-cluster communication connection; the type of container provider for the meta-cluster communication connection includes at least one of the following: standard cluster type, serverless virtual private cloud type, and independent edge node type.

[0032] It is understood that the global routing information in this embodiment may include the routing information of all Pods on the capacity provider of the access meta cluster (i.e., global Pod routing information), so that the central gateway node can determine the location of the Pod based on the identification information (such as IP address) of the Pod (such as the target container). In this embodiment, the target container may be the Pod to which the cross-domain data packet is to be sent.

[0033] Correspondingly, this embodiment may also include a process for storing and synchronizing global routing information. For example, the meta-cluster utilizes a routing information broker to store and synchronize global routing information with the container providing the communication connection to the meta-cluster. The routing information broker can be located in the central gateway node of the meta-cluster, or it can be located in other locations within the meta-cluster (such as other nodes). Figure 7 The Broker API (Application Programming Interface) in the document.

[0034] It should be noted that the second container provider in this embodiment can be the container provider where the target container resides. The first and second container providers in this embodiment can be two different container providers accessing the meta-cluster. The first and second container providers can be of different types; for example, the type of container provider for the meta-cluster communication connection can include at least two of the following: standard cluster type, serverless virtual private cloud type, and independent edge node type. Alternatively, the first and second container providers can be of the same type; this embodiment does not impose any restrictions on this.

[0035] Accordingly, the central gateway node in this step can determine the second container provider where the target container resides based on global routing information and the target container's identifier in the cross-domain data packet, thereby sending the cross-domain data packet to the target container in the second container provider. The specific method for determining the second container provider based on global routing information and the target container's identifier in the cross-domain data packet can be set by the designer according to the practical scenario and user requirements. For example, after receiving the cross-domain data packet, the central gateway node can parse its target address (i.e., the target container's identifier) ​​and determine the container provider (i.e., the second container provider) corresponding to that address based on global routing information. If this address is located within the VPC of the ECI (i.e., the second container provider) that has been connected via IPsec VPN, the central gateway node can forward the data packet to the ECI's VPC via IPsec VPN, and the network mechanism within the VPC will be responsible for accurately delivering the cross-domain data packet to the target Pod. This embodiment does not impose any restrictions on the central gateway node's ability to determine the second container provider where the target container resides based on global routing information and the target container's identifier in the cross-domain data packet.

[0036] Step 103: Send the cross-domain data packet to the second container provider so that the second container provider sends the cross-domain data packet to the target container.

[0037] Understandably, the central gateway node in this step can send cross-domain data packets to the second container provider, which then uses the second container provider to send the cross-domain data packets to the target container (Pod) inside it, thus enabling the transmission of cross-domain traffic.

[0038] Correspondingly, the specific method by which the central gateway node sends cross-domain data packets to the second container provider in this step can be set by the designer according to the practical scenario and user needs. For example, it can be set according to the type of the first container provider. For instance, when the type of the first container provider is a standard cluster type, the central gateway node can send cross-domain data packets to the local gateway node in the second container provider through the first encrypted tunnel, so that the local gateway node can send the cross-domain data packets to the target container in the target node. Here, the first encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the second container provider and the central gateway node; the local gateway node is a local node in the standard cluster type container provider; and the target node is the node in the second container provider where the target container is located.

[0039] Correspondingly, when the second container provider is a serverless virtual private cloud, the central gateway node can send cross-domain data packets to the second container provider via a target communication link, enabling the second container provider to send the cross-domain data packets to the target container. The target communication link is either a VPC peering connection or a Virtual Private Network (VPN) gateway between the meta-cluster and the second container provider. When the second container provider is an independent edge node, the central gateway node in this step can send cross-domain data packets to the second container provider via a target tunnel connection, utilizing the edge network proxy of the second container provider to forward the cross-domain data packets to the target container. The target tunnel connection can be a tunnel connection established between the edge network proxy of the second container provider and the central gateway node; a preset tunnel connection can also be a tunnel connection established between the edge network proxy and a network server outside the central gateway node in the meta-cluster, with communication between the central gateway node and this network server. This embodiment does not impose any restrictions as long as the central gateway node can send cross-domain data packets to the second container provider, thereby enabling the second container provider to send the cross-domain data packets to the target container.

[0040] Furthermore, the method provided in this implementation may also include the management process of external request traffic (i.e., north-south traffic) by the meta-cluster. For example, a unified traffic ingress gateway (Kubernetes Gateway API) can be deployed in the meta-cluster to centrally manage, route, and enforce policies for all north-south traffic entering the cluster, and forward the traffic to the backend Pods located on the corresponding capacity providers. Figure 4 As shown, external user request traffic (such as HTTPS requests, e.g., https: / / foo.example.com) can first reach a shared traffic gateway. This gateway routes the traffic to the corresponding containers in the container providers based on the Uniform Resource Locator (URL) information and different preset routing rules (such as HTTP routing rules, HTTPRoute). For example, requests with the path / login are forwarded to the login-v1 and login-v2 services at a ratio of 90% and 10%, respectively; requests with the path / are forwarded to the home service. These services ultimately direct the traffic to the backend Pods running on the various container providers, thus providing the platform with a unified, standardized, and feature-rich north-south traffic gateway.

[0041] The traffic ingress gateway can be deployed within the central gateway node, which can receive external request traffic and route it to containers in their respective container providers based on the Uniform Resource Locator (URL) information and preset routing rules. The traffic ingress gateway can also be deployed in other locations within the meta-cluster (such as other nodes). This embodiment does not impose any restrictions on this.

[0042] For example, in this embodiment, three types of capacity providers—standard cluster type, serverless virtual private cloud type, and independent edge node type—can be used as radiating nodes and connected to a star network centered on a meta-cluster. The technical implementation architecture can be as follows: Figure 5 As shown.

[0043] (1) For standard cluster-type capacity providers (e.g., user-built edge clusters ZhiQuanCluster): refer to Figure 6 The Submariner (an open-source project) component architecture is shown below, and as follows: Figure 7As shown, a network federation component is deployed in this type of cluster. This component automatically elects a local node (e.g., the ZhiQuanGateway Node with IP 192.168.12.1) as the local gateway node, runs a gateway engine on it, and actively establishes an encrypted secure tunnel with the central gateway node of the meta-cluster. Simultaneously, a route agent is deployed on each worker node in the cluster (e.g., 192.168.12.2). A centralized routing information broker runs in the meta-cluster, responsible for collecting and distributing CIDR (Classless Inter-Domain Routing) for all Pods connected to capacity providers. In a standard cluster-type capacity provider, the route agents on each node synchronize global routing information from the broker and add rules to the routing table of their local nodes, directing all traffic destined for Pods on other capacity providers to the local gateway node of their own cluster for the next hop.

[0044] (2) For serverless virtual private cloud type capacity providers (such as Elastic Container Instances, ECI): Such resources do not provide operable underlying nodes; for example, a Pod named pod / eci has an IP address of 10.0.0.5, while the service network segment of the cluster (such as the CLUSTER-IP of service / kubernetes) is 10.96.0.1. The two are located in completely different network segments and cannot communicate directly; in this embodiment, a VPC peering connection or IPsec VPN gateway is used to connect the VPC where ECI is located and the VPC where the meta cluster is located. Subsequently, an exit routing policy is configured in the routing table of the ECI VPC: all outbound traffic from non-VPC network segments will have their next hop uniformly pointed to the IP address of the central gateway node of the meta cluster, such as Figure 8 The connection method is shown on the right side of the middle section.

[0045] (3) For independent edge node type capacity providers (such as...) Figure 2 Tenant Edge Node): Reference Figure 9The KubeEdge (an open-source edge computing framework built on Kubernetes) EdgeMesh component architecture shown here deploys an EdgeMesh agent on such independent edge nodes. This agent proactively establishes a lightweight tunnel connection with the network server (EdgeMesh-Server) deployed in the meta cluster. All network traffic generated by the Pods on this edge node that needs to be sent to other capacity providers can be captured by this agent and sent to the meta cluster for unified routing and forwarding through the tunnel.

[0046] Correspondingly, in this embodiment, east-west traffic (i.e., cross-domain data packets) is relayed through the meta cluster, forming a star network topology. For example... Figure 8 As shown, when a Pod needs to access another Pod located on a different capacity provider, taking the example of a "Pod on ZhiQuanCluster" accessing a "Pod on ECI," the traffic path can be as follows: 1. The Pod within ZhiQuanCluster sends a cross-domain data packet, with the destination address being the IP address of the ECI Pod. 2. The cross-domain data packet arrives at its node, and according to local routing rules, the next hop is directed to the local gateway node (ZhiQuan Gateway Node 192.168.12.1). 3. The gateway engine on the local gateway node sends the cross-domain data packet to the central gateway node of the metacluster (MetaCluster Gateway Node) through the established tunnel. 4. After receiving the cross-domain data packet, the central gateway node resolves its destination address to the IP address of the ECI Pod; based on global routing information, the central gateway node knows that this IP address is located within the ECI VPC that has been established via IPsec VPN. 5. The central gateway node forwards the data packet to the ECI VPC through the VPN router. The network mechanism within the VPC is responsible for accurately delivering the cross-domain data packet to the target Pod. This completes a Pod-to-Pod communication that spans both standard cluster-based and serverless virtual private cloud-based capacity providers.

[0047] In this embodiment, the present invention constructs a star network topology using a centralized meta cluster as the network hub, and connects different capacity providers as radiating nodes. This enables the construction of a unified and flat Pod coverage network on physically isolated and heterogeneous capacity providers. By utilizing the central gateway node of the meta cluster to forward cross-domain data packets, direct communication between Pods deployed on different capacity providers under a serverless architecture is conveniently realized, reducing the operational load.

[0048] Corresponding to the above method embodiments, this invention also provides a serverless container traffic management device. The serverless container traffic management device described below and the serverless container traffic management method described above can be referred to each other.

[0049] Please refer to Figure 10 , Figure 10 This is a schematic diagram of a serverless container traffic management device provided in an embodiment of the present invention. The device is applied to the central gateway node of a meta-cluster and includes: Module 10 is used to acquire cross-domain data packets sent by the source container in the first container provider. The determination module 20 is used to determine the second container provider based on global routing information and the identification information of the target container in the cross-domain data packet; wherein, the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers of the meta-cluster communication connection; the type of the container provider of the meta-cluster communication connection includes at least one of standard cluster type, serverless virtual private cloud type and independent edge node type; Forwarding module 30 is used to send cross-domain data packets to the second container provider so that the second container provider can send cross-domain data packets to the target container.

[0050] In some embodiments, when the second container provider is a standard cluster type, the forwarding module 30 can be specifically used to send cross-domain data packets to the local gateway node in the second container provider through a first encrypted tunnel, so that the local gateway node sends the cross-domain data packets to the target container in the target node; wherein, the first encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the second container provider and the central gateway node; the local gateway node is a local node in the standard cluster type container provider; the target node is the node in the second container provider where the target container is located; When the type of the first container provider is a standard cluster, the acquisition module 10 can be specifically used to receive cross-domain data packets of the source container sent by the local gateway node in the first container provider through the second encrypted tunnel; wherein, the second encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the first container provider and the central gateway node; when the node where the source container is located is not the local gateway node in the first container provider, the node where the source container is located is used to send the cross-domain data packets to the local gateway node in the first container provider, so that they can be forwarded to the central gateway node by the local gateway node in the first container provider.

[0051] In some embodiments, when the type of the first container provider is a serverless virtual private cloud, the acquisition module 10 can be specifically used to receive cross-domain data packets of the source container sent by the first container provider through a preset communication link; wherein, the preset communication link is a virtual private cloud peer-to-peer connection or a virtual private network gateway.

[0052] In some embodiments, when the type of the first container provider is an independent edge node, the acquisition module 10 can be specifically used to receive cross-domain data packets of the source container sent by the edge network agent in the first container provider through a preset tunnel connection; wherein, the preset tunnel connection is a tunnel connection established between the edge network agent and the central gateway node, and the edge network agent is used to forward cross-domain data packets of each container in the first container provider.

[0053] In some embodiments, the device may further include: The storage synchronization module is used to utilize routing information proxy to store and provide synchronized global routing information to containers connected to the meta cluster communication connection.

[0054] In some embodiments, the first container provider and the second container provider are of different types.

[0055] In some embodiments, the device may further include: The north-south receiving module is used by the central gateway node to receive external request traffic; The North-South Management module is used to route external request traffic to the containers in their respective container providers based on the Uniform Resource Locator (URL) information and preset routing rules of the external request traffic.

[0056] In this embodiment, the present invention constructs a star network topology using a centralized meta cluster as the network hub, and connects different capacity providers as radiating nodes. This enables the construction of a unified and flat Pod coverage network on physically isolated and heterogeneous capacity providers. By utilizing the central gateway node of the meta cluster to forward cross-domain data packets, direct communication between Pods deployed on different capacity providers under a serverless architecture is conveniently realized, reducing the operational load.

[0057] Corresponding to the above method embodiments, this invention also provides a serverless container traffic management device. The serverless container traffic management device described below and the serverless container traffic management method described above can be referred to each other.

[0058] Please refer to Figure 11 , Figure 11 This is a schematic diagram of a serverless container traffic management device provided in an embodiment of the present invention. The device may include: Memory D1 is used to store computer programs; Processor D2 is used to implement the steps of the serverless container traffic management method provided in the above method embodiments when executing a computer program.

[0059] In this embodiment, the serverless container traffic management device can be specifically used as a node in a meta-cluster, such as the central gateway node mentioned above.

[0060] Corresponding to the above method embodiments, this invention also provides a serverless container traffic management system. The serverless container traffic management system described below and the serverless container traffic management device described above can be referred to in correspondence.

[0061] A serverless container traffic management system includes: a meta-cluster and at least two container providers that communicate with the meta-cluster; the container providers are of at least one of the following types: standard cluster type, serverless virtual private cloud type, and independent edge node type. The meta cluster includes a central gateway node; the central gateway node is a serverless container traffic management device as provided in the above embodiments.

[0062] In some embodiments, the meta-cluster may further include: The routing information proxy is used to store and synchronize global routing information.

[0063] In some embodiments, the meta-cluster may further include: A unified traffic ingress gateway is used to manage north-south traffic.

[0064] In some embodiments, a standard cluster-type container provider may include a local gateway node that establishes a tunnel with the central gateway node, and a routing agent deployed on each node for configuring local routes; a serverless virtual private cloud-type container provider's VPC can be connected to the meta-cluster's VPC via a network connection and is configured with a routing table policy to direct cross-domain traffic to the central gateway node; an independent edge node-type container provider may deploy an edge network agent that establishes a tunnel connection with the meta-cluster.

[0065] Corresponding to the above method embodiments, this invention also provides a computer program product. The computer program product described below can be referred to in conjunction with the serverless container traffic management method described above.

[0066] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the serverless container traffic management method provided in the above-described method embodiments.

[0067] Corresponding to the above method embodiments, this invention also provides a computer-readable storage medium. The computer-readable storage medium described below can be referred to in conjunction with the serverless container traffic management method described above.

[0068] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the serverless container traffic management method as provided in the above-described method embodiments.

[0069] The computer-readable storage medium can specifically be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0070] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, devices, systems, computer-readable storage media, and computer program products disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant details can be found in the method section.

[0071] The foregoing has provided a detailed description of a serverless container traffic management method, apparatus, device, and system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A container traffic management method for serverless architecture, characterized in that, include: The central gateway node of the meta cluster obtains cross-domain data packets sent by the source container in the first container provider. Based on global routing information and the identifier information of the target container in the cross-domain data packet, a second container provider is determined; wherein, the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers of the meta-cluster communication connection; the type of the container provider of the meta-cluster communication connection includes at least one of standard cluster type, serverless virtual private cloud type, and independent edge node type; The cross-domain data packet is sent to the second container provider so that the second container provider sends the cross-domain data packet to the target container.

2. The container traffic management method for serverless architecture according to claim 1, characterized in that, When the type of the second container provider is the standard cluster type, sending the cross-domain data packet to the second container provider includes: The cross-domain data packet is sent to the local gateway node in the second container provider through a first encrypted tunnel, so that the local gateway node sends the cross-domain data packet to the target container in the target node; wherein, the first encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the second container provider and the central gateway node; the local gateway node is a local node in a standard cluster-type container provider; the target node is the node in the second container provider where the target container is located; When the first container provider is of the standard cluster type, the central gateway node of the meta-cluster obtains cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the local gateway node in the first container provider through a second encrypted tunnel; wherein, the second encrypted tunnel is an encrypted communication tunnel established between the local gateway node in the first container provider and the central gateway node; when the node where the source container is located is not the local gateway node in the first container provider, the node where the source container is located is used to send the cross-domain data packets to the local gateway node in the first container provider, so that the local gateway node in the first container provider can forward them to the central gateway node.

3. The container traffic management method for serverless architecture according to claim 1, characterized in that, When the first container provider is of the serverless virtual private cloud type, the central gateway node of the meta-cluster obtains cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the first container provider through a preset communication link; wherein, the preset communication link is a virtual private cloud peer-to-peer connection or a virtual private network gateway.

4. The container traffic management method for serverless architecture according to claim 1, characterized in that, When the first container provider is of the independent edge node type, the central gateway node of the meta-cluster obtains cross-domain data packets sent by the source container in the first container provider, including: The central gateway node receives cross-domain data packets of the source container sent by the edge network agent in the first container provider through a preset tunnel connection; wherein, the preset tunnel connection is a tunnel connection established between the edge network agent and the central gateway node, and the edge network agent is used to forward cross-domain data packets of each container in the first container provider.

5. The container traffic management method for serverless architecture according to claim 1, characterized in that, Also includes: The routing information is used as a proxy to store and synchronize the global routing information to the container providing the meta-cluster communication connection.

6. The container traffic management method for serverless architecture according to claim 1, characterized in that, The first container provider is of a different type than the second container provider.

7. The container traffic management method for serverless architecture according to any one of claims 1 to 6, characterized in that, Also includes: The central gateway node receives external request traffic; Based on the Uniform Resource Locator (URL) information and preset routing rules of the external request traffic, the external request traffic is routed to the containers in their respective container providers.

8. A serverless container traffic management device, characterized in that, The central gateway node applied to the meta cluster includes: The acquisition module is used to acquire cross-domain data packets sent by the source container in the first container provider. The determination module is used to determine the second container provider based on global routing information and the identification information of the target container in the cross-domain data packet; wherein, the second container provider is the container provider where the target container is located, and the first container provider and the second container provider are different container providers of the meta-cluster communication connection; the type of the container provider of the meta-cluster communication connection includes at least one of standard cluster type, serverless virtual private cloud type and independent edge node type; The forwarding module is used to send the cross-domain data packet to the second container provider, so that the second container provider sends the cross-domain data packet to the target container.

9. A serverless container traffic management device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the serverless architecture container traffic management method as described in any one of claims 1 to 7 when executing the computer program.

10. A serverless container traffic management system, characterized in that, include: A meta-cluster and at least two container providers that are communicatively connected to the meta-cluster; the container providers include at least one of the following types: standard cluster type, serverless virtual private cloud type, and independent edge node type. The meta-cluster includes a central gateway node; the central gateway node is a serverless container traffic management device as described in claim 9.

Images