Resource scheduling method, computing device and system

Abstract

The invention provides a resource scheduling method, a computing device and a system, and the method comprises the steps: responding to a scheduling request of a container group, and determining a second virtual machine; wherein the host where the second virtual machine is located and the host where the first virtual machine where the container group is located are associated with the same storage resource group; migrating the container group from the first virtual machine to a second virtual machine; unmounting the first storage volume mounted on the first virtual machine from the first virtual machine; determining a second storage volume based on the second virtual machine and the first storage volume; wherein the storage resource where the second storage volume is located is located in the storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located; mounting the second storage volume to a second virtual machine, so that the container group can access the second storage volume in a local disk mode; therefore, when a complex topological relation exists between various storage resources on the cloud platform and the cloud platform host, resource scheduling can be quickly realized based on the storage resource group.

Description

Technical Field

[0001] This application relates to the field of cloud platform technology, and in particular to a resource scheduling method and computing device and system. Background Technology

[0002] Kubernetes (K8s) is a cloud-native application infrastructure that offers advantages such as rapid delivery, high elasticity, and high reliability. By running virtual machines as K8s nodes on a cloud platform, the resource advantages of the cloud platform can be fully utilized to achieve efficient container orchestration and management. In Kubernetes, a Pod (container group) is the smallest scheduling unit. A Pod contains one or more containers used to host specific business processes. During business operations, a large amount of data is generated, which needs to be stored in persistent volumes (PVs) on the containers. Persistent volumes are mounted into containers through storage plugins, thereby achieving persistent data storage.

[0003] However, when there are multiple storage resources in the cloud platform and there are complex topological relationships between these multiple storage resources and the cloud platform host, how to schedule Pods has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0004] This application provides a resource scheduling method, computing device, and system that can solve the problem of Pod scheduling difficulties when there are multiple storage resources on a cloud platform in the prior art.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a resource scheduling method, the method comprising: in the case of data migration of storage resources, scheduling of storage volumes using the whole-machine hot migration method of virtual machines. In response to a scheduling request for a container group, a second virtual machine is determined from the plurality of virtual machines; wherein the host where the second virtual machine resides is associated with the host where the first virtual machine containing the container group resides, and the host where the first virtual machine resides is associated with the same storage resource group; the container group is migrated from the first virtual machine to the second virtual machine; a first storage volume mounted on the first virtual machine is unmounted from the first virtual machine; a second storage volume is determined based on the second virtual machine and the first storage volume; wherein the storage resource containing the second storage volume is located in the storage resource group, and the host where the second virtual machine resides is associated with the storage resource containing the second storage volume; the second storage volume is mounted to the second virtual machine, so that the container group can access the second storage volume as a local disk.

[0007] Based on this solution, in response to a scheduling request from a container group, a second virtual machine is identified from multiple virtual machines. The host of the second virtual machine and the host of the first virtual machine (where the container group resides) are associated with the same storage resource group. The container group is migrated from the first virtual machine to the second virtual machine. The first storage volume mounted on the first virtual machine is unmounted. Based on the second virtual machine and the first storage volume, a second storage volume is identified. The storage resource containing the second storage volume is located within the storage resource group, and the host of the second virtual machine is associated with the storage resource containing the second storage volume. The second storage volume is mounted to the second virtual machine so that the container group can access the second storage volume as a local disk. Thus, storage volume scheduling based on storage resource groups can be completed, thereby enabling Pod scheduling. Therefore, in cloud platforms with multiple storage resources, especially when there are complex topological relationships between these storage resources and the cloud platform host, resource scheduling can be quickly and automatically achieved.

[0008] In one possible implementation, determining the second virtual machine from the plurality of virtual machines in response to a scheduling request for a container group includes: determining a storage resource group associated with the host where the first virtual machine resides in response to a scheduling request for a container group; obtaining resource configuration information of the storage resource group; wherein the resource configuration information includes a list of hosts associated with the storage resource group and a list of virtual machines running on the hosts; and determining the second virtual machine based on the list of hosts and the list of virtual machines.

[0009] Based on this scheme, by responding to the scheduling request of the scheduling container group, the storage resource group associated with the host where the first virtual machine is located is determined; the resource configuration information of the storage resource group is obtained; wherein, the resource configuration information includes a list of hosts associated with the storage resource group and a list of virtual machines running on the host; the second virtual machine is determined based on the list of hosts and the list of virtual machines; in this way, the target virtual machine after Pod scheduling can be determined based on the configuration information of the storage resource group associated with the host of the source virtual machine before Pod scheduling, thus laying the foundation for Pod scheduling.

[0010] In another possible implementation, the storage resource group includes at least one storage resource, and the resource configuration information further includes the status of the at least one storage resource; correspondingly, determining the second virtual machine based on the host list and the virtual machine list includes: determining the second virtual machine based on the status of the at least one storage resource; wherein the storage resource associated with the second virtual machine is in the status of being available.

[0011] Based on this scheme, when the storage resource group includes at least one storage resource and the resource configuration information also includes the status of at least one storage resource, the second virtual machine is determined based on the status of at least one storage resource; wherein the storage resource associated with the second virtual machine is in an available state; in this way, the destination virtual machine after Pod scheduling can be determined based on the status of each storage resource in the storage resource group associated with the host of the source virtual machine before Pod scheduling, thereby laying the foundation for Pod scheduling.

[0012] In another possible implementation, the resource configuration information further includes the association between the at least one storage resource and the plurality of virtual machines; correspondingly, determining the second virtual machine based on the host list and the virtual machine list further includes: determining the priority of the plurality of virtual machines based on the association; and determining the second virtual machine based on the priority.

[0013] Based on this scheme, by including the association between at least one storage resource and multiple virtual machines in the resource configuration information, the priority of multiple virtual machines is determined based on the association; based on the priority, the second virtual machine is determined; in this way, the target virtual machine after Pod scheduling can be determined based on the association between each storage resource in the storage resource group associated with the host of the source virtual machine before Pod scheduling and multiple virtual machines, thus laying the foundation for Pod scheduling.

[0014] In another possible implementation, determining the second storage volume based on the second virtual machine and the first storage volume includes: determining the second storage volume as the first storage volume when there is an association between the storage resource where the first storage volume is located and the host where the second virtual machine is located.

[0015] Based on this solution, the second storage volume is determined to be the first storage volume when there is an association between the storage resource where the first storage volume is located and the host where the second virtual machine is located. In this way, Pod scheduling can be achieved without performing storage volume migration operations when there is an association between the storage resource where the storage volume is located before scheduling and the host where the target virtual machine is located after Pod scheduling.

[0016] In another possible implementation, determining the second storage volume based on the second virtual machine and the first storage volume includes: when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, determining a target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located; migrating the data corresponding to the first storage volume to the target storage resource; and creating the second storage volume on the target storage resource.

[0017] Based on this solution, when there is no association between the storage resource where the first storage volume resides and the host where the second virtual machine resides, the target storage resource is determined based on the storage resources associated with the host where the first virtual machine resides and the storage resources associated with the host where the second virtual machine resides. The data corresponding to the first storage volume is migrated to the target storage resource. A second storage volume is created on the target storage resource. In this way, even when there is no association between the storage resource where the storage volume resides before scheduling and the host where the destination virtual machine resides after Pod scheduling, the target storage resource can be determined based on the storage resources associated with the host where the source virtual machine resides and the storage resources associated with the host where the destination virtual machine resides, thereby achieving storage volume scheduling.

[0018] In another possible implementation, determining the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located includes: when the host where the first virtual machine is located and the host where the second virtual machine is located are associated with the same first storage resource, and the first storage resource is located in the storage resource group, the first storage resource is determined as the target storage resource.

