Scheduling method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a scheduling method and device, computer equipment, a readable storage medium and a program product, and relates to the technical field of cloud computing and container arrangement. The method comprises the following steps: under the condition that a scheduling request sent by a target scheduler is received, determining a Pod to be scheduled and resource information required by scheduling according to the scheduling request; determining whether the Pod to be scheduled is in a locked state or not; under the condition that the target scheduler is not in the locking state, locking the to-be-scheduled Pod by adopting a preset distributed lock, and taking the target scheduler as a holder of the preset distributed lock; determining a target node matched with the resource information in the at least one slave node, and scheduling the Pod to be scheduled to the target node through a target scheduler; and after scheduling completion information sent by the target node is received, unlocking the to-be-scheduled Pod. By adopting the method, the scheduling conflict problem of multiple schedulers can be solved, and the system performance and reliability are ensured.

Description

Technical Field

[0001] The present application relates to the technical field of cloud computing and container orchestration, and in particular to a scheduling method, apparatus, computer equipment, readable storage medium, and program product. Background Art

[0002] In the Kubernetes (K8S) environment, the scheduler is the key component responsible for binding the Pod (container group) to be assigned to the appropriate node. By default, the scheduler in the Kubernetes cluster runs as a single instance, that is, usually, only one scheduler in a cluster can handle the scheduling task of the Pod. The single-instance scheduler can ensure the consistency of the scheduling process, avoid scheduling conflicts or resource competition caused by the simultaneous operation of multiple schedulers, and the scheduling is simple, without having to deal with the conflict management issues of concurrent scheduling.

[0003] With the popularity of cloud computing and containerized applications, more and more applications need to run in large-scale cluster environments, which puts higher requirements on the performance and scalability of schedulers. The single-instance scheduler model is insufficient in some high-load and complex environments. The main problems include: single point failure problem: the single-instance scheduler model has the risk of single point failure. Once the scheduler fails, the scheduling function of the entire cluster may be interrupted; performance bottleneck problem: in a large-scale cluster, all scheduling requests are handled by a single scheduler, which is easy to form a performance bottleneck and increase scheduling delays; lack of flexibility: single-instance schedulers usually adopt conservative scheduling strategies and are difficult to meet diverse scheduling needs; in order to solve these problems, the industry has begun to explore the multi-scheduler model, that is, running multiple scheduler instances in the same Kubernetes cluster.

[0004] Running multiple schedulers simultaneously introduces new problems, especially scheduling conflicts, which means that multiple schedulers trying to schedule the same Pod at the same time may cause resource competition or scheduling failure. In traditional methods, Kubernetes lacks an effective mechanism to coordinate conflicts between multiple schedulers, and usually resolves conflicts by increasing complexity or sacrificing performance. However, in large-scale, high-concurrency applications, especially in cloud-native application environments that require high reliability and low latency, traditional scheduling methods have the problem of difficulty in ensuring both system performance and reliability. Summary of the invention

[0005] Based on this, it is necessary to provide a scheduling method, device, computer equipment, computer-readable storage medium and computer program product that can solve the scheduling conflict problem of multiple schedulers and ensure system performance and reliability in response to the above technical problems.

[0006] In a first aspect, the present application provides a scheduling method, which is applied to a master node, comprising:

[0007] When receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request;

[0008] Determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information in at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler;

[0009] After receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked.

[0010] In one embodiment, the scheduling method further includes:

[0011] When a scheduling exception occurs during the process of executing a scheduling operation on the Pod to be scheduled through the target scheduler, the target scheduler unlocks the Pod to be scheduled;

[0012] Take the reference scheduling request from the request queue, use the preset distributed lock to lock the Pod to be scheduled, and use the scheduler corresponding to the reference scheduling request as the holder of the preset distributed lock;

[0013] The Pod to be scheduled is scheduled to the target node by referring to the scheduler corresponding to the scheduling request.

[0014] In one embodiment, the scheduling method further includes:

[0015] When a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue.

[0016] In one embodiment, the scheduling method further includes:

[0017] After the Pod to be scheduled is locked successfully using the preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node.

[0018] In one embodiment, the scheduling method further includes:

[0019] In the event of a master node failure, a target master node is determined in at least one slave node, and the target master node is used to determine pending scheduling requests based on the latest completed scheduling requests and request queues, and schedule the pending scheduling requests.

[0020] In one embodiment, the scheduling method further includes:

[0021] When the failed reference node recovers to normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0022] In a second aspect, the present application further provides a scheduling device, applied to a master node, comprising:

