CN113032102B - Resource rescheduling method, device, equipment and medium - Google Patents

Resource rescheduling method, device, equipment and medium Download PDF

Info

Publication number
CN113032102B
CN113032102B CN202110374110.4A CN202110374110A CN113032102B CN 113032102 B CN113032102 B CN 113032102B CN 202110374110 A CN202110374110 A CN 202110374110A CN 113032102 B CN113032102 B CN 113032102B
Authority
CN
China
Prior art keywords
pod
rescheduled
node
load
low
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110374110.4A
Other languages
Chinese (zh)
Other versions
CN113032102A (en
Inventor
田帅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Huya Technology Co Ltd
Original Assignee
Guangzhou Huya Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Huya Technology Co Ltd filed Critical Guangzhou Huya Technology Co Ltd
Priority to CN202110374110.4A priority Critical patent/CN113032102B/en
Publication of CN113032102A publication Critical patent/CN113032102A/en
Application granted granted Critical
Publication of CN113032102B publication Critical patent/CN113032102B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The embodiment of the invention discloses a resource rescheduling method, a device, equipment and a medium. The method comprises the following steps: acquiring actual load data of each node in the cluster at regular time; if the high-load node and the low-load node exist according to the actual load data of each node, determining the POD to be rescheduled on the high-load node, and simulating and calculating a rescheduling result of the POD to be rescheduled; and if the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, expelling the POD to be rescheduled so as to realize that the POD to be rescheduled is redeployed in the cluster. The technical scheme balances the actual load of each node in the cluster and also ensures the rescheduling success rate for the evicted Pod as much as possible.

Description

Resource rescheduling method, device, equipment and medium
Technical Field
The embodiment of the invention relates to the technical field of computers, in particular to a resource rescheduling method, a device, equipment and a medium.
Background
Kubernetes is an open-source container cluster management system, provides functions such as application deployment, maintenance, expansion mechanisms and the like, and can conveniently manage cross-cluster running containerized applications by utilizing Kubernetes.
In Kubernetes cluster technology, nodes (nodes) represent host physical computers or virtual machine servers running in the Kubernetes cluster, providing the necessary computing resources for the container. Pod (container set) is used as the minimum scheduling unit of the Kubernetes cluster, and one Pod can contain one or more running containers, and the containers run on the same node and share the resources of the node.
The original Kube-scheduler (scheduling) component only performs optimal scheduling selection according to the current resource distribution condition of the cluster, and secondary scheduling is not performed on the resource condition after the subsequent resource change. The descheduler items of the community can periodically achieve the purpose of balancing the node resource allocation rate aiming at the node expelling part Pod with high allocation rate according to the current cluster resource distribution. However, the problem that the actual load of the node is not balanced by the descheduler nodes according to the resource allocation rate may occur, and the problem that the evicted Pod is rescheduled back to the original node and cannot be scheduled even in the scheduling queue may be caused.
Disclosure of Invention
The embodiment of the invention provides a resource rescheduling method, device, equipment and medium, which are used for balancing the actual load of each node in a cluster and simultaneously ensuring the rescheduling success rate for the evicted Pod as much as possible.
In a first aspect, an embodiment of the present invention provides a resource rescheduling method, including:
acquiring actual load data of each node in the cluster at regular time;
If the high-load node and the low-load node exist according to the actual load data of each node, determining the POD to be rescheduled on the high-load node, and simulating and calculating a rescheduling result of the POD to be rescheduled;
And if the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, expelling the POD to be rescheduled so as to realize that the POD to be rescheduled is redeployed in the cluster.
In a second aspect, an embodiment of the present invention further provides a resource rescheduling apparatus, including:
the actual load acquisition module is used for acquiring actual load data of each node in the cluster at fixed time;
The rescheduling result simulation module is used for determining a to-be-rescheduled POD on the high-load node and calculating the rescheduling result of the to-be-rescheduled POD in a simulation mode if the high-load node and the low-load node exist according to the actual load data of each node;
And the POD eviction module is used for evicting the POD to be rescheduled if the rescheduled result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, so as to realize that the POD to be rescheduled is redeployed in the cluster.
In a third aspect, an embodiment of the present invention further provides a computer apparatus, including:
one or more processors;
A memory for storing one or more programs,
The one or more programs, when executed by the one or more processors, cause the one or more processors to implement the resource rescheduling method as described in any of the embodiments.
In a fourth aspect, embodiments of the present invention further provide a computer readable storage medium having stored thereon a computer program, which when executed by a processor, implements the resource rescheduling method according to any of the embodiments.
In the technical scheme provided by the embodiment of the invention, the actual load data of each node in the cluster is obtained at fixed time, and when the high-load node and the low-load node exist in the cluster according to the actual load data, the POD to be rescheduled on the high-load node is determined to be evicted, so that the actual load of each node in the cluster is balanced, and the problem of overload of the high-load node can be avoided; meanwhile, before the POD to be rescheduled on the high-load node is evicted, the rescheduled result of the POD to be rescheduled is simulated and calculated, and the POD to be rescheduled is evicted only when the rescheduled result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node after being evicted, so that the rescheduled success rate of the POD to be rescheduled to the original high-load node after being evicted is ensured as much as possible, and the problem that the POD to be rescheduled to the original high-load node after being evicted even cannot be scheduled in a scheduling queue is avoided.
Drawings
FIG. 1 is a flowchart of a method for rescheduling resources according to a first embodiment of the present invention;
FIG. 2 is a flowchart of a resource rescheduling method according to a second embodiment of the present invention;
FIG. 3 is a flowchart of a resource rescheduling method according to a third embodiment of the present invention;
Fig. 4 is a schematic diagram of a system architecture to which the resource rescheduling method according to the third embodiment of the present invention is applied;
Fig. 5 is a schematic block diagram of a resource rescheduling device according to a fourth embodiment of the present invention;
fig. 6 is a schematic structural diagram of a computer device according to a fifth embodiment of the present invention.
Detailed Description
The invention is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting thereof. It should be noted that, for convenience of description, only some, but not all of the structures related to the present invention are shown in the drawings.
Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.
Example 1
Fig. 1 is a flowchart of a resource rescheduling method according to an embodiment of the present invention, where the embodiment is applicable to a situation of rescheduling Pod in Kubernetes cluster, and the method may be performed by a resource rescheduling apparatus according to any embodiment of the present invention, where the apparatus may be composed of hardware and/or software, and may be generally integrated in a computer device.
As shown in fig. 1, the resource rescheduling method provided in this embodiment includes the following steps:
S110, acquiring actual load data of each node in the cluster at fixed time.
Wherein, the cluster may refer to a Kubernetes cluster; nodes within a cluster may refer to computing nodes in the Kubernetes cluster other than the master node.
The actual load data may refer to load data monitored by a monitor of a monitoring system in the running process of each node in the cluster, and may include CPU load data, memory load data, disk load data, network load data, and the like. Optionally, the actual load data refers to actual CPU load data and/or actual memory load data. The actual load data is taken as actual CPU load data as an example for explanation.
The obtained actual CPU load data of each node may include actual CPU load data of each POD on the node in addition to the actual CPU load data of the node.
The actual load data of each node in the cluster is obtained at regular time according to the preset period, and then the load type of each node in the cluster can be judged according to the actual load data of each node.
And S120, if the high-load node and the low-load node exist according to the actual load data of each node, determining the POD to be rescheduled on the high-load node, and simulating and calculating the rescheduling result of the POD to be rescheduled.
After the actual load data of each node is acquired, the node load type of each node can be determined according to a preset node type dividing rule, and the node load type can comprise a low-load node and a high-load node or can comprise a low-load node, a high-load node and an overload node.
Optionally, the preset node type dividing rule may be determined according to the actual load rate of the node, so that the high-load node can be accurately positioned, and the problem that the node allocation rate is high but the high-load node is not actually caused by the fact that a container with a very high resource statement but a very low actual use rate exists in an actual production environment is overcome.
The actual load rate of the low-load node belongs to a first load rate interval, the actual load rate of the high-load node belongs to a second load rate interval, the actual load rate of the overload node belongs to a third load rate interval, the actual load rate value in the first load rate interval is smaller than the actual load rate value in the second load rate interval, and the actual load rate value in the second load rate interval is smaller than the actual load rate value in the third load rate interval.
For example, a node having an actual CPU load rate of 0 to 40% may be determined as a low load node, a node having an actual CPU load rate of 70% to 90% may be determined as a high load node, and a node having an actual CPU load rate of 90% or more may be determined as an overload node. Wherein the status identifications of the nodes of different load types are different.
As an alternative embodiment, a new component "node-controller" component may be introduced in the Kubernetes cluster for enabling determination of the load type of each node in the cluster. The node-controller component periodically pulls CPU load data of all nodes in the cluster through the monitoring system, and sets different load state identifiers (including a low load state identifier, a high load state identifier and an overload state identifier) for nodes in different load rate intervals so as to identify node load types of all nodes. Meanwhile, the node-controller component can also provide the inquiry function of the CPU load data of each Pod on the node.
For example, the node-controller component adds a low-load state identifier (such as cpuUnderload identifier) for the node with the actual CPU load rate between 0 and 40%, adds a high-load state identifier (such as cpuPressure identifier) for the node with the actual CPU load rate between 70 and 90%, and adds an overload state identifier (such as cpuoverPressure identifier) for the node with the actual CPU load rate greater than 90%.
Optionally, the node-controller component adds a high-load state identifier (such as cpuPressure identifier) to the node with the actual CPU load rate between 70% and 90%, and adds a high-load state identifier (such as cpuPressure identifier) and a stain rule (Taint) of the high-load state (cpuPressure) to the node with the actual CPU load rate greater than 90%. Wherein a node where Taint is present (i.e., an overloaded node) can avoid new POD scheduling.
When the high-load node and the low-load node exist in the cluster, for example, the load type of each node in the cluster can be determined through the load state identification of each node, the POD on the high-load node can be rescheduled to reduce the level of the load type of the node, and if the load type is adjusted to be the low-load node by the high-load node.
First, a strippable POD is selected as a POD to be rescheduled among all PODs on the high-load node. Among them, the strippable POD may refer to a POD that can be stripped from a node without affecting service availability. If there are multiple strippable PODs on the high-load node, the POD to be rescheduled may be determined therein according to a preset selection policy or in a random manner.
Then, rescheduling results are calculated for the simulation of the POD to be rescheduled. That is, the simulation calculation is performed according to the current resource distribution situation of the cluster, and the rescheduling result after the POD to be rescheduled is evicted is determined, for example, whether the POD to be rescheduled can be rescheduled, the load type (whether a low-load node or a high-load node) of the node that can be rescheduled, and the like.
S130, if the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, the POD to be rescheduled is evicted, so that the POD to be rescheduled is redeployed in the cluster.
After the rescheduling result of the POD to be rescheduled is calculated through simulation, if the rescheduling result indicates that the POD to be rescheduled is redeployed on the low-load node, that is, the POD to be rescheduled can be migrated to the low-load node when being rescheduled after being evicted, and the POD to be rescheduled is evicted, so that the POD to be rescheduled is redeployed in the cluster.
After the rescheduling result of the POD to be rescheduled is calculated through simulation, if the rescheduling result indicates that the POD to be rescheduled cannot be redeployed, or the POD to be rescheduled cannot be evicted when the POD to be rescheduled is migrated to the original high-load node.
In this embodiment, after the to-be-rescheduled POD is evicted, the scheduling component kube-scheduler of the Kubernetes cluster determines how to reschedule the to-be-rescheduled POD, that is, determines that the component that evicts the to-be-rescheduled POD cannot determine the rescheduling result of the to-be-rescheduled POD. Wherein kube-scheduler is one of the core components of the kubernetes control plane, responsible for scheduling and binding of container resources and hosts.
Therefore, before the to-be-rescheduled POD is evicted, the rescheduled result of the to-be-rescheduled POD is firstly calculated in a simulation mode, the to-be-rescheduled POD is evicted only when the rescheduled result indicates that the to-be-rescheduled POD is allowed to migrate to the low-load node, the node load level is not considered only, but also the rescheduled result is not considered, so that the rescheduled success rate of the to-be-rescheduled POD is ensured as much as possible, and the problem that the to-be-rescheduled POD is rescheduled to the original high-load node after being evicted, and even the to-be-scheduled in a scheduling queue is avoided.
As an alternative implementation, a new component "load-balancing control (balance-controller) component" may be introduced in the Kubernetes cluster to implement an operation of evicting the POD to be rescheduled on the high-load node in the cluster. The balance-controller component periodically acquires load types (i.e., low-load nodes, high-load nodes, and overload nodes) of all nodes in the cluster, for example, can acquire the load types of all nodes in the cluster through the components kube-apiserver, filter out the high-load nodes and the low-load nodes in the cluster, and simulate and calculate a rescheduling result of the POD to be rescheduled on the high-load nodes, and only when the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load nodes after the POD to be rescheduled is evicted, so that the purpose of balancing actual loads among the nodes in the cluster is achieved. Wherein kube-apiserver is one of the core components of the kubernetes control plane, and provides an add-delete-modify-check interface for all resource objects, including nodes (nodes), container Sets (PODs), copy controllers (REPLICASET), and the like. RELICASET is used to ensure that the copy number of the container application is always kept at the user-defined copy number, i.e. if there is a container that has been abnormally exited, a new POD will be automatically created to replace it, and if there are abnormally excessive containers will be automatically recovered, and provide functions such as declarative updating.
Optionally, the resource rescheduling method provided in this embodiment further includes: and if the existence of the overload node is determined according to the actual load data of each node, determining the POD to be rescheduled on the overload node, and expelling the POD to be rescheduled.
Wherein, an overloaded node may refer to a node where the actual load rate exceeds the load rate threshold (e.g., 90%) and a smudge rule is added. The taint rule (Taint), a scheduling policy provided by kubernetes, prevents nodes from being scheduled by a new Pod by putting Taint on them, and only pods tolerating Taint conditions can be scheduled.
For the POD to be rescheduled on the overload node, the POD to be rescheduled can be directly subjected to the expelling process, for example, the POD to be rescheduled can be determined on the overload node according to the service priority, and the POD to be rescheduled is directly subjected to the expelling process, so that the protection of the overload node is realized. Optionally, when the node-controller component determines that an overloaded node exists in the cluster, the node-controller component directly evicts the POD to be rescheduled on the overloaded node.
Further, the resource rescheduling method provided in this embodiment further includes, after expelling the POD to be rescheduled: and redeploying the POD to be rescheduled based on a preset low-load node preference strategy through a kube-schedule component.
The low-load node optimizing strategy refers to a strategy of adding an optimizing low-load node to perform rescheduling on the basis of a primary scheduling strategy.
In this embodiment, the scheduling policy of the component kube-scheduler may be adjusted by means of scheduler-extender, and a policy of rescheduling by a preferred low-load node is added on the basis of the native scheduling policy. Wherein, scheduler-extender is a mechanism provided by kube-scheduler to extend scheduling policies, allowing users to customize scheduling policies.
After expelling the POD to be rescheduled, the POD to be rescheduled is redeployed based on a preset low-load node optimization strategy through a kube-schedule component, and the POD to be rescheduled is preferentially redeployed to the low-load node, so that the purpose of balancing loads is achieved.
As an optional implementation manner of this embodiment, determining the POD to be rescheduled on the high-load node may specifically be: and determining one POD to be rescheduled on the high-load node.
In this embodiment, only one to-be-rescheduled POD on the high-load node is determined at a time, that is, only one to-be-rescheduled POD on the high-load node is evicted at a time, instead of evicting a plurality of to-be-rescheduled PODs on the high-load node, because:
in this embodiment, the components (e.g., the balance-controller) that expel the PODs to be rescheduled are not responsible for the scheduling of the PODs to be rescheduled, and all the PODs to be rescheduled by the kube-schedule after being evicted. Therefore, the components that evict the POD to be rescheduled cannot guarantee the rescheduling result of the evicted POD. If multiple PODs to be rescheduled are evicted, the rescheduled results of the analog computation may collide, and since the analog computation process of the rescheduled result for each POD to be rescheduled is independent, the analog rescheduled result for the previous POD to be rescheduled cannot be perceived, and the analog rescheduled result for the previous POD to be rescheduled cannot be determined to be realized (i.e., the node in the ideal node must be rescheduled).
Meanwhile, when performing simulation calculation on the rescheduling result of the POD to be rescheduled, the cluster may have errors in scheduling view of components (such as a balance-controller) and a scheduling component (kube-scheduler) of the POD to be rescheduled while the newly created POD is waiting for scheduling at the same time. Thus, expelling multiple to-be-rescheduled PODs only amplifies this potential error, resulting in the problem of too many to-be-rescheduled PODs being expelled, e.g., there is a probability that the to-be-rescheduled PODs continue to return to the high-load node after being expelled, if the low-load node is fully occupied by other PODs at the same time.
In addition, when one POD to be rescheduled on the high-load node is evicted, the high-load node may already enter the state of the normal node because of load reduction, and at this time, it is not necessary to evict too many PODs to increase the possibility of influencing the service.
In the technical scheme provided by the embodiment of the invention, the actual load data of each node in the cluster is obtained at fixed time, and when the high-load node and the low-load node exist in the cluster according to the actual load data, the POD to be rescheduled on the high-load node is determined to be evicted, so that the actual load of each node in the cluster is balanced, and the problem of overload of the high-load node can be avoided; meanwhile, before the POD to be rescheduled on the high-load node is evicted, the rescheduled result of the POD to be rescheduled is simulated and calculated, and the POD to be rescheduled is evicted only when the rescheduled result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node after being evicted, so that the rescheduled success rate of the POD to be rescheduled to the original high-load node after being evicted is ensured as much as possible, and the problem that the POD to be rescheduled to the original high-load node after being evicted even cannot be scheduled in a scheduling queue is avoided.
Example two
Fig. 2 is a flowchart of a resource rescheduling method provided by a second embodiment of the present invention, where the rescheduling result of the POD to be rescheduled is calculated by simulation, and may be specifically:
under the condition that the low-load node meeting the rescheduling condition of the POD to be rescheduled does not exist according to the current resource distribution of the cluster, simulating and calculating a resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled is evicted on the low-load node based on a preemption scheduling strategy;
and judging whether low-load nodes meeting the rescheduling condition of the POD to be rescheduled exist or not according to the resource distribution result.
As shown in fig. 2, the resource rescheduling method provided in this embodiment includes the following steps:
S210, acquiring actual load data of each node in the cluster at fixed time.
S220, if the fact that the high-load node and the low-load node exist is determined according to the actual load data of each node, determining the POD to be rescheduled on the high-load node.
Optionally, determining the POD to be rescheduled on the high-load node may specifically be: obtaining the strippable POD on the high-load node; and determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container.
The strippable POD refers to a POD that can be stripped on a node without affecting service availability. When judging whether each POD on the high-load node is a strippable POD, it may be judged whether the POD belongs to a stateless programming application (e.g., REPLICASET), and whether the stateless programming application belongs to an available copy greater than 1, if so, it is judged that the POD is a strippable POD, and if not, it is judged that the POD is not a strippable POD.
For a plurality of strippable PODs acquired on the high load node, the POD to be rescheduled on the high load node may be determined based on the priority and/or the actual load of the container. For example, in the case where the priorities are different, the POD to be rescheduled on the high-load node may be sequentially determined in order of low priority to high priority, or in the case where the priorities are the same, the POD to be rescheduled on the high-load node may be sequentially determined in order of high priority to low degree of influence of the actual load of the container on the actual load rate of the high-load node.
As an alternative embodiment, determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container may include: and taking the POD with the lowest priority in the strippable PODs as the POD to be rescheduled.
And sequencing the plurality of strippable PODs on the high-load node according to the priority, and taking the POD with the lowest priority as the POD to be rescheduled.
As another alternative embodiment, determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container may include: and taking the POD of which the actual load of the container in the strippable POD meets the node load degradation condition as the POD to be rescheduled.
The node load degradation condition refers to a condition for lowering the node load level, and may be, for example, a condition for adjusting the node from a high-load node to a normal node or a low-load node, or a condition for adjusting the node from an overload node to a high-load node or a normal node or a low-load node.
And aiming at a plurality of strippable PODs on the high-load node, acquiring the actual load of each strippable POD, judging whether the node load degradation condition is met or not according to the actual load of each strippable POD so as to enable the node load level of the high-load node to be reduced, and if so, determining the node load level as the POD to be rescheduled.
As yet another alternative embodiment, determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container may further include: and taking the POD with the lowest priority and the actual load of the container meeting the node load degradation condition as the POD to be rescheduled.
And aiming at the plurality of strippable PODs on the high-load node, sequencing the strippable PODs according to the priority, simultaneously acquiring the actual load of each strippable POD, judging whether the node load degradation condition is met according to the actual load of each strippable POD to enable the node load level of the high-load node to be reduced, and further enabling the POD with the lowest priority and the actual load of the container meeting the node load degradation condition to be used as the POD to be rescheduled.
And S230, under the condition that the fact that no low-load node meeting the rescheduling condition of the POD to be rescheduled exists is determined according to the current resource distribution of the cluster, simulating and calculating a resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled is evicted on the low-load node based on a preemption scheduling strategy.
And after determining the POD to be rescheduled, calculating a rescheduling result of the POD to be rescheduled according to the current resource distribution simulation of the cluster.
Judging whether low-load nodes meeting the rescheduling conditions of the PODs to be rescheduled exist according to the current resource distribution of the clusters, if so, the rescheduling results of the PODs to be rescheduled can indicate that the PODs to be rescheduled are allowed to be migrated to the low-load nodes, and if not, the resource distribution results of the clusters on the low-load nodes, corresponding to the PODs to be rescheduled, after the PODs to be preempted are evicted, need to be calculated based on the preemptive scheduling strategy simulation.
The low-load node meeting the condition of rescheduling the POD to be rescheduled means that the idle resources of the low-load node meet the resources required for deploying the POD to be rescheduled.
Preemptive scheduling policy refers to kubernetes native preemptive scheduling policy.
When judging that the low-load node meeting the rescheduling condition of the POD to be rescheduled does not exist according to the current resource distribution of the cluster, continuously simulating and calculating the resource distribution result of the pre-rescheduled POD for the POD with the priority lower than that of the pre-loaded node on the low-load node, and expelling the pre-empted POD on the corresponding low-load node.
S240, judging whether a low-load node meeting the POD rescheduling condition to be rescheduled exists according to the resource distribution result, if so, executing S250, and if not, executing S220.
After the resource distribution result is obtained based on the preemptive scheduling policy simulation calculation, whether the low-load node meeting the rescheduling condition of the POD to be rescheduled exists or not can be continuously judged according to the resource distribution result, if yes, the step S250 of executing the expelling operation of the POD to be rescheduled can be executed, if not, the POD to be rescheduled cannot be expelled, the POD to be rescheduled needs to be determined again, and the judgment flow of the steps S230-S240 is continuously executed.
S250, expelling the POD to be rescheduled so as to realize that the POD to be rescheduled is redeployed in the cluster.
It should be noted that the flow provided in this embodiment is for the same high-load node, and is also for other high-load node flows. The present embodiment is not explained in detail herein, and reference is made to the foregoing embodiments.
According to the technical scheme, on the premise of not affecting the service, the proportion of high-load nodes and low-load nodes in the cluster is effectively reduced, and the effect of balancing the load among the nodes is achieved; the rescheduling result of the PODs to be rescheduled is simulated and calculated based on the preemptive scheduling strategy, so that the fact that the evicted PODs can be redeployed through preemptive scheduling as much as possible is guaranteed, instead of simply evicting all PODs meeting the conditions, and the strategy of resource rescheduling to balance loads among nodes is further refined.
Example III
Fig. 3 is a flowchart of a resource rescheduling method provided in a third embodiment of the present invention, where a specific implementation manner is provided based on the foregoing embodiment, and a node-controller component and a balance-controller component are introduced in the present embodiment.
The node-controller component periodically pulls CPU load data of all nodes in the cluster through the monitoring system, and sets different load state identifiers (including a low load state identifier, a high load state identifier and an overload state identifier) for nodes in different load rate intervals so as to identify node load types of all nodes. Meanwhile, the node-controller component can also provide the inquiry function of the CPU load data of each Pod on the node. In addition, when overload nodes exist in the cluster, the node-controller component can expel partial PODs on the overload nodes according to service priorities so as to achieve the purpose of protecting the host nodes.
Optionally, according to a predefined load interval, the node-controller component adds a low-load state identifier (cpuUnderload identifier) to a node with an actual CPU load rate between 0% and 40%, adds a high-load state identifier (such as cpuPressure identifier) to a node with an actual CPU load rate between 70% and 90%, and adds a high-load state identifier (such as cpuPressure identifier) and a stain rule (Taint) of a high-load state (cpuPressure) to a node with an actual CPU load rate greater than 90%. Wherein a node where Taint is present (i.e., an overloaded node) can avoid new POD scheduling.
The balance-controller component periodically acquires load types of all nodes in the cluster (i.e., low-load nodes, high-load nodes and overload nodes), for example, can acquire the load types of all nodes in the cluster through the components kube-apiserver, filters out the high-load nodes and the low-load nodes in the cluster, and calculates a rescheduling result according to the to-be-rescheduled POD on the high-load nodes, and only when the rescheduling result indicates that the to-be-rescheduled POD is allowed to be migrated to the low-load nodes after being evicted, the to-be-rescheduled POD is evicted, namely, a container instance on the high-load node is evaluated, and when the low-load nodes suitable for migration exist, the corresponding container instance on the high-load node is evicted, so that the purpose of balancing the actual load among the nodes in the cluster is achieved.
As shown in fig. 3, the resource rescheduling method provided in this embodiment includes the following steps:
And S310, periodically acquiring actual load data of each node in the cluster through a node-controller component, and adding a state identifier according to the actual load data to update the load type of the corresponding node.
Referring to fig. 4, the node-controller component periodically pulls load monitoring data of each node in the cluster through a monitor of the monitoring system, and according to a predefined load interval, identifies three example nodes (with cpu usage rates of 30%, 75% and 90% respectively) in fig. 4 as low-load nodes (cpuPressure id), high-load nodes (cpuPressure id) and overload nodes (cpuPressure id+taint rule) respectively, and updates the load type of the corresponding node while caching the latest node monitoring data. Alternatively, the identification of the low-load node may be obtained by the policy-controller component and then used to identify the node.
S320, if the overload node exists, the node-controller component drives out part of PODs on the overload node according to the service priority.
And S330, determining the POD to be rescheduled on the high-load node by the balance-controller component when the high-load node and the low-load node exist according to the node load type periodically.
The policy-controller component may obtain a node list and a POD list on each node in the master node.
And S340, under the condition that the fact that no low-load node meeting the POD rescheduling condition to be rescheduled exists is determined according to the current resource distribution of the cluster, simulating and calculating a resource distribution result of the cluster on the low-load node after the POD to be preempted corresponding to the POD to be rescheduled is evicted based on a preemption scheduling policy by a policy-controller component.
And S350, judging whether a low-load node meeting the POD rescheduling condition to be rescheduled exists or not through a balance-controller component according to the resource distribution result, if so, executing S360, and if not, executing S330.
Referring to FIG. 4, the policy-controller component periodically pulls state data for all nodes through the kube-apiserver component, filtering out high-load nodes and low-load nodes according to node load type. When the low-load node and the high-load node exist at the same time, the latest cached node monitoring data is pulled through an interface provided by the node-controller component, and whether the Pod on the high-load node has migration conditions is evaluated.
Firstly, judging whether the Pod on the high-load node belongs to REPLICASET such stateless programming application and whether the attached REPLICASET has an available copy larger than 1, if so, determining the Pod as the POD to be rescheduled, thereby ensuring that the operation of balanced rescheduling does not influence the service availability.
And secondly, judging whether one POD to be rescheduled has migration conditions or not at a time.
Specifically, for one POD to be rescheduled, whether a low-load node meeting the POD rescheduling condition to be rescheduled exists is judged according to the current resource distribution of the cluster, if yes, the POD to be rescheduled has a migration condition, S360 is executed to expel the POD to be rescheduled on a high-load node, if no, a resource distribution result of the cluster on the low-load node corresponding to the POD to be rescheduled after the POD to be preempted is simulated and calculated based on a preemptive scheduling policy, and whether a low-load node meeting the POD rescheduled condition to be rescheduled exists is continuously judged according to the resource distribution result, if yes, the POD to be rescheduled has a migration condition, S360 is executed to expel the POD to be rescheduled on the high-load node, and if no, judgment on whether the POD to be rescheduled has the migration condition is continued to be performed for the next POD to be rescheduled. If all the PODs to be rescheduled do not have the migration condition, the process is ended.
When performing the operation of simulating and calculating the resource distribution result of the cluster on the low-load node after the to-be-preempted POD corresponding to the to-be-preempted POD is evicted and continuously judging whether the low-load node meeting the to-be-preempted POD rescheduling condition exists according to the resource distribution result, traversing the list of the low-load node according to the kubernetes native preemptive scheduling strategy, performing preemptive simulation on the POD (which can be marked as the to-be-preempted POD) with the priority (PriorityClass) lower than the to-be-preempted POD on the low-load node, determining the resource distribution result after the to-be-preempted POD is evicted, and judging whether the low-load node meeting the to-be-preempted POD rescheduling condition exists according to the resource distribution result, and determining that the to-be-preempted POD has the migration condition when at least one low-load node meeting the to-be-preempted POD rescheduling condition exists.
Referring to fig. 4, P5, P6, P7, and P8 of the POD suffix are service priorities (PriorityClass) of PODs, and the primary kubernetes performs preemptive scheduling according to PriorityClass, and the core idea of the policy-controller component is to select stateless services on the high-load node in advance to perform simulation calculation of preemptive scheduling, so as to determine whether to expel the corresponding POD according to a rescheduling result obtained by the simulation calculation.
And S360, expelling the POD to be rescheduled through a balance-controller component.
It should be noted that the to-be-rescheduled POD flooding on the high-load node is evicted by the policy-controller component, while the POD on the overloaded node is evicted directly by the node-controller component.
And S370, redeploying the POD to be rescheduled based on a preset low-load node optimization strategy through a kube-schedule component.
The optimized strategy of the low-load node is added to the kube-schedule component in a schedule-extender mode, namely the kube-schedule component can preferentially select the low-load node to schedule, and the evicted POD can preferentially schedule to the low-load node, so that the aim of balancing loads is achieved.
In the example shown in fig. 4, after pod_p5 in the high-load node (original CPU actual usage is 75%) and pod_p5 in the overloaded node (original CPU actual usage is 90% and a stain rule is added) are evicted, a very high probability can be redeployed on the low-load node (original CPU actual usage is 30%).
The present embodiment is not explained in detail herein, and reference is made to the foregoing embodiments.
According to the technical scheme provided by the embodiment, the node-controller component and the balance-controller component work periodically, the node-controller component continuously marks the latest node load type, the balance-controller component continuously carries out simulation calculation on balanced migration of high-load nodes, and the POD to be rescheduled which is feasible in calculation is evicted, so that the proportion of the high-load nodes and the low-load nodes in the cluster is effectively reduced, and the effect of balancing the high-load nodes and the low-load nodes is achieved; meanwhile, the rescheduling result of the POD to be rescheduled is simulated and calculated based on the preemption scheduling strategy, so that the fact that the evicted POD can be redeployed through preemption scheduling as far as possible is guaranteed, instead of simply evicting all PODs meeting the conditions, the low-load nodes are preferentially scheduled through the expanded scheduling strategy, and the strategy of rescheduling resources to balance loads among the nodes is further refined.
Example IV
Fig. 5 is a schematic block diagram of a resource rescheduling device according to a fourth embodiment of the present invention, where the embodiment is applicable to a situation of rescheduling Pod in a Kubernetes cluster, and the device may be implemented in a software and/or hardware manner and may be generally integrated in a computer device.
As shown in fig. 5, the resource rescheduling apparatus provided in this embodiment specifically includes: an actual load acquisition module 410, a rescheduling result simulation module 420, and a POD eviction module 430. Wherein,
An actual load obtaining module 410, configured to obtain actual load data of each node in the cluster at regular time;
the rescheduling result simulation module 420 is configured to determine a to-be-rescheduled POD on the high-load node if it is determined that there are a high-load node and a low-load node according to actual load data of the nodes, and simulate and calculate a rescheduling result of the to-be-rescheduled POD;
the POD eviction module 430 is configured to evict the POD to be rescheduled if the rescheduled result indicates that the POD to be rescheduled is allowed to migrate onto the low-load node, so as to implement that the POD to be rescheduled is redeployed in the cluster.
In the technical scheme provided by the embodiment of the invention, the actual load data of each node in the cluster is obtained at fixed time, and when the high-load node and the low-load node exist in the cluster according to the actual load data, the POD to be rescheduled on the high-load node is determined to be evicted, so that the actual load of each node in the cluster is balanced, and the problem of overload of the high-load node can be avoided; meanwhile, before the POD to be rescheduled on the high-load node is evicted, the rescheduled result of the POD to be rescheduled is simulated and calculated, and the POD to be rescheduled is evicted only when the rescheduled result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node after being evicted, so that the rescheduled success rate of the POD to be rescheduled to the original high-load node after being evicted is ensured as much as possible, and the problem that the POD to be rescheduled to the original high-load node after being evicted even cannot be scheduled in a scheduling queue is avoided.
Optionally, the rescheduling result simulation module 420 is specifically configured to, when it is determined that there is no low-load node that satisfies the rescheduling condition of the POD to be rescheduled according to the current resource distribution of the cluster, simulate and calculate, based on a preemption scheduling policy, a resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled is evicted on the low-load node; and judging whether low-load nodes meeting the rescheduling condition of the POD to be rescheduled exist or not according to the resource distribution result.
Optionally, the rescheduling result simulation module 420 is specifically configured to obtain a peelable POD on the high-load node; and determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container.
Further, the rescheduling result simulation module 420 is specifically configured to take the POD with the lowest priority in the peelable PODs as the POD to be rescheduled; or alternatively
Taking the POD of which the actual load of the container in the strippable POD meets the node load degradation condition as the POD to be rescheduled; or alternatively
And taking the POD with the lowest priority and the actual load of the container meeting the node load degradation condition as the POD to be rescheduled.
On the basis of the above technical solution, the resource rescheduling device further includes: and the rescheduling module is used for redeploying the POD to be rescheduled based on a preset low-load node optimization strategy through a kube-schedule component after the POD to be rescheduled is evicted.
Optionally, the rescheduling result simulation module 420 is specifically configured to determine a POD to be rescheduled on the high-load node.
Optionally, the resource rescheduling device further includes: and the overload node POD expelling module is used for determining the POD to be rescheduled on the overload node and expelling the POD to be rescheduled if the overload node exists according to the actual load data of each node.
The resource rescheduling device provided by the embodiment of the invention can execute the resource rescheduling method provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
Example five
Fig. 6 is a schematic structural diagram of a computer device according to a fifth embodiment of the present invention, and as shown in fig. 6, the computer device includes a processor 50, a memory 51, an input device 52, and an output device 53; the number of processors 50 in the computer device may be one or more, one processor 50 being taken as an example in fig. 6; the processor 50, the memory 51, the input means 52 and the output means 53 in the computer device may be connected by a bus or by other means, in fig. 6 by way of example.
The memory 51 is a computer readable storage medium, and may be used to store a software program, a computer executable program, and modules, such as program instructions/modules corresponding to the resource rescheduling method in the embodiment of the present invention (for example, the actual load acquisition module 410, the rescheduling result simulation module 420, and the POD eviction module 430 in the resource rescheduling apparatus in fig. 5). The processor 50 executes various functional applications of the computer device and data processing, i.e., implements the resource rescheduling method described above, by running software programs, instructions and modules stored in the memory 51.
The memory 51 may mainly include a memory program area that may store an operating system, at least one application program required for functions, and a memory data table area; the stored data table area may store data created according to the use of the computer device, etc. In addition, memory 51 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some examples, memory 51 may further comprise memory located remotely from processor 50, which may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The input device 52 is operable to receive input numeric or character information and to generate key signal inputs related to user settings and function control of the computer apparatus. The output means 53 may comprise a display device such as a display screen.
Example six
A sixth embodiment of the present invention also provides a computer-readable storage medium storing a computer program which, when executed by a computer processor, is configured to perform a resource rescheduling method, the method comprising:
acquiring actual load data of each node in the cluster at regular time;
If the high-load node and the low-load node exist according to the actual load data of each node, determining the POD to be rescheduled on the high-load node, and simulating and calculating a rescheduling result of the POD to be rescheduled;
And if the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, expelling the POD to be rescheduled so as to realize that the POD to be rescheduled is redeployed in the cluster.
Of course, the computer readable storage medium storing the computer program provided by the embodiments of the present invention is not limited to the above method operations, and may also perform the related operations in the resource rescheduling method provided by any embodiment of the present invention.
From the above description of embodiments, it will be clear to a person skilled in the art that the present invention may be implemented by means of software and necessary general purpose hardware, but of course also by means of hardware, although in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a computer readable storage medium, such as a floppy disk, a read-only memory (ROM), a random access memory (Random Access Memory, RAM), a FLASH memory (FLASH), a hard disk, or an optical disk of a computer, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method of the embodiments of the present invention.
It should be noted that, in the embodiment of the resource rescheduling device, each unit and module included are only divided according to the functional logic, but are not limited to the above-mentioned division, so long as the corresponding functions can be implemented; in addition, the specific names of the functional units are also only for distinguishing from each other, and are not used to limit the protection scope of the present invention.
Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.

Claims (9)

1. A method for rescheduling resources, comprising:
acquiring actual load data of each node in the cluster at regular time;
If the high-load node and the low-load node exist according to the actual load data of each node, determining a to-be-rescheduled container set POD on the high-load node, and simulating and calculating a rescheduling result of the to-be-rescheduled POD;
If the rescheduling result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, the POD to be rescheduled is evicted, so that the POD to be rescheduled is redeployed in the cluster;
the simulation calculation of the rescheduling result of the POD to be rescheduled comprises the following steps:
under the condition that the low-load node meeting the rescheduling condition of the POD to be rescheduled does not exist according to the current resource distribution of the cluster, simulating and calculating a resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled is evicted on the low-load node based on a preemption scheduling strategy;
Judging whether low-load nodes meeting the rescheduling conditions of the POD to be rescheduled exist or not according to the resource distribution result;
The method for simulating and calculating the resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled on the low-load node is evicted based on the preemptive scheduling strategy comprises the following steps:
And when judging that the low-load node meeting the rescheduling condition of the POD to be rescheduled does not exist according to the current resource distribution of the cluster, continuing to simulate and calculate the resource distribution result of the pre-rescheduled POD for the POD with the priority lower than that of the pre-loaded node on the low-load node, and expelling the pre-empted POD on the corresponding low-load node.
2. The method of claim 1, wherein determining the to-be-rescheduled POD on the high-load node comprises:
obtaining the strippable POD on the high-load node;
and determining the POD to be rescheduled on the high-load node according to the priority of the strippable POD and/or the actual load of the container.
3. The method of claim 2, wherein determining the POD to be rescheduled on the high load node based on the priority of the strippable POD and/or the actual load of the container comprises:
Taking the POD with the lowest priority in the strippable PODs as the POD to be rescheduled; or alternatively
Taking the POD of which the actual load of the container in the strippable POD meets the node load degradation condition as the POD to be rescheduled; or alternatively
And taking the POD with the lowest priority and the actual load of the container meeting the node load degradation condition as the POD to be rescheduled.
4. The method of claim 1, further comprising, after evicting the POD to be rescheduled:
And redeploying the POD to be rescheduled based on a preset low-load node preference strategy through a kube-schedule component.
5. The method of claim 1, wherein determining the to-be-rescheduled POD on the high-load node comprises:
and determining one POD to be rescheduled on the high-load node.
6. The method as recited in claim 1, further comprising:
And if the existence of the overload node is determined according to the actual load data of each node, determining the POD to be rescheduled on the overload node, and expelling the POD to be rescheduled.
7. A resource rescheduling apparatus, comprising:
the actual load acquisition module is used for acquiring actual load data of each node in the cluster at fixed time;
The rescheduling result simulation module is used for determining a to-be-rescheduled POD on the high-load node and calculating the rescheduling result of the to-be-rescheduled POD in a simulation mode if the high-load node and the low-load node exist according to the actual load data of each node;
a POD eviction module, configured to evict the POD to be rescheduled if the rescheduled result indicates that the POD to be rescheduled is allowed to be migrated to the low-load node, so as to implement that the POD to be rescheduled is redeployed in the cluster;
The rescheduling result simulation module is specifically configured to simulate and calculate, based on a preemption scheduling policy, a resource distribution result of the cluster after the to-be-preempted POD corresponding to the to-be-rescheduled POD is evicted on the low-load node, when it is determined that there is no low-load node satisfying the to-be-rescheduled POD rescheduling condition according to the current resource distribution of the cluster; judging whether low-load nodes meeting the rescheduling conditions of the POD to be rescheduled exist or not according to the resource distribution result;
The method for simulating and calculating the resource distribution result of the cluster after the POD to be preempted corresponding to the POD to be rescheduled on the low-load node is evicted based on the preemptive scheduling strategy comprises the following steps:
And when judging that the low-load node meeting the rescheduling condition of the POD to be rescheduled does not exist according to the current resource distribution of the cluster, continuing to simulate and calculate the resource distribution result of the pre-rescheduled POD for the POD with the priority lower than that of the pre-loaded node on the low-load node, and expelling the pre-empted POD on the corresponding low-load node.
8. A computer device, the computer device comprising:
one or more processors;
A memory for storing one or more programs,
When executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-6.
9. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-6.
CN202110374110.4A 2021-04-07 2021-04-07 Resource rescheduling method, device, equipment and medium Active CN113032102B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110374110.4A CN113032102B (en) 2021-04-07 2021-04-07 Resource rescheduling method, device, equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110374110.4A CN113032102B (en) 2021-04-07 2021-04-07 Resource rescheduling method, device, equipment and medium

Publications (2)

Publication Number Publication Date
CN113032102A CN113032102A (en) 2021-06-25
CN113032102B true CN113032102B (en) 2024-04-19

Family

ID=76454032

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110374110.4A Active CN113032102B (en) 2021-04-07 2021-04-07 Resource rescheduling method, device, equipment and medium

Country Status (1)

Country Link
CN (1) CN113032102B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113553140B (en) * 2021-09-17 2022-03-18 阿里云计算有限公司 Resource scheduling method, equipment and system
CN113835840A (en) * 2021-09-28 2021-12-24 广东浪潮智慧计算技术有限公司 Cluster resource management method, device and equipment and readable storage medium
CN114466019B (en) * 2022-04-11 2022-09-16 阿里巴巴（中国）有限公司 Distributed computing system, load balancing method, device and storage medium

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103677958A (en) * 2013-12-13 2014-03-26 华为技术有限公司 Virtualization cluster resource scheduling method and device
CN109656716A (en) * 2018-12-13 2019-04-19 郑州云海信息技术有限公司 A kind of Slurm job scheduling method and system
CN110515730A (en) * 2019-08-22 2019-11-29 北京宝兰德软件股份有限公司 Resource secondary dispatching method and device based on kubernetes container arranging system
CN110727512A (en) * 2019-09-30 2020-01-24 星环信息科技（上海）有限公司 Cluster resource scheduling method, device, equipment and storage medium
CN110780998A (en) * 2019-09-29 2020-02-11 武汉大学 Kubernetes-based dynamic load balancing resource scheduling method
CN110851236A (en) * 2019-11-11 2020-02-28 星环信息科技（上海）有限公司 Real-time resource scheduling method and device, computer equipment and storage medium
CN111399989A (en) * 2020-04-10 2020-07-10 中国人民解放军国防科技大学 Task preemption scheduling method and system for container cloud
CN111694633A (en) * 2020-04-14 2020-09-22 新华三大数据技术有限公司 Cluster node load balancing method and device and computer storage medium
CN112181605A (en) * 2020-10-27 2021-01-05 北京城市网邻信息技术有限公司 Load balancing method and device, electronic equipment and computer readable medium

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103677958A (en) * 2013-12-13 2014-03-26 华为技术有限公司 Virtualization cluster resource scheduling method and device
CN109656716A (en) * 2018-12-13 2019-04-19 郑州云海信息技术有限公司 A kind of Slurm job scheduling method and system
CN110515730A (en) * 2019-08-22 2019-11-29 北京宝兰德软件股份有限公司 Resource secondary dispatching method and device based on kubernetes container arranging system
CN110780998A (en) * 2019-09-29 2020-02-11 武汉大学 Kubernetes-based dynamic load balancing resource scheduling method
CN110727512A (en) * 2019-09-30 2020-01-24 星环信息科技（上海）有限公司 Cluster resource scheduling method, device, equipment and storage medium
CN110851236A (en) * 2019-11-11 2020-02-28 星环信息科技（上海）有限公司 Real-time resource scheduling method and device, computer equipment and storage medium
CN111399989A (en) * 2020-04-10 2020-07-10 中国人民解放军国防科技大学 Task preemption scheduling method and system for container cloud
CN111694633A (en) * 2020-04-14 2020-09-22 新华三大数据技术有限公司 Cluster node load balancing method and device and computer storage medium
CN112181605A (en) * 2020-10-27 2021-01-05 北京城市网邻信息技术有限公司 Load balancing method and device, electronic equipment and computer readable medium

Also Published As

Publication number Publication date
CN113032102A (en) 2021-06-25

Similar Documents

Publication Publication Date Title
CN113032102B (en) Resource rescheduling method, device, equipment and medium
US10733026B2 (en) Automated workflow selection
US20200287961A1 (en) Balancing resources in distributed computing environments
CN111694633A (en) Cluster node load balancing method and device and computer storage medium
CN111966500B (en) Resource scheduling method and device, electronic equipment and storage medium
EP3507692B1 (en) Resource oversubscription based on utilization patterns in computing systems
CN111381950A (en) Task scheduling method and system based on multiple copies for edge computing environment
US10795735B1 (en) Method and apparatus for load balancing virtual data movers between nodes of a storage cluster
CN110389843B (en) Service scheduling method, device, equipment and readable storage medium
CN104679594B (en) A kind of middleware distributed computing method
CN110221920B (en) Deployment method, device, storage medium and system
CN111104227B (en) Resource control method and device of K8s platform and related components
CN112269641A (en) Scheduling method, scheduling device, electronic equipment and storage medium
US11220688B2 (en) Oversubscription scheduling
CN108376103A (en) A kind of the equilibrium of stock control method and server of cloud platform
CN111767145A (en) Container scheduling system, method, device and equipment
CN117331668A (en) Job scheduling method, device, equipment and storage medium
CN113626173A (en) Scheduling method, device and storage medium
CN112214288B (en) Pod scheduling method, device, equipment and medium based on Kubernetes cluster
US20230037293A1 (en) Systems and methods of hybrid centralized distributive scheduling on shared physical hosts
CN113051063B (en) Task scheduling method and device for distributed tasks and electronic equipment
Jiang et al. Multi-prediction based scheduling for hybrid workloads in the cloud data center
CN110297692B (en) Distributed software task dynamic management method and system
CN113127289A (en) Resource management method based on YARN cluster, computer equipment and storage medium
Guo et al. A Task Priority-based Resource Scheduling Algorithm for Container-based Clouds

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant