Container cold start

Abstract

Provided in the present disclosure are a container cold start method, and a device, a system, a program product and a storage medium. Containers run on nodes in a node cluster. The method comprises: in response to receiving a warm-up request for a target container to be cold-started, selecting a warm-up node from a node cluster, and the warm-up node acquiring image data of the target container and storing same locally; and in response to receiving a cold start request for the target container, selecting a target node by means of a selection strategy of preferentially selecting the warm-up node, and the target node first locally attempting to acquire pre-stored image data and then attempting to acquire the pre-stored image data by means of a communicable node, acquiring, when the image data is not successfully acquired, the image data of the target container by means of an image repository, and finally using the acquired image data to start the target container.

Description

[0001] Container cold start TECHNICAL FIELD

[0002]

[0001] The present disclosure relates to the field of cloud computing technology, and particularly to container cold start. BACKGROUND

[0003]

[0002] Container images have always been the mainstream running mode of cloud native applications. In the Serverless scenario, the Serverless application engine can provide a simple Serverless experience for applications based on container images. In some application scenarios, users are sensitive to the time of container startup, therefore, how to improve the speed of container cold start is a technical problem to be solved. SUMMARY

[0004]

[0003] To overcome the problems in the related art, the present disclosure provides a container cold start method, device, system, program product and storage medium.

[0005]

[0004] According to a first aspect of an embodiment of the present specification, a container cold start method is provided, the container runs on a node in a node cluster, the nodes in the node cluster are networked by a P2P network, the types of nodes in the P2P network include a root node and peer nodes managed by the root node, the root node and each node of the managed peer nodes can communicate with each other, the method comprises: in response to receiving a preheating request for a target container to be cold started, selecting at least one preheating node from the node cluster, and obtaining image data of the target container from an image repository by the preheating node and storing it locally; in response to receiving a cold start request for the target container, using a selection strategy of preheating node priority selection to select a target node from the node cluster, and the target node first tries to obtain pre-stored image data of the target container from the local, then tries to obtain the image data through the communicable node, and in the case of unsuccessful acquisition, obtains the image data of the target container through the image repository, and finally starts the target container using the obtained image data of the target container.

[0006]

[0005] According to a second aspect of the embodiments of the present disclosure, a container cold start method is provided, which is applied to a node in a node cluster, the node in the node cluster adopts a P2P network for networking, the node in the P2P network includes a root node and a peer node managed by the root node, the root node and each node in the managed peer nodes can communicate with each other, and the method includes: in response to receiving a preheating node of image data of a target container, obtaining the image data of the target container through a mirror warehouse and storing locally; in response to receiving a cold start request of a target container, first attempting to obtain the pre-stored image data of the target container from the local, then attempting to obtain the pre-stored image data of the target container through a communicable node, and in the case of unsuccessful acquisition, obtaining the image data of the target container through the mirror warehouse, and finally starting the target container by using the obtained image data of the target container.

[0007]

[0006] According to a third aspect of the embodiments of the present disclosure, a container management system is provided, which includes a scheduling end and a node cluster, the scheduling end is used to execute the steps of the method of the first aspect, and the node in the node cluster is used to execute the steps of the method of the second aspect.

[0008]

[0007] According to a fourth aspect of the embodiments of the present disclosure, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to realize the steps of the method embodiments of the first aspect or the second aspect.

[0009]

[0008] According to a fifth aspect of the embodiments of the present disclosure, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to realize the steps of the method embodiments of the first aspect or the second aspect.

[0010]

[0009] According to a sixth aspect of the embodiments of the present disclosure, a computer program product is provided, which includes a computer program, and the computer program is executed by a processor to realize the steps of the method embodiments of the first aspect or the second aspect.

[0011]

[0010] The technical solutions provided by the embodiments of the present specification can include the following beneficial effects: In the embodiments of the present specification, the nodes in the node cluster adopt a P2P network, the types of the nodes in the P2P network include a root node and peer nodes managed by the root node, the root node and the managed peer nodes can communicate with each other, therefore, after receiving a preheating request for a cold-start target container, at least one preheating node can be selected from the node cluster, the preheating node can obtain the image data of the target container through a mirror repository and store it locally; therefore, when receiving a cold-start request for the target container, a target node can be selected from the node cluster by using the preheating node selection strategy, the target node can first try to obtain the pre-stored image data of the target container from the local node, and then try to obtain the image data of the target container through the communicable nodes, and in the case of unsuccessful acquisition, the image data of the target container can be obtained through the mirror repository, and finally the target container can be started by using the obtained image data of the target container. Based on the network characteristics of the node cluster, the preheating node is pre-selected, and the image data is pre-stored, so that when the container needs to be cold-started subsequently, there is a certain probability to schedule to the preheating node, and therefore the speed of container cold-start can be improved.

[0012]

[0011] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0013]

[0012] The accompanying drawings incorporated into the specification and forming a part of the specification, show embodiments consistent with the present specification, and together with the specification, serve to explain the principles of the present disclosure.

[0014]

[0013] FIG. 1 is a schematic diagram of a container management scenario according to an exemplary embodiment of the present specification.

[0015]

[0014] FIG. 2A is a flowchart of a container startup method according to an exemplary embodiment of the present specification.

[0016]

[0015] FIG. 2B is a schematic diagram of a P2P network according to an exemplary embodiment of the present specification.

[0016] FIG. 2C is a schematic diagram of deleting an affinity label according to an exemplary embodiment of the present specification.

[0017]

[0017] FIG. 2D is a schematic diagram of a container startup scenario according to an exemplary embodiment of the present specification.

[0018]

[0018] FIG. 2E is a diagram illustrating a pre-warming of mirror data according to an example embodiment of the present specification.

[0019]

[0019] FIG. 3 is a diagram illustrating a hardware structure of a computer device in which a container launch apparatus is installed according to an example embodiment of the present specification.

[0020]

[0020] The example embodiments will be described in detail below with reference to the attached drawings. In the following description, the same numbers are used to designate the same elements, unless otherwise indicated. The embodiments described in the following example embodiments are not representative of all embodiments consistent with the present specification. Rather, they are merely examples of devices and methods consistent with some aspects of the present specification, as detailed in the appended claims.

[0021]