[0023] A determination module is used to determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request when receiving the scheduling request sent by the target scheduler;

[0024] The scheduling module is used to determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, the Pod to be scheduled is locked using a preset distributed lock, and the target scheduler is used as the holder of the preset distributed lock; a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler;

[0025] The processing module is used to unlock the Pod to be scheduled after receiving the scheduling completion information sent by the target node.

[0026] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0027] When receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request;

[0028] Determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information in at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler;

[0029] After receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0031] When receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request;

[0032] Determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information in at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler;

[0033] After receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked.

[0034] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0035] When receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request;

[0036] Determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information in at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler;

[0037] After receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked.

[0038] The above-mentioned scheduling method, apparatus, computer equipment, computer-readable storage medium and computer program product, by determining the Pod to be scheduled and the resource information required for scheduling according to the scheduling request when receiving the scheduling request sent by the target scheduler, and determining whether the Pod to be scheduled is in a locked state. Since the target scheduler cannot schedule the Pod to be scheduled in a locked state, for the Pod to be scheduled that is not in a locked state, a preset distributed lock is used to lock the Pod to be scheduled, and the target scheduler is used as the holder of the preset distributed lock. In this way, on the one hand, the target scheduler can schedule the Pod to be scheduled, and on the other hand, it can avoid scheduling conflicts caused by scheduling the Pod to be scheduled by other schedulers; further, a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler. After receiving the scheduling completion information sent by the target node, it indicates that the scheduling of the Pod to be scheduled is completed, and the Pod to be scheduled is unlocked, so that other schedulers can continue to schedule the Pod to be scheduled. The above-mentioned scheduling method solves the scheduling conflict problem of multiple schedulers in large-scale and high-concurrency scenarios, and ensures system performance and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0040] Figure 1 An application environment diagram of a scheduling method in an embodiment;

[0041] Figure 2 A schematic diagram of a scheduling method in one embodiment;

[0042] Figure 3 A schematic diagram of the relationship between a master node, a slave node, and a scheduler in one embodiment;

[0043] Figure 4 Schematic diagram of the overall flow of a scheduling method in one embodiment;

[0044] Figure 5 is a structural block diagram of a scheduling device in an embodiment;

[0045] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

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

[0047] The scheduling method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. This embodiment uses the method to apply to the master node in the Kubernetes cluster environment as an example. The master node can be a server, a terminal, or a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. When the server 104 receives the scheduling request sent by the target scheduler, it determines the resource information required for the Pod to be scheduled and the scheduling according to the scheduling request; determines whether the Pod to be scheduled is in a locked state; if it is not in a locked state, the preset distributed lock is used to lock the Pod to be scheduled, and the target scheduler is used as the holder of the preset distributed lock; determines the target node that matches the resource information in at least one slave node, and schedules the Pod to be scheduled to the target node through the target scheduler; after receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked. The terminal 102 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, IoT devices, and portable wearable devices. The IoT devices may be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. Head-mounted devices may be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server 104 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0048] In an exemplary embodiment, Figure 2 As shown, a scheduling method is provided, which is applied to Figure 1 The server 104 in the example is used as an example to illustrate the method, which includes the following steps 202 to 206. Among them:

[0049] Step 202: upon receiving a scheduling request sent by a target scheduler, determine the Pod to be scheduled and resource information required for scheduling according to the scheduling request.

[0050] The server can be a master node in a Kubernetes cluster environment. The master node can be a leader node elected in the cluster based on the Raft protocol (Reliable and Available Distributed Fault-Tolerant Consensus Protocol, a distributed consistency algorithm for managing replicated state machines). The Raft protocol is a distributed consistency algorithm used to manage consistency issues in distributed systems. Raft ensures data consistency of all nodes in the cluster by electing a leader node and replicating logs. It is a consensus algorithm that is easy to understand and implement, and has good readability and operability.

[0051] The scheduler is a component in the Kubernetes cluster that is responsible for scheduling the Pod to be scheduled to run on the appropriate node. The scheduler makes scheduling decisions based on factors such as resource requirements, policies, and constraints. The target scheduler is the scheduler that sends scheduling requests to the master node. Scheduling requests are requests for scheduling Pods to be scheduled.

