Data traffic forwarding method, system and device, target node, storage medium and program product

Abstract

The embodiment of the invention discloses a data traffic forwarding method, system and device, a target node, a storage medium and a program product. The method is applied to a target node in a node cluster, a load balancing container is deployed on the target node, an IP address allocated to the load balancing container is published as a virtual IP address, and the method can comprise the following steps: in response to data traffic for the virtual IP address, obtaining a candidate IP address corresponding to the virtual IP address, each candidate IP address corresponds to a corresponding application container; and determining a target IP address from the candidate IP addresses based on a load balancing strategy, and forwarding the data traffic to a target application container corresponding to the target IP address in the application containers. According to the technical scheme provided by the embodiment of the invention, jitter of data traffic under all VIP addresses can be avoided.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a data traffic forwarding method, system, device, target node, storage medium and program product. Background Technology

[0002] The cloud-native container orchestration platform (Kubernetes, also known as kube or k8s) provides powerful container orchestration capabilities, opens up network interfaces, and supports custom and flexible container networks.

[0003] Within Kubernetes (k8s), to ensure high availability and high performance, multiple application containers (pods) can be deployed for the same service, each with its own independent Internet Protocol (IP) address. Based on this, a centralized load balancer (LB) server group can be used as the host and publisher of virtual IP (VIP) addresses. The LB server, combined with load balancing (LB) strategies, performs IP address translation on data traffic arriving at it via the VIP address, forwarding it to the appropriate application container, thus achieving reasonable distribution of data traffic across the application containers.

[0004] In the process of realizing this invention, the inventors discovered the following technical problem in the prior art: when any LB server fails, the data traffic under all VIP addresses will fluctuate. Summary of the Invention

[0005] This invention provides a data traffic forwarding method, system, device, target node, storage medium, and program product, which solves the problem of data traffic jitter under all VIP addresses.

[0006] According to one aspect of the present invention, a data traffic forwarding method is provided, applied to a target node in a node cluster, wherein a load balancing container is deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address. The method may include:

[0007] In response to data traffic targeting a virtual IP address, candidate IP addresses corresponding to the virtual IP address are obtained, where each candidate IP address corresponds to a specific application container;

[0008] Based on the load balancing strategy, the target IP address is determined from each candidate IP address, and the data traffic is forwarded to the target application container corresponding to the target IP address in each application container.

[0009] According to another aspect of the present invention, a data traffic forwarding system is provided, which may include: a load balancing proxy, wherein the load balancing proxy is deployed on a target node in a node cluster, and a load balancing container is also deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address; wherein...

[0010] A load balancing proxy is used to execute the data traffic forwarding method provided in any embodiment of the present invention.

[0011] According to another aspect of the present invention, a data traffic forwarding device is provided, configured on a target node in a node cluster, wherein a load balancing container is deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address. The device may include:

[0012] The candidate IP address acquisition module is used to acquire candidate IP addresses corresponding to virtual IP addresses in response to data traffic targeting virtual IP addresses. Each candidate IP address corresponds to a specific application container.

[0013] The data traffic forwarding module is used to determine the target IP address from the candidate IP addresses based on the load balancing strategy, and forward the data traffic to the target application container corresponding to the target IP address in each application container.

[0014] According to another aspect of the present invention, a target node located in a node cluster is provided, on which a load balancing container is deployed, and the IP address assigned to the load balancing container has been advertised as a virtual IP address. The target node may include:

[0015] At least one processor; and

[0016] A memory that is communicatively connected to at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by at least one processor, such that when the at least one processor executes the program, it implements the data traffic forwarding method provided in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided having computer instructions stored thereon for causing a processor to execute and implement the data traffic forwarding method provided in any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer program product is provided, on which a computer program is stored, which, when executed by a processor, implements the data traffic forwarding method provided in any embodiment of the present invention.

[0020] The technical solution of this invention deploys a load balancing container (LB pod) on the target node within a node cluster, publishes the IP address assigned to the LB pod as the VIP address, and performs load balancing of data traffic based on this. In this way, even if a target node fails, only the data traffic under the VIP address represented by the LB pod deployed on that target node will experience fluctuations, and the data traffic under the VIP addresses represented by LB pods deployed on other target nodes will not be affected. This solves the problem of data traffic fluctuations under all VIP addresses.

[0021] It should be understood that the description in this section is not intended to identify key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0023] Figure 1 This is a diagram illustrating the relevant data traffic forwarding scheme;

[0024] Figure 2 This is a schematic diagram of an optional example of various data traffic forwarding methods provided according to embodiments of the present invention;

[0025] Figure 3 This is a flowchart of a data traffic forwarding method provided according to an embodiment of the present invention;

[0026] Figure 4a This is a schematic diagram of a forwarding scenario in a data traffic forwarding method provided according to an embodiment of the present invention;

[0027] Figure 4b This is a schematic diagram of another forwarding scenario in a data traffic forwarding method provided by an embodiment of the present invention;

[0028] Figure 4c This is a schematic diagram of another forwarding scenario in a data traffic forwarding method provided by an embodiment of the present invention;

[0029] Figure 5 This is a flowchart of another data traffic forwarding method provided by an embodiment of the present invention;

[0030] Figure 6This is a flowchart of another data traffic forwarding method provided according to an embodiment of the present invention;

