Intelligent dynamic load balancing method and system based on Clico-VPP

Abstract

The invention discloses an intelligent dynamic load balancing method and system based on Clico-VPP. The method comprises the following steps: acquiring a load state index of a back-end service pod; according to the load state index and a service capability coefficient corresponding to the back-end service pod, calculating a dynamic traffic allocation weight of the back-end service pod through a weighted calculation model; based on a dynamic threshold synchronization strategy, synchronizing the state of a first hash ring located in a control plane to a second hash ring located in a forwarding plane; and based on the second hash ring, determining a target pod for the input data stream through consistency lookup. A double-loop decoupling architecture is provided, hash rings of a control plane and a forwarding plane are separated, a synchronization strategy is determined through a dynamic threshold value, decision intelligence and forwarding stability are both considered, and jitter is avoided; meanwhile, a dynamic weight-driven consistent Hash algorithm is adopted, a real-time load index and Pod service capability are fused to calculate a dynamic weight, and the dynamic weight is mapped into the number of virtual nodes, so that intelligent scheduling based on capability and maximum maintenance of connection during capacity expansion and contraction are realized.

Description

A Smart Dynamic Load Balancing Method and System Based on Calico-VPP Technical Field

[0001] This application relates to the field of network resource scheduling technology, and in particular to an intelligent dynamic load balancing method and system based on Calico-VPP. Background Technology

[0002] With the widespread adoption of cloud-native technologies, Kubernetes has become the de facto standard for container orchestration. Networking is one of the core infrastructure components of a Kubernetes cluster, and load balancing is a key function for ensuring high availability and high performance. Calico is a widely used Kubernetes Container Network Interface (CNI) plugin, renowned for its high-performance three-layer network model and flexible network policies.

[0003] Traditional load balancing solutions in the Calico ecosystem suffer from performance bottlenecks when faced with numerous short connections or high throughput scenarios. To address this, Calico-VPP, an innovation within the Calico project, integrates a high-performance Vector Packet Processing (VPP) framework into the Calico network, completely moving the data plane from the kernel to user space. VPP significantly improves network forwarding performance and reduces latency through technologies such as vector batching and zero-copy. Calico-VPP's Services Manager component directly implements load balancing for Kubernetes services within VPP, bypassing kube-proxy and the kernel network stack, thus achieving higher forwarding efficiency.

[0004] However, current Calico-VPP (and many general-purpose load balancers) use a hash algorithm based on the data flow 5-tuple (source / destination IP, source / destination port, protocol) for backend selection by default. This method has the following inherent drawbacks: (1) Uneven load distribution: 5-tuple hashing is designed to ensure the continuity of the same flow session, rather than to distribute the load evenly. When a large number of data flows have similar 5-tuple structures, it may cause the hash result to be skewed, causing traffic to concentrate on a few backend Pods, while other Pods are idle.

[0005] (2) Ignoring heterogeneity: In a heterogeneous computing environment, different backend Pods may have different service capacities due to differences in resource specifications and processing capabilities. Static or simple round-robin / hash algorithms cannot perceive or adapt to this difference and cannot allocate traffic proportionally to service capacity.

[0006] (3) Backend changes cause connection interruption: When the number of backend Pods changes due to scaling up or down or failure, the number of nodes in the hash ring changes, causing most or even all existing connections to change their hash results, which are then redirected to new Pods, resulting in large-scale business session interruption and affecting user experience. Summary of the Invention

[0007] This application provides an intelligent dynamic load balancing method and system based on Calico-VPP to solve the problems of uneven load distribution and poor environmental adaptability in scheduling technology.

[0008] In a first aspect, this application provides an intelligent dynamic load balancing method based on Calico-VPP, comprising: obtaining load status indicators of backend service pods; the load status indicators include the current number of active connections, CPU utilization, and memory utilization; calculating the dynamic traffic allocation weight of the backend service pods through a weighted calculation model based on the load status indicators and the service capability coefficients corresponding to the backend service pods; synchronizing the state of a first hash ring located in the control plane to a second hash ring located in the forwarding plane based on a dynamic threshold synchronization strategy; wherein the first hash ring is constructed based on the dynamic traffic allocation weight of the backend service pods; and determining the target pod for the input data stream through a consistency lookup based on the second hash ring; the target pod is a service pod among the backend service pods whose hash value is greater than or equal to the hash value of the quintuple of the input data stream.

[0009] Based on this solution, by obtaining the load status indicators of backend Pods and combining them with service capability coefficients to calculate dynamic traffic allocation weights, the problem that static / simple hashing cannot adapt to backend heterogeneity is solved. Based on the dynamic threshold synchronization strategy, the first hash ring of the control plane is synchronized to the second hash ring of the forwarding plane, avoiding connection redirection caused by hash ring mutation when the number of backends changes, thus alleviating connection interruption issues. At the same time, the target Pod is determined based on the consistency lookup of the second hash ring, and the balance of traffic allocation is optimized by combining dynamic weights, improving the efficiency and stability of load balancing, and finally achieving high throughput and low latency intelligent load balancing in the Calico-VPP scenario.