[0021] The terminology used in the present specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the present specification. As used in the present specification and the appended claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0022]

[0022] It will be understood that, although the terms first, second, third, etc. can be used herein to describe various information, these terms are not intended to denote a temporal or chronological order. Rather, these terms are used solely to distinguish one type of information from another type of information. For example, a first information can also be termed a second information, and, similarly, a second information can also be termed a first information, without departing from the scope of the present specification. Depending on the context, the word "if' as used herein can be interpreted as meaning "when" or "if upon a determination."

[0023]

[0023] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present disclosure are information and data authorized by the user or authorized by all parties, and the collection, use and processing of the relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation portals for the user to choose authorization or refusal.

[0024]

[0024] As shown in FIG. 1, is a schematic diagram of a container management scenario according to an exemplary embodiment of the present specification. In the container management scenario, a scheduling end and some worker nodes Node can be included. For the convenience of example, only three Nodes (Node1 (Node 1), Node2 (Node 2) and Node3 (Node 3)) are shown in FIG. 1.

[0025]

[0025] Among them, the scheduling end can be used to schedule containers to run on the Node. The scheduling end can occupy one or more independent servers. A set of processes related to cluster management can be running on the scheduling end, which implements the management functions of the entire cluster such as resource management, scheduling, elasticity, security control, system monitoring and error correction.

[0026]

[0026] The Node as a worker node in the cluster, this node can be a physical machine, or a virtual machine in a private cloud or public cloud. The Node can be dynamically added to the cluster during runtime. Taking the serverless architecture as an example, on the Node, one Node can run one or more containers. For example, Node1, Node2 and Node3 shown in FIG. 1 can run different numbers of containers.

[0027]

[0027] In some application scenarios, the user can require the cloud to start the container required by the user through the container image, and run the process required by the user in the container. The container image is a lightweight, executable software package that contains everything needed to run an application: code, runtime environment, system tools, libraries and settings, etc. As an example, the user can build an application into a container image based on a Dockerfile file and upload it to a container image repository, and then pull the container image and start the container in the test or production environment. In other examples, the user can also provide application code and runtime environment data, and the platform provides the corresponding container image.

[0028]

[0028] Container images have been the mainstream runtime mode for cloud-native applications. In the serverless architecture, the serverless application engine can provide a simple serverless experience for applications based on container images. In other cloud computing scenarios, such as function computing, the use of container images has become increasingly popular in recent years, and the number of cold starts has increased in all runtimes. Container cold start refers to the process of creating a container from scratch. The speed of container cold start affects user experience.

[0029]

[0029] However, image applications increase the cold start time of serverless applications due to image pulling and image starting actions, and users can feel the increase in end-to-end delay caused by cold start. Especially for large concurrent real-time elastic scenarios, the cold start caused by image data pulling will seriously affect user request performance, which is unacceptable to some delay-sensitive users.

[0030]

[0030] Another scenario is for small image applications. Due to the cold start delay overhead of the serverless system side and the limitations of P2P (Peer-to-Peer, Peer-to-Peer) image acceleration itself, the average fluctuation of the initial call cold start of the test image helloworld image will reach 2 to 3 seconds, which will cause the experience of new users or user test scenarios to be not very friendly.

[0031]

[0031] At the same time, due to the particularity of the life cycle of the serverless instance, the execution node will be periodically rotated in some scenarios. For security reasons, the image data disk is not reused after rotation, which causes there to be no inventory of image data on the new machine after rotation. Then the function image scheduled to the node will pull the image data again, which will cause the delay fluctuation of the cold start request.

[0032]

[0032] There are some P2P-based smart mirroring and file distribution tools in the related art. It aims to improve the efficiency and rate of large-scale file transmission, and maximize the utilization of network bandwidth. It is widely used in application distribution, cache distribution, log distribution, and mirror distribution. The mirror acceleration inside the byte is also built based on this open source solution. However, these tools only solve the problem of mirror P2P transmission, and do not optimize the cold start time of mirror download and decompression. This way is only a temporary solution in the Serverless scenario, and still has a high cold start delay. And these tools do not solve the problem of mirror data cache miss.

[0033] There are also some Kubernetes (a container management platform) native distributed data set orchestration and acceleration engines, mainly serving data-intensive applications in cloud-native scenarios. The specific principle is to realize the caching of data in the underlying storage system on the memory or hard disk of the computing node through the cache acceleration engine to solve the problem of data transmission bandwidth limitation and underlying storage bandwidth and transmission capability limitation in the separation of computing and storage architecture. These tools provide cache data affinity scheduling capabilities, and Kubernetes can refer to the cache when scheduling tasks to allocate scheduling strategies. However, these tools mainly target machine learning data sets and do not provide cache and acceleration for container image data, and cannot achieve the acceleration capability of general container images.

[0033]

[0034] Based on this, the container cold start solution provided by the embodiments of the present specification can improve the speed of container cold start. Next, the embodiments of the present specification will be described in detail.

[0034]

[0035] The container of the present embodiment runs on a node in a node cluster, and the node in the node cluster adopts P2P network networking. The types of nodes in the P2P network include a root node and peer nodes managed by the root node. The root node and the managed peer nodes can communicate with each other. As shown in FIG. 2A, FIG. 2A is a flowchart of a container startup method according to an exemplary embodiment of the present specification. The method can include the following steps.

[0035]

[0036] In step 202, in response to receiving a preheating request for a target container for cold start, at least one preheating node is selected from the node cluster, and the preheating node obtains the image data of the target container from the image repository and stores it locally.

[0036]

[0037] In step 204, in response to receiving the cold start request of the target container, a target node is selected from the node cluster by using the selection strategy prioritized by the preheating node, the target node firstly attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain the pre-stored image data of the target container through a communicable node, and in the case of unsuccessful acquisition, obtains the image data of the target container through the image repository, and finally starts the target container by using the obtained image data of the target container.

[0037]

[0038] The container starting method of the embodiment can be applied to any computer device, including but not limited to a single server, a server group composed of multiple servers, or a cloud composed of a large number of hosts or servers based on cloud computing, etc. The embodiment method can be applied in various architectures, such as a Serverless architecture. Optionally, when the container starting method of the embodiment is executed, the above-mentioned process can be executed by the master node capable of managing the node cluster, for example, applied in the existing scheduling component in the container scenario; in other examples, part of the process can be executed by the scheduling component, and part of the process can be executed by other components cooperating with the scheduling component, and the embodiment does not limit this.

