A cloud edge container network interconnection and optimization system based on network performance perception

Abstract

This invention discloses a cloud-edge container network connectivity and optimization system based on network performance awareness. The system includes: a control and management module for centralized management and storage of edge node information, also functioning as a STUN server, which evaluates the cost of the current routing path in real time and dynamically decides and optimizes to obtain the optimal cloud-edge / edge-edge routing path; and a tunnel agent module deployed on each edge node and cloud node to establish network connectivity tunnels between edge nodes. This tunnel agent module uses IPSec or WireGuard network protocol suites, combined with information from other edge nodes obtained from the control and management module and the optimal cloud-edge / edge-edge routing path, to achieve network connectivity. This invention can make real-time and efficient decisions and establish cloud-edge / edge-edge routes, thereby connecting edge containers in different regions and network environments, significantly improving communication efficiency while reducing cloud bandwidth consumption.

Description

Technical Field

[0001] This invention relates to the field of cloud-edge container network connectivity technology, and in particular to a cloud-edge container network connectivity and optimization system based on network performance awareness. Background Technology

[0002] In the digital age, edge computing technology has become an important component of cloud computing, enabling more efficient processing of data in distributed applications and Internet of Things (IoT) scenarios. However, with the rapid development of edge computing, the interconnectivity of edge networks in different regions has become increasingly prominent, especially in achieving seamless connectivity between edge containers in various network environments.

[0003] Currently, the main technologies used for edge network connectivity are based on the TURN and STUN (Session Traversal Utilities for NAT) protocols. The TURN protocol allows clients to communicate with multiple different peers using the same relay server, while the STUN protocol is primarily used in Network Address Translation (NAT) environments to help devices discover their public IP addresses and port numbers, thereby enabling interconnection between edge devices located in different regions. However, these methods have demonstrated a series of shortcomings in practical applications.

[0004] First, since different peers must use a public network server as a relay to forward data, the performance of this relay server becomes a bottleneck. As network traffic increases and complexity intensifies, the relay server's data forwarding capacity may be limited. Especially in high-concurrency, high-traffic network environments, forwarding performance may degrade significantly, thus affecting the overall quality of network communication.

[0005] Secondly, because communication involves a forwarding layer, network latency will increase accordingly. At the same time, forwarding also consumes a significant amount of bandwidth in the cloud, resulting in extremely high monetary costs.

[0006] In addition, there are currently solutions in the industry based on libp2p for network connectivity. However, libp2p is designed specifically for peer-to-peer applications, not specifically for cloud-native edge computing scenarios, and its complexity makes integration with cloud-native applications quite difficult. Furthermore, although libp2p supports encrypted transmission, its security is slightly insufficient compared to network protocol suites like IPSec and WireGuard, which have dedicated security protocols.

[0007] Most importantly, current cloud-edge and edge-to-edge network connectivity solutions in the industry do not take into account the real-time changing network conditions in cloud-edge scenarios. They cannot establish tunnels based on network performance conditions, nor can they dynamically adjust and switch routes after changes in network performance conditions.

[0008] In summary, although the TURN protocol and the libp2p modular network stack methods can achieve cloud-edge container network connectivity, they still have a series of technical and practical application shortcomings that require further optimization and improvement. This necessitates finding a new network connectivity method that is more suitable for cloud-edge container network scenarios.

[0009] Furthermore, eBPF (Extended Berkeley Packet Filter) technology, as a lightweight and efficient kernel-level tracing tool, has gained popularity among researchers and developers. It can dynamically insert code into the kernel to monitor system operation in real time without affecting system performance, while providing rich data support for upper-layer applications. In addition, eBPF technology allows for in-depth insights into network traffic details. Against this backdrop, this invention proposes a network performance-aware cloud-edge container network connectivity and optimization method, specifically targeting the interconnection of container networks in cloud-native edge computing scenarios. This method, based on network performance information collected using eBPF technology, can make real-time and efficient decisions and establish cloud-edge and edge-edge routes, thereby connecting edge containers in different regions and network environments, significantly improving communication efficiency while reducing cloud bandwidth consumption. Summary of the Invention

[0010] The purpose of this invention is to address the shortcomings of existing technologies by proposing a network performance-aware cloud-edge container network connectivity and optimization system. This invention enables efficient and convenient network connectivity in cloud-native edge container network scenarios.