[0010] In some feasible embodiments, based on the load status index and the service capability coefficient corresponding to the backend service pod, the dynamic traffic allocation weight of the backend service pod is calculated using a weighted calculation model, including: calculating the service capability weight of the backend service pod using the weighted calculation model. Where W_t is the service capability weight that the backend service Pod can provide, S is the preset Pod service capability coefficient, C is the current active connection count, U_cpu is the CPU utilization, U_mem is the memory utilization, α, β, and γ are adjustable influence coefficients that satisfy α+β+γ=1, and ε is a constant; normalized weights are calculated based on the service capability weights. Among them, W i This represents the normalized weight corresponding to the i-th backend service pod.

[0011] Based on this solution, dynamic traffic allocation weights can accurately quantify the actual serviceability of each backend Pod, taking into account both hardware resource utilization (avoiding overload) and preset service capability differences (adapting to heterogeneous environments). This further solves the problem of traditional algorithms ignoring backend heterogeneity and improves the matching degree between traffic allocation and actual service capability.

[0012] In some feasible embodiments, based on a dynamic threshold synchronization strategy, the state of the first hash ring located in the control plane is synchronized to the state of the second hash ring located in the forwarding plane, including: constructing the first hash ring based on the dynamic traffic allocation weight; when the backend service pod corresponding to the virtual node on the first hash ring is inconsistent with the backend service pod corresponding to the virtual node on the second hash ring, the state of the first hash ring is synchronized to the second hash ring.

[0013] Based on this solution, the forwarding plane hash ring is updated immediately when a pod is added or deleted, ensuring timely synchronization.

[0014] In some feasible embodiments, when the backend service pod corresponding to the virtual node on the first hash ring is inconsistent with the backend service pod corresponding to the virtual node on the second hash ring, the state of the first hash ring is synchronized to the second hash ring, including: when a new backend service pod is added to the first hash ring, a virtual node corresponding to the newly added backend service pod is added to the first hash ring with a preset initial weight; when a backend service pod is deleted from the first hash ring, a first mark is added to the deleted backend service pod, and the virtual node corresponding to the deleted backend service pod is removed from the first hash ring; a connection timeout window corresponding to the deleted backend service pod is set so that the session of the deleted backend service pod is completed within a preset time through the connection timeout window.

[0015] Based on this solution, we avoid the sudden increase in traffic caused by the unstable weight of newly added Pods. By adding a first marker to retain its virtual node until the connection timeout window ends, we ensure that the existing sessions on the Pod can be completed naturally within the preset time, rather than being immediately redirected. This fundamentally solves the problem of large-scale connection interruption caused by backend deletion in traditional solutions.

[0016] In some feasible embodiments, the method further includes: calculating the cumulative load change of all backend service pods; calculating a dynamic threshold based on the dynamic traffic allocation weight; and synchronizing the state of the first hash ring to the second hash ring if the cumulative load change is greater than the dynamic threshold.

[0017] Based on this solution, the hash ring can adapt to changes in backend load in a timely manner, avoiding the exacerbation of uneven load due to failure to synchronize in time when the cumulative load changes are too large; at the same time, it avoids unnecessary synchronization overhead caused by frequent small fluctuations in load.

[0018] In some feasible embodiments, before the state of the second hash ring is completely consistent with the state of the first hash ring, the target pod is determined by a consistency lookup on the input data stream based on the second hash ring before synchronization.

[0019] Based on this solution, the stability of forwarding behavior during synchronization is ensured. Even if the control plane has updated the hash ring, the forwarding plane still maintains the original logic to process the input data stream, avoiding misjudgment of target Pods or connection redirection caused by partial updates of the hash ring during synchronization. This further reduces the impact of the synchronization process on business sessions and enhances the robustness of the system.

[0020] In some feasible embodiments, calculating the cumulative load change of all backend service pods includes: obtaining the weight change of the backend service pods before and after the load change; calculating the normalized cumulative deviation based on the sum of the weight changes of all backend service pods, as the cumulative load change of all backend service pods; and calculating a dynamic threshold based on the dynamic traffic allocation weights, including: calculating the dynamic threshold based on the current load weight distribution characteristics. ;in, and The upper and lower limits of the dynamic threshold θ are configurable; H is the information entropy of the current weight distribution; The maximum possible entropy; the method for calculating the information entropy is as follows: Where n is the number of healthy and ready pods for backend services.

[0021] Based on this scheme, by introducing information entropy, the synchronization trigger sensitivity can be adaptively adjusted according to the uniformity of the actual load distribution. When the load distribution tends to be uneven, the threshold is lowered, making it easier to trigger synchronization to adjust the hash ring; when the distribution is relatively uniform, the threshold is raised to reduce unnecessary synchronization, further optimizing the rationality of the synchronization strategy and improving the efficiency and stability of load balancing.

[0022] In some feasible embodiments, the method for constructing the first hash ring includes: mapping at least one virtual node on the first hash ring for each backend service pod based on the dynamic traffic allocation weight of the backend service pod; the number of virtual nodes on the first hash ring corresponding to backend service pods with different weights is different; the number of virtual nodes corresponding to each backend service pod is: ;in, As a baseline number of virtual nodes, With the number of virtual nodes Proportional This is for the lower bound operation.

