Data packet processing method and apparatus, and electronic device and storage medium

Abstract

Provided in the embodiments of the present disclosure are a data packet processing method and apparatus, and an electronic device and a storage medium, which are applied to an internal load balancing node of a service cluster. The method specifically comprises: receiving, by means of a service exposure port of an internal load balancing node, a request data packet forwarded by an external load balancing node of a service cluster, wherein the request data packet is initiated by a client and sent to the external load balancing node; parsing standard header fields of the request data packet to obtain address information of the client, and parsing optional header fields of the request data packet to obtain address information of the external load balancing node; forwarding the request data packet to a container instance, and acquiring a response data packet fed back after the container instance processes the request data packet; performing address translation processing on the response data packet, such that source address information of the response data packet is the address information of the external load balancing node, and destination address information is the address information of the client; and sending the translated response data packet to the client by means of the service exposure port.

Description

Data packet processing methods, apparatuses, electronic devices and storage media

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411733721.3, filed on November 28, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of network communication technology, and in particular to a data packet processing method, apparatus, electronic device, and storage medium. Background Technology

[0004] Data center-based clusters currently have two network types: physical networks (Underlay) and virtual networks (Overlay). Physical networks consist of various physical devices connected by physical links. In a physical network, the cluster's network topology is flat, internal addresses are visible to the outside world, and there is direct communication between the inside and outside of the cluster. Virtual networks, on the other hand, are virtual logical networks built on top of physical networks using technologies such as tunneling encapsulation. Because virtual networks run on top of physical networks and use tunneling technology for encapsulation, internal addresses are not visible to the outside world, and there is no direct communication between the inside and outside of the cluster.

[0005] In the process of realizing this disclosure, the inventors discovered that if a cluster built using a virtual network is to perform centralized load balancing, since the cluster cannot communicate directly with the outside world, an external load balancer is required. This requires bidirectional data packet processing on the external load balancer, which introduces additional network latency and resource consumption. The processing capacity of the external load balancer will become a system bottleneck, resulting in poor performance. Summary of the Invention

[0006] This disclosure provides a data packet processing method, apparatus, electronic device, and storage medium that enable centralized load balancing in a cluster constructed in a virtual network, using a direct return mode that does not require external load balancing nodes to return packets, thereby improving network performance.

[0007] In a first aspect, the data packet processing method provided in this disclosure is applied to an internal load balancing node of a service cluster, wherein the internal load balancing node includes a service exposure port, and the data packet processing method includes:

[0008] The service receives request packets forwarded by the external load balancer node of the service cluster through the service exposure port. The request packets are initiated by the client and sent to the external load balancer node.

[0009] The address information of the client is obtained by parsing the standard fields in the header of the request data packet, and the address information of the external load balancer node is obtained by parsing the optional fields in the header of the request data packet.

[0010] The request data packet is forwarded to the mounted container instance, and the response data packet returned by the container instance after processing the request data packet is obtained.

[0011] The response data packet is subjected to address translation processing so that the source address information of the response data packet is the address information of the external load balancing node, and the destination address information of the response data packet is the address information of the client.

[0012] The converted response data packet is sent to the client through the service's exposed port.

[0013] Secondly, the packet processing apparatus provided in this disclosure is applied to an internal load balancing node of a service cluster, the internal load balancing node including a service exposure port, and the packet processing apparatus comprising:

[0014] The receiving module is used to receive request data packets forwarded by the external load balancing node of the service cluster through the service exposure port. The request data packets are initiated by the client and sent to the external load balancing node.

[0015] The parsing module is used to parse the standard header fields of the request data packet to obtain the address information of the client, and to parse the optional header fields of the request data packet to obtain the address information of the external load balancer node.

[0016] The transmission module is used to forward the request data packet to the mounted container instance and obtain the response data packet returned by the container instance after processing the request data packet;

[0017] The address translation module is used to perform address translation processing on the response data packet so that the source address information of the response data packet is the address information of the external load balancing node, and the destination address information of the response data packet is the address information of the client.

[0018] The sending module is used to send the converted response data packet to the client through the service exposure port.

[0019] Thirdly, the electronic device provided in the embodiments of this disclosure includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the data packet processing method as described in any embodiment of this disclosure.

[0020] Fourthly, the computer-readable storage medium provided in the embodiments of this disclosure stores a computer program that, when executed by a processor, implements the data packet processing method as described in any embodiment of this disclosure.

