A cross-cluster device access system and method suitable for edge computing environment

Abstract

The present invention relates to a cross-cluster device access system and method suitable for edge computing environments, which belongs to the field of edge computing and computer networks. It mainly solves the problem that cross-cluster device access cannot be achieved efficiently and securely in scenarios such as physical isolation of edge clusters, limited network resources, and dynamic changes in devices. The system includes an upper-level cluster connector component deployed in an upper-level cluster and a lower-level cluster connector component deployed in a lower-level cluster. The upper-level cluster connector includes a cluster controller and a service relay agent, which are responsible for device registration, DNS resolution, and request forwarding; the lower-level cluster connector includes a cluster agent and a device relay agent, which are responsible for device information synchronization and data packet processing. Compared with the existing technology, the present invention has the advantages of lightweight deployment, efficient communication, safe and reliable, and transparent service. It is suitable for edge computing scenarios such as drone clusters, intelligent manufacturing, and post-disaster communications, and can significantly improve device access efficiency and resource coordination capabilities.

Description

Technical Field

[0001] The present invention relates to the fields of edge computing and computer networks, and in particular to a cross-cluster device access system and method suitable for an edge computing environment. Background Art

[0002] In a typical edge computing environment, IoT devices offload computations and share resources through local edge clusters or nodes. However, in real-world applications (such as large-scale drone collaboration), devices are often distributed across multiple heterogeneous clusters due to physical geographic distribution or network isolation, rendering traditional single-cluster access and scheduling strategies ineffective. Existing cross-cluster communication solutions are mostly designed for cloud data centers and rely on resource-intensive tunneling (such as VPNs) or service meshes, making them difficult to adapt to resource-constrained edge environments. For example, CN116010111A discloses a cross-cluster resource scheduling method, system, and terminal device. The cross-cluster resource scheduling method includes: the resource controller deployed on the master node reads the cluster configuration information of each cluster stored in the Secret object obtained by the resource controller, and determines the cluster to which the resource to be scheduled belongs; based on the user information of the determined cluster, the resource scheduling service of the corresponding cluster is called to schedule the resource to be scheduled and record the node resource affinity value of the resource to be scheduled. When the resource to be scheduled is scheduled by the scheduler deployed by the master node, the Pod is scheduled to the slave node that matches the node resource affinity value. The node resource affinity value is defined by the node key value field and the matching logic. This method is not suitable for resource-constrained edge environments. At the same time, cross-cluster access to IoT devices needs to take into account both security and access efficiency, which places higher requirements on the system architecture and network forwarding mechanism. Summary of the Invention

[0003] The purpose of the present invention is to provide a cross-cluster device access system and method suitable for edge computing environments with limited resources and strong network dynamics, to build a distributed cluster topology model, and through efficient data path design, to achieve transparent access of upper-level cluster services to lower-level cluster devices, while taking into account the system's easy deployment, low resource consumption and high access efficiency.

[0004] The purpose of the present invention can be achieved by the following technical solutions:

[0005] A cross-cluster device access system for an edge computing environment, comprising:

[0006] An upper-level cluster connector component deployed in an upper-level cluster and a lower-level cluster connector component deployed in a lower-level cluster, wherein:

[0007] The upper-level cluster connector component includes:

[0008] The cluster controller receives synchronization information from lower-level cluster nodes and devices, generates a cluster topology information model, and configures the DNS service of the upper-level cluster.

[0009] The service relay agent receives device access requests from services within the upper-level cluster and forwards the requests to the corresponding lower-level cluster.

[0010] The lower-level cluster connector component includes:

[0011] The cluster agent monitors node and device information changes on the lower-level cluster API server and periodically reports changes after establishing an authenticated connection with the cluster controller.

[0012] The device relay agent is used to receive device access requests from the service relay agent and rewrite and forward the destination address of the data packet.

[0013] The cluster controller establishes a mapping relationship between the device name and the IP address of the node where the service relay agent is located, and implements DNS resolution of the device name by modifying the configuration file of the cluster DNS server.