[0023] Based on this scheme, high-weight Pods occupy a larger "range" on the hash ring, thus having a higher probability of being selected during consistency lookup, directly achieving the goal of allocating traffic according to service capacity.

[0024] In some feasible embodiments, based on the second hash ring, the target pod is determined by a consistent lookup of the input data stream, including: extracting the 5-tuple information of the input data stream and calculating the first hash value corresponding to the 5-tuple information; on the second hash ring, searching clockwise for the first virtual node whose hash value is greater than or equal to the first hash value; and determining the backend service pod corresponding to the first virtual node as the target pod.

[0025] Based on this scheme, the continuity of the same stream session is guaranteed by maintaining compatibility with traditional 5-tuple hashes.

[0026] Secondly, embodiments of this application provide an intelligent dynamic load balancing system based on Calico-VPP, comprising: a load monitor for acquiring load status indicators of backend service pods; the load status indicators include the current number of active connections, CPU utilization, and memory utilization; a weight decision maker for calculating the dynamic traffic allocation weight of the backend service pods based on the load status indicators and the service capability coefficients corresponding to the backend service pods using a weighted calculation model; a first hash scheduler for constructing a first hash ring located in the control plane based on the dynamic traffic allocation weights; a second hash scheduler for maintaining a second hash ring located in the forwarding plane; a synchronization manager for synchronizing the state of the first hash ring to the second hash ring based on a dynamic threshold synchronization strategy; and a VPP execution engine for determining the target pod for the input data stream through a consistency lookup based on the second hash ring, and performing the translation and forwarding of the destination network address corresponding to the target pod; the target pod is a service pod among the backend service pods whose hash value is greater than or equal to the hash value of the five-tuple of the input data stream.

[0027] In some feasible embodiments, the load monitor collects load status metrics by at least one of the following methods: querying the Kubernetes Metrics Server API; reading CPU and memory usage statistics from the node cgroup control group file system; and parsing the connection tracking table of the vector packet processing framework or the connection tracking table in the host network namespace to obtain the number of active connections.

[0028] Based on this solution, the comprehensiveness and accuracy of load status indicators are ensured through multiple complementary collection methods. Among them, the Metrics Server API can provide standardized Kubernetes metrics, the cgroup file system can obtain details of underlying resource usage, and the connection tracking table can directly reflect the network connection status. Multi-source collection avoids the limitations of a single method, provides reliable input for the weight decision-maker, and ensures the calculation accuracy of dynamic traffic allocation weights.

[0029] In some feasible embodiments, the synchronization manager includes: an event listening module for listening to events from the Kubernetes API server regarding the addition or deletion of pods, and receiving weight change notifications from the weight decision-maker; a change accumulation calculation module for calculating the cumulative load change when the load state changes; an information entropy calculation module for weight distribution for measuring the uniformity of load distribution; a dynamic threshold calculation module for adaptively adjusting the synchronization trigger sensitivity according to the actual operating state; and a policy judgment module for determining whether to synchronize the state of the first hash ring to the second hash ring based on the event type and the cumulative load change, and generating a corresponding synchronization instruction.

[0030] Based on this solution, the modular design makes the functions of the synchronization manager clearer, improves the reliability and flexibility of the synchronization logic, and ensures that the hash ring can be synchronized in a timely and reasonable manner.

[0031] In some feasible embodiments, the VPP execution engine includes: a rule configuration plugin for converting the mapping relationship of the second hash ring into load balancing and network address translation rules recognizable by the vector packet processing framework; and a vectorized forwarding module for receiving network data packets in the input data stream and performing batch-optimized rule matching, address translation, and routing forwarding operations.

[0032] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method provided in the first aspect.

[0033] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the first aspect.

[0034] Compared with the prior art, the beneficial effects of this application are as follows: The solution provided by the embodiments of this application proposes a dual-ring decoupling architecture, separates the hash rings of the control plane and the forwarding plane, determines the synchronization strategy through dynamic thresholds, takes into account both decision intelligence and forwarding stability, and avoids jitter; at the same time, it adopts a dynamic weight-driven consistent hashing algorithm, integrates real-time load indicators and Pod service capabilities to calculate dynamic weights, and maps them to the number of virtual nodes, thereby realizing capability-based intelligent scheduling and maximizing connection maintenance during scaling up and down.

[0035] Furthermore, in terms of cost, the solution provided in this application requires no additional hardware investment. It only requires adding lightweight load balancing logic to the existing Calico-VPP-agent, leveraging the open-source ecosystem to avoid software licensing fees, and reducing computational resource waste through optimized resource allocation. Regarding feasibility, this application is fully compatible with the Calico-VPP architecture, requiring no modification to the core framework. It seamlessly integrates with Kubernetes through standard APIs, making implementation simple and deployment convenient. This solution only requires extending the load balancing module and can be quickly applied to various Kubernetes production environments without large-scale modifications to existing infrastructure. It has low implementation risk, high return on investment, and is an economically feasible solution for achieving efficient load balancing. Attached Figure Description

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

[0037] Figure 1 is a flowchart of an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application.

