A local disk scheduling method, device, electronic device and storage medium

Abstract

The present application discloses a scheduling method, device, electronic device and storage medium for a local disk, belonging to the technical field of cloud platforms. The method comprises: in response to a request for allocation of a local disk by a Pod to be scheduled, selecting at least one business node that meets the scheduling conditions, and obtaining the disk requirements of the Pod to be scheduled; based on the local disk information of the at least one business node and the disk requirements of the Pod to be scheduled, selecting a target local disk from the local disks of the at least one business node; then, storing identification information of the target local disk; and providing storage services for the Pod to be scheduled based on the identification information by the business node where the target local disk is located, thereby providing a solution for scheduling local disks.

Description

Technical Field

[0001] The present application relates to the technical field of cloud platforms, and in particular to a scheduling method, device, electronic device and storage medium for a local disk. Background Art

[0002] The rise of container technology has spawned a series of application orchestration management systems such as Kubernetes, Docker Swarm, and Mesosphere. Among them, Kubernetes has become a leader in the container orchestration field with its powerful application orchestration capabilities and intelligent scheduling algorithms.

[0003] The core component of Kubernetes is the native scheduler deployed on the management node. The native scheduler is mainly used to reasonably allocate node resources and schedule the orchestrated applications to the appropriate business nodes. However, the native scheduler only provides allocation and scheduling of resources such as the central processing unit (CPU), memory, and graphics processing unit (GPU) of the business node, and does not provide a scheduling solution for the local disk of the business node. Therefore, there is an urgent need to provide a solution for scheduling local disks. Summary of the invention

[0004] The embodiments of the present application provide a local disk scheduling method, device, electronic device and storage medium, which are used to provide a solution for scheduling the local disk.

[0005] In a first aspect, an embodiment of the present application provides a local disk scheduling method, including:

[0006] In response to the allocation request of the container group Pod to be scheduled for the local disk, select at least one service node that meets the scheduling conditions to obtain the disk requirement of the Pod to be scheduled;

[0007] Based on the local disk information of the at least one service node and the disk requirement, selecting a target local disk from the local disks mounted by the at least one service node;

[0008] The identification information of the target local disk is stored, and the service node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information.

[0009] In some embodiments, based on the local disk information of the at least one service node and the disk requirement, selecting a target local disk from the local disks mounted by the at least one service node includes:

[0010] Based on the local disk information of the at least one service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the at least one service node;

[0011] The target local disk is selected from the candidate local disks.

[0012] In some embodiments, the disk requirements include disk application requirements and disk hardware requirements, and the local disk information of each service node includes application scope information and hardware description information of each local disk mounted by the service node, and

[0013] Selecting a candidate local disk from local disks mounted by the at least one service node based on the disk requirement and local disk information of the at least one service node includes:

[0014] Based on the application scope information of each local disk mounted by the at least one service node, selecting a local disk whose application scope can meet the application requirement from each local disk as a primary local disk;

[0015] Based on the hardware description information of the preliminarily selected local disks, a disk whose hardware can meet the disk hardware requirement is selected from the preliminarily selected local disks as the candidate local disks.

[0016] In some embodiments, the application scope information of the local disk mounted by each service node is pre-configured through a configuration file.

[0017] In some embodiments, the service node where the target local disk is located deletes the identification information of the target local disk after providing storage services for the Pod to be scheduled.

[0018] In a second aspect, an embodiment of the present application provides a local disk scheduling device, including:

[0019] An acquisition module is used to select at least one service node that meets the scheduling conditions in response to the allocation request of the container group Pod to be scheduled for the local disk, and obtain the disk requirement of the Pod to be scheduled;

[0020] A selection module, configured to select a target local disk from local disks mounted by the at least one service node based on the local disk information of the at least one service node and the disk requirement;

[0021] The storage module is used to store the identification information of the target local disk, and the service node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information.

[0022] In some embodiments, the selection module is specifically used to:

[0023] Based on the local disk information of the at least one service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the at least one service node;

[0024] The target local disk is selected from the candidate local disks.

