Method and apparatus for determining task status

Abstract

The application discloses a kind of method and device for determining task state, it is related to computer technical field.The specific embodiment of the method includes: obtaining event occurring in container set, determine the current state of the container set from the event;When the current state is running state, and the pre-stored recent state of the task is start related state, the current state of the task is determined as running state;And / or, obtain event occurring in deployment unit, determine the number of unavailable container set controlled by the deployment unit from the event;When the number is equal to the first threshold value of pre-set, and the pre-stored recent state of the task is start failure state except start related state, the current state of the task is determined as start failure state.The embodiment can accurately judge task current state by obtaining container set event and / or deployment unit event.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, to a method and device for determining task state. BACKGROUND

[0002] Kubernetes is an application for managing, orchestrating and scheduling containers in multiple hosts. In the prior art, in order to determine the state of a task in Kubernetes, Fabric8 (an application program interface) provided by Kubernetes can be used to interact with API Server (a key service process that provides a unique entry for resource operations and provides mechanisms such as authentication, authorization, access control, application program interface registration and discovery) to query the state of a Pod (the smallest management element in Kubernetes, and a Pod can contain at least one container), and then determine the state of the task according to the state of the Pod.

[0003] In the process of implementing the present application, the inventors have found that the prior art has at least the following problems:

[0004] 1. The state of a Pod cannot directly reflect the state of a task, and it is not reasonable to completely rely on a Pod to determine the state of a task in the prior art.

[0005] 2. The prior art needs to frequently interact with API Server using Fabric8, which puts pressure on API Server. In addition, the prior art cannot query historical task information executed in Kubernetes. SUMMARY

[0006] Therefore, embodiments of the present application provide a method and device for determining task state, which can accurately determine the current state of a task by obtaining container set events and / or deployment unit events.

[0007] To achieve the above object, according to one aspect of the present application, a method for determining task state is provided. The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit. The task state includes a startup-related state and a running state, and the startup-related state includes a startup failure state.

[0008] The method for determining the task state of the embodiment comprises: obtaining an event occurring in the container set, determining a current state of the container set from the event; when the current state is a running state and a pre-stored latest state of the task is a start-related state, determining the current state of the task as a running state; and / or obtaining an event occurring in the deployment unit, determining a number of unavailable container sets controlled by the deployment unit from the event; when the number is equal to a pre-set first threshold and the pre-stored latest state of the task is a start-related state except a start failure state, determining the current state of the task as a start failure state.

[0009] Optionally, the task state further comprises a stop state; and the method further comprises: obtaining an event occurring in the deployment unit, determining a number of available container sets controlled by the deployment unit from the event; when the number is equal to a pre-set second threshold and the pre-stored latest state of the task is a running state, determining the current state of the task as a stop state.

[0010] Optionally, the start-related state further comprises a start start state and a starting state, and the latest state of the task is stored in a cache unit; and the method further comprises: after determining the current state of the task, storing the current state in the cache unit; before performing the step of determining the number of available container sets controlled by the deployment unit from the event: if it is determined that the event does not carry a stop event identifier, the step is not performed; after obtaining the event occurring in the deployment unit: determining an identifier of the task from the event, and when it is determined that the identifier is not stored in the cache unit, determining the current state of the task as a start start state; after obtaining the event occurring in the container set: if the latest state of the task stored in the cache unit is a start start state, determining the current state of the task as a starting state.

[0011] Optionally, the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, the cache unit stores historical task information, the container is a Docker container, the container set is a driver container set Driver Pod used for scheduling an executor container set Executor Pod, and the deployment unit is Deployment, the state of the Driver Pod further includes at least one of the following: a to-be-processed state, a failed state, and a deleted state; the event occurring in the container set is obtained by: using a listening unit to listen to the Driver Pod, and receiving the event sent by the listening unit when the event occurs in the Driver Pod; the event occurring in the deployment unit is obtained by: using a listening unit to listen to the Deployment, and receiving the event sent by the listening unit when the event occurs in the Deployment; and the method further includes: after receiving the event occurring in the Executor Pod, obtaining Spark user interface address information started by the Driver Pod from a label of the Executor Pod.

[0012] To achieve the above object, according to another aspect of the present application, a method for determining a task state is provided. The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit. The task state includes a start-related state, a running state, and a stop state.

[0013] The method for determining a task state includes: obtaining an event occurring in the container set, determining a current state of the container set from the event; when the current state is the running state and a latest state of the task stored in advance is the start-related state, determining the current state of the task as the running state; and / or obtaining an event occurring in the deployment unit, determining a number of available container sets controlled by the deployment unit from the event; when the number is equal to a preset second threshold and the latest state of the task stored in advance is the running state, determining the current state of the task as the stop state.

[0014] Optionally, the start-related state further comprises a start-starting state and a starting state, and the latest state of the task is stored in the cache unit; and the method further comprises: after determining the current state of the task, storing the current state in the cache unit; before performing the step of determining the number of available containers set controlled by the deployment unit from the event, if it is determined that the event does not carry a stop event identifier, the step is not performed; after obtaining the event occurring in the deployment unit, determining the identifier of the task from the event, and determining the current state of the task as the start-starting state when it is determined that the identifier is not stored in the cache unit; after obtaining the event occurring in the container set, if the latest state of the task stored in the cache unit is the start-starting state, the current state of the task is determined as the starting state.

[0015] Optionally, the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, the cache unit stores historical task information, the container is a Docker container, the container set is a driver container set Driver Pod for scheduling an executor container set Executor Pod, the deployment unit is Deployment, and the state of the Driver Pod further comprises at least one of the following: a to-be-processed state, a failed state and a deleted state; obtaining the event occurring in the container set comprises: using a listening unit to listen to the Driver Pod, and receiving the event sent by the listening unit when the event occurs in the Driver Pod; obtaining the event occurring in the deployment unit comprises: using a listening unit to listen to the Deployment, and receiving the event sent by the listening unit when the event occurs in the Deployment; and the method further comprises: after receiving the event occurring in the Executor Pod, obtaining the address information of a Spark user interface started by the Driver Pod from the label of the Executor Pod.

