A distributed timed task management method and device

Abstract

The present application provides a method and device for managing distributed timed tasks, the method comprising: if a change event is detected, node election is triggered; if any node is elected as the current master node for executing the timed task assignment, the working status of other nodes except any one node among multiple nodes is traversed, and multiple working nodes are determined from other nodes; multiple timed tasks in a first configuration file are traversed, and multiple timed tasks are respectively bound to corresponding ones of multiple working nodes, and a first mapping relationship between multiple timed tasks and multiple working nodes is constructed; the constructed first mapping relationship is stored in the first configuration file, and multiple timed tasks are assigned to a corresponding working node according to the first mapping relationship, so that the assigned timed tasks are executed by the working node. The present application reduces the software cost brought by the introduction of third-party storage middleware by using existing resources for data storage.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a method and device for managing distributed scheduled tasks. Background Art

[0002] In the software industry, with the rapid development of various technologies, cloud native technology is one of the fastest growing and popular technologies, and kubernetes cluster is one of the most representative frameworks. As a very important scheduling framework in a software system, the scheduled task framework is often used to handle tasks that need to be executed at a scheduled time. Although after years of development, there are already a variety of scheduled task frameworks on the market for users to choose from, these existing frameworks need an additional storage middleware to store the information of each node, such as zookeeper or redis, in order to achieve distributed operation.

[0003] When deploying the existing scheduled task framework to the Kubernetes cluster, it is necessary to introduce third-party middleware for data storage. The introduction of other middleware will make the management of the software system more complicated and also cause a waste of resources. Summary of the invention

[0004] In view of this, the purpose of this application is to at least provide a distributed scheduled task management method and device, which uses the existing resources of the Kubernetes cluster for data storage, thereby reducing the software cost caused by introducing third-party storage middleware.

[0005] This application mainly includes the following aspects:

[0006] In a first aspect, an embodiment of the present application provides a distributed scheduled task management method, which is applied to a Kubernetes cluster, wherein the Kubernetes cluster includes multiple nodes, and any one of the multiple nodes performs the following steps: monitors whether a ready probe detects a change event for triggering node election; if a change event is detected, triggers node election; if any one of the nodes is elected as the current master node for executing scheduled task allocation, traverses the working status of other nodes in the multiple nodes except any one node, and determines multiple working nodes from the other nodes; traverses multiple scheduled tasks in a first configuration file in the Kubernetes cluster, binds the multiple scheduled tasks to a corresponding one of the multiple working nodes, and constructs a first mapping relationship between the multiple scheduled tasks and the multiple working nodes; stores the constructed first mapping relationship in the first configuration file, and allocates the multiple scheduled tasks to a corresponding one of the working nodes according to the first mapping relationship, so that the working node executes the allocated scheduled tasks.

[0007] In a possible implementation, the step of monitoring whether the readiness probe detects a change event for triggering node election includes: detecting whether a second configuration file exists in the Kubernetes cluster, the second configuration file being used to store basic information of the master node of the Kubernetes cluster; if the second configuration file exists in the Kubernetes cluster, determining whether the original master node indicated by the second configuration file is in a valid state; if it is determined that the original master node is in a valid state, no change event is detected; if the second configuration file does not exist in the Kubernetes cluster, or it is determined that the original master node is in an invalid state, a change event is detected.

[0008] In a possible implementation, the step of triggering node election includes: detecting the working status of any node; if the working status of any node is in a ready state, calling a create command; if the create command call is successful, marking any node as a master node through the create command, and updating the second configuration file in the kubernetes cluster with the basic information of any node; if the working status of any node is not in a ready state, or the create command call is unsuccessful, marking any node as an election failure.

[0009] In a possible implementation, the step of traversing the working status of other nodes except any one node among multiple nodes and determining multiple working nodes from other nodes includes: using ready probes to traverse and monitor the working status of other nodes; and taking the nodes in the ready state among other nodes as working nodes.

[0010] In a possible implementation, the management method also includes: if any node is marked as an election failure, the target node among the other nodes is determined as the master node; when the working state of any node is in a ready state, any node is determined as a working node and receives the first target scheduled task corresponding to multiple scheduled tasks from the master node.

