Method and system for improving node resource utilization and load balancing of kubernetes

Abstract

The present invention provides a method and system for improving the node resource utilization rate of Kubernetes and balancing the load, comprising: step S1: obtaining the kube-apiserver version supported by the cluster through configuration creation of a client connected to the cluster, and judging whether the cluster supports expulsion; step S2: the verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory to obtain relevant information of the cluster; step S3: using a pod selector component to filter out pods for dynamic distribution adjustment; step S4: based on the filtered pods capable of dynamic distribution adjustment, obtaining a mapping relationship of pod-node; step S5: executing strategies in sequence according to a configuration file according to the obtained mapping relationship of pod-node, thereby obtaining an expulsion and reconstruction result; step S6: rebuilding the pod, and the cluster scheduler kube-scheduler redeploys the reconstructed pod to a preset node; performing cyclic monitoring according to the interval interval in the configuration parameter, repeatedly triggering steps S3 to S6, and dynamically adjusting the pod distribution in the cluster, thereby balancing the cluster load and adjusting the balance.

Description

Technical Field

[0001] The present invention relates to the technical field of resource allocation, and in particular to a method and system for improving node resource utilization and load balancing of Kubernetes. Background Art

[0002] In the current Kubernetes cluster, the official scheduling solution is to find the most suitable node at the current time point to deploy the pod, but once the pod is scheduled and bound to the node, it will not be rescheduled. Even if the cluster has problems such as load imbalance and affinity mismatch after a period of time.

[0003] The present invention realizes pod rescheduling by expelling rebuildable pods, thereby solving the problem that once a pod is bound in a Kubernetes cluster, the node will not trigger rescheduling. As the cluster changes dynamically, cluster nodes may experience load imbalance, affinity mismatch and other problems after a period of time. Summary of the invention

[0004] In view of the defects in the prior art, the object of the present invention is to provide a method and system for improving the node resource utilization and load balancing of Kubernetes.

[0005] A method for improving node resource utilization and load balancing of Kubernetes provided by the present invention includes:

[0006] Step S1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, and determine whether the cluster supports eviction. If not, exit directly;

[0007] Step S2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains relevant information about the cluster;

[0008] Step S3: Use the pod selector component to filter out pods for dynamic distribution adjustment;

[0009] Step S4: Based on the selected pods that can be dynamically distributed and adjusted, the pod-node mapping relationship is obtained according to the obtained cluster related information;

[0010] Step S5: According to the obtained pod-node mapping relationship, the policies are executed in sequence according to the configuration file to obtain the eviction and reconstruction result;

[0011] Step S6: Rebuild the pod, and the cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node; perform cyclic monitoring according to the interval in the configuration parameter, repeatedly trigger steps S3 to S6, and dynamically adjust the pod distribution in the cluster to balance the cluster load and adjust the balance;

[0012] The cluster related information includes information about each node in the cluster and information about pods on each node.

[0013] Preferably, the step S3 adopts:

[0014] Step S3.1: Get the namespace parameter in the configuration and determine whether the namespace parameter is empty; when the namespace parameter is empty, get the pods in all namespaces except the kubernetes system namespace under the namespace parameter from the cache of sharedInformerFactory; when the namespace parameter is not empty, get the pods in all namespaces under the namespace parameter from the cache of sharedInformerFactory;

[0015] Step S3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the acquired namespaces are dynamically distributed and adjusted; when the priorityThreshold parameter is not empty, the pods in all the acquired namespaces are traversed, and the pods with a priority greater than the priorityThreshold are removed, and the remaining pods are dynamically distributed and adjusted.

[0016] Preferably, the execution strategy includes: one or more of a LoadBalancing strategy component, an Affinity strategy component, and a ReCreate strategy component.

[0017] Preferably, the LoadBalancing strategy component is implemented by:

[0018] Step S5.1: remove the pods whose status is success and fail, and obtain the remaining pods;

[0019] Step S5.2: Get the relevant information of the nodes where the remaining pods are located from the sharedInformerFactory cache;

[0020] Step S5.3: Calculate the cpurequest percentage NodeCpuRequestPercent and the memoryrequest percentage NodeMemoryRequestPercent for each node;

[0021] Step S5.4: Calculate the average value of the cpurequest ratio AvgNodesCpuRequest for all nodes and the average value of the memoryrequest ratio AvgNodesMemoryRequest for all nodes;