[0025] In some embodiments, the disk requirements include disk application requirements and disk hardware requirements, the local disk information of each service node includes application scope information and hardware description information of each local disk mounted by the service node, and the selection module is specifically used to:

[0026] Based on the application scope information of each local disk mounted by the at least one service node, selecting a local disk whose application scope can meet the application requirement from each local disk as a primary local disk;

[0027] Based on the hardware description information of the preliminarily selected local disks, a disk whose hardware can meet the disk hardware requirement is selected from the preliminarily selected local disks as the candidate local disks.

[0028] In some embodiments, the application scope information of the local disk mounted by each service node is pre-configured through a configuration file.

[0029] In some embodiments, the service node where the target local disk is located deletes the identification information of the target local disk after providing storage services for the Pod to be scheduled.

[0030] In a third aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein:

[0031] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned local disk scheduling method.

[0032] In a fourth aspect, an embodiment of the present application provides a storage medium. When instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the above-mentioned local disk scheduling method.

[0033] In an embodiment of the present application, in response to a request for allocation of a local disk by a Pod to be scheduled, at least one business node that meets the scheduling conditions is selected, and the disk requirements of the Pod to be scheduled are obtained. Based on the local disk information of the at least one business node and the disk requirements of the Pod to be scheduled, a target local disk is selected from the local disks of the at least one business node. Then, identification information of the target local disk is stored, and the business node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information, thereby providing a solution for scheduling local disks. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0035] Figure 1 A schematic diagram of the architecture of Kubernetes provided in an embodiment of the present application;

[0036] Figure 2 A flowchart of a local disk scheduling method provided in an embodiment of the present application;

[0037] Figure 3 A flow chart of a method for selecting a target local disk provided in an embodiment of the present application;

[0038] Figure 4 An operation flow chart of node disk management provided in an embodiment of the present application;

[0039] Figure 5 An operation flow chart of an extended scheduler provided in an embodiment of the present application;

[0040] Figure 6 An operation flow chart of a CSI daemon process provided in an embodiment of the present application;

[0041] Figure 7 A schematic diagram of the structure of a local disk scheduling device provided in an embodiment of the present application;

[0042] Figure 8 A schematic diagram of the hardware structure of an electronic device for implementing a local disk scheduling method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] In order to provide a solution for scheduling a local disk, an embodiment of the present application provides a method, device, electronic device and storage medium for scheduling a local disk.

[0044] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0045] In order to facilitate the understanding of this application, the technical terms involved in this application are:

[0046] Kubernetes is an open source platform for automated deployment, expansion, and operation of container clusters. Application developers do not need to worry about the specific allocation and settings of underlying CPU, memory, network and other basic resources. They only need to focus on describing the deployment architecture of containerized applications and submitting them to Kubernetes through a declarative application programming interface (API). Kubernetes will use various resource objects such as Service, Deployment, and container group (Pod) to complete automated deployment according to user expectations.

[0047] Pod is the smallest scheduling unit of Kubernetes. A Pod can contain at least one container.

[0048] Local disk refers to the disk that provides storage services locally. It can be divided into solid-state and mechanical types according to the storage medium. Solid-state disks include solid-state drives (SSD) and mechanical disks include hard disk drives (HDD).

[0049] The container storage interface (CSI) is used to define scheduling specifications for storage resource scheduling.

[0050] Compared with remote disks across host networks, local disks on business nodes usually provide faster storage speeds and better storage performance. Therefore, it is necessary to schedule local disks on business nodes. Generally, disk media can affect the performance of local disks. For example, for applications that require frequent IO operations (such as frequent access to databases such as etcd and mysql), choosing solid-state local disks as backend storage is more conducive to the operation of applications. In addition, users may also need to customize disks of different sizes according to the needs of the application itself. As can be seen, there are many factors to consider when scheduling local disks.

