Implementing pod batch scheduling method and system in kubernetes

Abstract

The present invention provides a system and method for implementing batch scheduling of pods in kubernetes, including: storing the information status of a cyclic monitoring cluster in a cache module in the form of a snapshot; a session module reading the information in the cache module, obtaining different scheduling strategies through a plug-in module, and using a scheduling module to schedule target information based on different scheduling strategies. The present invention solves the problem that the native kubernetes scheduler can only schedule at the granularity of pods, and batch schedules pods as a group. If the resources are sufficient, the task can be scheduled and started normally, otherwise it will not be scheduled, avoiding deadlock.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and system for implementing pod batch scheduling in Kubernetes. Background Art

[0002] With the rapid development of Kubernetes, many ML / DL projects have begun to be deployed in containers on the cloud. However, the native scheduler of Kubernetes has some defects. The default native scheduler is based on pod granularity, but this scheduling method is very unfavorable for machine learning tasks. It cannot provide queue scheduling functions, which affects resource utilization.

[0003] Patent document CN111198756A (application number: 201911385165.4) discloses a method for scheduling applications in a kubernetes cluster, which is applied to a container cloud platform, wherein the kubernetes cluster is implemented based on a Loongson server. The method can pre-divide the kubernetes cluster nodes based on the Loongson server that are managed by the same container cloud platform into multiple logical pools in batches. In the reality that the stability of the Loongson server is insufficient, even if a node in a logical pool fails, it will not affect the application scheduling on other logical pools, thus avoiding the problem of the entire cluster being unavailable due to the failure of some nodes in the entire cluster, avoiding mutual influence between services, and improving the reliability of the kubernetes cluster service. In addition, the present application also provides an application scheduling device, a container cloud platform, and a readable storage medium for a kubernetes cluster, and its technical effects correspond to the technical effects of the above method.

[0004] The present invention provides a batch scheduler, which can schedule multiple workers of a training task as a whole. Only when the resources of all workers of the task are met will the container be started on the node, and the distribution method of the workers on the node can be selected. Summary of the invention

[0005] In view of the defects in the prior art, the object of the present invention is to provide a method and system for implementing pod batch scheduling in Kubernetes.

[0006] According to the present invention, a pod batch scheduling system in kubernetes is provided, including: storing the information status of a cyclic monitoring cluster in a cache module in the form of a snapshot; a session module reads the information in the cache module, obtains different scheduling strategies through a plug-in module, and uses a scheduling module to schedule target information based on different scheduling strategies.

[0007] Preferably, in the cache module, by calling the SDK of kubernetes, the state change information of the nodes and containers in the cluster is monitored using the watch mechanism, and the state change information is synchronously stored in a preset data structure.

[0008] Preferably, in the plug-in module, different scheduling strategies are provided to the scheduling module in a pluggable manner, and the plug-in module calculates the target node based on the scheduling strategy.

[0009] Preferably, in the scheduling module, the scheduler calculates available resource information of nodes and containers in the cluster based on monitored state changes of nodes and containers in the cluster, and performs batch scheduling of pods based on the resource calculation results and the selected target nodes.

[0010] Preferably, the plug-in module includes: a DRF plug-in, a Gang Scheduling plug-in, a predicates plug-in, a priority plug-in, a node order plug-in and a Deploymode plug-in;

[0011] The DRF plug-in is to give the highest priority to the task with the lowest resource occupancy ratio during scheduling;

[0012] The Gang Scheduling plugin schedules the pods to the nodes after all pods in the job or a specified preset number of pods are allocated resources.

[0013] The predicates plug-in is used to determine whether the node meets the basic resource requirements for normal container startup;

[0014] The priority plug-in registers a task sorting function, sorting according to pod priority; registers a job sorting function, sorting according to job priority, and registers a preemption function;

[0015] The node order plug-in sorts the nodes according to the resource utilization that meets the scheduling resources, and sets the priority of node selection during scheduling based on the resource utilization sorting;

[0016] The Deploymode plug-in is configured according to the job's requirements for intra-node and inter-node data communication when multiple nodes are capable of scheduling, thereby improving throughput.