[0014] The service relay agent and the device relay agent both use the eBPF Map data structure to maintain the mapping relationship between the request port and the target device.

[0015] The service relay agent and device relay agent both forward device request packets through the eBPF XDP program bound to the network card, including: intercepting packets sent to a specific port; querying the mapping table to obtain the target device address; rewriting the source and destination MAC, IP and port information; and forwarding to the corresponding physical network card.

[0016] The communication between the cluster agent and the cluster controller is based on a certificate authentication mechanism and supports periodic automatic rotation of certificates.

[0017] The system adopts a cluster topology model to realize the registration and synchronization of devices in a nested structure.

[0018] A cross-cluster device access method suitable for an edge computing environment includes the following steps:

[0019] Cluster information synchronization phase: The cluster agent reports information about lower-level cluster nodes and devices to the cluster controller and builds a cluster topology model for unified resource representation.

[0020] Access preparation phase: The cluster controller adds device resolution records to the cluster DNS service. The service relay agent and device relay agent maintain the mapping relationship between the port and the target device or service.

[0021] During cross-cluster access, the service relay agent forwards traffic between the upper-level service and the lower-level cluster. It forwards device access requests initiated by services within the upper-level cluster to the corresponding device relay agent and transmits the response. The device relay agent handles traffic between lower-level devices and the upper-level cluster, dynamically rewriting and forwarding the packet's destination address to achieve efficient forwarding of device access requests and a closed-loop response loop.

[0022] The cluster topology model is defined as a cluster topology structure, which adopts a nested design and includes:

[0023] Cluster field: Indicates basic information about the current cluster, including a node list and a device list. The node list describes the identification, capabilities, and location information of all computing nodes; the device list describes the name, logical port number, and attribute key-value pairs of each device.

[0024] Subordinates field: indicates the list of subordinate clusters of the current cluster, using a recursive nested structure to support the description capability of multi-level clusters.

[0025] During the access preparation phase, device registration and resolution are achieved through the following steps:

[0026] Device information acquisition: The cluster agent regularly monitors the API server of the lower-level cluster to obtain device information in the lower-level cluster, including device name, type, actual device port number, and capability description;

[0027] Generate topology objects and report them: Based on the acquired information, the cluster agent constructs cluster topology objects based on the cluster topology model, obtains the structured information of the devices, and reports it to the cluster controller;

[0028] Service access registration: After the upper-level cluster is started, the service relay agent reports its own IP address to the cluster controller as the target address for the device name DNS mapping;

[0029] DNS configuration modification: Based on the received device structured information and service relay agent address, the cluster controller generates DNS resolution rules in the cluster's DNS server, mapping the lower-level device name to the service relay agent's IP address, thereby supporting service access under unified naming;

[0030] Mapping table construction: The cluster agent sends the device's structured information to the device relay agent on the local node. The device relay agent builds a mapping table to map the device's logical port to the actual device address.

[0031] The cross-cluster access phase includes two steps: request forwarding and device response:

[0032] Request forwarding: The internal service of the upper cluster initiates a device access request; the device access request is parsed into the service relay agent IP and device logical port; the service relay agent determines the redirection port of the target device relay agent based on the requested device logical port and service information, and saves the original service address information; the service relay agent uses the forwarding port to send the data packet to the supNIC network interface bound to the XDP program; the XDP program intercepts the data packet at the supNIC, obtains the actual device address by querying the mapping table, and modifies the data packet header; the modified data packet is sent to the lower cluster network via the subNIC network interface; the target device receives the request and executes the task; wherein, the supNIC and subNIC are the network cards on the node where the lower cluster connector component is located, which are connected to the upper cluster and the lower cluster respectively;