[0031] Figure 7 This is a structural block diagram of a data traffic forwarding system provided according to an embodiment of the present invention;

[0032] Figure 8 This is a schematic diagram of a load balancing agent in a data traffic forwarding system according to an embodiment of the present invention;

[0033] Figure 9 This is a structural block diagram of another data traffic forwarding system provided according to an embodiment of the present invention;

[0034] Figure 10 This is a schematic diagram of a load balancer in another data traffic forwarding system provided by an embodiment of the present invention;

[0035] Figure 11 This is a structural block diagram of a data traffic forwarding device according to an embodiment of the present invention;

[0036] Figure 12 This is a schematic diagram of the structure of the target node that implements the data traffic forwarding method of this invention. Detailed Implementation

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

[0038] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The same applies to "target," "original," etc., and will not be repeated here. 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.

[0039] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solution of this invention 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 maintain user personal information security and network security.

[0040] Before introducing the embodiments of the present invention, the specific implementation process of the relevant data traffic forwarding scheme (hereinafter referred to as the relevant scheme) described above will be illustrated by example, so as to better understand why the technical problems described above exist, and thus better understand how the data traffic forwarding scheme proposed in the embodiments of the present invention solves the technical problems.

[0041] For example, see Figure 1 The Load Balancer (LB) server group consists of multiple LB servers located outside of Kubernetes (k8s), facilitating access from external clients to application containers within k8s. Assuming N VIP addresses need to be published, each LB server will publish these N VIP addresses via the Border Gateway Protocol (BGP) to ensure high availability for each VIP address. Application containers (pods) are deployed on nodes within k8s, with their IP address and port associated with the corresponding VIP address and port. Domain names registered on the Domain Name System (DNS) are resolved to the corresponding VIP addresses. When a client accesses the application via a domain name (i.e., without knowing the VIP address), the data traffic (or request) is first sent to the DNS. The DNS resolves the domain name and returns the VIP address. The client then uses this VIP address to forward the data traffic to a specific LB server, which in turn forwards the traffic to the appropriate application container.

[0042] As explained above, since each LB server publishes all VIP addresses, when any LB server fails, data traffic sent to that LB server through any VIP address will not receive a response, resulting in data traffic fluctuations under all VIP addresses.

[0043] Based on this, in order to solve the technical problems described above, the embodiments of the present invention exemplarily propose... Figure 2The data traffic forwarding system shown is primarily composed of a load balancer controller (kube-lb controller), load balancing containers (LB pods), load balancing agents (kube-lb agents), and a domain name system controller (dnscontroller). The kube-lb agent can be deployed on each node within the node cluster (i.e., k8s, or kube, in the example above); the LB pod can be deployed on at least some nodes within the node cluster; the kube-lb controller can be deployed on nodes within the node cluster or on external nodes (or external servers) that can communicate with the node cluster; and the deployment of the DNS controller is similar to that of the kube-lb controller, and will not be elaborated further here.

[0044] See Figure 2 Users write the relevant information of the load balancer pods to be deployed into the application programming interface service (apiserver). Taking the service.yaml file shown in the diagram with the label: kube-lb: true, pod-num:x as an example, service.yaml is a configuration file used to define a service resource. kube-lb: true and pod-num:x are labels attached to this service. kube-lb: true indicates that the service requires Layer 4 load balancing, where Layer 4 refers to the fourth layer in the network layering model – the transport layer. pod-num:x indicates that x load balancer pods need to be deployed for this service, and these x load balancer pods are deployed on different nodes. The specific deployment process will be detailed later. Furthermore, for each load balancer pod, the IP address assigned to that pod is published as the VIP address. It is understandable that since the IP addresses assigned to each load balancer pod are different, the VIP addresses published through them are also different. In this example, the Container Network Interface (CNI) functionality can be used to implement the publishing process.

[0045] In this embodiment of the invention, a node in the node cluster that has an LB pod deployed can be referred to as a target node. The following uses any target node in the node cluster as an example to illustrate the data traffic forwarding process.