[0016] To achieve the above object, according to another aspect of the present application, a device for determining a task state is provided. The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit. The task state comprises a start-related state and a running state, and the start-related state comprises a start-failed state.

[0017] The device for determining a task state according to an embodiment of the present application can include: a first state determining unit configured to acquire an event occurring in the container set, determine a current state of the container set from the event, and determine the current state of the task as a running state when the current state is a running state and a last state of the task stored in advance is a start-related state; and / or a second state determining unit configured to acquire an event occurring in the deployment unit, determine a number of unavailable container sets controlled by the deployment unit from the event, and determine the current state of the task as a start-failure state when the number is equal to a preset first threshold and the last state of the task stored in advance is a start-related state other than a start-failure state.

[0018] To achieve the above object, according to another aspect of the present application, a device for determining a task state is provided. The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit. The task state includes a start-related state, a running state and a stop state.

[0019] The device for determining a task state according to an embodiment of the present application can include: a first state determining unit configured to acquire an event occurring in the container set, determine a current state of the container set from the event, and determine the current state of the task as a running state when the current state is a running state and a last state of the task stored in advance is a start-related state; and / or a second state determining unit configured to acquire an event occurring in the deployment unit, determine a number of unavailable container sets controlled by the deployment unit from the event, and determine the current state of the task as a start-failure state when the number is equal to a preset first threshold and the last state of the task stored in advance is a start-related state other than a start-failure state.

[0020] To achieve the above object, according to another aspect of the present application, an electronic device is provided.

[0021] The electronic device according to the present application includes one or more processors, and a storage device configured to store one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method for determining a task state provided by the present application.

[0022] To achieve the above object, according to another aspect of the present application, a computer readable storage medium is provided.

[0023] The computer readable storage medium according to the present application has a computer program stored thereon, when the program is executed by a processor, the method for determining a task state provided by the present application is implemented.

[0024] According to the technical scheme of the present application, the above-mentioned one embodiment of the present application has the following advantages or beneficial effects:

[0025] Firstly, in the embodiment of the present application, the container set event and the deployment unit event related to the task can be obtained, and then the current state of the container set is extracted from the container set event, the current parameter state (such as the number of available container sets, the number of unavailable container sets) of the deployment unit is extracted from the deployment unit event, and the current state of the container set and the current parameter state of the deployment unit are combined with the pre-stored recent state of the task to determine the current accurate state of the task. In practical application, the current state of the container set and the recent state of the task are determined according to the preset strategy to determine whether the task is in a running state, and the current parameter state of the deployment unit and the recent state of the task are determined according to the preset strategy to determine whether the task is in a start failure state or a stop state.

[0026] Secondly, the present application can use the listening mechanism (Watch mechanism) of Kubernetes to obtain the container set event and the deployment unit event. Specifically, two listening units (Watchers) are started to listen to the container set and the deployment unit in parallel, and when an event occurs in the container set or the deployment unit, it is automatically captured and pushed, thereby reducing the pressure on the API Server. In addition, the present application can use a cache unit (such as Redis) to store the recent state of the current task and historical task information, and when the historical task information needs to be queried, the cache unit interface can be used to directly query.

[0027] The further effects of the above-mentioned non-conventional optional mode will be described in the following combined with the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0028] The accompanying drawings are used to better understand the present application and do not constitute an improper limitation on the present application. Among them:

[0029] Figure 1 is the main step diagram of the method for determining the task state in the first embodiment of the present application;

[0030] Figure 2 is the execution flow diagram of the method for determining the task state in the first embodiment of the present application;

[0031] Figure 3 is the main step diagram of the method for determining the task state in the second embodiment of the present application;

[0032] Figure 4 is the main step diagram of the method for determining the task state in the second embodiment of the present application; Figure 1 is the component part diagram of the device for determining the task state corresponding to the method shown in

[0033] Figure 5 is the component part diagram of the device for determining the task state corresponding to the method shown in Figure 3The method corresponds to a component of a device for determining a task state, as shown in the schematic diagram.

[0034] Figure 6 is an exemplary system architecture diagram to which embodiments of the present application can be applied;

[0035] Figure 7 is a schematic diagram of an electronic device structure for implementing the method for determining a task state in embodiments of the present application. DETAILED DESCRIPTION

[0036] Exemplary embodiments of the present application are described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to assist in understanding them. These should be considered in their context only. Thus, those of ordinary skill in the art will recognize the various changes and modifications of the embodiments described herein, without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and structures are omitted in the following description for clarity and conciseness.

[0037] In embodiments of the present application, a task executed in Kubernetes can be judged and tracked. Kubernetes is a lightweight, scalable open source platform for managing containerized applications and services, through which the automatic deployment and scaling of applications can be performed. In Kubernetes, containers that constitute an application are combined into a logical unit, which is a Pod (a container group), and the Pod is the most basic operating unit of Kubernetes, which encapsulates one or more closely related containers (such as Docker containers, Docker is an open source application container engine) inside. One or more labels can be attached to a Pod to mark relevant information, for example, a task label is used to mark the task performed by the Pod, and a role label is used to mark the function and role of the Pod, such as "app=wordcount" for the task label, where app represents the application and wordcount (word count) represents the task identifier (which can be the task name); "role=driver" for the role label, where role represents the role and driver represents the driver.

[0038] The state of a Pod can be in a pending state (Pending), a running state (Running), a success state (Succeeded), a failure state (Failed), an unknown state (Unknown), and a killed state (Killed), and the specific descriptions of the states are shown in the following table.

[0039]

