Load balancing methods and related products suitable for privately deployed clusters

Abstract

This specification discloses a load balancing method and related products suitable for privately deployed clusters. The method includes: periodically determining a first score for each node based on load data of nodes within the cluster, and determining a second score for each container group based on load data of container groups on the nodes; evicting container groups on the nodes based on the first score of the nodes and the second score of the container groups on the nodes; updating the first score of the nodes within the cluster based on the second score of the evicted container groups to obtain a third score for the nodes within the cluster; and redeploying the evicted container groups based on the third score of the nodes within the cluster. Thus, by combining rescheduling with load-aware scheduling, load balancing for privately deployed clusters is achieved while reducing risk, improving business stability, and saving resources, better adapting to the characteristics of privately deployed clusters.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to a load balancing method and related products suitable for privately deployed clusters. Background Technology

[0002] The cloud computing ecosystem derived from the containerized orchestration system Kubernetes supports an increasing number of software deployments, including not only public cloud systems but also small private cloud clusters deployed directly to customer data centers. While the Kubernetes orchestration and scheduling process is static, the changes in microservice load are dynamic, inevitably leading to load imbalances between nodes.

[0003] For privately deployed clusters such as small private cloud clusters, due to their relatively small size and fixed number of machines, the load pressure is greater and more concentrated when traffic is concentrated on a certain machine. In addition, since privately deployed clusters generally directly face a certain business module, if the orchestration and scheduling strategy is not designed properly, it is very easy to cause the business module to malfunction. Therefore, when orchestrating and scheduling, it is necessary not only to balance the load of each node in the cluster, but also to avoid the risks brought by scheduling, improve business stability, and minimize resource consumption as much as possible.

[0004] How to achieve load balancing for privately deployed clusters while reducing risks, improving business stability, and saving resources, in order to better adapt to the characteristics of privately deployed clusters, has become an urgent problem to be solved. Summary of the Invention

[0005] The purpose of the embodiments in this specification is to provide a load balancing method and related products suitable for privately deployed clusters. By combining rescheduling with load-aware scheduling, load balancing of privately deployed clusters can be achieved while reducing risks, improving business stability, and saving resources, so as to better adapt to the characteristics of private cloud clusters.

[0006] To achieve the above objectives, the embodiments in this specification adopt the following technical solutions:

[0007] Firstly, a load balancing method suitable for privately deployed clusters is provided, including:

[0008] A first score for a node is determined periodically based on the load data of the nodes within the cluster, and a second score for a container group is determined based on the load data of the container group on the node.

[0009] Based on the first score of the node and the second score of the container group on the node, the container group on the node is evicted.

[0010] The first score of the nodes in the cluster is updated based on the second score of the expelled container group to obtain the third score of the nodes in the cluster.

[0011] The evicted container group is redeployed based on the third score of the nodes within the cluster.

[0012] Secondly, a load balancing device suitable for privately deployed clusters is provided, including:

[0013] The first determining module is used to periodically determine a first score of a node based on the load data of the nodes in the cluster, and to determine a second score of a container group based on the load data of the container group on the node.

[0014] The eviction module is used to evict container groups on the node based on a first score of the node and a second score of the container groups on the node.

[0015] An update module is used to update the first score of the nodes in the cluster based on the second score of the expelled container group, so as to obtain the third score of the nodes in the cluster.

[0016] The deployment module is used to redeploy the evicted container group based on the third score of the nodes in the cluster.

[0017] Thirdly, an electronic device is provided, comprising:

[0018] processor;

[0019] Memory used to store the processor's executable instructions;

[0020] The processor is configured to execute the instructions to implement the load balancing method for privately deployed clusters as provided in the first aspect.

[0021] Fourthly, a computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a load balancing method suitable for privately deployed clusters as provided in the first aspect.

[0022] Fifthly, a computer program product is provided, the computer program product including a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the load balancing method for privately deployed clusters provided in the first aspect.

[0023] The scheme in this embodiment periodically evaluates a node's first score based on the load data of the nodes within the cluster to represent the node's load size, and evaluates a container group's second score based on the load data of the container groups on the nodes to represent the container group's load size. Then, based on the first score of the nodes within the cluster and the second score of the container groups on the nodes, container groups on the nodes are evicted, achieving periodic centralized rescheduling of the cluster. This avoids the risks associated with routine scheduling based on minute-level real-time data during peak business periods, improving business stability and saving resources compared to routine scheduling based on minute-level real-time data. Furthermore, based on the second score of the evicted container groups, the first score of the nodes within the cluster is updated to obtain a third score for the nodes within the cluster. Based on the third score of the nodes within the cluster, the evicted container groups are redeployed, achieving load-aware scheduling of the evicted container groups. This is equivalent to briefly enabling load-aware scheduling after rescheduling. Combining these two methods better balances the load of each node within the cluster, meeting the load balancing needs of private deployment clusters such as small private cloud clusters. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0025] Figure 1 This specification provides a schematic diagram of the architecture of a load balancing system suitable for a privately deployed cluster, as one embodiment of the present specification.

[0026] Figure 2 A schematic diagram of a rescheduler is provided for one embodiment of this specification;

[0027] Figure 3 A schematic diagram illustrating the interaction between an extender and a scheduler, provided as an embodiment of this specification;

[0028] Figure 4 A flowchart illustrating a load balancing method suitable for a privately deployed cluster, provided as an embodiment of this specification;

[0029] Figure 5 A schematic flowchart illustrating a container group eviction method provided as an embodiment of this specification;

[0030] Figure 6 A flowchart illustrating a container group deployment method provided as an embodiment of this specification;

[0031] Figure 7A flowchart illustrating a container group deployment method provided for another embodiment of this specification;

[0032] Figure 8 A schematic diagram of a load balancing device suitable for a privately deployed cluster, provided as an embodiment of this specification;

[0033] Figure 9 This is a schematic diagram of an electronic device provided as an embodiment of the present specification. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this document.

[0035] The term "comprising" and its variations as used in this document are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. The term "in response to" indicates that the performed operation depends on a condition or state. When the dependent condition or state is met, one or more operations may be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which multiple operations are performed.

[0036] It should be noted that the concepts of "first" and "second" mentioned in this document are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0037] It should be noted that the terms "one" and "more" used in this document are illustrative rather than restrictive, and those skilled in the art should understand that, unless explicitly stated otherwise in the context, they should be understood as "one or more".

[0038] The names of messages or information exchanged between multiple devices in the embodiments of this document are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0039] As mentioned earlier, current load balancing solutions for Kubernetes are generally provided by cloud vendors or the community. They are designed from the perspective of cloud vendor infrastructure, resulting in problems such as poor stability and high risk, and cannot better adapt to the characteristics of privately deployed clusters such as small private cloud clusters.