[0017] Preferably, in the scheduling module, a pod with clear resource requirements is allocated to a certain node, and the resources applied for by the pod are compared with the remaining resources of the node. When the remaining resources of the node meet the resource conditions required for starting the pod, the pod is bound to the current node;

[0018] Allocate pods that do not set resource requirements to the corresponding nodes.

[0019] Preferably, in the scheduling module, tasks to be scheduled are saved as preemptors according to priority sorting, and the preemption function is used to recall pods that meet resource conditions and have low priority, and evict them, and schedule the preemptors to nodes.

[0020] Preferably, a multi-level queue mechanism is set for the pod, and tasks in the same queue are run in sequence; priorities are set for different queues, and tasks in queues with higher priorities are scheduled first.

[0021] Preferably, the weight of the queue is set, and the queue with a higher weight will be allocated more resources.

[0022] According to the present invention, a method for implementing batch scheduling of pods in kubernetes includes: storing the information status of a cyclic monitoring cluster in a cache module in a snapshot manner; a session module reads the information in the cache module, obtains different scheduling strategies through a plug-in module, and uses a scheduling module to schedule target information based on different scheduling strategies;

[0023] In the cache module, by calling the SDK of kubernetes, the state change information of nodes and containers in the cluster is monitored using the watch mechanism, and the state change information is synchronously stored in a preset data structure;

[0024] In the plug-in module, different scheduling strategies are provided to the scheduling module in a pluggable manner, and the plug-in module calculates the target node based on the scheduling strategy;

[0025] In the scheduling module, the scheduler calculates the available resource information of the nodes and containers in the cluster based on the monitored state changes of the nodes and containers in the cluster, and performs batch scheduling of pods based on the resource calculation results and the selected target nodes.

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

[0027] 1. Use kubernetes CRD (CustomResourceDefinition is created directly in the cluster through yaml files) and plug-ins to implement functions, reducing the difficulty of deployment and use.

[0028] 2. Solved the problem that the native Kubernetes scheduler can only schedule at the pod level. The pods are scheduled as a group in batches. If the resources are sufficient, the task can be scheduled and started normally. Otherwise, it will not be scheduled to avoid deadlock.

[0029] 3. Provides a queue mechanism, tasks in the same queue will run in sequence. Different queues can be directly set with priority, and tasks in queues with high priority will be scheduled first. Queues can also be set with weights, and queues with high weights will be allocated more resources.

[0030] 4. Batch scheduling of pod containers is optional in node distribution mode, because in addition to the requirements in the resource dimension, there are also considerations for disaster recovery and interference isolation in actual scheduling: for example, containers of the same application are not allowed to be deployed on the same node, and many applications require that only one instance is allowed on each node. In addition, there are mutual exclusion relationships between some application components (such as resource competition), which seriously affects the performance of the application, so they are not allowed to be deployed on the same node. Therefore, it is very necessary to have an optional batch scheduling algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] 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:

[0032] Figure 1 This is the working principle diagram of DRF.

[0033] Figure 2 This is the working principle diagram of Gang scheduling.

[0034] Figure 3 This is the working principle diagram of the Deloymode binack algorithm.

[0035] Figure 4 This is a diagram of the working principle of the Deloymode topology algorithm.

[0036] Figure 5 For the work queue structure.

[0037] Figure 6 Call the process for key steps.

[0038] Figure 7 This is the scheduler workflow diagram. DETAILED DESCRIPTION

[0039] 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.

[0040] For the native scheduler of kubernetes, scheduling is performed at the granularity of pods. However, for a work pod group that needs to be scheduled as a whole, but the resources cannot fully meet the minimum number of pods to enter the running state, the native scheduler of kubernetes will directly schedule the executable pods, but in fact the work task cannot be started normally, thus entering a deadlock state. Therefore, this solution is implemented by implementing a scheduler using custom resources (CRD). It is very simple to deploy this scheduler in this way. By dividing the pods that need to be scheduled for the same work into a group and setting the minimum schedulable number, the pods are distributed to the optimal nodes using the set algorithm when the number is met, which improves resource utilization. In addition, due to the optional pods distribution algorithm, we can better optimize the performance of the workload and improve throughput.

[0041] Example 1