[0019] Based on this scheme, when the host where the first virtual machine is located and the host where the second virtual machine is located are associated with the same first storage resource, and the first storage resource is located in the storage resource group, the first storage resource is determined as the target storage resource. In this way, when the host where the first virtual machine is located and the host where the second virtual machine is located are associated with the same first storage resource, and the first storage resource is located in the storage resource group, the shared storage resource can be used to schedule the storage volume.

[0020] In another possible implementation, determining the target storage resource based on the storage resources associated with the host where the first virtual machine resides and the storage resources associated with the host where the second virtual machine resides includes: when the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, and the first storage resource is not located in the storage resource group, the storage resource associated with the host where the second virtual machine resides in the storage resource group is determined as the target storage resource; correspondingly, migrating the data corresponding to the first storage volume to the target storage resource includes: migrating the data corresponding to the first storage volume to the first storage resource; and migrating the data from the first storage resource to the target storage resource.

[0021] Based on this scheme, when the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, and the first storage resource is not located in a storage resource group, the storage resource associated with the host where the second virtual machine resides in the storage resource group is determined as the target storage resource. Correspondingly, the data corresponding to the first storage volume is migrated to the target storage resource, including: migrating the data corresponding to the first storage volume to the first storage resource; and migrating the data from the first storage resource to the target storage resource. In this way, when the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, and the first storage resource is not located in a storage resource group, the data of the storage volume is first migrated to the first storage resource, and then the data of the storage volume is migrated to the target storage resource through the first storage resource, thereby using the first storage resource as a bridge to realize the scheduling of the storage volume.

[0022] In another possible implementation, determining the target storage resource based on the storage resources associated with the host where the first virtual machine resides and the storage resources associated with the host where the second virtual machine resides includes: when the host where the first virtual machine resides and the host where the second virtual machine resides do not have the same associated storage resources, determining the storage resources associated with the host where the second virtual machine resides in the storage resource group as the target storage resource; correspondingly, migrating the data corresponding to the first storage volume to the target storage resource includes: if the cloud platform supports cross-storage resource data migration, determining the target application programming interface (API); and using the target API to migrate the data corresponding to the first storage volume to the target storage resource.

[0023] Based on this solution, when the host where the first virtual machine resides and the host where the second virtual machine resides are not associated with the same storage resources, the storage resource associated with the host where the second virtual machine resides in the storage resource group is determined as the target storage resource. Then, if the cloud platform supports cross-storage resource data migration, the target application programming interface (API) is determined. Using the target API, the data corresponding to the first storage volume is migrated to the target storage resource. In this way, storage volume scheduling can be achieved by using specific APIs supported by the cloud platform when the host where the first virtual machine resides and the host where the second virtual machine resides are not associated with the same storage resources.

[0024] In another possible implementation, determining the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located includes: terminating the scheduling of the container group when the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources; or, re-determining the second virtual machine when the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources.

[0025] Based on this solution, the scheduling of the container group is terminated when the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources; or, the second virtual machine is reassigned when the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources. In this way, the scheduling of the container group can be terminated or the second virtual machine can be reassigned directly when the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources, thereby meeting the user's needs.

[0026] Secondly, embodiments of this application provide a resource scheduling apparatus, comprising: a virtual machine determination unit, configured to determine a second virtual machine from a plurality of virtual machines in response to a scheduling request for a container group; wherein the host where the second virtual machine resides and the host where the first virtual machine, in which the container group resides, are associated with the same storage resource group; a container group migration unit, configured to migrate the container group from the first virtual machine to the second virtual machine; a storage volume unmounting unit, configured to unmount a first storage volume mounted on the first virtual machine from the first virtual machine; a storage volume determination unit, configured to determine a second storage volume based on the second virtual machine and the first storage volume; wherein the storage resource where the second storage volume resides is located in the storage resource group, and the host where the second virtual machine resides is associated with the storage resource where the second storage volume resides; and a storage volume mounting unit, configured to mount the second storage volume to the second virtual machine, so that the container group can access the second storage volume as a local disk.

[0027] Thirdly, embodiments of this application provide a computing device, the computing device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the following steps: in response to a scheduling request for a container group, determining a second virtual machine from a plurality of virtual machines; wherein the storage resources associated with the host where the second virtual machine resides are located in the same storage resource group as the storage resources associated with the host where the first virtual machine bound to the container group resides; migrating the container group from the first virtual machine to the second virtual machine; unmounting a first storage volume mounted on the first virtual machine from the first virtual machine; determining a second storage volume based on the second virtual machine and the first storage volume; wherein the storage resources where the second storage volume resides are located in the storage resource group; mounting the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

[0028] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for executing the resource scheduling method provided in the first aspect above.

[0029] Fifthly, embodiments of this application provide a computer program product that, when instructions in the computer program product are executed by a processor, performs the resource scheduling method provided in the first aspect above. Attached Figure Description

[0030] Figure 1A This is a schematic diagram of a system architecture provided in an embodiment of this application.

[0031] Figure 1B This is a schematic diagram of the composition structure of a cluster provided in an embodiment of this application.

[0032] Figure 2 This is a flowchart illustrating a resource scheduling method provided in an embodiment of this application.

[0033] Figure 3 This is a flowchart illustrating another resource scheduling method provided in an embodiment of this application.

[0034] Figure 4A This is a flowchart illustrating another resource scheduling method provided in an embodiment of this application.

[0035] Figure 4B This is a scenario diagram corresponding to a storage volume migration method provided in an embodiment of this application.

[0036] Figure 5A This is a flowchart illustrating another resource scheduling method provided in an embodiment of this application.

[0037] Figure 5B This is a scenario diagram corresponding to another storage volume migration method provided in the embodiments of this application.

[0038] Figure 5C This is a scenario diagram corresponding to another storage volume migration method provided in the embodiments of this application.

[0039] Figure 5D This is a scenario diagram corresponding to another storage volume migration method provided in the embodiments of this application.

[0040] Figure 6 This is a schematic diagram of the structure of a resource scheduling device provided in an embodiment of this application.

[0041] Figure 7 This is a schematic diagram of another resource scheduling device provided in an embodiment of this application.

[0042] Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0043] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0044] First, the relevant technical terms in the embodiments of this application will be explained:

[0045] Kubernetes (K8s): An open-source container orchestration platform for automating the deployment, scaling, and management of container groups.

[0046] Pod: Also known as a container group, it is the smallest deployable unit in Kubernetes. A Pod contains one or more containers and is typically used to run business processes.

[0047] Storage resource group: A logical group consisting of multiple storage resources, which can be used to record and manage the corresponding storage resources.

[0048] Volume migration: This is an operation where a volume from one of two storage resources associated with a host can be migrated to the other. This functionality is implemented by the cloud platform and triggered through Application Programming Interface (API) calls.

[0049] Virtual machine migration: An operation that refers to the complete migration of all virtual machine resources, including computing power, memory, and storage, from one host to another. This functionality is implemented by the cloud platform and triggered via API calls.

[0050] Pod scheduler: Implemented based on the K8s extended scheduler mechanism, it is used to schedule Pods to K8s nodes on cloud platform hosts bound to storage resources based on storage resource groups during Pod scheduling.

[0051] PV scheduler: Used to handle the storage volumes (such as persistent volumes) of Pods. After a Pod is scheduled to a Kubernetes Node, events such as volume creation, volume binding, volume mounting, and volume formatting are triggered, and the storage plugins perform the corresponding operations.

[0052] Persistent volume: A type of storage resource in Kubernetes that exists independently of the Pod's lifecycle and is used to persistently store data.

