Method and system for realizing queue ordering by utilizing coscheduling plug-in in kubernetes

Abstract

The application discloses a method and system for realizing queue sorting by using a plug-in in Kubernetes. First, a pre-filtering algorithm is used to pre-filter a PodGroup. It can be understood that the PodGroup can be filtered according to the total number of pods being less than the minimum number of running tasks, or the filtering can be performed according to the case that the current cluster node is less than the minimum resource requirement of the PodGroup, so as to avoid unnecessary waste of processing resources. Then, priorities of multiple pods of the PodGroup passing the pre-filtering are set. In the cluster node processing the PodGroup, the pods are queued from front to back based on the priorities of the pods. It is easily thought that the high-priority pods can be arranged in front of the low-priority pods, and the high-priority pods are preferentially processed. The mutual relationship among the pods is comprehensively considered, and the scheduler can timely and dynamically support the scheduling demand of a user.

Description

Technical Field

[0001] This invention relates to container management platforms, and more particularly to a method, system, and storage medium for implementing queue sorting using the Coscheduling plugin in Kubernetes. Background Technology

[0002] Kubernetes has become the de facto standard for container management platforms, and the Pod, as the immutable infrastructure in Kubernetes, is the smallest unit of scheduling. The Kubernetes scheduling framework also revolves around the Pod. In web application and microservice workloads, the native scheduler provides excellent full lifecycle management capabilities for containerized applications, including automated deployment, operation and maintenance, and resource scheduling. With the widespread adoption of Kubernetes in public clouds and enterprise environments, workloads beyond web applications and microservices, such as machine learning, deep learning training tasks, big data processing tasks, and gene computing workflows, are gradually being integrated into the Kubernetes ecosystem.

[0003] The native Kubernetes scheduler processes individual Pod containers sequentially, using Pods as the scheduling unit, without considering the relationships between Pods. However, many offline data computation jobs require combined scheduling, meaning that all subtasks must be successfully created before the entire job can run. If only some subtasks start, the started subtasks will wait for the remaining subtasks to be scheduled. In this scenario, the native scheduler cannot support the user's scheduling needs in a timely and dynamic manner. Summary of the Invention

[0004] The purpose of this invention is to overcome the above-mentioned technical deficiencies and propose a method, system, and storage medium for implementing queue sorting using the Coscheduling plugin in Kubernetes, thereby solving the technical problem that the native scheduler in the prior art cannot support users' scheduling needs in a timely and dynamic manner.

[0005] To achieve the above-mentioned technical objectives, in a first aspect, the present invention provides a method for implementing queue sorting using the Coscheduling plugin in Kubernetes, comprising the following steps:

[0006] Use a pre-filtering algorithm to pre-filter PodGroups;

[0007] Set priorities for multiple pods in the PodGroup that have passed the pre-filter;

[0008] In the cluster nodes processing the PodGroup, the pods are queued from front to back based on their priority.

[0009] Compared with existing technologies, the beneficial effects of the method for implementing queue sorting in Kubernetes using the Coscheduling plugin provided by this invention include:

[0010] First, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods in the PodGroups that have passed the pre-filtering. In the cluster nodes processing the PodGroups, the pods are queued from front to back based on their priorities. It's easy to see that higher-priority pods are placed before lower-priority pods, allowing for priority processing of higher-priority pods. The queue sorting method using the Coscheduling plugin in Kubernetes provided in this embodiment comprehensively considers the relationships between pods, enabling the scheduler to support user scheduling needs in a timely and dynamic manner.

[0011] According to some embodiments of the present invention, the pre-filtering of PodGroup using a pre-filtering algorithm includes the following steps;

[0012] Verify the total number of pods in the PodGroup containing the currently processed pod. If the total number of pods is less than the minimum number of running tasks, refuse to schedule the pod.

[0013] According to some embodiments of the present invention, the pre-filtering of PodGroup using a pre-filtering algorithm includes the following steps;

[0014] Verify the minimum resource requirement of the PodGroup containing the currently processing pod. If the current cluster node has less than the minimum resource requirement, refuse to schedule the pod.

[0015] According to some embodiments of the present invention, when the total number of scheduling failures of the pod exceeds a preset threshold, a locked node group is allocated to the PodGroup where the currently processed pod is located;

[0016] During the filtering phase, a node evaluation algorithm is invoked to select suitable cluster nodes and include them in the locked node group.

[0017] In the locked node group, the pods are queued from front to back based on their priority.

[0018] According to some embodiments of the present invention, when the total number of failed scheduling of the pod exceeds a preset threshold, and the PodGroup in which the currently processed pod is located is different from the PodGroup in the locked node group, a node evaluation algorithm is invoked to select a cluster node outside the locked node group to process the PodGroup in which the currently processed pod is located.

[0019] According to some embodiments of the present invention, priority is set according to the percentage of the total number of failed scheduling of the pods that exceeds a preset threshold.

[0020] According to some embodiments of the present invention, when multiple pods have the same priority, the pods are sorted according to the creation time of the PodGroup to which the pods belong.

[0021] According to some embodiments of the present invention, when multiple pods have the same priority and the PodGroup to which the pods belong has the same creation time, the pods are sorted according to their names.

[0022] In a second aspect, the present invention provides a system for implementing queue sorting in Kubernetes using a Coscheduling plugin, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method for implementing queue sorting in Kubernetes using a Coscheduling plugin as described in any one of the first aspects.

[0023] Thirdly, the present invention provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute a method for implementing queue sorting using the Coscheduling plugin in Kubernetes as described in any one of the first aspects.

[0024] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0025] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, wherein the abstract drawings are to be completely consistent with one of the drawings in the specification:

[0026] Figure 1 A flowchart illustrating a method for implementing queue sorting using the Coscheduling plugin in Kubernetes, provided as an embodiment of the present invention;

[0027] Figure 2 A flowchart illustrating a method for implementing queue sorting in Kubernetes using the Coscheduling plugin, provided as another embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0029] It should be noted that although functional modules are divided in the system diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0030] This invention provides a method for implementing queue sorting in Kubernetes using the Coscheduling plugin. It comprehensively considers the interrelationships between Pods and can support user scheduling needs in a timely and dynamic manner. While it can effectively schedule tasks composed of multiple interconnected processes, in situations of resource scarcity or multi-tenant shared resources, low-priority tasks or tasks with high resource demands may remain unschedulable for extended periods, leading to task "starvation." If a "starved" task is important and has a high priority, the entire cluster's resources cannot be utilized effectively. Therefore, multi-process PodGroup task scheduling also requires a fair scheduling mechanism: ensuring that tasks are scheduled only after reaching a critical state of prolonged starvation for some reason. This invention, by extending and improving custom resource PodGroups, enables a resource queue queuing mechanism and task priority strategy for process groups when resources are scarce in the same cluster / tenant space. This prevents high-resource-consuming process groups from remaining unschedulable and in a "starved" state, maximizing the utilization of overall cluster resources while maintaining high controllability and flexible scheduling.

[0031] Reference Figure 1 , Figure 1 This is a flowchart illustrating a method for implementing queue sorting in Kubernetes using the Coscheduling plugin, as provided in an embodiment of the present invention.

[0032] Methods for implementing queue sorting using the Coscheduling plugin in Kubernetes include, but are not limited to, steps S110 to S130.

[0033] Step S110: Perform pre-filtering on PodGroup using a pre-filtering algorithm;

[0034] Step S120: Set priorities for multiple pods in the PodGroup that have passed the pre-filter;

[0035] Step S130: In the cluster nodes processing PodGroup, pods are queued from front to back based on their priority.

[0036] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods within the pre-filtered PodGroups. In the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. It's easy to see that higher-priority pods are placed before lower-priority pods, allowing for priority processing of higher-priority pods. By comprehensively considering the relationships between pods, the scheduler can support user scheduling needs in a timely and dynamic manner.

[0037] Understandably, while this embodiment can effectively schedule tasks composed of multiple interconnected processes, in situations of resource scarcity or multi-tenant shared resources in a cluster, low-priority tasks or tasks with high resource demands may remain unschedulable for extended periods, leading to task "starvation." If the "starved" task is important and has a high priority, then the entire cluster's resources cannot be utilized effectively. Therefore, multi-process PodGroup task scheduling also requires a fair scheduling mechanism: ensuring that tasks are scheduled only after reaching a critical state of prolonged starvation for some reason. This invention, by extending and improving custom resource PodGroups, can implement a resource queue queuing mechanism and task priority strategy for process groups when resources are scarce in the same cluster / tenant space. This prevents high-resource-consuming process groups from remaining unschedulable and in a "starved" state, maximizing the utilization of overall cluster resources while maintaining high controllability and flexible scheduling.

[0038] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods in the pre-filtered PodGroups. In the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The pre-filtering algorithm for PodGroups includes the following steps: verifying the total number of pods in the PodGroup containing the currently processed pod; if the total number of pods is less than the minimum number of running tasks, the pod is rejected for scheduling.

[0039] Understandably, when the total number of pods is less than the minimum number of running tasks, the scheduler is not suitable for scheduling the PodGroup containing the currently processed pod, so refusing to schedule the PodGroup containing the currently processed pod is a better choice.

[0040] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster node's resource requirement is less than the minimum resource requirement of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods within the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The pre-filtering algorithm for PodGroups includes the following steps: verifying the minimum resource requirement of the PodGroup containing the currently processed pod; if the current cluster node's resource requirement is less than the minimum resource requirement, the pod is rejected from scheduling.

[0041] Not only is the scheduler unsuitable for scheduling the PodGroup containing the currently processed pod when the total number of pods is less than the minimum number of running tasks, but it is also unsuitable for scheduling the PodGroup containing the currently processed pod when the current number of cluster nodes is less than the minimum resource requirement of the PodGroup containing the currently processed pod. Therefore, the scheduler refuses to schedule the currently processed pod.

[0042] refer to Figure 2 , Figure 2 A flowchart illustrating a method for implementing queue sorting in Kubernetes using the Coscheduling plugin, provided as another embodiment of the present invention.

[0043] Methods for implementing queue sorting using the Coscheduling plugin in Kubernetes include, but are not limited to, steps S210 to S230.

[0044] Step S210: When the total number of failed scheduled pods exceeds a preset threshold, a locked node group is allocated to the PodGroup where the currently processed pod is located.

[0045] Step S220: In the filtering phase, the node evaluation algorithm is invoked to select suitable cluster nodes and include them in the locked node group.

[0046] Step S230: In the locked node group, pods are queued from front to back based on their priority.

[0047] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods in the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The pre-filtering algorithm for PodGroups includes the following steps: verifying the total number of pods in the PodGroup containing the currently processed pod; if the total number of pods is less than the minimum number of running tasks, the pod is rejected for scheduling. Verifying the minimum resource requirements of the PodGroup containing the currently processed pod; if the current cluster nodes have less than the minimum resource requirements, the pod is rejected for scheduling.

[0048] When the total number of failed pod scheduling exceeds a preset threshold, a locked node group is allocated to the PodGroup where the currently processed pod is located. During the filtering phase, a node evaluation algorithm is invoked to select suitable cluster nodes and include them in the locked node group. In the locked node group, pods are queued from front to back based on their priority.

[0049] This embodiment improves the custom resource PodGroup by adding a field for the maximum tolerable number of scheduling failures. It also expands and improves the extension point algorithm provided by the Scheduler Plugin, enabling node filtering and reservation at different extension points. These nodes are then included in the corresponding lock point node group of the PodGroup. Locked nodes cease accepting new job submissions from the moment of inclusion until the resource specifications of the locked node group meet the requirements of the target job. During this period, non-target jobs can only be scheduled using nodes outside the locked node group. Only after the target job is scheduled can other jobs be rescheduled across the entire cluster. This ensures the rational utilization of cluster resources across all process groups (PodGroups).

[0050] After adding the maximum number of scheduling failures field (i.e., the total number of failed pod scheduling attempts) to PodGroup, the corresponding queue sorting algorithm rules are adjusted as follows:

[0051] 1. Pods belonging to a PodGroup whose current scheduling failure count exceeds a threshold will be prioritized for queuing:

[0052] 1. The higher the percentage of scheduling failures exceeding the threshold, the higher the priority for queuing.

[0053] 2. If the percentage of scheduling failures is the same, then sort the Pods based on their priority.

[0054] 3. If the percentage of scheduling failures is the same and the priority is the same, then sort them according to their creation time.

[0055] 4. If the percentage of scheduling failures is the same, the priority is the same, and the creation time is the same, then the natural ordering of the combination of namespace and name will be used.

[0056] 2. If the current scheduling failure count of the PodGroup containing the Pod does not exceed the threshold or is empty, then the queuing rules follow the original algorithm rules:

[0057] 1. Based on priority comparison, higher-priority Pods will be ranked before lower-priority Pods;

[0058] 2. If the priorities are the same, the creation time of the PodGroup is compared (or the creation time of the Pod if there is no PodGroup), and the one created first is placed at the front of the queue;

[0059] 3. If the creation times are the same, the natural ordering of the combination of namespace and name will be used.

[0060] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, to avoid unnecessary waste of processing resources. Then, priorities are set for multiple pods in the pre-filtered PodGroups. In the cluster nodes processing the PodGroups, pods are queued from front to back based on their priorities. The pre-filtering algorithm for PodGroups includes the following steps: verifying the total number of pods in the PodGroup containing the currently processed pod; if the total number of pods is less than the minimum number of running tasks, the pod is rejected for scheduling. Verifying the minimum resource requirements of the PodGroup containing the currently processed pod; if the current cluster nodes have less than the minimum resource requirements, the pod is rejected for scheduling.

[0061] When the total number of failed scheduled pods exceeds a preset threshold, a locked node group is assigned to the PodGroup containing the currently processed pod. During the filtering phase, a node evaluation algorithm is invoked to select suitable cluster nodes and add them to the locked node group. Within the locked node group, pods are queued from highest to lowest priority. If the total number of failed scheduled pods exceeds the preset threshold, and the PodGroup containing the currently processed pod is different from the PodGroup in the locked node group, the node evaluation algorithm is invoked to select a cluster node outside the locked node group to process the PodGroup containing the currently processed pod.

[0062] Because after queuing, Pods with more than a threshold of scheduling failures will be prioritized for scheduling, the pre-filter extension point should check for any PodGroups with more than a threshold of scheduling failures. If such PodGroups exist, the corresponding PodGroup's node locking mechanism should be activated to facilitate node selection in the next filtering extension point. The optimized pre-filter algorithm is as follows:

[0063] 1. Verify the total number of Pods in PodGroupA where the Pod resides. If it is less than the minimum number of running tasks defined in PodGroupA, then directly refuse to schedule this Pod.

[0064] 2. Verify the scheduling failure cache queue. If the queue is not empty and the node group locking mechanism is not currently enabled, retrieve the PodGroupB at the head of the queue and mark PodGroupB to enable the node group locking mechanism.

[0065] 3. If PodGroupA (the PodGroup where the currently scheduled Pod resides) is different from PodGroupB (the PodGroup that starts the locking node group), verify the minimum resource requirement defined by PodGroupA. Note that resource requests can only be made on nodes outside the locking node group. If the current cluster resources do not meet the requirements, the scheduling is rejected. At the same time, if PodGroupA defines a maximum number of scheduling failures, update the status field of PodGroupA and increment the current number of scheduling failures by 1. By using both rejection and satisfaction caches, all Pods within the PodGroup only need to verify their resource requirements once.

[0066] 4. If PodGroupA and PodGroupB are the same, it means that the current PodGroup has started the node group locking mechanism and needs to be scheduled. It can be directly filtered.

[0067] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods in the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The pre-filtering algorithm for PodGroups includes the following steps: verifying the total number of pods in the PodGroup containing the currently processed pod; if the total number of pods is less than the minimum number of running tasks, the pod is rejected for scheduling. Verifying the minimum resource requirements of the PodGroup containing the currently processed pod; if the current cluster nodes have less than the minimum resource requirements, the pod is rejected for scheduling.

[0068] When the total number of failed scheduled pods exceeds a preset threshold, a locked node group is assigned to the PodGroup containing the currently processed pod. During the filtering phase, a node evaluation algorithm is invoked to select suitable cluster nodes and add them to the locked node group. Within the locked node group, pods are queued from highest to lowest priority. Priorities are set according to the percentage of failed scheduled pods exceeding the preset threshold.

[0069] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods within the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. When multiple pods have the same priority, they are sorted according to the creation time of the PodGroup they belong to.

[0070] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, thus avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods within the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. If multiple pods have the same priority, they are sorted according to the creation time of the PodGroup they belong to. If multiple pods have the same priority and the PodGroups they belong to have the same creation time, they are sorted according to their names.

[0071] It is understandable that when there are sequences A1, A2, A3 and B1, B2, B3, where A1, A2, A3 belong to PodGroupA and B1, B2, B3 belong to PodGroupB, assuming that PodGroupA has the same priority and creation time as PodGroupB, even if the pods received by the scheduler are in a random order, such as A2, A3, B1, B2, A1, B3, the queue sorting method using the Coscheduling plugin in this Kubernetes embodiment will automatically sort the sequences by name to A1, A2, A3, B1, B2, B3, which can significantly improve processing efficiency. Of course, this embodiment is merely an example; other methods of sorting by name also fall within the scope of this invention, and this embodiment does not limit them. That is, arranging a PodGroup by priority, by creation time, or by name is all within the scope of this invention.

[0072] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups where the total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes are less than the minimum resource requirement of the PodGroup, avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods in the pre-filtered PodGroups. Within the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The pre-filtering algorithm for PodGroups includes the following steps: verifying the total number of pods in the PodGroup containing the currently processed pod; if the total number of pods is less than the minimum number of running tasks, the pod is rejected for scheduling. Verifying the minimum resource requirement of the PodGroup containing the currently processed pod; if the current cluster nodes are less than the minimum resource requirement, the pod is rejected for scheduling. When the total number of failed pod scheduling attempts exceeds a preset threshold, a locked node group is allocated to the PodGroup containing the currently processed pod.

[0073] The original Coscheduling plugin algorithm did not use filtering extension points. The optimized solution uses filtering extension points to implement the node selection algorithm logic after the node group locking mechanism is started. To select the optimal node, the Kubernetes scheduler needs to consider the total resources of the nodes, the total available resources, node pressure, node affinity / anti-affinity, taints and tolerance strategies when selecting nodes. These strategies are configured in the cluster through plugins. For each node, the scheduler will call these filtering plugins in the order they are configured. If any filtering plugin marks a node as infeasible, the remaining filtering plugins will not be called for that node. Nodes can be evaluated simultaneously at this stage.

[0074] The optimized technical solution algorithm logic is as follows:

[0075] 1. Verify whether the locking node group mechanism is currently enabled. If it is enabled, obtain the PodGroupB corresponding to the enabled locking node group mechanism. If the PodGroupA corresponding to the current Pod is the same as PodGroupB, it means that the PodGroup to which the current Pod belongs has enabled the locking node group mechanism. Determine whether the resources of the PodGroup corresponding to the enabled locking node group mechanism meet the requirements.

[0076] If the conditions are not met, it means that node selection is required. The node evaluation algorithm of the Kubernetes scheduler is called to select a reasonable node and add it to the locked node group.

[0077] If the condition is met, it means that the current locking node group mechanism has completed the locking, and a success message will be returned directly.

[0078] If the PodGroupA and PodGroupB corresponding to the current Pod are different, it means that the current Pod may need to be temporarily scheduled to give way to the locking node group mechanism. Therefore, it is necessary to determine whether the resources of the PodGroup corresponding to the current Pod Group that has started the locking node group mechanism are sufficient.

[0079] If the conditions are not met, it means that scheduling needs to be temporarily suspended; if it fails, all nodes are filtered out, and the PodGroup A corresponding to the current Pod is re-enqueued for scheduling.

[0080] If the condition is met, it means that no temporary scheduling is needed, and a success message is returned.

[0081] For performance reasons, two PodGroup caches are designed to indicate whether all PodGroups are temporarily scheduled due to the startup of the node group locking mechanism; in this way, Pods in the same PodGroup only need to be checked once.

[0082] 2. If the node group locking mechanism is not enabled, there is no need to filter nodes; simply return success.

[0083] In one embodiment, firstly, a pre-filtering algorithm is used to pre-filter PodGroups. This can be understood as filtering PodGroups whose total number of pods is less than the minimum number of running tasks, or filtering PodGroups where the current cluster nodes have less than the minimum resource requirements of the PodGroup, avoiding unnecessary waste of processing resources. Then, priorities are assigned to the pods within the pre-filtered PodGroups. In the cluster nodes processing the PodGroups, pods are queued from highest to lowest priority. The method for queue sorting in Kubernetes using the Coscheduling plugin includes: a pre-filtering phase, a filtering phase, a post-filtering phase, and an permission phase.

[0084] The post-filtering algorithm logic of the Coscheduling scheduling plugin is as follows:

[0085] 1. If no available nodes are available during the pre-filtering or filtering phase, this algorithm is invoked.

[0086] 2. If the minimum number of running tasks in the PodGroup containing the current Pod has already met the condition, then it is not necessary to reject all Pods in the entire PodGroup;

[0087] 3. If the minimum number of running tasks required by the PodGroup to which the current Pod is located has exceeded 90%, then it is not necessary to reject all Pods in the entire PodGroup. The purpose of doing this is to avoid filtering out PodGroups that are about to be scheduled.

[0088] 4. Otherwise, reject all Pods in the same PodGroup.

[0089] During the permission phase, the permission algorithm logic of the Coscheduling scheduling plugin is the core of the entire plugin. Through the delay binding function of the Permit plugin, it ensures that all Pods in the same PodGroup wait when cluster resources are insufficient, and the number of waiting Pods accumulates to meet the minimum running requirement.

[0090] When the number of tasks is large, all Pods of the same PodGruop are bound and created together.

[0091] The algorithm logic is as follows:

[0092] 1. Obtain the scheduling timeout set in the plugin.

[0093] 2. Determine the number of Pods in the PodGruop that can run but are currently in a waiting state. If the number is less than the minimum number of running tasks, then although this Pod can run, it needs to wait. Set its state to waiting and set a timeout.

[0094] 3. If the number of Pods in the waiting state is greater than or equal to the minimum number of running tasks, then this PodGruop process group meets the scheduling conditions and notifies the Pods in the waiting state to enter the permitted state. The technical solution after optimizing the binding cycle needs to add the function of releasing locked node groups to prevent nodes in locked node groups from being unable to participate in cluster scheduling.

[0095] 1. Obtain the scheduling timeout set in the plugin;

[0096] 2. Determine the number of Pods in the PodGruop that can run but are currently in a waiting state. If the number is less than the minimum number of running tasks, then although this Pod can run, it needs to wait. Set its state to waiting and set a timeout.

[0097] 3. If the number of Pods in the waiting state is greater than or equal to the minimum number of running tasks, then this PodGruop process group meets the scheduling conditions, notifies the Pods in the waiting state to enter the permitted state, and thus performs the binding cycle; then the node tag of the locked node group is deleted, so that the locked node group can participate in the node scheduling of the entire cluster.

[0098] In one embodiment, the method for implementing queue sorting using the Coscheduling plugin in Kubernetes further includes an anti-retention phase. The anti-retention algorithm logic of the Coscheduling scheduling plugin in the anti-retention phase is as follows:

[0099] 1. If a Pod is set to a waiting state during the Permit phase and the set timeout period is exceeded, the UnReserve algorithm will be entered.

[0100] 2. Reject all Pods in the PodGroup containing the current Pod to prevent the remaining Pods from waiting in vain for a long time.

[0101] The present invention also provides a system for implementing queue sorting in Kubernetes using the Coscheduling plugin, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method for implementing queue sorting in Kubernetes using the Coscheduling plugin as described above.

[0102] The processor and memory can be connected via a bus or other means.

[0103] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor 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.

[0104] It should be noted that the system in Kubernetes that uses the Coscheduling plugin to implement queue sorting in this embodiment may include a business processing module, an edge database, a server version information register, and a data synchronization module. When the processor executes the computer program, it implements the method of implementing queue sorting in Kubernetes using the Coscheduling plugin as described above.

[0105] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] Furthermore, one embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions that are executed by a processor or controller, for example, by a processor in the above-described terminal embodiment, such that the processor executes the queue sorting method implemented in Kubernetes using the Coscheduling plugin in the above-described embodiment.

[0107] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0108] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

[0109] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for implementing queue sorting using the Coscheduling plugin in Kubernetes, characterized in that, Includes the following steps: Use a pre-filtering algorithm to pre-filter PodGroups; Set priorities for multiple Pods in the PodGroup that have passed the pre-filter; In the cluster nodes processing the PodGroup, the Pods are queued from front to back based on their priority. Also includes: After adding the maximum number of scheduling failures field to PodGroup, the corresponding queue sorting algorithm rules are adjusted as follows: Pods belonging to a PodGroup that have experienced more than a threshold of scheduling failures will be prioritized for queuing. The higher the percentage of scheduling failures exceeding the threshold, the higher the priority for queuing. If the percentage of scheduling failures exceeds the threshold is the same, then the Pods are sorted based on their priority. If the percentage of scheduling failures exceeding the threshold is the same and the priority is the same, then sorting is based on the creation time. If the percentage of scheduling failures exceeding the threshold is the same, the priority is the same, and the creation time is the same, then the natural ordering of the combination of namespace and name will be used; If the current scheduling failure count of the PodGroup containing the Pod does not exceed the threshold or is empty, then the queuing rule follows the original algorithm rule: Based on priority-based comparison, higher-priority Pods will be ranked before lower-priority Pods; If the priorities are the same, the creation time of the PodGroup is compared, and the one created first is placed at the front of the queue; If creation times are the same, the natural ordering of the namespace and name combination will be used; The step of using a pre-filtering algorithm to pre-filter PodGroups includes the following steps: Verify the minimum resource requirement of the PodGroup containing the currently processed Pod. If the current cluster node has less than the minimum resource requirement, refuse to schedule the Pod. When the total number of failed pod scheduling attempts exceeds a preset threshold, a locked node group is allocated to the PodGroup containing the currently processed pod. During the filtering phase, a node evaluation algorithm is invoked to select suitable cluster nodes and include them in the locked node group. In the locked node group, the Pods are queued from front to back based on their priority. When the total number of failed scheduling of the Pod exceeds a preset threshold, and the PodGroup containing the currently processed Pod is different from the PodGroup in the locked node group, the node evaluation algorithm is invoked to select a cluster node outside the locked node group to process the PodGroup containing the currently processed Pod. In the post-filtering stage, the logic of the post-filtering algorithm is as follows: If no available nodes are available during the pre-filtering or filtering phase, then this post-filtering algorithm is invoked. If the minimum number of running tasks in the PodGroup containing the current Pod has already met the condition, then it is not necessary to reject all Pods in the entire PodGroup; If the minimum number of running tasks required by the PodGroup to which the current Pod belongs exceeds 90%, then all Pods in the entire PodGroup will not be rejected. Otherwise, reject all Pods in the same PodGroup.

2. The method for implementing queue sorting in Kubernetes using the Coscheduling plugin according to claim 1, characterized in that, The pre-filtering of PodGroups using a pre-filtering algorithm includes the following steps: Verify the currently processed If the total number of Pods in the PodGroup to which the Pod belongs is less than the minimum number of running tasks, the Pod will not be scheduled.

3. A method for implementing queue sorting in Kubernetes using the Coscheduling plugin according to claim 1, characterized in that, Priority is set according to the percentage of Pod scheduling failures that exceed a preset threshold.

4. A system for implementing queue sorting in Kubernetes using the Coscheduling plugin, characterized in that, include: The memory, the processor, and the computer program stored on the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method for queue sorting in Kubernetes using the Coscheduling plugin as described in any one of claims 1 to 3.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform a queue sorting method in Kubernetes using the Coscheduling plugin as described in any one of claims 1 to 3.

Images