[0011] In a possible implementation, the first configuration file constructed by the master node also includes multiple scheduled task trigger times corresponding to multiple scheduled tasks, wherein the step of executing the first target scheduled task also includes: detecting whether the current time reaches the scheduled trigger time indicated by the first target scheduled task; if the current time reaches the scheduled trigger time, obtaining the first mapping relationship stored from the first configuration file; determining the second target scheduled task to be executed at the current time from the first mapping relationship; determining whether the first target scheduled task is consistent with the second target scheduled task; if the two are consistent, executing the first target scheduled task.

[0012] In one possible implementation, the distributed scheduled task management method also includes: after any node is elected as the current master node for executing the scheduled task allocation, using the ready probe to periodically poll and detect the status of all working nodes; if it is detected that there are working nodes that are not in the ready state, the working nodes that are not in the ready state are determined as faulty nodes, and the scheduled tasks corresponding to the faulty nodes are triggered to be reallocated.

[0013] In one possible implementation, a scheduled task list is stored in a first configuration file, and the scheduled task list includes multiple scheduled tasks, wherein the distributed scheduled task management method also includes: after any node is elected as the current master node for executing scheduled task allocation, regularly detecting the scheduled task list in the first configuration file; when there are new and / or deleted scheduled tasks in the scheduled task list, triggering reallocation of multiple scheduled tasks in the scheduled task list.

[0014] In a second aspect, an embodiment of the present application further provides a distributed scheduled task management device, which is applied to a Kubernetes cluster, and the Kubernetes cluster includes multiple nodes, and any one of the multiple nodes includes: a monitoring module, which is used to monitor whether the ready probe detects a change event for triggering node election; an election module, which is used to trigger node election if a change event is detected; a determination module, which is used to traverse the working status of other nodes except any one node among the multiple nodes if any one node is elected as the current master node for executing scheduled task allocation, and determine multiple working nodes from the other nodes; a construction module block, which is used to traverse multiple scheduled tasks in a first configuration file in the Kubernetes cluster, bind the multiple scheduled tasks to a corresponding one of the multiple working nodes, and construct a first mapping relationship between the multiple scheduled tasks and the multiple working nodes; an allocation module, which is used to store the constructed first mapping relationship in the first configuration file, and allocate the multiple scheduled tasks to a corresponding one of the working nodes according to the first mapping relationship, so that the working node executes the allocated scheduled tasks.

[0015] In a second aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned first aspect or any possible implementation manner of the first aspect are executed.

[0016] The management method and device of distributed timed tasks provided by the embodiment of the present application are applied to a kubernetes cluster, wherein the kubernetes cluster includes multiple nodes, and any one of the multiple nodes performs the following steps: monitoring whether the ready probe detects a change event for triggering node election; if a change event is detected, triggering node election; if any one of the nodes is elected as the current master node for executing the timed task assignment, traversing the working status of other nodes except any one of the multiple nodes, and determining multiple working nodes from the other nodes; traversing multiple timed tasks in the first configuration file in the kubernetes cluster, binding the multiple timed tasks to corresponding ones of the multiple working nodes respectively, and constructing a first mapping relationship between the multiple timed tasks and the multiple working nodes; storing the constructed first mapping relationship in the first configuration file, and assigning the multiple timed tasks to a corresponding working node according to the first mapping relationship, so that the assigned timed tasks are executed by the working node. By using existing resources for data storage, the software cost brought by the introduction of third-party storage middleware is reduced.

[0017] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0019] Figure 1 The following is a flow chart of a distributed timed task management method provided by an embodiment of the present application. Figure 1 ;

[0020] Figure 2 A flowchart showing the steps of triggering node election provided in an embodiment of the present application is shown;

[0021] Figure 3 The following is a flow chart of a distributed timed task management method provided by an embodiment of the present application. Figure 2 ;

[0022] Figure 4 A schematic diagram of the structure of a distributed scheduled task management device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present application, can add one or more other operations to the flowchart, or remove one or more operations from the flowchart.