[0011] The objective of this invention is achieved through the following technical solution: a cloud-edge container network connectivity and optimization system based on network performance awareness, comprising:

[0012] The control and management module is used for centralized management and storage of edge node information. It also functions as a STUN server, evaluating the cost of the current routing path in real time and dynamically deciding and optimizing to obtain the optimal cloud-edge / edge-edge routing path.

[0013] The Tunnel Agent module is deployed on each edge node and cloud node to establish network connectivity tunnels between edge nodes. This Tunnel Agent module uses the IPSec or WireGuard network protocol suite, combined with information from other edge nodes obtained from the control and management module and the optimal cloud-edge / edge-edge routing path, to achieve network connectivity.

[0014] Furthermore, the control management module is implemented through the following steps:

[0015] (1.1) Information Reception and Storage: The control and management module receives edge node information data from each edge node tunnel agent module via the HTTP protocol; the edge node information data of each edge node tunnel agent module is stored in the etcd repository of the Kubernetes cluster. The edge node information data is stored using a custom resource definition method. The control and management module receives edge node information data from each edge node tunnel agent module from the etcd repository.

[0016] (1.2) STUN server function: The control and management module has the function of STUN server, which can help edge nodes discover their public IP address and port number when they start up; each edge node communicates with the control and management module through the STUN protocol to obtain its network access information and registers the network access information back to the control and management module, wherein the network access information includes public IP address and port number;

[0017] (1.3) Distributed dynamic routing path decision and optimization: The control and management module calculates the optimal cloud-edge network routing path decision result based on the collected network performance index data, and optimizes and adjusts it in real time according to the changes in the status of network performance index.

[0018] Furthermore, the edge node information data includes the edge node's network status, public IP address, port number, and network performance indicators, including communication latency, bandwidth usage, and packet loss rate.

[0019] Furthermore, step (1.3) includes the following sub-steps:

[0020] (1.3.1) Constructing a routing path cost model: Perform outlier processing and normalization on all network performance indicators, and construct a routing path cost model based on decision trees by combining historical data of network performance indicators;

[0021] (1.3.2) Cloud-edge network routing path cost calculation: The cloud-edge network is regarded as a graph, where the nodes represent cloud nodes or edge nodes in the cloud-edge network, and the edges represent cloud-edge / edge-edge tunnels connecting the nodes; the routing path cost, i.e. the weight of each edge, is calculated according to the routing path cost model.

[0022] (1.3.3) Dynamic decision-making for cloud-edge network routing paths: The minimum spanning tree algorithm is used to find the spanning tree with the minimum sum of edge weights in the cloud-edge network to ensure that the total cost of the entire cloud-edge network is minimized. The routing path corresponding to the spanning tree with the minimum sum of edge weights is the optimal routing path decision result. The decision result will be optimized and adjusted in real time according to the changes in the network performance indicators. Once the calculation shows that the original routing path is no longer the optimal solution, the minimum spanning tree algorithm will be re-executed to update the routing path decision result and obtain the optimal routing path decision result again.

[0023] Furthermore, the routing path cost model represents the decision-making process through a tree structure, with each node corresponding to a judgment of a network performance indicator, and each leaf node outputting a predicted path cost value. In the routing path cost model, the cost of each path is obtained through a weighted combination of multiple network performance indicators. By learning historical data of network performance indicators, the routing path cost model identifies the weight of different combinations of network performance indicators on the routing path cost, thereby outputting the corresponding routing path cost for new network performance indicator data.

[0024] Furthermore, the tunnel agent module is implemented through the following steps:

[0025] (2.1) Interact with the control and management module: Before establishing a network connection tunnel, the tunnel agent module interacts with the control and management module through the STUN server function of the control and management module to obtain the public IP address and port number of the edge node itself;

[0026] (2.2) Acquisition and Upload of Network Performance Metrics: The Tunnel Agent module obtains the network access information of the edge nodes from the control and management module, including the public IP address and port number; the Tunnel Agent module obtains the current optimal cloud-edge network routing path decision result from the control and management module; the Tunnel Agent module obtains network performance metrics through ping and iperf tools; the Tunnel Agent module collects L2 to L4 events using eBPF technology; and uploads the network performance metrics data to the control and management module in real time, so that the control and management module can make dynamic optimization decisions on routing paths based on the latest network performance metrics data;