[0053] Persistent Volume Claim (PVC): A way for users to request storage resources. Through a PVC, users can apply to use a PV.

[0054] StorageClass: A resource type in Kubernetes used to define the category and configuration parameters of storage volumes, helping users select and create storage volumes that meet their requirements.

[0055] CSI (Container Storage Interface) is a standard interface used to connect different storage systems and container orchestration platforms, enabling storage plugins to interact with Kubernetes.

[0056] Controller: In the CSI architecture, the component responsible for handling control plane operations (such as creating and deleting volumes).

[0057] Node: In the CSI architecture, the component responsible for handling data plane operations (such as mounting and unmounting volumes).

[0058] Cloud platform: Public or private cloud service providers that provide infrastructure services such as computing and storage, such as AWS, Azure, and Google Cloud.

[0059] Virtual Machine (VM): A virtualized computing instance that runs on a cloud platform and can be used as a Kubernetes node.

[0060] Extended Scheduler: An extended Kubernetes scheduler that implements more complex scheduling logic through custom rules, ensuring that Pods are scheduled to the appropriate nodes.

[0061] Secret: A resource type in Kubernetes used to store sensitive information (such as usernames and passwords) and provide it to Pods in a secure manner.

[0062] Kubelet: A proxy process in Kubernetes that runs on each node and is responsible for managing the Pods and their containers on that node.

[0063] Containerd: A high-performance container runtime that manages the container lifecycle, including operations such as creating, starting, stopping, and destroying containers.

[0064] This application provides a resource scheduling method. In response to a container group's scheduling request, the method determines a second virtual machine from multiple virtual machines. The host of the second virtual machine and the host of the first virtual machine (where the container group resides) are associated with the same storage resource group. The container group is migrated from the first virtual machine to the second virtual machine. A first storage volume mounted on the first virtual machine is unmounted from the first virtual machine. Based on the second virtual machine and the first storage volume, a second storage volume is determined. The storage resource containing the second storage volume is located within the storage resource group, and the host of the second virtual machine is associated with the storage resource containing the second storage volume. The second storage volume is mounted to the second virtual machine so that the container group can access the second storage volume as a local disk. Thus, storage volume scheduling based on the storage resource group can be completed, thereby enabling Pod scheduling. Therefore, in a cloud platform with multiple storage resources, especially when there are complex topological relationships between these storage resources and the cloud platform host, resource scheduling can be quickly and automatically achieved.

[0065] The resource scheduling method provided in this application embodiment can be applied to, for example, Figure 1A The system architecture shown is as follows: Figure 1A As shown, the system architecture includes at least:

[0066] Container Management Platform 100 is used to manage at least one cloud platform, such as Figure 1A The cloud platforms are 110A to 110C. A cloud platform is a public or private cloud service provider that offers infrastructure services such as computing and storage, such as AWS, Azure, and Google Cloud. As the underlying infrastructure, the cloud platform provides Kubernetes clusters with K8s nodes (such as virtual machines) and storage resources.

[0067] Each cloud platform may include at least one host, which is a physical or virtual server running on the cloud platform and can serve as the host for Kubernetes nodes. For example, cloud platform 110A includes hosts 120A to 120C. Each host can run at least one virtual machine as a Kubernetes node. For example, host 120A runs virtual machines 130A to 130C, host 120B runs virtual machines 130D to 130F, and host 120C runs virtual machines 130G to 130I.

[0068] Furthermore, virtual machines on different hosts within a cloud platform can form different clusters, for example, Figure 1A Cluster 140A includes virtual machines 130A, 130D, and 130G; cluster 140B includes virtual machines 130B, 130E, and 130H; and cluster 140C includes virtual machines 130C, 130F, and 130I. It should be noted that the number of clusters in this application is not limited; any cluster may include at least one virtual machine, and this at least one virtual machine can run on any host.

[0069] like Figure 1A As shown, each cloud platform can also correspond to multiple storage resources; for example, cloud platform 110A corresponds to storage resources 150A to 150F. The storage resources corresponding to the cloud platform can be various types of storage, such as block storage, file storage, object storage, etc.

[0070] In this embodiment, the storage resources corresponding to the cloud platform can form at least one storage resource group; for example, storage resources 150A and 150B form one storage resource group, storage resources 150A, 150C, and 150D form another, storage resources 150C and 150E form yet another, and storage resource 150F is not in any storage resource group. Each storage resource group in this embodiment corresponds to a resource configuration information (which can be implemented through a K8s CRD instance). This resource configuration information records at least the following information: 1. Storage resource information included in the storage resource group, such as the identifier and priority of the storage resources (reference dimensions: capacity, performance, whether sharing is supported, etc.). 2. Whether the cloud platform supports cross-storage resource data migration for scenarios not associated with the same host. 3. Whether the cloud platform supports full-machine hot migration of virtual machines (migrating a virtual machine to another host while simultaneously migrating storage to a storage device associated with the new host).

[0071] In this embodiment, each cluster can be configured with a kubelet, a control component, node components, and the Pod scheduler and PV scheduler proposed in this embodiment. The Pod scheduler, implemented based on the Kubernetes extended scheduler mechanism, is primarily used to schedule Pods to Kubernetes nodes on cloud platform hosts bound to storage resources based on storage resource groups during Pod scheduling. The PV scheduler is mainly used to handle the scheduling of Pod storage volumes (such as persistent volumes). The control component is primarily responsible for cluster resource scheduling and management. For example, the control component may include a Kubernetes API server, which serves as the entry point for the Kubernetes cluster, responsible for receiving and processing requests from users or other components, providing a REST API interface, and performing authentication, authorization, and other operations. Alternatively, the control component may also include a Kubernetes Scheduler, which is responsible for Pod scheduling, selecting the optimal node for the Pod based on resource utilization, affinity, and other strategies. The node component is primarily responsible for container operation management and node resource scheduling.

[0072] like Figure 1B As shown, a cluster can include multiple virtual machines, such as virtual machine 1, virtual machine 2, ... virtual machine X. Each virtual machine can run at least one Pod, and each virtual machine node can include a kubelet and node components. The Pod scheduler, PV scheduler, and control components only run on one of the virtual machines, which is the control node, and the other virtual machines are worker nodes.

[0073] Furthermore, the Pod scheduler can be implemented based on the Kubernetes extended scheduler mechanism. During Pod scheduling, it schedules Pods to virtual machines on cloud platform hosts bound to storage resources based on the aforementioned storage resource groups. During Pod scheduling, it obtains the list of cloud platform hosts associated with the storage resource group, the virtual machines on those hosts, and the storage resource status. It then scores the virtual machines according to the priority and storage resource status recorded in the storage resource group's resource configuration information and returns candidate virtual machines. From these candidate virtual machines, the second virtual machine after Pod scheduling can be determined. Specifically, this can include three stages: pre-selection, sorting, and scheduling completion. In the pre-selection stage, only hosts associated with storage resources within available storage resource groups are selected. In the sorting stage, instances within the storage resource group are scored according to their priority and storage resource status (health, alerts, etc.), and the corresponding results are returned. In the scheduling completion stage, in conjunction with the native Kubernetes scheduler, a virtual machine is selected based on the scores to create a Pod. A Pod is the smallest deployable unit in Kubernetes. A Pod contains one or more containers used to host specific business processes. During business operation, Pods generate data, which needs to be persistently stored using persistent volumes (PVs). Storage plugins can interface with cloud platform storage resources by calling cloud platform APIs. A storage plugin typically includes at least two main components: a control unit and nodes. The PV scheduler is primarily used to handle persistent volume scheduling for Pods. After a Pod is scheduled to a virtual machine (Kubernetes Node), events such as volume creation, unbinding, binding, mounting, migrating, and formatting are triggered, and the storage plugin performs the corresponding operations. Specifically, volume creation refers to the storage plugin first obtaining the storage resources bound to the cloud platform host of the current virtual machine, then scoring them according to the priority and storage resource status recorded in the storage resource group, and selecting the highest-scoring storage resource to create the volume. Volume binding refers to the storage plugin calling the cloud platform's virtual machine disk binding API to bind the created volume to the virtual machine after the Pod is scheduled. Formatting the volume is an optional operation; it refers to the need to format the storage volume (i.e., establish a file system) when the Pod uses the storage volume as a file system. Unbinding the volume refers to the storage plugin calling the cloud platform's virtual machine unbinding disk API to unbind the volume from the virtual machine where the Pod resides. A volume migration refers to the PV scheduler calling the cloud platform's disk migration API or virtual machine full-machine migration API to migrate a storage volume (such as a persistent volume) from a storage resource associated with one host to a storage resource associated with another host. Here, both storage resources belong to the storage resource group where the storage volume used by the Pod is located.