[0021] In this embodiment, the services provided by container instances mounted on nodes within the service cluster are exposed to the outside world through fixed ports (i.e., service exposure ports) on the nodes within the cluster. The outside world can access the services provided by the container instances mounted within the service cluster through these service exposure ports. After receiving an external request data packet, the internal load balancing node parses and obtains the initial source address information and the initial destination address information of the request data packet. The initial source address information is the client's address information, and the initial destination address information is the address information of the external load balancing node. This information ensures the correctness of the response path. After the request data packet is forwarded internally and processed by the container instance to obtain the response data packet, the address translation can be simulated to ensure that the response data packet has the correct source and destination addresses. The translated response data packet is sent to the client through the service exposure port. The return packet bypasses the external load balancing node, reducing dependence on the external load balancing node, avoiding the bidirectional processing burden of the external load balancing node, reducing network latency and resource consumption, and improving processing efficiency. The internal load balancing node directly processes the request data packet and sends back the response data packet, reducing unnecessary network hops, optimizing the path, and further reducing latency. In a cluster built on a virtual network, this disclosure allows each node to expose its services through its service exposure port. Even if the internal network address is not visible, external requests can still be correctly forwarded to the container instances mounted on the nodes within the cluster for processing through service exposure port mapping. When the response data packet is returned, the internal load balancing node can correctly understand and plan the return packet path by parsing the client address information and the address information of the external load balancing node obtained when parsing the request data packet. The return packet is directly fed back to the client through the service exposure port. The return packet does not need to rely on the external load balancing node. Therefore, the solution provided by the embodiments of this disclosure can realize centralized load balancing in a cluster built on a virtual network by adopting a direct return mode that does not rely on the return packet of the external load balancing node. This disclosure decouples load balancing strategies from network types and utilizes service exposure ports, packet header parsing technology, and network address translation technology to achieve unified support for building clusters in physical and virtual networks. It is applicable to a variety of network types, allowing service clusters of multiple different network types to share the same external load balancing node. This reduces the number of external load balancing nodes required, saves hardware resources, simplifies network topology and configuration, and reduces management complexity. The sharing of external load balancing nodes enables centralized load balancing management and optimization, improves system consistency and reliability, and reduces operation and maintenance difficulty and costs. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this disclosure and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 is a schematic flowchart of a data packet processing method provided in an embodiment of this disclosure;

[0024] Figure 2 is a schematic diagram of the architecture of the load balancing node of the cluster provided in an embodiment of this disclosure;

[0025] Figure 3 is an example diagram of a data packet processing method provided in an embodiment of this disclosure;

[0026] Figure 4 is a schematic diagram of a data packet processing device provided in an embodiment of this disclosure;

[0027] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Figure 1 is a flowchart illustrating a data packet processing method provided in an embodiment of this disclosure. This method is applicable to scenarios where a cluster built using a virtual network provides services to the outside world, such as data query services and data download services. The data packet processing method can be executed by a data packet processing device provided in this disclosure, which can be implemented in software and / or hardware. In a specific embodiment, the device can be integrated into an electronic device, which can be an internal load balancing node of the service cluster, specifically a computer, server, etc. The following embodiment uses the integration of the data packet processing device into an internal load balancing node of the service cluster as an example. The internal load balancing node can expose the services provided by the container instances mounted on the backend to the outside world through a service exposure port, which can be a nodeport. Referring to Figure 1, the data packet processing method of this embodiment may include the following steps:

[0031] Step 101: Receive request data packets forwarded by the external load balancer node of the service cluster through the service exposure port. The request data packets are initiated by the client and sent to the external load balancer node.

[0032] A service cluster can be a collection of service instances (Pods) within a container orchestration system. These instances can be replicas of the same application, distributed across multiple nodes to achieve load balancing and high availability. Internal load balancing nodes, also known as distributed load balancing nodes, are deployed within the service cluster and are responsible for distributing traffic and requests among different nodes, machines, or containers within the cluster. Their purpose is to achieve efficient resource utilization and load balancing within the cluster. In this embodiment, the internal load balancing node is responsible for distributing external requests to the internally mounted container instances and feeding back the processing results of the internally mounted container instances. There can be one or more internal load balancing nodes, and each internal load balancing node can host multiple container instances. External load balancing nodes, also known as centralized load balancing nodes, are deployed outside the service cluster, such as at the cluster's entry point. They are responsible for distributing external traffic and requests to various service clusters. There can also be one or more external load balancing nodes.

[0033] Specifically, in this embodiment, the service cluster can be implemented using a virtual network overlay. Since the address information of container instances mounted on nodes within the cluster is not visible to the outside world in the virtual network, a service exposure port (nodeport) can be set on the internal load balancer nodes. The service exposure port is used to expose the services provided by the container instances within the cluster, thereby exposing the services provided by the container instances mounted on the internal nodes to the outside world. The service exposure port provides services to the outside world through a specific range of ports (e.g., 30000-32767) on the underlying physical network, allowing external traffic to enter the cluster through this port.

[0034] The client can be a user's mobile phone, tablet, personal computer, etc. A request packet refers to a data packet encapsulated during transmission of a network request initiated by the client. Request packets can be used to request or download data. A request packet contains the request data (i.e., the specific content of the request) and header fields. Header fields can include standard header fields and optional header fields. Standard header fields are mandatory fields defined in the communication protocol, containing basic information about the data packet, such as source address information (i.e., source address and port number) and destination address information (i.e., destination address and port number), and are crucial for ensuring communication. Optional header fields are fields defined as optional in the protocol specification, providing additional information or features, allowing more context or control information to be transmitted during communication.