[0052] In the scenario where multiple schedulers are running at the same time, the master node can receive scheduling requests sent by multiple schedulers. The master node contains a coordinator to manage scheduling conflicts under multiple schedulers and ensure the high availability of the scheduler. For example, when receiving scheduling requests sent by multiple schedulers, the coordinator can respond to the earliest received scheduling request and the scheduling request with the highest priority.

[0053] Pod is the smallest schedulable unit in a Kubernetes cluster, containing one or more containers. The containers in a Pod share the network and storage, and are always co-scheduled and run on a node. The Pod to be scheduled is the Pod that the target scheduler needs to schedule.

[0054] In some embodiments, when the target scheduler needs to schedule the Pod to be scheduled, the target scheduler sends a scheduling request to the coordinator in the master node, which includes the identification information of the Pod to be scheduled, the resource information required to schedule the Pod to be scheduled, and the identification information of the target scheduler.

[0055] The resource information required for scheduling refers to the type and quantity of resources required when the Pod to be scheduled runs in the node.

[0056] Step 204, determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information from at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler.

[0057] Distributed Lock refers to a mechanism used to coordinate access to shared resources in a distributed system. Distributed Lock ensures that in a multi-node environment, a resource can only be held by one node at a time. The lock state refers to the state in which the Pod to be scheduled is locked using a preset distributed lock.

[0058] When the Pod to be scheduled is in a locked state, each scheduler cannot schedule the Pod to be scheduled. When the Pod to be scheduled is not in a locked state, in response to the scheduling request sent by the target scheduler, the coordinator of the master node uses the preset distributed lock to lock the Pod to be scheduled, and uses the target scheduler as the holder of the preset distributed lock. In this way, the Pod to be scheduled is locked by the target scheduler, which can avoid scheduling conflicts caused by other schedulers scheduling the Pod to be scheduled.

[0059] The target scheduler is used to schedule the Pod to be scheduled to the appropriate node. At least one node refers to other nodes in the Kubernetes cluster except the master node, and the target node is a node in at least one slave node that matches the resource information. In some embodiments, the resource information includes multiple resource types and the number of resources corresponding to each resource type. The coordinator of the master node obtains the available resource types and available resource quantities of at least one node, and selects a target node from at least one node that matches the available resource types, available resource quantities, and resource information indicated by the scheduling request. For example, the available resource types in the target node include the resource types indicated by the scheduling request, and the number of available resources under each resource type is not less than the number of resources under the resource type indicated by the scheduling request.

[0060] The master node schedules the Pod to be scheduled to the target node through the target scheduler to instruct the target node to run the Pod to be scheduled.

[0061] like Figure 3The figure shows a schematic diagram of the relationship between the master node, slave nodes and scheduler in one embodiment. Among them, the Raft protocol can be used between the master node and each slave node to ensure the data consistency of all nodes in the cluster. Each scheduler A, B, and C initiates the same scheduling request, which is used to schedule the Pod to be scheduled. The master node coordinates the relationship between multiple schedulers through the coordinator to resolve the scheduling conflicts caused by the simultaneous operation of multiple schedulers. The master node is mainly used for locking judgment, locking and conflict handling, scheduling condition checking, and scheduling execution.

[0062] Step 206: After receiving the scheduling completion information sent by the target node, unlock the Pod to be scheduled.

[0063] After the Pod to be scheduled is completed, the target node sends a scheduling completion message to the master node. After receiving the scheduling completion message, the master node releases the preset distributed lock on the Pod to be scheduled. Since the current holder of the preset distributed lock is the target scheduler, the target scheduler has released the lock on the Pod to be scheduled, and the coordinator can assign the Pod to be scheduled to other schedulers for scheduling.

[0064] In the above scheduling method, when receiving a scheduling request sent by the target scheduler, the Pod to be scheduled and the resource information required for scheduling are determined according to the scheduling request, and whether the Pod to be scheduled is in a locked state is determined. Since the target scheduler cannot schedule the Pod to be scheduled in a locked state, for the Pod to be scheduled that is not in a locked state, a preset distributed lock is used to lock the Pod to be scheduled, and the target scheduler is used as the holder of the preset distributed lock. In this way, on the one hand, the target scheduler can schedule the Pod to be scheduled, and on the other hand, it can avoid scheduling conflicts caused by scheduling of the Pod to be scheduled by other schedulers; further, a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler. After receiving the scheduling completion information sent by the target node, it indicates that the scheduling of the Pod to be scheduled is completed, and the Pod to be scheduled is unlocked, so that other schedulers can continue to schedule the Pod to be scheduled. The above scheduling method solves the scheduling conflict problem of multiple schedulers in large-scale and high-concurrency scenarios, and ensures system performance and reliability.