[0040] Deployment is a way to deploy pods to the cluster, the main purpose of Deployment is to declare how many replicas of a pod should be running at the same time, when Deployment is added to the cluster, it will automatically create the required number of pods and monitor. If a pod disappears, Deployment will automatically recreate it. One or more labels can also be attached to Deployment to mark relevant information, such as attaching task labels to mark the tasks performed. Deployment can use one or more fields to describe the current state, such as available (available container set number), unavailable (unavailable container set number), the following shows the available field value and the unavailable field value of each state when Deployment controls a pod.

[0041] Deployment state available unavailable Start up 0 0 Start up failed 0 1 Running 1 0 Stop 0 0

[0042] In the prior art, the task execution state is generally determined by determining the pod state: when the pod is in the running state, the task is determined to be in the running state, when the pod is in the failed state, the task is determined to be in the startup failure state, and when the pod is in the deleted state, the task is determined to be in the stopped state. However, the above method is not accurate, because when the pod is in the failed or deleted state, Deployment can automatically recreate, and the execution of the task is not affected, so it is wrong to determine the task state as startup failure or stop state.

[0043] Based on the above considerations, the present application can comprehensively determine the task execution state by combining Pod and Deployment. In the task startup or stop phase, because Deployment can reflect the real working state of the system (Deployment start means task start, Deployment startup failure means task startup failure, and Deployment stop means task stop), the available and unavailable field data of Deployment can be used to determine whether the task has started, failed to start, or stopped in combination with the recent state of the task. In the task running phase, the pod state is strongly related to the task state, so the pod state can be used in combination with the recent state of the task to determine whether the task is running. In this way, the present application can realize the task state judgment from the complete life cycle of startup to stop.

[0044] In the embodiment of the present application, the task state has the following five kinds: start, startup, startup failure, running, and stop, which can be represented by different values of the phase field respectively, and the specific correspondence and description of each task state are shown in the following table.

[0045]

[0046] The starting state, the starting state and the starting failure state all belong to the starting related state. It should be noted that in the embodiment of the application, a cache unit (for example, Redis) can be used to store the state of the current task (i.e., the task that needs to be executed at present). After determining the current state of the current task, the current state can be updated to the cache unit. In the next task state judgment, the current state is the latest state of the current task. The latest state of the task stored in the cache unit can be represented by the phase value described above. In practical applications, in addition to storing the latest state of the current task, the cache unit also stores the task identifier (for example, the task name), the latest state of the Pod executing the task, the field data of the Deployment executing the task and other data that needs to be stored. It can be understood that the task identifier can be added to the relevant labels of the Pod and the Deployment, thereby associating the Pod, the Deployment and the task in the cache unit. In addition, the cache unit can also store historical task (historical period executed, current task not executed) information, such as task identifier, task description, execution time, etc. When the historical task information is needed, the cache unit interface can be used to directly query.

[0047] In addition, the task to which the method of the application is directed can be various types of tasks, such as single calculation tasks, batch calculation tasks, and stream calculation tasks. In practical applications, the above tasks can be Spark (a big data processing engine) tasks based on the Kubernetes platform, such as Spark Streaming (Spark stream processing framework) tasks. It can be understood that when performing a stream calculation task, the success state and the unknown state of the Pod generally do not need to be concerned. This is because the success state is generally used for state judgment of batch calculation tasks, and valuable information cannot be obtained from the unknown state.

[0048] In a Spark cluster built on a Kubernetes platform, the roles of the Pods are generally Driver and Executor. In the process of executing a task, a Deployment generally starts a Driver Pod through a Replication Controller (RC) or a Replica Set (RS), and the Driver Pod starts one or more Executor Pods. In executing a task, the Driver Pod divides the task into multiple tasks for the Executor Pods to run, and the Driver Pod is also responsible for tracking the health of the Executor Pods, assigning tasks to the Executor Pods, receiving the calculation results returned by the Executor Pods, etc. It can be seen that in the above scenario, the task is executed in a container in the Executor Pod, the container is encapsulated in the Executor Pod and managed by the Driver Pod, and the Driver Pod is deployed by the Deployment. The above scenario is referred to as the first scenario, and the technical solutions of the present application will be mainly introduced through the first scenario. The scenario without Driver Pod and Executor Pod is referred to as the second scenario, in which the task is executed in a container, the container is encapsulated in a Pod and managed by the Pod, and the Pod is deployed by the Deployment.

[0049] It can be understood that the following description mainly takes the task state judgment scenario of the Kubernetes platform as an example, but this does not form any limitation on the application scenarios of the present application. In fact, the method of the present application can be applied to any other applicable scenario, and the objects such as "container set" and "deployment unit" are not limited to "Pod" and "Deployment" in Kubernetes, but can represent the corresponding objects in the above applicable scenarios. The terms "first", "second", etc. used in the present application are used in the description of various objects, but these objects are not limited by the above terms. The above terms are only used to distinguish one object from another. For example, without departing from the scope of the present application, the first threshold can be referred to as the second threshold, and the second threshold can be referred to as the first threshold. The first threshold and the second threshold are both thresholds, but they are not the same threshold. In addition, it should be pointed out that the embodiments of the present application and the technical features in the embodiments can be combined with each other without conflict.

[0050] Figure 1is the main step schematic diagram of the method for determining the task state in the first embodiment of the present application. In the first embodiment, the current state of the task can be determined by obtaining the container set event and / or the deployment unit event. Generally, the container set event occurs when the container set is created or the state is changed, and the container set event can carry the task identification corresponding to the container set, the current state of the container set and the like; the deployment unit event occurs when the deployment unit is created, the state is changed or the field data is changed, and the deployment unit event can carry the task identification corresponding to the deployment unit, the current field data of the deployment unit and the like.

