Resource scheduling method, resource scheduling system and device

Abstract

The present invention discloses a resource scheduling method, a resource scheduling system, a device and a computer-readable storage medium, wherein the resource scheduling method includes obtaining a scheduling object from a scheduling queue; when the scheduling object is a custom resource, the custom resource is disassembled according to the current resource state to obtain a scheduling unit list, and the scheduling unit list includes a first scheduling unit for constituting the custom resource; and the first scheduling units in the scheduling unit list are scheduled in sequence. It is suitable for a Kubernetes scheduling platform. When scheduling, if the scheduling object is a CRD, the CRD is disassembled according to the current resource state to obtain a scheduling unit list, and the scheduling unit list includes a Pod collection, so that the Kubernetes scheduling platform can atomically schedule all Pods according to the scheduling unit list, and all Pods are scheduled in sequence according to the queue to avoid inserting other Pods, so as to ensure that the CRD can be reasonably scheduled, the scheduling efficiency is high, and the Kubernetes scheduling platform can be compatible with various business scenarios.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a resource scheduling method, a resource scheduling system, a device and a computer-readable storage medium. Background Art

[0002] As the most mainstream container orchestration and scheduling platform, Kubernetes can support the management of user-defined resources (Custom Resource Definitions, CRD) through good scalability, making it convenient for users to manage custom resources as a whole object entity. However, Kubernetes currently only supports the scheduling of Pods. A dedicated scheduler is required to schedule CRDs, which will cause resource scheduling conflicts between multiple schedulers. At the same time, the following problems will also occur: resources cannot meet the resource requests of CRDs, resulting in CRDs being unable to be scheduled; even if CRDs can be successfully scheduled, they are not scheduled according to the best resource allocation method, which will reduce operating efficiency. Summary of the invention

[0003] The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

[0004] The present invention provides a resource scheduling method, a resource scheduling system, a device and a computer-readable storage medium, which can disassemble and schedule custom resources, making the scheduling more efficient.

[0005] In a first aspect, an embodiment of the present invention provides a resource scheduling method, including:

[0006] Get the dispatch object from the dispatch queue;

[0007] When the scheduling object is a custom resource, the custom resource is disassembled according to the current resource state to obtain a scheduling unit list, wherein the scheduling unit list includes scheduling units used to constitute the custom resource;

[0008] The scheduling units in the scheduling unit list are scheduled in sequence.

[0009] In a second aspect, an embodiment of the present invention provides a resource scheduling system, including:

[0010] Scheduler, used to obtain scheduling objects from the scheduling queue;

[0011] A splitter, used for, when the scheduling object is a custom resource, splitting the custom resource according to the current resource state to obtain a scheduling unit list, wherein the scheduling unit list includes scheduling units used to constitute the custom resource;

[0012] The scheduler schedules the scheduling units in the scheduling unit list in sequence.

[0013] In a third aspect, an embodiment of the present invention provides a device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the resource scheduling method of the embodiment of the first aspect described above is implemented.

[0014] In a fourth aspect, a computer-readable storage medium provided by an embodiment of the present invention stores computer-executable instructions, and the computer-executable instructions are used to execute the resource scheduling method as described in the embodiment of the first aspect above.

[0015] The embodiment of the present invention includes: obtaining a scheduling object from a scheduling queue during resource scheduling; if the scheduling object is a custom resource, the custom resource is disassembled according to the current resource state to obtain a scheduling unit list, the scheduling unit list includes a first scheduling unit for constituting the custom resource, and then each first scheduling unit is scheduled in sequence according to the scheduling unit list. The present invention can be applied to a Kubernetes scheduling platform; if the scheduling object is a CRD during scheduling, the CRD is disassembled according to the current resource state to obtain a scheduling unit list, the scheduling unit list includes a collection of Pods, so that the Kubernetes scheduling platform can atomically schedule all Pods according to the scheduling unit list, and all Pods are scheduled in sequence according to the queue to avoid inserting other Pods, thereby ensuring that the CRD can be reasonably scheduled and the scheduling efficiency is high, so that the Kubernetes scheduling platform can be compatible with various business scenarios.

[0016] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention and do not constitute a limitation on the technical solution of the present invention.

[0018] Figure 1 is a schematic diagram of a system architecture platform provided by an embodiment of the present invention;

[0019] Figure 2 is a flow chart of a resource scheduling method provided by an embodiment of the present invention;

[0020] Figure 3 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0021] Figure 4 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0022] Figure 5 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0023] Figure 6 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0024] Figure 7 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0025] Figure 8 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0026] Fig. 9 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0027] Fig.10 is a flow chart of a resource scheduling method provided by another embodiment of the present invention;