[0038]

[0039] As an example, the image repository can be used to store and distribute images, and can also provide an external calling interface. The embodiment does not limit the storage mode of the image data in the image repository. As an example, the image data in the image repository can be stored in the form of being divided into at least two image blocks (Blob).

[0040] The image data of the container stored in the image repository can be provided by the user. As an example, the user can create the image data of an application and send it to the image repository for storage. There can be various ways for the preheating request acquisition mode in step 102, for example, the preheating request can be determined to be received after detecting that the user uploads the image data, the preheating request can be generated after each user uploads each image data, or the preheating request can be generated after some users upload some image data, and the embodiment does not limit this. Alternatively, it can also be dependent on the detection of application traffic. The traffic of the container is periodically detected, and the preheating in the background can be triggered actively before the traffic is found to rise.

[0039]

[0041] In some examples, the node types in the P2P network can include a root node Root and a peer node Peer. As an example, one or more data centers can be constructed, and the Root node in each data center can run a P2P module named Root, which plays the role of a root of a topology tree. The Root node can manage at least one Peer node, and the Peer node can run a P2P module named Agent. The Root node is responsible for obtaining data from a registry to a local persistent cache, and managing the nodes of the topology tree within its data center. As shown in FIG. 2B, a schematic diagram of a P2P network according to an example embodiment of the present specification is shown. In FIG. 2B, three Root nodes are included: Root-1, Root-2, and Root-3, and each Root node can manage one or more Peer nodes, and a Peer node can be managed by one or more Root nodes. The Root nodes can communicate with the managed Peer nodes, and the Peer nodes managed by a Root node can also communicate with each other. The Root nodes can also communicate with a mirror repository.

[0040]

[0042] As an example, various selection strategies can be set to select one or more preheating nodes from the node cluster, and the number of preheating nodes can be set according to actual needs, which is not limited in the present embodiment. For the selected preheating nodes, the image data of the target container can be pre-acquired and stored locally. In actual applications, the process of selecting the preheating nodes can be performed by the scheduling end shown in FIG. 1, or can be performed by the management end of the P2P network instructed by the scheduling end. The management end of the P2P network and the scheduling end can be two different components, or can be the same component, which is not limited in the present embodiment.

[0041]

[0043] For step 204, the initiation mode of the start request of the target container can be initiated by the user, or can be initiated by the cloud computing service party after determining that the target container needs to be started through some strategies, which is not limited in the present embodiment. Since the node cluster can include a large number of nodes, in the container scenario, when scheduling a node to start a container, there can be many factors affecting the scheduling strategy, such as resource limitations, changes in node states, or conflicts between scheduling rules, etc., which do not necessarily guarantee that the container can be scheduled to a specific node. Therefore, the preheating node selection strategy is adopted in the present embodiment to select the target node for starting the target container from the node cluster, but in actual applications, it cannot be guaranteed that the target node is the preselected preheating node.

[0042]

[0044] If the target node is a preheating node, the target node can directly start the container quickly by directly using the locally stored image data. The target node can also not be a preheating node, and due to the above networking mode, for the selected target node, the target node is designed to first try to obtain the pre-stored image data of the target container from the local, then try to obtain the pre-stored image data of the target container through the communicable node, and in the case that the image data is not successfully obtained, the image data of the target container is obtained through the image warehouse, and finally the target container is started by using the obtained image data of the target container. Therefore, the above networking mode can make the target node try to obtain the image data from the communicable node, so there is a certain probability that the image data can be obtained from other nodes, avoiding obtaining from the remote image warehouse. Among them, the way in which the target node obtains the image data from the image warehouse is not limited in this embodiment, the target node can have the ability to communicate with the image warehouse, and the target node can directly pull data from the image warehouse, or the target node can realize the pulling of the image data through other nodes that can communicate with the image warehouse. Finally, the target container is started by using the obtained image data of the target container.

[0043]

[0045] In some examples, the image warehouse can store image blocks obtained by dividing the image data of the target container; and selecting at least one preheating node from the node cluster, and obtaining, by the preheating node, the image data of the target container from the image warehouse and storing the image data locally, can include: selecting at least two preheating nodes from the node cluster, and storing, by the selected at least two preheating nodes, the image blocks of the image data of the target container provided by the image warehouse in a distributed manner.

[0044]

[0046] As an example, the image warehouse can implement fine-grained management of image data in a block storage manner. The number of image blocks obtained by dividing an image data can be determined according to the size of the image data, the management granularity of the block storage, or the division rule, and the like, and this embodiment is not limited thereto.

[0045]

[0047] As an example, this embodiment stores multiple (at least two) image blocks of the image data of the target container on at least two preheating nodes in a distributed manner, which can ensure the safety of the image data; and selecting multiple preheating nodes can improve the probability of being selected as a target node during scheduling.

[0046]

[0048] As an example, the number of pre-warming nodes can be the same as the number of mirror blocks, and each pre-warming node can store one of the mirror blocks. The number of pre-warming nodes can also be less than the number of mirror blocks, and these mirror blocks can be distributed and stored on each pre-warming node as needed. The number of pre-warming nodes can also be greater than the number of mirror blocks, and some mirror blocks can be redundantly stored on multiple pre-warming nodes. As an example, the pre-warming nodes used to distribute and store multiple mirror blocks can be peer nodes under the same root node.

[0047]

[0049] Since the mirror data is divided into multiple mirror blocks and distributed and stored, when selecting a target node for starting a container, the selected target node can be one of the pre-warming nodes, and the target container can successfully obtain part of the mirror blocks of the mirror data locally. Other mirror blocks can be obtained by the target node from other nodes to obtain other mirror blocks of the mirror data of the target container. For example, the target node can determine the pre-warming nodes that store other mirror blocks, and then obtain other mirror blocks from these pre-warming nodes. Alternatively, the target node can obtain other mirror blocks through the mirror repository. The target node can directly communicate with the mirror repository, or the target node can obtain other mirror blocks through other nodes that can communicate with the mirror repository.