[0035] Specifically, in this embodiment, when a user corresponding to the client has query or download requests, they can initiate a request data packet. In this case, the source address information carried in the standard field of the request data packet header is the client's address information, namely the client's Internet Protocol Address (IP) and port number, while the destination address information is the address information of the external load balancer node. After receiving the request data packet, the external load balancer node can query its own routing configuration information to determine the internal load balancer node to which the request data packet should be forwarded. Based on the determined internal load balancer node, it performs Destination Network Address Translation (DNAT) on the request data packet, that is, converts the destination address information carried in the standard field of the request data packet header from its own address information to the address information of the internal load balancer node, while keeping the source address information of the request data packet unchanged (the client's address information). Since the internal load balancer node exposes its services externally using service exposure ports, the address information of the internal load balancer node carried here can be the address information of the service exposure port on the internal load balancer node. Additionally, the external load balancer node can also carry its own address information in the optional field of the request data packet header for subsequent external response packets from the cluster. The internal load balancer forwards the request data packets after address information translation to the internal load balancer node. The internal load balancer node receives the request data packets forwarded by the external load balancer node through the service exposure port.

[0036] Step 102: Parse the standard header fields of the request data packet to obtain the client's address information, and parse the optional header fields of the request data packet to obtain the address information of the external load balancer node.

[0037] The client's address information can include its IP address and port number, while the external load balancer's address information can include its IP address and port number. In this case, the source address information carried in the standard header fields of the request packet is the client's address, and the destination address information is the address of the service-exposed port on the internal load balancer. The internal load balancer can save the client's address information as the initial source address information of the request packet and the external load balancer's address information as the initial destination address information of the request packet for subsequent response packets.

[0038] After parsing the header fields of the request data packet, the internal load balancer node can determine the external transmission path of the request data packet, which is: client - external load balancer node - internal load balancer node.

[0039] Step 103: Forward the request data packet to the mounted container instance and obtain the response data packet returned by the container instance after processing the request data packet.

[0040] Internal load balancer nodes can query their own routing configuration information to determine which container instance to forward request packets to, and then forward the request packets to the corresponding container instance based on the determination result. Since the internal load balancer nodes have already recorded the initial source address and initial destination address information of the request packets, the optional header fields of the request packets are no longer needed. Therefore, the optional header fields of the request packets can be removed, and the request packets after removing the optional header fields are then address-translated before being sent to the container instances.

[0041] At this point, the internal load balancer node learns the internal transmission path of the request data packet, which is: internal load balancer node - container instance. The internal load balancer node can generate path tracing mapping information based on the external and internal transmission paths. This path tracing mapping information can include the mapping information of the transmission path of the request data packet from the client to the container instance and the mapping information of the transmission path of the response data packet from the container instance to the client.

[0042] A container instance is the most basic execution unit in a container technology solution. It packages an application and its dependencies together, providing a lightweight, isolated, easily managed, and resource-efficient runtime environment. After receiving a request packet, a container instance can perform corresponding operations or calculations on it, such as querying a database or executing computational logic, to provide the corresponding services or data. A response packet is the response generated by the service instance after processing the received request packet. The response packet includes the processing result, which may include a status code, response content, and data. The standard header fields of the response packet carry source address information (which can be the container instance's address) and destination address information (which can be the address of the service's exposed port on the internal load balancer node).

[0043] Step 104: Perform address translation on the response data packet so that the source address information of the response data packet is the address information of the external load balancer node, and the destination address information of the response data packet is the address information of the client.

[0044] The address translation strategy for the response data packet can be determined based on the generated path tracing mapping information. The address translation strategy can include source address translation and destination address translation. The source address information and destination address information of the response data packet are gradually translated according to the address translation strategy, so that the final source address information of the response data packet is the address information of the external load balancer node, and the final destination address information is the address information of the client.

[0045] Step 105: Send the converted response data packet to the client through the service exposure port.

[0046] Because the internal load balancer node has a service exposure port that is visible to the outside of the cluster, after address translation of the response data packet, the translated response data packet can be directly sent to the client using the service exposure port, thus bypassing the external load balancer node. However, the source address information of the response data packet seen by the client is the address information of the external load balancer node, and the destination address information is the client's address information. That is, from the client's perspective, the sending path and the return path are completely opposite and these paths are accessible. Therefore, the client can still send request data packets to the external load balancer node to obtain the required service or data in the future.

[0047] In this embodiment, the services provided by container instances mounted on nodes within the service cluster are exposed to the outside world through fixed ports (i.e., service exposure ports) on the nodes within the cluster. External users can access the services provided by container instances mounted within the service cluster through these service exposure ports. Upon receiving an external request data packet, the internal load balancing node parses and obtains the initial source and destination address information of the request data packet. The initial source address information is the client's address information, and the initial destination address information is the address information of the external load balancing node. This information ensures the correctness of the response path. After the request data packet is forwarded internally and processed by the container instance to obtain the response data packet, the address translation can be simulated to ensure that the response data packet has the correct source and destination addresses. The translated response data packet is sent to the client through the service exposure port, bypassing the external load balancing node, reducing dependence on the external load balancing node, avoiding the bidirectional processing burden of the external load balancing node, reducing network latency and resource consumption, and improving processing efficiency. The internal load balancing node directly processes the request data packet and sends back the response data packet, reducing unnecessary network hops, optimizing the path, and further reducing latency. In a cluster built on a virtual network, this disclosure allows each node to expose its services through its service exposure port. Even if the internal network address is not visible, external requests can still be correctly forwarded to the container instances mounted on the nodes within the cluster for processing through service exposure port mapping. When the response data packet is returned, the internal load balancing node can correctly understand and plan the return packet path by parsing the client address information and the address information of the external load balancing node obtained when parsing the request data packet. The return packet is then directly fed back to the client through the service exposure port. That is, the solution provided by the embodiments of this disclosure can realize centralized load balancing in a cluster built on a virtual network by adopting a direct return mode that does not require the return packet from an external load balancing node. This disclosure decouples load balancing strategies from network types and utilizes service exposure ports, packet header parsing technology, and network address translation technology to achieve unified support for building clusters in physical and virtual networks. It is applicable to a variety of network types, allowing multiple clusters of different network types to share the same external load balancing node, reducing the number of external load balancing nodes required, saving hardware resources, simplifying network topology and configuration, and reducing management complexity. The sharing of external load balancing nodes enables centralized load balancing management and optimization, improves system consistency and reliability, and reduces operation and maintenance difficulty and costs.

[0048] Since a service cluster can have multiple internal load balancing nodes, when there are multiple internal load balancing nodes, the request data packets received by one internal load balancing node can be forwarded to the container instances mounted on it for processing, or to the container instances mounted on other load balancing nodes for processing. The Virtual eXtensible Local Area Network (VXLAN) where the container instances reside has Virtual Tunnel Endpoints (VTEPs). VTEPs expand the network scale and enable cross-host communication between virtual machines by overlaying virtual networks on traditional data center networks. For ease of distinction, the current internal load balancing node can be named the first load balancing node, and the other internal load balancing nodes can be named the second load balancing node. The VLAN where the container instances mounted on the first load balancing node reside has the first virtual tunnel endpoint, and the VLAN where the container instances mounted on the second load balancing node reside has the second virtual tunnel endpoint. If the container instance mounted on the first load balancer node and the container instance mounted on the second load balancer node are in the same virtual LAN, then the first virtual tunnel endpoint and the second virtual tunnel endpoint can be the same. If the container instance mounted on the first load balancer node and the container instance mounted on the second load balancer node are not in the same virtual LAN, then the first virtual tunnel endpoint and the second virtual tunnel endpoint will not be the same.

[0049] If the first load balancer forwards the request packet to the container instance it is mounted for processing, the specific implementation process is as follows:

[0050] After receiving a request packet through its service exposure port, the first load balancer node converts the destination address information carried in the standard header fields of the request packet from the address information of the service exposure port of the first load balancer node to the address information of the container instance mounted on the first load balancer node; it also converts the source address information carried in the standard header fields of the request packet from the client's address information to the address information of the first virtual tunnel endpoint; and then forwards the converted request packet to the container instance mounted on the first load balancer node. After processing the request packet, the container instance generates a response packet.

[0051] The first load balancer node can convert the destination address information carried in the standard header fields of the response packet from the address information of the first virtual tunnel endpoint to the client's address information; it can also convert the source address information carried in the standard header fields of the response packet from the address information of the container instance mounted on the first load balancer node to the address information of the service exposure port of the first load balancer node; furthermore, it can convert the source address information carried in the standard header fields of the response packet from the address information of the service exposure port of the first load balancer node to the address information of the external load balancer node. Ultimately, the source address information of the response packet is the address information of the external load balancer node, and the destination address information is the client's address information. The converted response packet is then sent to the client through the service exposure port.

[0052] If the first load balancer forwards the request packet to a container instance mounted on another internal load balancer for processing, and that other internal load balancer is a second load balancer, the specific implementation process can be as follows:

[0053] Because of cross-node forwarding, the data packets need to be encapsulated using VXLAN.

[0054] After receiving the request data packet through its service exposure port, the first load balancer node parses the packet to obtain the request data and performs inner and outer encapsulation (VXLAN encapsulation). Inner encapsulation involves encapsulating the source address information into the address information of the second virtual tunnel endpoint and the destination address information into the address information of the container instance mounted on the second load balancer node. Outer encapsulation involves encapsulating the source address information into the address information of the service exposure port of the first load balancer node and the destination address information into the address information of the service exposure port of the second load balancer node. The encapsulated request data is then forwarded to the container instance mounted on the second load balancer node. The container instance decapsulates and processes the request data packet, generating a response data packet.

[0055] The second load balancer node can parse the response data packet to obtain the response data. It then performs inner and outer encapsulation on the response data. The outer encapsulation includes encapsulating the outer source address information into the address information of the service exposed port of the second load balancer node and encapsulating the outer destination address information into the address information of the service exposed port of the first load balancer node. The inner encapsulation includes encapsulating the inner source address information into the address information of the container instance mounted by the second load balancer node and encapsulating the inner destination address information into the address information of the second virtual tunnel endpoint. The encapsulated response data packet is then forwarded to the first load balancer node.

[0056] The first load balancer node can remove the outer encapsulation of the response packet, convert the destination address information encapsulated in the inner layer of the response packet from the address information of the second virtual tunnel endpoint to the client's address information, and convert the source address information encapsulated in the inner layer of the response packet from the address information of the container instance mounted on the second load balancer node to the address information of the service exposure port of the second load balancer node. Further, the first load balancer node can convert the source address information encapsulated in the inner layer of the response packet from the address information of the service exposure port of the second load balancer node back to the address information of the service exposure port of the first load balancer node; and convert the source address information encapsulated in the inner layer of the response packet from the address information of the service exposure port of the first load balancer node back to the address information of the external load balancer node. Ultimately, the source address information of the response packet is the address information of the external load balancer node, and the destination address information of the response packet is the address information of the client. The first load balancer node then sends the converted response packet to the client through the service exposure port.

[0057] The following describes the architecture of the load balancing nodes in the cluster. The cluster can be a cluster built from a virtual network, as shown in Figure 2, and can include internal load balancing nodes and external load balancing nodes.

[0058] External load balancers operate in two modes: Direct Server Return (DSR) and Full Network Address Translation (Full-NAT). In DSR mode, the response packet does not rely on the external load balancer. The process involves the client request arriving at the external load balancer, which forwards the request to the backend server according to its configuration. The backend server then directly returns the response packet to the client without going through the external load balancer. In Full-NAT mode, the response packet relies on the external load balancer. The process involves the client request arriving at the external load balancer, which translates the destination address information of the request packet into the address information of the backend server and sends the packet to the backend server. The backend server sends the response packet back to the external load balancer, which translates the source address information of the response packet back into its own address information. Finally, the external load balancer sends the response packet to the client.

[0059] Specifically, in this embodiment, the external load balancer node can switch to direct return mode upon user interaction. In direct return mode, the external load balancer node can generate data forwarding rules based on the configured routing rules and store these rules in the service mapping information. The ingress traffic control can be equipped with a packet filtering program, which queries the data forwarding rules stored in the service mapping information when processing request packets, thereby performing destination address translation on the request packets.

[0060] Internal load balancing nodes also generate data forwarding rules based on the configured routing rules. Both inbound and outbound traffic control can be equipped with packet filtering programs. The packet filtering programs are used to query data forwarding rules and process data packets transmitted from inside and outside the system, including: performing source address translation and destination address translation on data packets, and generating path tracing mapping information based on the transmission path of the data packets.

[0061] The following example illustrates the data packet processing method provided in this embodiment of the disclosure. As shown in Figure 3, it is assumed that the internal load balancing nodes of the service cluster include node 1 and node 2. Node 1 mounts container instance 1 (i.e., pod1) and container instance 2 (i.e., pod2), and node 2 mounts container instance 3 (i.e., pod3) and container instance 4 (i.e., pod4). The client needs to access pod1 and pod3 to obtain services or data.

[0062] The client's address information is A, the external load balancer's address information is B, the address information of the service exposed port of node 1 is C1, the address information of the virtual tunnel endpoint (VTEP) of the virtual LAN where pod1 is located is D1, the address information of pod1 is E1, the address information of the service exposed port of node 2 is C2, the address information of the virtual tunnel endpoint (VTEP) of the virtual LAN where pod3 is located is D2, and the address information of pod3 is E2.

[0063] The client initiates a request data packet with source address A and destination address B, i.e., A->B. After the request data packet reaches the external load balancer node, the external load balancer node queries the data forwarding rules. Assume the external load balancer node's data forwarding rules are as follows:

[0064] As shown in Table 1:

[0065] Table 1

[0066] The external load balancer node will change the destination address information of the request data packet from B to C1, i.e., A->C1, and at the same time add its own address information B to the optional field of the header of the request data packet and send it to node 1.

[0067] After receiving the request data packet, Node 1 can query its own data forwarding rules. Assume that Node 1's data forwarding rules are as shown in Table 2 below:

[0068] Table 2

[0069] Node 1 can then forward the request packet to container instance 1 and container instance 3 respectively. Optional header fields can be removed during forwarding. When forwarding to container instance 1, the destination address information of the request packet can first be converted from C1 to E1 (A->E1), and then the source address information can be converted from A to D1 (D1->E1). After conversion, the request packet is forwarded to container instance 1.

[0070] Node 1 can generate path tracing mapping information based on the forwarding path of the request data packet. The generated path tracing mapping information is shown in Table 3 below:

[0071] Table 3

[0072] After container instance 1 processes the request data packet, it generates a response data packet. The source address information of the response data packet is E1, and the destination address information is D1, i.e., E1->D1. Node 1 can query the path tracing mapping information to convert the destination address information of the response data packet from D1 to A, i.e., E1->A, and the source address information of the response data packet from E1 to C1, i.e., C1->A. Finally, the source address information of the response data packet from C1 to B, i.e., B->A. After conversion, node 1 sends the data packet to the client through its own service exposed port, without going through the external load balancer node.

[0073] When node 1 forwards the request packet to container instance 3, due to cross-node forwarding, the request packet needs to be encapsulated using VXLAN. The inner address of the request packet can be D2->E2, and the outer address can be C1->C2. After container instance 3 on node 2 processes the request packet, it generates a response packet. The response packet return process can be referred to the previous description and will not be repeated here.

[0074] Figure 4 is a schematic diagram of a data packet processing apparatus provided in an embodiment of this disclosure. This apparatus is suitable for executing the data packet processing method provided in this embodiment. As shown in Figure 4, the apparatus may specifically include:

[0075] The receiving module 401 is used to receive request data packets forwarded by the external load balancing node of the service cluster through the service exposure port. The request data packets are initiated by the client and sent to the external load balancing node.

[0076] The parsing module 402 is used to parse the standard header fields of the request data packet to obtain the address information of the client, and to parse the optional header fields of the request data packet to obtain the address information of the external load balancing node.

[0077] The transmission module 403 is used to forward the request data packet to the mounted container instance and obtain the response data packet returned by the container instance after processing the request data packet;

[0078] Address translation module 404 is used to perform address translation processing on the response data packet so that the source address information of the response data packet is the address information of the external load balancing node, and the destination address information of the response data packet is the address information of the client.

[0079] The sending module 405 is used to send the converted response data packet to the client through the service exposure port.

[0080] In one embodiment, the transmission module 403 forwards the request data packet to the mounted container instance, including:

[0081] Remove optional fields from the header of the request data packet;

[0082] The request packet with optional header fields removed is forwarded to the container instance.

[0083] In one embodiment, the transmission module 403 forwards the request data packet to the mounted container instance, including:

[0084] The request data packet is forwarded to the container instance mounted on the internal load balancing node, and / or the request data packet is forwarded to the container instance mounted on other internal load balancing nodes.

[0085] In one embodiment, the virtual local area network where the container instance mounted by the internal load balancing node resides has a first virtual tunnel endpoint. The transmission module 403 forwards the request data packet to the container instance mounted by the internal load balancing node, including:

[0086] The destination address information carried in the header standard field of the request data packet is converted from the address information of the service exposed port of the internal load balancer node to the address information of the container instance mounted on the internal load balancer node.

[0087] The source address information carried in the header standard field of the request data packet is converted from the address information of the client to the address information of the first virtual tunnel endpoint;

[0088] The converted request data packet is forwarded to the container instance mounted on the internal load balancer node.

[0089] In one embodiment, before performing address translation processing on the response data packet, the address translation module 404 is further configured to:

[0090] The destination address information carried in the header standard field of the response data packet is converted from the address information of the first virtual tunnel endpoint to the address information of the client.

[0091] The source address information carried in the standard header field of the response data packet is converted from the address information of the container instance mounted by the internal load balancer node to the address information of the service exposure port of the internal load balancer node.

[0092] In one embodiment, the other internal load balancing nodes also include service exposure ports, and the virtual local area network where the container instances mounted on the other internal load balancing nodes reside has a second virtual tunnel endpoint. The transmission module 403 forwards the request data packet to the container instances mounted on the other internal load balancing nodes, including:

[0093] The request data packet is parsed to obtain request data, and the request data is encapsulated in an inner layer and an outer layer. The inner layer encapsulation of the request data includes: encapsulating the inner source address information into the address information of the second virtual tunnel endpoint and encapsulating the inner destination address information into the address information of the container instance mounted by the other internal load balancing nodes. The outer layer encapsulation of the request data includes: encapsulating the outer source address information into the address information of the service exposure port of the internal load balancing node and encapsulating the outer destination address information into the address information of the service exposure port of the other internal load balancing nodes.

[0094] The encapsulated request data is forwarded to the container instances mounted on the other internal load balancing nodes.

[0095] In one embodiment, before performing address translation processing on the response data packet, the address translation module 404 is further configured to:

[0096] Remove the outer encapsulation of the response data packet;

[0097] The destination address information encapsulated within the response data packet is converted from the address information of the second virtual tunnel endpoint to the address information of the client.

[0098] The source address information encapsulated within the response data is converted from the address information of the container instance mounted on the other internal load balancing nodes to the address information of the service exposure port of the other internal load balancing nodes.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0100] The apparatus of this embodiment exposes the services provided by container instances mounted on nodes within a service cluster to the outside world through a fixed port (i.e., a service exposure port) on the nodes within the cluster. The outside of the cluster can access the services provided by the container instances mounted within the service cluster through the service exposure port. After receiving an external request data packet, the internal load balancing node parses and obtains the initial source address information and the initial destination address information of the request data packet. The initial source address information is the client's address information, and the initial destination address information is the address information of the external load balancing node. This information ensures the correctness of the response path. After the request data packet is forwarded internally and processed by the container instance to obtain the response data packet, the address translation can be simulated by the external load balancing node to ensure that the response data packet has the correct source and destination addresses. Sending the translated response data packet to the client through the service exposure port bypasses the external load balancing node, reduces dependence on the external load balancing node, avoids the bidirectional processing burden of the external load balancing node, reduces network latency and resource consumption, and improves processing efficiency. The internal load balancing node directly processes the request data packet and sends back the response data packet, reducing unnecessary network hops, optimizing the path, and further reducing latency. In a cluster built on a virtual network, this disclosure allows each node to expose its services through its service exposure port. Even if the internal network address is not visible, external requests can still be correctly forwarded to the container instances mounted on the nodes within the cluster for processing through service exposure port mapping. When the response data packet is returned, the internal load balancing node can correctly understand and plan the return packet path by parsing the client address information and the address information of the external load balancing node obtained when parsing the request data packet. The return packet is then directly fed back to the client through the service exposure port. That is, the solution provided by the embodiments of this disclosure can realize centralized load balancing in a cluster built on a virtual network by adopting a direct return mode that does not require the return packet from an external load balancing node. This disclosure decouples load balancing strategies from network types and utilizes service exposure ports, packet header parsing technology, and network address translation technology to achieve unified support for building clusters in physical and virtual networks. It is applicable to a variety of network types, allowing multiple clusters of different network types to share the same external load balancing node, reducing the number of external load balancing nodes required, saving hardware resources, simplifying network topology and configuration, and reducing management complexity. The sharing of external load balancing nodes enables centralized load balancing management and optimization, improves system consistency and reliability, and reduces operation and maintenance difficulty and costs.