[0028] Fig.11 It is a flow chart of a resource scheduling method provided by another embodiment of the present invention. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0030] It should be noted that, although the functional modules are divided in the device schematic 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 device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims or the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0031] Kubernetes is an open source platform for managing containerized applications on multiple hosts in a cloud platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient. Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance. In Kubernetes, you can create multiple containers, each of which runs an application instance. Then, through the built-in load balancing strategy, you can manage, discover, and access this group of application instances. These details do not require the operation and maintenance personnel to perform complex manual configuration and processing. Kubernetes has a wide range of applications. Many cloud computing, artificial intelligence and other platforms of enterprises or research institutions are implemented based on Kubernetes. Kubernetes supports the management of user-defined resources (Custom Resource Definitions, CRD) through good scalability, which makes it convenient for users to manage custom resources as a whole object entity.

[0032] However, Kubernetes currently only supports the scheduling of Pods. Pods are the smallest unit that can be created and deployed in Kubernetes. They are an application instance in a Kubernetes cluster and are always deployed on the same node. Pods contain one or more containers, as well as resources shared by each container, such as storage and network. Kubernetes scheduling of CRDs requires a dedicated scheduler, which can cause resource scheduling conflicts between multiple schedulers.

[0033] The Kubernetes default scheduler only supports the scheduling of Pods, but does not support the scheduling of CRD objects. The Kubernetes default scheduler cannot automatically and reasonably decompose the CRD objects into Pods according to the current resource status. The present invention provides a resource scheduling method, a resource scheduling system, a device and a computer-readable storage medium. During resource scheduling, a scheduling object is obtained from a scheduling queue. If the scheduling object is a custom resource, the custom resource is decomposed according to the current resource status to obtain a scheduling unit list. The scheduling unit list includes a first scheduling unit for constituting a custom resource, and then each first scheduling unit is scheduled in sequence according to the scheduling unit list. The resource scheduling method can be applied to a Kubernetes scheduling platform. The first scheduling unit is a CRD object. During scheduling, if the scheduling object is a CRD, the CRD is decomposed according to the current resource status to obtain a scheduling unit list. The scheduling unit list includes a collection of Pods. In this way, the Kubernetes scheduling platform can atomically schedule the Pod according to the scheduling unit list, and all Pods are scheduled in sequence according to the queue to avoid inserting other Pods. This ensures that the CRD can be reasonably scheduled, and the scheduling efficiency is high, so that the Kubernetes scheduling platform can be compatible with various business scenarios.

[0034] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the embodiments described below are only some embodiments of the present invention, not all embodiments.

[0035] See also Figure 1 As shown, Figure 1 1 is a schematic diagram of a system architecture platform 100 for executing a resource scheduling method provided by an embodiment of the present invention. The system architecture platform 100 is also a resource scheduling system.

[0036] exist Figure 1 In the illustrated embodiment, the system architecture platform 100 includes a scheduler 110 and a splitter 120, wherein the scheduler 110 is used to schedule the scheduling object, and the splitter 120 is used to respond to the disassembly request of the scheduler 110 and disassemble the scheduling object to meet the scheduling requirements of the scheduler 110. Specifically, during scheduling, the scheduler 110 obtains the scheduling object from the scheduling queue. When the scheduling object is a custom resource, the splitter 120 can disassemble the custom resource according to the current resource state to obtain a scheduling unit list, and the scheduling unit list includes a first scheduling unit for constituting the custom resource. The scheduler 110 schedules the first scheduling unit in the scheduling unit list in sequence according to the scheduling unit list, thereby completing the scheduling of the custom resource.

[0037] like Figure 1 As shown in the figure, the Kubernetes scheduling platform is used as an example for explanation.

[0038] The Kubernetes scheduling system of the embodiment includes a scheduler (Scheduler) 110, a splitter (Pod-Splitor) 120 and a controller (CRD-Controller) 130.

[0039] Among them, the scheduler 110 is responsible for the scheduling of Pods, the splitter is responsible for splitting CRD objects, the first scheduling unit is a CRD object, and the second scheduling unit is a native Pod object. In this embodiment, CRD and Pod are placed in the same scheduling queue. When the scheduling object is CRD, the scheduler 110 obtains the disassembled Pod set through the extended Split interface, and uses the scheduler 110 to schedule all Pods in sequence.

[0040] The splitter 120 is a user-defined extension component that mainly responds to the disassembly request of the scheduler 110. According to the current cluster resource occupancy, it decomposes the CRD into reasonable Pods, and is responsible for creating a list of scheduling units containing these Pods, and returns the list of scheduling units to the scheduler 110 for scheduling; at the same time, the splitter 120 can respond to the node binding request of the scheduler 110 to complete the binding operation of the Pod and the node. Among them, the binding of the Pod and the node can be understood as adding some node information and resource information to the Pod object, and then the scheduling system will have a special component to run the Pod on the corresponding node according to this binding information.

[0041] Controller 130 is a user-defined extension component used for the status and lifecycle management of a specific CRD. The CRD status is updated according to the status of the CRD and the corresponding Pod, and the CRD lifecycle is maintained according to user commands or CRD's own policies, such as the CRD lifecycle ends after the Pod ends normally. Controller 130 is a functional component of the Kubernetes scheduling platform and will not be described here.