[0040] Through extensive research, the inventors discovered that privately deployed clusters have the following characteristics:

[0041] (1) Closer to business. Clusters can provide detailed rules for microservices and are responsible for the business's SLA (Service Level Agreement).

[0042] (2) The scale is relatively small, resources are more scarce, peak periods are concentrated, and business characteristics are obvious. Therefore, more attention needs to be paid to the risks that each scheduling may bring. At the same time, resources are fixed, and it is only necessary to balance the load of each node as much as possible over a longer period of time.

[0043] (3) Nodes within the cluster can be deployed using virtualization, i.e., super-division virtual machines on physical machines, with each virtual machine being a node, and the cluster and storage components are deployed in a hybrid manner. This requires consideration of the actual load of the underlying physical machines in the virtualization scenario.

[0044] Based on the above findings, this specification proposes a new load balancing strategy from the perspective of risk reduction, considering specific scenarios under these constraints. It periodically evaluates a node's first score based on the load data of nodes within the cluster to represent the node's load size, and evaluates a container group's second score based on the load data of the container groups on the node to represent the container group's load size. Then, based on the first score of the node within the cluster and the second score of the container groups on the node, it performs eviction processing on the container groups on the node within the cluster, achieving periodic centralized rescheduling of the cluster. This avoids the risks associated with routine scheduling based on minute-level real-time data during peak business periods, improves business stability, and saves resources compared to routine scheduling based on minute-level real-time data. Based on this, the first score of the nodes in the cluster is updated based on the second score of the expelled container group to obtain the third score of the nodes in the cluster. Based on the third score of the nodes in the cluster, the expelled container group is redeployed to achieve load-aware scheduling of the expelled container group. This is equivalent to briefly enabling load-aware scheduling after rescheduling. Combining the two can better balance the load of each node in the cluster and meet the load balancing needs of private deployment clusters such as small private cloud clusters.

[0045] Furthermore, for scenarios where nodes within a private deployment cluster are deployed using virtualization, this specification also proposes a container group eviction mechanism for such nodes. When eviction, the load of each virtual machine serving as a node is considered, as well as the load of the physical machine where each virtual machine resides. This not only keeps the overall load of the physical machines within the cluster within the same range as much as possible, but also keeps the load of the virtual machines below the threshold, thus better meeting the load balancing requirements of a virtualization deployment environment.

[0046] It should be understood that the load balancing method for privately deployed clusters provided in the embodiments of this specification can be executed by an electronic device or software installed in an electronic device. The electronic device here can be a terminal device or a server device.

[0047] Before providing a detailed description of the load balancing method for privately deployed clusters provided in the embodiments of this specification, a brief overview of the architecture of the load balancing system involved in the embodiments of this specification is provided. Please refer to... Figure 1 This is a schematic diagram of the architecture of a cluster load balancing system provided in one embodiment of this specification. The system includes: a cluster API (Application Programming Interface) server, a native scheduler, a descheduler, a scheduler extender, and a monitoring device within the cluster.

[0048] The API server is responsible for communication between the various functional modules of the cluster. The scheduler is responsible for monitoring newly created, unspecified nodes and deploying them to appropriate nodes for operation.

[0049] The monitoring equipment is used to monitor the load data of each node in the cluster and the load data of the container groups on the nodes, and to store this load data. The monitoring equipment may include various components or plugins with monitoring, data acquisition and storage functions, such as Prometheus, InfluxDB, etc., which are not limited to the embodiments in this specification.

[0050] Rescheduling provides a series of strategies to evict container groups on heavily loaded nodes in order to rebalance the cluster state. The extender interacts with the rescheduler and the scheduler, passing on the load information of the nodes and their container groups obtained by the rescheduler to the scheduler, providing the scheduler with a reference so that the scheduler can deploy container groups to appropriate nodes.

[0051] In one implementation, upon receiving a newly created container group, the API server sends the container group to the scheduler, which then deploys these container groups to appropriate nodes based on a preset scheduling policy. The rescheduler periodically retrieves load data from monitoring devices for nodes within the cluster and load data for container groups on those nodes. It evaluates the node scores based on the node load data and the container group scores based on the container group load data. Further, based on the node scores and the container group scores on those nodes, the rescheduler determines the first node to be rescheduled and the first container group on that first node to be rescheduled. Then, through the API server, it requests the scheduler to evict the first container group from the first node, thereby completing the rescheduling of nodes within the cluster.

[0052] After identifying the first container group, the rescheduler passes the scores of each node in the cluster and the scores of the container groups on those nodes to the extender. The extender then sorts the nodes based on these scores. Responding to the scoring request sent by the scheduler via a webhook, the extender sends the sorting results back to the scheduler, which then redeploys the first container group to suitable nodes. This achieves load-aware scheduling of the first container group. Essentially, the rescheduler briefly enables load-aware scheduling after rescheduling, and by combining rescheduling with load-aware scheduling, it better balances the load on each node within the cluster, meeting the load balancing needs of private deployment clusters such as small private cloud clusters.

[0053] In the embodiments described in this specification, the rescheduler can be implemented using a plug-in mechanism. In one implementation, such as... Figure 2 As shown, the rescheduler includes a first eviction plugin, a balancing plugin, a rescheduling plugin, and a second eviction plugin. The first eviction plugin initially filters out nodes within the cluster that can be rescheduled and the container groups on those nodes that can be rescheduled. The balancing plugin, aiming to balance the load across nodes in the cluster as much as possible, determines the first node to be rescheduled from the initially filtered nodes. The rescheduling plugin determines candidate container groups from the reschedulable container groups on the first node. The second eviction plugin selects container groups from the candidate container groups that meet preset rescheduling conditions as the container groups to be evictioned, so that the scheduler can process them.

[0054] Expanders can be implemented based on the cluster's scaling mechanism. In one implementation, such as... Figure 3As shown in (a), in addition to the API server and scheduler, the cluster may also include a control manager (such as Kube-controller-manager), node proxy servers (such as Kubelet), and network proxy services (Kube-proxy). The extender and scheduler communicate using either HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure). Specifically, as... Figure 3 As shown in (b), the scheduler's deployment of container groups includes a filtering phase, a scoring phase, and a binding phase. During these three phases, the scheduler and extenders can interact with each other. For example, the scheduler sends a request to the extender to obtain the necessary information, and the extender returns a response message to the scheduler, carrying the information required by the scheduler. Specifically, in the filtering phase, the scheduler selects all nodes in the cluster that meet the deployment requirements of the evicted container group. In the scoring phase, the scheduler scores each candidate node in the candidate node list according to preset scoring rules. In the binding phase, the scheduler redeploys the evicted container group to a second node.

