Load balancing method, platform, electronic device and computer readable storage medium

Abstract

The disclosure provides a load balancing method, platform, electronic device and computer readable storage medium, the method comprising: receiving an access request of a user device, the access request being used to request access to a predetermined application, and the access request carrying a virtual network address; finding routing information corresponding to the virtual network address from preset routing table information, the routing information being used to indicate a routing relationship between the virtual network address and network addresses of a plurality of service replicas; the plurality of service replicas being service replicas of the application, and the plurality of service replicas running on at least one node device in a container cluster management system; and forwarding the access request to a data receiving interface of each service replica through the network address of each service replica, the forwarding of the access request being used to evenly distribute access to the application to each service replica. According to the embodiments of the disclosure, the processing performance of load balancing can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of container service technology, and in particular to a load balancing method, platform, electronic device, and computer-readable storage medium. Background Technology

[0002] Kubernetes (K8s) is an open-source, container-based distributed architecture system that enables automated deployment, scaling, and maintenance of container clusters. Load balancing refers to distributing workloads, such as tasks, across multiple operational units within the Kubernetes containerized platform, allowing these units to collaborate and complete tasks. On the Kubernetes containerized platform, the load balancing technology for pods requires address translation before packet forwarding, which is time-consuming and results in poor load balancing performance. Summary of the Invention

[0003] This disclosure provides a load balancing method, platform, electronic device, and computer-readable storage medium that can improve the processing performance of load balancing.

[0004] In a first aspect, this disclosure provides a load balancing method, which includes: receiving an access request from a user device, the access request being for accessing a predetermined application, and the access request carrying a virtual network address; searching for routing information corresponding to the virtual network address from a preset routing table, the routing information being for indicating the routing relationship between the virtual network address and network addresses of multiple service replicas; the multiple service replicas being service replicas of the application, and the multiple service replicas running on at least one node device in a container cluster management system; and forwarding the access request to the data receiving interface of each service replica through the network address of each service replica, the forwarding of the access request being used to evenly distribute access to the application across each service replica.

[0005] Secondly, this disclosure provides a container cluster management system, which includes: a load management platform, the load management platform including: a receiving module for receiving access requests from user devices, the access requests being for accessing a predetermined application, and the access requests carrying a virtual network address; a lookup module for looking up first routing information corresponding to the virtual network address from a preset routing table, the first routing information indicating the routing relationship between the virtual network address and the network addresses of each of a plurality of service replicas; the plurality of service replicas being service replicas of the application, and the plurality of service replicas running on at least one node device in the container cluster management system; and a forwarding module for forwarding the access requests to the data receiving interface of each service replica via the network address of each service replica, the forwarding of the access requests being used to evenly distribute access to the application across each service replica.

[0006] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the above-described load balancing method.

[0007] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-described load balancing method when executed by a processor / processor core.

[0008] In the embodiments provided in this disclosure, the access requests from user equipment carry virtual network addresses. Based on the pre-established routing relationship between the virtual network address and the network addresses of multiple service replicas, access requests to a predetermined application can be evenly distributed to each service replica, achieving load balancing of access requests from user equipment. In this method, by establishing the routing relationship between the virtual network address and the network addresses of multiple service replicas, access requests from user equipment are directly forwarded to multiple service replicas. Compared to related technologies where load balancing requires address translation processing related to a proxy before data packet forwarding, the method of this disclosure reduces the time consumption of the data forwarding process, thus improving the performance of load balancing.

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

[0010] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0011] Figure 1 A flowchart of a load balancing method provided in this disclosure embodiment;

[0012] Figure 2 A schematic diagram of the architecture of the container cluster management system provided in this embodiment of the disclosure;

[0013] Figure 3 A block diagram of a container cluster management system provided in an embodiment of this disclosure;

[0014] Figure 4 A block diagram of a container cluster management system provided in an embodiment of this disclosure;

[0015] Figure 5 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0017] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0018] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, they specify the presence of features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0020] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0021] In this embodiment of the disclosure, in the Kubernetes system, the smallest running unit on a node is a virtual container or an enhanced container (Pod) within the node. A Pod is the basic scheduling unit created or deployed by Kubernetes for operating containers. Each Pod can include multiple containers; a Pod can be viewed as an extension or enhancement of a container, with the multiple containers within a Pod working together to perform a specific function. A Pod represents an instance of a process or application running on the cluster. When multiple processes are packaged into a single namespace, they constitute a Pod.

