Resource scheduling method, cluster and computing device
By calling cloud platform interfaces to create and mount storage volumes in the Kubernetes cluster, the problem of data loss caused by temporary storage space in Pods is solved, and persistent data storage of container groups is achieved, ensuring that data is not lost after the container group is destroyed or migrated.
Patent Information
- Application Number
- CN202510943395.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-08
- Publication Date
- 2025-11-18
AI Technical Summary
In a Kubernetes cluster, the temporary storage space of a Pod is the same as its lifecycle, which causes application runtime data to be lost after the Pod is destroyed. How can we achieve persistent storage of data for containerized applications?
The target volume is created by calling the cloud platform's volume creation interface and mounted to the target virtual machine, so that the container group can access the target volume as a local disk, thereby achieving persistent data storage.
It enables persistent storage of container group data, ensuring that data is not lost even if the container group is destroyed or migrated, thus improving the reliability and availability of data storage.
Smart Images

Figure CN120973301A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of resource scheduling, and particularly relates to a resource scheduling method, a cluster and a computing device. BACKGROUND
[0002] A Kubernetes (K8s for short) cluster is a system composed of multiple nodes, which is used for automatically deploying, expanding and managing containerized applications.
[0003] The Kubernetes cluster takes a Pod for deploying an application as a minimum scheduling unit, however, the Pod uses a temporary storage space in a file system of a virtual machine node where the Pod is located to store running data, and the temporary storage space has the same life cycle as the Pod, once the Pod is destroyed, the temporary storage space is released, and the running data of the application deployed in the Pod is lost.
[0004] Therefore, how to perform data persistent storage on the application deployed in the Pod is an urgent problem to be solved. SUMMARY
[0005] Embodiments of the present application provide a resource scheduling method, a cluster and a computing device, which can realize data persistent storage of a containerized application.
[0006] To achieve the above technical purpose, the present application adopts the following technical solutions:
[0007] In a first aspect, the embodiments of the present application provide a resource scheduling method, which comprises: in response to a first request, calling a first target interface of a cloud platform based on a target storage resource corresponding to a target storage type, to create a target volume, wherein the first request comprises the target storage type, and the cloud platform is used for managing virtual machine nodes of a cluster; in response to a second request, creating a target container group based on a target virtual machine, the target virtual machine running on a host machine capable of accessing the target storage resource; calling a second target interface of the cloud platform to mount the target volume to the target virtual machine of the cluster, so that the target container group accesses the target volume in the manner of a local disk.
[0008] It can be understood that the first target interface is a volume creation interface, and the second target interface is a volume mounting interface. When an application request for the target storage resource of the target storage type is received, the volume creation interface of the cloud platform is called to create the target volume. Then, when a target Pod (i.e., a target container group) creation request is received, the target container group is created based on a target virtual machine, the target virtual machine being a virtual machine capable of accessing the target storage resource; the target volume is mounted to the target virtual machine, so that the target container group accesses the target volume in the manner of a local disk, thus the target container group can realize data persistent storage through the target volume.
[0009] In a possible implementation, before the first target interface of the cloud platform is called based on the target storage type corresponding to the target storage resource, the method further includes the following steps of:
[0010] Based on the target storage type and the first resource information, the target storage resource is determined, wherein the first resource information includes a plurality of storage resources allowed to be accessed by the cluster in the cloud platform and a storage type of each storage resource.
[0011] It can be understood that when receiving a storage resource request of any storage type, the resource pool information of the cloud platform pre-stored can be called, and the configuration information of various storage resources of the cloud platform is included in the resource pool information. The first resource information can be further determined from the resource pool information, and the storage resource suitable for the volume is selected based on the first resource information, thereby improving the reliability of the volume.
[0012] In a possible implementation, the first resource information further includes an available storage amount of each storage resource; the first request further indicates a target storage amount of the target volume; and based on the target storage type and the first resource information, the target storage resource is determined, including: selecting a first storage resource from the plurality of storage resources allowed to be accessed by the cluster in the cloud platform, wherein the first storage resource is a storage resource whose storage type is the target storage type and whose available storage amount is greater than the target storage amount; and selecting the target storage resource from the first storage resource.
[0013] It can be understood that the configuration information of the storage resource in the resource pool information includes but is not limited to the cluster allowed to be accessed, the storage type, the available storage amount, and the like. Therefore, in the case that the first request indicates the target storage type and the target storage amount of the target volume, the most suitable storage resource can be selected from the plurality of storage resources allowed to be accessed by the cluster in the cloud platform.
[0014] In a possible implementation, the target container group is created based on the target virtual machine in response to the second request, including:
[0015] The target virtual machine is determined, and the target container group is created on the target virtual machine.
[0016] It can be understood that the target container group can be constructed on the target virtual machine, and the target virtual machine is a virtual machine that can access the target storage resource, so that the target container group can access the target storage resource through the target virtual machine.
[0017] In a possible implementation, the target container group is created based on the target virtual machine in response to the second request, including: creating the target container group on the first virtual machine; determining the target virtual machine; and scheduling the target container group from the first virtual machine to the target virtual machine.
[0018] It can be understood that the target container group can be built on any virtual machine node, and then the target container group is scheduled to the target virtual machine capable of accessing the target storage resource, so that the target container group can access the target storage resource through the target virtual machine.
[0019] In a possible implementation, the determining the target virtual machine includes: obtaining a host list associated with the target storage resource; and determining the target virtual machine based on the host list, the target virtual machine running on a host in the host list.
[0020] It can be understood that the target volume can be mounted only on a virtual machine in physical layer communication with the target storage resource, that is, the target volume can be mounted only on a virtual machine running on a target host, and the target host is a host capable of accessing the target storage resource. Therefore, before mounting the target volume, a target virtual machine suitable for mounting the target volume is selected, and then the target volume is mounted to the target virtual machine, so that the target container group running on the target virtual machine is in physical layer communication with the target volume, and the target container group can access the target volume in the manner of a local disk. The selection of the target virtual machine ensures the reliability of the volume mounting.
[0021] In a possible implementation, the determining the target virtual machine based on the host list includes: determining the target virtual machine from virtual machines running on hosts in the host list based on resource requirements of the target container group.
[0022] It can be understood that the target virtual machine most suitable for the target container group can be selected as the target virtual machine from a plurality of virtual machines in physical layer communication with the target storage resource according to resource requirements (for example, computing power requirements) of the target container group using the target volume.
[0023] In a possible implementation, the first request further indicates a volume usage mode of the target volume.
[0024] After the target volume is mounted to the target virtual machine of the cluster, the method further includes: formatting the target volume into a file system when the volume usage mode is a file mode; and mounting the file system to a specified directory; the specified directory is a file directory in a host running the target virtual machine.
[0025] It can be understood that after the target volume is mounted to the target virtual machine, the target container group running on the target virtual machine can access the target volume in the manner of a local disk. After the target volume is mounted to the target virtual machine, it is necessary to determine the volume usage mode of the target volume. When the volume usage mode is a file mode, the target volume is formatted into a file system, and the file system is mounted to a file directory in a host machine running the target virtual machine, so that the target container group on the target virtual machine accesses the specified directory to read data. When the volume usage mode of the target volume is a block mode, the target container group on the target virtual machine directly accesses the target volume to read data. Thus, the usage mode of the target volume mounted to the target virtual machine is adapted to the user demand.
[0026] In a possible implementation, the method further includes: in response to a third request, deleting the file system mounted on the specified directory; and in response to a fourth request, deleting the target volume.
[0027] It can be understood that after the target container group is destroyed, the file system mounted on the specified directory can be deleted in response to a volume unmounting request, and the target volume can be deleted in response to a volume deleting request, so that the resources are released.
[0028] In a second aspect, the present application provides a cluster, which includes a control virtual machine and a working virtual machine.
[0029] The control virtual machine is configured to: in response to a first request, invoke a first target interface of a cloud platform based on a target storage resource corresponding to a target storage type, to create a target volume, wherein the first request includes the target storage type, and the cloud platform is configured to manage virtual machines of the cluster; in response to a second request, create a target container group based on a target virtual machine, wherein the target virtual machine runs on a host machine capable of accessing the target storage resource, and the target virtual machine is the control virtual machine or the working virtual machine; and invoke a second target interface of the cloud platform to mount the target volume to the target virtual machine, so that the target container group accesses the target volume in the manner of a local disk.
[0030] In a third aspect, the present application provides a computing device, which includes a memory and a processor. The memory and the processor are coupled; the memory is configured to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the computing device performs the resource scheduling method according to the first aspect and any possible implementation thereof.
[0031] In a fourth aspect, the present application provides a computing device, which includes a processor, and the processor executes the resource scheduling method according to the first aspect and any possible implementation thereof.
[0032] For example, the computing device can be a server, a tablet computer, a desktop computer, a laptop computer, a notebook computer, a netbook, and the like.
[0033] In a fifth aspect, the present application provides a computer readable storage medium, comprising computer instructions. When the computer instructions are run on a computing device, the computing device is caused to perform the resource scheduling method according to the first aspect and any possible implementation manner thereof.
[0034] In a sixth aspect, the present application provides a computer program product, comprising computer instructions. When the computer instructions are run on a management device, the management device is caused to perform the resource scheduling method according to the first aspect and any possible implementation manner thereof.
[0035] The detailed description of the second aspect to the sixth aspect and various implementation manners thereof in the present application can refer to the detailed description in the first aspect and various implementation manners thereof; and the beneficial effects of the second aspect to the sixth aspect and various implementation manners thereof can refer to the beneficial effect analysis in the first aspect and various implementation manners thereof, which will not be repeated here.
[0036] These aspects or other aspects of the present application will be more apparent in the following description. BRIEF DESCRIPTION OF DRAWINGS
[0037] Figure 1 An application scenario diagram is provided for an embodiment of the present application;
[0038] Figure 2 A deployment diagram of a storage plug-in is provided for an embodiment of the present application;
[0039] Figure 3 An implementation environment diagram related to a resource scheduling method is provided for an embodiment of the present application;
[0040] Figure 4 A hardware structure diagram of a computing device is provided for an embodiment of the present application;
[0041] Figure 5 A flow diagram of a resource scheduling method is provided for an embodiment of the present application;
[0042] Figure 6 A flow diagram of another resource scheduling method is provided for an embodiment of the present application;
[0043] Figure 7 A flow diagram of yet another resource scheduling method is provided for an embodiment of the present application;
[0044] Figure 8 A working principle diagram of a storage plug-in is provided for an embodiment of the present application. DETAILED DESCRIPTION
[0045] In the following description of the embodiments of the present application, the same items or similar items with basically the same functions and roles are distinguished by using "first", "second", and the like in the embodiments of the present application. Those skilled in the art can understand that "first", "second", and the like do not limit the quantity and execution order, and "first", "second", and the like do not necessarily mean different.
[0046] In the description of the embodiments of the present application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this document only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can mean that A exists alone, A and B exist together, and B exists alone. In addition, "at least one" means one or more, and "multiple" means two or more.
[0047] It should be noted that in the embodiments of the present application, the words "exemplary" or "for example" are used to mean an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words "exemplary" or "for example" are used to present the relevant concept in a specific manner.
[0048] For the convenience of understanding, the following will first introduce the related terms involved in the embodiments of the present application:
[0049] (1) Kubernetes (K8s): an open-source container management platform for automating deployment, scaling, and managing containerized applications.
[0050] (2) Pod: the smallest deployable unit in Kubernetes, a Pod contains one or more containers, and is usually used to run business processes.
[0051] (3) Persistent Volume (PV): a storage resource in Kubernetes, which exists independently of the Pod life cycle and is used for persistent storage of data.
[0052] (4) Persistent Volume Claim (PVC): a way for users to request storage resources, and through PVC, PV can be applied for use.
[0053] (5) StorageClass: a resource type in Kubernetes, used to define the category and configuration parameters of the storage volume, helping users to select and create storage volumes that meet the requirements.
[0054] (6) CSI (Container Storage Interface): A standard interface that connects different storage systems and container management platforms, allowing storage plugins to interact with Kubernetes.
[0055] (7) Cloud Platform: A public or private cloud service provider that provides infrastructure services such as computing and storage.
[0056] (8) VM (Virtual Machine): A virtualized computing instance running on a cloud platform, which can be used as a Kubernetes node.
[0057] (9) Extended Scheduler: An extended scheduler in Kubernetes that implements more complex scheduling logic through custom rules to ensure that Pods are scheduled to appropriate nodes.
[0058] (10) Secret: A resource type in Kubernetes that stores sensitive information (such as account numbers and passwords) and provides it to Pods in a secure manner.
[0059] (11) External provisioner: An external dynamic provisioner component provided by Kubernetes, responsible for dynamically creating PVs based on PVC requests.
[0060] (12) External attacher: An external attacher component provided by Kubernetes, responsible for mounting PVs to specified nodes.
[0061] (13) kubelet: A proxy process in Kubernetes that runs on each virtual machine node, responsible for managing Pods and their containers on that virtual machine node.
[0062] (14) containerd: An efficient container runtime that manages the life cycle of containers, including operations such as creating, starting, stopping, and destroying containers.
[0063] (15) Cloud Platform Storage Pool: A collection of storage resources available on a cloud platform, including various types of storage (such as block storage, file storage, object storage, etc.).
[0064] (16) Host Machine: A physical server running on a cloud platform.
[0065] (17) Kubernetes Cluster Scheduler (Kubernetes Scheduler): One of the core components of the Kubernetes cluster control plane, responsible for assigning newly created Pods to appropriate nodes for running.
[0066] The resource scheduling method provided by the embodiments of the present application can be applied to the scheduling scenario of container storage resources, a storage volume is created by using the storage resources of a cloud platform, and the storage volume is mounted to a virtual machine node where a container is located to enable the container to read and write, so as to persistently store the running data of the container.
[0067] Kubernetes (K8s for short) is a cloud-native application infrastructure, which has the advantages of fast delivery, high elasticity and high reliability. Running K8s virtual machine nodes on a cloud platform can fully utilize the resources of the cloud platform through resource scheduling.
[0068] In Kubernetes, a Pod is the smallest scheduling unit, and a Pod contains one or more containers, which are used to carry a specific business process. During business running, a large amount of running data is generated and stored in a temporary storage space in the file system of the virtual machine node where the Pod is located. Since the temporary storage space has the same life cycle as the Pod, once the Pod is destroyed, the temporary storage space will be released, resulting in the loss of running data. Therefore, there is an urgent need to provide a resource scheduling method that can realize persistent storage of container running data.
[0069] The embodiments of the present application provide a resource scheduling method, which can be applied to the scheduling scenario of container storage resources, please refer to Figure 1 , which shows an application scenario provided by the embodiments of the present application. As Figure 1 shown, the application scenario includes a container management platform 100, and the container management platform 100 manages at least one cloud platform 110 (such as 110A, 110B and 110C in the figure); each cloud platform 110 includes a plurality of host computers 120 (such as 120A, 120B and 120C in the figure), and a plurality of virtual machine nodes 130 (such as virtual machine nodes 130A, 130B and 130C running on host computer 120A, virtual machine nodes 130D, 130E and 130F running on host computer 120B, and virtual machine nodes 130G, 130H and 130I running on host computer 120C) run on each host computer 120, wherein the host computer 120 is a physical or virtual server running on the cloud platform 110, at least one virtual machine node 130 is virtualized on one host computer 120, and the virtual machine node 130 is actually a virtualized computing instance.
[0070] A group of virtual machine nodes 130 can form a cluster, thus the cloud platform 110 manages multiple clusters 140 (e.g., virtual machine nodes 130A, 130D and 130G form a cluster 140A, virtual machine nodes 130B, 130E and 130H form a cluster 140B, virtual machine nodes 130C, 130F and 130I form a cluster 140C, and the cloud platform 110A manages the clusters 140A, 140B and 140C). It should be noted that the multiple virtual machine nodes 130 corresponding to each cluster 140 can be located in the same host 120 or in different hosts 120.
[0071] In addition, one cloud platform 110 has at least one storage resource 150 corresponding to a resource type (e.g., the storage resources corresponding to the cloud platform 110 are storage resource 150A, storage resource 150B and storage resource 150C), and these storage resources 150 are obtained by processing the physical storage resources on the hosts 120 on the cloud platform 110 using virtualized storage, so the hosts 120 and the at least one storage resource 150 have a binding relationship, that is, the virtual machine nodes 130 realize data read and write by accessing the storage resource 150 bound to the host 120 where the virtual machine nodes 130 are located.
[0072] Further, Figure 2 A deployment diagram of a storage plug-in provided by an embodiment of the present application is shown in Figure 2 The virtual machine nodes (e.g., virtual machine node 1, virtual machine node 2, …, virtual machine node X; similar to the virtual machine nodes 130 in the embodiment shown in Figure 1 The virtual machine nodes (e.g., virtual machine node 1, virtual machine node 2, …, virtual machine node X; similar to the virtual machine nodes 130 in the embodiment shown in Figure 1 The control nodes and the worker nodes jointly cooperate to manage and run containerized applications. Among them, the control nodes deploy key components such as API Server and cluster scheduler, and are mainly responsible for maintaining the state information of the entire cluster, including node state, Pod state, service, etc. The worker nodes deploy key components such as Kubelet and container runtime, and are mainly responsible for actually running the containers in the Pods, and provide computing, storage and network resources for the application programs.
[0073] Because different cloud platforms use different storage systems, such as a distributed storage system (Ceph), local storage (Local), a network file system (NFS), and the like, different storage systems support storage of resources of different storage types, for example, the distributed storage system (Ceph) supports block storage, file storage, and object storage, and the like. Therefore, different cloud platforms set different storage interfaces (CSI interfaces) for different storage types, then provide storage plugins for interfacing different storage interfaces, and then use different storage type storage plugins provided by different cloud platforms to complete containerized interfacing of different storage types of different cloud platforms, to provide persistent storage services for containers. For example: for N cloud platforms and M storage types, there are at most N*M storage plugins. This will cause the types of storage plugins that need to be managed by the container management platform to be too complicated.
[0074] Embodiments of the present application consider cloud platform APIs (volume creation, volume deletion, virtual machine volume mounting, and volume unmounting), which are independent of specific storage types, and the differences between different storage types are reflected in the attributes of disks. Therefore, a storage plugin is provided, which can respond to storage volume creation requests of any storage type. Correspondingly, the API interface of the storage plugin can be deployed on the cloud platform, and the API interface can create storage volumes of any storage type. In this way, a single storage plugin is implemented to containerize and interface with different storage types of different cloud platforms. Taking storage volume (i.e., persistent volume) creation as an example: the storage plugin creates a corresponding persistent volume through the volume creation interface provided by the cloud platform, so that containerized applications can use the persistent volume to achieve persistent storage.
[0075] Specifically, the storage plugin includes two main components: a control component and a node component. The control component is deployed on a control node, and the node component is deployed on the control node and a worker node. The control node and the worker node also include kubelet and a Pod and other structures.
[0076] The control component is responsible for processing control plane operations, such as creating a volume and deleting a volume. The component can identify the type of the cloud platform and interact with the cloud platform through an API to implement operations such as creating and deleting a storage volume. The node component is responsible for processing data plane operations, such as formatting a volume and mounting a directory.
[0077] It can be understood that, for the convenience of interfacing with the cloud platform, the storage plugin can be deployed in the form of a container in a Pod in the control node.
[0078] The implementation of the embodiments of the present application will be described in detail below with reference to the accompanying drawings.
[0079] Reference is made to Figure 3 which shows an implementation environment involved in a resource scheduling method provided by an embodiment of the present application. As shown in Figure 3 , the implementation environment includes:
[0080] The container management platform 300 is the container management platform 100 in the embodiment shown in FIG. 1, the cloud platform 310 is the cloud platform 110 in the embodiment shown in FIG. 1, the control virtual machine 331 is the control node of the cluster in the embodiment shown in FIG. 1, and the target virtual machine 332 is one node on the cluster in the embodiment shown in FIG. 1, which can be a control node or a worker node. Figure 1 Figure 1 The container management platform 300 is the container management platform 100 in the embodiment shown in FIG. 1, the cloud platform 310 is the cloud platform 110 in the embodiment shown in FIG. 1, the control virtual machine 331 is the control node of the cluster in the embodiment shown in FIG. 1, and the target virtual machine 332 is one node on the cluster in the embodiment shown in FIG. 1, which can be a control node or a worker node. Figure 2 Figure 2 The container management platform 300 is the container management platform 100 in the embodiment shown in FIG. 1, the cloud platform 310 is the cloud platform 110 in the embodiment shown in FIG. 1, the control virtual machine 331 is the control node of the cluster in the embodiment shown in FIG. 1, and the target virtual machine 332 is one node on the cluster in the embodiment shown in FIG. 1, which can be a control node or a worker node.
[0081] It can be understood that the first request is a volume creation request, which can specify the storage type and the target storage amount of the target volume to be created.
[0082] In a possible implementation, the first request can be statically initiated by the container management platform 300, that is, the container management platform 300 sends the first request to the control virtual machine 331, and the control virtual machine 331 creates the target volume belonging to the cluster where the control virtual machine 331 is located and having a different storage type in the cloud platform 310 where the control virtual machine 331 is located in response to the first request. At this time, the target storage amount of the target volume to be created specified in the first request can be one of a plurality of default storage amounts preset in advance.
[0083] In a possible implementation, the first request can be dynamically initiated by the container management platform 300, that is, the container management platform 300 sends the first request to the control virtual machine 331 under the instruction of an administrator of the container management platform 300, and the first request indicates the storage type and the target storage amount required by the target container group. The control virtual machine 331 creates the target volume for the target container group in the cloud platform 310 where the control virtual machine 331 is located in response to the first request.
[0084] The container management platform 300 is further configured to send a second request to the control virtual machine 331.
[0085] It can be understood that the second request is a volume mounting request.
[0086] When the container management platform 300 pre-allocates storage resources for the target container group in the cluster where the control virtual machine 331 is located, the target volume created previously and attributed to the cluster where the control virtual machine 331 is located can be matched with the storage resource requirement of the target container group, so as to select the target volume to be mounted, and then a mount volume request is sent for the target volume. The control virtual machine 331 determines the target virtual machine 332 in response to the mount volume request, and the target virtual machine is a virtual machine in the cluster where the control virtual machine 331 is located and can access the storage resource to which the target volume belongs. Then the target container group is created on the target virtual machine, and finally the target volume is mounted on the target virtual machine 332.
[0087] After the operation of creating the target volume for the target container group is completed, the container management platform 300 can automatically or under the instruction of the administrator thereof send a mount volume request for the target volume. The control virtual machine 331 determines the target virtual machine 332 in response to the mount volume request, and the target virtual machine is a virtual machine in the cluster where the control virtual machine 331 is located and can access the storage resource to which the target volume belongs. Then the target container group is created on the target virtual machine, and finally the target volume is mounted on the target virtual machine 332.
[0088] The control virtual machine 331 is configured to create the target volume based on the target storage resource corresponding to the target storage type by calling a first target interface of the cloud platform 310 in response to the first request.
[0089] It can be understood that the first target interface is a volume creation interface of the cloud platform 310, and is used to create the target volume of the target storage type.
[0090] After receiving the first request, the control virtual machine 331 determines the target storage resource that meets the storage type and the target storage amount of the target volume to be created, and then communicates with the cloud platform 310 to call the first target interface of the cloud platform 310 to create the target volume in the cloud platform 310.
[0091] The control virtual machine 331 is further configured to create the target container group based on the target virtual machine in response to the second request, and call a second target interface of the cloud platform to mount the target volume on the target virtual machine, so that the target container group accesses the target volume in the manner of a local disk.
[0092] It can be understood that the second target interface is a mount volume interface of the cloud platform 310, and is used to mount the target volume on the target virtual machine 332 in the cluster that can access the target storage resource.
[0093] After receiving the second request, the control virtual machine 331 determines a target virtual machine 332 suitable for mounting the target volume, creates a target container group on the target virtual machine, communicates with the cloud platform 310, and calls a second target interface of the cloud platform 310 to mount the target volume to the target virtual machine 332. In this way, the target container group and the target volume are in the target virtual machine 332, and the target container group accesses the target volume in the form of a local disk to read and write data. Since the target volume is actually a physical storage resource, the data can be persisted, and even if the target container group is destroyed or migrated, the data will not be lost.
[0094] The cloud platform 310 is configured to generate the target volume in response to the calling operation when the first target interface is called. The cloud platform 310 is also configured to mount the target volume to the target virtual machine 332 in response to the calling operation when the second target interface is called.
[0095] The container management platform 300 can be composed of at least one terminal device and / or at least one server. The terminal device can be at least one of a smartphone, a smart watch, a desktop computer, a laptop computer, a virtual reality terminal, an augmented reality terminal, a wireless terminal, and a laptop computer.
[0096] The server can be a standalone physical server such as a general-purpose server, a graphics processing unit (GPU) server, a data processing unit (DPU) server, or a server cluster or distributed file system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks, and big data.
[0097] The host machine running the control virtual machine 331 and the host machine running the target virtual machine 332 are at least one of a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks, and big data.
[0098] The resource scheduling method provided by the embodiments of the present application can be applied to the control virtual machine 331, and specifically to the control component in the control virtual machine 331.
[0099] The control virtual machine 331 in the embodiments of the present application is a virtualized computing instance running on a host machine, and the host machine is a computing device. Figure 4 A hardware structure diagram of a computing device provided by the embodiments of the present application is shown in FIG. 1.Figure 4 , Figure 4 The computing device 400 shown in FIG. 4 can include a processor 401, a memory 402, a communication interface 403, and a bus 404. The processor 401, the memory 402, and the communication interface 403 can be connected through the bus 404.
[0100] The processor 401 is a control center of the computing device, and can be a general central processing unit such as a CPU, or other general processor, etc. The general processor can be a microprocessor or any conventional processor, etc.
[0101] As an example, the processor 401 can include one or more CPUs, such as the CPU 0 and the CPU 1 shown in FIG. 4. Figure 4
[0102] The memory 402 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.
[0103] In a possible implementation, the memory 402 can exist independently of the processor 401. The memory 402 can be connected to the processor 401 through the bus 404, and used to store data, instructions, or program code. When the processor 401 invokes and executes the instructions or program code stored in the memory 402, the resource scheduling method provided by the embodiments of the present application can be implemented.
[0104] In another possible implementation, the memory 402 can also be integrated with the processor 401.
[0105] The communication interface 403 is used for the computing device to be connected with other devices through a communication network, which can be an Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc. The communication interface 403 can include a receiving unit for receiving data, and a sending unit for sending data.
[0106] The bus 404 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, Figure 4 Only one thick line is used to represent the bus in the figure, but it does not mean that there is only one bus or only one type of bus.
[0107] It should be noted that Figure 4 The structure shown in the figure does not constitute a limitation on the computing device, except Figure 4 The computing device can include more or fewer components than shown, or combine certain components, or different component arrangements.
[0108] Figure 5 A flowchart of a resource scheduling method provided by an embodiment of the present application. Referring to Figure 5 , applied to a control virtual machine as shown in Figure 3 , mainly applied to a control component in the control virtual machine, the method includes the following S501-S503:
[0109] S501, in response to a first request, calling a first target interface of a cloud platform based on a target storage resource corresponding to a target storage type, creating a target volume.
[0110] It can be understood that the cluster is similar to the cluster in the embodiment as shown in Figure 2 , and the control virtual machine is similar to the control virtual machine 331 in the embodiment as shown in Figure 3 , which is a virtualized computing instance. The cloud platform is used to manage the virtual machine nodes of the cluster, which is similar to the cloud platform 310 in the embodiment as shown in Figure 3 .
[0111] The first request is a volume creation request, which is used to indicate the creation of a target volume of a target storage type. The first target interface is a volume creation interface of the cloud platform, which is called to create a target volume of a target storage type. The target storage type can be any storage type on the cloud platform.
[0112] The target volume actually corresponds to part of the physical storage resource, so the data read and write on the target volume can be stored persistently, so the target volume in the embodiment of the present application is a persistent volume (PV).
[0113] It can be understood that since the control virtual machine is deployed in a cluster, and there can be more than one cluster in the cloud platform, and each cluster is composed of a group of virtual machines in the cloud platform, only the storage resources virtualized from the physical storage resources of the host corresponding to the group of virtual machines can be accessed, so the target storage type is one of the storage types of the storage resources allowed to be accessed by the cluster in the cloud platform. The storage types of the storage resources on the cloud platform include but are not limited to block storage, file storage, and object storage. There can be more than one storage resource of the same storage type on one cloud platform.
[0114] The first request can also indicate the target storage amount of the target volume to be created, so that the control virtual machine calls the first target interface of the cloud platform to create the target volume with the corresponding target storage amount.
[0115] Specifically, the control virtual machine determines the target storage resource in response to the first request, and then calls the first target interface of the cloud platform based on the target storage resource to create the target volume.
[0116] In a possible implementation, the container management platform manages at least one cloud platform and controls deployment and management of containers of clusters deployed on each cloud platform, so the first request can be issued by the container management platform.
[0117] As an example, the control virtual machine determining the target storage resource includes:
[0118] Based on the storage pool information of the cloud platform where the control virtual machine is located, determining the storage resource of the target storage type and the target storage amount that allows the cluster where the control virtual machine is located to access and meets the requirements of the first request;
[0119] Determining the storage resource as the target storage resource.
[0120] The storage pool information of each cloud platform can be maintained in the container management platform, or the cloud platform maintains its own storage pool information, and the control virtual machine obtains the storage pool information of the cloud platform where the control virtual machine is located by communicating with the container management platform or the cloud platform where the control virtual machine is located. The storage pool information includes configuration information of the storage resource of each storage type in the corresponding cloud platform, and the configuration information includes but is not limited to available storage amount, allowed access cluster (one or more virtual machines exist in the cluster and have a binding relationship with the storage resource), and storage resource unique identifier.
[0121] As another example, in the case that the storage pool information of each cloud platform is maintained in the container management platform, the control virtual machine determining the target storage resource includes:
[0122] The storage resource corresponding to the resource identifier indicated in the first request is determined as the target storage resource.
[0123] It can be understood that each storage resource on each cloud platform has a unique identity indicating identity, and the container management platform or its administrator can determine the target storage resource based on the storage type allowed to be accessed by the cluster in the cloud platform, and then generate a first request using the resource identifier of the target storage resource, and issue the first request to the cluster.
[0124] In a possible implementation, before the control virtual machine calls the first target interface of the cloud platform, the method further includes:
[0125] Based on the account information of the cloud platform, a communication connection is established with the cloud platform. The account information includes but is not limited to an account and a password.
[0126] As an example, the container management platform maintains the account information of each cloud platform it manages, and the control virtual machine obtains the account information of the cloud platform where it is located from the container management platform, and then establishes a communication connection with the cloud platform based on the account information.
[0127] For example, the cluster is a Kubernetes cluster, the control virtual machine is a Kubernetes virtual machine node, and the container management platform stores the account information of each cloud platform it manages in a Secret resource. Since the Secret resource is used to store sensitive information, the account information of the cloud platform can be provided to the Kubernetes virtual machine node running in the cloud platform in a secure manner.
[0128] It can be understood that before the control virtual machine accesses other interfaces (such as a second target interface) of the cloud platform or accesses resource information (such as storage pool information of the cloud platform itself) maintained by the cloud platform, a communication connection between the control virtual machine and the cloud platform also needs to be established. Subsequent details will not be described.
[0129] S502, in response to the second request, creating a target container group based on a target virtual machine, the target virtual machine running on a host machine capable of accessing the target storage resource.
[0130] The target container group is a target Pod.
[0131] The second request is a mount request, which indicates to create a target Pod and mount a target volume to a virtual machine where the target Pod is located. The mount request can be issued to the cluster by the container management platform. Generally, the container management platform will issue the mount request of the target volume when the container management platform schedules the target volume to the target Pod.
[0132] Specifically, in response to the second request, the control virtual machine first determines the target virtual machine, and creates the target Pod on the target virtual machine or on any virtual machine, and schedules the target Pod to the target virtual machine; then it mounts the target volume to the target virtual machine so that the target Pod can access the target volume as a local disk.
[0133] As an example, the process of determining the target virtual machine described above may include:
[0134] Based on the second resource information, the target virtual machine is determined. The second resource information includes the virtual machines running on each host machine in the cluster, as well as the storage resources that each host machine in the cluster can access.
[0135] It is understandable that the target volume can only be mounted to a virtual machine that is physically connected to its associated storage resource. Specifically, the cloud platform's storage resources are associated with the host machine, and the virtual machine runs on the host machine. Therefore, the target volume can only be mounted to the virtual machine that is bound to the host machine and the target storage resource.
[0136] Since Pods run on virtual machines, if you want the target Pod to access the target volume, you must schedule the Pod and the target volume onto the same virtual machine to ensure physical connectivity between them. Therefore, you need to determine the target virtual machine before mounting the target volume.
[0137] As an example, the container management platform described above can maintain topology data for various cloud platforms, or the cloud platform can maintain its own topology data. It controls virtual machines to communicate with the container management platform or their respective cloud platforms to obtain the topology data of their respective cloud platforms, and then extract second resource information from this topology data. This topology data includes the host machine bound to each storage resource in the corresponding cloud platform, and the virtual machines virtualized on each host machine.
[0138] In one possible implementation, determining the target virtual machine based on the second resource information includes: determining a list of host machines associated with the target storage resources based on the second resource information;
[0139] The target virtual machine is determined based on the host list, and the target virtual machine runs on a host machine in the host list.
[0140] In one possible implementation, determining the target virtual machine based on the host list includes: randomly selecting one virtual machine from the virtual machines running on the hosts in the host list as the target virtual machine.
[0141] In one possible implementation, the above-mentioned determination of the target virtual machine based on the host list, wherein the target virtual machine runs on a host in the host list, includes:
[0142] determining a target virtual machine from the virtual machines running on the host machines in the host machine list based on resource requirements of a target Pod. The resource requirements of the target Pod can be computing power requirements, which include one or more of the following: computing power, encoding power, and decoding power.
[0143] S503, calling a second target interface of the cloud platform to mount the target volume to the target virtual machine, so that the target container group accesses the target volume in the manner of a local disk.
[0144] The second target interface is a volume mounting interface of the cloud platform, which is used to mount the target volume to a virtual machine in the cluster that can access the target storage resource.
[0145] The resource scheduling method provided by the embodiments of the present application controls the virtual machine to call a volume creation interface of the cloud platform to create a target volume when the virtual machine receives an application request for a target storage resource of a target storage type. Then, when a target Pod creation request is received, the virtual machine determines a target virtual machine, which is a virtual machine that can access the target storage resource, and creates a target pod using the target volume on the target virtual machine. Finally, the target volume is mounted to the target virtual machine, so that the target Pod accesses the target volume in the manner of a local disk. In this way, the target Pod can achieve persistent storage of data through the target volume. Moreover, containerized docking of different storage types of various cloud platforms can be achieved through a single storage plug-in, reducing the operation and maintenance cost.
[0146] Figure 6 Another flowchart of a resource scheduling method provided by the embodiments of the present application is provided. Referring to Figure 6 , the method is applied to a control virtual machine of a cluster, and includes the following S601-S604:
[0147] S601, in response to a first request, determining a target storage resource based on a target storage type and first resource information. The first request is a volume creation request, which is used to indicate the creation of a target volume of the target storage type. The first resource information includes a plurality of storage resources allowed to be accessed by the cluster and their respective configuration information in the cloud platform. The cloud platform is used to manage virtual machines of the cluster.
[0148] In a possible implementation, the container management platform can maintain storage pool information of each cloud platform, or the cloud platform maintains its own storage pool information, and the control virtual machine obtains the storage pool information of the cloud platform where it is located by communicating with the container management platform or the cloud platform where it is located. The storage pool information includes configuration information of storage resources of each storage type in the corresponding cloud platform, and the configuration information includes but is not limited to available storage amount, allowed access cluster (a cluster in which one or more virtual machines have a binding relationship with the storage resource), storage resource unique identifier, and the like. The first resource information is determined based on the storage pool information of the cloud platform.
[0149] As an example, the cluster can be a Kubernetes cluster, the control virtual machine is a Kubernetes virtual machine node, and the administrator of the container management platform creates a StorageClass corresponding to each available storage resource on each cloud platform. The StorageClass stores information such as cloud platform identifier, allowed access cluster identifier, storage resource identifier, and available storage amount. The control virtual machine calls the StorageClass created by the administrator of the container management platform to determine the first resource information.
[0150] In a possible implementation, the configuration information of each storage resource included in the first resource information includes but is not limited to storage type and available storage amount; the target storage amount is included in the first request; and the target storage resource is determined based on the target storage type and the first resource information, including: selecting a first storage resource from a plurality of storage resources allowed to be accessed by the cluster in the cloud platform, where the first storage resource is a storage resource whose storage type is the target storage type and whose available storage amount is greater than the target storage amount; and selecting the target storage resource from the first storage resource. That is, in the range of storage resources available to the cluster, a storage resource that meets the target storage type and the target storage amount is found as the target storage resource, so as to meet the demand of the Pod for the storage resource.
[0151] In a possible implementation, the first request indicates the identifier of the target storage resource, and the control virtual machine queries the storage resource corresponding to the identifier, and determines the found storage resource as the target storage resource.
[0152] As an example, the control virtual machine queries the storage resource corresponding to the identifier in the StorageClass created by the administrator of the container management platform in an inquiry manner, and determines the found storage resource as the target storage resource.
[0153] It can be understood that the first request can be a persistent volume claim (PVC) created by the container management platform (or the administrator thereof) referring to the StorageClass, the persistent volume claim (PVC) including the target storage type and the target storage amount, or including the unique identifier of the target storage resource and the target storage amount, through which the target volume can be applied. Of course, the target storage amount can also not be included in the persistent volume claim (PVC), and if the target storage amount is not specified, the volume can be created according to the default value. In this way, the convenience of the container management platform for creating a volume is improved.
[0154] S602, invoking a first target interface of the cloud platform based on the target storage resource to create the target volume.
[0155] S603, in response to the second request, creating a target container group based on the target virtual machine, the target virtual machine running on a host machine capable of accessing the target storage resource.
[0156] S604, invoking a second target interface of the cloud platform to mount the target volume to the target virtual machine, so that the target container group accesses the target volume in the form of a local disk.
[0157] The steps S601-S602 are a refinement of the step S501 of the embodiment shown in Figure 5 The steps S603-S604 have been described in detail in the steps S502-S503 of the embodiment shown in Figure 5 , and will not be described here.
[0158] The resource scheduling method provided by the embodiment of the application improves the reliability of volume creation by controlling the virtual machine to invoke the resource pool information of the cloud platform to determine the storage resource that meets the demand when receiving a storage resource request of any storage type, and then creating a volume on the storage resource.
[0159] Figure 7 A flowchart of another resource scheduling method provided by the embodiment of the application is shown in Figure 7 , applied to a control virtual machine of a cluster, the method comprising the following steps S701-S705:
[0160] S701, in response to a first request, invoking a first target interface of the cloud platform based on a target storage resource corresponding to a target storage type to create a target volume; the cloud platform is used to manage virtual machines of the cluster.
[0161] S702, in response to a second request, creating a target container group based on a target virtual machine, the target virtual machine running on a host machine capable of accessing the target storage resource. The target container group refers to a target Pod.
[0162] S703. Invoking a second target interface of the cloud platform to mount the target volume to the target virtual machine, so that the target container group accesses the target volume in a local disk manner.
[0163] The steps S701-S703 have been described in detail in steps S501-S503 of the embodiment as shown in Figure 5 The steps S501-S503 of the embodiment have been described in detail, and will not be repeated here.
[0164] S704. When the volume usage mode of the target volume indicated in the first request is a file mode, the target virtual machine is controlled to format the target volume into a file system.
[0165] S705. The target virtual machine is controlled to mount the file system to a specified directory. The specified directory is a file directory on a host machine where the target virtual machine is located.
[0166] In this way, when the volume usage mode of the target volume is a file mode, the target Pod on the target virtual machine accesses the specified directory to perform data reading. When the volume usage mode of the target volume is a block mode, the target Pod on the target virtual machine directly accesses the target volume to perform data reading.
[0167] As an implementation manner, after the target Pod is destroyed, a file system mounted on the specified directory is deleted in response to a third request; and the target volume is deleted in response to a fourth request.
[0168] The third request is an unmounting volume request, and the fourth request is a volume deletion request.
[0169] The resource scheduling method provided by the embodiment of the present application controls the virtual machine and the target virtual machine mounting the target volume to cooperate with each other, so that the target volume mounted to the target virtual machine is further changed into a volume usage mode expected by a user, thereby fitting the actual needs of the user.
[0170] Figure 8 A working principle diagram of a storage plug-in provided by the embodiment of the present application is shown in Figure 8 As shown in the figure, an administrator of the container management platform creates a StorageClass corresponding to each available storage resource on each cloud platform. The StorageClass stores information such as cloud platform identification, allowed access cluster identification, storage resource identification, and available storage amount. These StorageClasses form storage pool information. The container management platform also places account information (account and password) of each cloud platform in a Secret resource.
[0171] For a cluster of a single cloud platform (taking a Kubernetes cluster as an example), the storage resources of the cloud platform include storage resource 1, storage resource 2…storage resource X. The control virtual machine (i.e. virtual machine node 1) of the cluster includes a control component and a node component; the control component includes an External attacher sub-component, an External provisioner sub-component, an extension scheduler and a control module; wherein the extension scheduler, the control module and the node module are deployed in the form of a container; the External attacher sub-component and the External provisioner sub-component are components provided by Kubernetes officially and are deployed in the form of a sidecar container.
[0172] Specifically, the container management platform references a StorageClass to create a persistent volume claim (PVC) and issues it to the control virtual machine of the cluster through a Kubernetes API service. After the External provisioner sub-component monitors the persistent volume claim, the control module is called. The persistent volume claim contains the address of the referenced StorageClass, and the control module determines the cloud platform (i.e. the cloud platform in the figure) to which the persistent volume claim is directed through the address of the StorageClass, and further determines the target storage resource (i.e. storage resource 1 on the cloud platform in the figure) to which the persistent volume claim is directed; in addition, the control module also accesses a Secret resource to obtain account information (account and password) of the cloud platform, and establishes a communication connection with the cloud platform through the account information; after the communication connection is established, the control module calls the volume creation interface of the cloud platform to create a corresponding target volume (i.e. a persistent volume, PV).
[0173] After that, the cluster scheduler monitors the container management platform referencing the persistent volume claim (PVC) to create a target Pod (i.e. monitors the container management platform issuing a volume mounting request), and determines the candidate virtual machines that can access the target storage resource to which the target volume belongs by accessing the extension scheduler in the control component, and then determines the target virtual machine from the candidate virtual machines based on the resource requirements of the target Pod. Then the target Pod is created and the target Pod is scheduled to the target virtual machine.
[0174] Among them, the extension scheduler is realized based on the cluster scheduler extension mechanism, and in the pre-selection link of Pod scheduling, only the virtual machines that meet the topology rules are selected as candidate virtual machines.
[0175] Specifically, the extension scheduler can query the query interface of the cloud platform, call the topology data of the cloud platform, and then select the host associated with the storage resource where the persistent volume is located in the cluster based on the topology data, and select the virtual machines on the host as candidate virtual machines.
[0176] The External attacher sub-component in the control component monitors whether the target Pod is scheduled to the target virtual machine, and in the case that the target Pod is monitored to be scheduled to the target virtual machine, a control module is called; the control module calls a mounting volume interface of the cloud platform to mount the target volume to the target virtual machine, so that the target volume and the target Pod are connected at a physical layer, so that the target Pod can access the persistent volume for data reading and writing.
[0177] The kube let of the target virtual machine identifies whether the volume usage mode of the target volume is a file mode after monitoring that the target volume is mounted to the target virtual machine, and if the volume usage mode of the target volume is the file mode, a formatting interface of the node component is called to format the target volume and mount the target volume to a specified directory. Then the kube let passes the specified directory to a container runtime (such as containerd) of the target virtual machine, the container runtime passes the specified directory to the target Pod, and the target Pod can read and write data using the target volume. If the volume usage mode of the target volume is a block mode, the target Pod can directly read and write data using the target volume.
[0178] The embodiment of the application also provides a resource scheduling device. The device is applied to a control virtual machine, and is used for, in response to a first request, calling a first target interface of a cloud platform based on a target storage type corresponding to a target storage resource to create a target volume; the first request includes the target storage type, and the cloud platform is a virtual machine for managing a cluster. The device is also used for, in response to a second request, creating a target container group based on a target virtual machine, and the target virtual machine runs on a host machine capable of accessing the target storage resource. The device is also used for calling a second target interface of the cloud platform to mount the target volume to the target virtual machine; so that the target container group accesses the target volume in a local disk mode.
[0179] The resource scheduling device provided by the embodiment of the application calls a volume creation interface of the cloud platform to create the target volume when receiving an application request of the target storage type of the target storage resource. Then, when receiving a target Pod (that is, a target container group) creation request, the target container group is created based on a target virtual machine, and the target virtual machine is a virtual machine capable of accessing the target storage resource; the target volume is mounted to the target virtual machine, so that the target container group accesses the target volume in a local disk mode, so that the target container group can realize data persistent storage through the target volume. Moreover, containerized docking of different storage types of various cloud platforms can be realized through a single storage plug-in, and the operation and maintenance cost is reduced.
[0180] In some possible implementation manners, the apparatus is specifically configured to determine the target storage resource based on the target storage type and the first resource information before calling the first target interface of the cloud platform based on the target storage resource corresponding to the target storage type, wherein the first resource information includes configuration information of a plurality of storage resources in the cloud platform that are allowed to be accessed by the cluster and storage types of the storage resources.
[0181] In some possible implementation manners, the first resource information further includes available storage amounts of the storage resources; the first request further indicates a target storage amount of the target volume; and the apparatus is specifically configured to select a first storage resource from the plurality of storage resources in the cloud platform that are allowed to be accessed by the cluster, wherein the first storage resource is a storage resource whose storage type is the target storage type and whose available storage amount is greater than the target storage amount; and the target storage resource is selected from the first storage resource.
[0182] In some possible implementation manners, the method further includes: determining the target virtual machine; and creating the target container group on the target virtual machine.
[0183] In some possible implementation manners, the method further includes: creating the target container group on the first virtual machine; determining the target virtual machine; and scheduling the target container group from the first virtual machine to the target virtual machine.
[0184] In some possible implementation manners, the method further includes: obtaining a host list associated with the target storage resource; and determining the target virtual machine based on the host list, wherein the target virtual machine runs on a host in the host list.
[0185] In some possible implementation manners, the method further includes: determining the target virtual machine from virtual machines running on the hosts in the host list based on resource requirements of the target container group.
[0186] In some possible implementation manners, the first request further indicates a volume use mode of the target volume; and the apparatus is specifically configured to: format the target volume into a file system after mounting the target volume to the target virtual machine of the cluster when the volume use mode is a file mode; and mount the file system to a specified directory by the first mounting unit, wherein the specified directory is a file directory in a host running the target node.
[0187] In some possible implementation manners, the apparatus is specifically configured to: delete the file system mounted on the specified directory in response to a third request; and delete the target volume in response to a fourth request.
[0188] The embodiments of the present application further provide a cluster, which includes a control virtual machine and a working virtual machine.
[0189] The control virtual machine is configured to, in response to a first request, invoke a first target interface of a cloud platform based on a target storage resource corresponding to a target storage type, to create a target volume; the first request includes the target storage type, and the cloud platform is configured to manage virtual machines of a cluster; in response to a second request, create a target container group based on a target virtual machine; the target virtual machine runs on a host machine capable of accessing the target storage resource, and the target virtual machine is the control virtual machine or a working virtual machine; invoke a second target interface of the cloud platform, and mount the target volume to the target virtual machine, so that the target container group accesses the target volume in a local disk manner.
[0190] The embodiment of the application further provides a computing device, comprising a processor and a memory, which are coupled. The memory is configured to store computer program instructions, and the processor is configured to invoke the computer program instructions in the memory to execute the resource scheduling method shown in the above embodiment.
[0191] The embodiment of the application further provides a computer readable storage medium, which stores computer program instructions, and the computer program instructions are configured to enable a computing device to execute the resource scheduling method shown in the above embodiment.
[0192] The embodiment of the application further provides a computer program product, comprising computer program instructions, which, when executed on a management device, enable a computing device to execute the resource scheduling method shown in the above embodiment.
[0193] The computing device, the computer readable storage medium or the computer program product provided by the embodiment of the application are all configured to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved by the computing device, the computer readable storage medium or the computer program product are for reference to the beneficial effects in the corresponding method provided above, which will not be described herein again.
[0194] Through the description of the above embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device (such as an electronic device) is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device (such as an electronic device) and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described herein again.
[0195] In several embodiments provided in the present application, it should be understood that the disclosed system, apparatus (such as an electronic device) and method can be implemented by other manners. For example, the apparatus (such as an electronic device) embodiments described above are merely illustrative, for example, the division of the modules or units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0196] The units described above as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e. can be located in one place or can be distributed to a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.
[0197] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.
[0198] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part of the prior art that makes a contribution or the whole or part of the technical solutions can be embodied in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the method of each embodiment of the present application. The foregoing storage medium includes: a flash memory, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and various media that can store program codes.
[0199] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A resource scheduling method, characterized in that, The method includes: In response to the first request, the first target interface of the cloud platform is invoked based on the target storage resources corresponding to the target storage type to create a target volume; the first request includes the target storage type, and the cloud platform is used to manage virtual machines in the cluster; In response to the second request, a target container group is created based on the target virtual machine, the target virtual machine running on a host machine that can access the target storage resources; The second target interface of the cloud platform is invoked to mount the target volume to the target virtual machine, so that the target container group can access the target volume as a local disk.
2. The resource scheduling method according to claim 1, characterized in that, Before invoking the first target interface of the cloud platform based on the target storage resource corresponding to the target storage type, the following steps are also included: Based on the target storage type and the first resource information, the target storage resource is determined, wherein the first resource information includes multiple storage resources in the cloud platform that the cluster is allowed to access and the storage type of each storage resource.
3. The resource scheduling method according to claim 2, characterized in that, The first resource information also includes the available storage capacity of each storage resource; the first request further indicates the target storage capacity of the target volume; The step of determining the target storage resource based on the target storage type and the first resource information includes: Among the multiple storage resources that the cluster is allowed to access in the cloud platform, a first storage resource is selected, wherein the first storage resource is a storage resource of the target storage type and whose available storage capacity is greater than the target storage capacity; Select the target storage resource from the first storage resource.
4. The resource scheduling method according to claim 1, characterized in that, The step of creating a target container group based on the target virtual machine in response to the second request includes: Identify the target virtual machine; Create the target container group on the target virtual machine.
5. The resource scheduling method according to claim 1, characterized in that, The step of creating a target container group based on the target virtual machine in response to the second request includes: Create the target container group on the first virtual machine; Identify the target virtual machine; The target container group is scheduled from the first virtual machine to the target virtual machine.
6. The resource scheduling method according to claim 4 or 5, characterized in that, Determining the target virtual machine includes: Obtain the list of host machines associated with the target storage resource; The target virtual machine is determined based on the host list, and the target virtual machine runs on a host in the host list.
7. The resource scheduling method according to claim 6, characterized in that, The step of determining the target virtual machine based on the host list includes: determining the target virtual machine from the virtual machines running on the hosts in the host list based on the resource requirements of the target container group.
8. The resource scheduling method according to claim 1, characterized in that, The first request also indicates the volume usage mode of the target volume; After mounting the target volume to the target virtual machine in the cluster, the method further includes: when the volume usage mode is file mode, formatting the target volume as a file system; Mount the file system to the specified directory; The specified directory is a file directory on the host machine running the target virtual machine.
9. A cluster, characterized in that, The cluster includes control virtual machines and working virtual machines; The control virtual machine is configured to, in response to a first request, call a first target interface of the cloud platform based on the target storage resources corresponding to the target storage type to create a target volume; the first request includes the target storage type, and the cloud platform is used to manage the virtual machines of the cluster; in response to a second request, create a target container group based on the target virtual machine, the target virtual machine running on a host machine capable of accessing the target storage resources, and the target virtual machine being either the control virtual machine or the working virtual machine; and call a second target interface of the cloud platform to mount the target volume to the target virtual machine, so that the target container group can access the target volume as a local disk.
10. A computing device, characterized in that, It includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions; wherein, when the processor invokes the program instructions to execute the resource scheduling method as described in any one of claims 1-8.