[0033] Response return: The target device sends the response result back to the subNIC; the XDP program on the subNIC captures the device's response data packet; rewrites the target IP and target MAC address of the response data packet to the IP and MAC information of the service relay agent; forwards the response data packet to the service relay agent through the supNIC network interface; the service relay agent looks up the original address information of the service and forwards the device response data packet to the original service, completing a complete cross-cluster device call process.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] (1) Simple deployment and low operation and maintenance costs: Each cluster only needs to deploy a lightweight connector component (upper cluster connector or lower cluster connector), avoiding the introduction of sidecar or proxy services in each node or pod, greatly simplifying system deployment and subsequent maintenance. This feature is particularly suitable for resource-constrained edge computing environments, effectively reducing resource usage and operation and maintenance complexity.

[0036] (2) Efficient communication and low performance overhead: This invention leverages eBPF / XDP technology to implement packet capture and forwarding operations in kernel mode, avoiding frequent user-mode and kernel-mode switching and significantly reducing processing latency and CPU usage. Compared to traditional user-mode proxy-based solutions, this invention offers higher forwarding throughput and lower response latency, making it suitable for edge device interaction scenarios with high real-time requirements.

[0037] (3) Safe and controllable, with a complete mechanism: The present invention uses a two-way certificate authentication mechanism to ensure the authenticity and credibility of the identities of both communicating parties. Combined with a regular certificate rotation strategy, it can effectively prevent security risks such as man-in-the-middle attacks and identity theft that may exist during the communication process, ensuring that cross-cluster communication is carried out within a controllable trust boundary.

[0038] (4) Transparent access, no business awareness: This invention combines the DNS service discovery mechanism to provide unified service name resolution and access path mapping for upper-layer applications, enabling cross-cluster service access without modifying business logic. This mechanism is completely transparent to the application layer, significantly reducing system transformation costs and business access barriers.

[0039] (5) Support for multi-level topology and adaptability to master-slave architecture: This invention designs a hierarchical structure that supports multi-level clusters. Multiple lower-level clusters can be connected under a higher-level cluster to form a master-slave edge computing topology. The higher-level cluster can uniformly manage the device resources and service status within the lower-level clusters, facilitating centralized scheduling and operation and maintenance.

[0040] (6) Strong scalability and support for subsequent evolution: This invention has good scalability and can be further expanded into a complete cross-cluster service access and resource sharing mechanism. Its basic capabilities provide solid support for the subsequent implementation of functional modules such as device scheduling optimization, service discovery collaboration, and resource-aware distribution, and it has good room for evolution. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a system structure diagram of the present invention;

[0042] Figure 2 This is a schematic diagram of the device registration and parsing process of the present invention;

[0043] Figure 3 Schematic diagram of the request forwarding process in cross-cluster device access of the present invention;

[0044] Figure 4 Schematic diagram of the response return process in cross-cluster device access according to the present invention. DETAILED DESCRIPTION

[0045] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.

[0046] Example 1

[0047] In edge computing systems, clusters are usually distributed in different local area networks and have the characteristics of decentralized resources, strong network dynamics, and high device heterogeneity. Traditional cross-cluster communication methods rely on VPN or tunnel technology, which are complex to deploy, inefficient, and have high maintenance costs. They are difficult to meet the needs of low-latency, high-availability device access in actual scenarios. Based on this, this embodiment provides a cross-cluster device access system for edge computing environments, such as Figure 1 Shown, including:

[0048] An upper-level cluster connector component deployed in an upper-level cluster and a lower-level cluster connector component deployed in a lower-level cluster, wherein:

[0049] The upper-level cluster connector component is responsible for device registration, DNS resolution, and request forwarding, including:

[0050] The cluster controller receives synchronization information from lower-level cluster nodes and devices, generates a cluster topology information model, and configures the DNS service of the upper-level cluster.

[0051] The service relay agent receives device access requests from services within the upper-level cluster and forwards the requests to the corresponding lower-level cluster.

[0052] The lower-level cluster connector component is responsible for device information synchronization and data packet processing for device requests and responses, including:

[0053] The cluster agent monitors node and device information changes on the lower-level cluster API server and periodically reports changes after establishing an authenticated connection with the cluster controller.

[0054] The device relay agent is used to receive device access requests from the service relay agent and rewrite and forward the destination address of the data packet.

[0055] In a preferred embodiment, the cluster controller establishes a mapping relationship between the device name and the IP address of the node where the service relay agent is located, and implements DNS resolution of the device name by modifying the configuration file of the cluster DNS server. For details on the specific implementation method, see Example 2.

[0056] In one embodiment, both the service relay agent and the device relay agent use the eBPF Map data structure to maintain the mapping between the requested port and the target device. This approach offers the following technical advantages: 1) Dynamic, real-time effectiveness: Device routing rules are updated in real time by userspace, with changes taking effect in seconds without requiring a kernel restart or reload, significantly improving adaptability to frequent device changes in edge environments. 2) Zero port resource usage: By storing the mapping between devices and target IP addresses in the eBPF Map, the traditional approach of binding a separate port to each device is eliminated, saving over 90% of system port resources. 3) Cross-space zero-copy communication: Userspace and kernelspace exchange data by sharing the eBPF Map, avoiding data serialization and inter-process communication (IPC) overhead and improving interaction efficiency. 4) Highly concurrent and secure read and write: The eBPF Map supports atomic concurrent operations, ensuring high-performance and secure updates of routing maps in scenarios with tens of thousands of devices. 5) Nanosecond query performance: Leveraging a kernel-optimized hash structure, extremely low-latency queries of device routing tables are achieved, reducing query latency by over a hundred times compared to traditional user-space solutions.

[0057] Both the service relay agent and the device relay agent efficiently forward device access request and response packets by binding the eBPF XDP program to the physical network interface card (NIC). This process includes the following steps: 1) NIC binding and program mounting: The customized eBPF XDP program is mounted to the driver layer entry point of the designated physical NIC to prioritize the interception and processing of incoming packets, ensuring that the forwarding logic is implemented at the earliest possible kernel stage, reducing latency. 2) Packet identification and classification: The program identifies the destination port field (such as the preset device proxy port and the preset service relay port) to distinguish device access packets to be forwarded. 3) Target information query: Using the port in the packet as a query key, the corresponding eBPF map is accessed to retrieve the corresponding target MAC address, IP address, and target service port. 4) Kernel-level packet rewriting: Ethernet, IP, and TCP / UDP header fields are directly modified in kernel mode to replace the destination and source addresses. 5) Packet forwarding: Kernel APIs such as bpf_redirect() are called to send the rewritten packet to the destination physical NIC queue, achieving low-latency and uninterrupted data link forwarding.

[0058] Communication between the cluster agent and the cluster controller is based on a certificate authentication mechanism, supporting periodic automatic certificate rotation to ensure communication security and long-term availability during cross-cluster connections. This communication process includes the following steps: 1) Identity authentication: The cluster agent initiates an identity authentication request to the certificate authority (CA) deployed by the cluster controller to verify its legitimacy. After authentication, the cluster controller issues a dedicated communication certificate to the cluster agent; 2) Encrypted connection establishment: The cluster agent uses the issued certificate to establish an encrypted communication connection with the cluster controller to achieve identity trust and data encryption transmission of the communication link; 3) Initial information synchronization: The cluster agent obtains the node and device information in the lower-level cluster it is connected to, and synchronizes this information to the cluster controller. The latter generates and maintains the corresponding cluster topology resource objects in the upper-level cluster based on the received content; 4) Event monitoring: The cluster agent continuously monitors the API server of the lower-level cluster, including events such as node status changes and device offline and online, to capture dynamic updates of the topology structure; 5) Topology information synchronization: After monitoring the cluster change event, the cluster agent updates the local topology status in real time and synchronizes the change information to the cluster controller, thereby enabling the upper cluster to accurately and continuously perceive the topology structure of the lower cluster.