[0022] On the Kubernetes containerization platform, load balancing technologies for pods mainly include native Kubernetes cluster load balancing technologies and routing rule services (ingress-nginx) technologies. The core technology of this type of load balancing is to forward traffic to pods through a proxy.

[0023] For Kubernetes cluster load balancing, each node in a Kubernetes cluster can run a kube-proxy process. Kube-proxy is a network proxy component running on each node in Kubernetes. It maintains network rules on the nodes. The kube-proxy process running on each node is essentially an intelligent software load balancer; it forwards requests to the service to a backend Pod instance and internally implements load balancing and session persistence mechanisms for the service.

[0024] For the ingress load balancer (Ingress-nginx) technology, Ingress in Kubernetes is a Layer 7 routing and forwarding mechanism, typically using Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS). Ingress can be understood as an entry point for accessing the Kubernetes cluster from outside; that is, Ingress provides an entry point for services within the Kubernetes cluster, enabling access to internal Kubernetes applications via domain names and providing load balancing functionality. Common Ingress implementations include load balancers (Nginx). Typically, Ingress is deployed on all Node nodes, defining routing rules to obtain HTTP and HTTPS routing rules from outside the cluster to inside. Service routing functionality based on flexible Ingress policy definitions is implemented through control policies and specific Ingress controllers that provide forwarding services.

[0025] In related technologies, load balancing in Kubernetes (K8S) does not directly achieve traffic load balancing through the functions provided by the load balancer itself. Instead, it utilizes the firewall rules (IPTables) provided by the Linux operating system or the load balancing capabilities provided by IP Virtual Servers (IPVS) to forward traffic to pods. IPTables is a commonly used firewall software on Linux; IPVS is a technology that provides load balancing functionality while running on Linux Virtual Servers (LVS). When installing a K8S cluster, it is necessary to specify whether to use IPTables or IPVS load balancing methods. Additionally, load balancing in K8S can also utilize the load balancing capabilities provided by the open-source Nginx load balancer to forward traffic to pods.

[0026] Specifically, in related technologies, both Kubernetes cluster and Ingress-nginx load balancing technologies require monitoring the functionality provided by the Kubernetes Application Programming Interface (API) to listen for changes in Pods in real time (changes include restarts, deletions, and additions). When a change is detected, Kubernetes cluster updates the iptables rule table, and Ingress-nginx updates the upstream forwarding table, ultimately enabling traffic forwarding to Pods accessed via the Virtual IP Address (VIP) provided by the cluster and ingress.

[0027] In some scenarios related to this technology, when a user device accesses the VIP address 10.97.217.168 of a K8Scluster via the source IP address 10.193.7.1, the traffic data will be forwarded to the pod's IP address 10.97.106.99. The entire traffic forwarding can be chained into a complete data forwarding link through IP Tables rules. After the traffic data arrives at the target pod, the source IP address can be viewed on the target pod. It can be seen that the user device's request source IP address is displayed as 10.97.3.1, which is the traffic entry address of the Kubernetes cluster. However, the user device's real source IP address is 10.193.7.1, which is inconsistent. The real source IP address of the user device cannot be viewed on the target pod.

[0028] In the load balancing process described above, Kubernetes Cluster is based on Layer 4 load balancing technology, while Ingress-nginx is based on Layer 4 / 7 load balancing technology developed using Nginx. Taking Layer 4 load balancing technology as an example, when a user device accesses the VIP address through its real source IP address, it uses either the Transmission Control Protocol (TCP) or a connectionless transport protocol (User Datagram Protocol). After a Layer 4 network proxy (UDP protocol) is used, the Pod can only obtain the proxy server's IP address, not the actual user device's IP address. Therefore, the Pod cannot see the user device's real source IP address. Furthermore, after the user device's access requests are processed by the kube-proxy proxy component in Kubernetes, the entire business architecture relies on the kube-proxy proxy component to forward data to a specific Pod. This is equivalent to the kube-proxy proxy component becoming a unified traffic entry point or a "centralized" gateway. This leads to excessive reliance on kube-proxy for data forwarding. Once the kube-proxy proxy component fails, all related fault domains (servers, storage, and / or network connection components) will fail, resulting in a problem of concentrated fault domains. In addition, different types of proxy components often rely on different underlying technologies, which is not conducive to the unified standard implementation of the native Kubernetes architecture. Moreover, the proxy component needs to perform proxy-related address translation processing before forwarding data packets, which takes a long time and results in poor load balancing performance.