[0042] In addition, the user creates CRD and Pod objects through Api-Server 140, and the scheduler 110 monitors the binding information of CRD and Pod objects through Api-Server. After completing the scheduling of all Pods, the splitter 120 completes the binding of Pods and nodes through Api-Server.

[0043] In addition, the scheduler 110 currently has two extension methods: Extender and Scheduling Framework. A Split interface is added to the original extension interface. When the scheduler 110 schedules CRD, the Pod set after CRD disassembly is obtained through the Split interface. Among them, the extender extends the scheduler 110 through the web hook method, and the scheduling framework directly compiles the extension interface into the scheduler 110. In order to reasonably split the CRD resources, the embodiment of the present invention introduces a new extension interface, namely the Split interface, which is used to realize the splitting of CRD resource objects and convert CRD into a set of Pods. Different CRD resources may be split in different ways. The specific Split interface implementation is carried out in the Extender or Scheduling Framework, which is mainly responsible for two parts of work: using a certain strategy to split this CRD into a set of 1 to N Pods, and allocating a specific number of resources for each Pod; during the splitting process, it is necessary to determine whether the remaining resources of the cluster node can meet the splitting requirements, such as GPU, CPU resources, etc.; if not, an error message is returned to the scheduler 110; if both are satisfied, the split Pod set is returned.

[0044] When the scheduling system is scheduling, if the scheduling object is CRD, the CRD is disassembled according to the current resource status to obtain a scheduling unit list. The scheduling unit list includes a Pod set. In this way, the Kubernetes scheduling platform can schedule the Pod according to the scheduling unit list, and all Pods are scheduled in sequence according to the queue to avoid inserting other Pods. This ensures that CRD can be scheduled reasonably and efficiently, making the Kubernetes scheduling platform compatible with various business scenarios.

[0045] It should be noted that when the scheduling object is a Pod, it is processed according to the scheduling process of the original Kubernetes scheduling system, but the Pod binding operation is completed by the splitter 120; when the scheduling object is a CRD, the splitter 120 will disassemble the Pod according to the resource status of the current cluster, and disassemble the CRD into one or more Pods. The splitter 120 only needs to determine the number of Pods that the CRD needs to be disassembled, and the resources (CPU, memory, GPU) used by a certain Pod. After the splitter 120 splits the CRD, the scheduler 110 completes the scheduling of these Pods. The scheduler 110 will filter, prioritize, score and other optimization algorithms to select suitable nodes for the Pod, so that the Pod in the Pod list is bound to the node through the splitter 120, which can ensure the synchronization of resources between the scheduler 110 and the splitter 120.

[0046] In this way, the scheduler 110 of the Kubernetes scheduling platform can support the mixed scheduling of CRDs and Pods and the atomic scheduling of Pods of a single CRD. It can be understood that when CRDs and Pods are mixed, the scheduler 110 reads the configuration to know which CRDs are involved in the scheduling, and the scheduler 110 puts the Pods and the CRDs to be scheduled into the same scheduling queue; when the object scheduled by the scheduler 110 is CRD, it is necessary to obtain the list of Pod objects after the CRD object is disassembled through the extended Split interface, and schedule each Pod in turn, thereby realizing the mixed scheduling of CRDs and Pods.

[0047] CRD's Pod atomic scheduling can be understood as, when scheduling the Pod set decomposed from CRD, other Pods cannot be scheduled. The Pod set decomposed from CRD must all be scheduled successfully to be considered successful, otherwise it will fail. This avoids the failure of the entire CRD scheduling due to insufficient remaining resources.

[0048] It should be noted that CRD scheduling has a backoff mechanism, which can be understood as if any Pod in the CRD fails to schedule, the entire CRD scheduling is considered to have failed. If CRD scheduling fails, the Pod that has been successfully scheduled in the CRD needs to be deleted and resources released. In addition, CRD decomposition Pod has a reentry protection function. The scheduling queue of the scheduler 110 stores CRD objects and Pod objects, and the Pod set belonging to the CRD object does not need to be inserted into the scheduling queue.

[0049] It should be noted that the scheduler 110 and the splitter 120 have a resource synchronization mechanism. To reasonably and optimally split the CRD, the splitter 120 needs to know the resource status of the cluster, monitor the node and Pod information, and cache the allocatable resource information locally. After the Pod set of the CRD is successfully scheduled by the scheduler 110, the scheduler 110 sends a Pod binding (Bind) request to the splitter 120. After receiving the binding request, the splitter 120 first updates the node allocatable resource information cached locally by the splitter 120, and then sends the final binding request to the Api-Server 140, so that the resource synchronization can be achieved.