[0065] In an exemplary embodiment, the scheduling method also includes: in the event of a scheduling exception during the process of executing a scheduling operation on the Pod to be scheduled through the target scheduler, releasing the lock of the Pod to be scheduled by the target scheduler; taking out a reference scheduling request from the request queue, locking the Pod to be scheduled using a preset distributed lock, and referring to the scheduler corresponding to the scheduling request as the holder of the preset distributed lock; and scheduling the Pod to be scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0066] Among them, scheduling exception refers to the scheduling failure or scheduling timeout that occurs when the target scheduler performs scheduling operations on the Pod to be scheduled. In the case of scheduling exceptions, the coordinator of the master node can release the lock of the target scheduler on the Pod to be scheduled, so that other schedulers can schedule the Pod to be scheduled.

[0067] The request queue refers to the queue for storing scheduling requests. The request queue may store pending scheduling requests. The coordinator takes the reference scheduling request from the request queue, and uses the preset distributed lock to lock the Pod to be scheduled, and uses the scheduler corresponding to the reference scheduling request as the holder of the preset distributed lock. In this way, the Pod to be scheduled can be scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0068] In this embodiment, when a scheduling exception occurs in the target scheduler, a reference scheduling request is taken out from the request queue, and the Pod to be scheduled is locked and scheduled using the scheduler corresponding to the reference scheduling request, thereby realizing parallel scheduling of multiple schedulers. In addition, a method of locking with a preset distributed lock is adopted to avoid scheduling conflicts during the scheduling process of multiple schedulers, thereby improving scheduling efficiency.

[0069] In an exemplary embodiment, the scheduling method further includes: when a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, adding the scheduling request sent by the reference scheduler to a request queue.

[0070] Among them, in the process of the Pod to be scheduled being scheduled by the target scheduler, since the Pod to be scheduled is in a locked state, if a scheduling request sent by the reference scheduler is received, the reference scheduler is a scheduler different from the target scheduler, and the scheduling request of the reference scheduler indicates that the Pod to be scheduled should be scheduled, then the coordinator of the master node can add the reference scheduler to the request queue to wait for the scheduling of the Pod to be scheduled to be completed before continuing the scheduling.

[0071] In some embodiments, the coordinator of the master node may also block the scheduling request of the reference scheduler and wait for the scheduling of the coordinator.

[0072] In this embodiment, when a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue to temporarily suspend the response to the reference scheduler to avoid scheduling conflicts caused by multiple schedulers scheduling the same Pod; at the same time, the scheduling requests in the request queue can be coordinated and scheduled by the coordinator after the scheduling of the Pod to be scheduled is completed, which is beneficial to ensure the performance and reliability of the system.

[0073] In an exemplary embodiment, the scheduling method further includes: after successfully locking the Pod to be scheduled using a preset distributed lock, sending locking success information, identification information of the Pod to be scheduled, and identification information of the holder of the preset distributed lock to at least one slave node.

[0074] Among them, after the coordinator of the master node successfully locks the Pod to be scheduled using the preset distributed lock, it generates a lock success message, and sends the lock success message, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock to at least one slave node.

[0075] If the current holder of the preset distributed lock is the target scheduler, the identification information of the target scheduler is sent to at least one slave node to synchronize the information between the master node and the slave node, thereby ensuring the consistency of information in all nodes in the cluster.

[0076] In some embodiments, the coordinator of the master node may also write all received scheduling requests into a log and copy the log to each slave node. When more than a preset number of slave nodes confirm receipt of the log, the master node begins to execute the scheduling method, that is, determining the Pod to be scheduled and the resource information required for scheduling according to the scheduling request, until the scheduling completion information sent by the target node is received, and then the Pod to be scheduled is unlocked.

[0077] In this embodiment, after successfully locking the Pod to be scheduled using a preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node to synchronize the information between the master node and the slave node, thereby ensuring the consistency of information in all nodes in the cluster.

[0078] In an exemplary embodiment, the scheduling method also includes: in the event of a failure of the master node, determining a target master node among at least one slave node, the target master node being used to determine the scheduling requests to be processed based on the latest processed scheduling requests and request queue, and scheduling the scheduling requests to be processed.

[0079] The failure of the master node refers to a failure that causes the master node to fail to operate normally. For example, network failure, hardware failure, or downtime caused by other reasons. Since each slave node has copied all the information of the master node, a new master node, i.e., a target master node, can be determined from at least one slave node. For example, the Raft protocol can be used to determine the target master node.