[0029] The load balancing method according to embodiments of this disclosure can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Servers can include independent physical servers, server clusters consisting of multiple servers, or cloud servers capable of cloud computing.

[0030] Figure 1 A flowchart illustrating a load balancing method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The load balancing method may include the following steps.

[0031] S110 receives an access request from a user device. The access request is used to request access to a predefined application and carries a virtual network address.

[0032] S120: Search for the routing information corresponding to the virtual network address from the preset routing table information. The routing information is used to indicate the routing relationship between the virtual network address and the network addresses of multiple service replicas. The multiple service replicas are service replicas of the application, and the multiple service replicas run on at least one node device in the container cluster management system.

[0033] In this step, the network address (Node IP) of the node device can be the IP address of the node device's physical network interface card (NIC); the application is a program running on the node device, which can be represented by a Pod. A service copy of the application refers to a copy of the application file that provides the same functionality. For example, multiple service copies of the application, such as three service copies, can be represented by Pod1, Pod2, and Pod3. Pod1, Pod2, and Pod3 provide the same service, i.e., provide the same functionality. Pod1, Pod2, and Pod3 have their own IP addresses, and Kubernetes assigns a unique IP address to each Pod.

[0034] S130 forwards access requests to the data receiving interface of each service replica via the network address of each service replica. The forwarding of access requests is used to distribute access to the application evenly across each service replica.

[0035] In this step, the access request carrying the VIP sent by the user device is forwarded to each pod running on at least one node device by the routing relationship between the virtual network address and the network addresses of multiple service replicas, that is, by the routing relationship between the VIP and multiple Pod IPs. The access request forwarding distributes the access to the application evenly to each service replica, so that multiple pods can be accessed by a single VIP address, thus achieving traffic balance.

[0036] In this embodiment, the user equipment's access request carries a virtual network address. Based on the pre-established routing relationship between the virtual network address and the network addresses of multiple service replicas, access requests to a predetermined application can be evenly distributed to each service replica, achieving load balancing of access requests from the user equipment. In this method, by establishing a routing relationship between the virtual network address and the network addresses of multiple service replicas, access requests from the user equipment are directly forwarded to multiple service replicas. Compared to related technologies where load balancing requires address translation processing related to a proxy before data packet forwarding, this embodiment reduces the time consumed in the data forwarding process, thus improving the performance of load balancing.

[0037] In this embodiment of the disclosure, since access requests to the application can be directly forwarded to multiple service replicas of the application, and each service replica can directly obtain the real source IP of the user device that initiated the access request, various business applications can be implemented based on the real source IP of the user device in scenarios that require the use of the user's real source IP. These scenarios may include, for example, network probing based on the real source IP of the user device and risk warnings for remote logins in the container cluster management system, thereby meeting the security requirements of the container cluster.

[0038] The load balancing method of this disclosure does not rely on the kube-proxy proxy component to forward traffic related to access requests. Instead, it can achieve distributed load balancing for each application by setting multiple service replicas to run on different node devices. If one service replica of an application has a problem, it will not affect the operation of other replicas of the application. Therefore, it will not have the problem of fault domain concentration caused by the use of the kube-proxy proxy component in related technologies, thus improving the operational stability of the system.

[0039] Furthermore, in this embodiment of the present disclosure, compared to the related technologies where different types of proxy components are used in the container cluster management system, the underlying technologies on which different types of proxy components depend are inconsistent, which would cause the k8s native architecture to fail to achieve a unified underlying technology standard, the load balancing method of this embodiment of the present disclosure allows multiple service components to run on at least one node device in the container cluster management system, and the underlying technology of each service component is based on container technology (with consistent underlying technologies), which is conducive to achieving a unified standard of underlying technology for the k8s native architecture.

[0040] Figure 2 This is a schematic diagram of the architecture of a container cluster management system provided in an embodiment of this disclosure. Figure 2 The container cluster management system 200 includes: a load management platform 210, a container cluster platform 220, a configuration management database 230, and a network management platform 240.