[0050] The above embodiments are described by taking the mirror data as mirror blocks and the mirror blocks distributed and stored in pre-warming nodes as an example. In other examples, the pre-warming nodes can also store the entire mirror data, which can improve the speed of container startup. In actual applications, appropriate methods can be selected as needed, for example, some mirror data can be distributed and stored in mirror blocks, and some mirror data can be stored in the entire mirror data. The present embodiment does not limit this.

[0048]

[0051] In some scenarios, how to select the preheat nodes and how many to select can be a problem to be considered. If too few are selected, cache misses can occur; if too many are preheated, the risk of high disk water level can occur. As an example, selecting at least one preheat node from the node cluster can include: selecting at least two peer nodes managed by the same root node from the node cluster as preheat nodes; the target node first attempts to obtain pre-stored image data of the target container locally, and then attempts to obtain the image data of the target container through the communicable nodes, and in the case of unsuccessful acquisition, obtains the image data of the target container through the image repository, can include: the target node first attempts to obtain pre-stored image data of the target container locally; in the case of unsuccessful acquisition locally, it communicates with other communicable peer nodes to determine whether the image data of the target container can be obtained from other communicable peer nodes; and in the case of failure to obtain from other peer nodes, the root node obtains the image data of the target container from the image repository.

[0049]

[0052] In this embodiment, at least two peer nodes under the same root node can be used as preheat nodes, and the number of preheat nodes can be configured as needed. In this way, the selected at least two preheat nodes under the same root node can communicate with each other. In this scheme, if the target node does not store the image data (here it is not limited to the whole data or the image block), the target node can first attempt to communicate with other peer nodes to determine whether the image data of the target container can be obtained from other peer nodes. If not, the root node can be used to obtain the image data of the target container from the image repository. If the target node is a preheat node and the target node stores part of the image block of the image data, since multiple peer nodes under the same root node are selected, other image blocks can be obtained from other communicable peer nodes with high probability. Therefore, the above-mentioned way of this embodiment improves the speed of container startup.

[0050]

[0053] In other examples, other pre-warming node selection manners can also be used. For example, the selecting at least one pre-warming node from the node cluster can include: selecting at least one root node from the node cluster as a pre-warming node, and selecting at least one peer node from the peer nodes managed by the selected root node as a pre-warming node; the attempting by the target node to obtain the pre-stored image data of the target container first locally and then through the communicable node can include: attempting by the target node to obtain the pre-stored image data of the target container first locally; in the case of unsuccessful local obtaining, requesting the image data of the target container through the root node to which the node belongs; wherein the root node attempts to obtain the pre-stored image data of the target container first locally, and in the case of unsuccessful obtaining, obtains the image data from the image repository.

[0051]

[0054] The pre-warming node selection manner of the embodiment can be to select at least one root node, and select at least one peer node from all the peer nodes managed by the root node as a pre-warming node. The number of the selected root node and peer node as pre-warming nodes can be set as needed. As an example, the root node can be one, and the peer nodes can be multiple. The number of peer nodes can be set according to the number of nodes, for example, 30% of the number of nodes can be selected as pre-warming nodes.

[0052]

[0055] Through the above embodiment, in the part of the sub-nodes of the tree composed of the root, if the affinity cache is not hit, data can be directly obtained from the root node storing the image data through P2P transmission, avoiding the consumption of directly pulling from the image repository. Because the leaf node is selected as a pre-warming node on the tree, when the pre-warming node is not selected as the target node of the starting container, the leaf node can request data from the root node.

[0053]

[0056] Optionally, in some examples, after the root node requests the image data, the root node can also distribute the image data to all or part of the sub-nodes managed by the root node according to needs, which can improve the probability of subsequent scheduling success.

[0054]

[0057] As an example, in actual applications, the manner of selecting the root node can be various, and the embodiment is not limited in this regard. As an example, as shown in FIG. 2B, a user identifier can be hashed to select a corresponding root node Root-3 as a preheating node from all root nodes of the node cluster, and then a Peer node is selected as a preheating node from a plurality of Peer nodes managed by Root-3. In other examples, when the mirror data is large, the preheating node can also be selected from a plurality of root nodes.

[0055]

[0058] In some other examples, the preheating node can also be selected in combination with a resource water level. For example, the selecting at least one preheating node from the node cluster can include: selecting at least one preheating node from the node cluster according to a resource occupancy rate of a node in the node cluster; and wherein the resource occupancy rate of the node is in a negative correlation with a probability of being selected as the preheating node.

[0056]

[0059] As an example, the resource herein can include a combination of one or more of the following resources: a processor CPU, a memory, a disk, and the like. The resource occupancy rate can refer to a proportion of a capacity of the resource that is used. The resource occupancy rate of the node is in a negative correlation with the probability of being selected as the preheating node. In actual applications, the specific relationship between the resource occupancy rate and the probability of being selected as the preheating node can be flexibly set as needed, and the embodiment is not limited in this regard.

[0057]

[0060] As an example, the scheduling end for selecting the preheating node according to the embodiment can obtain a mirror data preheating state result of each node in the node cluster, i.e., which containers of the mirror data are preheated by each node, so that the preheating node can be selected based on the mirror data preheating state result of each node in the node cluster.

[0058]

[0061] Therefore, by the above manner, the node with a lower resource occupancy rate is more likely to have sufficient idle resources to store and provide the mirror data, and is also more likely to be selected as the preheating node, thereby preventing some nodes from being preheated too much and causing a high water level risk of the disk, and also avoiding the generation of hot spots and uneven loads as much as possible.

[0059]

[0062] In some examples, after the step of selecting at least one preheating node from the node cluster, the method can further include: configuring an affinity label corresponding to the target container for the preheating node; and the selecting strategy of preferentially selecting the preheating node can include: using an affinity scheduling strategy to preferentially select the target node having the affinity label from the node cluster.

[0060]

[0063] In some existing container orchestration platforms, a node or a pod can be regarded as a resource object, and the resource object can be defined or described by using a definition file. For example, a definition file of a node can be submitted, so that the master node can obtain the information of the node defined in the definition file after receiving the definition file of the node. A definition file of a pod can be submitted, so that the master node can create the pod and schedule the pod to a certain node for running after receiving the definition file of the pod. One or more attributes of the resource object, such as a name, a label, a number of replicas, a CPU limit, a memory limit, or a storage volume, can be defined in the definition file of the pod. One or more attributes of the node, such as a label, address information, resource information, a taint, or an annotation, can be defined in the definition file of the node.

