Container cold start method, device and system, program product and storage medium

Abstract

The invention provides a container cold start method, device and system, a program product and a storage medium, a container runs on nodes in a node cluster, the node cluster adopts P2P network networking and comprises a root node and peer-to-peer nodes managed by the root node, and the root node and each node in the managed peer-to-peer nodes can communicate with each other. The method comprises the following steps: in response to a received preheating request for a cold-started target container, selecting a preheating node from a node cluster, acquiring mirror image data of the target container by the preheating node, and storing the mirror image data locally; in response to a received cold start request of a target container, selecting a target node by adopting a selection strategy of preferentially selecting a preheating node, trying to obtain pre-stored mirror image data from the local by the target node, trying to obtain the pre-stored mirror image data through a communicable node, and sending the pre-stored mirror image data to the target container under the condition that the pre-stored mirror image data is not successfully obtained. And obtaining the mirror image data of the target container through the mirror image warehouse, and finally starting the target container by utilizing the obtained mirror image data.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, and in particular to container cold start methods, devices, systems, program products and storage media. Background Technology

[0002] Container images have long been the mainstream operating mode for cloud-native applications. In serverless scenarios, for example, serverless application engines can provide a streamlined serverless experience based on container images. In some application scenarios, users are highly sensitive to container startup time; therefore, improving the speed of container cold starts is a pressing technical challenge. Summary of the Invention

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

[0004] According to a first aspect of the embodiments of this specification, a container cold start method is provided, wherein the container runs on nodes in a node cluster, the nodes in the node cluster are networked using a P2P network, the types of nodes in the P2P network include a root node and peer nodes managed by the root node, and the root node and the managed peer nodes can communicate with each other, the method comprising:

[0005] In response to receiving a warm-up request for a target container for cold start, at least one warm-up node is selected from the node cluster, and the warm-up node obtains the image data of the target container through the image repository and stores it locally.

[0006] In response to receiving a cold start request for the target container, a selection strategy prioritizing warm-up nodes is adopted to select a target node from the node cluster. The target node first attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain it through a communicable node. If the attempt fails, the target container's image data is obtained through the image repository. Finally, the target container is started using the obtained image data.

[0007] According to a second aspect of the embodiments of this specification, a container cold start method is provided, the method being applied to nodes in a node cluster, the nodes in the node cluster being networked using a P2P network, the types of nodes in the P2P network including a root node and peer nodes managed by the root node, the root node and the managed peer nodes being able to communicate with each other, the method comprising:

[0008] In response to receiving the image data of the target container from the warm-up node, the image data of the target container is obtained from the image repository and stored locally;

[0009] In response to receiving a cold start request for the target container, the system first attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain it through a communicable node, and if the attempt fails, obtains the image data of the target container through the image repository. Finally, the system uses the obtained image data of the target container to start the target container.

[0010] According to a third aspect of the embodiments of this specification, a container management system is provided, the system including a scheduler and a node cluster, the scheduler being used to execute the steps of the method described in the first aspect, and the nodes in the node cluster being used to execute the steps of the method described in the second aspect.

[0011] According to a fourth aspect of the embodiments of this specification, a computer device is provided, including 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 implement the steps of the method embodiments described in the first or second aspect above.

[0012] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method embodiments described in the first or second aspect above.

[0013] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method embodiments described in the first or second aspect above.

[0014] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0015] In this embodiment, the nodes in the node cluster are networked using 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 its managed peer nodes can communicate with each other. Therefore, upon receiving a warm-up request for a target container to be cold-started, at least one warm-up node can be selected from the node cluster. This warm-up node obtains the image data of the target container from the image repository and stores it locally. Thus, when a cold-start request for the target container is received, a selection strategy prioritizing warm-up nodes can be adopted. The target node can first attempt to obtain the pre-stored image data of the target container locally, then attempt to obtain it through a communicable node, and if unsuccessful, obtain the image data of the target container from the image repository. Finally, the target container is started using the obtained image data. This embodiment, based on the network characteristics of the node cluster, pre-selects warm-up nodes and pre-stores image data. Therefore, when a cold start of a container is needed later, there is a certain probability that a warm-up node will be scheduled, thus improving the speed of container cold starts.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this specification and, together with the specification, serve to explain the principles of this disclosure.

[0018] Figure 1 This is a schematic diagram illustrating a container management scenario according to an exemplary embodiment of this specification.

[0019] Figure 2A This is a flowchart illustrating a container startup method according to an exemplary embodiment of this specification.

[0020] Figure 2B This is a schematic diagram of a P2P network illustrated in this specification according to an exemplary embodiment.

[0021] Figure 2C This is a schematic diagram illustrating the removal of an affinity label according to an exemplary embodiment of this specification.

[0022] Figure 2D This is a schematic diagram illustrating a container startup scenario according to an exemplary embodiment of this specification.

[0023] Figure 2E This is a schematic diagram illustrating a mirror data preheating according to an exemplary embodiment of this specification.

[0024] Figure 3 This specification is a hardware structure diagram of a computer device containing a container startup device according to an exemplary embodiment. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

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