[0042] According to the present invention, a pod batch scheduling system in kubernetes is provided, including: storing the information status of a cyclic monitoring cluster in a cache module in the form of a snapshot; a session module reads the information in the cache module, obtains different scheduling strategies through a plug-in module, and uses a scheduling module to schedule target information based on different scheduling strategies.

[0043] Specifically, in the cache module, by calling the SDK of kubernetes, the state change information of the nodes and containers in the cluster is monitored using the watch mechanism, and the state change information is synchronously stored in a preset data structure.

[0044] The cache module encapsulates the data synchronization logic for the API Server's nodes, containers, and other objects, as well as the calls to the API Server's interfaces. Kubernetes data is stored in the distributed storage etcd, and all queries and operations on data are performed by calling the API Server's interfaces rather than directly operating etcd.

[0045] Specifically, the session module uses a custom data structure to save cache snapshot information. Different plug-ins in the plug-in module can call the required information in the session, thereby giving the scheduling target result and writing it into the session. The scheduling module obtains the target result for actual scheduling.

[0046] Specifically, in the plug-in module, different scheduling strategies are provided to the scheduling module in a pluggable manner, and the plug-in module calculates the target node based on the scheduling strategy; for example, there are 6 plug-ins, and the main functions of these 6 plug-ins are to set the minimum schedulable amount of the pod group and implement their node resource selection strategy, and schedule according to the corresponding algorithm;

[0047] More specifically, the plug-in module includes: DRF plug-in, Gang Scheduling plug-in, predicates plug-in, priority plug-in, node order plug-in and Deploymode plug-in;

[0048] like Figure 1 As shown, the DRF plug-in implements a resource fairness algorithm that can effectively schedule multiple major resources (CPU, Memory, GPU); during scheduling, the task with the lowest resource occupancy ratio has the highest priority;

[0049] like Figure 2 As shown, the Gang Scheduling plug-in implements the logic of gang scheduling, that is, ensuring that the workers required for the task are started at the same time; when all pods in the job, or a specified preset number of pods, are allocated resources, the pods are scheduled to the nodes;

[0050] The predicates plug-in is used to determine whether the node meets the basic resource requirements for normal container startup;

[0051] The priority plug-in determines the priority of the container and the queue according to the PriorityClass set for the container and the queue; registers the task sorting function, sorts according to the pod priority; registers the job sorting function, sorts according to the job priority, and registers the preemption function; wherein, Job = pods; task = pod;

[0052] The node order plug-in determines which node is selected first among the nodes that meet the scheduling requirements; sorts the nodes by resource utilization according to the resources that meet the scheduling requirements, and sets the priority of node selection during scheduling based on the resource utilization sorting;

[0053] The Deploymode plug-in provides a selection algorithm that can affect the distribution mode of pods on nodes; when multiple nodes can be scheduled, the job is configured according to its needs for intra-node and inter-node data communication to improve throughput.

[0054] More specifically,

[0055] DRF (Dominant Resource Fairness) plugin

[0056] Try to avoid the undesirable situation where the usage ratio of one type of resource in the cluster is high while the usage ratio of other types of resources is very low. When scheduling, give high priority to the task with the lowest resource usage ratio.

[0057] Count the total amount of resources that can be allocated to all nodes in the cluster;

[0058] Count job resource applications and calculate resource ratio (resource application / total resources);

[0059] Register the job sorting function and sort by resource proportion. The lower the proportion of main resources, the higher the job priority.

[0060] Register event processing functions, including allocation functions and eviction functions. The function implementation is relatively simple. When the task changes, increase (allocate) / decrease (evict) the total amount of Job resource applications and update the resource ratio.

[0061] Gang Scheduling Plugin

[0062] The strategy that the gang needs to implement is to schedule the pods to the nodes only when all the pods in the job, or some pods specified by the user, are allocated resources. (That is, first logically allocate resources to the pods, and then actually schedule them when the conditions are met.)

[0063] Predicates plugin

[0064] Predicates registers a prediction function to determine whether a node meets the basic resource requirements for the container to start normally, such as

[0065] CheckNodeCondition Predicate

[0066] CheckNodeUnschedulable Predicate