[0061]

[0064] In this embodiment, the selecting strategy of preferentially selecting the preheating node can be implemented by using affinity scheduling. An affinity label of a node and a container can be set by defining an affinity rule of the pod, and the affinity rule allows the pod to run on a node having a specific label. For example, the image of the container A is preheated on a node, and in order to preferentially enable the container A to start on the node, an affinity label of the preheating node can be customized, and the specific content of the affinity label can be flexibly configured according to actual needs, which is not limited in this embodiment. In actual application, the image data of one or more containers can be preheated on the preheating node, and therefore the preheating node can have one or more affinity labels of the containers.

[0062]

[0065] Next, in the definition file of the pod of the container A, an affinity nodeAffinity field can be used to set the affinity rule, and the rule can specify that the container A preferentially runs on a node having the above-mentioned affinity label. Therefore, by using the affinity scheduling, the preheating node having the affinity label corresponding to the container A can be preferentially selected when the node is selected to run the container A.

[0063]

[0066] In actual application, if there is not enough resource on the preheating node to start container A, or container A cannot be scheduled to start on the preheating node due to other reasons (such as node failure), the scheduling component in the container management platform can also schedule container A to other nodes.

[0064]

[0067] In actual application, when selecting the target node, other strategies can also be combined for selection. For example, the selection strategy of preheating node priority selection for selecting the target node from the node cluster can include: selecting a candidate node set that meets the resource requirement of the start request and whose resource occupancy rate meets a normal condition from the node cluster; and the selection strategy of preheating node priority selection for selecting the target node from the candidate node set.

[0065]

[0068] In some examples, the resource requirement information of the container to be started can be carried in the start request of the user, such as CPU information, memory information, and / or disk information, and the like. The specific resource requirement information can have different implementation manners according to actual needs, which are not limited in the embodiment. Based on this, in the embodiment, a node set that currently meets the container creation requirement and whose resource occupancy rate meets a normal condition can be selected from the node cluster. For example, the normal condition can be a condition that indicates that the resource occupancy rate of the node meets a set normal resource occupancy rate after the node preheats the image data. The normal condition can have various different implementation manners according to actual needs, which are not limited in the embodiment. The selected candidate set can include one or more nodes. Then, the selection strategy of preheating node priority selection and the selection strategy of resource average allocation can be combined to select one or more target nodes from the candidate node set.

[0066]

[0069] The priority of the selection strategy of preheating node priority selection and the selection strategy of resource average allocation can be configured according to needs. For example, the priority of the selection strategy of preheating node priority selection can be higher, so that in the case of current node resource shortage, resource is prioritized instead of image affinity, which can reduce the probability of affinity. Alternatively, the priority of the selection strategy of resource average allocation can be higher, which can improve the probability of affinity hit, but can more easily cause a “hot spot”. For example, a sudden increase in the concurrency of container creation can cause a CPU hot spot of the node, which can affect other users of the node.

[0067]

[0070] In some examples, the root node is connected to a scheduling end and a management end of the P2P network respectively; the management end and the scheduling end have a communication channel; the method is applied in the scheduling end; the method further includes: recording a preheating state of the mirror image data of the target container sent by the preheating node of the management end in a preset preheating state data; in response to a first preheating node in the preheating state data satisfying a preset rescheduling condition, sending an elimination request of the first preheating node to the management end, so that the management end informs the first preheating node to delete the mirror image data of the first target container stored by the node through the root node after receiving the elimination request, and reselects a preheating node to store the mirror image data of the first target container.

[0068]

[0071] In the embodiment, a bidirectional flow communication can be introduced between the management end and the scheduling end, the preheating state of the mirror image data can be pushed to the scheduling end in real time through the data flow, and the scheduling end can determine whether to perform the mirror image data rescheduling according to the need. The preset rescheduling condition is used to indicate whether the preheating node is in resource shortage, which can be a condition indicating whether the resource occupancy rate of the node is higher than a set resource occupancy rate. The rescheduling condition can have various implementation manners according to the actual need, which is not limited in the embodiment.

[0069]

[0072] For example, the resource usage of each preheating node can be monitored, if it is found that some preheating nodes in the preheating state data satisfy the preset rescheduling condition, which is referred to as a first preheating node in the embodiment, the first preheating node can perform the elimination operation of the mirror image data, can directly send a notification to the management end, and informs the first preheating node to delete the mirror image data of the first target container stored by the node through the root node, and can reselect a preheating node to store the mirror image data of the first target container. Based on this, the embodiment can adopt the logic of “mirror image data rescheduling”, and the preheating node in resource shortage can be actively removed by dynamically obtaining the resource occupancy of the node, and a node with low current resource level is reselected for data preheating.

[0070]

[0073] In other examples, the preheating node can be used to store the mirror image data of one or more containers; the method can further include: obtaining a resource occupancy rate of the preheating node; in response to the resource occupancy rate of the preheating node satisfying a preset rescheduling condition, selecting and deleting one or more affinity labels corresponding to the preheating node, and deleting the mirror image data of the container corresponding to the selected affinity label.

[0071]

[0074] The embodiment can be understood as a rescheduling strategy of the mirror image data. For the selected preheating node, the embodiment can continuously obtain the resource occupancy of the preheating node, so as to determine a condition indicating whether the preheating node will appear resource shortage. The preset rescheduling condition used to indicate whether the preheating node will appear resource shortage can be a condition indicating whether the resource occupancy of the node is higher than the set resource occupancy. The rescheduling condition herein can have various implementation manners according to actual needs, and the embodiment does not limit this.

[0072]

[0075] If it is found that the preheating node appears resource shortage, the affinity label corresponding to one or more containers in the preheating node can be deleted, and the corresponding mirror image data is also deleted.

[0073]