[0051] In the first scenario, the deployment unit needs to be created first when the task is started for the first time, and after the deployment unit is created, the related records (such as the task identification and the task state) of the task can be stored in the cache unit (the cache unit does not store the related records of the task before), and the current state of the task is determined as starting. Then, the deployment unit creates the driver container set through the RC or the RS, and in the creation process of the driver container set, the current state of the task can be determined as starting. After that, if the deployment unit fails to start, it means that the task fails to start, and at this time, the value of the unavailable field of the deployment unit is 1; if the driver container set enters the running state, it means that the task enters the running state. Finally, when the task needs to be stopped due to updating the script, abandoning the execution of the task and the like, the deployment unit can be stopped first, and at this time, the value of the available field of the deployment unit is 0, which means that the task is in the stopping state. In addition, in the first scenario, the task can directly enter the starting failure state from the starting state (that is, the task enters the starting failure state due to the failure of the driver container set when the task is in the starting state), and can directly enter the running state from the starting failure state.

[0052] As shown in Figure 1 , the method for determining the task state of the present embodiment can be specifically executed according to the following steps:

[0053] Step S101: obtaining the event occurring in the container set, and determining the current state of the container set from the event; when the current state is the running state and the pre-stored latest state of the task is the starting related state, the current state of the task is determined as the running state.

[0054] It can be understood that the container set used for judging the task state in this step can be the driver container set in the first scenario. This step can obtain the container set event through a listening mechanism. Specifically, in the first scenario, a listening unit (for example, a watcher in Kubernetes) can be started before the task is executed, the driver container set and the executor container set are listened to by using the listening unit, and the event sent by the listening unit is received when an event occurs in the container set. After receiving the container set event, the task identifier can be extracted therefrom to associate the event with the task stored in the cache unit, and the container set role is extracted. When the container set is the executor container set, since the label of the executor container set has the network address of the driver container set so as to communicate with the driver container set, the network address of the driver container set can be obtained from the label thereof as the user interface address information (that is, the IP address and port of SparkUI, and the IP address refers to the Internet Protocol address) of Spark started in the driver container set, so as to facilitate viewing and tracking the Spark state.

[0055] If the container set corresponding to the received event is the driver container set, it can be firstly judged in the cache unit whether the recent state of the driver container set is the start starting state: if yes, the current state of the task is determined as the starting state (because when the task is in the start starting state, the first driver container set event received is generally a creation event, and therefore the task is converted to the starting state). If not, the current state of the driver container set is extracted from the event, and when the current state of the driver is determined as the running state and the recent state of the task is the starting related state, the current state of the task is determined as the running state. If the current state of the driver is not determined as the running state, or the recent state of the task is not the starting related state, the task state stored in the cache unit is not updated, and the container set is continuously listened to.

[0056] Step S102: obtaining an event occurring in the deployment unit, determining the number of unavailable container sets controlled by the deployment unit from the event; when the number is equal to a preset first threshold value and the recent state of the task stored in advance is a starting related state except the starting failure state, the current state of the task is determined as the starting failure state.

[0057] In this step, the monitoring unit can be started to monitor the deployment unit, and receive the event sent by the monitoring unit when the event occurs in the deployment unit. After receiving the event of the deployment unit, the task identifier can be extracted therefrom, and it is determined whether the task identifier is stored in the cache unit. If not stored in the cache unit, it indicates that the task is a new task, at this time, the task identifier and the like can be recorded in the cache unit, and the current state of the task is determined as a start state. If the task identifier has been stored in the cache unit, it indicates that the task is not a new task, at this time, it is first determined in the cache unit whether the recent state of the task is a start state or a starting state: if so, it is further determined whether the value of the unavailable field of the deployment unit is a preset first threshold value (generally, the first threshold value can be set as the total number of containers controlled by the deployment unit, and in the first scenario, the first threshold value is 1), if the value of the unavailable field is the first threshold value, it indicates that the deployment unit fails to start at this time, and therefore the current state of the task is determined as a start failure state. If the value of the unavailable field is not the first threshold value, the original state of the task is maintained. It should be noted that steps S102 and S101 can be executed independently or in combination.

[0058] In an optional implementation, if it is determined in the cache unit that the recent state of the task is not a start state or a starting state, it is further determined whether the recent state is a running state: if not, the original state of the task is maintained; if so, the value of the available field of the deployment unit is extracted from the event, and it is determined whether the value of the available field is a preset second threshold value (the second threshold value can be set according to requirements, and in the first scenario, the second threshold value is zero). If the value of the available field is the second threshold value, it indicates that the deployment unit has stopped at this time, and therefore the current state of the task is determined as a stop state. If the value of the available field is not the second threshold value, the original state of the task is maintained.

[0059] As a preferred scheme, before extracting the value of the available field of the deployment unit from the event, it is first determined whether the event carries a stop event identifier (such as a stop event code): if the event carries the stop event identifier, it indicates that the event is a stop event, and the value of the available field of the deployment unit can be extracted and determined; if the event does not carry the stop event identifier, it indicates that the event is not a stop event, and the determination process is terminated, and the original state of the task is maintained. Through the above steps, the accuracy of the determination of the stop state of the task can be improved.

[0060] Figure 2 is a schematic diagram of the execution flow of the method for determining the state of the task in the first embodiment of the present application, as Figure 2As shown, in the first scenario, the task state can be determined by the following specific steps. First, start the monitoring task, and start two monitoring units to monitor the Pod (lower branch) and Deployment (upper branch) respectively. In the upper branch, after obtaining the Deployment event, the app name (as the task identifier) is extracted therefrom, and it is determined whether the app name exists in the Redis (cache unit). If not, a new task record is created in the Redis, the phase is stored as zero (i.e., it is determined that the task is in the starting state), and the current state of the driver container set is set to be pending. If the app name exists in the Redis, it is further determined whether the phase is 0 or 1 (i.e., it is determined whether the latest state of the task is the starting state or the starting state): if so, the unavailable field value of the Deployment is obtained, and when the unavailable field value is 1, the task phase of the cache unit is updated to be 2 (i.e., it is determined that the task is in the starting failure state), and the state of the driver container set is updated to be failed; when the unavailable field value is not 1, the original state of the task is maintained.