[0038] Figure 2 is a flowchart of hash ring synchronization in a scaling-up / scaling scenario of an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application; Figure 3 is a flowchart of hash ring synchronization in a load fluctuation scenario of an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application; Figure 4 is a structural diagram of an intelligent dynamic load balancing system based on Calico-VPP provided in an embodiment of this application. Detailed Implementation

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

[0040] The technical terms involved in the embodiments of this application are first introduced as follows: Calico: an open-source network and network security solution, mainly used for Kubernetes and other container orchestration platforms. Traditionally, Calico uses Linux kernel network functions (such as iptables, BGP) to process network packets.

[0041] VPP: Vector Packet Processing, is a high-performance, production-grade userspace packet processing framework maintained by FD.io.

[0042] Calico-VPP is a sub-project or pattern of the Calico project, whose goal is to "graft" the powerful capabilities of VPP onto Calico. It does not rewrite Calico, but rather replaces the default kernel data plane with VPP within its architecture.

[0043] Control plane: Makes decisions by listening to events from the Kubernetes API Server (such as creating Pods and Services), then generates configurations and distributes them to the data plane.

[0044] Data plane (forwarding plane): Processes each incoming and outgoing data packet in real time, including executing rules issued by the control plane and performing operations such as packet encapsulation, decapsulation, routing, and filtering.

[0045] Traditional load balancing solutions in the Calico ecosystem, such as MetalLB, typically rely on external hardware routers or the forwarding capabilities of the operating system kernel. For example, MetalLB's BGP mode requires upper-layer hardware to support the BGP protocol, while Layer 2 mode suffers from single-point bottlenecks and slow fault recovery. More importantly, its load balancing ultimately depends on kube-proxy on the nodes, distributing traffic in kernel space by manipulating iptables or IPVS, which can become a performance bottleneck when handling a large number of short connections or high-throughput scenarios.

[0046] Calico-VPP is an innovation within the Calico project that integrates a high-performance Vector Packet Processing (VPP) framework into the Calico network, completely moving the data plane from the kernel to user space. VPP significantly improves network forwarding performance and reduces latency through technologies such as vector batching and zero-copy. Calico-VPP's Services Manager component directly implements load balancing for Kubernetes services within VPP, bypassing kube-proxy and the kernel network stack, thus achieving higher forwarding efficiency.

[0047] However, Calico-VPP currently uses a hash algorithm based on the data stream 5-tuple (source / destination IP, source / destination port, protocol) for backend selection by default. In practical applications, this often leads to problems such as uneven load distribution, ignoring heterogeneity, and easy connection interruption due to backend changes.

[0048] To address the aforementioned technical issues, this application provides an intelligent dynamic load balancing method based on Calico-VPP, which can deeply integrate dynamic load weights and consistent hashing algorithms at the VPP data plane level to achieve intelligent and stable load balancing.

[0049] Referring to Figure 1, it is a flowchart of an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application.

[0050] As shown in Figure 1, the intelligent dynamic load balancing method based on Calico-VPP provided in this application may include: S100: obtaining the load status indicators of the backend service pod; the load status indicators include the current number of active connections, CPU utilization and memory utilization.

[0051] Specifically, load monitors deployed on each node can be used to collect load status metrics of the backend service pods corresponding to that node in real time. The load monitor can run in DaemonSet form and collect load status metrics through various means (such as cAdvisor, VPP connection trace table).

[0052] S200: Based on the load status indicators and the service capacity coefficients corresponding to the backend service pods, the dynamic traffic allocation weight of the backend service pods is calculated using a weighted calculation model. The weight of a pod is inversely proportional to its current service capacity (i.e., the lighter the load, the higher the weight).

[0053] Specifically, during the dynamic traffic allocation weight calculation phase, the weighted calculation model can be used to calculate the service capability weight of the backend service pod based on the received load status indicators: Where W_t is the service capability weight of the backend service Pod, S is the preset Pod service capability coefficient, C is the current active connection count, U_cpu is the CPU utilization, U_mem is the memory utilization, α, β, and γ are adjustable influence coefficients satisfying α+β+γ=1, and ε is a constant; assuming there are n healthy and ready backend Pods, W_t of all backend Pods needs to be normalized: Among them, W i This represents the normalized weight corresponding to the i-th backend service pod; the final normalized weight directly determines the relative proportion of traffic that the pod should handle.

[0054] In some embodiments, the period used for weight calculation can be set to 60 seconds by default and can be dynamically adjusted.

[0055] S300: Based on a dynamic threshold synchronization strategy, the state of the first hash ring located in the control plane is synchronized to the second hash ring located in the forwarding plane; wherein, the first hash ring is constructed based on the dynamic traffic allocation weight of the backend service pod.

[0056] In this embodiment, a dual-consistency hash ring mapping mechanism is adopted. By introducing two logically separate but collaborative hash ring structures: a first hash ring located in the control plane and a second hash ring located in the forwarding plane, the stability requirements of the data plane and the dynamic response requirements of the control plane can be effectively decoupled, significantly reducing resource contention, rule oscillation and forwarding delay of a single hash ring in high-concurrency and frequently changing scenarios.

[0057] Specifically, the first hash ring (control plane hash ring) can run within the control logic of calico-vpp-agent, serving as a sandbox environment for dynamic topology calculation and load awareness. It reflects the latest status of backend service Pods in real time, including changes in quantity, health status, and service capability weights, but its changes do not directly affect data forwarding; they are only used to decide when to update the second hash ring.