[0076] For example, the preheating node stores the mirror image data of the container A, the container B and the container C respectively. The preheating node is configured with the affinity label corresponding to the container A, the affinity label corresponding to the container B and the affinity label corresponding to the container C. If it is found that the preheating node appears resource shortage, for example, the CPU increases due to sudden traffic or the number of concurrent instance creation increases and the like, the affinity label of one of the containers can be deleted according to needs, and the mirror image data of the container is also deleted. For example, as shown in FIG. 2C, a preheating node list of the preheating node in which the mirror image data is preheated can be obtained, the list includes various preheating nodes, and the preheating node in which resource shortage exists can be found based on this. For example, in the figure, the node is taken as an example in a square, and the CPU resource occupancy is high, so that the affinity label of part or all of the containers is selected and deleted.

[0074]

[0077] The selected container to be removed from the preheating node can be configured according to needs, for example, the starting frequency of the container in the recent period of time can be determined, for example, some containers with low mirror image data access frequency can be preferentially selected, or the size of the mirror image data of the container can be determined, and the like.

[0075]

[0078] Optionally, after the selected container is removed from the preheating node, other preheating nodes can also be selected to preheat the removed container according to needs. For example, when the operation of deleting the affinity label of the target container stored in the preheating node and deleting the mirror image data of the target container is performed, the preheating request of the target container can be triggered, so that the step of selecting at least one preheating node from the node cluster is re-executed. For example, as shown in FIG. 2C, a new preheating node is selected to preheat the mirror image data, and the preheating node reselected will add the affinity label of the container.

[0076]

[0079] As can be seen from the above embodiments, due to the characteristic of affinity scheduling being to schedule as much as possible rather than to force scheduling, this embodiment adopts the logic of "mirror data rescheduling". By dynamically obtaining the resource occupancy of nodes, preheating nodes with tight resources can be actively removed, and nodes with low current resource levels can be selected for data preheating. This can avoid affinity failures caused by node resource issues, thereby improving the cache hit rate.

[0077]

[0080] In other examples, the image data stored on each preheating node can be managed more proactively. For instance, the scheduling component executing this embodiment can detect instance deletion and count the number of requests to instances. Therefore, it can proactively manage the resource level of the preheating node, such as disk level, to avoid disk pressure on the node caused by preheating too many images. For example, the access status of each image data stored on the preheating node can be obtained. For example, the timestamps of the K most recent accesses can be proactively or, under the aforementioned resource shortage, the image data with the oldest K most recent access time can be prioritized for eviction. K can be set according to actual needs, and this embodiment does not limit it. The above-mentioned image data deletion approach is similar to the Least Recently Used K (LRU-K) replacement algorithm in the cache eviction field, and is similar to the traditional Least Recently Used algorithm.

[0078] Compared to Least Recently Used (LRU), the LRU-K algorithm is more suitable for scenarios such as Serverless request scheduling. For example, in some sparse call scenarios, such as Serverless asynchronous requests or tasks, the requests are not continuous but intermittent. Prioritizing the elimination of the image with the oldest access time in the last K times can better remove image data with low usage probability.

[0079]

[0081] Figure 2D illustrates an application scenario for container startup according to an exemplary embodiment of this specification. The figure shows two processes: a control process, i.e., the preheating process; and a cold start data flow, i.e., the process of starting the container. As an example, the figure shows the following components:

[0080]

[0082] ① Gateway component API-Server;

[0081]

[0083] The gateway component can be responsible for receiving and forwarding requests to other components; for example, receiving a request to build a new container or update the image of a container; it can also receive a container startup request.

[0082]

[0084] ②State management component EERouter, responsible for routing requests to instances;

[0083]

[0085] For example, a cold start instruction, i.e. a container startup request, can be sent to the resource scheduling component Placement (i.e. the aforementioned scheduling end), so as to create a new instance.

[0084]

[0086] ③Resource scheduling component Placement, responsible for binding instances to nodes, and can be responsible for affinity scheduling and rescheduling logic in this embodiment.

[0085]

[0087] P2P management component P2P-Manager (i.e. the aforementioned management end), responsible for maintaining the P2P networking relationship of the node cluster, and issuing commands to P2P-Deamon

[0086]

[0088] ⑤P2P node component P2P-Deamon, responsible for collecting node information and executing related P2P instructions.

[0087]

[0089] ⑥Image conversion service Image-Converter, used for converting user image data.

[0088]

[0090] ⑦Image repository service, used for storing the converted image data to the image repository.

[0089]

[0091] ⑧P2P agent module P2P-Agent, running in each node, responsible for executing the instructions issued by the P2P management component.

[0090]

[0092] As shown in FIG. 2E, it is a container image data preheating process diagram according to an exemplary embodiment of the present specification, which can include the following processes.

[0093] 1.1, the gateway component API-Server sends a preheating processing credential prewarmAccIImage (Credential) to the management component P2P-manager of the P2P system.

[0091]

[0094] 1.2 P2P-manager invokes the service interface API of the mirror repository, and can send a request getRepoTagManifest ACREE to obtain the description information of the mirror.

[0092]

[0095] 1.3 P2P-manager selects a node for pulling data (that is, selects one or more preheating nodes for pulling data from the P2P network).

[0093]

[0096] 1.4: P2P-manager requests the object storage service OSS to obtain the storage address of the signed mirror data signedURL.

[0094]

[0097] 1.5: P2P-manager issues a mirror data pulling plan to the selected node P2P-deamon.

[0095]

[0098] 1.5.1: P2P-deamon sends a mirror data pulling request to the object storage service.

[0096]

[0099] 1.5.2: Pull the mirror data from the OSS.

[0097]

[0100] 2. P2P-manager pushes the mirror data preheating state result to Placement.

[0098]

[0101] 2.1: Placement updates the distribution of the mirror data of the node in the memory.

[0099]

[0102] 3. API-Server sends an Invoke cold start CreateContainer request to Placement:

[0100]

[0103] 3.1: Consider the distribution of the node preheating data in the scheduling logic.

[0101]

[0104] As can be seen from the above embodiment, based on the characteristics of the mixed storage and computing nodes of the Serverless, the mirror data is preheated and cached on the computing node in advance, the computing node can achieve a near-local mirror pulling speed, and the additional cold start time of the Serverless platform side is eliminated, which has a good effect on user experience and performance.

[0102]

[0105] The preheating operation of the embodiment does not introduce additional machine storage costs, and compared with the Kubernetes architecture, the Serverless architecture can perceive traffic requests of an application, the embodiment can discard image data that has not been requested for use for the last K times through an LRU-K algorithm, is more suitable for a Serverless application scenario, and can further improve the utilization rate of node disk resources.