[0055] Based on the architecture of the load balancing system for privately deployed clusters described above, the load balancing method for privately deployed clusters provided in this specification will now be described in detail with reference to the accompanying drawings.

[0056] Please refer to Figure 4 The following is a flowchart illustrating a load balancing method suitable for a privately deployed cluster, provided as an embodiment of this specification. The method includes the following steps:

[0057] S402 periodically determines the first score of a node based on the load data of the nodes within the cluster, and determines the second score of a container group based on the load data of the container group on the node.

[0058] A cluster can refer to a Kubernetes cluster. For example, a cluster can be a privately deployed cluster such as a small private cloud Kubernetes cluster. Each node within the cluster can refer to a worker node within the Kubernetes cluster. In the embodiments of this specification, the cluster can be deployed using either a virtualization method or a non-virtualization method. In a non-virtualization deployment, each node is a physical machine, while in a virtualization deployment, each node is a virtual machine (VM) on a physical machine. A physical machine refers to an actual hardware device with independent physical resources (such as CPU, memory, etc.). A virtual machine refers to a logical computer simulated on a physical machine using virtualization technology, sharing the resources of the physical machine. Multiple virtual machines can exist on a single physical machine.

[0059] For each node within the cluster, node load data reflects its resource usage and performance, and can include, but is not limited to, multiple dimensions of load data such as CPU (Central Processing Unit) load data, memory load data, disk I / O (Input / Output) load data, and network load data. CPU load data may include, but is not limited to, CPU utilization, number of CPU cores, and CPU latency. Memory load data may include, but is not limited to, memory utilization, memory allocation / release rate, and cache hit rate. Disk I / O load data may include, but is not limited to, disk read / write speed, IOPS (Input / Output Operations Per Second), and disk latency. Network load data may include, but is not limited to, network bandwidth utilization, packet loss rate, and network latency.

[0060] After obtaining the load data for each node, a first score can be obtained for each node by analyzing its load data. The first score reflects the node's load level. The higher the first score, the greater the node's load. In one implementation, the load data of each node is weighted and averaged to obtain the node's first score, denoted as score = sum(weight × resource percent) / sum(weight), where resource percent represents the load data for each dimension, and weight represents the weight corresponding to each dimension. The weight of each dimension can be set according to actual needs, and this specification does not limit this. For example, assuming the node's CPU utilization is 80%, the weight corresponding to CPU utilization is 0.5; the memory utilization is 70%, the weight corresponding to memory utilization is 0.4; and the network bandwidth utilization is 60%, the weight corresponding to network bandwidth utilization is 0.1, then the node's first score = (80% × 0.5 + 70% × 0.4 + 60% × 0.1) / 1 = 0.74.

[0061] A container group consists of at least one container. A container group can refer to a Pod in a Kubernetes cluster. A Pod is the smallest deployable computing unit created and managed by Kubernetes. A Pod consists of at least one container, which shares storage, network, and the declaration of how to run these containers. At least one container group is deployed on a node, and these container groups are orchestrated and scheduled by the cluster's scheduler. Each container group has corresponding load data. The container group's load data reflects the resource usage and performance of the container group, and may include, but is not limited to, load data across multiple dimensions such as CPU load, memory load, disk I / O load, and network load.

[0062] After obtaining the load data for each container group, a second score can be obtained for each container group by analyzing its load data. The second score reflects the load magnitude of the container group. The larger the second score, the greater the load of the container group. In one implementation, a weighted average is applied to the load data of the container group in each dimension to obtain the second score. The specific implementation method for determining the second score of the container group is similar to that for determining the first score of the first node, and will not be repeated here.

[0063] In the application, the load data of nodes and the load data of container groups on nodes can be obtained from monitoring devices. For example, the rescheduler periodically queries the monitoring system for the load data of each node in the cluster during the previous period, as well as the load data of the container groups on each node during the previous period. Then, for each dimension of the load data for each node, the P99, P98, and other percentile values ​​of that dimension's load data are calculated to obtain the final load data for that dimension; further, based on the final load data of that node across all dimensions, a first score for that node is determined. Similarly, for each dimension of the load data for each container group, the P99, P98, and other percentile positions of that dimension's load data are calculated to obtain the final load data for that dimension; further, based on the final load data of that container group across all dimensions, a second score for that container group is determined. Here, P99 refers to the percentile value where 99% or less of the load data in the previous period is less than or equal to the previous percentile value, and P98 refers to the percentile value where 98% or less of the load data in the previous period is less than or equal to the previous percentile value. This avoids the impact of outliers in the load data on score prediction, thereby improving the accuracy of the first score prediction for each node and the second score prediction for the container group on the node.

[0064] Furthermore, considering the limited resources of privately deployed clusters and their generally direct focus on business modules, minute-level real-time rescheduling not only consumes significant resources and puts pressure on the cluster, but may also introduce risks during high-risk business periods, impacting business stability. Therefore, the cycle duration can be set to a longer value, and the timing can be set during off-peak business periods to achieve long-term, low-frequency, low-risk rescheduling. For example, a rescheduling can be initiated at 1:11 AM daily, executing step S402 above and subsequent steps S404 to S408 based on the first score of each node and the second score of the container group on the node. This avoids the risks associated with scheduling during peak business periods, improves business stability, saves resources, and better meets the load balancing requirements of privately deployed clusters.

[0065] S404, based on the first score of the node and the second score of the container group on the node, performs eviction processing on the container group on the node.

[0066] Since the first score of a node reflects the node's load, and the second score of the container group on the node reflects the container group's load, the nodes with high load and the container groups on these nodes can be identified based on the first score and the second score of the container group on the node. By removing these container groups from their respective nodes, they can be redeployed to other nodes with lower load, achieving load balancing among different nodes in the cluster. This reduces the load pressure on high-load nodes and increases the resource utilization of low-load nodes.

[0067] In the first implementation, S404 includes the following steps: First, the node with a first score greater than a first threshold in the cluster is identified as the first node to be rescheduled; then, the container group on the first node with a second score greater than a third threshold is identified as the first container group to be rescheduled; further, the first container group is expelled from the first node.

[0068] Considering that the above method of directly filtering and evicting nodes and container groups on nodes based on thresholds is rather crude and ignores the load and dynamism of cluster operation, it may lead to the wrongful eviction of critical container groups, thereby affecting business stability and availability. Therefore, in the second implementation method, the above 404 includes the following steps:

[0069] S4041 Sort the nodes in the cluster according to the first score from high to low to obtain the first priority queue.

[0070] S4042, traverse the first priority queue.