[0051] In order to be able to better schedule the local disks in the business nodes, in an embodiment of the present application, the applications that the local disks can serve are planned in advance, and the disk requirements of the Pod to be scheduled for the local disks can be set. Subsequently, when allocating local disks to the Pod to be scheduled, the target local disk can be selected for the Pod to be scheduled based on the disk requirements of the Pod to be scheduled and the planning of each local disk, and then the target local disk is used to provide storage services for the Pod to be scheduled, so as to ensure that the Pod to be scheduled can obtain better local storage services.

[0052] The local disk scheduling method provided in the embodiment of the present application can be applied to all scenarios where local disks need to be scheduled. Subsequently, the scheme of the embodiment of the present application will be introduced by taking the application of the scheduling method to Kubernetes as an example.

[0053] Figure 1 A schematic diagram of the architecture of Kubernetes provided for an embodiment of the present application includes 1 management node and 3 business nodes: business node 1, business node 2 and business node 3, wherein business node 1 has two local disks: 1a and 1b, business node 2 has 1 local disk: 2a, and business node 3 has three local disks: 3a, 3b and 3c; the management node has a native scheduler and an extended scheduler, the native scheduler is mainly used to schedule the CPU, memory, GPU and other resources of the business node, and the extended scheduler can run simultaneously with the native scheduler, and is mainly used to schedule the storage resources of the business node, that is, to schedule the local disks of each business node.

[0054] After introducing the system architecture of the embodiment of the present application, the solution of the embodiment of the present application is described below in conjunction with specific embodiments.

[0055] The execution subject of the embodiment of the present application may be an extended scheduler in the management node. Figure 2 A flowchart of a local disk scheduling method provided in an embodiment of the present application includes the following steps.

[0056] In step 21, in response to the allocation request of the Pod to be scheduled for the local disk, at least one service node that meets the scheduling conditions is selected, and the disk requirement of the Pod to be scheduled is obtained.

[0057] Generally, after starting a Pod, the local disk is scheduled to provide storage resources for the Pod. After the Pod has available storage resources, it can actually enter the running stage.

[0058] Among them, the scheduling condition is schedulable. Considering that the native scheduler can obtain schedulable service nodes when scheduling resources such as CPU, memory, GPU, etc., the native scheduler can be used to select at least one schedulable service node.

[0059] In step 22, based on the local disk information of the at least one service node and the disk requirement of the Pod to be scheduled, a target local disk is selected from the local disks mounted on the at least one service node.

[0060] In specific implementation, Figure 3 The process shown selects a target local disk from the local disks mounted on the at least one service node, and the process includes the following steps.

[0061] In step 221, based on the local disk information of the at least one service node, a candidate local disk that can meet the disk requirement is selected from the local disks mounted by the at least one service node.

[0062] Taking the disk requirements including the application requirements and hardware requirements of the disk, the local disk information of each business node includes the application scope information and hardware description information of each local disk in the business node as an example, the application requirements of the disk are used to explain which applications the local disk needs to provide storage services for, such as the local disk needs to provide storage services only for specified applications, which types of applications the local disk needs to provide storage services for, etc. The disk hardware requirements are used to explain which hardware conditions the local disk should have, such as which media type of local disk is required, how large the disk size should be, etc. The application scope information is used to describe which applications the local disk can provide storage services for, such as providing storage services only for specified applications, providing storage services for a certain type of application, etc. The hardware description information is used to describe the hardware situation of the local disk, such as what the media type of the disk is, how large the disk size is, etc.

[0063] Subsequently, when selecting candidate local disks, based on the application scope information of the local disks mounted on the at least one business node, a local disk whose application scope can meet the application requirements of the disk can be selected from the local disks of the at least one business node as a preliminary local disk. Then, based on the hardware description information of the preliminary local disk, a local disk whose disk hardware can meet the disk hardware requirements can be selected from the preliminary local disks as a candidate local disk.

[0064] Considering that the number of local disks may be relatively large, first select a local disk that meets the application requirements of the disk from the local disks of the at least one business node, and then further select a local disk that meets the disk hardware requirements from these local disks, thereby avoiding unnecessary calculations and improving the disk selection speed.