[0027] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0028] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0029] like Figure 1 The diagram shown is a schematic representation of a container management scenario according to an exemplary embodiment of this specification. This container management scenario may include a scheduler and several worker nodes. Figure 1 For the sake of simplicity, only 3 nodes (Node1, Node2, and Node3) are shown in the example.

[0030] The scheduler is used to schedule containers to run on Nodes. The scheduler can occupy one or more independent servers. A set of cluster management processes run on the scheduler, which implement management functions such as resource management, scheduling, elastic scaling, security control, system monitoring, and error correction for the entire cluster.

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

[0032] In some application scenarios, the cloud can launch the required containers from container images when needed, allowing the user to run the necessary processes. A container image is a lightweight, executable software package that contains everything needed to run an application: code, runtime environment, system tools, libraries, and settings. As an example, a user can build an application into a container image based on a Dockerfile and upload it to a container image repository. Then, they can pull the container image and start the container in a test or production environment. In other examples, the user can provide the application code and runtime environment data, and the platform can provide the corresponding container image.

[0033] Container images have long been the mainstream operating mode for cloud-native applications. In serverless scenarios, for example, serverless application engines can provide a streamlined serverless experience 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, with cold starts accounting for a growing proportion of all runtime environments. A container cold start refers to the process of creating a container from scratch. The speed of a container cold start significantly impacts the user experience.

[0034] However, because mirrored applications involve image fetching and startup, they increase the cold start time of serverless applications, resulting in a noticeable increase in end-to-end latency for users. This is especially true for high-concurrency, real-time elastic scenarios, where the cold start caused by mirrored data fetching can severely impact user request performance, which is unacceptable for latency-sensitive users.

[0035] Another scenario is for applications with smaller images. Due to the cold start latency overhead on the Serverless system side and the inherent limitations of P2P (Peer-to-Peer) image acceleration, the average fluctuation of the initial cold start of the test image "helloworld" can reach 2 to 3 seconds. This can lead to a less than user-friendly experience for new users or users in test scenarios.

[0036] Meanwhile, due to the unique lifecycle of Serverless instances, execution nodes are periodically rotated in some scenarios. For security reasons, the image data disk is not reused after rotation, resulting in no existing image data on the new machine after rotation. Therefore, the function images scheduled to that node will then fetch the image data again, causing latency fluctuations for cold start requests.

[0037] Several related technologies include P2P-based intelligent image and file distribution tools. These aim to improve the efficiency and speed of large-scale file transfers, maximizing network bandwidth utilization. They are widely used in application distribution, cache distribution, log distribution, and image distribution. ByteDance's internal image acceleration is also built upon this open-source solution. However, these tools only solve the problem of P2P image transmission; they do not optimize the cold start time for image download and decompression. This approach is only a temporary solution in serverless scenarios, and high cold start latency still exists. Furthermore, these tools do not address the issue of image data cache misses.

[0038] There are also some distributed dataset orchestration and acceleration engines native to Kubernetes (a container management platform), primarily serving data-intensive applications in cloud-native scenarios. The principle behind these engines is to cache data from the underlying storage system on the memory or disk of compute nodes, solving problems caused by data transmission bandwidth limitations and the bandwidth and transmission capacity limitations of the underlying storage in compute-storage separation architectures. These tools provide cached data affinity scheduling capabilities, allowing Kubernetes to refer to the cache when allocating scheduling strategies. However, these tools are primarily designed for machine learning datasets and do not provide caching and acceleration for container image data, thus failing to achieve acceleration capabilities for general-purpose container images.

[0039] Based on this, the embodiments of this specification provide a container cold start solution that can improve the speed of container cold start. The embodiments of this specification will now be described in detail.

[0040] In this embodiment, the container runs on nodes in a node cluster. The nodes in the node cluster are networked using 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 its managed peer nodes can communicate with each other. Figure 2A As shown, Figure 2A This is a flowchart illustrating a container startup method according to an exemplary embodiment, the method including the following steps:

[0041] In step 202, in response to receiving a preheating request for the 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 through the image repository and stores it locally.

[0042] In step 204, in response to receiving the cold start request of the target container, a selection strategy of prioritizing warm-up nodes is adopted to select a target node from the node cluster. The target node first attempts to obtain the pre-stored image data of the target container locally, and then attempts to obtain it through a communicable node. If it fails to obtain the image data, it obtains the image data of the target container through the image repository. Finally, the target container is started using the obtained image data of the target container.

[0043] The container startup method of this embodiment can be applied to any computer device, including but not limited to a single server, a server group consisting of multiple servers, or a cloud based on cloud computing consisting of a large number of hosts or servers. This method can be applied to various architectures, such as serverless architectures. Optionally, as an example, when the container startup method of this embodiment is executed, the above process can be entirely executed by the master node capable of managing the worker node cluster, for example, in an existing scheduling component in a container scenario; in other examples, some processes can be executed by the scheduling component, and some processes can be executed through other components that cooperate with the scheduling component. This embodiment does not limit this.

[0044] As an example, a mirror repository can be used to store and distribute images, and can also provide external APIs. This embodiment does not limit the storage method of image data in the mirror repository. As an example, image data in the mirror repository can be stored by splitting it into at least two image blobs, etc.