[0027] (2.3) Tunnel establishment and maintenance: Using IPSec or WireGuard as the underlying technology, based on the obtained edge node information and the optimal cloud-edge network routing path decision results, network connection tunnels are established according to the tunnel establishment rules; the network configuration information of the edge nodes is updated periodically or upon receiving change instructions from the control and management module to ensure that the configuration of the network connection tunnel is always consistent with the expected network topology, thereby achieving the maintenance of the network connection tunnel.

[0028] Furthermore, the interaction with the control management module through the STUN server function of the control management module specifically includes the following sub-steps:

[0029] (2.1.1) Initialization request: The tunnel agent module sends a binding request message to the STUN server in the control and management module. The binding request message contains the local area network IP address and pre-configured port information of the edge node where the tunnel agent module is located.

[0030] (2.1.2) Receiving response: After processing the received binding request message, the STUN server in the control and management module returns the public IP address and port number of the edge node;

[0031] (2.1.3) Registration information: The Tunnel Agent module will register the obtained public IP address and port number to the control management module for updating the network configuration records of the edge node, so as to ensure that other edge nodes can establish a direct connection to the edge node.

[0032] Furthermore, the use of IPSec or WireGuard as the underlying technology, based on the acquired edge node information and the optimal cloud-edge network routing path decision results, establishes a network connectivity tunnel according to the tunnel establishment rules, specifically including:

[0033] (2.3.1) Prepare connection information: Based on the optimal cloud-edge network routing path decision result, prepare the public IP address, port number, key, and network protocol type of the corresponding edge node to be connected;

[0034] (2.3.2) For WireGuard: The edge node sets the public key, allowed IP range and endpoint information of the peer node according to the obtained connection information. The public key is determined according to the key, the allowed IP range is determined according to the edge node's podCIDR, and the endpoint information is determined according to the edge node's public IP address and port number. In addition, the edge node also sets a persistent heartbeat to ensure that the port mapping on the NAT device remains valid.

[0035] (2.3.3) For IPSec: Use the libreswan tool to configure the network connectivity tunnel. The configuration information in the libreswan tool includes creating security policies, setting encryption parameters, configuring routes, and then starting the network connectivity tunnel.

[0036] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0037] (1) The present invention is fully compatible with cloud-native architecture in design. All network information is stored in etcd of the Kubernetes cluster and adopts the form of custom resource definition (CRD). This not only ensures the high availability and consistency of data, but also makes the entire system easy to expand and maintain, and enhances the cloud-native integration and scalability of STUN.

[0038] (2) This invention realizes a comprehensive evaluation mechanism based on real-time and historical network performance data, which is used for dynamic routing decision optimization in cloud-edge scenarios. When the network conditions change, this invention can re-evaluate and adjust the existing routing decisions in real time. This flexible re-decision capability ensures that the cloud-edge network can maintain optimal performance under various conditions and optimize the routing path based on real-time decision optimization based on network performance awareness.

[0039] (3) This invention uses tools such as ping and iperf to obtain common indicators such as latency, packet loss rate and bandwidth, and also uses eBPF technology to collect network performance indicators, that is, to collect L2 to L4 events to comprehensively evaluate network performance.

[0040] (4) This invention makes full use of STUN to optimize edge network interconnection, enabling edge containers in different network environments to discover and register their public IP addresses and port information. This method simplifies the traditional network configuration process and improves the interconnection between edge devices, especially in NAT environments.

[0041] (5) This invention effectively solves the problem of interconnection of edge container networks under NAT environment and greatly simplifies the communication process across network devices; by controlling and managing the data of each node in real time, dynamically optimizing the network topology, and intelligently adjusting the tunnel and routing configuration, the latency is reduced and the network performance is improved; by using the automatic tunnel management and maintenance function of the tunnel agent module, combined with the encryption technology of IPSec and WireGuard, not only is the stability and high availability of network connection guaranteed, but the security of data transmission is also enhanced; the cloud-native compatibility of the whole system and the use of CRD for data management improve maintainability and facilitate scale expansion and cross-cluster management; through the above measures, the network operating cost is significantly reduced, and an efficient, reliable and secure network connectivity solution is provided for cloud-native distributed edge computing environment. Attached Figure Description

[0042] Figure 1 This is a diagram of the overall architecture of the cloud-edge container network connectivity and optimization system based on network performance awareness of the present invention.

[0043] Figure 2 This is a deployment architecture diagram of the system described in this invention. Detailed Implementation