[0050] The system architecture platform 100 and application scenarios described in the embodiment of the present invention are intended to more clearly illustrate the technical solution of the embodiment of the present invention, and do not constitute a limitation on the technical solution provided by the embodiment of the present invention. Those skilled in the art will appreciate that with the evolution of the system architecture platform 100 and the emergence of new application scenarios, the technical solution provided by the embodiment of the present invention is equally applicable to similar technical problems.

[0051] It can be understood by those skilled in the art that Figure 1 The system architecture platform 100 shown in the figure does not constitute a limitation on the embodiments of the present invention, and may include more or fewer components than those shown in the figure, or a combination of certain components, or a different arrangement of components.

[0052] Based on the above system architecture platform 100, various embodiments of the resource scheduling method of the present invention are proposed below.

[0053] See also Figure 2 As shown, Figure 2 It is a flowchart of a resource scheduling method provided by an embodiment of the present invention. The resource scheduling method includes but is not limited to step S100, step S200 and step S300.

[0054] Step S100, obtaining a scheduling object from a scheduling queue.

[0055] In one embodiment, resource scheduling can be understood as the reasonable and effective use of various resources. It can be understood that the scheduling object is the resource object, and the schedulable objects are arranged in the form of queues. During scheduling, they are called according to the order or priority of the queue to obtain the scheduling object, which facilitates the rapid acquisition of the scheduling object and is also conducive to the reasonable scheduling of resources.

[0056] Taking the Kubernetes scheduling platform as an example, the Kubernetes scheduling platform provides many default resource types, such as Pod, Deployment, Service, Volume, etc., which can meet most daily system deployment and management needs. However, in some special demand scenarios, these existing resource types cannot meet them. In this case, CRD can be used to meet these needs, effectively improving the scalability of Kubernetes.

[0057] It should be noted that the Kubernetes scheduling platform supports the scheduling of Pods, which means that Pods can be scheduled directly. It can be understood that CRD and Pod objects can be inserted into the same scheduling queue at the same time, or CRD can be scheduled separately. Specifically, when CRD and Pod are mixed, the scheduler of the Kubernetes scheduling platform reads the configuration to obtain the CRD objects and Pod objects that can participate in the scheduling. The scheduler puts the Pod and the CRD to be scheduled into the same scheduling queue, and obtains the scheduling objects from the scheduling queue in turn through the scheduler for scheduling.

[0058] Step S200: When the scheduling object is a custom resource, the custom resource is disassembled according to the current resource state to obtain a scheduling unit list.

[0059] Among them, the scheduling unit list includes the first scheduling unit used to constitute a custom resource, the custom resource is CRD, and the first scheduling unit is a CRD object. It can be understood that CRD objects and native Pod objects can be inserted into the same scheduling queue at the same time, that is, CRD objects and Pod objects can be mixed for scheduling. When CRD and Pod are mixed for scheduling, the scheduler obtains the scheduling objects from the scheduling queue in sequence. When scheduling, the scheduler will first determine the type of scheduling object. If the scheduling object is CRD, the CRD will be disassembled according to the current resource status to obtain a scheduling unit list. The scheduling unit list is a Pod list that constitutes CRD, that is, CRD is split into a Pod set, so that the Kubernetes scheduling platform can directly schedule the Pod according to the Pod list.

[0060] It can be understood that the CRD needs to be disassembled according to the current resource status, which can be understood as the remaining resources or available resources of the current scheduling platform. When the resource request for disassembling the CRD is met, the CRD object is reasonably split through the splitter, so that the CRD can be scheduled according to the best resource allocation method and the operation efficiency is higher.

[0061] It should be noted that when the scheduling object is a native Pod, the Pod can be scheduled directly without disassembling it. It is understandable that Pod is the basic unit of the Kubernetes scheduling platform, the smallest component created or deployed by the user, and the resource object for running containerized applications. Other resource objects in the Kubernetes cluster are all supporting the pod resource object to achieve the purpose of Kubernetes managing application services. In this way, the Kubernetes scheduling platform supports the mixed scheduling of Pods and CRDs, while realizing the atomic scheduling of Pods with a single CRD, and also ensuring that CRDs can be reasonably scheduled and compatible with various business scenarios.

[0062] Step S300, scheduling the scheduling units in the scheduling unit list in sequence.

[0063] In one embodiment, a scheduling unit list is generated after the disassembly is completed. In the Kubernetes scheduling platform, the scheduling unit is a Pod, and the scheduling unit list is a Pod collection list. According to the Pod collection list, the scheduler schedules all the Pods in the Pod collection list in sequence, thereby completing the scheduling of a single CRD. It can be understood that scheduling all Pods in sequence in the form of a list can avoid the failure of the entire CRD scheduling due to the insertion of other Pods, which causes the remaining Pods in the list to be unable to be scheduled due to insufficient remaining resources; it can also avoid the problem that when scheduling some Pods of a CRD, some Pods of another CRD are inserted, which may cause the remaining Pods of the two CRDs to be unable to be scheduled due to insufficient remaining resources, and the occupied resources cannot be released, and the two CRDs will enter a resource deadlock state.