[0041] exist Figure 2 In the middle, the load management platform (Kubernetes load management platform) 210 is used to establish routing relationships between virtual network addresses and the network addresses of multiple service replicas, directly forwarding access requests from user devices to multiple service replicas, thereby achieving a balanced distribution of access requests from user devices to each service replica and achieving traffic balancing; the container cluster platform (Kubernetes platform) 220 is responsible for managing the cluster components in the entire Kubernetes cluster, including multiple Nodes and Pods running on each Node; Figure 2In this example, multiple nodes include Node1, Node2, and Node3. Node1 runs pod1, Node2 runs pod2, and Node3 runs pod3. pod1, pod2, and pod3 are three service replicas of the same application, providing the same functionality. In some embodiments, a Node is a physical server. When a physical server joins a Kubernetes cluster, it can be defined as a Node in Kubernetes.

[0042] Continue to refer to Figure 2 The Configuration Management Database (CMDB) system 230 is used to store basic information such as router routing information, switch information, and server information, and is a basic asset management platform; the network management platform (referred to as the Kubernetes network management platform) 240 is used to manage the IP addresses used by pods and ensure network connectivity.

[0043] The following is combined Figure 2 The container cluster management system described herein provides a detailed description of the load management method of embodiments of this disclosure.

[0044] In some embodiments, prior to step S110, the load balancing method further includes:

[0045] S11, obtain the basic information of each service copy that is pre-stored and the routing information of the router corresponding to at least one node device that is pre-stored.

[0046] In some embodiments, the load management platform 210 can obtain basic information of each service replica through the container cluster platform 220, and obtain router information and other information corresponding to the basic hardware information of each service replica from the configuration management database 230.

[0047] For example, the basic information (PodInfo) may include one or more of the following: the service replica name (PodName) for each service replica, the network address (Pod IP) for each service replica, the network address (Node IP) of the node device corresponding to each service replica, and the gateway address (GatewayIP) of the corresponding node device. Different service replicas have different Pod names and Pod IPs.

[0048] For example, the corresponding router information (Routeinfo) may include: the gateway address (gatewayip) of the node device and the routing table information (Routelist) corresponding to the gateway address.

[0049] S12 generates a virtual network address based on the basic information and the router's routing information.

[0050] In this step, the load management platform 210 can automatically generate virtual network addresses, each corresponding to the Pod IP and Node IP in the basic information.

[0051] S13, through the virtual device interface pair, generate the association information between the virtual network address and each service replica, generate the routing information corresponding to each association information, and add the routing information to the routing table information.

[0052] In this embodiment, a direct association between a virtual network address and multiple service replicas of the application is established through a virtual device interface pair, providing a foundation for subsequently forwarding access requests from user devices directly to multiple service replicas and achieving load balancing for the application.

[0053] In some embodiments, the basic information includes: the network address of each service replica and the network address of the node device corresponding to each service replica, as well as the gateway address of the corresponding node device; the routing information of the router includes: the routing information corresponding to the gateway address of each node device.

[0054] In this embodiment, step S12 may specifically include:

[0055] S21, obtain a virtual network address as the first address based on the Dynamic Host Configuration Protocol.

[0056] refer to Figure 2 The load management platform 210 can obtain dynamically assigned virtual network addresses through a DHCP client. Dynamic Host Configuration Protocol (DHCP) is a local area network protocol that allows a server to control a range of IP addresses. When a DHCP client logs into the DHCP server, it can automatically obtain an IP address and subnet mask assigned by the server.

[0057] S22, find the routing information corresponding to the first address from the routing information corresponding to the gateway address of each node device.

[0058] S23, if no routing information corresponding to the first address is found, determine that the first address has not been used and use the first address as the generated virtual network address.

[0059] In this embodiment, the RouteList, which corresponds to the gateway address of the node device, stores routing information corresponding to different virtual network addresses. The generated virtual network addresses are checked for duplicates. Specifically, it checks whether the routing information corresponding to the first address already exists. If it does not exist, it is determined that the first address has not been used, that is, the generated virtual network address has not been used. If it exists, steps S21-S23 are repeated until a virtual network address that passes the duplicate check is obtained. A virtual network address corresponding to the Node IP and Pod IP is generated for each service replica running on each node device.

[0060] In some embodiments, steps S21-S23 above can be executed through the function setpodvip, and after executing step S23, the generated result (getresult) is output. If the output generated result is 1, it means that the execution was successful; if the output generated result is 2, it means that the execution failed; if the output generated result is 0, it means that the interface call failed; if the output generated result is 3, it means that there was a partial failure, such as execution failure caused by a network error.

[0061] In some embodiments, for a generation result that fails entirely or partially, the virtual network address generated in step S21 can be deleted, and then steps S21-S23 can be re-executed.