[0080] The target master node has the same information as the original master node, including the request queue, lock success information, identification information of the Pod to be scheduled, and identification information of the holder of the preset distributed lock, etc. Therefore, the target master node can be used to continue to execute the scheduling method to ensure the continuity of the scheduling.

[0081] The latest processed scheduling request refers to the scheduling request that has received the scheduling completion information returned by the target node. When the master node fails and there is no scheduling request in the scheduling process, the scheduling request is taken out of the request queue as the scheduling request to be processed, and the scheduling request to be processed is scheduled through the target master node.

[0082] When there is a scheduling request in the scheduling process at the time when the master node fails, the scheduling request corresponding to the time when the master node fails is used as a pending scheduling request, and the pending scheduling request is scheduled through the target master node.

[0083] In this embodiment, in the event of a failure of the master node, the target master node is re-determined. Since the target master node has a copy of the information of the original master node, the scheduling method can continue to be executed through the target master node. At the same time, based on the latest processed scheduling request and request queue, the scheduling request to be processed is determined, and the scheduling request to be processed is scheduled through the target master node. On the one hand, the continuity of the scheduling process is guaranteed, and on the other hand, the high availability of the system is ensured through multi-node replica deployment.

[0084] In an exemplary embodiment, the scheduling method also includes: when the failed reference node recovers to a normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0085] The reference node refers to the node where the fault occurs, which can be a master node or a slave node. When the reference node recovers to normal state, the master node at the current moment or other slave nodes can send the lock success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock to the reference node, and use the reference node as a slave node to make the reference node rejoin the cluster.

[0086] In this embodiment, by copying the information in the node to the reference node when the failed reference node recovers to a normal state, the information consistency of each node can be ensured. The reference node rejoins the cluster as a slave node and can continue to participate in the execution of the scheduling method.

[0087] To illustrate the effect of the scheduling method in this solution in detail, a most detailed embodiment is described below:

[0088] The scheduling method proposed in this embodiment can be applied to a Kubernetes cluster environment, for example, in a complex container orchestration scenario with concurrent scheduling of multiple schedulers. Specific application scenarios may include: Large-scale cloud-native application scenarios: There are multiple schedulers in a large Kubernetes cluster to handle different workloads, such as batch tasks, high-priority application scheduling, etc. These schedulers need to work together to avoid scheduling conflicts and improve cluster resource utilization. Scheduler high availability scenario: In a Kubernetes cluster, in order to ensure high availability, you can consider deploying the scheduler as a multi-copy collaborative job. The scheduling efficiency of the scheduler is required to be high. Therefore, the scheduling conflict detection function needs to be transferred to the coordinator, and the coordinator should also be in a high availability state.

[0089] like Figure 4 The figure shows the overall flow diagram of the scheduling method in one embodiment. In a Kubernetes cluster, multiple scheduler instances are running. These schedulers try to schedule the same Pod at the same time according to different policies or tenant requirements. In order to avoid conflicts, the coordinator implements a multi-copy mechanism according to the Raft protocol to ensure that each Pod can only be scheduled by one scheduler. The specific implementation steps are as follows:

[0090] 1. The scheduler initiates a scheduling request:

[0091] Scheduler A detects that there is a Pod to be scheduled (Pod X) and sends a scheduling request to the coordinator of the master node.

[0092] At the same time, Scheduler B also found that the same Pod X was in the waiting-to-be-scheduled state, so it also initiated a scheduling request.

[0093] 2. The master node receives the scheduling request:

[0094] The coordinator of the master node receives the scheduling requests from Scheduler A and Scheduler B. The master node is responsible for processing all scheduling requests and writing the request information to the log.

[0095] 3. Distributed locking and conflict handling:

[0096] The master node first determines whether Pod X is in a locked state. If Pod X is not in a locked state, the master node will try to obtain the lock of Pod X and assign it to Scheduler A, that is, lock Pod X to Scheduler A. At this point, PodX is in a locked state, and other schedulers cannot schedule Pod X, that is, the master node rejects the scheduling requests of other schedulers.

[0097] After the lock is successful, Scheduler A obtains the lock of Pod X, and the master node copies the lock information (including the identification information of the holder Scheduler A) to other slave nodes to ensure consistency.

[0098] When Scheduler B's scheduling request arrives, the coordinator detects that Pod X has been locked by Scheduler A, so Scheduler B's scheduling request will be rejected or added to the waiting queue.