[0045] The container image data stored in the image repository can be provided by users. As an example, a user can create image data for an application and send it to the image repository for storage. There are multiple ways to obtain the preheating request in step 102. For example, it could be determined that a preheating request has been received after detecting a user uploading image data; it could be generated after each user uploads each piece of image data; or it could be generated after certain users upload certain pieces of image data. This embodiment does not limit this. Alternatively, it could rely on the detection of application traffic, periodically monitoring container traffic, and proactively triggering background preheating before a traffic surge is detected.

[0046] In some examples, the node types in a P2P network can include a root node (Root) and peer nodes (Peer). As an example, one or more data centers can be built, each with a root node that runs a P2P module called Root, acting as the root of the topology tree. The root node can manage at least one peer node, and each peer node can run a P2P module called Agent. The root node is responsible for retrieving data from the registry to a local persistent cache and managing the nodes in the topology tree within its data center. Figure 2B The diagram shown is a schematic representation of a P2P network according to an example embodiment of this specification. Figure 2B It includes three root nodes: Root-1, Root-2, and Root-3. Each root node can manage one or more peer nodes, and a peer node can be managed by one or more root nodes. Root nodes can communicate with the peer nodes they manage, and peer nodes managed by a root node can also communicate with each other. Root nodes can also communicate with the image repository.

[0047] As an example, various selection strategies can be set to select one or more preheating nodes from the node cluster. The number of preheating nodes can be set according to actual needs, and this embodiment does not limit this. For the selected preheating nodes, the image data of the target container can be obtained in advance and stored locally. In practical applications, the process of selecting preheating nodes can be as follows: Figure 1 The scheduling terminal shown can be the one that instructs the management terminal of the P2P network to execute the task. The management terminal and the scheduling terminal of the P2P network can be two different components or the same component. This embodiment does not limit this.

[0048] Regarding step 204, the method of initiating the target container startup request can be initiated by the user or by the cloud computing service provider after determining that the target container needs to be started through some strategies. This embodiment does not limit this. Since a node cluster can contain a large number of nodes, in a container scenario, when scheduling a node to start a container, many factors may affect the scheduling strategy, such as resource limitations, changes in node status, or conflicts between scheduling rules, etc., and it is not guaranteed that the container can be scheduled to a specific node. Therefore, this embodiment adopts a selection strategy of prioritizing the selection of preheating nodes to select the target node for starting the target container from the node cluster. However, in practical applications, it cannot be guaranteed that the target node is the preheating node that was selected in advance.

[0049] If the target node is a pre-warming node, it can directly and quickly start the container using the locally stored image data. The target node may not be a pre-warming node. Due to the networking method described above, for the selected target node, the system is designed so that it first attempts to obtain the pre-stored image data of the target container from its local machine, then attempts to obtain it from a communicable node. If this fails, it obtains the image data of the target container from the image repository. Finally, it uses the obtained image data to start the target container. Therefore, this networking method allows the target node to attempt to obtain image data from communicable nodes, thus having a certain probability of obtaining image data from other nodes, avoiding the need to obtain it from a remote image repository. The method by which the target node obtains image data from the image repository is not limited in this embodiment. It can be that the target node has the ability to communicate with the image repository and pulls the data directly from it, or it can pull the image data from other nodes that can communicate with the image repository. Finally, the target container is started using the obtained image data.

[0050] In some examples, the image repository can store image blocks obtained by splitting the image data of the target container; the step of selecting at least one warm-up node from the node cluster, and having the warm-up node obtain the image data of the target container from the image repository and store it locally, may include:

[0051] At least two preheating nodes are selected from the node cluster, and the selected at least two preheating nodes disperse and store image blocks of the image data of the target container provided by the image repository.

[0052] As an example, a block storage approach can be used in a mirror repository to achieve fine-grained management of mirror data. The number of mirror blocks obtained by splitting a set of mirror data can be determined based on factors such as the size of the mirror data, the granularity of block storage management, or the splitting rules; this embodiment does not impose any limitations on this.

[0053] As an example, this embodiment distributes multiple (at least two) image blocks of the target container's image data across at least two preheating nodes. This method can ensure the security of the image data; and selecting multiple preheating nodes can increase the probability of being selected as the target node during scheduling.

[0054] As an example, the number of warm-up nodes can be the same as the number of mirror blocks, meaning each warm-up node can store one mirror block. The number of warm-up nodes can also be less than the number of mirror blocks; how these mirror blocks are distributed across the warm-up nodes can be flexibly configured according to actual needs. The number of warm-up nodes can also be more than the number of mirror blocks, employing redundant storage of mirror blocks, where some mirror blocks can be redundantly stored across multiple warm-up nodes. As an example, warm-up nodes used to distribute the storage of multiple mirror blocks can be peer nodes under the same root node.

[0055] Because the image data is divided into multiple image blocks and stored in a distributed manner, when selecting a target node to start the container, the selected target node may be one of the preheating nodes. In this case, a portion of the target container's image data can be successfully obtained locally. The remaining image blocks can be obtained by the target node from other nodes. For example, the target node could identify preheating nodes that store other image blocks and then obtain those blocks from them. Alternatively, the target node could obtain other image blocks through an image repository; this could involve the target node communicating directly with the image repository or obtaining other image blocks through other nodes that can communicate with the image repository.