[0101] This disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the video processing method provided in any of the above embodiments.

[0102] This disclosure also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the data packet processing method provided in any of the above embodiments.

[0103] Referring now to FIG5, a schematic diagram of a computer system 500 suitable for implementing an electronic device according to embodiments of the present disclosure is shown. The electronic device shown in FIG5 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present disclosure.

[0104] As shown in Figure 5, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0105] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0106] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this disclosure.

[0107] It should be noted that the computer-readable medium disclosed herein may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0109] The modules and / or units described in the embodiments of this disclosure can be implemented in software or hardware. The described modules and / or units can also be housed in a processor; for example, a processor can be described as including a receiving module, a parsing module, a transmission module, an address translation module, and a sending module. The names of these modules do not necessarily limit the module itself.

[0110] In another aspect, this disclosure also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include:

[0111] The system receives request packets forwarded by external load balancing nodes of the service cluster through the service exposure port. These request packets are initiated by the client and sent to the external load balancing node. The system parses the standard header fields of the request packets to obtain the client's address information and parses the optional header fields to obtain the address information of the external load balancing node. The system forwards the request packets to the mounted container instance and obtains the response packets returned by the container instance after processing the request packets. The system performs address translation on the response packets so that the source address information of the response packets is the address information of the external load balancing node, and the destination address information of the response packets is the address information of the client. Finally, the system sends the translated response packets to the client through the service exposure port.