[0062] For example, the `delpodvip` function can be used to delete a virtual network address. Specifically, it obtains the corresponding virtual network address using the PodIP and Node IP, and then performs a deletion operation on that virtual network address. After the deletion operation, it outputs the deletion result. If the deletion result (getdelresult) is 1, it indicates that the deletion was successful; if the deletion result is 0, it indicates that the deletion failed.

[0063] It should be understood that the values ​​of the above allocation results and the processing results of the deletion operation can be set according to actual needs, and this disclosure embodiment does not make specific limitations.

[0064] In some embodiments, if the routing information generated in step S13 is referred to as the first routing information, then second routing information can be generated based on the routing relationship between the virtual network address and the network address of each node device, and the second routing information can be added to the routing table information. For example, in... Figure 2 In the routing table information, the second routing information is used to characterize the routing relationship between the virtual network address and the network addresses of multiple node devices such as Node1, Node2 and Node3. Through the second routing information, it can be determined which node devices the access request is forwarded to as a service replica.

[0065] In this embodiment, the step of generating second routing information based on the routing relationship between the virtual network address and the network address of each node device may specifically include: generating interface information of the virtual network address based on the network address of the node device, the network address of the service replica running on the node device, and the corresponding virtual network address; publishing the interface information of the virtual network address to the router corresponding to the node device, and the router adding the routing information corresponding to the interface information to the routing table information to obtain the second routing information.

[0066] For example, the load management platform 210 sends the virtual network address (VIP corresponding to the Node IP and Pod IP) to the network management platform 240. Based on the received information, the network management platform 240 sends a command to the node agent server (Node Agent) on the corresponding node device to add the VIP interface. The command carries command parameters (Node IP, Pod IP, VIP). The Agent on the node device executes the steps described above to generate the second routing information, allocates the corresponding interface information to the virtual network address, and generates routing information corresponding to the interface information.

[0067] In some embodiments, the network management platform 240 is used to implement the use and management of the Node Agent. By issuing a setting command to the Node Agent, the command carries command parameters (Node IP, Pod IP, VIP). The Agent on the Node parses the command to obtain the command parameters carried in the command. Then, by associating the VIP with the Node IP and Pod IP, the Node Agent publishes the first routing information and the second routing information to the router.

[0068] For example, the load management platform 210 can also perform deletion operations on the interface information of virtual network addresses according to management needs. For instance, the load management platform 210 sends a deletion command to the Node Agent, which carries command parameters (NodeIP, Pod IP, VIP). The Agent on the Node parses the command, obtains the command parameters carried in the command, and then deletes the interface information of the VIP corresponding to the Node IP and Pod IP.

[0069] In this embodiment, the load management platform 210 can also trigger the activation of the load function. Specifically, the load management platform 210 sends an activation request to the network management platform 240 to request the activation of the load function; upon receiving the activation request, the network management platform 240 begins sending configuration commands to the Node Agent on the node device where the service copy of the application runs, and implements the underlying configuration required to activate the load function through the Node Agent. After the configuration is completed, the VIP is published to the corresponding router through the relevant routing protocol.

[0070] In some embodiments, the network address of each service replica corresponds to a pre-configured virtual network device; the step S13 above, which generates the association information between the virtual network address and each service replica through the virtual device interface pair, may include the following steps:

[0071] S41, establish an association between the virtual network address and the network address of the i-th service replica and the corresponding virtual network device; wherein, the virtual network device is used to directly send the access request corresponding to the virtual network address to the data receiving interface of the i-th service replica, where i is greater than or equal to 1 and less than the total number of service replicas.

[0072] In this step, the virtual network (Veth Pair) device is a software device used to solve the communication between physical machines and pods. A Veth Pair can be understood as a virtual network cable and contains a pair of ports, which can also be called a virtual device interface pair. Data packets entering from one interface of the virtual device interface pair will exit from the other interface of the same virtual device interface pair, and vice versa.

[0073] S42, generate association information corresponding to the association relationship, as the association information between the virtual network address and the i-th service copy.

[0074] For example, for any service replica Pod1, assume the device name of the Veth Pair device for Pod1 is veth1, and the IP address of Pod1 is 2.2.2.2. The Linux system's route command is used to display and manipulate the IP routing table. The routing information displayed by the command "route -n" is as follows: "2.2.2.2 255.255.255.255veth1 corresponds to pod1", where 255.255.255.255 is the subnet mask. The method to associate the VIP address with the network address of Pod1 can be achieved by the following command: "route add 1.1.1.1mask 255.255.255.0dev veth1". This command means adding the connection between the VIP address "1.1.1.1" and the Veth Pair device "veth1" in the routing information.