[0044] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to limit this application.

[0045] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0046] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to determination," or "includes." Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process or method. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0047] The present invention will now be described in detail with reference to the accompanying drawings. Unless otherwise specified, the features of the following embodiments and implementations can be combined with each other.

[0048] See Figure 1 The cloud-edge container network connectivity and optimization system based on network performance awareness of the present invention specifically includes a control management module and a tunnel agent module.

[0049] In this embodiment, the control and management module is used to centrally manage and store edge node information, and also functions as a STUN server. It evaluates the cost of the current routing path in real time, and makes dynamic decisions and optimizations to obtain the optimal cloud-edge / edge-edge routing path.

[0050] It should be understood that the control and management module plays a crucial role in the system. It is not only responsible for the centralized management and storage of edge node information, but also functions as a STUN server and dynamically optimizes the network topology.

[0051] Furthermore, the control and management module is implemented through the following steps:

[0052] (1.1) Information Reception and Storage: The control and management module receives edge node information data from each edge node tunnel agent module via the HTTP protocol. The edge node information data of each edge node tunnel agent module is stored in the etcd repository of the Kubernetes cluster. The edge node information data is stored using the custom resource definition (CRD) method. The control and management module receives edge node information data from each edge node tunnel agent module from the etcd repository.

[0053] It should be understood that Custom Resource Definitions (CRDs) are a well-known existing method in Kubernetes, allowing users to create custom resource types in a Kubernetes cluster. Once the data structure of this resource is defined, the corresponding information data can be stored under the corresponding data structure type in the etcd repository. Edge node information data is stored in the etcd repository of the Kubernetes cluster, and the control and management module receives edge node information data from the etcd repository. This approach not only leverages the high availability and consistency features of etcd but also facilitates management and access within the Kubernetes environment.

[0054] Furthermore, edge node information data includes, but is not limited to: the network status of the edge node, public IP address, port number, and network performance indicators, including communication latency, bandwidth usage, and packet loss rate.

[0055] It should be noted that the network status of an edge node specifically refers to whether the edge node can connect to the external network (whether it is a purely internal network environment).

[0056] (1.2) STUN server function: The control and management module has the function of STUN server, which can help edge nodes discover their public IP address and port number when they start up; each edge node communicates with the control and management module through the STUN protocol to obtain its network access information and registers the network access information back to the control and management module, wherein the network access information includes public IP address and port number.

[0057] It should be understood that this STUN server function is the foundation for enabling direct communication between nodes, avoiding the latency and bandwidth consumption caused by forwarding through relay servers.

[0058] (1.3) Distributed dynamic routing path decision and optimization: The control and management module calculates the optimal cloud-edge network routing path decision result based on the collected network performance index data, and optimizes and adjusts it in real time according to the changes in the status of network performance index.

[0059] (1.3.1) Constructing a routing path cost model: Perform outlier processing and normalization on all network performance indicators (including latency, bandwidth, packet loss rate, etc.), and construct a routing path cost model based on decision trees by combining historical data of network performance indicators.

[0060] Furthermore, the routing path cost model represents the decision-making process through a tree structure, with each node corresponding to a judgment of a network performance indicator, and each leaf node outputting a predicted path cost value. In the routing path cost model, the cost of each path is obtained through a weighted combination of multiple network performance indicators. By learning historical data of network performance indicators, the routing path cost model identifies the weight of different combinations of network performance indicators on the routing path cost, thereby outputting the corresponding routing path cost for new network performance indicator data.

[0061] (1.3.2) Cloud-edge network routing path cost calculation: The cloud-edge network is regarded as a graph, where the nodes represent cloud nodes or edge nodes in the cloud-edge network, and the edges represent cloud-edge / edge-edge tunnels connecting the nodes; the routing path cost, i.e. the weight of each edge, is calculated according to the routing path cost model.

[0062] (1.3.3) Dynamic decision-making for cloud-edge network routing paths: The minimum spanning tree algorithm is used to find the spanning tree with the minimum sum of edge weights in the cloud-edge network to ensure that the total cost of the entire cloud-edge network is minimized. The routing path corresponding to the spanning tree with the minimum sum of edge weights is the optimal routing path decision result. The decision result will be optimized and adjusted in real time according to the changes in the network performance indicators. Once the calculation shows that the original routing path is no longer the optimal solution, the minimum spanning tree algorithm will be re-executed to update the routing path decision result and obtain the optimal routing path decision result again.