[0046] Figure 3This is a flowchart of a data traffic forwarding method provided in an embodiment of the present invention. This embodiment is applicable to situations where data traffic is evenly distributed across application containers. The method can be executed by a data traffic forwarding device provided in this embodiment, which can be implemented in software and / or hardware. This device can be integrated on a target node in a node cluster (such as the Kubernetes example above). The target node can be a physical server, a cloud virtual machine, or an edge device, etc. A load balancer (LB) pod is deployed on the target node, and the IP address assigned to the LB pod has been published as a virtual IP address; that is, the VIP address uses the IP address of the pod within the node cluster. Optionally, in this embodiment, the pods in the node cluster can use an underlay network (such as a VLAN network or a BGP network). In this case, the published VIP address (i.e., the pod's IP address) can be directly accessed by clients outside the node cluster, thereby enabling clients to access the pods within the node cluster.

[0047] It should be noted that the above only describes the data traffic forwarding method executed by the target node, but does not limit which container, controller, or proxy on the target node executes the data traffic forwarding method. Based on this, and considering the application scenarios that may be involved in the embodiments of this invention, optionally, the method can be executed by the LB pod deployed on the target node; in particular, a load balancing proxy can be deployed on the target node and executed by it, that is, before the data traffic reaches the LB pod, it has been intercepted and responded to by the load balancing proxy. At this time, the load balancing proxy is responsible for carrying the actual LB service, while the LB pod can be a small container (such as a container that can be requested with 0.1C / 100M), which does not carry the actual LB service, but only serves as a VIP address carrier; of course, the method can also be executed by other content on the target node, without specific limitations.

[0048] Next, we will use the example of a load balancing agent executing this method to illustrate the point, but this is just an example and not a specific limitation.

[0049] See Figure 3 The method of this invention specifically includes the following steps:

[0050] S110. In response to data traffic to a virtual IP address, obtain candidate IP addresses corresponding to the virtual IP address, wherein each candidate IP address corresponds to a specific application container.

[0051] Since the IP address of the LB pod deployed on the target node has been published as a virtual IP address, clients and other senders that can send data traffic can send data traffic to this virtual IP address. The target node can then receive this data traffic and forward it to the load balancer that carries the actual LB service.

[0052] Based on this, the load balancer can respond to received data traffic and, for the virtual IP address corresponding to that data traffic, obtain a candidate IP address. This candidate IP address can be understood as the IP address of a specific application container. It's understood that since each application container has an independent IP address, each candidate IP address corresponds to a specific application container. Optionally, these application containers could be containers launched for the same service; in this case, the virtual IP address can be considered an IP address published for that service. Further, some of these application containers could be containers launched for one service, and others could be containers launched for another service; in this case, the virtual IP address can be considered an IP address published for both services. And so on, without specific limitations.

[0053] S120. Based on the load balancing strategy, determine the target IP address from each candidate IP address and forward the data traffic to the target application container corresponding to the target IP address in each application container.

[0054] The load balancing strategy can be understood as a pre-set strategy that represents how to evenly distribute data traffic across application containers. Based on this, and considering the application scenarios that may be involved in the embodiments of this invention, the strategy may optionally be to poll each application container in round-robin mode, or to poll the candidate IP addresses corresponding to each application container in round-robin mode, and use the polled candidate IP addresses as the target IP addresses; it may also be to determine the target IP address from each candidate IP address through a hash algorithm; or it may be to analyze the load of each application container, and then determine the target application container from each application container based on the load, such as using the application container with a lower load as the target application container, and then using the candidate IP address of the target application container as the target address; etc. This can be set according to actual needs, and no specific limitation is made here.

[0055] In other words, the target IP address can be determined from among the candidate IP addresses based on a load balancing strategy. Furthermore, for the target application container corresponding to the target IP address within each application container, data traffic is forwarded to the target application container, which then responds to the data traffic.

[0056] The technical solution of this invention deploys a load balancing container (LB pod) on the target node within a node cluster, publishes the IP address assigned to the LB pod as the VIP address, and performs load balancing of data traffic based on this. In this way, even if a target node fails, only the data traffic under the VIP address represented by the LB pod deployed on that target node will experience fluctuations, and the data traffic under the VIP addresses represented by LB pods deployed on other target nodes will not be affected. This solves the problem of data traffic fluctuations under all VIP addresses.

[0057] In addition, in related solutions, the LB server needs to publish a VIP address and carry the actual LB business, which means it is a large-scale or high-cost server. In addition, since it is an additional server set up outside of Kubernetes, only a limited number of LB servers can be set up. At this time, the data traffic will be concentrated on this limited number of LB servers and cannot be distributed. Therefore, a large buffer needs to be reserved on each LB server to prevent the impact of sudden data traffic on the machine. Obviously, this results in a waste of resources for most of the time.

[0058] Accordingly, in the technical solution of this invention embodiment, a load balancing proxy and LB pods are deployed on the target nodes. The load balancing proxy is responsible for carrying the actual LB services, while the LB pods only serve as VIP address carriers; that is, they do not need to carry actual LB services and are small-scale pods. This allows for large-scale deployment of LB pods within the node cluster. This means that the data traffic brought by the LB pods can be distributed across multiple target nodes, thus minimizing the possibility of sudden data traffic surges impacting a single target node. Therefore, it eliminates the need to reserve large buffers for the target nodes where LB pods are deployed, thereby solving the problem of resource waste during most of the time.

[0059] An optional technical solution, when the originating point of the data traffic is not deployed on the target node, forwards the data traffic to the target application container corresponding to the target IP address in each application container, including:

[0060] The source IP address of the data traffic is converted from the originating IP address to a virtual IP address, and the destination IP address of the data traffic is converted from the virtual IP address to the target IP address, so as to forward the data traffic to the target application container corresponding to the converted destination IP address in each application container. The conversion of the source IP address is to enable the target application container to return the response traffic to the target node in response to the data traffic.

[0061] In this context, the sending end can be understood as the end that sends out data traffic; in this technical solution, it can optionally be figuratively referred to as the client. If the client is not deployed on the target node, then regardless of whether the target application container is deployed on the target node, see, for example... Figure 4a For data traffic sent from the client to the LB pod (i.e., pointing to ebpf in the diagram), its destination IP address can be converted from a virtual IP address to a target IP address, and its source IP address can be converted from the client's IP address to a virtual IP address. The former conversion is to forward the data traffic to the target application container (represented by server in the diagram) corresponding to the converted destination IP address (i.e., target IP address); the latter conversion is to allow the target application container to return the response traffic to the target node in response to the data traffic, and then return it to the client. This achieves the effective flow of data traffic (i.e., the orange line in the diagram) and response traffic (i.e., the red line in the diagram).

[0062] Another alternative technical solution, when the data traffic originating from the target node is deployed on the target node, is to forward the data traffic to the target application container corresponding to the target IP address within each application container, including:

[0063] The destination IP address of data traffic is converted from a virtual IP address to a target IP address, so that the data traffic is forwarded to the target application container corresponding to the converted destination IP address in each application container.

[0064] In the case where the client is deployed on the target node (i.e., the client is a pod on the target node), then it doesn't matter whether the target application container (server) is deployed on the target node. For example, see [link to example]. Figure 4b (The server is not deployed on the target node) and Figure 4c (The server is deployed on the target node) For data traffic sent from the client pod to the LB pod (i.e., pointing to ebpf in the diagram), its destination IP address can be converted from the virtual IP address to the target IP address, so that the data traffic can be forwarded to the server corresponding to the converted destination IP address (i.e., the target IP address).

[0065] It should be noted that in this case, since both the LB pod and the client pod are deployed on the target node, there is no need to convert the source IP address of the data traffic. This is because both the client's IP address and the virtual IP address can be mapped to the target node, meaning that the response traffic returned by the server can be routed back to the target node.

[0066] The above technical solution achieves efficient flow of data traffic and response traffic through address translation.

[0067] Figure 5 This is a flowchart of another data traffic forwarding method provided by an embodiment of the present invention. This embodiment is based on and optimized from the above-described technical solutions. Optionally, in this embodiment, the above-described data traffic forwarding method may further include: identifying a deployed load balancing container and obtaining a candidate IP address corresponding to the IP address of the load balancing container from an application programming interface service deployed in the node cluster; storing the candidate IP address in the storage space of the target node so as to retrieve the candidate IP address from the storage space when responding to data traffic. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0068] See Figure 5 The method in this embodiment may specifically include the following steps:

[0069] S210, Identify deployed load balancing containers.

[0070] Since both the LB pod and the load balancing agent are deployed on the target node, the load balancing agent can identify the LB pods deployed on the target node.

[0071] S220. Obtain candidate IP addresses corresponding to the IP addresses of the load balancing containers from the application programming interface services deployed in the node cluster, wherein each candidate IP address corresponds to a corresponding application container.

[0072] As explained above, the application programming interface service (apiserver) can be deployed within the node cluster, storing information about IP addresses, especially the most up-to-date information. This allows the load balancer to retrieve candidate IP addresses corresponding to the identified LB pod's IP address from the apiserver.

[0073] Based on this, optionally, the system can monitor the apiserver and, if an update is detected in the candidate IP address in the apiserver, update the candidate IP address in the storage space based on the monitoring result (i.e., the updated candidate IP address in the apiserver); alternatively, the system can perform health checks on the application containers corresponding to the candidate IP addresses in the storage space, and, if an anomaly is detected, remove the candidate IP address of the application container with the anomaly from the storage space.

[0074] The two options mentioned above can dynamically detect changes in candidate IP addresses and update the candidate IP addresses in the storage space, thereby ensuring accurate response to data traffic.

[0075] S230. Store each candidate IP address in the target node's storage space.

[0076] Storage space can be understood as the space on the target node where data can be stored, such as cache, memory, or disk. This can be configured according to actual needs and is not specifically limited here. Candidate IP addresses are stored in the storage space so that they can be quickly retrieved later when needed.

[0077] S240, In response to data traffic targeting a virtual IP address, retrieve a candidate IP address from storage space.

[0078] S250. Based on the load balancing strategy, determine the target IP address from each candidate IP address and forward the data traffic to the target application container corresponding to the target IP address in each application container.

[0079] The technical solution of this invention takes into account that the IP address of a pod changes with the destruction and creation of the pod, which may cause changes in the VIP address, candidate IP address and their relationship. Therefore, the load balancing agent can obtain the latest IP address and its relationship from the apiserver in the node cluster by linking with the apiserver. This allows for dynamic perception of IP address changes, thereby ensuring accurate response to data traffic.

[0080] Figure 6 This is a flowchart of another data traffic forwarding method provided by an embodiment of the present invention. This embodiment is based on and optimized from the above-described technical solutions. In this embodiment, optionally, a target program is embedded in the kernel corresponding to the load balancing proxy to obtain a candidate IP address corresponding to the virtual IP address. This can include: intercepting data traffic through the target program and obtaining a candidate IP address corresponding to the virtual IP address, so as to forward the data traffic to the target application container. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0081] See Figure 6 The method in this embodiment may specifically include the following steps:

[0082] S310, in response to data traffic targeting virtual IP addresses, executes S320-S330 through a target program embedded in the kernel.

[0083] It should be noted that in the relevant scheme, after the load balancer (LB) server receives data traffic, its kernel first processes the data traffic, then passes the processed data traffic to the user-space program for further processing, and finally forwards it to the target application container. This process from the kernel to the user-space program inevitably involves data traffic copying and CPU usage, which can affect the forwarding performance of the data traffic.

[0084] Accordingly, in this embodiment of the invention, a target program is embedded in the kernel of the target node. The target program can intercept data traffic entering the kernel and forward the data traffic directly to the target application container through the following S320-S330, without passing it to the user-space program for processing and forwarding. This achieves high-performance forwarding of data traffic.