[0099] 4. Scheduling condition check:

[0100] After obtaining the lock of Pod X, Scheduler A determines whether the scheduling conditions are met, for example, whether the target node has sufficient resources, whether the network and storage status are normal, etc. If the scheduling conditions are met, Scheduler A will continue to perform the scheduling operation and schedule Pod X to the target node; if the scheduling conditions are not met, the scheduling operation will be terminated and Pod X will be unlocked.

[0101] 5. Scheduling execution and lock release:

[0102] After Scheduler A successfully schedules Pod X to the target node, it releases the lock of Pod X through the coordinator. After the lock is released, other schedulers can try to schedule Pod X again, or the coordinator processes the next request in the request queue.

[0103] 6. Scheduling conflict handling:

[0104] If Scheduler A fails or times out during the scheduling process, the coordinator will automatically release the lock of Pod X, allowing other schedulers to retry scheduling.

[0105] In some embodiments, in actual operation, a node in the coordinator cluster may go down due to network failure, hardware failure or other reasons. In order to ensure the continuity of scheduling operations, the coordinator cluster implements multi-copy deployment through the Raft protocol to ensure high availability of the system. The specific implementation steps are as follows:

[0106] 1. Deployment of the coordinator cluster:

[0107] The coordinator is deployed in a Kubernetes cluster in multiple copies, usually with at least three nodes (for example, master node A, slave node B, and slave node C). The Raft protocol uses an election mechanism to ensure that there is only one master node (Leader) in the cluster, and the other nodes are slave nodes (Followers).

[0108] 2. Log replication and consistency guarantee:

[0109] The master node is responsible for receiving all scheduling requests and recording them in its log. The master node then copies the log entries to other slave nodes to ensure that the log status of all nodes is consistent. When more than a preset number of slave nodes confirm receipt of the log entry, the master node will submit the log entry and perform the corresponding scheduling operation.

[0110] 3. Master node failure and election:

[0111] If the master node (e.g., node A) goes offline due to a fault, the remaining slave nodes will detect that the master node is disconnected and start the election process for a new master node. Slave nodes B and C will compete for the new master node, and the node with the most votes will become the new master node and continue to process scheduling requests. The new master node will start from the last submitted log entry and continue to synchronize unfinished scheduling tasks to ensure system continuity.

[0112] 4. Fault recovery and data consistency:

[0113] When the failed node A comes back online, it will automatically synchronize the latest log entries from the new master node or slave node to restore its data status. The recovered node will rejoin the coordinator cluster as a slave node and continue to participate in log replication and consistency assurance.

[0114] The above scheduling method determines whether the Pod to be scheduled is in a locked state by determining the resource information required for scheduling and the Pod to be scheduled according to the scheduling request when receiving the scheduling request sent by the target scheduler. Since the target scheduler cannot schedule the Pod to be scheduled in a locked state, for the Pod to be scheduled that is not in a locked state, a preset distributed lock is used to lock the Pod to be scheduled, and the target scheduler is used as the holder of the preset distributed lock. In this way, on the one hand, the target scheduler can schedule the Pod to be scheduled, and on the other hand, it can avoid scheduling conflicts caused by scheduling of the Pod to be scheduled by other schedulers; further, a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler. After receiving the scheduling completion information sent by the target node, it indicates that the scheduling of the Pod to be scheduled is completed, and the Pod to be scheduled is unlocked, so that other schedulers can continue to schedule the Pod to be scheduled. The above scheduling method solves the scheduling conflict problem of multiple schedulers in large-scale and high-concurrency scenarios, while ensuring system performance and reliability. In addition, optimistic distributed scheduling in a multi-scheduler environment is implemented. Through distributed locks and conflict handling mechanisms, it is ensured that each Pod can only be successfully scheduled by one scheduler at the same time, avoiding resource competition and scheduling failures. The scheduling performance is optimized, the scheduling delay caused by conflict handling is reduced, and the utilization rate of cluster resources and the operating efficiency of the scheduler are improved. The high availability and fault recovery capability of the coordinator are achieved through the multi-copy mechanism of the Raft protocol. When the master node fails, the system can automatically elect a new master node to maintain the normal scheduling operation. The data consistency guarantee mechanism ensures the reliability and accuracy of scheduling operations in high concurrency and complex network environments, and avoids conflicts and data inconsistencies between schedulers.

[0115] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0116] Based on the same inventive concept, the embodiment of the present application also provides a scheduling device for implementing the scheduling method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more scheduling device embodiments provided below can refer to the above limitations on the scheduling method, which will not be repeated here.