[0067] NodeSelector Predicate

[0068] HostPorts Predicate

[0069] Toleration / Taint Predicate

[0070] …

[0071] priority plugin

[0072] Register the task sorting function to sort by pod priority; register the job sorting function to sort by job priority, and register the preemption function.

[0073] Node order plugin

[0074] Analyze the resource utilization of nodes according to the resources that meet the scheduling requirements, such as CPU utilization, memory utilization, and GPU utilization, and sort and score them. Set the scoring weight according to the optional parameters most or least to improve resource utilization.

[0075] Deploymode plugin

[0076] It includes two algorithm modes: paking and tuop algorithms. When multiple nodes can be scheduled, they are configured according to the job's requirements for intra-node and inter-node data communication to improve throughput.

[0077] Specifically, in the scheduling module, the scheduler needs to calculate the information such as the used resources and status of the nodes and containers in the cluster, so as to determine the resource allocation as the basis for scheduling. More specifically, the scheduler calculates the available resource information of the nodes and containers in the cluster based on the monitored status changes of the nodes and containers in the cluster, and performs batch scheduling of pods based on the resource calculation results and the selected target nodes, and performs actions such as expelling the scheduled pods.

[0078] Specifically, in the scheduling module, a pod with clear resource requirements is allocated to a node, and the resources requested by the pod are compared with the remaining resources of the node. When the remaining resources of the node meet the resource conditions required for starting the pod, the pod is bound to the current node;

[0079] Assign pods that do not set resource requirements to nodes.

[0080] Specifically, in the scheduling module, according to the priority sorting, the tasks to be scheduled are saved as preemptors, and the preemption function is used to recall the pods that meet the resource conditions and have low priority (the pods that meet the resource conditions and have low priority are used as victims), and evict them, preempt the pods that have been scheduled and meet the conditions, and schedule the target pods to the node

[0081] Specifically, Figure 5 As shown in the figure, a multi-level queue mechanism is set for the pod, and tasks in the same queue are run in sequence; different queues are set with priorities, and tasks in queues with higher priorities are scheduled first. Set the weight of the queue, and queues with higher weights will be allocated more resources.

[0082] The present invention provides a method for implementing pod batch scheduling in kubernetes, including: registering the scheduler and plug-in after starting the cache, monitoring the cluster resources, and starting the scheduling process after starting the session. The specific work flow chart is shown in Figure 6-7 .

[0083] Step 1: Enable caching

[0084] Step 1 includes:

[0085] Step 1.1: Lock resources to ensure consistency and create a client to access the API Server. Use the watch mechanism to monitor the status changes of nodes and containers in the cluster and synchronize the information to its own data structure.

[0086] Step 1.2: Prepare API server interface calls, such as pod binding interface and eviction interface, call API Server's Bind interface, and bind the container to the specified node.

[0087] Step 2: Load the scheduler and register the self-defined Action and six plug-ins with the cluster.

[0088] Step 3: list-watch monitors resources such as Pod, Queue, PodGroup, and Node, and maintains a global cache of cluster resources locally.

[0089] Step 3 above includes:

[0090] Step 3.1: Start ListWatch of each REST, including node\podGroup\pv\pvc\sc, etc. PodGroup is the CRDs defined by the scheduler and is the core of batch scheduling;

[0091] Step 3.2: Resynchronize the Pod status according to the processResyncTask queue, and clean up the cache according to the processCleanupJob queue;

[0092] Step 4: Start the session and execute the scheduling;

[0093] Step 4 above includes:

[0094] Step 4.1: At the beginning of each scheduling cycle, a new session object needs to be created;

[0095] The above step 4.1 includes:

[0096] Step 4.1.1: Call the cache snapshot to store the cache data generated in step 3, make a copy of the node, task, and queue information in the cache, and then use this copy for scheduling in this scheduling cycle.

[0097] Step 4.1.2: Initialize each plug-in in the configuration, and then call the plug-in's OnSessionOpen interface. In OnSessionOpen, the plug-in will initialize the data it needs and register some callback functions to the session.

[0098] The above step 4.1.2 includes:

[0099] Step 4.1.2.1: Call DRF to define the priority of the Job;