[0024] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0025] See also Figure 1 , Figure 1 A process of managing a distributed scheduled task provided by an embodiment of the present application Figure 1 .like Figure 1 As shown, the distributed scheduled task management method provided in the embodiment of the present application is applied to a kubernetes cluster, and the kubernetes cluster includes multiple nodes. Specifically, any one of the multiple nodes performs the following steps:

[0026] S100 , monitoring whether the readiness probe detects a change event for triggering node election.

[0027] In the specific implementation, each node in the Kubernetes cluster is the smallest computing hardware unit in Kubernetes. It is the representation of a single machine in the Kubernetes cluster. In most cases, the node is likely to be a physical machine in a data center, or a virtual machine hosted on a cloud provider such as Google Cloud Platform. There is no specific limitation here. Each node in the Kubernetes cluster has the ability to use CPU and / or RAM resources, which means that each node in the Kubernetes cluster has the ability to process scheduled tasks.

[0028] In a preferred embodiment, the kubernetes cluster is provided with a readiness probe to check whether each node is ready to provide services for requests. In the present application, it is also possible to check whether each node is ready to provide services for each scheduled task. Therefore, the status of the node can be determined by monitoring the feedback results of the readiness probe.

[0029] In one example, the step of monitoring whether the readiness probe detects a change event for triggering a node election may include:

[0030] Check whether the second configuration file exists in the Kubernetes cluster.

[0031] In a preferred embodiment, the second configuration file is used to store basic information of the master node of the kubernetes cluster. Specifically, in the kubernetes cluster, if the master node already exists, a second configuration file is created in the kubernetes cluster, and the basic information of the master node is stored in the created second configuration file. If the master node does not exist, the second configuration file is not created in the kubernetes cluster. Based on this, it can be determined whether the current kubernetes cluster is a new cluster by detecting whether the second configuration file exists.

[0032] If the second configuration file exists in the kubernetes cluster, it is determined whether the original node indicated by the second configuration file is in a valid state.

[0033] In a preferred embodiment, if the second configuration file exists in the Kubernetes cluster, it means that the current Kubernetes cluster is not a new cluster. Since the master node has not been set up in the new Kubernetes cluster, there is no second configuration file for storing the basic information of the master node. The existence of the second configuration file means that the master node has been created. Therefore, the Kubernetes cluster with the second configuration file is not a new cluster.

[0034] In this case, it is necessary to determine whether the original master node indicated by the second configuration file is in effect. Specifically, the original master node may no longer be in effect due to failure or manual offline. Therefore, the survival probe in the kubernetes cluster can be used to determine whether the original master node indicated by the second configuration file is in effect. The survival probe can obtain whether the node is in effect. Any node in the cluster can use the survival probe and obtain the effectiveness status of the original node through the api-server interface in the kubernetes cluster.

[0035] If it is determined that the original master node is in a valid state, no change event is detected.

[0036] In a preferred embodiment, if any node monitors the original master node in an effective state through a survival probe, it means that the original master node is in normal operation at this time, that is, no change event is detected. At this time, the original master node continues to exist and performs scheduled task allocation and management work.

[0037] If the second configuration file does not exist in the Kubernetes cluster, or it is determined that the original node is in a failed state, a change event is detected.

[0038] In a preferred embodiment, if the second configuration file cannot be fetched in the Kubernetes cluster, it means that the Kubernetes cluster is a new cluster and a node needs to be elected as the master node to ensure the normal operation of the cluster.

[0039] In another preferred embodiment, if any node detects that the original master node is in a failed state through a survival probe, it means that the original master node is in an abnormal operating state at this time, and the original master node needs to be removed and a new master node needs to be re-elected to replace it to ensure the normal operation of the cluster.

[0040] S200: If a change event is detected, a node election is triggered.

[0041] In a preferred embodiment, when any node in the cluster detects a change event, the current kubernetes cluster needs to elect a node as the master node, which means that a node election will be triggered, that is, a master node needs to be determined from multiple nodes in the cluster.