[0022] Step S5.5: Use the policy configuration parameters cputhresholds and memorythresholds to determine low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds;

[0023] Step S5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to determine high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds;

[0024] Step S5.7: Calculate the average value of the cpurequest AvgPodCpu and the average value of the memoryrequest AvgPodMemory for all pods of high-load nodes in the node;

[0025] Step S5.8: Determine whether each pod of the corresponding node is to be evicted based on the average value of the cpurequest and the average value of the memoryrequest of all pods of high-load nodes. For a pod to be evicted, cpurequest > AvgPodCpu and / or memoryrequest > AvgPodMemory;

[0026] Step S5.9: Use the node selector component to filter low-load nodes, and determine whether the pod is deployed on the low-load node based on pod affinity, node affinity, and stains, and whether it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, the current pod will be evicted, otherwise it will not be evicted.

[0027] Preferably, the Affinity strategy component adopts: respectively judging whether the pods in all acquired namespaces satisfy the pod affinity, node affinity and stains; when the pod does not satisfy the pod affinity and / or node affinity, using the node selector component to screen nodes satisfying the pod affinity and node affinity in the cluster to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted.

[0028] Preferably, the ReCreate policy component adopts: judging whether the existence time of the pods in all the acquired namespaces exceeds the maxPodLifeTimeSeconds in the policy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

[0029] A system for improving node resource utilization and balancing load of Kubernetes provided by the present invention includes:

[0030] Module M1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, determine whether the cluster supports eviction, and exit directly if it does not support eviction;

[0031] Module M2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains cluster-related information;

[0032] Module M3: Use the pod selector component to filter out pods for dynamic distribution adjustment;

[0033] Module M4: Based on the selected pods that can be dynamically distributed and adjusted, the pod-node mapping relationship is obtained according to the obtained cluster-related information;

[0034] Module M5: Based on the obtained pod-node mapping relationship, the policies are executed in sequence according to the configuration files to obtain the eviction and reconstruction results;

[0035] Module M6: rebuilds the pod. The cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node. It performs cyclic monitoring according to the interval in the configuration parameters, repeatedly triggers modules M3 to M6, and dynamically adjusts the distribution of pods in the cluster to balance the cluster load and adjust the balance.

[0036] The cluster related information includes information about each node in the cluster and information about pods on each node.

[0037] Preferably, the module M3 adopts:

[0038] Module M3.1: Get the namespace parameter in the configuration and determine whether the namespace parameter is empty; when the namespace parameter is empty, get the pods in all namespaces except the kubernetes system namespace under the namespace parameter from the cache of sharedInformerFactory; when the namespace parameter is not empty, get the pods in all namespaces under the namespace parameter from the cache of sharedInformerFactory;

[0039] Module M3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the namespaces are dynamically distributed; when the priorityThreshold parameter is not empty, the pods in all the namespaces are traversed, and the pods with a priority greater than priorityThreshold are removed, and the remaining pods are dynamically distributed.

[0040] Preferably, the execution strategy includes: one or more of a LoadBalancing strategy component, an Affinity strategy component, and a ReCreate strategy component.

[0041] Preferably, the LoadBalancing strategy component is implemented by:

[0042] Module M5.1: Remove the pods with success and fail status and get the remaining pods;

[0043] Module M5.2: Obtain relevant information about the nodes where the remaining pods are located from the cache of the sharedInformerFactory;

[0044] Module M5.3: Calculate the NodeCpuRequestPercent of the cpurequest occupancy ratio of each node and the NodeMemoryRequestPercent of the memoryrequest occupancy ratio;

[0045] Module M5.4: Calculate the average value of the cpurequest ratio of all nodes AvgNodesCpuRequest and the average value of the memoryrequest ratio of all nodes AvgNodesMemoryRequest;

[0046] Module M5.5: Use the policy configuration parameters cputhresholds and memorythresholds to judge low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds;

[0047] Module M5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to judge high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds;

[0048] Module M5.7: Calculate the average value of the cpurequest of all high-load node pods AvgPodCpu and the average value of the memoryrequest AvgPodMemory;

[0049] Module M5.8: Judge whether each pod of the corresponding node is to be evicted based on the average value of the cpurequest and the average value of the memoryrequest of all high-load node pods. The cpurequest of the pod to be evicted > AvgPodCpu and / or the memoryrequest of the pod > AvgPodMemory;