[0103]

[0106] Compared with the Kubernetes architecture, the embodiment can implement management of image cache data in a block granularity, and further proposes a logic of "image data rescheduling", which can reschedule image data to a node with a lower CPU and memory water level, so that the next time a cold start scheduling instance is scheduled to the node with the image data, the probability of hitting the cache is further improved, and the cold start probability is reduced.

[0104]

[0107] Compared with image preheating and affinity scheduling under the Kubernetes architecture, the embodiment can fully utilize the characteristics of P2P node networking, and is more flexible in selection of preheating nodes and control of scheduling strategies; for example, the weight of the preheating node can be set according to the current cluster node P2P networking structure when the preheating node is selected, so that the embodiment can achieve a better balance between resource utilization and improvement of affinity hit rate, and can solve the problem of uneven resource utilization caused by image affinity under the Kubernetes architecture.

[0105]

[0108] The embodiment of the present specification further provides another container cold start method, which can be applied to a node in the node cluster, and the method can include: in response to receiving a preheating node of image data of a target container, obtaining the image data of the target container through an image repository and storing the image data locally; in response to receiving a cold start request of the target container, first attempting to obtain the pre-stored image data of the target container from the local, then attempting to obtain the image data of the target container through a communicable node, and in the case that the image data of the target container is not successfully obtained, obtaining the image data of the target container through the image repository, and finally starting the target container by using the obtained image data of the target container.

[0106]

[0109] The embodiment method can refer to the description of the foregoing embodiments, and will not be described here.

[0107]

[0110] Corresponding to the foregoing embodiments of the container cold start method, the present specification further provides embodiments of a container cold start device and a computer device to which the container cold start device is applied.

[0108]

[0111] The embodiments of the container cold start apparatus in the specification can be applied to a computer device, such as a server or a terminal device. The apparatus embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a logically meaningful apparatus, it is formed by reading corresponding computer program instructions in the non-volatile memory into the memory for running by the processor where it is located. From the hardware level, as shown in FIG. 3, it is a hardware structure diagram of a computer device where the container cold start apparatus in the specification is located. In addition to the processor 310, the memory 330, the network interface 320, and the non-volatile memory 340 shown in FIG. 3, the computer device where the container cold start apparatus in the embodiments is located can also include other hardware according to the actual functions of the computer device, which will not be described here.

[0109]

[0112] As an example, a container cold start apparatus can include: a preheating module configured to: in response to receiving a preheating request for a target container for cold start, select at least one preheating node from the node cluster, and cause the preheating node to obtain image data of the target container from a mirror repository and store the image data locally; and a scheduling module configured to: in response to receiving a cold start request for the target container, select a target node from the node cluster using a selection strategy in which preheating nodes are given priority, cause the target node to attempt to obtain pre-stored image data of the target container from the local storage, and in the case that the target node fails to obtain the image data from the local storage, obtain the image data of the target container from the mirror repository, and finally start the target container using the obtained image data of the target container.

[0110]

[0113] The implementation processes of the functions and roles of the modules in the above container cold start apparatus are specifically described in the implementation processes of the corresponding steps in the above container cold start method, which will not be described here.

[0111]

[0114] Correspondingly, the embodiments of the specification also provide a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above container cold start method embodiments.

[0112]

[0115] Correspondingly, the embodiments of the specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the container cold start method embodiments when executing the program.

[0113]

[0116] Correspondingly, the embodiments of the present specification also provide a computer readable storage medium, having stored thereon a computer program, the computer program being executed by a processor to implement the steps of the container cold start method embodiment.

[0114]

[0117] For the device embodiment, since it basically corresponds to the method embodiment, the relevant part is described in the part of the method embodiment. The device embodiment described above is only schematic, and the modules described as separate components can or can not be physically separate, and the components displayed as modules can or can not be physical modules, i.e. can be located in one place, or can be distributed on multiple network modules. Part or all of the modules can be selected to achieve the purpose of the present specification according to actual needs. Those skilled in the art can understand and implement it without creative labor.

[0115]

[0118] The above embodiments can be applied to one or more computer devices, which are devices capable of automatically performing numerical calculation and / or information processing according to pre-set or stored instructions. The hardware of the computer device includes but is not limited to microprocessors, application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), digital signal processors (DSP), embedded devices, etc.

[0116]

[0119] The computer device can be any electronic product that can interact with the user, such as a personal computer, a tablet computer, a smart phone, a personal digital assistant (PDA), a game machine, an interactive Internet Protocol Television (IPTV), a smart wearable device, etc.

[0117]

[0120] The computer device can also include a network device and / or a user device. The network device includes, but is not limited to, a single network server, a server group composed of multiple network servers, or a cloud composed of a large number of hosts or network servers based on cloud computing.

[0118]

[0121] The network in which the computer device is located includes, but is not limited to, the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (VPN), and the like.

[0119]

[0122] The above-described embodiments of the present specification are described, and other embodiments are within the scope of the appended claims. In some cases, the acts or steps in a claim can be performed in an order different from embodiments, and still achieve the desired result. Also, the process depicted in the figures does not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous or possible.

[0120]

[0123] The division of steps in the above various methods is only for the purpose of clear description, and when implemented, some steps can be combined into one step or some steps can be split and decomposed into multiple steps, as long as the same logical relationship is included, which is within the protection scope of the present patent; adding insignificant modifications or introducing insignificant designs in the algorithm or process, but not changing the core design of the algorithm and process, are within the protection scope of the present application.

[0121]

[0124] Although the present specification contains many specific implementation details, these should not be construed as limiting the scope or the range of any invention, but merely as describing specific embodiments of the particular invention. Some features described in the present specification in connection with one embodiment can also be combined with features described in connection with a different embodiment. On the other hand, various features described in connection with a single embodiment can also be separated from that embodiment and employed with other embodiments. Furthermore, while features can have been described above as belonging to one or more embodiments, features from one embodiment can be employed with another embodiment as appropriate, and vice versa. Processing circuits and engines can also perform functions not specifically described in connection with an embodiment, but nevertheless properly fall within the scope of the claims.

[0122]