[0063] In this embodiment, as Figure 2 As shown, the tunnel agent module is deployed on each edge node and cloud node to establish network connectivity tunnels between edge nodes. The tunnel agent module uses the IPSec or WireGuard network protocol suite, combined with other edge node information obtained from the control and management module and the optimal cloud-edge / edge-edge routing path, to achieve efficient network connectivity.

[0064] It should be understood that the Tunnel Agent module is a core component of this system. A Tunnel Agent module is deployed on each edge node and cloud node. It can establish network connection tunnels between edge nodes and can collect edge node information, collect network performance indicators using eBPF technology, and establish network connection tunnels based on the real-time decision results of the control and management module.

[0065] It's important to note that IPSec is a complete suite of network protocols, while WireGuard is not a complete suite but a single protocol focused on VPNs. A network protocol suite refers to a collection of network protocols designed to work together, combining IPSec and WireGuard. Each protocol is responsible for a specific task, collectively enabling comprehensive network communication functions from the application layer to the physical layer.

[0066] Furthermore, the tunnel agent module is implemented through the following steps:

[0067] (2.1) Interaction with the Control and Management Module: Before establishing a network connection tunnel, the Tunnel Agent module interacts with the Control and Management Module through the STUN server function to obtain the public IP address and port number of the edge node. This step is a prerequisite for establishing a network tunnel, because only by correctly identifying the public access point of the edge node can cross-network connectivity be ensured.

[0068] Furthermore, the interaction with the control and management module is achieved through the STUN server function of the control and management module, specifically including the following sub-steps:

[0069] (2.1.1) Initialization request: The tunnel agent module sends a binding request message to the STUN server in the control and management module. The binding request message contains the local area network IP address and pre-configured port information of the edge node where the tunnel agent module is located.

[0070] (2.1.2) Receiving Response: After processing the received binding request message, the STUN server in the control and management module returns the public IP address and port number of the edge node. This information reflects the network identity of the edge node through a NAT device (such as a router).

[0071] (2.1.3) Registration information: The Tunnel Agent module will register the obtained public IP address and port number to the control management module for updating the network configuration records of the edge node, so as to ensure that other edge nodes can establish a direct connection to the edge node.

[0072] (2.2) Acquisition and Upload of Network Performance Metrics: The Tunnel Agent module obtains the network access information of the edge nodes from the control and management module, including the public IP address and port number; the Tunnel Agent module obtains the current optimal cloud-edge network routing path decision result from the control and management module, which helps the Tunnel Agent module to establish tunnels; the Tunnel Agent module obtains network performance metrics (including communication latency, packet loss rate, and bandwidth usage) through tools such as ping and iperf; the Tunnel Agent module collects L2 to L4 events (the time spent on key events in layers 2 to 4 of the network protocol stack) using eBPF technology and uploads the network performance metrics data to the control and management module in real time, so that the control and management module can make dynamic optimization decisions on routing paths based on the latest network performance metrics data.

[0073] It should be understood that ping and iperf are both commonly used network diagnostic and testing tools in operating systems, and will not be elaborated on here.

[0074] It should be noted that L2 to L4 events refer to key events in the L2 (data link layer), L3 (network layer), and L4 (transport layer) of the network protocol stack. eBPF technology can capture network activity at each layer at the kernel level without modifying the kernel code.

[0075] (2.3) Tunnel establishment and maintenance: Using IPSec or WireGuard as the underlying technology, based on the obtained edge node information and the optimal cloud-edge network routing path decision results, network connection tunnels are established according to the tunnel establishment rules; the network configuration information of the edge nodes is updated periodically (e.g., every 30 minutes) or upon receiving change instructions from the control and management module, so as to ensure that the configuration of the network connection tunnel is always consistent with the expected network topology, thereby realizing the maintenance of the network connection tunnel.

[0076] Furthermore, using IPSec or WireGuard as the underlying technology, network connectivity tunnels are established based on the acquired edge node information and the optimal cloud-edge network routing path decision results, according to tunnel establishment rules. Specifically, this includes:

[0077] (2.3.1) Prepare connection information: Based on the optimal cloud-edge network routing path decision, prepare the public IP address, port number, key, network protocol type and other relevant network configuration information of the corresponding edge node to be connected.