[0065] In addition, in an embodiment of the present application, the application scope information of the local disk mounted on each business node can be configured through a configuration file. This makes it convenient for users to set the application scope of the local disk according to actual needs, which is more flexible and helps to improve the scheduling effect of subsequent disk scheduling.

[0066] In step 222, a target local disk is selected from the candidate local disks.

[0067] In some embodiments, there is only one candidate local disk. In this case, the only candidate local disk can be used as the target local disk.

[0068] In some embodiments, there are at least two candidate local disks and the at least two candidate local disks are located in the same service node. In this case, a target local disk may be randomly selected from the at least two candidate local disks.

[0069] In some embodiments, there are at least two candidate local disks and these at least two candidate local disks are located in different business nodes. At this time, the business nodes can be scored based on the CPU, memory, GPU and other information of the business node where each candidate local disk is located, and then the target local disk is selected based on the score of each business node. For example, the candidate local disk in the business node with the highest score is selected as the target local disk. In addition, it should be noted that when there is more than one candidate local disk in the business node with the highest score, the target local disk can be randomly selected from the candidate local disks of the business node with the highest score.

[0070] In step 23, the identification information of the target local disk is stored, and the service node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information.

[0071] The identification information of the target local disk is used to uniquely identify the target local disk.

[0072] In specific implementation, the identification information of the target local disk can be stored in a user-defined resource (CustomResource Definition, CRD), and finally persistently stored in etcd of the management node.

[0073] Since each business node monitors the information in etcd, the business node to which the target disk belongs can create a directory on the target local disk and mount the directory in the container of the Pod to be scheduled after detecting from etcd that the target local disk corresponding to the Pod to be scheduled belongs to itself. Subsequently, the target local disk can be used to provide storage services for the Pod to be scheduled.

[0074] In addition, after the business node where the target local disk is located provides storage services for the Pod to be scheduled, it can also delete the identification information of the target local disk to save storage space.

[0075] The scheme of the embodiment of the present application is described below in conjunction with specific embodiments.

[0076] In the embodiment of the present application, three parts are mainly involved when scheduling the local disk: node disk management, extended scheduler and node CSI daemon, among which, the node disk management is deployed on each business node, and is mainly used to call the node agent process to initialize the local disk according to the application planning information of the disk input by the user, and mount the local disk; the extended scheduler is deployed on the management node, and is mainly used to select the target local disk in the appropriate business node according to the disk requirements of the Pod to be scheduled, such as disk affinity, disk size, etc., and store the identification information of the target local disk in the CRD, and finally persist it in etcd; the node CSI daemon is deployed on each business node, and is mainly used to create a persistent volume (Persistent Volume, PV) when monitoring the identification information of the target local disk stored in etcd, create a directory on the target local disk, mount the directory to the container of the Pod to be scheduled, and finally update the disk status information of the business node such as disk size, availability status, etc.

[0077] The following is a detailed overview of these three parts.

[0078] 1. Node disk management.

[0079] The purpose of node disk management is to allow users to customize the applications that local disks can serve. Generally, users only need to enter the application planning information of a local disk, and the node agent process can convert the application planning information to obtain the application scope information of the local disk and store the application scope information in the node information of the corresponding business node.

[0080] For example, for a 3TB local SSD disk, the user hopes that this disk will only be used by application A. At this time, the user only needs to enter a label such as application A: yes, then, in the subsequent scheduling process, this local disk will not be used by applications other than application A. This can not only ensure the exclusivity of the disk, but also solve the problem of mismatch between actual allocation and actual occupancy of local directories.

[0081] See also Figure 4 The operation process of node disk management may include the following steps:

[0082] In step 41, the user sets application planning information of the local disk on the service node in the operation and maintenance related interface.

[0083] In step 42, the service node calls the node agent process to create a pre-planned disk path, mounts each local disk, and generates application scope information of each local disk according to the application planning information set by the user.

[0084] In step 43, the node information of the business node is obtained through the Kubernetes client, and the application scope information of the local disk in the business node is stored in the node information to update the node disk status.

[0085] The node disk status is used to record disk status information such as changes in the application range of the disk and changes in the available size of the disk.

[0086] 2. Extend the scheduler.