[0125] Where a term is introduced as "in some examples," or "in some embodiments," or the like, it is intended to mean that the feature so described can be present in some embodiments, but not necessarily in others. In other words, the description is not intended to be limiting, and the described features are not intended to be exclusive of other features that can be present in some embodiments.

[0123]

[0126] Other embodiments of this specification will be apparent to those of ordinary skill in the art from a consideration of the specification and practice of the inventions disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.

[0124]

[0127] It is to be understood that the specification is not limited to particular

[0125]

[0128] The foregoing is considered as illustrative only of the principles of the specification. Other variations and modifications of the specification herein disclosed can be carried out by those skilled in the art, which fall within the scope of the specification, which is to be determined by the broadest permissible interpretation of the following claims.

Claims

CLAIM 1. A container cold start method, the container running on a node in a node cluster, the nodes in the node cluster adopting a P2P network for networking, the types of nodes in the P2P network including a root node and peer nodes managed by the root node, the root node and each of the managed peer nodes being communicable, the method comprising: in response to receiving a preheating request for a target container for cold start, selecting at least one preheating node from the node cluster, and obtaining, by the preheating node, image data of the target container through a mirror repository and storing the image data locally; in response to receiving a cold start request for the target container, selecting a target node from the node cluster using a selection strategy in which preheating nodes are given priority, attempting, by the target node, to obtain pre-stored image data of the target container first locally and then through a communicable node, and in the case of unsuccessful obtaining, obtaining the image data of the target container through the mirror repository, and finally starting the target container using the obtained image data of the target container.

2. The method of claim 1, wherein the root node is connected to a scheduling end and a management end of the P2P network, respectively. The control end and the scheduling end have a communication channel; The method is applied to the scheduling end; The method further comprises: recording, in a preset preheating state data, a preheating state of the preheating node for the image data of the target container sent by the control end; In response to a first preheating node in the preheating state data satisfying a preset rescheduling condition, sending an elimination request for the first preheating node to the control end, so that the control end, after receiving the elimination request, notifies the first preheating node to delete the image data of a first target container stored by the node through the root node, and reselects a preheating node to store the image data of the first target container.

3. The method according to claim 1, wherein the image repository stores image blocks obtained by splitting the image data of the target container; the step of selecting at least one preheating node from the node cluster, and having the preheating node obtain the image data of the target container from the image repository and store it locally, includes: Selecting at least two preheating nodes from the node cluster, and dispersively storing, by the selected at least two preheating nodes, image blocks of the image data of the target container provided by the mirror repository.

4. The method of claim 1 or 3, wherein the selecting at least one pre-warmed node from the cluster of nodes comprises: Selecting at least two peer nodes managed by the same root node from the node cluster as preheating nodes; The attempting, by the target node, to obtain pre-stored image data of the target container first locally and then through a communicable node, and in the case of unsuccessful obtaining, obtaining the image data of the target container through the mirror repository, comprises: the target node first attempts to obtain the pre-stored image data of the target container locally, and then attempts to obtain the image data of the target container from other communicable peer nodes in case of unsuccessful local obtaining, and in case of failure to obtain from other peer nodes, obtains the image data of the target container from the image repository through the root node; or, selecting at least one pre-warmed node from the node cluster, comprising: selecting at least one root node from the node cluster as a pre-warmed node, and selecting at least one peer node from the peer nodes managed by the selected root node as a pre-warmed node; the target node first attempts to obtain the pre-stored image data of the target container locally, and then attempts to obtain the image data of the target container from other communicable peer nodes in case of unsuccessful local obtaining, and in case of failure to obtain from other peer nodes, obtains the image data of the target container from the image repository through the root node; wherein, the root node first attempts to obtain the pre-stored image data of the target container locally, and then requests the image data of the target container from the image repository in case of unsuccessful local obtaining.

5. The method of claim 1, wherein the selecting at least one pre-warmed node from the cluster of nodes comprises: According to the resource occupancy rate of the nodes in the node cluster, at least one pre-warmed node is selected from the node cluster; The resource occupancy rate of the node is negatively correlated with the probability of being selected as a pre-warmed node.

6. The method of claim 1, after the step of selecting at least one warm node from the cluster of nodes, the method further comprising: The pre-warmed node is configured with an affinity label corresponding to the target container. The selection strategy of giving priority to pre-warmed nodes is used to select a target node from the node cluster, comprising: using an affinity scheduling strategy to attempt to preferentially select a target node with the affinity label from the node cluster.

7. The method of claim 6, the preheat node is configured to store image data for one or more containers; the method further comprising: The resource occupancy rate of the pre-warmed node is obtained. In response to the resource occupancy rate of the pre-warmed node meeting a preset rescheduling condition, the affinity label corresponding to one or more containers of the pre-warmed node is selected and deleted, and the image data of the container corresponding to the selected affinity label is deleted.

8. The method of claim 1, wherein the selecting strategy of the preheating node priority selection is used to select a target node from the node cluster, comprising: A candidate node set meeting the resource requirement of the start request and the normal condition of the resource occupancy rate is selected from the node cluster. The selection strategy of giving priority to pre-warmed nodes is combined with the selection strategy of average resource allocation to select a target node from the candidate node set.

9. A container cold start method, the method is applied to a node in a node cluster, the nodes in the node cluster are networked by a P2P network, the types of the nodes in the P2P network include a root node and peer nodes managed by the root node, the root node and the managed peer nodes can communicate with each other, the method comprises: in response to receiving a preheating node of image data of a target container, obtaining the image data of the target container through an image warehouse and storing in the local; in response to receiving a cold start request of a target container, firstly trying to obtain the pre-stored image data of the target container from the local, then trying to obtain the pre-stored image data of the target container through the communicable nodes, and in the case of unsuccessful acquisition, obtaining the image data of the target container through the image warehouse, and finally starting the target container by using the obtained image data of the target container.

10. A container management system, the system comprises a scheduling end and a node cluster, the scheduling end is used to execute the steps of the method in any one of claims 1 to 8, and the nodes in the node cluster are used to execute the steps of the method in claim 9.

11. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 9.

12. A computer program product, comprising a computer program, the computer program is executed by a processor to implement the steps of the method in any one of claims 1 to 9.

13. A computer readable storage medium, having a computer program stored thereon, the computer program is executed by a processor to implement the steps of the method in any one of claims 1 to 9.

Images