[0085] Optionally, the target program described above can be implemented using an extended Berkeley Packet Filter (ebpf), thereby enabling high-performance filtering and forwarding of network packets (i.e., data traffic).

[0086] S320. Obtain the candidate IP address corresponding to the virtual IP address, wherein each candidate IP address corresponds to a corresponding application container.

[0087] S330: Based on the load balancing strategy, determine the target IP address from each candidate IP address and forward the data traffic to the target application container corresponding to the target IP address in each application container.

[0088] The technical solution of this invention embeds a target program (such as ebpf) in the kernel, thereby enabling direct data traffic forwarding in the kernel without having to pass the data traffic to the user-space program for processing and forwarding. This reduces the processing steps in the data traffic forwarding process and achieves high-performance data traffic forwarding.

[0089] In one optional technical solution, the target program obtains candidate IP addresses from the kernel's kernel space. These candidate IP addresses are pre-obtained from the target node's storage space and stored in the kernel space by the data plane in the node cluster. Therefore, the above data traffic forwarding method further includes:

[0090] Through the data plane, in response to an update of the candidate IP addresses stored in the storage space, the candidate IP addresses stored in the kernel space are updated based on the update result of the storage space.

[0091] In this approach, combining the aforementioned technical solutions, after the load balancing proxy stores the candidate IP address in the storage space, the data plane in the node cluster can retrieve the candidate IP address from the storage space and store it in the kernel space. This allows the target program to quickly retrieve the candidate IP address from the kernel space when responding to data traffic.

[0092] Based on this, in order to ensure the accuracy of the candidate IP addresses stored in the kernel space, the data plane can monitor the storage space, and when an update is detected in the candidate IP address stored therein, the candidate IP address in the kernel space can be updated accordingly, thereby ensuring accurate response to data traffic.

[0093] Another alternative technical solution involves mounting the target program on both the kernel's network socket connection mount point and the flow control entry mount point; the target program then intercepts data traffic, including:

[0094] When the originating point of the data traffic is deployed on the target node, the data traffic is intercepted by a target program mounted on the network socket connection mount point; or,

[0095] When the data traffic originating from a node is not deployed on the target node, the data traffic is intercepted by a target program mounted on the traffic control entry point.

[0096] The target program is mounted on both the kernel's network socket connection (sock connect) mount point and the flow control entry point (tc ingress) mount point. The target program mounted on the sock connect mount point can be used to process... Figure 4a The data traffic shown is in a forwarding scenario, and the target program mounted on the tc ingress mount point can be used to process it. Figure 4b and Figure 4c The diagram illustrates data traffic in various forwarding scenarios. These two technologies work together to achieve high-volume data forwarding in different scenarios.

[0097] Figure 7 This is a structural block diagram of a data traffic forwarding system provided in an embodiment of the present invention. This embodiment is applicable to situations where data traffic is evenly distributed across various application containers.

[0098] See Figure 7 The data traffic forwarding system described in this embodiment of the invention includes: a load balancing proxy 410, wherein the load balancing proxy 410 is deployed on a target node in a node cluster, and a load balancing container is also deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address; wherein...

[0099] The load balancing agent 410 is used to execute the data traffic forwarding method provided in any embodiment of the present invention.

[0100] Building on this, in order to better understand the load balancing agent (kube-lbagent) 410 described above as a whole, the following example illustrates it in conjunction with optional examples.

[0101] For example, see Figure 8 In Kubernetes, the data plane deploys a kube-lb agent on each node and issues LB policies to the ebpf, which then forwards data traffic based on these policies.

[0102] 1. The kube-lb agent monitors (watches) information related to resources such as svc, ep, and pod of the apiserver. Here, svc is short for service and ep is short for external IP.

[0103] 2. Identify the LB pods on this node and store the relevant information in the local cache.

[0104] 3. The data plane adds EBPF processing at the sock connect mount point and tc ingress mount point, and updates the kernel space based on the relevant information stored in the cache. In this example, the relevant information is stored in the kernel space using an EBPF map data structure.

[0105] 4. The Endpoint health check program updates the cache and EBPF map based on the pod's IP network status and removes abnormal pods.

[0106] 5. The Metric program provides VIP-level monitoring information.

[0107] As can be seen from the above description, the data traffic forwarding system provided by the embodiments of the present invention solves the problem of data traffic jitter under all VIP addresses on the one hand, and the problem of resource waste during most periods of time on the other hand.

[0108] Figure 9This is a structural block diagram of another data traffic forwarding system provided by an embodiment of the present invention. This embodiment is based on and optimized from the above-described technical solutions. Optionally, in this embodiment, the data traffic forwarding system may further include: a load balancing controller; wherein, the application container corresponding to the virtual IP address provides a target service, the target service being tagged, the tag indicating that a load balancing container needs to be deployed; wherein, the load balancing controller is used to: for the application programming interface service deployed in the node cluster, obtain the tagged services in the node cluster from the application programming interface service; for the target service among the services, create a replica controller for the target service, so as to deploy the load balancing container on the target node through the replica controller. The explanations of terms that are the same as or corresponding to those in the above embodiments are not repeated here.

[0109] For details, see Figure 9 The data traffic forwarding system described in this embodiment may include: a load balancing proxy 510 and a load balancing controller 520, wherein the load balancing proxy 510 is deployed on the target node in the node cluster; wherein,