[0058] The second hash ring (forwarding plane hash ring) resides in the VPP data plane and is used as the data structure for service flow mapping. When an external request arrives at the node's network interface card and is taken over by the VPP, the system calculates a hash value based on the five-tuple of the data flow (source IP, destination IP, source port, destination port, protocol type) and searches for the nearest clockwise virtual node in the second hash ring to determine the target backend Pod. The second hash ring must maintain high stability as much as possible to ensure that all packets in the same flow always hit the same backend, avoiding out-of-order delivery or connection interruption.

[0059] In some embodiments, when performing step S300, a first hash ring can be constructed based on dynamic traffic allocation weights (if a first hash ring already exists, it needs to be rebuilt).

[0060] Specifically, when building / rebuilding the first hash ring, to improve the uniformity of the consistent hash ring distribution, weights can be allocated based on the dynamic traffic of the backend service pods. At least one virtual node is mapped to each backend service pod on the first hash ring. Backend service pods with different weights correspond to different numbers of virtual nodes on the first hash ring; pods with higher weights have more virtual nodes and a greater probability of being selected. The number of virtual nodes corresponding to a backend service pod is as follows: ;in, The baseline number of virtual nodes (e.g., it can be 1000). ∈(0,1] represents the weights after weighted calculation and normalization, and is related to the number of virtual nodes. Proportional This is for the lower bound operation.

[0061] It should be noted that, in the initial state, the first hash ring and the second hash ring have the same virtual node distribution, that is, the number of virtual nodes and the corresponding backend service pods are the same.

[0062] In step S300, determining whether a synchronization operation needs to be performed can be based on a pre-built dual-consistency hash ring synchronization strategy. By introducing a controlled and strategic state synchronization layer between the control plane hash ring and the data plane hash ring, a differentiated synchronization strategy mechanism is adopted to implement different synchronization strategies for "load changes" and "topology changes (Pod additions and deletions)," thereby achieving an effective balance between "real-time intelligent scheduling" and "high-performance stable forwarding."

[0063] Referring to Figure 2, it is a flowchart of the hash ring synchronization process in a scaling-up / scaling scenario of an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application.

[0064] In some embodiments, referring to Figure 2, when pod scaling scenarios (pod addition and deletion) are involved, when Kubernetes detects a change in the Service backend EndpointSlice (such as HPA-triggered scaling or node failure causing pod deletion), the following process can be executed: S301: Immediately reconstruct the topology in the first hash ring: Add Pod: Add virtual nodes according to its initial weight (which can be set to a conservative value, such as 0.5); Delete Pod: Mark it as drained, remove the virtual node from the first hash ring, but retain its existing connection records for VPP to continue forwarding; Whether adding or deleting a pod, it will cause the backend service pod corresponding to the virtual node on the first hash ring to be inconsistent with the backend service pod corresponding to the virtual node on the second hash ring. At this time, the following steps can be executed.

[0065] S302: Unconditionally trigger synchronization: Immediately synchronize the updated first hash ring to the second hash ring to ensure that new connections can be correctly routed to valid backend Pods.

[0066] S303: For Pods in the drain state, a connection timeout window (e.g., 30 seconds) can be set, allowing them to complete existing sessions during this period, after which their data flow forwarding rules are thoroughly cleaned up. That is, before the state of the second hash ring is completely consistent with the state of the first hash ring, the target pod is determined through a consistency lookup of the input data flow based on the second hash ring before synchronization.

[0067] In this embodiment, the unconditionally triggered synchronization strategy ensures service continuity in scaling up and down scenarios, avoids traffic misdirection to terminated Pods, and enables gradual traffic import into new Pods.

[0068] Referring to Figure 3, it is a flowchart of hash ring synchronization under load fluctuation scenario in an intelligent dynamic load balancing method based on Calico-VPP provided in an embodiment of this application.

[0069] In some embodiments, referring to Figure 3, when dealing with pod load fluctuation scenarios (load changes), if the running load of the backend pod changes (such as a sudden increase in CPU or network congestion), the following process can be executed: S305: Recalculate the affected pods And adjust the number of virtual nodes in the first hash ring; S306: Accumulate the weight changes of all Pods and calculate the normalized cumulative bias: Step B3: Calculate the dynamic threshold θ based on the current load weight distribution characteristics, enabling the system to adaptively adjust the sensitivity of synchronization triggering according to the actual operating state. The calculation method is as follows: ;in, and Configurable upper and lower limits for threshold θ (e.g.) = 0.05 and = 0.3); H is the information entropy of the current weight distribution, used to measure the uniformity of load distribution; This is the maximum possible entropy, i.e., the entropy when all Pods have equal weights. Information entropy. The calculation method is as follows: ;in, The weights are calculated and normalized, with ε being a minimum value to prevent the denominator from being zero; n is the number of healthy and ready Pods for backend services.

[0070] S307: If Δ > threshold θ, then trigger an atomic synchronization operation: safely replace the second hash ring with the overall state of the first hash ring; otherwise, keep the second hash ring unchanged.