[0059] In this embodiment, a cluster topology model is used to implement device registration and synchronization in a nested structure. The specific implementation method is described in Example 2, and this embodiment will not be repeated here.

[0060] The system is suitable for device access scenarios where there is network isolation between edge clusters. It does not require pre-allocation of service ports or establishment of tunnel connections.

[0061] Example 2

[0062] This embodiment provides a cross-cluster device access method applicable to an edge computing environment, including the following steps:

[0063] Cluster information synchronization phase: The cluster agent reports the information of lower-level cluster nodes and devices to the upper-level cluster controller and builds a cluster topology model for unified resource representation;

[0064] Access preparation phase: The cluster controller adds device resolution records to the cluster DNS service. The service relay agent and device relay agent maintain the mapping relationship between the port and the target device or service.

[0065] During cross-cluster access, the service relay agent forwards access traffic between the upper-level cluster service and the lower-level cluster. It forwards device access requests initiated by services within the upper-level cluster to the corresponding device relay agent and transmits the response results. The device relay agent handles communication traffic between lower-level devices and the upper-level cluster. By dynamically rewriting the destination address of data packets, it achieves rapid forwarding of device requests and a closed-loop response loop, ensuring efficient and reliable cross-cluster access.

[0066] This embodiment proposes a hierarchical modeling approach for uniformly representing node resources, device resources, and the logical affiliations between clusters in an edge cluster. This model is defined as a recursively nested cluster topology structure (ClusterTopology). Its core fields include the following: 1) The Cluster field describes the static and dynamic resource information of the current cluster. Specifically, it includes: a NodeList, which records the identifiers of each compute node in the cluster (e.g., node name, user identifier), and attribute key-value pairs (e.g., resource capabilities such as CPU, memory, and network bandwidth, as well as location information such as geographic location or network topology); and a DeviceList, which records heterogeneous device information in the cluster, including device name, device logical port number, and attribute key-value pairs (e.g., sensor type, sampling period, and interface protocol), supporting flexible device expansion and description. 2) The Subordinates field describes all subordinate clusters within the current cluster. This field is a ClusterTopology list, thus constructing a multi-level nested topology. This field is recursively defined, enabling dynamic expression of multi-level cluster structures of arbitrary depth, supporting complex distributed organizational structures in edge environments.

[0067] This model features support for multi-tiered cluster structures, dynamic updates, seamless integration with the Kubernetes API server (registration and updates are performed using CRDs), and flexible expansion of heterogeneous devices. This structured model provides the technical foundation for hierarchical management and unified scheduling of edge resources, and is a core component for achieving cross-cluster resource collaboration.

[0068] The following is a schematic diagram of the three-tier cluster structure:

[0069] Cluster:

[0070] Name: "Cluster1"

[0071] NodeList:

[0072] - NodeID: "NodeA"

[0073] Properties:

[0074] CPU: 8

[0075] Mem: 16Gi

[0076] Location: "building1"

[0077] DeviceList:

[0078] - DeviceName: "Cam01.device.Cluster1"

[0079] Port: 8080

[0080] Properties:

[0081] Type: "Camera"

[0082] FPS: 30

[0083] - DeviceName: "Cam02.device.Cluster1"

[0084] Port: 8081

[0085] Properties:

[0086] Type: "Camera"

[0087] FPS: 30

[0088] Subordinates:

[0089] - Cluster:

[0090] Name: "SubCluster-1"

[0091] NodeList:

[0092] - NodeID: "NodeB"

[0093] Properties:

[0094] CPU: 4

[0095] Mem: 8Gi

[0096] Location: "building2"

[0097] DeviceList:

[0098] - DeviceName: "Temp01.device.SubCluster-1"

[0099] Port: 3000

[0100] Properties:

[0101] Type: "Thermometer"

[0102] Interval: "5s"

[0103] Subordinates:

[0104] - Cluster:

[0105] Name: "SubCluster-1-1"

[0106] NodeList:

[0107] - NodeID: "NodeC"