[0110] The load balancer controller 520 is used to obtain tagged services in the node cluster from the application programming interface service deployed in the node cluster. The tag indicates that a load balancing container needs to be deployed. Each service includes the target service, and the node cluster has an application container deployed to provide the target service.

[0111] The load balancer controller 520 is also used to create a replica set (rs) for the target service, so that the load balancer container corresponding to the target service can be deployed on the target node through the replica set controller. The IP address assigned to the load balancer container has been published as a virtual IP address.

[0112] The load balancer 510 is used to respond to data traffic to a virtual IP address and obtain candidate IP addresses corresponding to the virtual IP address, wherein each candidate IP address corresponds to a specific application container.

[0113] The load balancer broker 510 is also used to determine the target IP address from among the candidate IP addresses based on the load balancing strategy, and forward the data traffic to the target application container in each application container that corresponds to the target IP address.

[0114] The meanings of the load balancer 520 and the tags have been explained above and will not be repeated here.

[0115] The target service can be considered as any service among all tagged services. That is, the embodiments of the present invention are only illustrated using the target service as an example. Services other than the target service can be deployed in a similar way to create corresponding LB pods.

[0116] Specifically, an rs is created for the target service, so that the corresponding LB pod can be deployed on the target node through the rs. The candidate IP address associated with the VIP address represented by the LB pod is the IP address of the application container that provides the target service.

[0117] In the technical solution of this invention, the load balancer controller, in conjunction with the apiserver, determines the services that need to be deployed as LB pods from the apiserver, and then creates an RS for the service so that the corresponding LB pods can be deployed on the target node through the RS, thereby achieving load balancing of data traffic for the service.

[0118] An alternative technical solution involves deploying the load balancing container as a replica controller in the following manner:

[0119] For the number of containers recorded in the tag attached to the target service, determine the container nodes with the number of containers from each node in the node cluster, where each container node includes the target node;

[0120] For each target node in the container nodes, deploy a load balancing container on the target node.

[0121] The number of containers represents the number of load balancer pods that need to be deployed for the target service. The number of containers is determined from the nodes of the node cluster, and the load balancer pod is deployed on each container node. This separate deployment of the load balancer pod on each container node helps to distribute data traffic, thus achieving a traffic offloading effect. Furthermore, the method for determining the container nodes can be found in the method for determining the target IP address, and will not be repeated here.

[0122] The above technical solution achieves two goals: first, dynamic deployment of LB pods; and second, data traffic distribution, which avoids the situation where all data traffic for the target service is concentrated on the same container node.

[0123] Another alternative technical solution, the load balancer controller, is also used for:

[0124] In response to the load balancer container starting up, the IP address assigned to the load balancer container is filled into the external IP address of the target service as a virtual IP address to achieve the publication of the virtual IP address.

[0125] The above technical solution achieves effective publication of the VIP address by automatically associating it with the external IP address of the target service and then filling the VIP address into that external IP address.

[0126] Optionally, the aforementioned data traffic forwarding system may further include: a Domain Name System (DNS) controller; wherein the DNS controller is used for:

[0127] Retrieve tagged services from the node cluster from the application programming interface service;

[0128] For each target service, the external IP address of the target service is registered with the Domain Name System (DNS) service, so that the originating end of the data traffic obtains the external IP address from the DNS service and sends data traffic to the virtual IP address in the external IP address.

[0129] In the above technical solution, the Domain Name System (DNS) controller, in conjunction with the API server, obtains the target service with the corresponding VIP address (i.e., tagged) from the API server, and then registers the external IP address of the target service with the DNS service. In this way, clients, especially external clients, can obtain the external IP address from the DNS service, and particularly the VIP address within that external IP address, and then send data traffic targeting that VIP address.

[0130] Building upon this, to better understand the load balancer (Kube-lbcontroller) described above, the following example provides an illustrative illustration. For an example, see [link to example]. Figure 10 Kube-lbcontroller can be centrally deployed (primary / backup) and is mainly used for managing LB pods and SVC external IPs. The specific implementation process is as follows:

[0131] 1. After initialization and leader election, the kube-lb controller listens for information about resources such as svc, rs, and pods of the apiserver.

[0132] 2. Create an RS for the LB pod for an SVC with the label (kube-lb:true) of type clusterIP, and the number of replicas (i.e. the number of containers as described above) is the pod-num in the label.

[0133] 3. After the LB pod starts normally, fill in the LB pod's IP address into the external IP address of the svc.

[0134] 4. The lifecycle of rs follows the creation, updating, and deletion of the associated svc.

[0135] 5. The health check program probes the LB pod. If the LB pod is abnormal, it removes the corresponding VIP address from the external IP of the svc, then calls the apiserver to delete the abnormal LB pod. After the new LB pod starts normally, the external IP of the svc is updated.

[0136] Figure 11 This is a structural block diagram of a data traffic forwarding device provided in an embodiment of the present invention. This device is used to execute the data traffic forwarding method provided in any of the above embodiments. This device and the data traffic forwarding methods of the above embodiments belong to the same inventive concept. Details not described in detail in the embodiments of the data traffic forwarding device can be found in the embodiments of the data traffic forwarding methods described above. See also... Figure 11 The device is configured on a target node in a node cluster. A load balancing container is deployed on the target node. The IP address assigned to the load balancing container has been published as a virtual IP address. The device may specifically include a candidate IP address acquisition module 610 and a data traffic forwarding module 620.