[0071] Since the node with the highest score is located at the beginning of the first priority queue, the node with the highest load is traversed first.

[0072] S4043, when traversing a node in the first priority queue, if the first score of the node is greater than or equal to the first threshold, then the node is determined as the first node to be rescheduled.

[0073] S4044, based on the second score of the container group on the first node and the difference between the first score of the first node and the first threshold, perform eviction processing on the container group on the first node.

[0074] As an example, firstly, the difference between the first score of the first node and the first threshold is determined as the eviction reserve of the first node; then, from the container groups on the first node, the container groups with first scores greater than the eviction reserve of the first node are determined as the first container groups to be rescheduled, and the first container groups are then evicted from the first node; if the second scores of all container groups on the first node are less than the eviction reserve of the first node, then at least two container groups whose sum of second scores is greater than the eviction reserve are selected as the first container groups to be rescheduled, and the first container groups are then evicted from the first node.

[0075] For example, assuming the cluster contains m nodes, where m is an integer greater than 1, sorting these nodes according to their first score from highest to lowest yields the following result: Figure 5 The first priority queue is shown. Traversing the first priority queue, when node 1 is reached, its first score is 74%, which is greater than the first threshold of 50%, so node 1 is determined as the first node. Assume that p container groups are deployed on the first node, denoted as container group 1 to container group p, where p is an integer greater than 1. Assuming the first node's first score is 74% and the first threshold is 50%, then the eviction margin for the first node is 74% - 50% = 24%. Assuming only container group 1 has a second score greater than 24%, then container group 1 is evicted from the first node. At this point, the container groups on the first node include container groups 2 to p. Assuming that the second scores of container groups 1 to p are all less than 24%, but the sum of the second scores of container group 1 and container group p is greater than 24% and smaller than the sum of the second scores of other container groups, then container group 1 and container group p are evicted from the first node. At this point, the container groups on the first node include container groups 2 to p-1. Continue traversing the next node in the first priority queue and repeat the above operation.

[0076] As another example, the container groups on the first node are sorted in descending order of the second score to obtain the third priority queue; the third priority queue is traversed; when a container group in the third priority queue is traversed, if the container group meets the preset rescheduling conditions, the container group is evicted from the first node.

[0077] The rescheduling conditions can be set according to actual needs, and this specification does not limit them in the embodiments. For example, the rescheduling conditions may include at least one of the following: the evicted container group is not on the blacklist, the evicted container group is on the whitelist, the resource request of the evicted container group is less than the request threshold, the second score of the evicted container group is less than the evictable capacity of its node, the number of evicted container groups is less than the quantity threshold, and the number of available container groups on the node where the evicted container group is located is greater than one, etc. The blacklist is used to record container groups that are not allowed to be evicted, such as container groups that would cause system failure after being evicted, or container groups that would increase the load on other nodes after being evicted, etc. The whitelist is used to record container groups that are allowed to be evicted, such as container groups that will not cause system failure after being evicted, or container groups that will not increase the load on other nodes after being evicted, etc.

[0078] like Figure 5 As shown, p container groups are deployed on the first node. These container groups are sorted in descending order of their second score, resulting in the following: Figure 5 The third priority queue is shown. Traversing the third priority queue, upon reaching each container group, it checks if the container group is in the blacklist. If not, it continues to the next container group; if so, it checks if the resource requirement of the currently traversed container group is less than a pre-set requirement threshold. If the resource requirement of the container group is greater than or equal to the requirement threshold, it continues to the next container group; if the resource requirement of the container group is less than the requirement threshold, it checks if the second score of the container group is less than the evictable reserve of the first node; if the second score of the container group is greater than or equal to the evictable reserve, it continues to the next container group. If the second score of the currently traversed container group is less than the remaining evictable quantity, then determine whether the number of currently evicted container groups is less than a preset quantity threshold; if the number of currently evicted container groups is greater than or equal to the quantity threshold, then stop traversing the third priority queue; if the number of currently evicted container groups is less than the quantity threshold, then determine whether the number of available container groups on the first node is greater than 1; if not, then stop traversing the third priority queue; if the number of available container groups on the first node is greater than 1, then call the API server to evict the currently traversed container group from the first node.

[0079] By evicting containers from nodes within the cluster using the methods described above, the load on nodes within the cluster can be finely adjusted, avoiding risks that may arise after container eviction, such as affecting system stability and availability, or causing increased load on other nodes.

[0080] In the third implementation, considering that nodes are virtual machines on physical machines in a virtualized deployment cluster, eviction based solely on the node's first score and the second score of the container group on the node may still overload the physical machine hosting the node, affecting load balancing among physical machines in the cluster. Therefore, the second implementation is improved. For clusters using virtualization, the scores of both the physical machine and virtual machine layers are calculated and abstracted into two priority queues. The node eviction process is as follows: first, high-load physical machines are ejected; then, relatively high-load virtual machines (nodes) on the high-load physical machines are ejected. Based on the load of the container groups on these virtual machines, appropriate container groups are selected for eviction to control the overall load of physical machines within the same range and keep the virtual machine load below a threshold, thereby allocating limited resources to high-load physical machines.

[0081] Specifically, prior to S4041, the process includes: if the nodes in the cluster are virtual machines on physical machines, determining the fourth score of each physical machine in the cluster based on its load data; sorting the physical machines in the cluster according to their fourth scores from highest to lowest to obtain a second priority queue; traversing the second priority queue; and, when traversing to a physical machine in the second priority queue, if the fourth score of that physical machine is greater than or equal to a second threshold, identifying that physical machine as the first physical machine to be rescheduled. Correspondingly, in S4041, the nodes on the first physical machine are sorted according to their first scores from highest to lowest to obtain the first priority queue corresponding to the first physical machine.

[0082] The physical machine load data reflects the resource usage and performance of each physical machine, and may include, but is not limited to, load data from multiple dimensions such as CPU load, memory load, disk I / O load, and network load. After obtaining the load data for each physical machine, a fourth score can be obtained by analyzing the load data of each physical machine. The fourth score reflects the magnitude of the physical machine's load. The higher the fourth score, the greater the load on the physical machine.

[0083] It should be noted that the specific implementation method for determining the fourth score of the physical machine is similar to that for determining the first score of the first node, and will not be repeated here. Secondly, the load data of the physical machine can be obtained from the monitoring equipment. Additionally, the second threshold can be less than the first threshold.

[0084] For example, such as Figure 5 As shown, the first cluster contains n physical machines, where n is an integer greater than 1. These physical machines are sorted in descending order of their fourth score, resulting in the following... Figure 5The second priority queue is shown, and the second priority queue is traversed.