[0064] In one embodiment, in step S200, the custom resource is disassembled according to the current resource status to obtain a scheduling unit list, which may include but is not limited to the following steps:

[0065] Step S210: When the remaining resources of the cluster nodes meet the requirements for disassembling the custom resources, the custom resources are disassembled to obtain a scheduling unit list.

[0066] In one embodiment, in the Kubernetes scheduling platform, the splitter mainly responds to the scheduler's disassembly request, decomposes the CRD into reasonable Pods according to the resource usage of the current cluster nodes, and is responsible for creating a scheduling unit list containing these Pods, and returns the scheduling unit list to the scheduler for scheduling. It can be seen that the splitter can obtain the resource status of the cluster nodes, for example, by monitoring the binding status of the cluster nodes to obtain the resource status, and reasonably disassemble the CRD according to the resource status to meet the optimal disassembly CRD requirements.

[0067] In this way, the splitter can efficiently and reasonably split CRD while fully considering the status of resources. At the same time, the scheduler does not need to understand CRD and can focus on the scheduling of Pods to achieve the splitting and scheduling of CRD.

[0068] It should be noted that CRD decomposition Pod has a reentry protection function. The scheduler's scheduling queue stores CRD objects and Pod objects. The Pod set belonging to the CRD object does not need to be inserted into the scheduling queue.

[0069] See also Figure 3 In one embodiment, the resource scheduling method further includes but is not limited to the following steps:

[0070] Step S101: creating a scheduling object according to a scheduling request;

[0071] Step S102: monitoring the binding information of the scheduling object, and putting the newly added scheduling object into the same queue to form a scheduling queue.

[0072] It can be understood that users create CRD objects and Pod objects according to the actual needs of the application scenario, such as the need for deep learning CRD. Users create CRD objects and Pod objects through Api-Server, and the scheduler listens to the binding information of CRD objects and Pod objects through Api-Server, and puts the schedulable CRDs and Pods into the same queue. CRDs and Pods are added to the queue to form a scheduling queue, and then the scheduling objects are obtained from the scheduling queue. The added scheduling objects can be CRDs and Pods, or all CRDs or all Pods.

[0073] See also Figure 4 In one embodiment, the resource scheduling method further includes but is not limited to the following steps:

[0074] Step S400: After completing the scheduling of all scheduling objects, bind the scheduling unit to the corresponding node.

[0075] In one embodiment, the Kubernetes scheduling platform can reasonably disassemble the CRD when scheduling the CRD object, and return the scheduling unit list to the scheduler for scheduling. The scheduler only needs to focus on the scheduling of the Pod to complete the scheduling of all scheduling objects. After all scheduling objects are scheduled, the scheduler sends a node binding request to the splitter, and the splitter can respond to the node binding request of the scheduler to complete the binding operation of the Pod and the node. Specifically, the splitter completes the binding of the Pod and the node through the Api-Server.

[0076] In one embodiment, the resource scheduling method further includes but is not limited to the following steps:

[0077] Step S500: When any scheduling unit fails to schedule, the scheduled scheduling unit is deleted and resources are released.

[0078] In the embodiment, if any Pod in the Pod set of the CRD fails to be scheduled, the entire CRD scheduling is considered to have failed. If the CRD scheduling fails, the Pod that has been successfully scheduled in the CRD needs to be deleted and resources released to avoid resource occupation and reduce operating efficiency.

[0079] See also Figure 5 In one embodiment, step S400: after completing the scheduling of all scheduling objects, binding the scheduling unit to the corresponding node may include but is not limited to the following steps:

[0080] Step S410: Initiate a node binding request, and update the node's allocatable resource information, determine the optimal node according to the allocatable resource information, and allocate hosts to the scheduling units according to the optimal node;

[0081] Step S420: Bind the scheduling unit to the corresponding host.

[0082] In one embodiment, after completing the scheduling of all Pods, the splitter completes the binding of the Pods and nodes through the API-Server. The process of node binding is to select a suitable node by filtering, prioritizing, scoring and other optimization algorithms, and then rotate the best node to assign a host to the pod, and send a binding request for the pod to the API-Server, so as to bind the Pod to the corresponding host and complete the binding operation.

[0083] It should be noted that when the scheduling object is Pod, the Kubernetes scheduling system handles it according to the original scheduling process, but the Pod binding operation is completed by the splitter; when the scheduling object is CRD, the splitter will disassemble the Pod according to the current cluster resource status, and disassemble the CRD into one or more Pods. The splitter only needs to determine the number of Pods that the CRD needs to be disassembled and the resources (CPU, memory, GPU) used by a Pod. After the splitter splits the CRD, the scheduler will complete the scheduling of these Pods. The scheduler will filter, prioritize, score and other optimization algorithms to select the appropriate node for the Pod, so as to bind the Pod in the Pod list to the node through the splitter, so as to ensure the synchronization of scheduler and splitter resources.