[0137] The candidate IP address acquisition module 610 is used to acquire candidate IP addresses corresponding to virtual IP addresses in response to data traffic targeting virtual IP addresses, wherein each candidate IP address corresponds to a corresponding application container.

[0138] The data traffic forwarding module 620 is used to determine the target IP address from each candidate IP address based on the load balancing strategy, and forward the data traffic to the target application container corresponding to the target IP address in each application container.

[0139] Optionally, the aforementioned data traffic forwarding system may further include:

[0140] The candidate IP address acquisition module is used to identify the deployed load balancing container and obtain the candidate IP address corresponding to the IP address of the load balancing container from the application programming interface service deployed in the node cluster.

[0141] The candidate IP address storage module is used to store candidate IP addresses in the storage space of the target node, so as to retrieve candidate IP addresses from the storage space when responding to data traffic.

[0142] In addition, the aforementioned data traffic forwarding system may optionally include:

[0143] The first candidate IP address update module is used to monitor the application programming interface service and update the candidate IP address in the storage space based on the monitoring result when the candidate IP address in the application programming interface service is updated.

[0144] And / or,

[0145] The candidate IP address removal module is used to perform health checks on the application containers corresponding to candidate IP addresses in the storage space, and remove the candidate IP addresses of the application containers with abnormalities from the storage space if an anomaly is detected.

[0146] Optionally, if the data traffic originating end is not deployed on the target node, the data traffic forwarding module 620 may include:

[0147] The first data traffic forwarding unit is used to convert the source IP address of the data traffic from the originating IP address to a virtual IP address, and to convert the destination IP address of the data traffic from a virtual IP address to a target IP address, so as to forward the data traffic to the target application container corresponding to the converted destination IP address in each application container. The conversion of the source IP address is to enable the target application container to return the response traffic to the target node in response to the data traffic.

[0148] Or,

[0149] When the data traffic originating end is deployed on the target node, the data traffic forwarding module 620 may include:

[0150] The second data traffic forwarding unit can be used to convert the destination IP address of data traffic from a virtual IP address to a target IP address, so as to forward the data traffic to the target application container corresponding to the converted destination IP address in each application container.

[0151] Optionally, a target program is embedded in the kernel corresponding to the target node. The candidate IP address acquisition module 610 may include:

[0152] The candidate IP address acquisition unit is used to intercept data traffic through the target program and obtain the candidate IP address corresponding to the virtual IP address, so as to forward the data traffic to the target application container.

[0153] Based on this, optionally, the target program obtains candidate IP addresses from the kernel space of the kernel. These candidate IP addresses in the kernel space are pre-obtained from the storage space on the target node and stored in the kernel space by the data plane in the node cluster. The aforementioned data traffic forwarding device may further include:

[0154] The second candidate IP address update module is used to update the candidate IP addresses stored in the kernel space in response to an update of the candidate IP addresses stored in the storage space through the data plane, based on the update result of the storage space.

[0155] Alternatively, the target program may be mounted on the kernel's network socket connection mount point and flow control entry mount point, respectively; the candidate IP address acquisition unit may include:

[0156] The first data traffic subunit is used to intercept data traffic by a target program mounted on a network socket connection mount point when the data traffic originating from the target node is deployed on the target node.

[0157] Or,

[0158] The second data traffic subunit is used to intercept data traffic by attaching a target program to the traffic control entry point when the data traffic originating from the target node is not deployed on the target node.

[0159] The data traffic forwarding device provided in this embodiment of the invention solves the problem of data traffic jitter under all VIP addresses by cooperating with each other through various modules.

[0160] The data traffic forwarding device provided in the embodiments of the present invention can execute the data traffic forwarding method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0161] It is worth noting that in the above-described embodiments of the data traffic forwarding device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0162] Figure 12 A schematic diagram of a target node 10 located in a node cluster, which can be used to implement embodiments of the present invention, is shown. A load balancing container is deployed on the target node 10, and the IP address assigned to the load balancing container has been advertised as a virtual IP address. The target node is intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The target node can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0163] like Figure 12 As shown, the target node 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 and a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the target node 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0164] Multiple components in target node 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows target node 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0165] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as data traffic forwarding methods.

[0166] In some embodiments, the data traffic forwarding method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the target node 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data traffic forwarding method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the data traffic forwarding method by any other suitable means (e.g., by means of firmware).

[0167] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips or system-on-a-chips (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0168] Computer programs used to implement the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0169] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0170] To provide interaction with the user, the systems and techniques described herein can be implemented on a target node having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the target node. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0171] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0172] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0173] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory 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 unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0174] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

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

Claims

1. A data traffic forwarding method, characterized in that, The method involves applying the method to a target node in a node cluster, wherein a load balancing container is deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address. In response to data traffic to the virtual IP address, candidate IP addresses corresponding to the virtual IP address are obtained, wherein each candidate IP address corresponds to a corresponding application container; Based on the load balancing strategy, the target IP address is determined from the candidate IP addresses, and the data traffic is forwarded to the target application container corresponding to the target IP address in each application container.