[0061] If it is determined in the above steps that the phase is neither zero nor 1, it is determined whether the phase is 3: if not, the original state of the task is maintained; if so, it is further determined whether the Deployment event is a stop event. If the Deployment event is not a stop event, the original state of the task is maintained; if the Deployment event is a stop event, the available field value of the Deployment is obtained. When the available field value is not zero, the original state of the task is maintained; when the available field value is zero, the task phase of the cache unit is updated to be 4 (i.e., it is determined that the task is in the stop state), and the state of the driver container set is updated to be deleted.

[0062] In the lower branch, after listening to the Pod event, the Pod role is first obtained, the Spark UI address is obtained from the Executor Pod label when the Pod is an Executor Pod, and it is judged whether the task phase stored in the cache is zero when the Pod is a Driver Pod: if yes, the phase is updated to 1 (i.e., it is determined that the task is in the starting state), and the Pod state is pending at this time; if no, the current state of the Pod is extracted from the Pod event, and it is judged whether the phase is 1 or 2 and the current state of the Pod is the running state. If the phase is 1 or 2 and the current state of the Pod is the running state, the phase in the cache unit is updated to 3 (i.e., it is determined that the task is in the running state). If the phase is neither 1 nor 2, or the current state of the Pod is not the running state, the process ends and continues to listen to the Pod.

[0063] It should be noted that, Figure 2 The upper branch and the lower branch in the first scenario have a close correlation. Specifically, first, when the upper branch determines that the task is in the starting failure state or the stopping state, it may need to rely on the previously determined starting state or the running state, and the starting state and the running state are determined through the lower branch; when the lower branch determines that the task is in the starting state or the running state, it may need to rely on the previously determined starting state or the starting failure state, and the starting state or the starting failure state is determined through the upper branch. In addition, since the Deployment has a management and scheduling effect on the Pod, the Deployment state change can trigger the Pod event, so the judgment logic of the upper branch and the lower branch has strong relevance.

[0064] In the second scenario, the Pod has no distinction between the Driver Pod and the Executor Pod, and the Deployment directly deploys one or more Pods, and the process of determining the task state is basically the same as that in the first scenario, and the difference is that: in the judgment branch of listening to the Pod, it is not necessary to judge the role of the Pod; in the judgment branch of listening to the Deployment, the first threshold can be set as the total number of Pods, and the second threshold can still be set as zero.

[0065] Figure 3 is the main step schematic diagram of the method for determining the task state in the second embodiment of the application. As shown in Figure 3 The following steps can be executed to determine the task state in the second embodiment.

[0066] Step S101: Acquire the event occurred in the container set, determine the current state of the container set from the event; when the current state is the running state, and the latest state of the pre-stored task is the start-related state, determine the current state of the task as the running state. This step is the same as step S101 in the first embodiment, and is not repeated here.

[0067] Step S302: Acquire the event occurred in the deployment unit, determine the number of available container sets controlled by the deployment unit from the event; when the number is equal to the preset second threshold, and the latest state of the pre-stored task is the running state, determine the current state of the task as the stop state. This step is the same as the step of determining the current state of the task as the stop state in the first embodiment, and is not repeated here. It can be understood that step S302 and step S101 can be executed independently, or can be combined.

[0068] Preferably, in the present embodiment, the event occurred in the deployment unit can be acquired, and the number of unavailable container sets controlled by the deployment unit can be determined from the event; when the number is equal to the preset first threshold, and the latest state of the pre-stored task is the start-related state other than the start failure state, the current state of the task is determined as the start failure state. This step is the same as the step of determining the task in the start failure state in the first embodiment, and the specific details are not repeated here.

[0069] In addition, in an optional implementation, before the step of determining the number of available container sets controlled by the deployment unit from the deployment unit event is executed, if it is determined that the stop event identifier is not carried in the deployment unit event, the step is not executed. After the event occurred in the deployment unit is acquired, the task identifier is determined from the event, and when it is determined that the task identifier is not stored in the cache unit, the current state of the task is determined as the start state. After the event occurred in the container set is acquired, if the latest state of the task stored in the cache unit is the start state, the current state of the task is determined as the starting state.

[0070] In the technical solution of the embodiment of the present application, the container set event and the deployment unit event related to the task can be acquired, then the current state of the container set is extracted from the container set event, the current parameter state of the deployment unit is extracted from the deployment unit event, and the current state of the container set, the current parameter state of the deployment unit and the latest state of the task stored in advance are combined to determine, so as to obtain the accurate current state of the task. In actual application, the current state of the container set and the latest state of the task are determined according to the preset strategy to determine whether the task is in a running state, and the current parameter state of the deployment unit and the latest state of the task are determined according to the preset strategy to determine whether the task is in a startup failure state or a stop state. Meanwhile, the Kubernetes listening mechanism can be used to acquire the container set event and the deployment unit event. Specifically, two listening units are started to listen to the container set and the deployment unit in parallel, and when an event occurs in the container set or the deployment unit, it is automatically captured and pushed, thereby reducing the pressure of the API Server. In addition, the cache unit can be used to store the latest state of the current task and historical task information, and the cache unit interface can be used to directly query the historical task information when the historical task information is needed.

[0071] It should be noted that, for each of the above method embodiments, in order to facilitate the description, it is expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the described actions, and some steps can actually be performed in other order or simultaneously. In addition, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily essential to implement the present application.

[0072] In order to better implement the above scheme of the embodiment of the present application, the related device for implementing the above scheme is also provided below.