[0042] See also Figure 2 , Figure 2 Flow chart of the steps for triggering node election provided in the embodiment of the present application. Figure 2 As shown, the steps to trigger node election include:

[0043] S201. Detect the working status of any node.

[0044] In a preferred embodiment, any node among multiple nodes in the kubernetes cluster monitors its own working status by calling the readiness probe, that is, uses the readiness probe to monitor whether it is ready to provide services for requests.

[0045] S202: If the working status of any node is in the ready state, call the create command.

[0046] In a preferred embodiment, in a new kubernetes cluster, if any node detects that it is in a ready state using a readiness probe, a create command is called. By calling the create command, any node becomes a candidate master node. Specifically, if multiple nodes are in a ready state at the same time, each node in a ready state will call a create command to make itself one of the multiple candidate master nodes.

[0047] In a specific embodiment, in a kubernetes cluster where an original master node already exists, if any node detects that it is in a ready state using a ready probe, it is necessary to call a replacement command. By calling the replacement command, any node can be made a candidate master node, that is, any node can have the ability to replace the original node as the new master node. For example, in a kubernetes cluster, the replacement command can be a patch command plus the original version number of the second configuration file to perform an optimistic lock update operation. The version number is added to avoid the problem of losing basic information of any node that is successfully elected.

[0048] S203. If the creation command is successfully called, any node is marked as a master node through the creation command, and the second configuration file in the kubernetes cluster is updated with the basic information of any node.

[0049] In a preferred embodiment, the creation command call is successful, which means that any node is successfully elected and has been successfully marked as the master node, that is, its basic information is successfully updated to the second configuration file for storing the master node information. In the kubernetes cluster, there is ultimately only one master node for allocating scheduled tasks. Therefore, when any node is successfully elected, the other nodes among the multiple nodes except the any node are marked as election failures, and when any node is successfully elected, an election success event is triggered. At this time, the node election is stopped until the next change event is detected, and the node election is re-triggered.

[0050] In another specific embodiment, the replacement command call is successful, which means that any one node is successfully elected and has been successfully marked as the master node, that is, its own basic information is successfully updated to the second configuration file for storing the master node information, and the basic information of the original master node is successfully deleted. At this time, any one node is successfully elected, and the other nodes among the multiple nodes except the any one node are marked as election failures. After any one node is successfully elected, an election success event will be triggered. At this time, the node election is stopped until the next change event is detected, and the node election will be re-triggered.

[0051] S204: If the working status of any node is not in the ready state, or the creation command call is unsuccessful, any node is marked as election failure.

[0052] In a preferred embodiment, if any node in the kubernetes cluster uses a ready probe to detect that it has not completed the preparations to provide services for requests, that is, it is considered not to be in a ready state, the arbitrary node will be directly marked as having failed election and will lose the qualification to become the master node. In another case, the creation command is not called successfully, that is, the working status of any node is in a ready state, but the basic information of its own node is not successfully written into the second configuration file. At this time, the arbitrary node will also be directly marked as having failed election, and the node other than any node among the multiple nodes that successfully writes the basic node information into the second configuration file will become the master node.

[0053] In addition, in a cluster where an original node that has expired exists, if the replacement command is not called successfully, that is, the working status of any node is in the ready state, but the basic information of its own node is not successfully written into the second configuration file and / or the version number of the second configuration file is not successfully updated, and / or, the basic information of the original node is not completely deleted, that is, the working status of any node is in the ready state, but the basic information of its own node is not successfully written into the second configuration file.

[0054] return Figure 1 , S300, if any node is elected as the current master node for executing the scheduled task allocation, then traverse the working status of other nodes except any node among the multiple nodes, and determine multiple working nodes from the other nodes.

[0055] In a preferred embodiment, multiple working nodes are determined from other nodes in the following manner:

[0056] Use the ready probe to traverse and monitor the working status of other nodes, and use the nodes in the ready state as working nodes.

[0057] Specifically, after any node is elected as the current master node for executing scheduled task allocation, the working status of other nodes except itself is monitored through the ready probe, and multiple scheduled tasks in the first configuration file are randomly allocated to the working nodes in the ready state.