[0100] Statistics on the total amount of resources that can be allocated to all nodes in the cluster

[0101] Count job resource applications and calculate resource ratio (resource application / total resources)

[0102] Register the job sorting function and sort by resource proportion. The lower the proportion of main resources, the higher the job priority.

[0103] Register event processing functions, including allocation functions and eviction functions. The function implementation is relatively simple. When the task changes, increase (allocate) / decrease (evict) the total amount of Job resource applications and update the resource ratio.

[0104] Step 4.1.2.2: Enable Gang Scheduling and register the minimum scheduling requirements;

[0105] Check whether the number of tasks (Pods) of the schedulable Job in the simulation scheduling meets the requirements.

[0106] If the quantity requirement is not met, a verification failure is returned and the job is not scheduled; if the minimum scheduling requirement is met, the pod is scheduled on the real node.

[0107] Step 4.1.2.3: The priority plug-in sorts jobs and tasks according to their priorities.

[0108] Step 4.1.2.4: After the predicat plug-in registers the prediction function, it determines whether a node meets the basic requirements of the container. Then the node order plug-in obtains the availability of cluster node resources (CPU, memory, GPU) from the predicates plug-in, selects the utilization of the requested resources according to different parameters, sets different scoring weights to classify the schedulable nodes into different priorities and perform aix.

[0109] Step 4.1.2.5: After the schedulable nodes are determined, the distribution mode of the pod (task) can be selected according to the Deloymode plug-in, which provides two scheduling algorithms:

[0110] like Figure 3 As shown in the figure, the binack algorithm tries to fill up the nodes as much as possible to make the scheduling of pods more centralized. However, centralized deployment is not suitable for the utilization of hardware resources for some tasks. Therefore, the second parameter topology can be selected to change to the second algorithm:

[0111] like Figure 4 As shown in the figure, the topology algorithm: evenly schedules tasks to nodes, with balanced speed, which improves the overall storage capacity. This algorithm is affected by the result returned by the 4.1.2.4 plug-in, and meets the minimum scheduling requirements. The number of schedulable nodes is 1, and the final scheduling result is the same as the binack algorithm result.

[0112] Step 4.2: Execute the dispatch through Action;

[0113] The above step 4.2 includes:

[0114] Step 4.2.1: The recycling activity saves the task to be scheduled as a preemptor, finds the queue, job, and task with the highest priority, then traverses the node, executes the preselection function, finds the pod running on the node to determine the victim (the pod to be evicted), and skips evicting the victim if the total amount of victim resources is less than the total amount of pod resources requested. Otherwise, the deletion interface is called. If enough resources are released, the eviction process is exited.

[0115] Step 4.2.2: Execute allocation, traverse the node and call the pre-selection plug-in to execute the pre-selection function, compare the pod resource application and the node idle resources, and schedule according to the priority sorting of the nodes in 4.1.2.4 and the expected results of the pod distribution algorithm plug-in (Deploymode). If the conditions are met, a binding request is initiated to the apiserver through the session, otherwise, eviction is performed, and the task is preempted from the node according to the node priority compared with the already running tasks.

[0116] Step 4.2.3: After scheduling the pod with resource request, perform backfill action and schedule the operation with empty InitResreq task. Traverse the node list and select the pod that meets all the prediction functions to schedule it on the node. This is not run in parallel with the allocation operation and there is no risk of conflict. After that, the session is closed and a scheduling cycle is completed.

[0117] 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.