[0075] After the command executes successfully and the VIP is set up successfully, the information displayed by the command `route -n` is as follows:

[0076] 2.2.2.2 255.255.255.255 veth1

[0077] 1.1.1.1 255.255.255.255veth1

[0078] At this point, Pod1's network address and VIP are associated with the Veth Pair device "veth1".

[0079] For example, for any service replica Pod2, after the VIP address "1.1.1.1" and Pod2's network address "3.3.3.3" are associated with the Veth Pair device "veth2", the information displayed by the command route -n is as follows:

[0080] 3.3.3.3 255.255.255.255veth1

[0081] 1.1.1.1 255.255.255.255veth1

[0082] For example, for any service replica Pod3, after the VIP address "1.1.1.1" and Pod3's network address "4.4.4.4" are associated with the Veth Pair device "veth3", the information displayed by the command route -n is as follows:

[0083] 4.4.4.4 255.255.255.255veth1

[0084] 1.1.1.1 255.255.255.255veth1

[0085] For example, if pod1 and pod2 are on the same Node (pod1 and pod2 are two identical service replicas of the same application), the route -n of VIP address 1.1.1.1 will look like this:

[0086] 1.1.1.1 255.255.255.255veth1

[0087] veth2

[0088] In other words, if pod1 and pod2 are on the same physical node, the association information established between VIP address 1.1.1.1 and the Veth Pair device "veth1" corresponding to the network address of pod1, and the association information established between VIP address 1.1.1.1 and the Veth Pair device "veth2" corresponding to the network address of pod2, can be represented in the above form, indicating that VIP address 1.1.1.1 is associated with both veth1 and veth2.

[0089] In this way, the virtual network address and the network address of any service replica can be associated with the Veth Pair device corresponding to that service replica.

[0090] In some embodiments, the step of generating routing information corresponding to each association information in step S13 above may specifically include: publishing the routing information corresponding to each established association relationship to the router corresponding to the node device based on a predetermined routing protocol, and the router being used to add the equivalent route path corresponding to each association information to the routing information.

[0091] For example, to ensure that data traffic corresponding to access requests to VIP 1.1.1.1 is evenly distributed across pod1, pod2, and pod3, the VIP needs to be published in Border Gateway Protocol (BGP) or Open Shortest Path First Interior Gateway Protocol (OSPF) to form ECMP equivalent routes. This will create ECMP equivalent routes to 1.1.1.1 on the router. Simply put, ECMP means there are multiple paths to 1.1.1.1, each with the same weight. This allows multiple pods to be accessed by a single VIP address, achieving traffic balance.

[0092] For example, the Node Agent can publish the veth information of the Pod running on the Node to OSPF / BGP. When the veth1 interface is directly published to the routing information via the BGP protocol, it can be achieved through the function protocol direct{interface-"veth1(interface)","bgp / ospf(protocol)","establish neighbor with router"}.

[0093] In this embodiment, the router's routing table information is updated with an equivalent route path corresponding to each association established through the Veth Pair device, and corresponding routing information is generated to obtain routing information corresponding to the virtual network address.

[0094] In this embodiment, by establishing a routing relationship between a virtual network address and the network addresses of multiple service replicas, access requests from user devices are directly forwarded to multiple service replicas. Compared to the load balancing process in related technologies, which requires address translation processing related to the proxy before forwarding data packets, this embodiment can reduce the time consumption of the data forwarding process and improve the processing performance of load balancing.

[0095] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0096] In addition, this disclosure also provides a container cluster management system, electronic devices, and computer-readable storage media, all of which can be used to implement any of the load balancing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the relevant section on methods and will not be repeated here.

[0097] Figure 3 This is a block diagram of a container cluster management system provided in an embodiment of the present disclosure. Figure 3 and Figure 2 Identical or equivalent structures have the same label.

[0098] In some embodiments, the container cluster management system 200 includes a load management platform 210, which includes: a receiving module 211 for receiving access requests from user devices, the access requests being for accessing a predetermined application and carrying a virtual network address; a lookup module 212 for looking up first routing information corresponding to the virtual network address from a preset routing table, the first routing information indicating the routing relationship between the virtual network address and the network address of each of a plurality of service replicas; the plurality of service replicas being service replicas of the application, and the plurality of service replicas running on at least one node device in the container cluster management system 200; and a forwarding module 213 for forwarding access requests to the data receiving interface of each service replica via the network address of each service replica, the forwarding of access requests being used to evenly distribute access to the application across each service replica.