[0058] S400, traverse multiple scheduled tasks in the first configuration file in the kubernetes cluster, bind the multiple scheduled tasks to corresponding ones of the multiple working nodes respectively, and build a first mapping relationship between the multiple scheduled tasks and the multiple working nodes.

[0059] In a specific embodiment, after any node is elected as the current master node for executing scheduled task allocation, it will traverse multiple scheduled tasks in the first configuration file, randomly allocate the multiple scheduled tasks to the corresponding multiple working nodes, and establish a first mapping relationship between the multiple scheduled tasks and the multiple working nodes in the first configuration file.

[0060] S500: Store the constructed first mapping relationship in a first configuration file, and assign multiple scheduled tasks to a corresponding working node according to the first mapping relationship, so that the working node executes the assigned scheduled tasks.

[0061] In a specific implementation, the current master node stores the first mapping relationship between multiple scheduled tasks and multiple working nodes in a first configuration file, so that the working node assigned to the task can determine the corresponding scheduled task to be executed through the first mapping relationship in the first configuration file.

[0062] See also Figure 3 , Figure 3 A process of managing a distributed scheduled task provided by the embodiment of the present application Figure 2 .like Figure 3 As shown, if any node is marked as election failure, the management method of distributed scheduled tasks also includes:

[0063] 600. The target node among other nodes is determined as the master node.

[0064] In a preferred embodiment, if any node is marked as election failure, it means that there is a node among other nodes that is successfully elected as the master node, and the node is determined as the target node.

[0065] S700: When the working state of any node is in the ready state, any node is determined as a working node, and receives a first target scheduled task corresponding to a plurality of scheduled tasks from a master node.

[0066] In a specific embodiment, if any node is marked as having failed election, it is necessary to use the ready probe again to obtain its own working status. If any node is still in the ready state at this time, then any node is determined as a working node and can receive the corresponding scheduled task from the master node at any time. The scheduled task received by any node as a working node is determined as the first target scheduled task.

[0067] S800: Execute the first target scheduled task.

[0068] In a preferred embodiment, after receiving the first target scheduled task when any node serves as a working node, it will execute the first target scheduled task according to the timing trigger time indicated by the first target scheduled task.

[0069] Specifically, the steps of any node acting as a working node to execute the first target scheduled task include:

[0070] Check whether the current time reaches the timing trigger time indicated by the first target timing task.

[0071] In a preferred embodiment, the first configuration file constructed by the master node also includes multiple scheduled task trigger times corresponding to multiple scheduled tasks. Any working node assigned to a scheduled task needs to always match the current event with the scheduled trigger time indicated by the first target scheduled task corresponding to itself.

[0072] If the current time reaches the timing trigger time, the stored first mapping relationship is obtained from the first configuration file.

[0073] In a preferred embodiment, if the current time reaches the timing trigger time indicated by the first target timing task corresponding to any working node, the first configuration file is retrieved, and the first mapping relationship pre-stored in the first configuration file is obtained.

[0074] A second target scheduled task to be executed at the current time is determined from the first mapping relationship.

[0075] In a preferred embodiment, after obtaining the first mapping relationship, the scheduled task that needs to be executed corresponding to any working node corresponding to the current time is determined through the first mapping relationship, and the scheduled task is determined as the second target scheduled task that any working node really needs to execute.

[0076] Determine whether the first target scheduled task is consistent with the second target scheduled task.

[0077] Specifically, if the two are consistent, the first target timed task is executed according to the specific content of the first target timed task. If the first target timed task is inconsistent with the second target timed task, other working nodes corresponding to the second target timed task are determined according to the first mapping relationship, and the second target timed task is executed by the working node.

[0078] The management method of distributed scheduled tasks also includes:

[0079] After any node is elected as the current master node for executing scheduled task allocation, the readiness probe is used to periodically poll and detect the status of all working nodes.

[0080] In a preferred embodiment, after any node is elected as the current master node for executing scheduled task allocation and multiple scheduled tasks are allocated to corresponding working nodes, it is also necessary to periodically monitor the working status of the working nodes bound to the scheduled tasks in the first configuration file.