[0056] The above embodiment illustrates the concept of dividing image data into image blocks and distributing these blocks across preheating nodes. In other examples, the preheating nodes can store the entire image data, which can improve container startup speed. In practical applications, a suitable method can be selected as needed. For example, some image data can be stored in image blocks, while other image data can be stored as a single, continuous image. This embodiment does not limit this approach.

[0057] In some scenarios, the selection of preheating nodes and the number of nodes to select may be issues that need to be considered. Selecting too few nodes can lead to cache misses; selecting too many nodes can result in excessively high disk water levels. As an example, selecting at least one preheating node from the node cluster may include:

[0058] Select at least two peer nodes managed by the same root node from the node cluster as warm-up nodes;

[0059] The process of the target node first attempting to obtain the pre-stored image data of the target container locally, and then attempting to obtain it through a communicable node, and if unsuccessful, obtaining the image data of the target container through the image repository, may include:

[0060] The target node first attempts to obtain the pre-stored image data of the target container from its local machine; if it fails to obtain the image data locally, it then 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 if it fails to obtain the image data from other peer nodes, it obtains the image data of the target container from the image repository through the root node.

[0061] In this embodiment, at least two peer nodes under the same root node can be used as warm-up nodes, and the number of warm-up nodes can be configured as needed. Thus, the selected at least two warm-up nodes under the same root node can communicate with each other. In this scheme, if the target node does not store image data (not limited to the entire data set or image blocks), the target node can first try to communicate with other peer nodes to determine if it can obtain the image data of the target container from other peer nodes. If this fails, it can obtain the image data of the target container from the image repository through the root node. If the target node is a warm-up node, and the target node stores a portion of the image data as image blocks, since multiple peer nodes under the same root node are selected, other image blocks are highly likely to be obtained from other communicable peer nodes. Therefore, this embodiment improves the container startup speed through the above method.

[0062] In other examples, there may be other methods for selecting preheating nodes. For instance, selecting at least one preheating node from the node cluster may include:

[0063] At least one root node is selected from the node cluster as a warm-up node, and at least one peer node is selected from the peer nodes managed by the selected root node as a warm-up node.

[0064] The process of the target node first attempting to obtain the pre-stored image data of the target container locally, and then attempting to obtain it through a communicable node, includes:

[0065] The target node first attempts to obtain the pre-stored image data of the target container from its local machine; if it fails to obtain the image data locally, it then requests the image data of the target container from the root node to which it belongs; wherein, the root node first attempts to obtain the pre-stored image data of the target container from its local machine, and if it fails to obtain the image data locally, it then obtains the image data from the image repository.

[0066] The method for selecting preheating nodes in this embodiment can be to select at least one root node and at least one peer node from all peer nodes managed by that root node as preheating nodes. The number of root nodes and peer nodes selected as preheating nodes can be set as needed. As an example, there can be one root node and multiple peer nodes. The number of peer nodes can be set according to the number of nodes, for example, 30% of the nodes can be selected as preheating nodes.

[0067] Through the above embodiments, within the sub-nodes of the tree composed of the Root, if an affinity failure cache miss occurs, data can be directly obtained from the Root node storing the image data via P2P transmission, avoiding the overhead of directly pulling from the remote image repository. Because leaf nodes are selected as warm-up nodes in this tree, if a warm-up node is not selected as the target node for starting the container, the leaf node can request data from the Root node.

[0068] Optionally, in some cases, the root node may request image data and then distribute the image data to all or some of its managed child nodes, as needed, which can increase the probability of subsequent successful scheduling.

[0069] As an example, in practical applications, there can be multiple ways to select the root node, and this embodiment does not limit this. As an example, such as... Figure 2B As shown, a hash calculation can be performed using the user identifier to select the corresponding root node Root-3 from all root nodes in the node cluster as the preheating node. Then, one peer node is selected from the multiple peer nodes managed by Root-3 as the preheating node. In other examples, if the image data is large, the preheating node can also be selected by hashing through multiple root nodes in the tree.

[0070] In other examples, the selection of preheating nodes can also be based on resource water levels. For instance, selecting at least one preheating node from the node cluster may include:

[0071] Based on the resource utilization rate of the nodes in the node cluster, at least one preheating node is selected from the node cluster; wherein, the resource utilization rate of a node is negatively correlated with the probability of being selected as a preheating node.

[0072] As an example, the resources here may include one or more combinations of resources such as a processor (CPU), memory, or disk. Resource utilization can refer to the proportion of a resource's capacity that is being used. A node's resource utilization is negatively correlated with its probability of being selected as a preheating node. In practical applications, the specific relationship between resource utilization and the probability of being selected as a preheating node can be flexibly set as needed; this embodiment does not impose any limitations on this.

[0073] As an example, the scheduling terminal that implements the preheating node selection in this embodiment can obtain the image data preheating status result of each node in the node cluster, that is, which container image data each node has preheated, so that the preheating node can be selected based on the image data preheating status result of each node in the node cluster.