[0085] When traversing to physical machine 1, if the fourth score of physical machine 1 is less than or equal to the second threshold, it means that the load of physical machine 1 is not high, and there is no need to perform container group eviction on the nodes on physical machine 1. Then, continue traversing to the next physical machine. If the fourth score of physical machine 1 is greater than the second threshold, it means that the load of physical machine 1 is too high. Then, physical machine 1 is determined as the first physical machine to be rescheduled. Further, the nodes (i.e., virtual machines) on physical machine 1 are sorted in descending order of the first score to obtain the first priority queue corresponding to physical machine 1. Then, the above S4042 to S4044 are executed to complete the container group eviction process for the nodes on physical machine 1.

[0086] Next, continue iterating through the next physical machine and repeat the above operations.

[0087] This ensures that the overall load of physical machines within the cluster is kept within the same range, and the load of virtual machines is also kept below the first threshold.

[0088] For the third implementation method mentioned above, after each traversal of a node in the first priority queue corresponding to the first physical machine, and after determining the node as the first node to be rescheduled and performing eviction processing on the container group on the first node, the method further includes: updating the fourth score of the first physical machine based on the first score of the first node to obtain the fifth score of the first physical machine; if the fifth score of the first physical machine is less than the second threshold, then traversing the first priority queue corresponding to the first physical machine is stopped.

[0089] For example, continue with Figure 5 Taking the first priority queue and the second priority queue as an example, when traversing to physical machine 1 in the first priority queue, physical machine 1 is identified as the first physical machine, and its fourth score is 90%. During the traversal of the first priority queue corresponding to the first physical machine, if node 1 is currently being traversed and identified as the first node, and its first score is 70%, then the first score of the first node is deducted from the fourth score of physical machine 1, resulting in a fifth score of 20% for physical machine 1. Since this fifth score is less than the second threshold of 50%, it means that the load on physical machine 1 is not high, and there is no need to implement container group eviction for other nodes on physical machine 1. Therefore, the traversal of the first priority queue corresponding to physical machine 1 is stopped, and the traversal of the next physical machine 2 in the second priority queue continues.

[0090] This allows the cluster's limited resources to be allocated to high-load physical machines, thus optimizing the utilization of the cluster's resources.

[0091] For the third implementation described above, after updating the fourth score of the first physical machine based on the first score of the first node to obtain the fifth score of the first physical machine, the following steps may also be included: adjusting the order of physical machines in the second priority queue based on the fifth score of the first physical machine. For example, according to the order of scores from high to low, the first physical machine is pushed back into the appropriate position in the second priority queue.

[0092] This allows for dynamic adjustment of the rescheduling order of physical machines within the cluster, ensuring that high-load physical machines are rescheduled first, thereby ensuring that the cluster's limited resources are allocated to high-load physical machines and achieving further optimization of cluster resource utilization.

[0093] The foregoing illustrates a partial implementation of S404. It should be understood that S404 can also be implemented in other ways, and this specification does not limit this implementation.

[0094] S406 updates the first score of the nodes in the cluster based on the second score of the expelled container group, and obtains the third score of the nodes in the cluster.

[0095] In one implementation, after completing the container group eviction process for all nodes in the cluster, for each node, if there are evictiond container groups on that node, the node's first score is updated based on the second score of that container group to obtain the node's third score. For example, the second score of the container group is deducted from the node's first score.

[0096] In another implementation, where the second implementation method is used in S404 to evict container groups on nodes within the cluster, S406 includes: after S4044, updating the first node's first score based on the second score of the evicted container group on the first node to obtain the first node's third score. For example, subtracting the second score of the evicted container group from the first node's first score yields the first node's third score.

[0097] Furthermore, after S406, it may also include: stopping traversal of the third priority queue if the third score of the first node is less than the first threshold; and adjusting the order of nodes in the first priority queue based on the third score of the first node.

[0098] If the third score of the first node is less than the first threshold, it means that the load of the first node has been controlled below the threshold, and there is no need to perform container group eviction processing on the first node, which can save cluster resources. In addition, the order of nodes in the first priority queue is adjusted based on the third score of the first node, which can realize the dynamic adjustment of the rescheduling order of nodes within the cluster. This ensures that nodes with higher loads are rescheduled first, thereby ensuring that the cluster's limited resources are allocated to high-load nodes, and achieving further optimization of cluster resource utilization.

[0099] The foregoing illustrates a partial implementation of S406. It should be understood that S406 can also be implemented in other ways, and this specification does not limit this implementation.

[0100] S408 redeploys the evicted container group based on the third score of the nodes within the cluster.

[0101] In one implementation, S408 includes the following steps: selecting a node with a smaller third score from among the nodes in the cluster other than the node where the evicted container originally resided, as the second node for deploying the evicted container group, and then deploying the evicted container group on the second node.

[0102] Considering that when there are many evicted container groups, redeploying the evicted container groups using the above implementation method may lead to an imbalance in the load among nodes in the cluster, in another implementation method, the above S408 includes the following steps: S4081, sort the nodes in the cluster in descending order of the third score to obtain a fourth priority queue; S4082, based on the fourth priority queue, determine the second node in the cluster for deploying the evicted container groups; S4083, deploy the evicted container groups to the second node.

[0103] Specifically, the rescheduler passes the third score of each node in the cluster to the extender. The extender then sorts the nodes in the cluster to obtain a fourth priority queue, which is sent to the cluster's native scheduler. The scheduler, combining the default static orchestration strategy with the fourth priority queue, determines the second node from within the cluster. The scheduler then deploys the evicted container group to the second node. In this way, the rescheduler effectively initiates the load awareness function, and the extender indirectly passes the node scores (based on load data) and the scores of the container groups on those nodes to the cluster's native scheduler for scheduling, achieving load-aware scheduling of evicted container groups.

[0104] Figure 6The scheduling logic of the scheduler is illustrated, which includes three phases: filtering, scoring, and binding. In the filtering phase, the scheduler selects all nodes in the cluster that meet the deployment requirements of the evicted container group, such as nodes whose available resources meet the resource requirements of the evicted container group, resulting in a candidate node list. This list contains all schedulable candidate nodes.

[0105] During the scoring phase, the scheduler scores each candidate node in the candidate node list according to preset scoring rules. This includes combining strategies such as minimum request priority, affinity priority, and load awareness, along with the weights of each strategy, to determine the score for each candidate node. Specifically, the minimum request priority strategy assigns higher priority to nodes with fewer minimum requests; the affinity priority strategy prioritizes nodes whose currently deployed container groups have affinity with those of the evicted container groups; and the load awareness strategy determines node priority based on the fourth priority queue sent by the extender. For example, if a node has a priority of 2 under the minimum request priority strategy, 1 under the affinity priority strategy, and 1 under the load awareness strategy, with a weight of 1 for both the minimum request priority and affinity priority strategies, and a priority of 100 for the load awareness priority strategy, then the node's final score is (2+1+1) / (1+1+100) = 0.039.