[0112] According to the technical solution of this disclosure, the services provided by container instances mounted on nodes within the service cluster are exposed to the outside world through fixed ports (i.e., service exposure ports) on the nodes within the cluster. The outside of the cluster can access the services provided by the container instances mounted within the service cluster through these service exposure ports. After receiving an external request data packet, the internal load balancing node parses and obtains the initial source address information and the initial destination address information of the request data packet. The initial source address information is the client's address information, and the initial destination address information is the address information of the external load balancing node. This information ensures the correctness of the response path. After the request data packet is forwarded internally and processed by the container instance to obtain the response data packet, the address translation can be simulated by the external load balancing node to ensure that the response data packet has the correct source and destination addresses. Sending the translated response data packet to the client through the service exposure port bypasses the external load balancing node, reduces dependence on the external load balancing node, avoids the bidirectional processing burden of the external load balancing node, reduces network latency and resource consumption, and improves processing efficiency. The internal load balancing node directly processes the request data packet and sends back the response data packet, reducing unnecessary network hops, optimizing the path, and further reducing latency. In a cluster built on a virtual network, this disclosure allows each node to expose its services through its service exposure port. Even if the internal network address is not visible, external requests can still be correctly forwarded to the container instances mounted on the nodes within the cluster for processing through service exposure port mapping. When the response data packet is returned, the internal load balancing node can correctly understand and plan the return packet path by parsing the client address information and the address information of the external load balancing node obtained when parsing the request data packet. The return packet is then directly fed back to the client through the service exposure port. That is, the solution provided by the embodiments of this disclosure can realize centralized load balancing in a cluster built on a virtual network by adopting a direct return mode that does not require the return packet from an external load balancing node. This disclosure decouples load balancing strategies from network types and utilizes service exposure ports, packet header parsing technology, and network address translation technology to achieve unified support for building clusters in physical and virtual networks. It is applicable to a variety of network types, allowing multiple clusters of different network types to share the same external load balancing node, reducing the number of external load balancing nodes required, saving hardware resources, simplifying network topology and configuration, and reducing management complexity. The sharing of external load balancing nodes enables centralized load balancing management and optimization, improves system consistency and reliability, and reduces operation and maintenance difficulty and costs.