[0081] If it is detected that there is a working node that is not in the ready state, the working node that is not in the ready state is determined as a faulty node, and the scheduled task corresponding to the faulty node is triggered to be reallocated.

[0082] In a preferred embodiment, if any node that serves as the current master node detects that the working node that has been assigned to the scheduled task is not in a ready state, it means that the working node is a faulty node and may be in an offline state or an invalid state. At this time, it will trigger any node that serves as the current master node to reallocate the scheduled task in the first configuration file and reallocate the scheduled task to a valid node that is in a ready state.

[0083] In a preferred embodiment, the distributed scheduled task management method further includes:

[0084] After any node is elected as the current master node for executing scheduled task allocation, the scheduled task list in the first configuration file is regularly detected.

[0085] In a preferred embodiment, a scheduled task list is stored in the first configuration file, the scheduled task list includes a plurality of scheduled tasks, and each scheduled task is executed by a different working node according to the first mapping relationship.

[0086] When new and / or deleted scheduled tasks are added in the scheduled task list, a reallocation of multiple scheduled tasks in the scheduled task list is triggered.

[0087] In a preferred embodiment, a user can add and / or delete scheduled tasks in a kubernetes cluster. When any node as a master node detects that there are new and / or deleted scheduled tasks in the first configuration file, at this time, any node as a master node will reallocate multiple scheduled tasks in the scheduled task list.

[0088] The present application also provides a distributed scheduled task management device, which is applied to a kubernetes cluster. Figure 4 As shown, Figure 4 A schematic diagram of a distributed scheduled task management device provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the kubernetes cluster includes multiple nodes, and any one of the multiple nodes includes:

[0089] The monitoring module 910 is used to monitor whether the readiness probe detects a change event for triggering node election.

[0090] The election module 920 is used to trigger a node election if a change event is detected.

[0091] The determination module 930 is used to traverse the working status of other nodes except any one node among the multiple nodes and determine multiple working nodes from the other nodes if any one node is elected as the current master node for executing the scheduled task allocation.

[0092] The construction module 940 is used to traverse multiple scheduled tasks in the first configuration file in the kubernetes cluster, bind the multiple scheduled tasks to corresponding ones of the multiple working nodes respectively, and build a first mapping relationship between the multiple scheduled tasks and the multiple working nodes.

[0093] The allocation module 950 is used to store the constructed first mapping relationship in the first configuration file, and allocate multiple scheduled tasks to a corresponding working node according to the first mapping relationship, so that the working node executes the allocated scheduled tasks.

[0094] Optionally, the monitoring module 910 is also used to: detect whether there is a second configuration file in the Kubernetes cluster, the second configuration file is used to store basic information of the master node of the Kubernetes cluster; if the second configuration file exists in the Kubernetes cluster, determine whether the master node indicated by the second configuration file is in an effective state; if it is determined that the master node indicated by the second configuration file is in an effective state, no change event is detected; if the second configuration file does not exist in the Kubernetes cluster, or it is determined that the master node indicated by the second configuration file is in an invalid state, a change event is detected.

[0095] Optionally, the election module 920 is further configured to:

[0096] Detect the working status of any node; if the working status of any node is in the ready state, call the create command; if the create command call is successful, mark any node as the master node through the create command, and update the second configuration file in the kubernetes cluster with the basic information of any node; if the working status of any node is not in the ready state, or the create command call is unsuccessful, mark any node as failed in the election.

[0097] Optionally, the building block 940 is further configured to:

[0098] Use the ready probe to traverse and monitor the working status of other nodes; determine the nodes in the ready state among other nodes as working nodes.

[0099] Optionally, the device further comprises:

[0100] An execution module (not shown in the figure) is used to determine the target node among other nodes as the main node if any node is marked as having failed election; when the working state of any node is in the ready state, any node is determined as a working node and receives the first target scheduled task corresponding to multiple scheduled tasks from the main node; and executes the first target scheduled task.

[0101] Optionally, the execution module is further configured to:

[0102] Detect whether the current time reaches the timing trigger time indicated by the first target timing task; if the current time reaches the timing trigger time, obtain the stored first mapping relationship from the first configuration file; determine the second target timing task to be executed at the current time from the first mapping relationship; determine whether the first target timing task is consistent with the second target timing task; if the two are consistent, execute the first target timing task; wherein, the first configuration file constructed by the master node also includes multiple timing task trigger times corresponding to multiple timing tasks.

[0103] Optionally, the device further comprises a reallocation module (not shown in the figure), configured to:

[0104] After any node is elected as the current master node for executing scheduled task allocation, the ready probe is used to periodically poll and detect the status of all working nodes; if a working node that is not in the ready state is detected, the working node that is not in the ready state is determined as a faulty node, and the scheduled task corresponding to the faulty node is triggered to be reallocated.

[0105] Optionally, the reallocation module is also used to:

[0106] After any node is elected as the current master node for executing scheduled task allocation, the scheduled task list in the first configuration file is regularly checked; when there are new and / or deleted scheduled tasks in the scheduled task list, the multiple scheduled tasks in the scheduled task list are triggered to be reallocated; wherein the first configuration file stores the scheduled task list, and the scheduled task list includes multiple scheduled tasks.

[0107] Based on the same application concept, an embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the distributed scheduled task management method provided in the above embodiment are executed.

[0108] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0109] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0110] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0111] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc., various media that can store program codes.

[0112] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A distributed timed task management method, the distributed timed task management method is applied to a kubernetes cluster, the kubernetes cluster includes multiple nodes, characterized in that: Any one of the multiple nodes performs the following steps: Monitor whether the readiness probe detects a change event that triggers node election; If a change event is detected, a node election is triggered; If any one of the nodes is elected as the current master node for executing the scheduled task allocation, traverse the working states of other nodes among the multiple nodes except the any one of the nodes, and determine a plurality of working nodes from the other nodes; Traversing multiple scheduled tasks in the first configuration file in the kubernetes cluster, binding the multiple scheduled tasks to corresponding ones of the multiple working nodes respectively, and building a first mapping relationship between the multiple scheduled tasks and the multiple working nodes; The constructed first mapping relationship is stored in the first configuration file, and the plurality of scheduled tasks are assigned to a corresponding working node according to the first mapping relationship, so that the working node executes the assigned scheduled task; The step of monitoring whether the readiness probe detects a change event for triggering node election includes: Detect whether there is a second configuration file in the kubernetes cluster, where the second configuration file is used to store basic information of the master node of the kubernetes cluster; If the second configuration file exists in the kubernetes cluster, executing: determining whether the original master node indicated by the second configuration file is in a valid state through a survival probe, if it is determined that the original master node is in a valid state, not triggering a node election, if it is determined that the original master node is in a failed state, triggering a node election; If the second configuration file does not exist in the Kubernetes cluster, it is determined that there is no master node in the Kubernetes cluster, and a node election is triggered; Any node in the kubernetes cluster uses a survival probe to call the api-server interface in the kubernetes cluster to obtain the validity status of the original node; The steps to trigger node election include: Detecting the working status of any one of the nodes; If the working state of any of the nodes is in the ready state: If the second configuration file does not exist in the kubernetes cluster, call the creation command to create the master node and generate the second configuration file; If the second configuration file exists in the kubernetes cluster, call the replacement command to re-elect the master node and use the basic information corresponding to the re-elected master node to replace the basic information corresponding to the original master node indicated by the second configuration file; The replacement command is a patch command plus the original version number of the second configuration file to perform an optimistic lock update operation.

2. The distributed scheduled task management method according to claim 1, characterized in that: The steps to trigger node election also include: If the working state of any one of the nodes is not in the ready state, or the creation command call is unsuccessful, the any one of the nodes is marked as election failure.

3. The distributed scheduled task management method according to claim 1, characterized in that: The step of traversing the working states of other nodes among the multiple nodes except the any one node and determining a plurality of working nodes from the other nodes comprises: Use the readiness probe to traverse and monitor the working status of the other nodes; Among the other nodes, the nodes in the ready state are used as working nodes.