[0074] It should be noted that in this embodiment, the PV scheduler can be used as a component of the storage plugin or as a separate component, as long as the normal communication conditions between the PV scheduler and the storage plugin are met. This embodiment does not impose any restrictions on this. Furthermore, this embodiment does not limit the number of cloud platforms, the number of hosts running on each cloud platform, the number of virtual machines running on each host, the number of clusters included in each cloud platform, the number of virtual machines included in each cluster, the number of storage resources corresponding to each cloud platform, or the number of storage resource groups. Those skilled in the art can configure these settings according to specific application scenarios.

[0075] Figure 2 This is a flowchart illustrating a resource scheduling method provided in an embodiment of this application. This embodiment can be applied to... Figure 1B On the virtual machine shown, as Figure 2 As shown, the method includes the following steps S201-S205.

[0076] Step S201: In response to the scheduling request of the container group, a second virtual machine is determined from multiple virtual machines; wherein the host where the second virtual machine is located is associated with the same storage resource group as the host where the first virtual machine where the container group is located.

[0077] For example, this step can be performed by running in Figure 1B The Pod scheduler on virtual machine 1 executes. Responding to a Pod's scheduling request, the Pod scheduler determines a second virtual machine from among the multiple virtual machines in the cluster. This second virtual machine becomes the destination virtual machine after Pod scheduling. For example, it can first select hosts with storage resources in an associated, available storage resource group, then score them according to the priority and storage resource status (health, alarms, etc.) recorded in the storage resource group's resource configuration information, and return candidate virtual machines. Finally, combining the results with the native Kubernetes scheduler (Kubernetes' own mechanism), a virtual machine is selected as the second virtual machine based on the scores.

[0078] In some examples, the host where the second virtual machine resides and the host where the first virtual machine (where the Pod resides) resides are associated with the same storage resource group in this embodiment. For example, if the storage resources associated with the host where the second virtual machine resides are storage resources A, B, and C, and the storage resources associated with the host where the first virtual machine (where the Pod resides before scheduling) resides are storage resources B and C, and the first storage resource group included in the cloud platform includes storage resources A, B, C, and D; then, the host where the second virtual machine resides and the host where the first virtual machine (where the Pod resides) resides are associated with the same storage resource group, and this same storage resource group is the first storage resource group. As another example, if the storage resource associated with the host where the second virtual machine resides is storage resource A, and the storage resource associated with the host where the first virtual machine (where the Pod resides before scheduling) resides is storage resource B, and the second storage resource group included in the cloud platform includes storage resources A, B, D, and E; then, the host where the second virtual machine resides and the host where the first virtual machine (where the Pod resides) resides are associated with the same storage resource group, and this same storage resource group is the second storage resource group.

[0079] Step S202: Migrate the container group from the first virtual machine to the second virtual machine.

[0080] For example, after the second virtual machine is identified, the Pod scheduler can be used to migrate the Pod from the first virtual machine to the second virtual machine.

[0081] Step S203: Unmount the first storage volume mounted on the first virtual machine from the first virtual machine.

[0082] For example, this step can be performed by running in Figure 1B The PV scheduler on virtual machine 1 executes. After identifying the second virtual machine, the PV scheduler can unmount the first storage volume mounted on the first virtual machine from the first virtual machine. For example, if the Pod uses the disk of the first virtual machine as the first persistent volume, and this disk is provided to the first virtual machine by the cloud platform host, then the cloud platform's virtual machine unbinding disk API can be called to unbind the first storage volume mounted on the first virtual machine from the first virtual machine where the Pod resides.

[0083] Step S204: Based on the second virtual machine and the first storage volume, determine the second storage volume; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0084] For example, in this embodiment of the application, the second storage volume to be used after Pod scheduling can be determined based on the identified second virtual machine (the virtual machine where the Pod resides after scheduling) and the first storage volume mounted on the first virtual machine. For instance, the second storage volume can be determined based on whether there is an association between the host where the second virtual machine resides and the storage resources where the first storage volume resides. Alternatively, the second storage volume can be determined based on the association between the host where the second virtual machine resides and the storage resources where the first storage volume resides, as well as the storage resource group corresponding to the cloud platform.

[0085] In some examples, the host where the second virtual machine resides and the host where the first virtual machine, which contains the container group, resides are associated with the same storage resource group. Furthermore, in this embodiment, the storage resource where the second storage volume resides is located within the storage resource group, and the host where the second virtual machine resides is associated with the storage resource where the second storage volume resides. For example, if the storage resources associated with the host where the first virtual machine resides are storage resources A, B, and C, the storage resource where the first storage volume resides is storage resource A, the storage resources associated with the host where the second virtual machine resides are storage resources B and C, and the host where the second virtual machine resides and the host where the first virtual machine, which contains the Pod, resides with the same storage resource group, and this storage resource group includes storage resources A, B, C, and E; then, the storage resource where the second storage volume resides can be storage resource B.

[0086] In some examples, after identifying the second virtual machine, the target storage resource can be determined based on the second virtual machine and the first storage volume. Then, the data corresponding to the first storage volume can be migrated to the target storage resource, and a second storage volume can be created on the target storage resource. For example, the PV scheduler can call the cloud platform's disk migration API to migrate the first storage volume from the host-associated storage resource of the first virtual machine to the host-associated storage resource of the second virtual machine, where both storage resources belong to the aforementioned common storage resource group.

[0087] Step S205: Mount the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

[0088] For example, this step can be performed by running in Figure 1B The PV scheduler on virtual machine 1 executes. In this embodiment, after determining the second storage volume, it can be mounted onto the second virtual machine, allowing the Pod to access the second storage volume as a local disk, thereby enabling Pod scheduling. For example, the cloud platform's virtual machine disk binding API can be called to bind the created second storage volume to the second virtual machine after Pod scheduling.

[0089] It should be noted that there is no restriction on the execution order of steps S202 and S203 in this embodiment of the application. Step S202 can be executed first, followed by steps S203-S205. Alternatively, steps S203-S205 can be executed first, followed by step S202.

[0090] The resource scheduling method provided in this application, in response to a scheduling request for a container group, determines a second virtual machine from multiple virtual machines. The host of the second virtual machine and the host of the first virtual machine (where the container group resides) are associated with the same storage resource group. The container group is migrated from the first virtual machine to the second virtual machine. A first storage volume mounted on the first virtual machine is unmounted from the first virtual machine. Based on the second virtual machine and the first storage volume, a second storage volume is determined. The storage resource containing the second storage volume is located in the storage resource group, and the host of the second virtual machine is associated with the storage resource containing the second storage volume. The second storage volume is mounted to the second virtual machine so that the container group can access the second storage volume as a local disk. Thus, the scheduling of storage volumes based on storage resource groups can be completed, thereby enabling Pod scheduling. Therefore, in a cloud platform with multiple storage resources, especially when there are complex topological relationships between these storage resources and the cloud platform host, resource scheduling can be quickly and automatically achieved.