[0106] Furthermore, based on each node's score, the scheduler selects the most suitable node as the second node for the evicted container group; for example, it selects the node with the highest score as the second node. If multiple nodes with the highest scores exist, the scheduler will randomly select one of them as the second node.

[0107] During the binding phase, the scheduler will redeploy the evicted container group to the second node.

[0108] This completes the redeployment of the evicted container group.

[0109] In another embodiment, after S4083 above, the following steps may be included: in response to the successful deployment of the evicted container group, the third score of the nodes in the cluster is updated based on the second score of the evicted container group to obtain the sixth score of the nodes in the cluster; and the order of the nodes in the fourth priority queue is adjusted based on the sixth score of the nodes in the cluster.

[0110] Specifically, if the second node is a physical machine, then the third score of the second node is updated based on the second score of the expelled container group to obtain the sixth score of the second node. For example, the second score of the expelled container group is added to the third score of the second node to obtain the sixth score of the second node.

[0111] If the second node is a virtual machine, then based on the second score of the evicted container group, the third score of the second node and the third scores of other nodes on the same physical machine as the second node are updated to obtain the sixth score of the second node and the sixth scores of the other nodes. For example, assuming that container group 1 is redeployed to node 2 after being evicted from node 1, and node 2, node 3, and node 4 are distributed on the physical machine where node 2 resides, then the second score of container group 1 is added to the third score of node 2 to obtain the sixth score of node 2. In addition, the second score of container group 1 is added to the third score of node 3 to obtain the sixth score of node 3, and the second score of container group 4 is added to the third score of node 4 to obtain the sixth score of node 4. It is understandable that the load-bearing objects within the cluster are physical machines. After a container group that has been evicted is redeployed to a certain node, it is equivalent to adding that container to the physical machine where that node resides. Based on this, the load status of the physical machine can only be reflected on that node by updating the second score of all nodes on the physical machine where that node resides. Otherwise, when scheduling the next container group in the future, there may be a situation where the physical machine has a high load, but a certain node on that physical machine has a low load and is deployed to a new container group, which may lead to a situation where the physical machine is severely overloaded.

[0112] Furthermore, the order of nodes in the fourth priority queue is adjusted according to the latest scores of each node in the cluster from high to low, thereby providing reliable data support for the scheduling of the next container group.

[0113] The foregoing illustrates a partial implementation of S408. It should be understood that S408 can also be implemented in other ways, and this specification does not limit this implementation.

[0114] To facilitate understanding of the load balancing method for privately deployed clusters provided in the above embodiments of this specification, the following is in conjunction with... Figure 7 In response to a received start scheduling request, the rescheduler periodically retrieves load data of nodes within the cluster and load data of container groups on those nodes from the monitoring device. It then evaluates the node scores based on the node load data and the container group scores based on the container group load data, writing both scores into a cache. Furthermore, based on the node and container group scores, the rescheduler also performs eviction operations on container groups on the nodes and briefly activates a load awareness switch for a preset duration.

[0115] After receiving a scoring request from the native scheduler within the cluster, the extender iterates through the cluster's node list. For each node encountered, it obtains its score and the score of the container group associated with that node. Then, based on the scores of all nodes in the list, it sorts these nodes and returns the sorting result to the scheduler. This effectively transmits the scheduler's load awareness results to the scheduler, which then redeploys the evicted container groups. If the extender cannot obtain the score for a node or the score for its container group, it activates a pre-defined fallback strategy to generate the score for that node or container group.

[0116] In one implementation, the process by which the extender obtains the score of a node and the score of the container group on that node is as follows: For each node in the node list, the extender retrieves the score of that node and the score of the container group on that node from the cache; if the original container group on that node is evicted, the extender also updates the score of that node based on the score of the evicted container group, and listens for whether the evicted container group has been redeployed through a built-in listening mechanism. If so, the extender updates the score of the node where the evicted container group is currently located based on the score of the evicted container group, and if the node where the evicted container group is currently located is a virtual machine, the extender also updates the scores of other nodes on the same physical machine as that node.

[0117] The load balancing method for privately deployed clusters provided in this specification periodically evaluates a node's first score based on the load data of the nodes within the cluster, representing the node's load size, and evaluates a container group's second score based on the load data of the container groups on the nodes, representing the container group's load size. Then, based on the first score of the nodes within the cluster and the second score of the container groups on the nodes, container groups on the nodes are evicted, achieving periodic centralized rescheduling of the cluster. This avoids the risks associated with routine scheduling based on minute-level real-time data during peak business periods, improving business stability and saving resources compared to routine scheduling based on minute-level real-time data. Furthermore, based on the second score of the evicted container groups, the first score of the nodes within the cluster is updated to obtain a third score for the nodes within the cluster. Based on the third score of the nodes within the cluster, the evicted container groups are redeployed, achieving load-aware scheduling of the first container group. This is equivalent to briefly enabling load-aware scheduling after rescheduling. Combining these two methods better balances the load of each node within the cluster, meeting the load balancing needs of privately deployed clusters such as small private cloud clusters.

[0118] In addition, with the above Figure 4 Corresponding to the load balancing method for privately deployed clusters shown, embodiments of this specification also provide a load balancing device for privately deployed clusters. Figure 8 This is a schematic diagram of the structure of a load balancing device 800 suitable for private deployment clusters provided in the embodiments of this specification, including: a first determining module 810, an eviction module 820, an update module 830, and a deployment module 840.

[0119] The first determining module 810 is used to periodically determine a first score of a node based on the load data of the nodes in the cluster, and to determine a second score of a container group based on the load data of the container group on the node.

[0120] The eviction module 820 is used to evict container groups on the node based on a first score of the node and a second score of the container groups on the node.

[0121] The update module 830 is used to update the first score of the nodes in the cluster based on the second score of the expelled container group, so as to obtain the third score of the nodes in the cluster.

[0122] The deployment module 840 is used to redeploy the expelled container group based on the third score of the nodes in the cluster.