[0078] (2.3.2) For WireGuard: The edge node sets the public key, allowed IP range and endpoint information of the peer node according to the obtained connection information. The public key is determined according to the key, the allowed IP range is determined according to the edge node's podCIDR, and the endpoint information is determined according to the edge node's public IP address and port number. In addition, the edge node also sets a persistent heartbeat to ensure that the port mapping on the NAT device remains valid.

[0079] It's important to understand that CIDR can be understood as a method of allocating IP addresses. We can use CIDR notation to represent a range of IP addresses. For example, the CIDR block 192.168.1.0 / 24 represents the IP address range from 192.168.1.0 to 192.168.1.255. Pod CIDR, on the other hand, defines the IP address range of Pods in a Kubernetes cluster. For instance, we might use 10.244.0.0 / 16 to represent the IP address space of a Pod in a cluster. Each node in Kubernetes typically obtains a subnet range from the Pod CIDR. For example, if the Pod CIDR is 10.244.0.0 / 16, a node might be allocated 10.244.1.0 / 24 and assign IP addresses to Pods on that node within this subnet range. Therefore, the Pod CIDR here essentially refers to a subnet range allocated to Pods on that node.

[0080] (2.3.3) For IPSec: Use the libreswan tool to configure the network connectivity tunnel. The configuration information in the libreswan tool includes creating security policies, setting encryption parameters, routing configuration, etc., and then start the network connectivity tunnel.

[0081] It should be understood that the libreswan tool is an open-source software package specifically for implementing IPSec. In contrast, WireGuard not only defines the VPN tunneling protocol but also provides the actual VPN software tools.

[0082] For example, in a cloud vendor's edge computing product, before using the network performance-aware cloud-edge container network connectivity and optimization system described in this invention, relay forwarding could only be performed based on the TURN protocol, resulting in low communication performance and high cloud bandwidth. After applying the network performance-aware cloud-edge container network connectivity and optimization system described in this invention, direct communication tunnels between edge containers can be established in suitable scenarios, improving communication performance while reducing cloud bandwidth consumption within the company and lowering costs.

[0083] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cloud-edge container network connectivity and optimization system based on network performance awareness, characterized in that, include: The control and management module is used to centrally manage and store edge node information, and also functions as a STUN server. It evaluates the cost of the current routing path in real time, and makes dynamic decisions and optimizations to obtain the optimal cloud-edge / edge-edge routing path. and The Tunnel Agent module is deployed on each edge node and cloud node to establish network connectivity tunnels between edge nodes. This Tunnel Agent module uses the IPSec or WireGuard network protocol suite, combined with other edge node information obtained from the control and management module and the optimal cloud-edge / edge-edge routing path, to achieve network connectivity. The control and management module is implemented through the following steps: (1.1) Information Reception and Storage: The control and management module receives edge node information data from the tunnel agent modules of each edge node via the HTTP protocol; the edge node information data includes the network status, public IP address, port number and network performance indicators of the edge node; (1.2) STUN server function: The control and management module has the function of STUN server, which can help edge nodes discover their public IP address and port number when they start up; each edge node communicates with the control and management module through the STUN protocol to obtain its network access information and registers the network access information back to the control and management module, wherein the network access information includes public IP address and port number; (1.3) Distributed dynamic routing path decision and optimization: The control and management module calculates the optimal cloud-edge network routing path decision result based on the collected network performance index data, and optimizes and adjusts it in real time according to the changes in the network performance index status; step (1.3) includes the following sub-steps: (1.3.1) Constructing a routing path cost model: Perform outlier processing and normalization on all network performance indicators, and construct a routing path cost model based on decision trees by combining historical data of network performance indicators; (1.3.2) Cloud-edge network routing path cost calculation: The cloud-edge network is regarded as a graph, where the nodes represent cloud nodes or edge nodes in the cloud-edge network, and the edges represent cloud-edge / edge-edge tunnels connecting the nodes; the routing path cost, i.e. the weight of each edge, is calculated according to the routing path cost model. (1.3.3) Dynamic decision-making for cloud-edge network routing paths: The minimum spanning tree algorithm is used to find the spanning tree with the minimum sum of edge weights in the cloud-edge network to ensure that the total cost of the entire cloud-edge network is minimized. The routing path corresponding to the spanning tree with the minimum sum of edge weights is the optimal routing path decision result. The decision result will be optimized and adjusted in real time according to the changes in the network performance indicators. Once the calculation shows that the original routing path is no longer the optimal solution, the minimum spanning tree algorithm will be re-executed to update the routing path decision result and obtain the optimal routing path decision result again. The routing path cost model represents the decision-making process through a tree structure, where each node corresponds to a judgment of a network performance indicator, and each leaf node outputs a predicted path cost value. In the routing path cost model, the cost of each path is obtained through a weighted combination of multiple network performance indicators. By learning historical data of network performance indicators, the routing path cost model identifies the weight of different combinations of network performance indicators on the routing path cost, thereby outputting the corresponding routing path cost for new network performance indicator data.