[0087] Kubernetes provides a solution to develop an extended scheduler by implementing related plug-ins such as pre-selection filter plug-ins without changing the source code of the native scheduler, and the developed extended scheduler can run simultaneously with the native scheduler. In order to enable the extended scheduler to schedule the local disk, the local disk resources can be abstracted into three types: disk size, disk media, and disk label (a form of expression of the application range that the disk can provide).

[0088] See also Figure 5 , the operation process of the extended scheduler may include the following steps:

[0089] In step 51, a request for allocation of a local disk by a Pod to be scheduled is received.

[0090] Generally, when a local disk needs to be applied for a Pod to be scheduled, the application type submitted by the user to the Apiserver (that is, the application type corresponding to the Pod that configures the local disk) is presented as a stateful service, namely Statefulset. The stateful service specifies the persistent volume claim (PVC) required for scheduling.

[0091] In step 52, at least one schedulable service node is selected through the native scheduler.

[0092] In step 53, the disk requirement of the Pod to be scheduled is obtained according to the PVC associated with the Pod to be scheduled.

[0093] The disk requirements of the Pod to be scheduled include the application requirements of the disk and the disk hardware requirements such as the disk size and the media type of the disk.

[0094] Generally, the PVC Annotation of the PVC associated with the Pod to be scheduled includes application requirements expressed in the form of key1:value1. The native PVC contains disk size information, and the media type can be specified through the StorageClass of the native PVC. In StorageClass, LOCAL-HDD means that an HDD disk is required, and LOCAL-SSD means that an SSD disk is required.

[0095] In step 54, according to the local disk information of the schedulable service node and the disk requirement of the Pod to be scheduled, a target local disk is selected from the local disks mounted on the schedulable service node.

[0096] For each schedulable service node, the local disk information of the service node stores application scope information and hardware description information of each local disk mounted on the service node.

[0097] Considering that there may be a large number of disks, we can first select local disks whose application scope can meet the application requirements of the disks from the local disks based on the application scope information of each local disk, and then further select local disks whose disk hardware can meet the disk hardware requirements (i.e., candidate local disks) based on the hardware description information of the selected local disks. In this way, unnecessary calculations can be reduced and the disk selection speed can be improved.

[0098] Generally, multiple candidate local disks can be obtained through the above selection process. In order to obtain a more suitable local disk, a target local disk can be selected from the multiple candidate local disks based on the service processing capability of the service node where each candidate local disk is located.

[0099] In step 55, the identification information of the target local disk is stored in the CRD and finally persistently stored in etcd.

[0100] 3. Node CSI daemon.

[0101] In actual applications, the extended scheduler is only responsible for selecting the appropriate local disk on the appropriate business node, and the creation and mounting of the directory are implemented by the node CSI daemon.

[0102] See also Figure 6 , the CSI daemon process includes the following steps:

[0103] In step 61, the PVC creation instruction on the service node is monitored.

[0104] In step 62, the identification information of the target local disk stored in the scheduling phase is read from the CRD, and the target local disk for which a directory needs to be created is determined based on the identification information.

[0105] In step 63, a directory is created on the target local disk, the node disk status is updated, and a PV is created.

[0106] Among them, updating the node disk status includes updating the available size of the disk.

[0107] In step 64 , it is determined whether the PV is created successfully. If not, the process proceeds to step 65 . If yes, the process proceeds to step 66 .

[0108] In step 65, the node disk allocation data is rolled back.

[0109] In step 66, information indicating successful creation of the PV is returned to the extended scheduler.

[0110] In addition, after successfully creating the PV, you can also delete the identification information of the target local disk stored in etcd to save storage space.

[0111] An embodiment of the present application provides a service binding strategy for a local disk, which can specify a local disk to be bound to an application corresponding to a Pod to be scheduled, thereby avoiding inconsistencies in the allocation and creation of storage resources.

[0112] Based on the same technical concept, an embodiment of the present application also provides a scheduling device for a local disk. The principle of solving the problem by the scheduling device for the local disk is similar to that of the above-mentioned scheduling method for the local disk. Therefore, the implementation of the scheduling device for the local disk can refer to the implementation of the scheduling method for the local disk, and the repeated parts will not be repeated.