[0113] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0114] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0115] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A data packet processing method applied to an internal load balancing node of a service cluster, wherein, The internal load balancing node includes a service exposure port, and the packet processing method includes: The service receives request packets forwarded by the external load balancer node of the service cluster through the service exposure port. The request packets are initiated by the client and sent to the external load balancer node. The address information of the client is obtained by parsing the standard fields in the header of the request data packet, and the address information of the external load balancer node is obtained by parsing the optional fields in the header of the request data packet. The request data packet is forwarded to the mounted container instance, and the response data packet returned by the container instance after processing the request data packet is obtained. The response data packet is subjected to address translation processing so that the source address information of the response data packet is the address information of the external load balancing node, and the destination address information of the response data packet is the address information of the client. The converted response data packet is sent to the client through the service's exposed port.

2. The data packet processing method of claim 1, wherein, Forwarding the request data packet to the mounted container instance includes: Remove optional fields from the header of the request data packet; The request packet with optional header fields removed is forwarded to the container instance.

3. The data packet processing method of claim 1, wherein, Forwarding the request data packet to the mounted container instance includes: The request data packet is forwarded to the container instance mounted on the internal load balancing node, and / or the request data packet is forwarded to the container instance mounted on other internal load balancing nodes.

4. The data packet processing method of claim 3, wherein, The virtual local area network (VLAN) where the container instance mounted on the internal load balancer node resides has a first virtual tunnel endpoint. The request data packet is forwarded to the container instance mounted on the internal load balancer node, including: The destination address information carried in the header standard field of the request data packet is converted from the address information of the service exposed port of the internal load balancer node to the address information of the container instance mounted on the internal load balancer node. The source address information carried in the header standard field of the request data packet is converted from the address information of the client to the address information of the first virtual tunnel endpoint; The converted request data packet is forwarded to the container instance mounted on the internal load balancer node.