2. The method according to claim 1, characterized in that, Also includes: Identify the deployed load balancing container and obtain the candidate IP address corresponding to the IP address of the load balancing container from the application programming interface service deployed in the node cluster; For the storage space of the target node, the candidate IP address is stored in the storage space so that the candidate IP address can be retrieved from the storage space when responding to the data traffic.

3. The method according to claim 2, characterized in that, Also includes: Monitor the application programming interface service, and if an update is detected in the candidate IP address in the application programming interface service, update the candidate IP address in the storage space based on the monitoring result; And / or, A health check is performed on the application container corresponding to the candidate IP address in the storage space, and if an anomaly is detected, the candidate IP address of the application container with the anomaly is removed from the storage space.

4. The method according to claim 1, characterized in that, If the originating end of the data traffic is not deployed on the target node, forwarding the data traffic to the target application container corresponding to the target IP address in each of the application containers includes: The source IP address of the data traffic is converted from the originating IP address to the virtual IP address, and the destination IP address of the data traffic is converted from the virtual IP address to the target IP address, so as to forward the data traffic to the target application container in each application container corresponding to the converted destination IP address. The conversion of the source IP address is to enable the target application container to return the response traffic for the data traffic to the target node. Or, When the originating end of the data traffic is deployed on the target node, forwarding the data traffic to the target application container corresponding to the target IP address in each of the application containers includes: The destination IP address of the data traffic is converted from the virtual IP address to the target IP address, so as to forward the data traffic to the target application container corresponding to the converted destination IP address in each of the application containers.

5. The method according to claim 1, characterized in that, The target program is embedded in the kernel corresponding to the target node. The step of obtaining the candidate IP address corresponding to the virtual IP address includes: The target program intercepts the data traffic and obtains a candidate IP address corresponding to the virtual IP address, so as to forward the data traffic to the target application container.

6. The method according to claim 5, characterized in that, The target program obtains the candidate IP address from the kernel space of the kernel. The candidate IP address in the kernel space is obtained in advance from the storage space on the target node and stored in the kernel space by the data plane in the node cluster. The method further includes: Through the data plane, in response to an update of the candidate IP address stored in the storage space, the candidate IP address stored in the kernel space is updated based on the update result of the storage space.

7. The method according to claim 5, characterized in that, The target program is mounted on the network socket connection mount point and the flow control entry mount point of the kernel, respectively; The interception of data traffic through the target program includes: When the data traffic originating from the target node is deployed on the target node, the data traffic is intercepted by the target program mounted on the network socket connection mount point; Or, If the data traffic originating from the target node is not deployed on the target node, the data traffic is intercepted by the target program mounted on the traffic control ingress mounting point.

8. A data traffic forwarding system, characterized in that, include: A load balancing proxy, wherein the load balancing proxy is deployed on a target node in a node cluster, and a load balancing container is also deployed on the target node, the IP address assigned to the load balancing container has been advertised as a virtual IP address; wherein... The load balancing agent is used to perform the data traffic forwarding method according to any one of claims 1-7.

9. The system according to claim 8, characterized in that, Also includes: A load balancer controller; wherein the application container corresponding to the virtual IP address provides a target service, the target service being tagged with a tag indicating that a load balancing container needs to be deployed; wherein the load balancer controller is used for: For the application programming interface service deployed in the node cluster, obtain the services in the node cluster that are tagged with the above tag from the application programming interface service; For each of the aforementioned services, a replica controller is created for the target service to deploy the load balancing container on the target node through the replica controller.

10. The system according to claim 9, characterized in that, The replica controller deploys the load balancing container in the following manner: For the number of containers recorded in the tag attached to the target service, container nodes containing the number of containers are determined from each node in the node cluster, wherein each container node includes the target node; For each of the container nodes, the load balancing container is deployed on the target node.

11. The system according to claim 9, characterized in that, The load balancer controller is also used for: In response to the start of the load balancing container, the IP address assigned to the load balancing container is filled into the external IP address of the target service as the virtual IP address, so as to realize the publication of the virtual IP address.

12. The system according to claim 11, characterized in that, Also includes: Domain Name System (DNS) controller; wherein, the DNS controller is configured to: Obtain the services in the node cluster that are tagged with the above tag from the application programming interface service; For each of the aforementioned services, the external IP address of the target service is registered with the Domain Name System (DNS) service, so that the originating end of the data traffic obtains the external IP address from the DNS service and sends the data traffic to the virtual IP address of the external IP address.

13. A data traffic forwarding device, characterized in that, A target node configured in a node cluster, wherein a load balancing container is deployed on the target node, and the IP address assigned to the load balancing container has been advertised as a virtual IP address, the device comprising: The candidate IP address acquisition module is used to acquire candidate IP addresses corresponding to the virtual IP address in response to data traffic to the virtual IP address, wherein each candidate IP address corresponds to a corresponding application container; The data traffic forwarding module is used to determine the target IP address from the candidate IP addresses based on the load balancing strategy, and forward the data traffic to the target application container corresponding to the target IP address in each of the application containers.

14. A target node, characterized in that, The target node is located in a node cluster, and a load balancing container is deployed on the target node. The IP address assigned to the load balancing container has been advertised as a virtual IP address. The target node includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to cause the at least one processor to perform the data traffic forwarding method as described in any one of claims 1-7.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement the data traffic forwarding method as described in any one of claims 1-7.

16. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the data traffic forwarding method as described in any one of claims 1-7.

Images