[0113] Figure 7 A structural diagram of a local disk scheduling device provided in an embodiment of the present application includes an acquisition module 701, a selection module 702, and a storage module 703.

[0114] The acquisition module 701 is used to select at least one service node that meets the scheduling conditions in response to the allocation request of the container group Pod to be scheduled for the local disk, and obtain the disk requirement of the Pod to be scheduled;

[0115] A selection module 702, configured to select a target local disk from local disks mounted by the at least one service node based on the local disk information of the at least one service node and the disk requirement;

[0116] The storage module 703 is used to store the identification information of the target local disk, and the service node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information.

[0117] In some embodiments, the selection module 702 is specifically used to:

[0118] Based on the local disk information of the at least one service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the at least one service node;

[0119] The target local disk is selected from the candidate local disks.

[0120] In some embodiments, the disk requirements include disk application requirements and disk hardware requirements, and the local disk information of each service node includes application scope information and hardware description information of each local disk mounted by the service node. The selection module 702 is specifically used to:

[0121] Based on the application scope information of each local disk mounted by the at least one service node, selecting a local disk whose application scope can meet the application requirement from each local disk as a primary local disk;

[0122] Based on the hardware description information of the preliminarily selected local disks, a disk whose hardware can meet the disk hardware requirement is selected from the preliminarily selected local disks as the candidate local disks.

[0123] In some embodiments, the application scope information of the local disk mounted by each service node is pre-configured through a configuration file.

[0124] In some embodiments, the service node where the target local disk is located deletes the identification information of the target local disk after providing storage services for the Pod to be scheduled.

[0125] The division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, the functional modules in the embodiments of the present application may be integrated in a processor, or may exist physically separately, or two or more modules may be integrated in one module. The coupling between the modules may be achieved through some interfaces, which are usually electrical communication interfaces, but it is not excluded that they may be mechanical interfaces or other forms of interfaces. Therefore, the modules described as separate components may or may not be physically separated, and may be located in one place or distributed to different locations of the same or different devices. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0126] After introducing the comparative learning method and device according to the exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is introduced.

[0127] Refer to the following Figure 8 The electronic device 130 implemented according to this embodiment of the present application is described. Figure 8 The electronic device 130 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0128] like Figure 8As shown, the electronic device 130 is in the form of a general electronic device. The components of the electronic device 130 may include but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 connecting different system components (including the memory 132 and the processor 131).

[0129] Bus 133 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

[0130] The memory 132 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1321 and / or a cache memory 1322 , and may further include a read-only memory (ROM) 1323 .

[0131] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0132] The electronic device 130 may also communicate with one or more external devices 134 (e.g., keyboards, pointing devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 130, and / or communicate with any device that enables the electronic device 130 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 135. Furthermore, the electronic device 130 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 136. As shown, the network adapter 136 communicates with other modules for the electronic device 130 via a bus 133. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0133] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 132 including instructions, and the instructions can be executed by the processor 131 to complete the above-mentioned comparative learning method. Optionally, the storage medium can be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0134] In an exemplary embodiment, the electronic device of the present application may include at least one processor and at least one memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes the steps of any exemplary method provided in the present application.

[0135] In an exemplary embodiment, a computer program product is also provided. When the computer program product is executed by an electronic device, the electronic device can implement any exemplary method provided in the present application.

[0136] Furthermore, the computer program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a RAM, a ROM, an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0137] The program product for scheduling the local disk in the embodiment of the present application may adopt a CD-ROM and include program code, and may be run on a computing device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, and the program may be used by or in combination with an instruction execution system, apparatus, or device.

[0138] The readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein the readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0139] The program code contained on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

[0140] Program code for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device via any type of network such as a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0141] It should be noted that, although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into multiple units to be embodied.