[0091] like Figure 3 As shown above, in the above Figure 2 Based on the illustrated embodiment, step S201 may include the following steps S2011-S2013.

[0092] Step S2011: In response to the scheduling request of the scheduling container group, determine the storage resource group associated with the host where the first virtual machine is located.

[0093] For example, in response to a scheduling request for a Pod, the Pod scheduler can determine the storage resource group associated with the host where the first virtual machine resides. For instance, the storage resources in the cloud platform include storage resources A, B, C, D, E, and F; where storage resources A, B, and C constitute the first storage resource group, storage resources B and E constitute the second storage resource group, and storage resources A, E, and F constitute the third storage resource group. If the host where the first virtual machine resides is associated with storage resource A, then the storage resource group associated with the host where the first virtual machine resides is both the first and third storage resource groups.

[0094] Step S2012: Obtain the resource configuration information of the storage resource group; wherein, the resource configuration information includes the list of hosts associated with the storage resource group and the list of virtual machines running on the hosts.

[0095] For example, embodiments of this application may include at least one storage resource group, each storage resource group including at least one storage resource, and each storage resource group having corresponding resource configuration information. This resource configuration information includes, but is not limited to: a list of hosts associated with the storage resource group, and virtual machines running on each host in the associated host list. Therefore, the resource configuration information of the storage resource group associated with the host where the first virtual machine resides can be obtained;

[0096] Step S2013: Determine the second virtual machine based on the host list and the virtual machine list; wherein the host where the second virtual machine is located is associated with the same storage resource group as the host where the first virtual machine, which is the container group, is located.

[0097] For example, the second virtual machine can be determined based on the list of hosts and virtual machines recorded in the resource configuration information of the storage resource group associated with the host where the first virtual machine resides; wherein the host where the second virtual machine resides is associated with the same storage resource group as the host where the first virtual machine, which contains the container group, resides. For instance, the Pod scheduler can score multiple candidate nodes according to the priority and storage resource status recorded in the resource configuration information corresponding to the storage resource group associated with the host where the first virtual machine resides, based on the list of cloud platform hosts, the virtual machines on the hosts, and the status of the storage resources, and return multiple candidate nodes. The second virtual machine is then determined based on the sorting result of the multiple candidate nodes according to their scores.

[0098] The resource scheduling method provided in this application, in response to a scheduling request for a container group, determines the storage resource group associated with the host where the first virtual machine resides; obtains the resource configuration information of the storage resource group; wherein the resource configuration information includes a list of hosts associated with the storage resource group and a list of virtual machines running on the host; and determines the second virtual machine based on the host list and the virtual machine list; thus, the target virtual machine after Pod scheduling can be determined based on the configuration information of the storage resource group associated with the host of the source virtual machine before Pod scheduling, thereby laying the foundation for Pod scheduling.

[0099] In some embodiments, the storage resource group includes at least one storage resource, and the resource configuration information also includes the status of at least one storage resource; correspondingly, step S2013, determining the second virtual machine based on the host list and the virtual machine list, includes: determining the second virtual machine based on the status of at least one storage resource; wherein the status of the storage resource associated with the second virtual machine is available.

[0100] For example, the storage resource group in this embodiment includes at least one storage resource. Therefore, the resource configuration information of the storage resource group associated with the host where the first virtual machine resides also includes the status of at least one storage resource. The status of each storage resource is used to indicate whether it is an available or unavailable storage resource. Furthermore, based on the content recorded in the resource configuration information, the virtual machine on the host associated with the available storage resource can be selected as the second virtual machine. In this way, the destination virtual machine after Pod scheduling can be determined based on the status of each storage resource in the storage resource group associated with the host of the source virtual machine before Pod scheduling, thus laying the foundation for Pod scheduling.

[0101] In some embodiments, the resource configuration information further includes the association between at least one storage resource and multiple virtual machines; correspondingly, step S2013, determining the second virtual machine based on the host list and the virtual machine list, further includes: determining the priority of the multiple virtual machines based on the association; and determining the second virtual machine based on the priority.

[0102] For example, the storage resource group in this embodiment includes at least one storage resource. Therefore, the resource configuration information of the storage resource group associated with the host where the first virtual machine resides also includes the association between at least one storage resource and multiple virtual machines in the cloud platform. The association between at least one storage resource and multiple virtual machines in the cloud platform refers to whether there is an association between at least one storage resource and the host where each virtual machine resides. Furthermore, based on this association, the priority of multiple virtual machines can be determined; and the virtual machine with the highest priority can be identified as the second virtual machine.

[0103] For example, if the association between at least one storage resource and multiple virtual machines has been determined, the priority of multiple virtual machines can be determined based on the rule that "virtual machines located on the same cloud platform host" have a higher priority than "virtual machines located on different cloud platform hosts but associated with the storage resources of the storage volume used by the Pod" has a higher priority than "virtual machines located on different cloud platform hosts but associated with the same storage resources on both cloud platform hosts" has a higher priority than "virtual machines located on different cloud platform hosts and not associated with the same storage resources on both cloud platform hosts". The virtual machine with the higher priority is then designated as the second virtual machine. In this way, based on the association between each storage resource in the storage resource group associated with the host of the source virtual machine before Pod scheduling and multiple virtual machines, combined with the set priority rules, the target virtual machine after Pod scheduling can be determined, thus laying the foundation for Pod scheduling.

[0104] Of course, in some embodiments, the resource configuration information of the storage resource group associated with the host where the first virtual machine is located also includes the priority of each storage resource in the storage resource group. This priority can be set by the user, and then the virtual machine associated with the storage resource with the highest priority can be selected as the second virtual machine.

[0105] like Figure 4A As shown above, in the above Figure 2 Based on the illustrated embodiment, step S204 may include the following step S2041a.

[0106] Step S2041a: When the storage resource where the first storage volume is located is associated with the host where the second virtual machine is located, the second storage volume is determined to be the first storage volume; wherein, the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0107] For example, if the storage resource where the first storage volume is located is associated with the host where the second virtual machine is located, the second storage volume can be directly identified as the first storage volume.

[0108] For example, such as Figure 4B As shown, the cloud platform's storage resources include storage resource groups and storage resource D outside of these groups; the storage resource group includes storage resources A, B, and C. Host 1 runs K8sNode 1 (the first virtual machine) and K8s Node 2 (the second virtual machine), and host 1 is associated with storage resource A. Host 2 runs multiple K8s Nodes (virtual machines), and host 2 is not associated with any storage resources. Meanwhile, the Pod before scheduling (the old Pod) uses the disk of K8sNode 1 as its first storage volume, which is provided to K8s Node 1 by storage resource A associated with host 1 on the cloud platform. The Pod after scheduling (the new Pod) resides on K8s Node 2. Figure 4B As can be seen, cloud platform host 1, where K8s Node 2 is located, is associated with storage resource A. Therefore, it can be determined that the second storage volume is the first storage volume. Therefore, the first storage volume (such as a persistent volume PV) can be unmounted (unbound) from K8s Node 1, and then the unmounted first storage volume (i.e., the second storage volume) can be mounted (bound) to K8s Node 2 via storage resource A.

[0109] The resource scheduling method provided in this application determines the second storage volume as the first storage volume when there is an association between the storage resource where the first storage volume is located and the host where the second virtual machine is located. In this way, Pod scheduling can be achieved without performing storage volume migration operations when there is an association between the storage resource where the storage volume is located before scheduling and the host where the target virtual machine is located after Pod scheduling.