2. The cloud-edge container network connectivity and optimization system based on network performance awareness according to claim 1, characterized in that, In step (1.1), the edge node information data of each edge node tunnel agent module is stored in the etcd repository of the Kubernetes cluster. The edge node information data is stored using a custom resource definition method. The control and management module receives the edge node information data from each edge node tunnel agent module from the etcd repository.

3. The cloud-edge container network connectivity and optimization system based on network performance awareness according to claim 1, characterized in that, The network performance metrics include communication latency, bandwidth usage, and packet loss rate.

4. The cloud-edge container network connectivity and optimization system based on network performance awareness according to claim 1, characterized in that, The tunnel agent module is implemented through the following steps: (2.1) Interact with the control and management module: Before establishing a network connection tunnel, the tunnel agent module interacts with the control and management module through the STUN server function of the control and management module to obtain the public IP address and port number of the edge node itself; (2.2) Acquisition and Upload of Network Performance Metrics: The Tunnel Agent module obtains the network access information of the edge nodes from the control and management module, including the public IP address and port number; the Tunnel Agent module obtains the current optimal cloud-edge network routing path decision result from the control and management module; the Tunnel Agent module obtains network performance metrics through ping and iperf tools; the Tunnel Agent module collects L2 to L4 events using eBPF technology; and uploads the network performance metrics data to the control and management module in real time, so that the control and management module can make dynamic optimization decisions on routing paths based on the latest network performance metrics data; (2.3) Tunnel establishment and maintenance: Using IPSec or WireGuard as the underlying technology, based on the obtained edge node information and the optimal cloud-edge network routing path decision results, network connection tunnels are established according to the tunnel establishment rules; the network configuration information of the edge nodes is updated periodically or upon receiving change instructions from the control and management module to ensure that the configuration of the network connection tunnel is always consistent with the expected network topology, thereby achieving the maintenance of the network connection tunnel.

5. The cloud-edge container network connectivity and optimization system based on network performance awareness according to claim 4, characterized in that, The interaction with the control management module through the STUN server function of the control management module specifically includes the following sub-steps: (2.1.1) Initialization request: The tunnel agent module sends a binding request message to the STUN server in the control and management module. The binding request message contains the local area network IP address and pre-configured port information of the edge node where the tunnel agent module is located. (2.1.2) Receiving response: After processing the received binding request message, the STUN server in the control and management module returns the public IP address and port number of the edge node; (2.1.3) Registration information: The Tunnel Agent module will register the obtained public IP address and port number to the control management module for updating the network configuration records of the edge node, so as to ensure that other edge nodes can establish a direct connection to the edge node.

6. The cloud-edge container network connectivity and optimization system based on network performance awareness according to claim 4, characterized in that, The use of IPSec or WireGuard as the underlying technology, based on the obtained edge node information and the optimal cloud-edge network routing path decision results, establishes network connectivity tunnels according to tunnel establishment rules, specifically including: (2.3.1) Prepare connection information: Based on the optimal cloud-edge network routing path decision result, prepare the public IP address, port number, key, and network protocol type of the corresponding edge node to be connected; (2.3.2) For WireGuard: The edge node sets the public key, allowed IP range and endpoint information of the peer node according to the obtained connection information. The public key is determined according to the key, the allowed IP range is determined according to the edge node's pod CIDR, and the endpoint information is determined according to the edge node's public IP address and port number. In addition, the edge node also sets a persistent heartbeat to ensure that the port mapping on the NAT device remains valid. (2.3.3) For IPSec: Use the libreswan tool to configure the network connectivity tunnel. The configuration information in the libreswan tool includes creating security policies, setting encryption parameters, configuring routes, and then starting the network connectivity tunnel.

Images