[0073] Please refer to Figure 4 As shown in FIG. 4, the device 400 for determining the task state (the device corresponds to the first embodiment method) provided by the embodiment of the present application can include a first state determining unit 401 and / or a second state determining unit 402. Wherein, the task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit; the task state includes a startup related state and a running state, and the startup related state includes a startup failure state.

[0074] The first state determining unit 401 is configured to: acquire an event occurring in the container set, determine a current state of the container set from the event; and when the current state is a running state and a last state of the task stored in advance is a start-related state, determine the current state of the task as a running state. The second state determining unit 402 is configured to: acquire an event occurring in the deployment unit, determine a number of unavailable container sets controlled by the deployment unit from the event; and when the number is equal to a preset first threshold and the last state of the task stored in advance is a start-related state except a start failure state, determine the current state of the task as the start failure state.

[0075] In the embodiment of the present application, the task state further includes a stop state. The apparatus 400 further includes a third state determining unit configured to: acquire an event occurring in the deployment unit, determine a number of available container sets controlled by the deployment unit from the event; and when the number is equal to a preset second threshold and a last state of the task stored in advance is a running state, determine the current state of the task as the stop state.

[0076] The start-related state further includes a start start state and a start running state, and the last state of the task is stored in a cache unit. The apparatus 400 further includes an executing unit configured to: after determining the current state of the task, store the current state in the cache unit; before performing the step of determining the number of available container sets controlled by the deployment unit from the event: if it is determined that the event does not carry a stop event identifier, do not perform the step; after acquiring the event occurring in the deployment unit: determine an identifier of the task from the event, and when it is determined that the identifier is not stored in the cache unit, determine the current state of the task as the start start state; after acquiring the event occurring in the container set: if the last state of the task stored in the cache unit is the start start state, determine the current state of the task as the start running state.

[0077] Further, in the embodiment of the present application, the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, and the cache unit stores historical task information. The container is a Docker container, the container set is a driver container set Driver Pod for scheduling an executor container set Executor Pod, and the deployment unit is Deployment. The state of the Driver Pod further includes at least one of the following: a to-be-processed state, a failed state, and a deleted state. The first state determining unit 401 is further configured to: listen to the Driver Pod by using the listening unit, and receive the event sent by the listening unit when the event occurs in the Driver Pod. The second state determining unit 402 is further configured to: listen to the Deployment by using the listening unit, and receive the event sent by the listening unit when the event occurs in the Deployment. The execution unit is further configured to: after receiving the event occurring in the Executor Pod, obtain the Spark user interface address information started by the Driver Pod from the label of the Executor Pod.

[0078] Figure 5 is a component of the device for determining the state of the task corresponding to the method shown in Figure 3 As shown in Figure 5 The device 500 includes a first state determining unit 401 and / or a third state determining unit 502. The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit. The state of the task includes a startup-related state, a running state, and a stopped state.

[0079] Specifically, the first state determining unit 401 is configured to: obtain an event occurring in the container set, determine a current state of the container set from the event, and determine a current state of the task as the running state when the current state is the running state and a latest state of the task stored in advance is the startup-related state. The third state determining unit 502 is configured to: obtain an event occurring in the deployment unit, determine a number of available container sets controlled by the deployment unit from the event, and determine the current state of the task as the stopped state when the number is equal to a preset second threshold and a latest state of the task stored in advance is the running state.

[0080] In the embodiments of the present application, the startup-related state includes a start startup state, a startup-in-progress state, and a startup failure state. The apparatus 500 can further include a second state determining unit configured to acquire an event occurring at the deployment unit, determine a number of unavailable container sets controlled by the deployment unit from the event, and determine the current state of the task as the startup failure state when the number is equal to a preset first threshold and the pre-stored latest state of the task is a startup-related state other than the startup failure state.

[0081] As a preferred solution, the apparatus 500 further includes an execution unit configured to: after determining the current state of the task, store the current state in a cache unit; before performing the step of determining the number of available container sets controlled by the deployment unit from the event: if it is determined that the event does not carry a stop event identifier, the step is not performed; after acquiring the event occurring at the deployment unit: determine the identifier of the task from the event, and determine the current state of the task as the start startup state when it is determined that the identifier is not stored in the cache unit; and after acquiring the event occurring at the container set: if the pre-stored latest state of the task in the cache unit is the start startup state, determine the current state of the task as the startup-in-progress state.

[0082] Preferably, in the embodiments of the present application, the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, and the cache unit stores historical task information. The container is a Docker container, the container set is a driver container set Driver Pod for scheduling an executor container set Executor Pod, and the deployment unit is Deployment. The state of the Driver Pod further includes at least one of the following: a to-be-processed state, a failure state, and a deleted state. The first state determining unit 401 can be further configured to: listen to the Driver Pod by using a listening unit, and receive the event sent by the listening unit when the event occurs at the Driver Pod. The second state determining unit can be further configured to: listen to the Deployment by using the listening unit, and receive the event sent by the listening unit when the event occurs at the Deployment. The execution unit can be further configured to: after receiving the event occurring at the Executor Pod, acquire Spark user interface address information started by the Driver Pod from a label of the Executor Pod.

[0083] In the technical solution of the embodiment of the application, the container set event and the deployment unit event related to the task can be acquired, then the current state of the container set is extracted from the container set event, the current parameter state of the deployment unit is extracted from the deployment unit event, and the current state of the task is obtained by combining the current state of the container set, the current parameter state of the deployment unit and the latest state of the task stored in advance. In actual application, whether the task is in a running state can be determined according to the preset strategy for judging the current state of the container set and the latest state of the task, and whether the task is in a start failure state or a stop state can be determined according to the preset strategy for judging the current parameter state of the deployment unit and the latest state of the task. Meanwhile, the Kubernetes listening mechanism can be used to acquire the container set event and the deployment unit event. Specifically, two listening units are started to listen to the container set and the deployment unit in parallel, and when an event occurs in the container set or the deployment unit, the event is automatically captured and pushed, thereby reducing the pressure on the API Server. In addition, the cache unit can be used to store the latest state of the current task and historical task information, and the cache unit interface can be used to directly query the historical task information when the historical task information is needed.