[0071] In some embodiments, the synchronization process can employ a double buffering + version number locking mechanism: the VPP forwarding thread always reads the second hash ring of the current version, and after the new version is built, zero-copy updates are achieved through pointer switching to avoid read-write conflicts.

[0072] In this embodiment, the dynamic threshold synchronization mechanism of the dual-consistency hash ring can both trigger timely updates to maintain balance when the system load changes while it is in a balanced state, and effectively avoid frequent hash ring refreshes caused by small fluctuations in hot Pods when the system is highly unbalanced, thus improving the system robustness.

[0073] S400: Based on the second hash ring, the target pod is determined by consistent lookup of the input data stream; the target pod is the service pod in the backend service pod whose hash value is greater than or equal to the hash value of the five-tuple of the input data stream.

[0074] In some embodiments, when a new data stream arrives, the data plane, which integrates a vector packet processing framework, can perform a consistent hash lookup based on the mapping relationship of the second hash ring to determine the target Pod and perform destination network address translation and forwarding. Specifically, the VPP data plane can perform network address translation on the data packets based on the hash scheduling result, replace the service IP with the selected backend Pod IP, and forward it through VPP's high-performance forwarding path.

[0075] Specifically, in some embodiments, step S400 can be divided into the following steps: S410: extract the quintuple information of the input data stream and calculate the first hash value corresponding to the quintuple information; S420: on the second hash ring, find the first virtual node whose hash value is greater than or equal to the first hash value in a clockwise direction; S430: determine the backend service pod corresponding to the first virtual node as the target pod.

[0076] In some embodiments, the test results of the method provided in this application and the traditional Calico-VPP scheme are as follows:

[0077] As can be seen, the method provided in this application, without significantly sacrificing the original high performance of Calico-VPP, effectively solves the three major pain points of load balancing in the production environment through the innovative dynamic weight and double consistency hash ring fusion mechanism, and provides more intelligent and robust network traffic management capabilities for cloud-native applications based on Kubernetes and Calico-VPP.

[0078] As can be seen from the above technical solutions, the method provided in this application proposes a dual-ring decoupling architecture, separates the hash rings of the control plane and the forwarding plane, determines the synchronization strategy through dynamic thresholds, takes into account both decision intelligence and forwarding stability, and avoids jitter; at the same time, it adopts a dynamic weight-driven consistent hashing algorithm, integrates real-time load indicators and Pod service capabilities to calculate dynamic weights, and maps them to the number of virtual nodes, thereby realizing capability-based intelligent scheduling and maximizing connection maintenance during scaling up and down.

[0079] Furthermore, in terms of cost, the solution provided in this application requires no additional hardware investment. It only requires adding lightweight load balancing logic to the existing Calico-VPP-agent, leveraging the open-source ecosystem to avoid software licensing fees, and reducing computational resource waste through optimized resource allocation. Regarding feasibility, this application is fully compatible with the Calico-VPP architecture, requiring no modification to the core framework. It seamlessly integrates with Kubernetes through standard APIs, making implementation simple and deployment convenient. This solution only requires extending the load balancing module and can be quickly applied to various Kubernetes production environments without large-scale modifications to existing infrastructure. It has low implementation risk, high return on investment, and is an economically feasible solution for achieving efficient load balancing.

[0080] Referring to Figure 4, it is a structural diagram of an intelligent dynamic load balancing system based on Calico-VPP provided in an embodiment of this application.

[0081] This application also provides an intelligent dynamic load balancing system based on Calico-VPP, which can be manifested as a Calico-VPP intelligent load balancing module deployed on each node of the Kubernetes cluster, as shown in Figure 4. It can include a load monitor, a weight decision-maker, a hash scheduler, and a synchronization manager, and is tightly integrated with the original Calico-VPP VPP data plane execution engine (hereinafter referred to as the VPP execution engine). The load monitor runs in the form of a DaemonSet and is deployed on each node. It collects the load status indicators of the backend service pods in real time through various means (such as cAdvisor and VPP connection tracking table). The load status indicators include the current number of active connections, CPU utilization, and memory utilization.

[0082] The weight decision maker is used to calculate the dynamic traffic allocation weight of the backend service pods based on the load status indicators and the service capacity coefficients corresponding to the backend service pods (which can be obtained from pod resource requests or performance benchmarks) through a weighted calculation model. The weight is directly proportional to the current service capacity of the pod and inversely proportional to the current load.

[0083] The first hash scheduler is used to construct and maintain the first hash ring in the control plane based on dynamic traffic allocation weights. According to the weight list output by the weight decision-maker, it dynamically generates a corresponding number of virtual nodes for each Pod and constructs a consistent hash ring. The first hash scheduler can continuously and agilely respond to all load changes and Pod set changes.

[0084] The second hash scheduler maintains a second hash ring located in the forwarding plane. Upon receiving an update instruction from the synchronization manager, the updated second hash ring can drive the VPP data plane. The second hash ring is updated less frequently than the first hash ring, ensuring a highly stable forwarding path.

[0085] The synchronization manager is used to synchronize the state of the first hash ring to the second hash ring based on a dynamic threshold synchronization strategy. Specifically, two synchronization strategies can be used: For Pod scaling (topology change): it is triggered immediately, and the state of the first hash ring is atomically synchronized to the second hash ring.