[0142] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0143] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0144] The present application is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0145] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0146] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0147] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0148] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A local disk scheduling method, characterized in that: A node agent process and a node container storage interface CSI daemon process are deployed on each service node. The node agent process is used to pre-mount the local disk of the service node and generate application scope information of each local disk according to the application planning information set by the user; A native scheduler and an extended scheduler are deployed on the management node, and the method includes: The extended scheduler receives the allocation request of the Pod to be scheduled for the local disk, selects a schedulable service node through the native scheduler, and obtains the disk demand of the Pod to be scheduled for the local disk according to the persistent volume declaration PVC associated with the Pod to be scheduled; Based on the local disk information of the schedulable service node and the disk requirement, selecting a target local disk from the local disks mounted on the schedulable service node, the local disk information including application scope information of each mounted local disk; The identification information of the target local disk is stored in a user-defined resource CRD, and the CSI daemon on the service node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information in the CRD.

2. The method according to claim 1, characterized in that Selecting a target local disk from local disks mounted on the schedulable service node based on the local disk information of the schedulable service node and the disk requirement includes: Based on the local disk information of the schedulable service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the schedulable service node; The target local disk is selected from the candidate local disks.

3. The method according to claim 2, characterized in that The disk requirements include disk application requirements and disk hardware requirements, and the local disk information also includes hardware description information of each mounted local disk, and Based on the local disk information of the schedulable service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the schedulable service node includes: Based on the application scope information of each local disk mounted by the schedulable service node, a local disk having an application scope that can meet the application requirement is selected from each local disk as a primary local disk; Based on the hardware description information of the preliminarily selected local disks, a disk whose hardware can meet the disk hardware requirement is selected from the preliminarily selected local disks as the candidate local disks.

4. The method according to claim 1, characterized in that After the identification information of the target local disk is stored in the CRD, the identification information is persistently stored in etcd, and also includes: After providing storage services for the Pod to be scheduled, the identification information in the etcd is deleted.

5. A local disk scheduling device, characterized in that: A node agent process and a node container storage interface CSI daemon process are deployed on each service node. The node agent process is used to pre-mount the local disk of the service node and generate application scope information of each local disk according to the application planning information set by the user; A native scheduler and an extended scheduler are deployed on the management node, and the device is applied to the extended scheduler, and the device includes: An acquisition module is used to receive an allocation request for a local disk from a Pod to be scheduled, select a schedulable service node through the native scheduler, and obtain the disk demand of the Pod to be scheduled for the local disk according to the persistent volume declaration PVC associated with the Pod to be scheduled; A selection module, configured to select a target local disk from local disks mounted on the schedulable service node based on the local disk information of the schedulable service node and the disk requirement, wherein the local disk information includes application scope information of each mounted local disk; The storage module is used to store the identification information of the target local disk in the user-defined resource CRD, and the CSI daemon on the business node where the target local disk is located provides storage services for the Pod to be scheduled based on the identification information in the CRD.

6. The device according to claim 5, characterized in that The selection module is specifically used for: Based on the local disk information of the schedulable service node, selecting a candidate local disk that can meet the disk requirement from the local disks mounted by the schedulable service node; The target local disk is selected from the candidate local disks.

7. The device according to claim 6, characterized in that The disk requirements include disk application requirements and disk hardware requirements, the local disk information also includes hardware description information of each mounted local disk, and the selection module is specifically used for: Based on the application scope information of each local disk mounted by the schedulable service node, a local disk having an application scope that can meet the application requirement is selected from each local disk as a primary local disk; Based on the hardware description information of the preliminarily selected local disks, a disk whose hardware can meet the disk hardware requirement is selected from the preliminarily selected local disks as the candidate local disks.

8. The device according to claim 5, characterized in that After the identification information of the target local disk is stored in the CRD, the identification information is persistently stored in etcd, and after providing storage services for the Pod to be scheduled, the identification information in etcd is deleted.

9. An electronic device, characterized in that: include: at least one processor, and a memory communicatively connected to the at least one processor, wherein: The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can perform the method according to any one of claims 1 to 4.

10. A storage medium, characterized in that: When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the method as claimed in any one of claims 1 to 4.

Images