[0074] Therefore, by using the above methods, nodes with lower resource utilization are more likely to have enough free resources to store and provide mirrored data, and are also more likely to be selected as warm-up nodes. This prevents some nodes from being over-warmed up, which could lead to high disk water level risks, and can also minimize the occurrence of hot spots and uneven load.

[0075] In other examples, after the step of selecting at least one preheating node from the node cluster, the method may further include:

[0076] Configure the preheating node with an affinity tag corresponding to the target container;

[0077] The selection strategy that prioritizes preheating nodes, in selecting target nodes from the node cluster, may include:

[0078] An affinity scheduling strategy is adopted to attempt to select target nodes with the affinity label from the node cluster.

[0079] In some existing container orchestration platforms, Nodes or Pods can be viewed as resource objects, which can be defined or described using definition files. For example, a Node definition file can be submitted so that the master node, upon receiving the file, can retrieve the node information defined within it. Similarly, a Pod definition file can be submitted so that the master node, upon receiving the file, can create the Pod and schedule it to run on a specific node. Pod definition files can be used to define one or more attributes of the resource object, such as name, label, number of replicas, CPU limits, memory limits, or storage volumes. Node definition files can be used to define one or more attributes of the Node, such as label, address information, resource information, taints, or comments.

[0080] In this embodiment, an affinity scheduling strategy can be used to prioritize the selection of warm-up nodes. Affinity rules for Pods can be defined to set affinity labels between nodes and containers. Affinity rules allow Pods to run on nodes with specific labels. For example, if the image of container A is warmed up on a certain node, to prioritize the startup of container A on that node, a custom affinity label can be defined for the warm-up node. The specific content of this affinity label can be flexibly configured according to actual needs; this embodiment does not impose any limitations on this. In practical applications, one or more container image data can be warmed up on a warm-up node; therefore, a warm-up node can have affinity labels for one or more containers.

[0081] Next, in the Pod definition file of container A, an affinity rule can be set using the `nodeAffinity` field. This rule specifies that container A will preferentially run on nodes with the aforementioned affinity label. Therefore, through affinity scheduling, when selecting nodes to run container A, preheating nodes with the affinity label corresponding to container A can be preferentially selected.

[0082] In practical applications, if there are not enough resources on the preheating node to start container A, or if container A may not be able to be scheduled to start on the preheating node due to other reasons (such as node failure), the scheduling component in the container management platform may schedule container A to other nodes.

[0083] In practical applications, other strategies can be combined when selecting target nodes. For example, the selection strategy that prioritizes preheating nodes, when selecting target nodes from the node cluster, can include:

[0084] Select a set of candidate nodes from the node cluster that meet the resource requirements of the startup request and whose resource utilization rate meets the normal conditions.

[0085] A selection strategy prioritizing preheating nodes is adopted to select target nodes from the candidate node set.

[0086] In some examples, the user's startup request may carry the resource requirements of the container to be started, such as the required CPU, memory, and / or disk information. The specific resource requirements can be implemented in different ways depending on actual needs, and this embodiment does not limit this. Based on this, in this embodiment, a set of nodes that currently meet the container creation requirements and whose resource utilization meets normal conditions can be selected from the node cluster. For example, normal conditions may indicate that after the node warms up the image data, the node's resource utilization meets a set normal resource utilization rate. These normal conditions can be implemented in various ways depending on actual needs, and this embodiment does not limit this. The selected candidate set may contain one or more nodes. Then, a selection strategy that prioritizes warming up nodes combined with a resource-average allocation strategy can be used to select one or more target nodes from the candidate node set.

[0087] The priorities of the pre-warming node selection strategy and the resource equalization selection strategy can be configured as needed. For example, if the pre-warming node selection strategy has a higher priority, then when the current node's resources are scarce, resources will be prioritized over image affinity, which may reduce the affinity probability. Alternatively, the resource equalization selection strategy can have a higher priority. In this case, the probability of affinity matching can be increased, but it may be more prone to "hot spots," such as a sudden increase in concurrent container creation, which may cause CPU hotspots on the node and affect other users on the same node.

[0088] In some examples, the root node is connected to both the scheduling terminal and the management terminal of the P2P network; a communication channel exists between the management terminal and the scheduling terminal; the method is applied to the scheduling terminal; the method further includes:

[0089] The preheating status of the image data of the target container sent by the preheating node from the control terminal is recorded in the preset preheating status data.

[0090] In response to the first preheating node in the preheating status data meeting the preset rescheduling conditions, a replacement request for the first preheating node is sent to the management terminal. Upon receiving the replacement request, the management terminal notifies the first preheating node through the root node to delete the image data of the first target container stored on that node, and then reselects a preheating node to store the image data of the first target container.

[0091] In this embodiment, bidirectional streaming communication can be introduced between the control end and the scheduling end. The preheating status of the mirrored data can be pushed to the scheduling end in real time via data stream. At the same time, the scheduling end can determine whether to perform mirrored data rescheduling as needed. The preset rescheduling condition is used to indicate whether the preheating node will experience resource shortage. It can be a condition indicating whether the node's resource utilization rate is higher than the set resource utilization rate. The rescheduling condition can be implemented in various ways according to actual needs. This embodiment does not limit it.