[0084] Figure 6 An exemplary system architecture 600 to which the method of determining a task state or the apparatus of determining a task state of the embodiments of the application can be applied is shown.

[0085] As shown in Figure 6 The system architecture 600 can include terminal devices 601, 602, 603, a network 604 and a server 605 (this architecture is only an example, and the components included in the specific architecture can be adjusted according to the specific application). The network 604 is used to provide a communication link medium between the terminal devices 601, 602, 603 and the server 605. The network 604 can include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0086] A user can use the terminal devices 601, 602, 603 to interact with the server 605 through the network 604 to receive or send messages, etc. Various client applications can be installed on the terminal devices 601, 602, 603, such as an application for determining a task state (only an example).

[0087] The terminal devices 601, 602, 603 can be various electronic devices with a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers and desktop computers, etc.

[0088] The server 605 can be a server providing various services, for example, a background server (for example only) providing support for an application operated by a user using the terminal device 601, 602, 603 for determining a task state. The background server can process a received state judgment request and feed back a processing result (for example, a determined task state, for example only) to the terminal device 601, 602, 603.

[0089] It should be noted that the method for determining a task state provided by the embodiments of the present application is generally executed by the server 605, and accordingly, the apparatus for determining a task state is generally arranged in the server 605.

[0090] It should be understood that, Figure 6 The number of terminal devices, networks and servers in the system is merely illustrative. Any number of terminal devices, networks and servers can be provided according to implementation needs.

[0091] The present application also provides an electronic device. The electronic device of the embodiments of the present application comprises one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method for determining a task state provided by the present application.

[0092] Reference is made below to Figure 7 which shows a structural schematic diagram of a computer system 700 suitable for implementing the electronic device of the embodiments of the present application. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functions and use range of the embodiments of the present application.

[0093] As shown in Figure 7 , the computer system 700 comprises a central processing unit (CPU) 701 which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 702 or programs loaded from a storage portion 708 into a random access memory (RAM) 703. Various programs and data required for the operation of the computer system 700 are also stored in the RAM 703. The CPU 701, the ROM 702 and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0094] The following components are connected to the I / O interface 705: an input part 706 including a keyboard, a mouse, etc.; an output part 707 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage part 708 including a hard disk, etc.; and a communication part 709 including a network interface card such as a LAN card, a modem, etc. The communication part 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as necessary. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 710 as necessary, so that a computer program read therefrom is installed in the storage part 708 as necessary.

[0095] In particular, the process described by the above main flowchart can be implemented as a computer software program according to the embodiments disclosed herein. For example, the embodiments of the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the method shown in the main flowchart. In the above embodiments, the computer program can be downloaded and installed from a network by the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit 701, the above-described functions defined in the system of the present application are executed.

[0096] It should be noted that the computer-readable medium shown in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or component. In the present application, the computer-readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or component. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0097] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment or a part of code containing one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different order than that shown in the drawings. For example, two blocks that are shown in succession can actually be executed substantially in parallel, and they can also be executed in reverse order, depending on the involved functions. It should also be noted that each block in the block diagrams or flowcharts, and the combination of blocks in the block diagrams or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0098] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware. The described units can also be arranged in a processor, for example, a processor can be described as including a first state determining unit and a second state determining unit. In some cases, the names of these units do not constitute a limitation on the units themselves, for example, the first state determining unit can also be described as a unit for determining the current state of the task according to the container set event.

[0099] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist separately without being assembled into the device. The computer readable medium carries one or more programs, which, when executed by the device, cause the device to perform the steps including: obtaining an event occurring in a container set, determining the current state of the container set from the event; when the current state is a running state and the last state of the task stored in advance is a start-related state, determining the current state of the task as a running state; and / or obtaining an event occurring in a deployment unit, determining the number of unavailable container sets controlled by the deployment unit from the event; when the number is equal to a preset first threshold and the last state of the task stored in advance is a start-related state other than a start failure state, determining the current state of the task as a start failure state.

[0100] In the technical solutions of the embodiments of the present application, the container set event and the deployment unit event related to the task can be obtained, and then the current state of the container set is extracted from the container set event, the current parameter state of the deployment unit is extracted from the deployment unit event, and the current state of the container set, the current parameter state of the deployment unit and the last state of the task stored in advance are combined to determine the current state of the task. In actual application, the current state of the container set and the last state of the task are determined according to a preset strategy to determine whether the task is in a running state, and the current parameter state of the deployment unit and the last state of the task are determined according to a preset strategy to determine whether the task is in a start failure state or a stop state. At the same time, the present application can use the listening mechanism of Kubernetes to obtain the container set event and the deployment unit event. Specifically, two listening units are started to listen to the container set and the deployment unit in parallel, and when an event occurs in the container set or the deployment unit, it is automatically captured and pushed, thereby reducing the pressure on the API Server. In addition, the present application can use a cache unit to store the last state of the current task and historical task information, and when the historical task information needs to be queried, the cache unit interface can be used to directly query.

[0101] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of specific terminology. However, embodiments thereof can be practiced with the exact description not being presented in detail. The term "device" should be understood to encompass devices operating in various modes, such as active mode, sleep mode, hibernate mode, and the like. The terms "coupled" and "connected," along with derivatives thereof, can be used. It should be understood that these terms are not intended as synonyms for each other. Rather, particular circuitry that can be said to be coupled to, or connected with, other circuitry can be some of the other circuitry that can communicate in some way, while other circuitry can be some of the other circuitry that can not be in communication with that particular circuitry.