[0050] Module M5.9: Use the node selector component to filter low-load nodes, and determine whether the pod is deployed on a low-load node based on pod affinity, node affinity, and stains, and whether it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted;

[0051] The Affinity strategy component adopts: respectively judging whether the pods in all the acquired namespaces satisfy the pod affinity, node affinity and stains; when the pod does not satisfy the pod affinity and / or node affinity, the node selector component is used to select nodes in the cluster that satisfy the pod affinity and node affinity to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted;

[0052] The ReCreate strategy component adopts: judging whether the existence time of the pods in all the acquired namespaces exceeds the maxPodLifeTimeSeconds in the strategy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

[0053] Compared with the prior art, the present invention has the following beneficial effects:

[0054] 1. The present invention can dynamically adjust the distribution of pods in a kubernetes cluster;

[0055] 2. Multiple strategies are supported to obtain different pod distribution adjustment results;

[0056] 3. The mean deviation algorithm under the LoadBalancing strategy determines low-load nodes and high-load nodes;

[0057] 4. The algorithm for determining pods to be evicted on high-load nodes under the LoadBalancing strategy.

[0058] 5. The present invention expels the rebuildable pod to dynamically adjust the distribution of pods in the kubernetes cluster, ensuring that the distribution of pods in the cluster is in a reasonable state for a long time;

[0059] 6. The present invention achieves load balancing by expelling high-load pods from high-load nodes and rebuilding them on other nodes;

[0060] 7. The present invention achieves the effect of ensuring affinity in the cluster by expelling anti-affinity pods and rebuilding them on nodes that meet the affinity relationship. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0062] Figure 1 Flowchart of a method for load balancing to improve node resource utilization in Kubernetes.

[0063] Figure 2 The following is a flow chart of the LoadBalancing strategy.

[0064] Figure 3 For working example diagram DETAILED DESCRIPTION

[0065] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0066] Example 1

[0067] According to a method for improving the node resource utilization and balancing the load of Kubernetes provided by the present invention, Figures 1 to 3 As shown, including:

[0068] Step S1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, and determine whether the cluster supports eviction. If not, exit directly;

[0069] Step S2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains cluster-related information, including information about each node in the cluster and information about the pods on each node, for subsequent resource calculations.

[0070] Step S3: Use the pod selector component to filter out pods for dynamic distribution adjustment;

[0071] The Pod selector component selects pods that may be dynamically distributed from the cluster based on configurations such as namespaces and priorities.

[0072] Specifically, the step S3 adopts:

[0073] Step S3.1: Get the namespace parameter in the configuration and determine whether the namespace parameter is empty; when the namespace parameter is empty, get the pods in all namespaces except the kubernetes system namespace (kube-system) under the namespace parameter from the cache of sharedInformerFactory; when the namespace parameter is not empty, get the pods in all namespaces under the namespace parameter from the cache of sharedInformerFactory;

[0074] Step S3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the acquired namespaces are dynamically distributed and adjusted; when the priorityThreshold parameter is not empty, the pods in all the acquired namespaces are traversed, and the pods with a priority greater than the priorityThreshold are removed, and the remaining pods are dynamically distributed and adjusted.

[0075] Step S4: Organize the obtained pods according to the mapping relationship of map[nodeName][]podInfo to facilitate the subsequent screening of related nodes and pods;

[0076] Step S5: According to the obtained pod-node mapping relationship, the strategies are executed in sequence according to the configuration file (different strategies have different pod eviction judgments, and the order determines the weight of the strategy. The earlier the order, the higher the weight). Different strategy combinations ultimately result in different eviction and reconstruction results.

[0077] Specifically, the execution strategy includes: one or more of a LoadBalancing strategy component, an Affinity strategy component, and a ReCreate strategy component;

[0078] The LoadBalancing strategy determines low-load nodes and high-load nodes through policy configuration parameters and mean deviation algorithm. In high-load nodes, the algorithm for determining pods to be evicted is used. These pods are then evicted and rebuilt on low-load nodes to achieve load balancing between nodes.

[0079] The Affinity strategy component traverses the pods on the node to determine the anti-affinity between pods and the anti-affinity relationship between nodes. This situation is generally caused by adding node affinity, taints, and labels after pod deployment, which makes the originally scheduled pods and nodes mismatched. If a pod with anti-affinity is found, it will be expelled and redeployed to a node that meets the affinity constraints.