[0084] In addition, the scheduler and splitter have a resource synchronization mechanism. To reasonably and optimally split CRD, the splitter needs to know the resource status of the cluster, monitor the node and Pod information, and cache the allocatable resource information locally. After the Pod set of CRD is successfully scheduled by the scheduler, the scheduler sends a Pod binding request to the splitter. After receiving the binding request, the splitter first updates the node allocatable resource information in the local cache of the splitter, and then sends the final binding request to the Api-Server, so that the resources can be synchronized.

[0085] See also Figure 6 In one embodiment, taking the Kubernetes scheduling platform as an example, the resource scheduling method includes but is not limited to the following steps:

[0086] Step S610: Create CRD and Pod objects through Api-Server;

[0087] Step S620: Monitor CRD and Pod objects through Api-Server, and put the newly added CRD or Pod into the same scheduling queue;

[0088] Step S630: Obtain a scheduling object from the scheduling queue;

[0089] When the scheduling object is a Pod, it is processed according to the Pod scheduling process;

[0090] When the scheduling object is CRD, a CRD disassembly request is sent to the splitter, so that the splitter disassembles the CRD according to the current resource status and creates the disassembled Pod through the Api-Server;

[0091] Step S640: Schedule the Pods in sequence according to the Pod list returned by the splitter;

[0092] Step S650: After all Pods are scheduled, a binding request is sent to the splitter and the binding of the Pod and the node is completed through the Api-Server.

[0093] In order to more clearly illustrate the specific steps and processes of the resource scheduling method in the above-mentioned embodiments, five embodiments are used for illustration below.

[0094] Embodiment 1:

[0095] This embodiment is an example of the scheduler successfully hybrid scheduling of CRDs and Pods. The embodiment shows the process of hybrid scheduling of CRDs and Pods on the Kubernetes scheduling platform. The deep learning job is defined as a CRD, and the Workers that complete the parallel execution of the deep learning job are carried by the Pod. Hybrid scheduling of deep learning jobs and Pods can be achieved and can run successfully.

[0096] Instance environment: A Kubernetes cluster running Ubuntu 16.04, with two nodes and sufficient node resources. The cluster has deployed a modified scheduler. The controller and splitter for custom deep learning jobs are deployed.

[0097] See also Figure 7 , the specific steps are as follows:

[0098] Step S710: define a deep learning job file and create the CRD object;

[0099] Step S720: define a file for a single Pod and create the Pod object;

[0100] Step S730: After the deep learning job is successfully created, the CRD corresponding to the deep learning job is in the running state;

[0101] Step S740: After the Pods related to the deep learning job are successfully created, the Pods decomposed from the deep learning job are all in the running state.

[0102] In this way, the status of the single Pod created in step S720 is the running status, wherein the status of the CRD should be consistent with the status of the disassembled Pod.

[0103] Embodiment 2:

[0104] This embodiment shows that the scheduler successfully schedules two CRD objects. The embodiment demonstrates the process of mixed scheduling of different CRDs on the Kubernetes scheduling platform. The deep learning job is defined as CRD, and the machine learning job is defined as CRD. The Workers executed by the two CRD objects are both carried by the Pod, which can realize mixed scheduling of deep learning jobs and machine learning jobs and both can run successfully.

[0105] Instance environment: A Kubernetes cluster running Ubuntu 16.04, with two nodes and sufficient node resources. The cluster has deployed a modified scheduler. The controller and splitter for custom deep learning jobs have been deployed. The controller and splitter for custom machine learning jobs have been deployed.

[0106] See also Figure 8 , the specific steps are as follows:

[0107] Step S810: define the file of the deep learning job and create the CRD object;

[0108] Step S820: define the file of the machine learning job and create the CRD object;

[0109] Step S830: After the deep learning job is successfully created, the CRD corresponding to the deep learning job is in the running state;

[0110] Step S840: After the Pods related to the deep learning job are successfully created, the Pods decomposed from the deep learning job are all in the running state;

[0111] Step S850: After the machine learning job is successfully created, the CRD corresponding to the deep learning job is in the running state;

[0112] Step S860: After the Pods related to the machine learning job are successfully created, the Pods decomposed from the deep learning job are all in the running state.

[0113] The status of the CRD should be consistent with the status of the disassembled Pod.

[0114] Embodiment three:

[0115] This embodiment is that the scheduler schedules CRD to run on the least nodes. The embodiment shows that when scheduling CRD objects on the Kubernetes scheduling platform, CRD can be reasonably disassembled according to the resource status, and the deep learning job is defined as CRD. The Workers that complete the parallel execution of the deep learning job are carried by the Pod. When scheduling CRD, the scheduler can automatically disassemble the CRD according to the current resource status and schedule the CRD Pod to run on a very small node, thereby reducing network overhead and ensuring the rationality of the disassembly.