5. The data packet processing method of claim 4, wherein, Before performing address translation processing on the response data packet, the following is also included: The destination address information carried in the header standard field of the response data packet is converted from the address information of the first virtual tunnel endpoint to the address information of the client. The source address information carried in the standard header field of the response data packet is converted from the address information of the container instance mounted by the internal load balancer node to the address information of the service exposure port of the internal load balancer node.

6. The data packet processing method of claim 3, wherein, The other internal load balancing nodes also include service exposure ports. The virtual local area network where the container instances mounted on the other internal load balancing nodes reside has a second virtual tunnel endpoint. Forwarding the request data packet to the container instances mounted on the other internal load balancing nodes includes: The request data packet is parsed to obtain request data, and the request data is encapsulated in an inner layer and an outer layer. The inner layer encapsulation of the request data includes: encapsulating the inner source address information into the address information of the second virtual tunnel endpoint and encapsulating the inner destination address information into the address information of the container instance mounted by the other internal load balancing nodes. The outer layer encapsulation of the request data includes: encapsulating the outer source address information into the address information of the service exposure port of the internal load balancing node and encapsulating the outer destination address information into the address information of the service exposure port of the other internal load balancing nodes. The encapsulated request data is forwarded to the container instances mounted on the other internal load balancing nodes.