[0099] In the container cluster management system of this disclosure embodiment, the load management platform receives access requests from user devices, obtains the virtual network address carried in the access request, and distributes access requests to the predetermined application evenly to each service replica according to the routing relationship between the pre-established virtual network address and the network addresses of multiple service replicas, thereby achieving load balancing of access requests from user devices. Compared with the load balancing process in related technologies, which requires proxy-related address translation processing before data packet traffic forwarding, this method can reduce the time consumption of data forwarding process and improve the processing performance of load balancing.

[0100] Figure 4 A block diagram of a container cluster management system provided in an exemplary embodiment of this disclosure is shown. Figure 4 and Figure 2 , Figure 3 Identical or equivalent structures have the same label.

[0101] In some embodiments, the container cluster management system 200 further includes a network management platform 240; the load management platform 210 further includes an acquisition module and a sending module; the acquisition module is used to acquire pre-stored basic information of each service replica and pre-stored routing information of the router corresponding to at least one node device before receiving an access request from a user device; the sending module is used to send the basic information and the routing information of the router to the network management platform 240; the network management platform 240 is used to send an address setting instruction to the node proxy server running on each node device, the address setting instruction including the basic information and the routing information of the router; the node proxy server running on each node device is used to generate a virtual network address based on the basic information and the routing information of the router, generate association information between the virtual network address and each service replica through the virtual device interface pair, generate first routing information corresponding to each association information, and add the first routing information to the routing table information.

[0102] In some embodiments, the load management platform 210 is further configured to: obtain a virtual network address as a first address based on the Dynamic Host Configuration Protocol; search for routing information corresponding to the first address from the routing information corresponding to the gateway address of each node device; if no routing information corresponding to the first address is found, determine that the first address has not been used, and send the virtual network address to the network management platform 240 as the generated virtual network address.

[0103] In some embodiments, the network address of each service replica corresponds to a pre-configured virtual network device; the node proxy server running on each node device is specifically used to: establish an association between the virtual network address and the network address of the i-th service replica and the corresponding virtual network device; wherein, the virtual network device is used to directly send the access request corresponding to the virtual network address to the data receiving interface of the i-th service replica, where i is greater than or equal to 1 and less than the total number of service replicas; generate association information corresponding to the association relationship, as the association information between the virtual network address and the i-th service replica.

[0104] According to the container cluster management system of this disclosure, the system receives access requests from user devices through a load management platform, obtains the virtual network address carried in the access request, and distributes access requests to a predetermined application evenly to each service replica based on the routing relationship between the virtual network address and the network addresses of multiple service replicas. This achieves load balancing of access requests from user devices. Compared with the load balancing process in related technologies, which requires address translation processing related to the proxy before forwarding data packets, this system can reduce the time consumption of the data forwarding process and improve the processing performance of load balancing.

[0105] It should be clarified that the present invention is not limited to the specific configurations and processes described in the above embodiments and shown in the figures. For the sake of convenience and brevity, detailed descriptions of known methods are omitted here, and the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0106] Figure 5 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0107] Reference Figure 5 This disclosure provides an electronic device, which includes: at least one processor 501; at least one memory 502; and one or more I / O interfaces 503 connected between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs that can be executed by the at least one processor 501, and the one or more computer programs are executed by the at least one processor 501 to enable the at least one processor 501 to perform the above-described load balancing method.

[0108] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor / processor core, implements the above-described load balancing method. The computer-readable storage medium may be volatile or non-volatile.

[0109] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described load balancing method.

[0110] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0111] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable program instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0112] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0113] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0114] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0115] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0116] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0117] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0118] 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 the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0119] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A load balancing method, characterized in that, include: Receive an access request from a user device, the access request being used to request access to a predetermined application, and the access request carrying a virtual network address; The routing information corresponding to the virtual network address is retrieved from the preset routing table information. The routing information includes first routing information and second routing information. The first routing information is used to indicate the routing relationship between the virtual network address and the network addresses of multiple service replicas. The second routing information is used to characterize the routing relationship between the virtual network address and the network addresses of multiple node devices; the first routing information and the second routing information are generated by associating the virtual network address with the network address of the node device and the network address of the service replica through a node proxy server and publishing it to the router; the multiple service replicas are service replicas of the application, and the multiple service replicas run on at least one node device in the container cluster management system; The access request is forwarded to the data receiving interface of each service replica via the network address of each service replica. The forwarding of the access request is used to distribute access to the application evenly across each service replica.