[0116] Instance environment: A Kubernetes cluster running Ubuntu 16.04, consisting of three nodes with sufficient CPU and memory resources. Node 1 has eight idle GPUs, and nodes 2 and 3 each have four idle GPUs. The cluster has deployed a modified scheduler. A custom deep learning job controller and splitter have been deployed.

[0117] See also Fig. 9 , the specific steps are as follows:

[0118] Step S910: define a file for a deep learning job, where the job applies for 8 GPU resources and creates the CRD object;

[0119] Step S920: After the deep learning job is successfully created, the CRD corresponding to the deep learning job is in the running state;

[0120] Step S930: After the Pods related to the deep learning job are successfully created, the Pods decomposed from the deep learning job are all in the running state;

[0121] Step S940: The number of Pods after CRD decomposition is 1, and the Pod runs on node 1.

[0122] Embodiment 4:

[0123] This embodiment shows that the scheduler successfully schedules a CRD with a large resource application granularity. The embodiment shows that when scheduling CRD objects on the Kubernetes scheduling platform, the CRD can be reasonably disassembled according to the resource status. The deep learning job is defined as a CRD, and the Workers that complete the parallel execution of the deep learning job are carried by the Pod. When scheduling the CRD, the scheduler can automatically disassemble the CRD according to the current resource status. If the resource application granularity of the job is large, the single-node resources cannot meet the resource application of the job, but when the total resources of the cluster can meet the requirements, the CRD can be successfully disassembled and successfully scheduled and run, ensuring that the job will not be in a resource starvation state.

[0124] Instance environment: A Kubernetes cluster running Ubuntu 16.04, consisting of 4 nodes with sufficient CPU and memory resources. Nodes 1 and 3 have 4 free GPUs, and nodes 2 and 4 have 2 free GPUs. The cluster has deployed a modified scheduler. A custom deep learning job controller and splitter have been deployed.

[0125] See also Fig.10 , the specific steps are as follows:

[0126] Step S1010: define a file for a deep learning job, where the job applies for 8 GPU resources and creates the CRD object;

[0127] Step S1020: After the deep learning job is successfully created, the CRD corresponding to the deep learning job is in the running state;

[0128] Step S1030: After the Pods related to the deep learning job are successfully created, the Pods decomposed from the deep learning job are all in the running state;

[0129] Step S1040: The number of Pods after CRD decomposition is 2, and two Pods are running on Node 1 and Node 3.

[0130] Embodiment five:

[0131] This embodiment shows that the scheduler atomically schedules the Pod after the CRD is disassembled. The embodiment shows that in the Kubernetes scheduling platform, the scheduler can schedule the Pod of a single CRD object, define the deep learning job as CRD, and define the machine learning job as CRD. The Workers executed by the two CRD objects are both carried by the Pod, which can achieve atomic scheduling of the CRD Pod and avoid unreasonable scheduling of CRDs and the problem of resource deadlock between the two CRDs.

[0132] Instance environment: A Kubernetes cluster running Ubuntu 16.04, consisting of 3 nodes with sufficient CPU and memory resources. All 3 nodes have 4 free GPUs. The cluster has deployed a modified scheduler. The controller and splitter for custom deep learning jobs have been deployed. The controller and splitter for custom machine learning jobs have been deployed.

[0133] See also Fig.11 , the specific steps are as follows:

[0134] Step S1110: define a file for a deep learning job, the job applies for 8 GPU resources, and creates the CRD object;

[0135] Step S1120: define a file for a machine learning job, the job applies for 8 GPU resources, and creates the CRD object;

[0136] Step S1130: After the deep learning job is successfully created, the CRD status corresponding to the deep learning job;

[0137] Step S1140: After the machine learning job is successfully created, the CRD status corresponding to the deep learning job;

[0138] Step S1150: It is obtained that only one of the deep learning job and the machine learning job is in the running state, and the related Pods of the running job are all in the running state.

[0139] In addition, an embodiment of the present invention further provides a device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor and the memory may be connected via a bus or other means.

[0140] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0141] It should be noted that the terminal in this embodiment may include: Figure 1 The system architecture platform 100 in the embodiment shown, the terminal and the Figure 1 The system architecture platform 100 in the illustrated embodiments belongs to the same inventive concept, and therefore these embodiments have the same implementation principles and technical effects, which will not be described in detail here.

[0142] The non-transient software program and instructions required to implement the resource scheduling method of the above embodiment are stored in the memory. When executed by the processor, the resource scheduling method of the above embodiment is executed, for example, the above described Figure 2 Steps S100 to S300, Figure 3 Steps S101 to S102 of the method, Figure 4 In the method step S400, Figure 5 Steps S410 to S420 of the method, Figure 6 Steps S610 to S650 of the method, Figure 7 Steps S710 to S740 of the method, Figure 8 Steps S810 to S860 of the method, Fig. 9 Steps S910 to S940 of the method, Fig.10 Steps S1010 to S1040 of the method, Fig.11 Method steps S1110 to S1150.

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