[0118] 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 pod batch scheduling system in kubernetes, characterized in that: include: The information status of the cyclic monitoring cluster is stored in the cache module in the form of snapshots; The session module reads the information in the cache module, obtains different scheduling strategies through the plug-in module, and uses the scheduling module to schedule target information based on different scheduling strategies; In the cache module, by calling the SDK of kubernetes, the state change information of nodes and containers in the cluster is monitored using the watch mechanism, and the state change information is synchronously stored in a preset data structure; In the plug-in module, different scheduling strategies are provided to the scheduling module in a pluggable manner, and the plug-in module calculates the target node based on the scheduling strategy; In the scheduling module, the scheduler calculates the available resource information of the nodes and containers in the cluster based on the monitored state changes of the nodes and containers in the cluster, and performs batch scheduling of pods based on the resource calculation results and the selected target nodes; The plug-in module includes: DRF plug-in, Gang Scheduling plug-in, predicates plug-in, priority plug-in, node order plug-in and Deploymode plug-in; The DRF plug-in is to give the highest priority to the task with the lowest resource occupancy ratio during scheduling; The Gang Scheduling plugin schedules the pods to the nodes after all pods in the job or a specified preset number of pods are allocated resources. The predicates plug-in is used to determine whether the node meets the basic resource requirements for normal container startup; The priority plug-in registers a task sorting function, sorting according to pod priority; registers a job sorting function, sorting according to job priority, and registers a preemption function; The node order plug-in sorts the nodes according to the resource utilization that meets the scheduling resources, and sets the priority of node selection during scheduling based on the resource utilization sorting; The Deploymode plug-in is used to configure the job according to its requirements for intra-node and inter-node data communication when multiple nodes can be scheduled, thereby improving throughput. In the scheduling module, a pod with clear resource requirements is allocated to a node, and the resources requested by the pod are compared with the remaining resources of the node. When the remaining resources of the node meet the resource conditions required for starting the pod, the pod is bound to the current node; Allocate pods that do not have resource requirements to the corresponding nodes; In the scheduling module, tasks to be scheduled are saved as preemptors according to priority sorting, and the preemption function is used to recall and evict pods that meet resource conditions and have low priority, and the preemptors are scheduled to nodes; A multi-level queue mechanism is set for pods, and tasks in the same queue are run in sequence. Priorities are set for different queues, and tasks in queues with higher priorities are scheduled first. Set the weight of the queue. Queues with higher weights will be allocated more resources.

2. A method for implementing pod batch scheduling in kubernetes, characterized in that: include: The information status of the cyclic monitoring cluster is stored in the cache module in the form of snapshots; The session module reads the information in the cache module, obtains different scheduling strategies through the plug-in module, and uses the scheduling module to schedule target information based on different scheduling strategies; In the cache module, by calling the SDK of kubernetes, the state change information of nodes and containers in the cluster is monitored using the watch mechanism, and the state change information is synchronously stored in a preset data structure; In the plug-in module, different scheduling strategies are provided to the scheduling module in a pluggable manner, and the plug-in module calculates the target node based on the scheduling strategy; In the scheduling module, the scheduler calculates the available resource information of the nodes and containers in the cluster based on the monitored state changes of the nodes and containers in the cluster, and performs batch scheduling of pods based on the resource calculation results and the selected target nodes; The plug-in module includes: DRF plug-in, Gang Scheduling plug-in, predicates plug-in, priority plug-in, node order plug-in and Deploymode plug-in; The DRF plug-in is to give the highest priority to the task with the lowest resource occupancy ratio during scheduling; The Gang Scheduling plugin schedules the pods to the nodes after all pods in the job or a specified preset number of pods are allocated resources. The predicates plug-in is used to determine whether the node meets the basic resource requirements for normal container startup; The priority plug-in registers a task sorting function, sorting according to pod priority; registers a job sorting function, sorting according to job priority, and registers a preemption function; The node order plug-in sorts the nodes according to the resource utilization that meets the scheduling resources, and sets the priority of node selection during scheduling based on the resource utilization sorting; The Deploymode plug-in is used to configure the job according to its requirements for intra-node and inter-node data communication when multiple nodes can be scheduled, thereby improving throughput. In the scheduling module, a pod with clear resource requirements is allocated to a node, and the resources requested by the pod are compared with the remaining resources of the node. When the remaining resources of the node meet the resource conditions required for starting the pod, the pod is bound to the current node; Allocate pods that do not have resource requirements to the corresponding nodes; In the scheduling module, tasks to be scheduled are saved as preemptors according to priority sorting, and the preemption function is used to recall and evict pods that meet resource conditions and have low priority, and the preemptors are scheduled to nodes; A multi-level queue mechanism is set for pods, and tasks in the same queue are run in sequence. Priorities are set for different queues, and tasks in queues with higher priorities are scheduled first. Set the weight of the queue. Queues with higher weights will be allocated more resources.

Images