2. The method according to claim 1, characterized in that, Before receiving the access request from the user equipment, the method further includes: Obtain the pre-stored basic information of each service copy and the pre-stored routing information of the router corresponding to the at least one node device; The virtual network address is generated based on the basic information and the routing information of the router; The virtual device interface is used to generate association information between the virtual network address and each service replica, generate routing information corresponding to each association information, and add the routing information to the routing table information.

3. The method according to claim 2, characterized in that, The basic information includes: the network address of each service replica and the network address of the node device corresponding to each service replica, as well as the gateway address of the corresponding node device; the router's routing information includes: the routing information corresponding to the gateway address of each node device; The step of generating the virtual network address based on the basic information and the router's routing information includes: A virtual network address is obtained as the first address based on the Dynamic Host Configuration Protocol; Search for the routing information corresponding to the first address from the routing information corresponding to the gateway address of each node device; If no routing information corresponding to the first address is found, it is determined that the first address has not been used, and the first address is used as the generated virtual network address.

4. The method according to claim 2, characterized in that, Each service replica's network address corresponds to a pre-configured virtual network device; the generation of the association information between the virtual network address and each service replica through the virtual device interface includes: The virtual network address and the network address of the i-th service replica are associated with the corresponding virtual network device; wherein, the virtual network device is used to directly send the access request corresponding to the virtual network address to the data receiving interface of the i-th service replica, where i is greater than or equal to 1 and less than the total number of service replicas. Generate association information corresponding to the aforementioned association relationship, which serves as the association information between the virtual network address and the i-th service replica.

5. A container cluster management system, characterized in that, The container cluster management system includes a load management platform, which includes a receiving module for receiving access requests from user devices. The access requests are for requesting access to a predetermined application and carry a virtual network address. A lookup module is used to search for routing information corresponding to the virtual network address from a preset routing table. The routing information includes first routing information and second routing information. The first routing information is used to indicate the routing relationship between the virtual network address and the network address of each of the multiple service replicas. The second routing information is used to characterize the routing relationship between the virtual network address and the network addresses of multiple node devices. The first routing information and the second routing information are generated by associating the virtual network address with the network address of the node device and the network address of the service replica through a node proxy server and publishing it to a router. The multiple service replicas are service replicas of the application, and the multiple service replicas run on at least one node device in the container cluster management system. The forwarding module is used to forward the access request to the data receiving interface of each service replica through the network address of each service replica. The forwarding of the access request is used to distribute access to the application evenly to each service replica.

6. The system according to claim 5, characterized in that, The container cluster management system also includes a network management platform; the load management platform also includes an acquisition module and a sending module. The acquisition module is used to acquire, before receiving an access request from a user device, the basic information of each service copy stored in advance and the routing information of the router corresponding to the at least one node device stored in advance. The sending module is used to send the basic information and the routing information of the router to the network management platform; The network management platform is used to send address setting instructions to the node proxy server running on each node device. The address setting instructions include the basic information and the routing information of the router. The node proxy server running on each node device is used to generate the virtual network address based on the basic information and the routing information of the router, generate the association information between the virtual network address and each service replica through the virtual device interface, generate the first routing information corresponding to each association information, and add the first routing information to the routing table information.

7. The system according to claim 6, characterized in that, The load management platform is further configured to: obtain a virtual network address as a first address based on the Dynamic Host Configuration Protocol; search for routing information corresponding to the first address from the routing information corresponding to the gateway address of each node device; if no routing information corresponding to the first address is found, determine that the first address has not been used, and send the virtual network address to the network management platform as the generated virtual network address.

8. The system according to claim 6, characterized in that, Each service copy's network address corresponds to a pre-configured virtual network device; The node proxy server running on each node device is specifically used for: establishing an association between the virtual network address and the network address of the i-th service replica and the corresponding virtual network device; wherein, the virtual network device is used to directly send the access request corresponding to the virtual network address to the data receiving interface of the i-th service replica, where i is greater than or equal to 1 and less than the total number of service replicas; generating association information corresponding to the association relationship, as the association information between the virtual network address and the i-th service replica.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the load balancing method as described in any one of claims 1-4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the load balancing method as described in any one of claims 1-4.

Images