[0092] For example, by monitoring the resource usage of each preheating node, if some preheating nodes in the preheating status data meet preset rescheduling conditions (referred to as the first preheating node in this embodiment), the first preheating node can perform a mirror data elimination operation. A notification can be sent directly to the management terminal, instructing the root node to delete the mirror data of the first target container stored on that node. Furthermore, a new preheating node can be selected to store the mirror data of the first target container. Based on this, this embodiment can employ the logic of "mirror data rescheduling." By dynamically acquiring the resource occupancy of nodes, preheating nodes with high resource consumption can be proactively removed, and nodes with lower current resource levels can be selected for data preheating.

[0093] In other examples, the preheating node can be used to store image data of one or more containers; the method may also include:

[0094] Obtain the resource utilization rate of the preheating node;

[0095] In response to the resource occupancy rate of the preheating node meeting the preset rescheduling conditions, the affinity tags corresponding to one or more containers of the preheating node are selected and deleted, and the image data of the containers corresponding to the selected affinity tags are deleted.

[0096] This embodiment can be understood as a rescheduling strategy for mirrored data. For the selected warm-up node, this embodiment can continuously acquire the resource utilization rate of the warm-up node to determine the conditions indicating whether the warm-up node will experience resource stress. The preset rescheduling conditions are used to indicate whether the warm-up node will experience resource stress, and can be conditions indicating whether the node's resource utilization rate is higher than the set resource utilization rate. The rescheduling conditions here can be implemented in various ways according to actual needs, and this embodiment does not limit them.

[0097] If resource shortages are detected in the preheating node, you can delete the affinity tags corresponding to one or more containers in the preheating node, and at the same time delete the corresponding image data.

[0098] For example, if a preheating node stores image data for containers A, B, and C respectively, then that preheating node will be configured with an affinity tag corresponding to container A, container B, and container C. If resource constraints are detected on the preheating node, such as a sudden surge in traffic causing high CPU usage or a high number of concurrent instance creations, the affinity tag of one of the containers can be deleted as needed, along with the image data for that container. For example, ... Figure 2C As shown, a list of preheated nodes that have preheated the image data can be obtained in the node cluster. This list contains each preheated node, and based on this, preheated nodes with tight resources can be identified. For example, the nodes in the figure are squares. A certain CPU resource has a high utilization rate, so it is selected to delete some or all of the container affinity tags.

[0099] The selection of which container to remove from the preheating node can be configured as needed. For example, it can be determined based on the container's startup frequency in recent times, or by prioritizing containers with lower image data access frequency, or by determining the size of the container's image data, and so on.

[0100] Optionally, after a container is removed from the preheating nodes, other preheating nodes can be selected as needed to preheat the removed container. For example, when operations such as deleting the affinity tag of the target container stored on the preheating node and deleting the image data of the target container occur, a "target container preheating request" can be triggered, thereby re-executing the aforementioned step of "selecting at least one preheating node from the node cluster". For example, Figure 2C As shown, a new warm-up node was selected to warm up the image data, and the newly selected warm-up node will have a container affinity tag added to it.

[0101] 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.

[0102] 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 levels of preheating nodes, such as disk levels, to avoid disk pressure on nodes caused by preheating too many images. For example, it can obtain the access status of each image data stored on the preheating node, such as the timestamps of the K most recent accesses. It can proactively, or under the aforementioned resource constraints, prioritize the eviction of image data with the oldest K most recent access times, where K can be set according to actual needs; this embodiment does not limit this setting. The above-mentioned approach to deleting mirrored data is similar to the Least Recently Used K (LRU-K) replacement algorithm in the cache eviction field. Compared with the traditional Least Recently Used (LRU) algorithm, 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 eviction of the oldest mirrored data with the K most recent access times can better remove mirrored data with low usage probability.

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

[0104] ① Gateway component API-Server;

[0105] This gateway component can be responsible for receiving and forwarding requests to other components; for example, receiving requests to create or update container images; it can also receive container startup requests.

[0106] ② The state management component EERoutui is responsible for routing requests to instances;

[0107] For example, a cold start command, i.e. a container start request, can be sent to the resource scheduling component Placement (i.e., the aforementioned scheduler) to create a new instance.

[0108] ③ The resource scheduling component Placement is responsible for binding instances to nodes. In this embodiment, it can be responsible for logic such as affinity scheduling and rescheduling.

[0109] ④ The P2P management component P2P-Manager (i.e. the aforementioned management terminal) is responsible for maintaining the P2P networking relationship of the node cluster and issuing commands to P2P-Daamon.

[0110] ⑤ The P2P node component P2P-Deamon is responsible for collecting node information and executing relevant P2P commands.

[0111] ⑥ Image-Converter service, used to convert user image data.

[0112] ⑦ Mirror repository service, used to store transferred image data in the mirror repository.

[0113] ⑧ The P2P agent module, P2P-Agent, runs on each node and is responsible for executing the instructions issued by the P2P management component.