4. The distributed scheduled task management method according to claim 3 is characterized in that: The management method also includes: If any of the nodes is marked as having failed the election, the target node among the other nodes is determined to be the master node; When the working state of any one of the nodes is in the ready state, the any one of the nodes is determined as a working node, and receives a first target scheduled task corresponding to the multiple scheduled tasks from the master node.

5. The distributed timed task management method according to claim 4, characterized in that: The first configuration file constructed by the master node also includes multiple scheduled task triggering times corresponding to the multiple scheduled tasks. The step of executing the first target timing task also includes: Detect whether the current time reaches the timing trigger time indicated by the first target timing task; If the current time reaches the timing trigger time, the first mapping relationship stored is obtained from the first configuration file; Determine a second target scheduled task to be executed at the current time from the first mapping relationship; Determine whether the first target timed task is consistent with the second target timed task; If the two are consistent, the first target timing task is executed.

6. The distributed scheduled task management method according to claim 1, characterized in that: The distributed scheduled task management method also includes: After any one of the nodes is elected as the current master node for executing the scheduled task allocation, the ready probe is used to periodically poll and detect the status of all working nodes; If it is detected that there is a working node that is not in the ready state, the working node that is not in the ready state is determined as a faulty node, and reallocation of the scheduled tasks corresponding to the faulty node is triggered.

7. The distributed scheduled task management method according to claim 1, characterized in that: The first configuration file stores a scheduled task list, which includes a plurality of scheduled tasks. The distributed scheduled task management method further includes: After any one of the nodes is elected as the current master node for executing scheduled task allocation, regularly detecting the scheduled task list in the first configuration file; When there is a new and / or deleted scheduled task in the scheduled task list, a reallocation of multiple scheduled tasks in the scheduled task list is triggered.

8. A distributed scheduled task management device, the distributed scheduled task management device is applied to a kubernetes cluster, the kubernetes cluster includes multiple nodes, characterized in that: Any one of the multiple nodes includes: The monitoring module is used to monitor whether the readiness probe detects a change event used to trigger node election; The election module is used to trigger node election if a change event is detected; A determination module, configured to, if any one of the nodes is elected as the current master node for executing the scheduled task allocation, traverse the working states of other nodes among the multiple nodes except the any one of the nodes, and determine a plurality of working nodes from the other nodes; A building module block is used to traverse multiple scheduled tasks in a first configuration file in the kubernetes cluster, bind the multiple scheduled tasks to a corresponding one of the multiple working nodes respectively, and build a first mapping relationship between the multiple scheduled tasks and the multiple working nodes; An allocation module, used for storing the constructed first mapping relationship in the first configuration file, and allocating the plurality of scheduled tasks to a corresponding working node according to the first mapping relationship, so that the working node executes the allocated scheduled tasks; Among them, the monitoring module is also used for: Detect whether there is a second configuration file in the kubernetes cluster, where the second configuration file is used to store basic information of the master node of the kubernetes cluster; If the second configuration file exists in the kubernetes cluster, executing: determining whether the original master node indicated by the second configuration file is in a valid state through a survival probe, if it is determined that the original master node is in a valid state, not triggering a node election, if it is determined that the original master node is in a failed state, triggering a node election; If the second configuration file does not exist in the Kubernetes cluster, it is determined that there is no master node in the Kubernetes cluster, and a node election is triggered; Any node in the kubernetes cluster uses a survival probe to call the api-server interface in the kubernetes cluster to obtain the validity status of the original node; The election module is also used to: Detecting the working status of any one of the nodes; If the working state of any of the nodes is in the ready state: If the second configuration file does not exist in the kubernetes cluster, call the creation command to create the master node and generate the second configuration file; If the second configuration file exists in the kubernetes cluster, call the replacement command to re-elect the master node and use the basic information corresponding to the re-elected master node to replace the basic information corresponding to the original master node indicated by the second configuration file; The replacement command is a patch command plus the original version number of the second configuration file to perform an optimistic lock update operation.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the distributed scheduled task management method according to any one of claims 1 to 7 are executed.

Images