[0086] For Pod load fluctuations (state changes): calculate the cumulative change Δ, calculate the dynamic threshold θ, and only trigger synchronization when Δ exceeds the threshold θ to avoid frequent updates to the forwarding plane due to minor fluctuations.

[0087] The VPP execution engine, based on the second hash ring, determines the target pod from the input data stream through consistent lookup, and performs the translation and forwarding of the destination network address corresponding to the target pod. The target pod is a service pod in the backend service pod whose hash value is greater than or equal to the 5-tuple hash value of the input data stream. The VPP execution engine can generate corresponding configuration entries based on the mapping relationship of the second hash ring, then perform 5-tuple hashing on the new data stream, locate the target pod through consistent lookup, and perform efficient NAT translation and vectorized forwarding.

[0088] In some embodiments, the load monitor can collect load status metrics in at least one of the following ways: querying the Kubernetes Metrics Server API; reading CPU and memory usage statistics from the node cgroup control group file system; or parsing the connection tracking table in the vector packet processing framework or the connection tracking table in the host network namespace to obtain the number of active connections.

[0089] In some embodiments, the synchronization manager may include: an event listening module for listening to events from the Kubernetes API server regarding the addition or deletion of pods, and receiving weight change notifications from the weight decision maker; a change accumulation calculation module for calculating the cumulative load change when the load state changes; an information entropy calculation module for weight distribution for measuring the uniformity of load distribution; a dynamic threshold calculation module for adaptively adjusting the synchronization trigger sensitivity according to the actual running state; and a policy judgment module for determining whether to synchronize the state of the first hash ring to the second hash ring based on the event type and the cumulative load change, and generating corresponding synchronization instructions.

[0090] In some embodiments, the VPP execution engine may include: a rule configuration plugin for converting the mapping relationship of the second hash ring into load balancing and network address translation rules recognizable by the vector packet processing framework; and a vectorized forwarding module for receiving network packets in the input data stream and performing batch-optimized rule matching, address translation, and routing forwarding operations.

[0091] The solution provided by the system in this application embodiment is similar to the solution described in any of the above method embodiments. Therefore, the specific limitations in the system embodiment can be found in the limitations of the intelligent dynamic load balancing method based on Calico-VPP above, and will not be repeated here.

[0092] In one exemplary embodiment, the present invention also provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the intelligent dynamic load balancing method based on Calico-VPP of this application. A multi-core processor is preferred to improve the parallel processing capability of the system. The memory provides sufficient temporary storage space to support program execution and data processing. The memory capacity should be large enough to accommodate large amounts of data and computational tasks.

[0093] In one exemplary embodiment, the present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the intelligent dynamic load balancing method based on Calico-VPP of this application. The computer-readable storage medium may include: a read-only memory, a random access memory, a solid-state drive, or an optical disk, etc.

[0094] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A smart dynamic load balancing method based on Calico-VPP, applied to Kubernetes container cluster networks, characterized in that, include: Obtain the load status indicators of the backend service pod; the load status indicators include the current number of active connections, CPU utilization, and memory utilization; calculate the dynamic traffic allocation weight of the backend service pod through a weighted calculation model based on the load status indicators and the service capability coefficient corresponding to the backend service pod. Based on a dynamic threshold synchronization strategy, the state of the first hash ring located in the control plane is synchronized to the state of the second hash ring located in the forwarding plane; wherein, the first hash ring is constructed based on the dynamic traffic allocation weight of the backend service pod; Based on the second hash ring, the target pod is determined by a consistent lookup of the input data stream; the target pod is the service pod in the backend service pod whose hash value is greater than or equal to the hash value of the five-tuple of the input data stream.

2. The intelligent dynamic load balancing method based on Calico-VPP according to claim 1, characterized in that, Based on the load status indicators and the service capability coefficients corresponding to the backend service pods, a weighted calculation model is used to calculate the dynamic traffic allocation weights of the backend service pods, including: using the weighted calculation model to calculate the service capability weights of the backend service pods. Where W_t is the service capability weight that the backend service Pod can provide, S is the preset Pod service capability coefficient, C is the current active connection count, U_cpu is the CPU utilization, U_mem is the memory utilization, α, β, and γ are adjustable influence coefficients that satisfy α+β+γ=1, and ε is a constant; normalized weights are calculated based on the service capability weights. Among them, W i This represents the normalized weight corresponding to the i-th backend service pod.

3. The intelligent dynamic load balancing method based on Calico-VPP according to claim 2, characterized in that, Based on a dynamic threshold synchronization strategy, the state of the first hash ring located in the control plane is synchronized to the state of the second hash ring located in the forwarding plane, including: constructing the first hash ring based on the dynamic traffic allocation weight; when the backend service pod corresponding to the virtual node on the first hash ring is inconsistent with the backend service pod corresponding to the virtual node on the second hash ring, the state of the first hash ring is synchronized to the second hash ring.