[0080] The ReCreate strategy uses the policy parameter maxPodLifeTimeSeconds to filter out pods that have been running for too long and evict them, and then recreate the schedule.

[0081] Specifically, the LoadBalancing strategy component is implemented as follows:

[0082] Step S5.1: remove the pods whose status is success and fail, and obtain the remaining pods;

[0083] Step S5.2: Get the relevant information of the nodes where the remaining pods are located from the sharedInformerFactory cache;

[0084] Step S5.3: Calculate the cpurequest ratio NodeCpuRequestPercent and memoryrequest ratio NodeMemoryRequestPercent of each node;

[0085] NodeCpuRequestPercent

[0086]

[0087] Node memory request ratio: NodeMemoryRequestPercent

[0088]

[0089] Step S5.4: Calculate the average cpurequest ratio AvgNodesCpuRequest of all nodes and the average memoryrequest ratio AvgNodesMemoryRequest of all nodes;

[0090] The average cpurequest ratio of all nodes: AvgNodesCpuRequest

[0091]

[0092] Average value of memory request ratio of all nodes: AvgNodesMemoryRequest

[0093]

[0094] Step S5.5: Use the policy configuration parameters cputhresholds and memorythresholds to determine low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds;

[0095] Step S5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to determine high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds;

[0096] Step S5.7: Calculate the average value of cpurequest, AvgPodCpu, and the average value of memoryrequest, AvgPodMemory, of all pods of high-load nodes in the node;

[0097] Average value of cpurequest of the node: AvgPodCpu

[0098]

[0099] Average value of memoryrequest of the node: AvgPodMemory

[0100]

[0101] Step S5.8: Determine whether each pod of the corresponding node is to be evicted based on the average value of cpurequest and the average value of memoryrequest of all pods of high-load nodes. For pods to be evicted, cpurequest of the pod > AvgPodCpu and / or memoryrequest of the pod > AvgPodMemory;

[0102] Step S5.9: Use the node selector component to filter low-load nodes, and determine whether the pod is deployed on the low-load node based on pod affinity, node affinity, and stains, and whether it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, the current pod will be evicted, otherwise it will not be evicted.

[0103] The node selector looks for nodes that can redeploy the pod to be evicted based on the above different strategies. Node selection is mainly based on node affinity, pod affinity, taints, etc. If the LoadBalancing strategy is used, the selected node must be a low-load node. If there is no other node to deploy the pod to be evicted, the final pod will not be evicted.

[0104] Specifically, the Affinity strategy component adopts: respectively judging whether the pods in all acquired namespaces satisfy the pod affinity, node affinity and stains; when the pod does not satisfy the pod affinity and / or node affinity, the node selector component is used to screen nodes satisfying the pod affinity and node affinity in the cluster to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted.

[0105] Specifically, the ReCreate strategy component adopts: judging whether the existence time of the pods in all the namespaces obtained exceeds the maxPodLifeTimeSeconds in the strategy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

[0106] Step S6: Rebuild the pod. The cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node. Perform cyclic monitoring according to the interval in the configuration parameters, repeatedly trigger steps S3 to S6, and dynamically adjust the pod distribution in the cluster to balance the cluster load and adjust the balance.

[0107] A system for improving node resource utilization and balancing load of Kubernetes provided by the present invention includes:

[0108] Module M1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, determine whether the cluster supports eviction, and exit directly if it does not support eviction;

[0109] Module M2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains cluster-related information, including information about each node in the cluster and information about the pods on each node, for subsequent resource calculations.

[0110] Module M3: Use the pod selector component to filter out pods for dynamic distribution adjustment;

[0111] The Pod selector component filters out pods that may be dynamically distributed from the cluster based on configurations such as namespaces and priorities.

[0112] Specifically, the module M3 adopts:

[0113] Module M3.1: Get the namespace parameter in the configuration and determine whether the namespace parameter is empty; when the namespace parameter is empty, get the pods in all namespaces except the kubernetes system namespace (kube-system) under the namespace parameter from the cache of sharedInformerFactory; when the namespace parameter is not empty, get the pods in all namespaces under the namespace parameter from the cache of sharedInformerFactory;

[0114] Module M3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the namespaces are dynamically distributed; when the priorityThreshold parameter is not empty, the pods in all the namespaces are traversed, and the pods with a priority greater than priorityThreshold are removed, and the remaining pods are dynamically distributed.