[0110] like Figure 5A As shown above, in the above Figure 2 Based on the illustrated embodiment, step S204 may include the following steps S2041b-S2043b.

[0111] Step S2041b: When there is no association between the storage resources where the first storage volume is located and the host where the second virtual machine is located, determine the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located.

[0112] For example, if the storage resource where the first storage volume resides is not associated with the host where the second virtual machine resides, the target storage resource can be determined based on the storage resources associated with the host where the first virtual machine resides and the storage resources associated with the host where the second virtual machine resides. For instance, it can be determined whether there is an intersection between the storage resources associated with the host where the first virtual machine resides and the storage resources associated with the host where the second virtual machine resides, and the target storage resource can be determined from that intersection.

[0113] Step S2042b: Migrate the data corresponding to the first storage volume to the target storage resource;

[0114] For example, in this embodiment of the application, after the target storage resource is determined, the data corresponding to the first storage volume can be migrated to the target storage resource.

[0115] Step S2043b: Create a second storage volume on the target storage resource; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0116] For example, after migrating the data corresponding to the first storage volume to the target storage resource, a second storage volume can be created on the target storage resource.

[0117] For example, such as Figure 5BAs shown, the cloud platform storage resources include storage resource groups and storage resource D outside of these groups; the storage resource group includes storage resources A, B, and C. Host 1 runs K8sNode 1 (the first virtual machine), and host 1 is associated with storage resources A, B, and C. Host 2 runs K8s Node 2 (the second virtual machine) and K8s Node 3, and host 2 is associated with storage resources B and C. Meanwhile, the Pod before scheduling (the old Pod) uses the disk of K8s Node 1 as its first storage volume (e.g., a persistent volume PV), which is provided to K8s Node 1 by storage resource A associated with host 1. The Pod after scheduling (the new Pod) resides on K8s Node 2. As can be seen from 5B, the storage resources associated with the host where the first virtual machine resides overlap with the storage resources associated with the host where the second virtual machine resides, and this overlap includes storage resources B and C. Furthermore, based on the priority recorded in the resource configuration information, storage resource B is determined to have a higher priority than storage resource C, and therefore storage resource B is designated as the target storage resource. Thus, the data corresponding to the first storage volume can be migrated to the target storage resource B, and a second storage volume can be created on the target storage resource B.

[0118] The resource scheduling method provided in this application determines the target storage resource based on the storage resources associated with the host where the first storage volume is located and the host where the second virtual machine is located when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located. The data corresponding to the first storage volume is migrated to the target storage resource. A second storage volume is created on the target storage resource. In this way, the target storage resource can be determined based on the storage resources associated with the host where the source virtual machine is located and the storage resources associated with the host where the destination virtual machine is located when there is no association between the storage resource where the storage volume is located before scheduling and the host where the destination virtual machine is located after Pod scheduling, thereby realizing the scheduling of storage volumes.

[0119] In some embodiments, step S2041b, when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, determines the target storage resource based on the storage resource associated with the host where the first virtual machine is located and the storage resource associated with the host where the second virtual machine is located, including: if, in the case that there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, the host where the first virtual machine is located and the host where the second virtual machine is located are associated with the same first storage resource, and the first storage resource is located in a storage resource group, then the first storage resource is determined as the target storage resource.

[0120] For example, in this embodiment of the application, if the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, and the first storage resource is located in a storage resource group, then the first storage resource can be identified as the target storage resource. Furthermore, the data corresponding to the first storage volume can be migrated to the target storage resource, and a second storage volume can be created on the target storage resource. For example, such as... Figure 5B As shown, the host of the first virtual machine and the host of the second virtual machine are associated with the same first storage resource, which is storage resource B and storage resource C. Furthermore, both storage resource B and storage resource C are located in a storage resource group. Therefore, either storage resource B or storage resource C can be identified as the target storage resource. In this way, when the host of the first virtual machine and the host of the second virtual machine are associated with the same first storage resource, and the first storage resource is located in the storage resource group, storage volume scheduling can be achieved using shared storage resources.

[0121] In some embodiments, step S2041b, when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, determines the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located, including: if, in the case that there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, the host where the first virtual machine is located and the host where the second virtual machine is located are associated with the same first storage resource, and the first storage resource is not located in the storage resource group, then the storage resource associated with the host where the second virtual machine is located in the storage resource group is determined as the target storage resource; correspondingly, step S2042b, migrating the data corresponding to the first storage volume to the target storage resource, includes: migrating the data corresponding to the first storage volume to the first storage resource; and migrating the data from the first storage resource to the target storage resource.

[0122] For example, in this embodiment of the application, if the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, but the first storage resource is not located in a storage resource group, then the storage resource in the storage resource group associated with the host where the second virtual machine resides is determined as the target storage resource. Then, the data corresponding to the first storage volume is first migrated to the first storage resource, and then the data is migrated from the first storage resource to the target storage resource. In this way, even when the host where the first virtual machine resides and the host where the second virtual machine resides are associated with the same first storage resource, and the first storage resource is not located in a storage resource group, the data of the storage volume can be migrated to the first storage resource first, and then the data of the storage volume can be migrated to the target storage resource through the first storage resource, thereby utilizing the first storage resource as a bridge to achieve storage volume scheduling.

[0123] For example, such as Figure 5C As shown, the cloud platform storage resources include storage resource groups and storage resource D outside of these groups; the storage resource group includes storage resources A, B, and C. Host 1 runs K8sNode 1 (the first virtual machine), and host 1 is associated with storage resources A and D. Host 2 runs K8s Node 2 (the second virtual machine) and K8s Node 3, and host 2 is associated with storage resources B and D. Meanwhile, the Pod before scheduling (the old Pod) uses the disk of K8s Node 1 as its first storage volume (e.g., a persistent volume PV), which is provided to K8s Node 1 by storage resource A associated with host 1. The Pod after scheduling (the new Pod) resides on K8s Node 2. Figure 5C As can be seen, the host where the first virtual machine resides and the host where the second virtual machine resides share the same first storage resource, which is storage resource D. Since storage resource D is not located in the storage resource group, storage resource B, which is associated with the host where the second virtual machine resides within the storage resource group, can be identified as the target storage resource. Therefore, the data corresponding to the first storage volume can be migrated to storage resource D first, and then the data can be migrated from storage resource D to storage resource B.

[0124] In some embodiments, step S2041b, when the storage resource where the first storage volume is located is not associated with the host where the second virtual machine is located, determines the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located, including: if the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resource, then the storage resource associated with the host where the second virtual machine is located in the storage resource group is determined as the target storage resource; correspondingly, step S2042b, migrating the data corresponding to the first storage volume to the target storage resource, includes: if the cloud platform supports cross-storage resource data migration function, determining the target application interface; using the target application interface, migrating the data corresponding to the first storage volume to the target storage resource.

[0125] For example, in this embodiment of the application, if the host where the first virtual machine resides and the host where the second virtual machine resides are not associated with the same storage resources, the storage resource associated with the host where the second virtual machine resides in the storage resource group can be determined as the target storage resource. Then, if the cloud platform supports cross-storage resource data migration, a target application programming interface (API) is determined; using the target API, the data corresponding to the first storage volume is migrated to the target storage resource. In this way, storage volume scheduling can be achieved using specific APIs supported by the cloud platform, even when the host where the first virtual machine resides and the host where the second virtual machine resides are not associated with the same storage resources.

[0126] In some embodiments, if the host where the first virtual machine resides and the host where the second virtual machine resides are not associated with the same storage resources, the storage resource in the storage resource group associated with the host where the second virtual machine resides can be determined as the target storage resource. Then, the data corresponding to the first storage volume can be migrated to the target storage resource using a virtual machine hot migration method.