4. The intelligent dynamic load balancing method based on Calico-VPP according to claim 3, characterized in that, When the backend service pod corresponding to the virtual node on the first hash ring is inconsistent with the backend service pod corresponding to the virtual node on the second hash ring, the state of the first hash ring is synchronized to the second hash ring, including: when a new backend service pod is added to the first hash ring, a virtual node corresponding to the new backend service pod is added to the first hash ring with a preset initial weight; when a backend service pod is deleted from the first hash ring, a first mark is added to the deleted backend service pod, and the virtual node corresponding to the deleted backend service pod is removed from the first hash ring; a connection timeout window corresponding to the deleted backend service pod is set so that the session of the deleted backend service pod is completed within a preset time through the connection timeout window.

5. The intelligent dynamic load balancing method based on Calico-VPP according to claim 3, characterized in that, The method further includes: calculating the cumulative load change of all backend service pods; calculating a dynamic threshold based on the dynamic traffic allocation weight; and synchronizing the state of the first hash ring to the second hash ring if the cumulative load change is greater than the dynamic threshold.

6. The intelligent dynamic load balancing method based on Calico-VPP according to claim 5, characterized in that, Before the state of the second hash ring is completely consistent with the state of the first hash ring, the target pod is determined by a consistency lookup on the input data stream based on the second hash ring before synchronization.

7. The intelligent dynamic load balancing method based on Calico-VPP according to claim 5, characterized in that, Calculate the cumulative load change of all backend service pods, including: obtaining the weight change of the backend service pods before and after the load change; calculating the normalized cumulative deviation based on the sum of the weight changes of all backend service pods, as the cumulative load change of all backend service pods; calculating a dynamic threshold based on the dynamic traffic allocation weights, including: calculating the dynamic threshold based on the current load weight distribution characteristics. ;in, and The upper and lower limits of the dynamic threshold θ are configurable; H is the information entropy of the current weight distribution; The maximum possible entropy; the method for calculating the information entropy is as follows: Where n is the number of healthy and ready pods for backend services.

8. The intelligent dynamic load balancing method based on Calico-VPP according to claim 2, characterized in that, The method for constructing the first hash ring includes: mapping at least one virtual node to each backend service pod on the first hash ring based on the dynamic traffic allocation weight of the backend service pod; the number of virtual nodes corresponding to backend service pods with different weights on the first hash ring is different; the number of virtual nodes corresponding to each backend service pod is: ;in, As a baseline number of virtual nodes, With the number of virtual nodes Proportional This is for the lower bound operation.

9. The intelligent dynamic load balancing method based on Calico-VPP according to claim 1, characterized in that, Based on the second hash ring, the target pod is determined by consistent lookup of the input data stream, including: extracting the 5-tuple information of the input data stream and calculating the first hash value corresponding to the 5-tuple information; on the second hash ring, searching clockwise for the first virtual node whose hash value is greater than or equal to the first hash value; and determining the backend service pod corresponding to the first virtual node as the target pod.

10. A smart dynamic load balancing system based on Calico-VPP, characterized in that, include: A load monitor is used to obtain load status metrics for backend service pods; these metrics include the number of currently active connections, CPU utilization, and memory utilization. The weight decision-maker is used to calculate the dynamic traffic allocation weight of the backend service pod based on the load status index and the service capability coefficient corresponding to the backend service pod through a weighted calculation model. A first hash scheduler is used to construct a first hash ring located in the control plane based on the dynamic traffic allocation weights. The second hash scheduler is used to maintain the second hash ring located in the forwarding plane; A synchronization manager is used to synchronize the state of the first hash ring to the second hash ring based on a dynamic threshold synchronization strategy. The VPP execution engine is used to determine the target pod by consistent lookup of the input data stream based on the second hash ring, and to perform the translation and forwarding of the destination network address corresponding to the target pod; the target pod is a service pod in the backend service pod whose hash value is greater than or equal to the hash value of the five-tuple of the input data stream.

11. The intelligent dynamic load balancing system based on Calico-VPP according to claim 10, characterized in that, The load monitor collects load status metrics in at least one of the following ways: querying the Kubernetes Metrics Server API; reading CPU and memory usage statistics from the node cgroup control group file system; and parsing the connection tracking table of the vector packet processing framework or the connection tracking table in the host network namespace to obtain the number of active connections.

12. The intelligent dynamic load balancing system based on Calico-VPP according to claim 10, characterized in that, The synchronization manager includes: an event listening module for listening to events from the Kubernetes API server regarding the addition or deletion of pods, and receiving weight change notifications from the weight decision-maker; a cumulative change calculation module for calculating the cumulative load change when the load state changes; an information entropy calculation module for weight distribution for measuring the uniformity of load distribution; a dynamic threshold calculation module for adaptively adjusting the synchronization trigger sensitivity according to the actual operating state; and a policy judgment module for determining whether to synchronize the state of the first hash ring to the second hash ring based on the event type and the cumulative load change, and generating corresponding synchronization instructions.

13. The intelligent dynamic load balancing system based on Calico-VPP according to claim 10, characterized in that, The VPP execution engine includes: a rule configuration plugin for converting the mapping relationship of the second hash ring into load balancing and network address translation rules recognizable by the vector packet processing framework; and a vectorized forwarding module for receiving network data packets in the input data stream and performing batch-optimized rule matching, address translation, and routing forwarding operations.

14. A computer device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 9.

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

Images