[0123] The load balancing device for privately deployed clusters provided in this specification periodically evaluates a node's first score based on the load data of the nodes within the cluster, representing the node's load size, and evaluates a container group's second score based on the load data of the container groups on the nodes, representing the container group's load size. Then, based on the first score of the nodes within the cluster and the second score of the container groups on the nodes, it performs eviction processing on the container groups on the nodes within the cluster, achieving periodic centralized rescheduling of the cluster. This avoids the risks associated with routine scheduling based on minute-level real-time data during peak business periods, improving business stability and saving resources compared to routine scheduling based on minute-level real-time data. Furthermore, based on the second score of the evicted container groups, the first score of the nodes within the cluster is updated to obtain a third score for the nodes within the cluster. Based on the third score of the nodes within the cluster, the evicted container groups are redeployed, achieving load-aware scheduling of the evicted container groups. This is equivalent to briefly enabling load-aware scheduling after rescheduling. Combining these two methods better balances the load of each node within the cluster, meeting the load balancing needs of privately deployed clusters such as small private cloud clusters.

[0124] In another embodiment, the expulsion module includes:

[0125] The first sorting submodule is used to sort the nodes in the cluster in descending order of the first score to obtain a first priority queue.

[0126] The first traversal submodule is used to traverse the first priority queue;

[0127] The first determining submodule is used to determine the node as the first node to be rescheduled if the first score of the node is greater than or equal to the first threshold when traversing the first priority queue.

[0128] The eviction submodule is used to evict a container group on the first node based on a second score of the container group on the first node and the difference between the first score of the first node and the first threshold.

[0129] In another embodiment, the expulsion module further includes:

[0130] The second determining submodule is used to determine the fourth score of the physical machine in the cluster based on the load data of the physical machine in the cluster if the node in the cluster is a virtual machine on a physical machine.

[0131] The second sorting submodule is used to sort the physical machines in the cluster in descending order of the fourth score to obtain the second priority queue.

[0132] The second traversal submodule is used to traverse the second priority queue;

[0133] The third determination submodule is used to determine the physical machine as the first physical machine to be rescheduled if the fourth score of the physical machine is greater than or equal to the second threshold when a physical machine is traversed in the second priority queue.

[0134] The first sorting submodule is used to sort the nodes on the first physical machine in descending order of the first score to obtain the first priority queue corresponding to the first physical machine.

[0135] In another embodiment, the expulsion module further includes:

[0136] The first update submodule is used to update the fourth score of the first physical machine based on the first score of the first node, so as to obtain the fifth score of the first physical machine.

[0137] The first traversal submodule is used to stop traversing the first priority queue corresponding to the first physical machine if the fifth score of the first physical machine is less than the second threshold.

[0138] In another embodiment, the expulsion module further includes:

[0139] The first adjustment submodule is used to adjust the order of physical machines in the second priority queue based on the fifth score of the first physical machine.

[0140] In another embodiment, the expulsion submodule is used for:

[0141] The containers on the first node are sorted in descending order of their second scores to obtain the third priority queue.

[0142] Traverse the third priority queue;

[0143] When a container group is encountered in the third priority queue, if the container group meets the preset rescheduling conditions, the container group is evicted from the first node.

[0144] In another embodiment, the update module includes:

[0145] The second update submodule is used to update the first score of the first node based on the second score of the container group that was expelled on the first node, so as to obtain the third score of the first node.

[0146] The expulsion submodule is also used to stop traversing the third priority queue when the third score of the first node is less than the first threshold.

[0147] The expulsion module also includes:

[0148] The second adjustment submodule is used to adjust the order of nodes in the first priority queue based on the third score of the first node.

[0149] In another embodiment, the deployment module includes:

[0150] The third sorting submodule is used to sort the nodes in the cluster in descending order of the third score to obtain the fourth priority queue.

[0151] The fourth determination submodule is used to determine, based on the fourth priority queue, a second node from within the cluster for deploying the evicted container group;

[0152] The deployment submodule is used to deploy the expelled container group to the second node.

[0153] In another embodiment, the deployment module further includes:

[0154] The third update submodule is used to respond to the successful deployment of the expelled container group by updating the third score of the nodes in the cluster based on the second score of the expelled container group, so as to obtain the sixth score of the nodes in the cluster.

[0155] The third adjustment submodule is used to adjust the order of nodes in the fourth priority queue based on the sixth score of the nodes in the cluster.

[0156] In another embodiment, the third update submodule is used for:

[0157] If the second node is a physical machine, then the third score of the second node is updated based on the second score of the expelled container group to obtain the sixth score of the second node;

[0158] If the second node is a virtual machine, then based on the second score of the expelled container group, the third score of the second node and the third scores of other nodes on the same physical machine as the second node are updated to obtain the sixth score of the second node and the sixth scores of the other nodes.

[0159] Obviously, the load balancing device suitable for privately deployed clusters in the embodiments of this specification can be used as described above. Figure 4 The execution entity shown is for a load balancing method suitable for privately deployed clusters, thus enabling the implementation of a load balancing method suitable for privately deployed clusters. Figure 4 The functions implemented are the same, so they will not be described in detail here.

[0160] Figure 9 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this specification. Please refer to it. Figure 9 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0161] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0162] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0163] The processor reads the corresponding computer program from non-volatile memory into main memory and then runs it, forming a load balancer suitable for private deployment clusters at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0164] A first score for a node is determined periodically based on the load data of the nodes within the cluster, and a second score for a container group is determined based on the load data of the container group on the node.

[0165] Based on the first score of the node and the second score of the container group on the node, the container group on the node is evicted.

[0166] The first score of the nodes in the cluster is updated based on the second score of the expelled container group to obtain the third score of the nodes in the cluster.

[0167] The evicted container group is redeployed based on the third score of the nodes within the cluster.

[0168] The above is as described in this instruction manual. Figure 4The method for executing a load balancing device suitable for privately deployed clusters, as disclosed in the illustrated embodiments, can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this specification. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this specification can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0169] It should be understood that the electronic devices described in the embodiments of this specification can implement load balancing devices suitable for privately deployed clusters. Figure 4 The embodiments shown have the same function. Since the principle is the same, the embodiments in this specification will not be described again here.

[0170] Of course, in addition to software implementation, the electronic device described in this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0171] This specification also provides an embodiment of a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform... Figure 4 The method of the illustrated embodiment is specifically used to perform the following operations:

[0172] A first score for a node is determined periodically based on the load data of the nodes within the cluster, and a second score for a container group is determined based on the load data of the container group on the node.

[0173] Based on the first score of the node and the second score of the container group on the node, the container group on the node is evicted.

[0174] The first score of the nodes in the cluster is updated based on the second score of the expelled container group to obtain the third score of the nodes in the cluster.

[0175] The evicted container group is redeployed based on the third score of the nodes within the cluster.

[0176] This specification also provides a computer program product comprising a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the load balancing method for privately deployed clusters provided in this specification.

[0177] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0178] In summary, the above description is merely a preferred embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