[0114] like Figure 2E The diagram shown is a preheating flowchart for container image data according to an exemplary embodiment of this specification, which may include the following process:

[0115] 1.1 The gateway component API-Server sends the prewarm processing credential prewarmAccIImage(Credential) to the P2P management component P2P-manager of the P2P system.

[0116] 1.2 The management component P2P-manager calls the service interface API of the image repository and can send a request getRepoTagManifest ACREE to obtain the image description information.

[0117] 1.3 The management component P2P-manager selects the nodes for pulling data (that is, selects one or more warm-up nodes from the P2P network for pulling data).

[0118] 1.4: The management component P2P-manager requests Object Storage Service (OSS) to obtain the storage address signedURL of the signed image data.

[0119] 1.5: The management component P2P-manager sends a plan to the selected node P2P-daemon to pull image data.

[0120] 1.5.1: The P2P-daemon sends a request to the object storage service to pull image data;

[0121] 1.5.2: Pull image data from OSS.

[0122] 2. The management component P2P-manager pushes the image data warm-up status results to Placement;

[0123] 2.1: Placement updates the mirror data distribution of nodes in memory.

[0124] 3. The gateway component API-Server sends an Invoke cold start CreateContainer request to the Placement:

[0125] 3.1: The distribution of node preheating data is taken into account in the scheduling logic.

[0126] As can be seen from the above embodiments, this embodiment is based on the characteristic of Serverless storage and computing nodes being used together. By preheating, the image data is cached on the computing nodes in advance, and the computing nodes can achieve near-local image start-up speed. This eliminates the additional cold start time on the Serverless platform side, which has a good effect on user experience and performance.

[0127] The warm-up operation in this embodiment does not introduce additional machine storage costs. At the same time, compared with the Kubernetes architecture, the Serverless architecture can sense the application's traffic requests. This embodiment can use the LRU-K algorithm to evict image data that has not been requested in the last K times, which is more suitable for Serverless application scenarios and can further improve the utilization of node disk resources.

[0128] Compared to the Kubernetes architecture, this embodiment can manage image cache data at the block level. This embodiment also proposes the logic of "image data rescheduling", which can reschedule image data to nodes with lower CPU and memory levels. This will increase the probability of scheduling instances to nodes with image data during the next cold start, further improving the probability of cache hit and reducing the probability of cold start.

[0129] Compared with image preheating and affinity scheduling in the Kubernetes architecture, this embodiment can make full use of the characteristics of P2P node networking, and the selection of preheating nodes and the control of scheduling strategies are more flexible. For example, when selecting preheating nodes, the weight of the preheating nodes can be set according to the current cluster node P2P networking structure. Therefore, this embodiment can achieve a better balance between resource utilization and improving affinity hit rate, and can solve the problem of uneven resource utilization caused by image affinity in the Kubernetes architecture.

[0130] This specification also provides another method for cold starting a container, which can be applied to nodes in the node cluster. This method may include:

[0131] In response to receiving the image data of the target container from the warm-up node, the image data of the target container is obtained from the image repository and stored locally;

[0132] In response to receiving a cold start request for the target container, the system first attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain it through a communicable node, and if the attempt fails, obtains the image data of the target container through the image repository. Finally, the system uses the obtained image data of the target container to start the target container.

[0133] The method described in this embodiment can be referred to the description of the foregoing embodiments, and will not be repeated here.

[0134] Corresponding to the embodiments of the aforementioned container cold start method, this specification also provides embodiments of the container cold start device and the computer equipment used thereon.

[0135] The embodiments of the container cold start device described in this specification can be applied to computer equipment, such as servers or terminal devices. The device embodiments can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by its processor reading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 3 The diagram shown is a hardware structure diagram of the computer equipment where the container cold start device of this manual is located, except for... Figure 3 In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown, the computer device where the container cold start device is located in the embodiment may also include other hardware depending on the actual function of the computer device, which will not be described in detail here.

[0136] As an example, a container cold start device may include:

[0137] The preheating module is used 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 have the preheating node obtain the image data of the target container through the image repository and store it locally;

[0138] The scheduling module is used to: respond to receiving a cold start request for the target container, select a target node from the node cluster using a selection strategy that prioritizes warm-up nodes, have the target node attempt to obtain the pre-stored image data of the target container from its local storage, and if it fails to obtain the image data of the target container locally, obtain the image data of the target container from the image repository, and finally start the target container using the obtained image data of the target container.

[0139] The specific implementation process of the functions and roles of each module in the above-mentioned container cold start device can be found in the implementation process of the corresponding steps in the above-mentioned container cold start method, and will not be repeated here.

[0140] Accordingly, this specification also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned container cold start method embodiment.

[0141] Accordingly, embodiments of this 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 executes the program to implement the steps of the container cold start method embodiment.

[0142] Accordingly, embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the container cold start method embodiments.

[0143] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0144] The above embodiments can be applied to one or more computer devices. The computer device is a device that can automatically perform numerical calculations 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 (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0145] The computer device can be any electronic product that can interact with the user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, interactive network television (IPTV), smart wearable device, etc.

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

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