7. The data packet processing method of claim 6, wherein, Before performing address translation processing on the response data packet, the following is also included: Remove the outer encapsulation of the response data packet; The destination address information encapsulated within the response data packet is converted from the address information of the second virtual tunnel endpoint to the address information of the client. The source address information encapsulated within the response data is converted from the address information of the container instance mounted on the other internal load balancing nodes to the address information of the service exposure port of the other internal load balancing nodes.

8. A data packet processing apparatus applied to an internal load balancing node of a service cluster, wherein, The internal load balancing node includes a service exposure port, and the packet processing device includes: The receiving module is used to receive request data packets forwarded by the external load balancing node of the service cluster through the service exposure port. The request data packets are initiated by the client and sent to the external load balancing node. The parsing module is used to parse the standard header fields of the request data packet to obtain the address information of the client, and to parse the optional header fields of the request data packet to obtain the address information of the external load balancer node. The transmission module is used to forward the request data packet to the mounted container instance and obtain the response data packet returned by the container instance after processing the request data packet; The address translation module is used to perform address translation processing on the response data packet so that the source address information of the response data packet is the address information of the external load balancing node, and the destination address information of the response data packet is the address information of the client. The sending module is used to send the converted response data packet to the client through the service exposure port.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, When the processor executes the computer program, it implements the data packet processing method as described in any one of claims 1 to 7.

10. A computer readable storage medium having stored thereon a computer program, wherein, When the computer program is executed by a processor, it implements the data packet processing method as described in any one of claims 1 to 7.

Images