[0117] In an exemplary embodiment, Figure 5 As shown, a scheduling device 500 is provided, comprising: a determination module 520, a scheduling module 540 and a processing module 560, wherein:

[0118] A determination module 520 is used to determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request when receiving the scheduling request sent by the target scheduler;

[0119] The scheduling module 540 is used to determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, the Pod to be scheduled is locked using a preset distributed lock, and the target scheduler is used as the holder of the preset distributed lock; a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler;

[0120] The processing module 560 is used to unlock the Pod to be scheduled after receiving the scheduling completion information sent by the target node.

[0121] The above-mentioned scheduling device, by determining the Pod to be scheduled and the resource information required for scheduling according to the scheduling request when receiving the scheduling request sent by the target scheduler, determines whether the Pod to be scheduled is in a locked state. Since the target scheduler cannot schedule the Pod to be scheduled in a locked state, for the Pod to be scheduled that is not in a locked state, a preset distributed lock is used to lock the Pod to be scheduled, and the target scheduler is used as the holder of the preset distributed lock. In this way, on the one hand, the target scheduler can schedule the Pod to be scheduled, and on the other hand, it can avoid scheduling conflicts caused by other schedulers scheduling the Pod to be scheduled; further, a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler. After receiving the scheduling completion information sent by the target node, it indicates that the scheduling of the Pod to be scheduled is completed, and the Pod to be scheduled is unlocked, so that other schedulers can continue to schedule the Pod to be scheduled. The above-mentioned scheduling method solves the scheduling conflict problem of multiple schedulers in large-scale and high-concurrency scenarios, while ensuring system performance and reliability.

[0122] In one embodiment, the scheduling device 500 also includes an exception handling module, which is used to: when a scheduling exception occurs during the process of performing a scheduling operation on the Pod to be scheduled through the target scheduler, release the lock of the Pod to be scheduled by the target scheduler; take out the reference scheduling request from the request queue, use a preset distributed lock to lock the Pod to be scheduled, and use the scheduler corresponding to the reference scheduling request as the holder of the preset distributed lock; schedule the Pod to be scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0123] In one embodiment, the scheduling device 500 further includes a multi-scheduler processing module, which is used to: upon receiving a scheduling request sent by a reference scheduler and the Pod to be scheduled is in a locked state, add the scheduling request sent by the reference scheduler to a request queue.

[0124] In one embodiment, the scheduling device 500 also includes an information synchronization module, which is further used to: after successfully locking the Pod to be scheduled using a preset distributed lock, send the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock to at least one slave node.

[0125] In one embodiment, the scheduling device 500 also includes a fault handling module, which is used to: in the event of a failure in the master node, determine a target master node among at least one slave node, the target master node being used to determine the scheduling requests to be processed based on the latest processed scheduling requests and request queues, and schedule the scheduling requests to be processed.

[0126] In one embodiment, the scheduling device 500 further includes a fault recovery processing module, which is used to:

[0127] When the failed reference node recovers to normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0128] Each module in the above scheduling device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0129] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used for scheduling requests, storing Pods to be scheduled, resource information required for scheduling, etc. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a scheduling method is implemented.

[0130] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0131] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0132] Upon receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request; determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information from at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler; after receiving the scheduling completion information sent by the target node, unlock the Pod to be scheduled.

[0133] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0134] In the event of a scheduling exception during the process of executing a scheduling operation on the Pod to be scheduled through the target scheduler, the target scheduler unlocks the Pod to be scheduled; the reference scheduling request is taken out from the request queue, the Pod to be scheduled is locked using a preset distributed lock, and the scheduler corresponding to the reference scheduling request is used as the holder of the preset distributed lock; the Pod to be scheduled is scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0135] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0136] When a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue.

[0137] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0138] After the Pod to be scheduled is locked successfully using the preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node.

[0139] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0140] In the event of a master node failure, a target master node is determined in at least one slave node, and the target master node is used to determine pending scheduling requests based on the latest completed scheduling requests and request queues, and schedule the pending scheduling requests.

[0141] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0142] When the failed reference node recovers to normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0143] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0144] Upon receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request; determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information from at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler; after receiving the scheduling completion information sent by the target node, unlock the Pod to be scheduled.