[0108] Properties:

[0109] CPU: 2

[0110] Mem: 4Gi

[0111] Location: "building3"

[0112] DeviceList:

[0113] - DeviceName: "PLC01.device.SubCluster-1-1"

[0114] Port: 4000

[0115] Properties:

[0116] Type: "PLC"

[0117] Protocol: "Modbus"

[0118] Subordinates: []

[0119] This structure shows that the root cluster contains a lower-level cluster, SubCluster-1, which in turn contains its subcluster, SubCluster-1-1. Each level of cluster can independently maintain a list of nodes and devices, and a complete hierarchical link can be constructed through the subcluster field.

[0120] During the visit preparation phase, Figure 2 As shown, device registration and resolution are achieved through the following steps:

[0121] ① Obtaining lower-level cluster device information: The cluster agent regularly monitors the API server of the lower-level cluster to obtain device information in the current cluster, including device name, type, actual access address and port (for example, the access method for device 1 is nip1:nport1, where nip1 represents the device's IP address and nport1 represents the access port), as well as device capability descriptions.

[0122] ② Generate and report topology objects: Based on the information obtained, the cluster agent constructs a cluster topology object containing nodes, devices, and subordinate clusters based on the cluster topology model, and reports it to the cluster controller as a custom resource (CRD). The information in the device list is a structured reorganization of the original device data, including the generated domain name format device name (for example, device 1 in cluster 1 is named "device 1.device.cluster 1"), the assigned device logical port number (for example, the logical port corresponding to device 1 is "device logical port number 1"), and other content to facilitate unified management and subsequent service mapping;

[0123] ③Service relay agent registration: After the upper-level cluster is started, the service relay agent automatically reports its own IP address and listening port information to the cluster controller as the target address for device name DNS resolution to support cross-cluster access traffic forwarding;

[0124] ④ Modify the upper-level cluster DNS configuration: The cluster controller generates a DNS resolution rule in the cluster's DNS server (such as CoreDNS) based on the received device structured information and service relay agent address. This rule uniformly maps the name of each lower-level cluster device to the IP address of the corresponding service relay agent, achieving transparent access based on the device's global naming.

[0125] ⑤ Mapping table construction: The cluster agent sends the structured information of the device to the device relay agent. The relay agent builds an eBPF mapping table called DstMap based on the received device logical port information. This mapping table establishes a mapping relationship between the device logical port and the physical address of the actual device (for example, device logical port 1 corresponds to device 1's IP address nip1 and port number nport1), thereby achieving high-performance, low-latency packet forwarding.

[0126] Through the above mechanism, the present invention realizes automatic registration of devices, DNS name resolution and forwarding information configuration, laying the foundation for transparent access to device resources across clusters.

[0127] This embodiment uses XDP technology to achieve cross-cluster device access. By deploying two components, service relay agent and device relay agent, on the nodes connecting the upper and lower clusters, combined with XDP technology, low-latency, high-performance access from the upper cluster service to the lower cluster devices is achieved.

[0128] The cross-cluster access phase includes two steps: request forwarding and device response.

[0129] like Figure 3 As shown in the figure, the XDP program used to forward traffic in the service relay agent is called xdp-redirect-pod. The XDP program bound to the device relay agent connected to the upper-level cluster NIC (supNIC) is xdp-redirect-request, which handles information rewriting of device request packets. The XDP program bound to the lower-level cluster NIC (subNIC) is xdp-redirect-response, which handles information rewriting of device response packets. Assuming the service initiating the device request is called service 1 and the target device is called device 1, request forwarding includes the following steps:

[0130] ① Service 1 in the upper-level cluster initiates a device access request (the request format is "device name: device logical port", such as "device 1.device.cluster 1: device logical port 1"). This request is first sent to the cluster's DNS server for domain name resolution.

[0131] ②The DNS server resolves the device name to the service relay agent IP;

[0132] ③ Service 1 sends a device request message to the service relay agent;

[0133] ④ The service relay agent generates a forwarding port (i.e., service logical port 1) based on the original network message of service 1 and the device logical port (e.g., device logical port 1), and saves the mapping relationship between the forwarding port and service information through the eBPF Map (SrcMap);

[0134] ⑤ The service relay agent sets the destination address of the device request packet to the address of the supNIC (the network card in the lower cluster that is connected to the upper cluster) on the node where the lower cluster connector is located, and forwards the packet to the supNIC through the forwarding port (service logical port 1);

[0135] ⑥The XDP program on the supNIC intercepts the data packet and obtains the actual access address of the device (including IP, MAC, and actual port of the device) by querying the eBPF Map (i.e., DstMap) in the mapping table;

[0136] ⑦The XDP program uses eBPF Map (PortMap) to save the correspondence between the source port (service logical port 1) and the destination port (device logical port 1), and modifies the destination information of the data packet to the actual access address of the target device, and sends it to the target device (i.e., device 1) through the subNIC;

[0137] ⑧The target device receives the request and performs the task, such as image acquisition, execution of actions, etc.

[0138] like Figure 4 As shown in the figure, the service that initiates the device request is called Service 1, and the target device is called Device 1. The response backhaul includes the following steps:

[0139] ① Device 1 sends the response back to the network card of the lower-level cluster, that is, subNIC;

[0140] ②The XDP program on the subNIC captures the device response data packet and obtains the corresponding device logical port (device logical port 1) by querying the eBPF Map (PortMap);

[0141] The XDP program on the subNIC modifies the destination address of the device's response packet to the service relay agent address, sets the source IP address to the supNIC's IP address (supNICIP), and sets the source port to the device's logical port (device logical port 1).

[0142] ④Forward the device response data packet to the service relay agent via the supNIC network interface;

[0143] ⑤ The service relay agent retrieves the original network information of service 1 from the eBPF Map (SrcMap) and sets it as the destination information of the response packet;

[0144] ⑥The service relay agent forwards the device response data packet to service 1, completing a complete cross-cluster device call process.

[0145] The above describes in detail the preferred embodiments of the present invention. It should be understood that those skilled in the art can make numerous modifications and variations based on the concepts of the present invention without inventive effort. Therefore, any technical solutions that can be derived by those skilled in the art through logical analysis, reasoning, or limited experimentation based on the concepts of the present invention and the prior art should be within the scope of protection defined by the claims.

Claims

1. A cross-cluster device access system suitable for edge computing environment, characterized in that: include: An upper-level cluster connector component deployed in an upper-level cluster and a lower-level cluster connector component deployed in a lower-level cluster, wherein: The upper-level cluster connector component includes: The cluster controller receives synchronization information from lower-level cluster nodes and devices, generates a cluster topology information model, and configures the DNS service of the upper-level cluster. The service relay agent receives device access requests from services within the upper-level cluster and forwards the requests to the corresponding lower-level cluster. The lower-level cluster connector component includes: The cluster agent monitors node and device information changes on the lower-level cluster API server and periodically reports changes after establishing an authenticated connection with the cluster controller. The device relay agent is used to receive device access requests from the service relay agent and rewrite and forward the destination address of the data packet; Among them, the service relay agent and device relay agent both forward device request data packets through the eBPF XDP program bound to the network card, including: intercepting data packets sent to a specific port; querying the mapping table to obtain the target device address; rewriting the source and destination MAC, IP and port information; and forwarding to the corresponding physical network card.

2. A cross-cluster device access system suitable for edge computing environment according to claim 1, characterized in that: The cluster controller establishes a mapping relationship between the device name and the IP address of the node where the service relay agent is located, and implements DNS resolution of the device name by modifying the configuration file of the cluster DNS server.

3. A cross-cluster device access system suitable for edge computing environment according to claim 1, characterized in that: The service relay agent and the device relay agent both use the eBPF Map data structure to maintain the mapping relationship between the request port and the target device.

4. A cross-cluster device access system suitable for edge computing environment according to claim 1, characterized in that: The communication between the cluster agent and the cluster controller is based on a certificate authentication mechanism and supports periodic automatic rotation of certificates.

5. A cross-cluster device access system suitable for edge computing environment according to claim 1, characterized in that: The system adopts a cluster topology model to realize the registration and synchronization of devices in a nested structure.

6. A cross-cluster device access method suitable for edge computing environment, characterized in that: The following steps are involved: Cluster information synchronization phase: The cluster agent reports information about lower-level cluster nodes and devices to the cluster controller and builds a cluster topology model for unified resource representation. Access preparation phase: The cluster controller adds device resolution records to the cluster DNS service. The service relay agent and device relay agent maintain the mapping relationship between the port and the target device or service. Cross-cluster access phase: The service relay agent is responsible for forwarding traffic between the upper-level service and the lower-level cluster. It forwards device access requests initiated by services in the upper-level cluster to the corresponding device relay agent and is responsible for returning the response results. The device relay agent is responsible for handling the communication traffic between the lower-level devices and the upper-level cluster. By dynamically rewriting and forwarding the destination address of the data packet, it realizes the efficient forwarding of device access requests and the closed loop of the response circuit; The cluster topology model is defined as a cluster topology structure, which adopts a nested design and includes: Cluster field: Indicates basic information about the current cluster, including a node list and a device list. The node list describes the identification, capabilities, and location information of all computing nodes; the device list describes the name, device logical port number, and attribute key-value pairs of each device. Subordinates field: indicates the list of subordinate clusters of the current cluster, using a recursive nested structure to support the description capability of multi-level clusters.

7. A cross-cluster device access method suitable for edge computing environment according to claim 6, characterized in that: During the access preparation phase, device registration and resolution are achieved through the following steps: Device information acquisition: The cluster agent regularly monitors the API server of the lower-level cluster to obtain device information in the lower-level cluster, including device name, type, actual device port number, and capability description; Generate topology objects and report them: Based on the acquired information, the cluster agent constructs cluster topology objects based on the cluster topology model, obtains the structured information of the devices, and reports it to the cluster controller; Service access registration: After the upper-level cluster is started, the service relay agent reports its own IP address to the cluster controller as the target address for the device name DNS mapping; DNS configuration modification: Based on the received device structured information and service relay agent address, the cluster controller generates DNS resolution rules in the cluster's DNS server, mapping the lower-level device name to the service relay agent's IP address, thereby supporting service access under unified naming; Mapping table construction: The cluster agent sends the device's structured information to the device relay agent on the local node. The device relay agent builds a mapping table to map the device's logical port to the actual device address.

8. A cross-cluster device access method suitable for edge computing environment according to claim 6, characterized in that: The cross-cluster access phase includes two steps: request forwarding and device response: Request forwarding: The upper-level cluster internal service initiates a device access request; the device access request is parsed into the service relay agent IP and device logical port; the service relay agent determines the redirection port of the target device relay agent based on the requested device logical port and service information, and saves the original service address information; the service relay agent uses the forwarding port to send the data packet to the supNIC network interface bound to the XDP program; the XDP program intercepts the data packet on the supNIC, obtains the actual device address by querying the mapping table, and modifies the data packet header; the modified data packet is sent to the lower-level cluster network via the subNIC network interface; The target device receives the request and executes the task; wherein the supNIC and subNIC are network cards on the node where the lower-level cluster connector component is located, which are connected to the upper-level cluster and the lower-level cluster respectively; Response return: The target device sends the response result back to the subNIC; the XDP program on the subNIC captures the device's response data packet; rewrites the target IP and target MAC address of the response data packet to the IP and MAC information of the service relay agent; forwards the response data packet to the service relay agent through the supNIC network interface; the service relay agent looks up the original address information of the service and forwards the device response data packet to the original service, completing a complete cross-cluster device call process.

Images