[0144] In addition, an embodiment of the present invention further provides a computer-readable storage medium, which stores computer-executable instructions. The computer-executable instructions are executed by a processor or a controller, for example, by a processor in the above terminal embodiment, so that the above processor can execute the resource scheduling method in the above embodiment, for example, execute the above described Figure 2 Steps S100 to S300, Figure 3 Steps S101 to S102 of the method, Figure 4 In the method step S400, Figure 5 Steps S410 to S420 of the method, Figure 6 Steps S610 to S650 of the method, Figure 7 Steps S710 to S740 of the method, Figure 8 Steps S810 to S860 of the method, Fig. 9 Steps S910 to S940 of the method, Fig.10 Steps S1010 to S1040 of the method, Fig.11 Method steps S1110 to S1150.

[0145] It will be appreciated by those skilled in the art that all or some of the steps and systems in the disclosed method above may be implemented as software, firmware, hardware and appropriate combinations thereof. Some physical components or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or a non-transitory medium) and a communication medium (or a temporary medium). As known to those skilled in the art, the term computer storage medium 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 include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that may be used to store desired information and may be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0146] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above-mentioned implementation mode. Technical personnel familiar with the field can also make various equivalent deformations or substitutions without violating the spirit of the present invention. These equivalent deformations or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A resource scheduling method, comprising: Get the dispatch object from the dispatch queue; When the scheduling object is a custom resource, the custom resource is disassembled according to the current resource state to obtain a scheduling unit list, wherein the scheduling unit list includes a first scheduling unit used to constitute the custom resource, wherein the custom resource is a custom resource type in Kubernetes; The first scheduling units in the scheduling unit list are scheduled in sequence.

2. The resource scheduling method according to claim 1, characterized in that: The step of disassembling the custom resource according to the current resource state to obtain a scheduling unit list includes: When the remaining resources of the cluster nodes meet the requirements for disassembling the custom resources, the custom resources are disassembled to obtain the scheduling unit list.

3. The resource scheduling method according to claim 1, characterized in that: Also includes: When the scheduling object is the second scheduling unit, the second scheduling unit is directly scheduled.

4. The resource scheduling method according to claim 3, characterized in that: Also includes: After completing the scheduling of all the scheduling objects, the first scheduling unit and the second scheduling unit are bound to corresponding nodes respectively.

5. The resource scheduling method according to claim 4, characterized in that: After completing the scheduling of all the scheduling objects, the method further includes: A node binding request is initiated, and the allocatable resource information of the node is updated, and the optimal node is determined according to the allocatable resource information.

6. The resource scheduling method according to claim 1, characterized in that: Also includes: Create a scheduling object according to the scheduling request; The binding information of the scheduling object is monitored, and the newly added scheduling object is placed in the same queue to form the scheduling queue.

7. The resource scheduling method according to claim 1, characterized in that: Also includes: When any of the first scheduling units fails in scheduling, the scheduled first scheduling unit is deleted and resources are released.

8. A resource scheduling system, characterized in that: include: Scheduler, used to obtain scheduling objects from the scheduling queue; A splitter, used for, when the scheduling object is a custom resource, disassembling the custom resource according to the current resource state to obtain a scheduling unit list, wherein the scheduling unit list includes a first scheduling unit used to constitute the custom resource, wherein the custom resource is a custom resource type in Kubernetes; The scheduler sequentially schedules the first scheduling units in the scheduling unit list.

9. The resource scheduling system according to claim 8, characterized in that: The splitter is also used to: When the remaining resources of the cluster nodes meet the requirements for disassembling the custom resources, the custom resources are disassembled to obtain the scheduling unit list.

10. The resource scheduling system according to claim 8, characterized in that: The scheduler is also used to: When the scheduling object is the second scheduling unit, the second scheduling unit is directly scheduled.

11. The resource scheduling system according to claim 10, characterized in that: The splitter is also used to: Bind the first scheduling unit and the second scheduling unit to corresponding nodes respectively.

12. The resource scheduling system according to claim 11, characterized in that: The scheduler is also used to: A binding request is initiated, and the allocatable resource information of the node is updated, and the optimal node is determined according to the allocatable resource information.

13. The resource scheduling system according to claim 8, characterized in that: The scheduler is also used to: Obtaining a scheduling request for the scheduling object; The binding information of the scheduling object is monitored, and the newly added scheduling object is placed in the same queue to form the scheduling queue.

14. The resource scheduling system according to claim 8, characterized in that: The scheduler is also used to: When any of the first scheduling units fails in scheduling, the scheduled first scheduling unit is deleted and resources are released.

15. A device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the resource scheduling method according to any one of claims 1 to 7 is implemented.

16. A computer-readable storage medium storing computer-executable instructions, characterized in that: The computer executable instructions are used to execute the resource scheduling method as described in any one of claims 1 to 7.

Images