[0115] Module M4: Organizes the obtained pods according to the mapping relationship of map[nodeName][]podInfo to facilitate the subsequent screening of related nodes and pods;

[0116] Module M5: Based on the acquired pod-node mapping relationship, the strategies are executed in sequence according to the configuration files. (Different strategies have different judgments on pod eviction. The order determines the weight of the strategy. The higher the order, the higher the weight.) Different strategy combinations ultimately lead to different eviction and reconstruction results.

[0117] Specifically, the execution strategy includes: one or more of a LoadBalancing strategy component, an Affinity strategy component, and a ReCreate strategy component;

[0118] The LoadBalancing strategy determines low-load nodes and high-load nodes through policy configuration parameters and mean deviation algorithm. In high-load nodes, the algorithm for determining pods to be evicted is used. These pods are then evicted and rebuilt on low-load nodes to achieve load balancing between nodes.

[0119] The Affinity strategy component traverses the pods on the node to determine the anti-affinity between pods and the anti-affinity relationship between nodes. This situation is generally caused by adding node affinity, taints, and labels after pod deployment, which makes the originally scheduled pods and nodes mismatched. If a pod with anti-affinity is found, it will be expelled and redeployed to a node that meets the affinity constraints.

[0120] The ReCreate strategy uses the policy parameter maxPodLifeTimeSeconds to filter out pods that have been running for too long and evict them, and then recreate the schedule.

[0121] Specifically, the LoadBalancing strategy component is implemented as follows:

[0122] Module M5.1: Remove the pods with success and fail status and get the remaining pods;

[0123] Module M5.2: Get the information about the nodes where the remaining pods are located from the sharedInformerFactory cache;

[0124] Module M5.3: Calculate the cpurequest ratio NodeCpuRequestPercent and memoryrequest ratio NodeMemoryRequestPercent of each node;

[0125] NodeCpuRequestPercent

[0126]

[0127] Memory request ratio of the node: NodeMemoryRequestPercent

[0128]

[0129] Module M5.4: Calculate the average value of the cpu request ratios of all nodes, AvgNodesCpuRequest, and the average value of the memory request ratios of all nodes, AvgNodesMemoryRequest;

[0130] Average value of the cpu request ratios of all nodes: AvgNodesCpuRequest

[0131]

[0132] Average value of the memory request ratios of all nodes: AvgNodesMemoryRequest

[0133]

[0134] Module M5.5: Use the policy configuration parameters cputhresholds and memorythresholds to determine low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds;

[0135] Module M5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to determine high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds;

[0136] Module M5.7: Calculate the average value of the cpu requests of all pods of high-load nodes in the node, AvgPodCpu, and the average value of the memory requests, AvgPodMemory;

[0137] Average cpurequest value of the node: AvgPodCpu

[0138]

[0139] Average memory request of the node: AvgPodMemory

[0140]

[0141] Module M5.8: Determine whether each pod of the corresponding node is to be evicted based on the average cpurequest and memoryrequest of all high-load node pods. The cpurequest of the pod to be evicted is greater than AvgPodCpu and / or the memoryrequest of the pod is greater than AvgPodMemory.

[0142] Module M5.9: Use the node selector component to filter low-load nodes, and determine whether the pod is deployed on a low-load node based on pod affinity, node affinity, and stains, and whether it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, the current pod will be evicted, otherwise it will not be evicted.

[0143] The node selector looks for nodes that can redeploy the pod to be evicted based on the above different strategies. Node selection is mainly based on node affinity, pod affinity, taints, etc. If the LoadBalancing strategy is used, the selected node must be a low-load node. If there is no other node to deploy the pod to be evicted, the final pod will not be evicted.

[0144] Specifically, the Affinity strategy component adopts: respectively judging whether the pods in all acquired namespaces satisfy the pod affinity, node affinity and stains; when the pod does not satisfy the pod affinity and / or node affinity, the node selector component is used to screen nodes satisfying the pod affinity and node affinity in the cluster to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted.

[0145] Specifically, the ReCreate strategy component adopts: judging whether the existence time of the pods in all the namespaces obtained exceeds the maxPodLifeTimeSeconds in the strategy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

[0146] Module M6: Rebuild the pod. The cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node. It performs cyclic monitoring according to the interval in the configuration parameters, repeatedly triggers modules M3 to M6, and dynamically adjusts the pod distribution in the cluster to balance the cluster load and adjust the balance.