Claims

1. A method of determining a status of a task, wherein, The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit; The task state includes a startup-related state and a running state, and the startup-related state includes a startup failure state; The method comprises: acquiring an event occurring in the container set, determining a current state of the container set from the event; when the current state is a running state and a previously stored latest state of the task is a startup-related state, determining the current state of the task as a running state; and / or acquiring an event occurring in the deployment unit, determining a number of unavailable container sets controlled by the deployment unit from the event; when the number is equal to a preset first threshold and the previously stored latest state of the task is a startup-related state other than a startup failure state, determining the current state of the task as a startup failure state.

2. The method of claim 1, wherein, The task state further includes a stop state; and the method further comprises: acquiring an event occurring in the deployment unit, determining a number of available container sets controlled by the deployment unit from the event; when the number is equal to a preset second threshold and the previously stored latest state of the task is a running state, determining the current state of the task as a stop state.

3. The method of claim 2, wherein, The startup-related state further includes a start startup state and a startup state, and the latest state of the task is stored in a cache unit; and the method further comprises: after determining the current state of the task, storing the current state in the cache unit; before performing the step of determining the number of available container sets controlled by the deployment unit from the event: if it is determined that the event does not carry a stop event identifier, the step is not performed; after acquiring the event occurring in the deployment unit: determining an identifier of the task from the event, and when it is determined that the identifier is not stored in the cache unit, determining the current state of the task as a start startup state; after acquiring the event occurring in the container set: if the latest state of the task stored in the cache unit is a start startup state, determining the current state of the task as a startup state.

4. The method of claim 3, wherein: the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, and the cache unit stores historical task information; the container is a Docker container, the container set is a driver container set Driver Pod for scheduling an executor container set Executor Pod, and the deployment unit is Deployment, and the state of the Driver Pod further includes at least one of the following: a pending state, a failure state, and a deleted state; acquiring the event occurring in the container set comprises: using a listening unit to listen to the Driver Pod, and receiving the event sent by the listening unit when an event occurs in the Driver Pod. The event occurring in the deployment unit is obtained by using a listening unit to listen to the Deployment, and the event is received from the listening unit when the event occurs in the Deployment. The method further comprises: after the event occurring in the Executor Pod is received, obtaining the Spark user interface address information started by the Driver Pod from the label of the Executor Pod.

5. A method of determining a status of a task, wherein, The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit; the task state comprises a start-related state, a running state and a stop state; The method comprises: obtaining an event occurring in the container set, determining the current state of the container set from the event; when the current state is the running state and the latest state of the task stored in advance is the start-related state, determining the current state of the task as the running state; and / or obtaining an event occurring in the deployment unit, determining the number of available container sets controlled by the deployment unit from the event; when the number is equal to a preset second threshold and the latest state of the task stored in advance is the running state, determining the current state of the task as the stop state.

6. The method of claim 5, wherein, The start-related state further comprises a start state and a starting state, and the latest state of the task is stored in a cache unit; and the method further comprises: after determining the current state of the task, storing the current state in the cache unit; before performing the step of determining the number of available container sets controlled by the deployment unit from the event: if it is determined that the event does not carry a stop event identifier, the step is not performed; after obtaining the event occurring in the deployment unit: determining the identifier of the task from the event, and determining the current state of the task as the start state when it is determined that the identifier is not stored in the cache unit; after obtaining the event occurring in the container set: if the latest state of the task stored in the cache unit is the start state, determining the current state of the task as the starting state.

7. The method of claim 6, wherein: the task is a stream computing task, the task is executed in a Spark cluster built on a Kubernetes platform, and the cache unit stores historical task information; the container is a Docker container, the container set is a driver container set Driver Pod for scheduling an executor container set Executor Pod, and the deployment unit is Deployment, and the state of the Driver Pod further comprises at least one of the following: a pending state, a failure state and a deleted state; the event occurring in the container set is obtained by using a listening unit to listen to the Driver Pod, and the event is received from the listening unit when the event occurs in the Driver Pod. The event occurring in the deployment unit is obtained by using a listening unit to listen to the Deployment, and the event is received from the listening unit when the event occurs in the Deployment; The method further comprises: after the event occurring in the Executor Pod is received, obtaining the Spark user interface address information started by the Driver Pod from the label of the Executor Pod.

8. An apparatus for determining a state of a task, wherein, The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit; The task state comprises a startup-related state and a running state, and the startup-related state comprises a startup failure state; The device comprises: A first state determining unit is configured to obtain an event occurring in the container set, determine a current state of the container set from the event, and determine a current state of the task as a running state when the current state is a running state and a latest state of the task stored in advance is a startup-related state; and / or A second state determining unit is configured to obtain an event occurring in the deployment unit, determine a number of unavailable container sets controlled by the deployment unit from the event, and determine the current state of the task as a startup failure state when the number is equal to a preset first threshold and the latest state of the task stored in advance is a startup-related state other than a startup failure state.

9. An apparatus for determining a state of a task, wherein, The task is executed in a container, the container is managed by a container set, and the container set is deployed by a deployment unit; the task state comprises a startup-related state, a running state, and a stop state; The device comprises: A first state determining unit is configured to obtain an event occurring in the container set, determine a current state of the container set from the event, and determine a current state of the task as a running state when the current state is a running state and a latest state of the task stored in advance is a startup-related state; and / or A third state determining unit is configured to obtain an event occurring in the deployment unit, determine a number of available container sets controlled by the deployment unit from the event, and determine the current state of the task as a stop state when the number is equal to a preset second threshold and the latest state of the task stored in advance is a running state.

10. An electronic device, comprising: The device comprises: One or more processors; A storage device configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-7.

11. A computer readable storage medium having stored thereon a computer program, characterized in that The program is executed by the processor to implement the method according to any one of claims 1-7.

Images