[0179] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0180] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0181] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0182] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A load balancing method suitable for privately deployed clusters, characterized in that, include: A first score is determined periodically based on the load data of the nodes within the cluster, and a second score is determined based on the load data of the container groups on the nodes; the first score represents the load size of the node, and the second score represents the load size of the container group. Based on the first score of the node and the second score of the container group on the node, the container group on the node is evicted; wherein, if the node in the cluster is a virtual machine on a physical machine, the eviction process of the container group on the node in the cluster includes: sorting the nodes on the first physical machine in descending order of the first score to obtain the first priority queue corresponding to the first physical machine, wherein the first physical machine is the physical machine in the cluster whose fourth score is greater than or equal to the second threshold, the fourth score of the physical machine is determined based on the load data of the physical machine, and the fourth score represents the load size of the physical machine; traversing the first physical machine... If the first score of a traversed node is greater than or equal to a first threshold, the traversed node is determined as the first node to be rescheduled. Based on the second score of the container group on the first node and the difference between the first score of the first node and the first threshold, the container group on the first node is evicted. After the evictation, the fourth score of the first physical machine is updated based on the first score of the first node to obtain the fifth score of the first physical machine. If the fifth score of the first physical machine is less than the second threshold, the traversal of the first priority queue corresponding to the first physical machine is stopped. The first score of the nodes in the cluster is updated based on the second score of the expelled container group to obtain the third score of the nodes in the cluster. The evicted container group is redeployed based on the third score of the nodes within the cluster.

2. The method according to claim 1, characterized in that, If the nodes in the cluster are physical machines, then the eviction process for the container groups on the node based on the first score of the node and the second score of the container groups on the node includes: The nodes in the cluster are sorted in descending order of their first score to obtain the first priority queue; Traverse the first priority queue; When a node in the first priority queue is traversed, if the first score of the node is greater than or equal to the first threshold, the node is determined as the first node to be rescheduled. Based on the second score of the container group on the first node and the difference between the first score of the first node and the first threshold, the container group on the first node is evicted.

3. The method according to claim 1, characterized in that, If the nodes in the cluster are virtual machines on physical machines, then before sorting the nodes on the first physical machine in descending order of the first score to obtain the first priority queue corresponding to the first physical machine, the following steps are also included: Based on the load data of the physical machines in the cluster, the fourth score of the physical machines in the cluster is determined; The physical machines in the cluster are sorted in descending order of their fourth score to obtain the second priority queue; Traverse the second priority queue; In each case where a physical machine is traversed to the second priority queue, if the fourth score of the physical machine is greater than or equal to the second threshold, then the physical machine is identified as the first physical machine to be rescheduled.

4. The method according to claim 3, characterized in that, After updating the fourth score of the first physical machine based on the first score of the first node to obtain the fifth score of the first physical machine, the method further includes: Based on the fifth score of the first physical machine, the order of the physical machines in the second priority queue is adjusted.

5. The method according to claim 2, characterized in that, The process of evicting the container group on the first node based on the second score of the container group on the first node and the difference between the first score of the first node and the first threshold includes: The containers on the first node are sorted in descending order of their second scores to obtain the third priority queue. Traverse the third priority queue; When a container group is encountered in the third priority queue, if the container group meets the preset rescheduling conditions, the container group is evicted from the first node.

6. The method according to claim 5, characterized in that, The process of updating the first score of nodes within the cluster based on the second score of the expelled container group to obtain the third score of nodes within the cluster includes: The first score of the first node is updated based on the second score of the container group that was expelled on the first node, so as to obtain the third score of the first node. After updating the first score of the first node based on the second score of the container group expelled from the first node to obtain the third score of the first node, the method further includes: If the third score of the first node is less than the first threshold, stop traversing the third priority queue; Based on the third score of the first node, adjust the order of nodes in the first priority queue.

7. The method according to any one of claims 1 to 6, characterized in that, The redeployment of the evicted container group based on the third score of the nodes within the cluster includes: The nodes in the cluster are sorted in descending order of the third score to obtain the fourth priority queue; Based on the fourth priority queue, a second node is determined from within the cluster for deploying the evicted container group; Deploy the expelled container group onto the second node.

8. The method according to claim 7, characterized in that, After deploying the expelled container group to the second node, the process further includes: In response to the successful deployment of the evicted container group, the third score of the nodes in the cluster is updated based on the second score of the evicted container group to obtain the sixth score of the nodes in the cluster. Based on the sixth score of the nodes within the cluster, the order of the nodes in the fourth priority queue is adjusted.

9. The method according to claim 8, characterized in that, The process of updating the third score of nodes within the cluster based on the second score of the expelled container group to obtain the sixth score of nodes within the cluster includes: If the second node is a physical machine, then the third score of the second node is updated based on the second score of the expelled container group to obtain the sixth score of the second node; If the second node is a virtual machine, then based on the second score of the expelled container group, the third score of the second node and the third scores of other nodes on the same physical machine as the second node are updated to obtain the sixth score of the second node and the sixth scores of the other nodes.

10. A load balancing device suitable for privately deployed clusters, characterized in that, include: The first determining module is used to periodically determine a first score of a node based on the load data of the nodes in the cluster, and to determine a second score of a container group based on the load data of the container group on the node; the first score represents the load size of the node, and the second score represents the load size of the container group. An eviction module is used to evict container groups on a node based on a first score and a second score of the container groups on that node. If the nodes in the cluster are virtual machines on physical machines, the eviction process for container groups on those nodes includes: sorting the nodes on a first physical machine in descending order of their first scores to obtain a first priority queue corresponding to the first physical machine. The first physical machine is a physical machine in the cluster whose fourth score is greater than or equal to a second threshold. The fourth score of the physical machine is determined based on its load data, where the fourth score represents the load size of the physical machine. The module iterates through the first... If the first score of a node traversed in the first priority queue corresponding to the physical machine is greater than or equal to a first threshold, then the traversed node is determined as the first node to be rescheduled. Based on the second score of the container group on the first node and the difference between the first score of the first node and the first threshold, the container group on the first node is evicted. After the evicting, the fourth score of the first physical machine is updated based on the first score of the first node to obtain the fifth score of the first physical machine. If the fifth score of the first physical machine is less than the second threshold, then traversing the first priority queue corresponding to the first physical machine is stopped. An update module is used to update the first score of the nodes in the cluster based on the second score of the expelled container group, so as to obtain the third score of the nodes in the cluster. The deployment module is used to redeploy the evicted container group based on the third score of the nodes in the cluster.

11. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the load balancing method for a privately deployed cluster as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the load balancing method for a privately deployed cluster as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps in the load balancing method for a privately deployed cluster as described in any one of claims 1 to 9.

Images