[0147] Those skilled in the art know that, in addition to implementing the system, device and its various modules provided by the present invention in a purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and its various modules provided by the present invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing the method and structures within the hardware component.

[0148] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A method for improving the node resource utilization and load balancing of kubernetes, characterized in that: include: Step S1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, and determine whether the cluster supports eviction. If not, exit directly; Step S2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains cluster-related information; Step S3: Use the pod selector component to filter out pods for dynamic distribution adjustment; Step S4: Based on the selected pods that can be dynamically distributed and adjusted, the pod-node mapping relationship is obtained according to the obtained cluster related information; Step S5: According to the obtained pod-node mapping relationship, the policies are executed in sequence according to the configuration file to obtain the eviction and reconstruction result; Step S6: Rebuild the pod, and the cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node; perform cyclic monitoring according to the interval in the configuration parameter, repeatedly trigger steps S3 to S6, and dynamically adjust the pod distribution in the cluster to balance the cluster load and adjust the balance; The cluster related information includes the information of each node in the cluster and the pods information on each node; The execution strategy Including: one or more of LoadBalancing strategy component, Affinity strategy component and ReCreate strategy component; The LoadBalancing strategy component uses: Step S5.1: remove the pods whose status is success and fail, and obtain the remaining pods; Step S5.2: Get the relevant information of the nodes where the remaining pods are located from the sharedInformerFactory cache; Step S5.3: Calculate the cpurequest ratio NodeCpuRequestPercent and memoryrequest ratio NodeMemoryRequestPercent of each node; Step S5.4: Calculate the average cpurequest ratio AvgNodesCpuRequest of all nodes and the average memoryrequest ratio AvgNodesMemoryRequest of all nodes; Step S5.5: Use the policy configuration parameters cputhresholds and memorythresholds to determine low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds; Step S5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to determine high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds; Step S5.7: Calculate the average value AvgPodCpu of cpurequest of all pods of high-load nodes in the node and the average value AvgPodMemory of memoryrequest; Step S5.8: Determine whether each pod of the corresponding node is to be evicted based on the average value of cpurequest and the average value of memoryrequest of all pods of high-load nodes. The cpurequest of the pod to be evicted > AvgPodCpu and / or the memoryrequest of the pod > AvgPodMemory; Step S5.9: Use the node selector component to filter low-load nodes, and judge whether it meets the condition of deploying the pod on the low-load node based on pod affinity, node affinity, and taints, and it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, then evict the current pod, otherwise do not evict.

2. The method for improving the node resource utilization and load balancing of kubernetes according to claim 1, characterized in that: The said Step S3 adopts: Step S3.1: Obtain the namespace parameter in the configuration and judge whether the namespace parameter is empty; when the namespace parameter is empty, obtain the pods in all namespaces except the kubernetes system namespace under the namespace parameter from the cache of the sharedInformerFactory; when the namespace parameter is not empty, obtain the pods in all namespaces under the namespace parameter from the cache of the sharedInformerFactory; Step S3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the acquired namespaces are dynamically distributed and adjusted; when the priorityThreshold parameter is not empty, the pods in all the acquired namespaces are traversed, and the pods with a priority greater than the priorityThreshold are removed, and the remaining pods are dynamically distributed and adjusted.

3. The method for improving the node resource utilization and load balancing of kubernetes according to claim 1, characterized in that: The Affinity strategy component adopts: judging whether the pods in all the acquired namespaces satisfy the pod affinity, node affinity and stain respectively; when the pod does not satisfy the pod affinity and / or node affinity, the node selector component is used to select nodes satisfying the pod affinity and node affinity in the cluster to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted.

4. The method for improving the node resource utilization and load balancing of kubernetes according to claim 1, characterized in that: The ReCreate strategy component adopts: judging whether the existence time of the pods in all the acquired namespaces exceeds the maxPodLifeTimeSeconds in the strategy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