[0148] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0149] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0150] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0151] The terms "specific example" or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with the embodiments or examples, which are included in at least one embodiment or example of this specification. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0152] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0153] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

[0154] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A container cold start method, wherein the container runs on nodes in a node cluster, the nodes in the node cluster are networked using a P2P network, the types of nodes in the P2P network include a root node and peer nodes managed by the root node, and the root node and the managed peer nodes can communicate with each other, the method comprising: In response to receiving a warm-up request for a target container for cold start, at least one warm-up node is selected from the node cluster, and the warm-up node obtains the image data of the target container through the image repository and stores it locally. In response to receiving a cold start request for the target container, a selection strategy prioritizing warm-up nodes is adopted to select a target node from the node cluster. The target node first attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain it through a communicable node. If the attempt fails, the target container's image data is obtained through the image repository. Finally, the target container is started using the obtained image data.

2. The method according to claim 1, wherein the root node is connected to both the scheduling terminal and the management terminal of the P2P network; There is a communication channel between the control terminal and the scheduling terminal; The method is applied to the scheduling terminal; The method further includes: The preheating status of the image data of the target container sent by the preheating node from the control terminal is recorded in the preset preheating status data. In response to the first preheating node in the preheating status data meeting the preset rescheduling conditions, a replacement request for the first preheating node is sent to the management terminal. Upon receiving the replacement request, the management terminal notifies the first preheating node through the root node to delete the image data of the first target container stored on that node, and then 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: At least two preheating nodes are selected from the node cluster, and the selected at least two preheating nodes disperse and store image blocks of the image data of the target container provided by the image repository.

4. The method according to claim 1 or 3, wherein selecting at least one preheating node from the node cluster comprises: Select at least two peer nodes managed by the same root node from the node cluster as warm-up nodes; The process of the target node first attempting to obtain the pre-stored image data of the target container locally, and then attempting to obtain it through a communicable node, and, if unsuccessful, obtaining the image data of the target container through the image repository, includes: The target node first attempts to obtain the pre-stored image data of the target container from its local machine; if it fails to obtain the image data locally, it then 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 if it fails to obtain the image data from other peer nodes, it obtains the image data of the target container from the image repository through the root node. or, Selecting at least one preheating node from the node cluster includes: At least one root node is selected from the node cluster as a warm-up node, and at least one peer node is selected from the peer nodes managed by the selected root node as a warm-up node. The process of the target node first attempting to obtain the pre-stored image data of the target container locally, and then attempting to obtain it through a communicable node, includes: The target node first attempts to obtain the pre-stored image data of the target container from its local machine; if it fails to obtain the image data locally, it then requests the image data of the target container from the root node to which it belongs; wherein, the root node first attempts to obtain the pre-stored image data of the target container from its local machine, and if it fails to obtain the image data locally, it then obtains the image data from the image repository.

5. The method according to claim 1, wherein selecting at least one preheating node from the node cluster comprises: Based on the resource utilization rate of the nodes in the node cluster, at least one preheating node is selected from the node cluster; wherein, the resource utilization rate of a node is negatively correlated with the probability of being selected as a preheating node.

6. The method of claim 1, after the step of selecting at least one preheating node from the node cluster, the method further comprises: Configure the preheating node with an affinity tag corresponding to the target container; The selection strategy that prioritizes preheating nodes, selecting target nodes from the node cluster, includes: An affinity scheduling strategy is adopted to attempt to select target nodes with the affinity label from the node cluster.

7. The method according to claim 6, wherein the preheating node is used to store image data of one or more containers; The method further includes: Obtain the resource utilization rate of the preheating node; In response to the resource occupancy rate of the preheating node meeting the preset rescheduling conditions, the affinity tags corresponding to one or more containers of the preheating node are selected and deleted, and the image data of the containers corresponding to the selected affinity tags are deleted.

8. The method according to claim 1, wherein selecting a target node from the node cluster using a preheating node priority selection strategy comprises: Select a set of candidate nodes from the node cluster that meet the resource requirements of the startup request and whose resource utilization rate meets the normal conditions. The target node is selected from the candidate node set by combining a selection strategy that prioritizes preheating nodes with a selection strategy that distributes resources evenly.

9. A container cold start method, the method being applied to nodes in a node cluster, the nodes in the node cluster being networked using a P2P network, the types of nodes in the P2P network including a root node and peer nodes managed by the root node, the root node and the managed peer nodes being able to communicate with each other, the method comprising: In response to receiving the image data of the target container from the warm-up node, the image data of the target container is obtained from the image repository and stored locally; In response to receiving a cold start request for the target container, the system first attempts to obtain the pre-stored image data of the target container locally, then attempts to obtain it through a communicable node, and if the attempt fails, obtains the image data of the target container through the image repository. Finally, the system uses the obtained image data of the target container to start the target container.

10. A container management system, the system comprising a scheduler and a node cluster, the scheduler being configured to execute the steps of the method of any one of claims 1 to 8, and the nodes in the node cluster being configured to execute the steps of the method of claim 9.

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

12. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method of any one of claims 1 to 9.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any one of claims 1 to 9.

Images