[0145] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0146] In the event of a scheduling exception during the process of executing a scheduling operation on the Pod to be scheduled through the target scheduler, the target scheduler unlocks the Pod to be scheduled; the reference scheduling request is taken out from the request queue, the Pod to be scheduled is locked using a preset distributed lock, and the scheduler corresponding to the reference scheduling request is used as the holder of the preset distributed lock; the Pod to be scheduled is scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0147] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0148] When a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue.

[0149] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0150] After the Pod to be scheduled is locked successfully using the preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node.

[0151] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0152] In the event of a master node failure, a target master node is determined in at least one slave node, and the target master node is used to determine pending scheduling requests based on the latest completed scheduling requests and request queues, and schedule the pending scheduling requests.

[0153] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0154] When the failed reference node recovers to normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0155] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0156] Upon receiving a scheduling request sent by the target scheduler, determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request; determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, use a preset distributed lock to lock the Pod to be scheduled, and use the target scheduler as the holder of the preset distributed lock; determine a target node that matches the resource information from at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler; after receiving the scheduling completion information sent by the target node, unlock the Pod to be scheduled.

[0157] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0158] In the event of a scheduling exception during the process of executing a scheduling operation on the Pod to be scheduled through the target scheduler, the target scheduler unlocks the Pod to be scheduled; the reference scheduling request is taken out from the request queue, the Pod to be scheduled is locked using a preset distributed lock, and the scheduler corresponding to the reference scheduling request is used as the holder of the preset distributed lock; the Pod to be scheduled is scheduled to the target node through the scheduler corresponding to the reference scheduling request.

[0159] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0160] When a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue.

[0161] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0162] After the Pod to be scheduled is locked successfully using the preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node.

[0163] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0164] In the event of a master node failure, a target master node is determined in at least one slave node, and the target master node is used to determine pending scheduling requests based on the latest completed scheduling requests and request queues, and schedule the pending scheduling requests.

[0165] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0166] When the failed reference node recovers to normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

[0167] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0168] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0169] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0170] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A scheduling method, characterized in that: Applied to the master node, the method comprises: Upon receiving a scheduling request sent by the target scheduler, determining the Pod to be scheduled and resource information required for scheduling according to the scheduling request; Determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, lock the Pod to be scheduled using a preset distributed lock, and use the target scheduler as the holder of the preset distributed lock; determine a target node matching the resource information in at least one slave node, and schedule the Pod to be scheduled to the target node through the target scheduler; After receiving the scheduling completion information sent by the target node, the Pod to be scheduled is unlocked.

2. The method according to claim 1, characterized in that: The method further comprises: In the event that a scheduling exception occurs during the process of executing a scheduling operation on the Pod to be scheduled by the target scheduler, unlocking the Pod to be scheduled by the target scheduler; Take out a reference scheduling request from the request queue, use the preset distributed lock to lock the Pod to be scheduled, and use the scheduler corresponding to the reference scheduling request as the holder of the preset distributed lock; The Pod to be scheduled is scheduled to the target node through the scheduler corresponding to the reference scheduling request.

3. The method according to claim 1, characterized in that The method further comprises: When a scheduling request sent by a reference scheduler is received and the Pod to be scheduled is in a locked state, the scheduling request sent by the reference scheduler is added to the request queue.

4. The method according to claim 1, characterized in that The method further comprises: After the Pod to be scheduled is locked successfully by using the preset distributed lock, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to at least one slave node.

5. The method according to claim 4, characterized in that The method further comprises: In the event of a master node failure, a target master node is determined in at least one slave node, and the target master node is used to determine pending scheduling requests based on the latest completed scheduling requests and request queues, and schedule the pending scheduling requests.

6. The method according to claim 1, characterized in that The method further comprises: When the failed reference node recovers to a normal state, the locking success information, the identification information of the Pod to be scheduled, and the identification information of the holder of the preset distributed lock are sent to the reference node, and the reference node is used as a slave node.

7. A scheduling device, characterized in that: Applied to a master node, the device comprises: A determination module is used to determine the Pod to be scheduled and the resource information required for scheduling according to the scheduling request when receiving the scheduling request sent by the target scheduler; The scheduling module is used to determine whether the Pod to be scheduled is in a locked state; if it is not in a locked state, the Pod to be scheduled is locked using a preset distributed lock, and the target scheduler is used as the holder of the preset distributed lock; a target node matching the resource information is determined in at least one slave node, and the Pod to be scheduled is scheduled to the target node through the target scheduler; The processing module is used to unlock the Pod to be scheduled after receiving the scheduling completion information sent by the target node.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images