[0127] For example, such as Figure 5D As shown, the cloud platform storage resources include storage resource groups and storage resource D outside of these groups; the storage resource group includes storage resources A, B, and C. Host 1 runs K8sNode 1 (the first virtual machine), and host 1 is associated with storage resource A. Host 2 runs K8s Node 2 (the second virtual machine), and host 2 is associated with storage resource C. Meanwhile, the Pod before scheduling (the old Pod) uses the disk of K8s Node 1 as its first storage volume (e.g., a persistent volume PV), which is provided to K8s Node 1 by storage resource A associated with host 1. The Pod after scheduling (the new Pod) resides on K8s Node 2. Figure 5D As can be seen, the host of the first virtual machine and the host of the second virtual machine are not associated with the same storage resources. Therefore, the storage resource C associated with the host of the second virtual machine in the storage resource group can be identified as the target storage resource. Then, the data corresponding to the first storage volume can be migrated to storage resource C using the target application programming interface; or, the data corresponding to the first storage volume can be migrated to storage resource C using a virtual machine hot migration method. Specifically, the virtual machine hot migration method can be a full-scale virtual machine hot migration of K8s Node 1, migrating K8s Node 1 to host 2 to obtain K8s Node 1'. The migrated K8s Node 1' can then be used to migrate the data of the first storage volume, enabling it to be migrated from storage resource A to storage resource C.

[0128] In some embodiments, step S2041b, when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, determines the target storage resource based on the storage resource associated with the host where the first virtual machine is located and the storage resource associated with the host where the second virtual machine is located, including: if there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, and if the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resource, then the scheduling of the container group is terminated; or, if the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resource, then the second virtual machine is re-determined.

[0129] For example, if the host where the first virtual machine is located and the host where the second virtual machine is located are not associated with the same storage resources, the scheduling of the Pod can be terminated directly, or the second virtual machine can be reassigned.

[0130] Corresponding to the aforementioned resource scheduling method embodiments, this application also provides an embodiment of a resource scheduling apparatus. Figure 6 A resource scheduling device provided in the embodiments of this application, such as Figure 6 As shown, the resource scheduling device 600 includes a virtual machine determination unit 601, a container group migration unit 602, a storage volume unmounting unit 603, a storage volume determination unit 604, and a storage volume mounting unit 605.

[0131] The virtual machine determination unit 601 is used to determine a second virtual machine from multiple virtual machines in response to a scheduling request for a scheduling container group; wherein the host where the second virtual machine is located is associated with the same storage resource group as the host where the first virtual machine, where the container group is located, is located.

[0132] Container group migration unit 602 is used to migrate a container group from a first virtual machine to a second virtual machine;

[0133] Storage volume unmounting unit 603 is used to unmount the first storage volume mounted on the first virtual machine from the first virtual machine;

[0134] The storage volume determination unit 604 is used to determine the second storage volume based on the second virtual machine and the first storage volume; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located;

[0135] Storage volume mounting unit 605 is used to mount the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

[0136] For example, Figure 1B The Pod scheduler includes at least the virtual machine determination unit 601 and the container group migration unit 602. Figure 1B The PV scheduler in the system includes at least the storage volume unmounting unit 603, the storage volume determining unit 604, and the storage volume mounting unit 605.

[0137] In one possible implementation, such as Figure 7 As shown, the virtual machine determination unit 601 includes a resource group determination subunit 6011, a configuration information determination subunit 6012, and a virtual machine determination subunit 6013.

[0138] Resource group determination subunit 6011 is used to determine the storage resource group associated with the host where the first virtual machine is located in response to the scheduling request of the scheduling container group;

[0139] The configuration information determination subunit 6012 is used to obtain the resource configuration information of the storage resource group; wherein, the resource configuration information includes a list of hosts associated with the storage resource group and a list of virtual machines running on the hosts;

[0140] The virtual machine determination subunit 6013 is used to determine the second virtual machine based on the host list and the virtual machine list; wherein the host where the second virtual machine is located is associated with the same storage resource group as the host where the first virtual machine, which is the container group, is located.

[0141] In another possible implementation, the storage resource group includes at least one storage resource, and the resource configuration information also includes the status of at least one storage resource;

[0142] Correspondingly, the virtual machine determination subunit 6013 is specifically used to determine the second virtual machine based on the status of at least one storage resource; wherein the storage resource associated with the second virtual machine is in an available state; wherein the host where the second virtual machine is located is associated with the same storage resource group as the host where the first virtual machine, which is the container group, is located.

[0143] In another possible implementation, the resource configuration information also includes the association between at least one storage resource and multiple virtual machines;

[0144] Correspondingly, the virtual machine determination subunit 6013 is specifically used to determine the priority of multiple virtual machines based on the association relationship; and to determine the second virtual machine based on the priority; wherein the host where the second virtual machine is located is associated with the host where the first virtual machine, where the container group is located, is located, and they are associated with the same storage resource group.

[0145] In another possible implementation, the storage volume determination unit 604 is specifically used to determine the second storage volume as the first storage volume when there is an association between the storage resource where the first storage volume is located and the host where the second virtual machine is located; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0146] In another possible implementation, the storage volume determination unit 604 is specifically used to determine the target storage resource based on the storage resources associated with the host where the first storage volume is located and the host where the second virtual machine is located when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located; migrate the data corresponding to the first storage volume to the target storage resource; and create a second storage volume on the target storage resource; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0147] In another possible implementation, the storage volume determination unit 604 is specifically used to determine the first storage resource as the target storage resource when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, and the host where the first virtual machine is located is associated with the same first storage resource and the first storage resource is located in a storage resource group; migrate the data corresponding to the first storage volume to the target storage resource; and create a second storage volume on the target storage resource; wherein the storage resource where the second storage volume is located is located in a storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0148] In another possible implementation, the storage volume determination unit 604 is specifically used to determine the storage resource associated with the host where the second virtual machine is located as the target storage resource when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, and the host where the first virtual machine is located is associated with the same first storage resource, and the first storage resource is not located in the storage resource group; migrate the data corresponding to the first storage volume to the target storage resource; and create a second storage volume on the target storage resource; wherein the storage resource where the second storage volume is located is located in the storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0149] In another possible implementation, the storage volume determination unit 604 is specifically used to determine the storage resource associated with the host where the second virtual machine is located as the target storage resource when there is no association between the storage resource where the first storage volume is located and the host where the second virtual machine is located, and the host where the first virtual machine is located is associated with the same first storage resource, and the first storage resource is not located in the storage resource group; migrate the data corresponding to the first storage volume to the first storage resource; migrate the data from the first storage resource to the target storage resource; and create a second storage volume on the target storage resource; wherein the storage resource where the second storage volume is located is located in the storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located.

[0150] The beneficial technical effects corresponding to the above-described exemplary embodiment of the resource scheduling device 600 can be found in the corresponding beneficial technical effects in the above-described method embodiment section, and will not be repeated here.

[0151] Corresponding to the aforementioned resource scheduling method embodiments, this application also provides an embodiment of a computing device. The computing device includes a processor and a memory for storing processor-executable instructions. The processor is configured to read executable instructions from the memory and execute the instructions to perform the following steps: in response to a container group scheduling request, determining a second virtual machine from a plurality of virtual machines; wherein the storage resources associated with the host where the second virtual machine resides are located in the same storage resource group as the storage resources associated with the host where the first virtual machine bound to the container group resides; migrating the container group from the first virtual machine to the second virtual machine; unmounting a first storage volume mounted on the first virtual machine from the first virtual machine; determining a second storage volume based on the second virtual machine and the first storage volume; wherein the storage resources where the second storage volume resides are located in the storage resource group; and mounting the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