5. A system for improving the node resource utilization and load balancing of kubernetes, characterized in that: include: Module M1: Create a client connected to the cluster through configuration to obtain the kube-apiserver version supported by the cluster, determine whether the cluster supports eviction, and exit directly if it does not support eviction; Module M2: The verified cluster client creates a sharedInformerFactory, registers informers of nodes, pods, and namespaces resources to the sharedInformerFactory, and obtains cluster-related information; Module M3: Use the pod selector component to filter out pods for dynamic distribution adjustment; Module M4: Based on the selected pods that can be dynamically distributed and adjusted, the pod-node mapping relationship is obtained according to the obtained cluster-related information; Module M5: Based on the obtained pod-node mapping relationship, the policies are executed in sequence according to the configuration files to obtain the eviction and reconstruction results; Module M6: rebuilds the pod. The cluster scheduler kube-scheduler redeploys the rebuilt pod to the preset node. It performs cyclic monitoring according to the interval in the configuration parameters, repeatedly triggers modules M3 to M6, and dynamically adjusts the distribution of pods in the cluster to balance the cluster load and adjust the balance. The relevant information of the cluster includes the information of each node in the cluster and the information of pods on each node; The execution policy includes one or more of: LoadBalancing policy component, Affinity policy component, and ReCreate policy component; The LoadBalancing policy component adopts: Module M5.1: Exclude the pods with the pod status of success and fail obtained, and get the remaining pods; Module M5.2: Obtain the relevant information of the nodes where the remaining pods are located from the cache of the sharedInformerFactory; Module M5.3: Calculate the proportion of cpurequest of each node NodeCpuRequestPercent and the proportion of memoryrequest NodeMemoryRequestPercent; Module M5.4: Calculate the average value of cpurequest ratio of all nodes AvgNodesCpuRequest and the average value of memoryrequest ratio of all nodes AvgNodesMemoryRequest; Module M5.5: Use the policy configuration parameters cputhresholds and memorythresholds to judge low-load nodes: NodeCpuRequestPercent < AvgNodesCpuRequest - cputhresholds and NodeMemoryRequestPercent < AvgNodesMemoryRequest - memorythresholds; Module M5.6: Use the policy configuration parameters cpuTargetThresholds and memoryTargetThresholds to judge high-load nodes: NodeCpuRequestPercent > AvgNodesCpuRequest + cpuTargetThresholds or NodeMemoryRequestPercent > AvgNodesMemoryRequest + memoryTargetThresholds; Module M5.7: Calculate the average value of cpurequest AvgPodCpu and the average value of memoryrequest AvgPodMemory of all high-load node pods in the node; Module M5.8: Judge whether each pod of the corresponding node is to be evicted according to the average value of cpurequest and the average value of memoryrequest of all high-load node pods, and the cpurequest of the pod to be evicted > AvgPodCpu and / or the memoryrequest of the pod > AvgPodMemory; Module M5.9: Use the node selector component to filter low-load nodes, and determine whether the pod is deployed on a low-load node based on pod affinity, node affinity, and stains, and whether it will not become a high-load node; when a deployment node is found to deploy the pod to be evicted, the current pod will be evicted, otherwise it will not be evicted.

6. The system for improving node resource utilization and balancing load of Kubernetes according to claim 5, characterized in that: The module M3 adopts: Module M3.1: Get the namespace parameter in the configuration and determine whether the namespace parameter is empty; when the namespace parameter is empty, get the pods in all namespaces except the kubernetes system namespace under the namespace parameter from the cache of sharedInformerFactory; when the namespace parameter is not empty, get the pods in all namespaces under the namespace parameter from the cache of sharedInformerFactory; Module M3.2: Get the priorityThreshold parameter in the configuration and determine whether the priorityThreshold parameter is empty; when the priorityThreshold parameter is empty, the pods in all the namespaces are dynamically distributed; when the priorityThreshold parameter is not empty, the pods in all the namespaces are traversed, and the pods with a priority greater than priorityThreshold are removed, and the remaining pods are dynamically distributed.

7. The system for improving node resource utilization and balancing load of Kubernetes according to claim 5, characterized in that: The Affinity strategy component adopts: respectively judging whether the pods in all the acquired namespaces satisfy the pod affinity, node affinity and stains; when the pod does not satisfy the pod affinity and / or node affinity, the node selector component is used to select nodes in the cluster that satisfy the pod affinity and node affinity to deploy the current pod; when a deployment node is found to deploy the pod to be evicted, the current pod is evicted; otherwise, it is not evicted; The ReCreate strategy component adopts: judging whether the existence time of the pods in all the acquired namespaces exceeds the maxPodLifeTimeSeconds in the strategy configuration, retaining the pods with timeout, and removing the pods without timeout; for the retained pods, using the node selector component to screen the nodes that meet the pod affinity and node affinity in the cluster to deploy the current pod; when the deployment node is found to deploy the pod to be evicted, the current pod is evicted, otherwise it is not evicted.

Images