[0152] For example, if the Pod scheduler and PV scheduler described above are located on host 120A of cluster 140A, then the computing device in this embodiment is host 120A. Furthermore, the plurality of virtual machines may include a plurality of virtual machines in cluster 140A.

[0153] It should be noted that the beneficial technical effects corresponding to the above exemplary embodiments of the computing device can be found in the corresponding beneficial technical effects in the above method embodiment section, and will not be repeated here.

[0154] Corresponding to the aforementioned resource scheduling method embodiments, this application also provides an embodiment of a resource scheduling system. This resource scheduling system includes at least a container group scheduling module and a storage volume scheduling module. Wherein,

[0155] The container group scheduling module is used to respond to the scheduling request of the container group, determine the second virtual machine from multiple virtual machines; wherein the storage resources associated with the host where the second virtual machine is located are in the same storage resource group as the storage resources associated with the host where the first virtual machine bound to the container group is located; and migrate the container group from the first virtual machine to the second virtual machine.

[0156] The storage volume scheduling module is used to unmount the first storage volume mounted on the first virtual machine from the first virtual machine; determine the second storage volume based on the second virtual machine and the first storage volume; wherein the storage resource where the second storage volume is located is located in the storage resource group; and mount the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

[0157] For example, the container group scheduling module can be the above Figure 1B The Pod scheduler located on virtual machine 1, and the storage volume scheduling module can be the one described above. Figure 1B The PV scheduler is located on virtual machine 1.

[0158] It should be noted that the beneficial technical effects corresponding to the above exemplary embodiment of the resource scheduling system can be found in the corresponding beneficial technical effects in the above method embodiment section, and will not be repeated here.

[0159] Figure 8 This is a schematic diagram of the structure of a computing device 800 provided in an embodiment of this application. The computing device 800 can be a host on a cloud platform, such as... Figure 1A The host computer is 120A. For example... Figure 8 As shown, the hardware entity of the computing device 800 includes: a processor 801, a communication interface 802, and a memory 803, wherein,

[0160] The processor 801 typically controls the overall operation of the computing device 800.

[0161] The communication interface 802 enables the computing device 800 to communicate with other electronic devices or servers via a network.

[0162] The memory 803 is configured to store instructions and applications executable by the processor 801, and can also cache data to be processed or already processed by the processor 801 and the various modules in the computing device 800. It can be implemented by FLASH (flash memory) or RAM (Random Access Memory).

[0163] In addition to the methods and apparatus described above, embodiments of this application may also provide a computer program product, including computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the resource scheduling methods of the various embodiments of this application described in the above method embodiment section.

[0164] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0165] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the resource scheduling methods of the various embodiments of this application described in the above-described method embodiment section.

[0166] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0167] The basic principles of this application have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details of the above embodiments are for illustrative and facilitative purposes only, and are not limitations. These details do not restrict this application from being implemented using the aforementioned specific details.

[0168] Those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0169] Furthermore, the embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A resource scheduling method, characterized in that, The method includes: In response to a scheduling request for a container group, a second virtual machine is determined from multiple virtual machines; wherein the host where the second virtual machine resides is associated with the same storage resource group as the host where the first virtual machine, in which the container group resides. Migrate the container group from the first virtual machine to the second virtual machine; Unmount the first storage volume that was mounted on the first virtual machine from the first virtual machine; Based on the second virtual machine and the first storage volume, a second storage volume is determined; wherein the storage resource where the second storage volume is located is located in the storage resource group, and the host where the second virtual machine is located is associated with the storage resource where the second storage volume is located; The second storage volume is mounted to the second virtual machine so that the container group can access the second storage volume as a local disk.

2. The method according to claim 1, characterized in that, The step of determining a second virtual machine from the plurality of virtual machines in response to a scheduling request for a scheduling container group includes: In response to a scheduling request for a container group, determine the storage resource group associated with the host where the first virtual machine resides; Obtain the resource configuration information of the storage resource group; wherein, the resource configuration information includes a list of hosts associated with the storage resource group and a list of virtual machines running on the hosts; The second virtual machine is determined based on the host list and the virtual machine list.

3. The method according to claim 2, characterized in that, The storage resource group includes at least one storage resource, and the resource configuration information also includes the status of the at least one storage resource; Correspondingly, determining the second virtual machine based on the host list and the virtual machine list includes: The second virtual machine is determined based on the status of the at least one storage resource; wherein the storage resource associated with the second virtual machine is in an available state.

4. The method according to claim 3, characterized in that, The resource configuration information also includes the association between the at least one storage resource and the plurality of virtual machines; Correspondingly, determining the second virtual machine based on the host list and the virtual machine list further includes: Based on the aforementioned relationship, the priority of the plurality of virtual machines is determined; The second virtual machine is determined based on the priority.

5. The method according to claim 1, characterized in that, The step of determining the second storage volume based on the second virtual machine and the first storage volume includes: When the storage resource where the first storage volume is located is associated with the host where the second virtual machine is located, the second storage volume is determined to be the first storage volume.

6. The method according to claim 1, characterized in that, The step of determining the second storage volume based on the second virtual machine and the first storage volume includes: When there is no association between the storage resources where the first storage volume is located and the host where the second virtual machine is located, the target storage resource is determined based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located. Migrate the data corresponding to the first storage volume to the target storage resource; Create the second storage volume on the target storage resource.

7. The method according to claim 6, characterized in that, The step of determining the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located includes: When the host where the first virtual machine is located is associated with the same first storage resource as the host where the second virtual machine is located, and the first storage resource is located in the storage resource group, the first storage resource is determined as the target storage resource.

8. The method according to claim 6, characterized in that, The step of determining the target storage resource based on the storage resources associated with the host where the first virtual machine is located and the storage resources associated with the host where the second virtual machine is located includes: When the host where the first virtual machine is located is associated with the same first storage resource as the host where the second virtual machine is located, and the first storage resource is not located in the storage resource group, the storage resource in the storage resource group associated with the host where the second virtual machine is located is determined as the target storage resource; Correspondingly, migrating the data corresponding to the first storage volume to the target storage resource includes: Migrate the data corresponding to the first storage volume to the first storage resource; The data is migrated from the first storage resource to the target storage resource.

9. A computing device, characterized in that, The computing device includes: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to perform the following steps: in response to a scheduling request for a container group, determining a second virtual machine from a plurality of virtual machines; wherein the storage resources associated with the host where the second virtual machine resides are located in the same storage resource group as the storage resources associated with the host where the first virtual machine to which the container group is bound resides; migrating the container group from the first virtual machine to the second virtual machine; unmounting a first storage volume mounted on the first virtual machine from the first virtual machine; determining a second storage volume based on the second virtual machine and the first storage volume; wherein the storage resources where the second storage volume resides are located in the storage resource group; and mounting the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

10. A resource scheduling system, characterized in that, The system includes: The container group scheduling module is used to respond to a scheduling request for scheduling a container group, determine a second virtual machine from multiple virtual machines, wherein the storage resources associated with the host where the second virtual machine is located are in the same storage resource group as the storage resources associated with the host where the first virtual machine bound to the container group is located; and migrate the container group from the first virtual machine to the second virtual machine. The storage volume scheduling module is used to unmount the first storage volume mounted on the first virtual machine from the first virtual machine; determine the second storage volume based on the second virtual machine and the first storage volume; wherein the storage resource where the second storage volume is located is located in the storage resource group; and mount the second storage volume to the second virtual machine so that the container group can access the second storage volume as a local disk.

Images