A container starting method and apparatus

Abstract

The application discloses a container starting method and device, and relates to the technical field of container starting. The specific embodiment of the application comprises the following steps: monitoring each container in a running state, a file block that needs to be accessed, and the access frequency of each file block, and screening out hot file blocks that need to be accessed by each container according to the access frequency; regarding each node in a cluster as a target node of container migration, and performing the following operations on the target node: predicting that a target container will be migrated to the target node within a preset time period in the future based on a container migration history event, pre-pulling a target hot file block from a source node to which the target hot file block belongs, and caching the target hot file block to the target node, so that the target container can be started based on the target hot file block cached by the target node in the process of migrating the target container from the source node to the target node. The embodiment guarantees the container starting speed, realizes the inductive migration of the container, and enhances the real-time response capability of the business.

Description

Technical Field

[0001] This invention relates to the field of container startup technology, and in particular to a container startup method and apparatus. Background Technology

[0002] The increasing size of container images makes pulling full container images slow, and lazy loading of container images increases container startup latency or causes performance fluctuations during container runtime. Existing pre-pull solutions for container images face a trade-off between "redundant pulling" and "loading latency" due to a lack of accurate runtime data support. Especially when migrating containers across nodes, the target node needs to temporarily load the required image files, resulting in significant startup latency, low container startup efficiency, and a serious impact on business responsiveness. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a container startup method and apparatus. On the one hand, a hot file block filtering mechanism is used to replace full fetching, which reduces resource waste while ensuring container startup speed. On the other hand, by advancing the pre-fetching time to before container migration occurs, the waiting time for the target node to load the image is eliminated, realizing near-seamless startup of container migration and enhancing the real-time response capability of the business.

[0004] To achieve the above objectives, according to one aspect of the present invention, a container startup method is provided, comprising: monitoring the file blocks that each container needs to access and the access frequency of each file block when it is running, and filtering out the hot file blocks that each container needs to access when it is running based on the access frequency; Each node in the cluster is used as the target node for container migration, and the following operations are performed on the target node: based on container migration history events, it is predicted that the target container will migrate to the target node within a preset time period in the future; the target hot file block corresponding to the target container is pre-fetched from the source node; the target hot file block is cached in the target node; so that during the process of migrating the target container from the source node to the target node, the target container is started based on the target hot file block cached in the target node.

[0005] Optionally, monitoring the file blocks that each container needs to access and the access frequency of each file block during operation includes: A monitoring program is loaded into the kernel of each node to monitor the access information of each container to each file block while it is running. Based on the access information, the attenuation access frequency corresponding to each file block is calculated.

[0006] Optionally, the step of filtering out the hot file blocks that each container needs to access based on access frequency includes: For each container: The image of the container is grouped into multiple file blocks by image layer; Sort the multiple file blocks within each group according to the access popularity; Based on the sorting results, hot file blocks are identified from multiple files within each group.

[0007] Optionally, after caching the target hot file block to the target node, and before performing the container migration operation, the method further includes: Monitor the resource pressure indicators of each node in the cluster. If the monitoring results indicate that the resource pressure indicator of the source node has reached the preset migration trigger condition, determine the target container to be migrated from the source node and trigger the container migration operation.

[0008] Optionally, determining the target container to be migrated from the source node includes: The service type, access frequency, and latency sensitivity of each container within the source node are determined. Based on the service type, access frequency, and latency sensitivity of the multiple containers within the source node, the target container to be migrated is determined from the multiple containers.

[0009] Optionally, it also includes: During the migration of the target container from the source node to the target node, an initial memory snapshot is generated, memory write pages in the source node are monitored, incremental data generated during the migration is determined based on the memory write pages, and the initial memory snapshot and the incremental data are synchronized to the target node. And / or, Monitor the connection requests received by the source node for the target container, and redirect the connection requests to the target node.

[0010] Optionally, the migration triggering condition includes: the resource pressure index is greater than or equal to a first preset threshold and the duration is not less than a preset target duration; And / or, The resource pressure metrics are derived based on one or more of the following metrics: CPU pressure, memory pressure, I / O pressure, CPU scheduling latency, and memory reclamation frequency.

[0011] Optionally, after caching the target hot file block to the target node, and before performing the container migration operation, the method further includes: The resource pressure index of each node is compared with the second preset threshold, and multiple candidate nodes whose resource pressure index is less than the second preset threshold are identified; the second preset threshold is less than the first preset threshold. From the multiple candidate nodes, the target node that has cached the target hot file corresponding to the target container is determined; Trigger a container migration operation to migrate the target container to the target node.

[0012] Optionally, it also includes: After the target container migration is completed, while the target container is running, monitor the changes in resource pressure of the target node and the performance indicators of the target container, and adjust the second preset threshold according to the changes in resource pressure and the performance indicators; And / or, Calculate the ratio of target hot file blocks pre-cached to the target node to the file blocks actually needed to access when starting the target container on the target node, and calculate the startup latency of the target container. Based on the ratio and the startup latency, adjust the hot file block filtering strategy.

[0013] To achieve the above objectives, according to another aspect of the present invention, a container initiation apparatus is provided, comprising: a screening module and a prediction module, wherein, The filtering module is used to monitor the file blocks that each container needs to access during its running state and the access frequency of each file block, and to filter out the hot file blocks that each container needs to access during its running state based on the access frequency. The prediction module is used to use each node in the cluster as the target node for container migration, and to perform the following operations on the target node: based on container migration history events, predict that the target container will migrate to the target node within a preset time period in the future; pre-fetch the target hot file block from the source node to which the target hot file block belongs; cache the target hot file block in the target node; so that during the process of migrating the target container from the source node to the target node, the target container is started based on the target hot file block cached in the target node.

[0014] To achieve the above objectives, according to another aspect of the present invention, an electronic device for container startup is provided, comprising: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors perform the method as described in the above embodiments.

[0015] To achieve the above objectives, according to another aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method described in the above embodiments.

[0016] To achieve the above objectives, according to another aspect of the present invention, a computer program product is provided, comprising a computer program, characterized in that, when the program is executed by a processor, it implements the method described in the above embodiments.

[0017] One embodiment of the above invention has the following advantages or beneficial effects: on the one hand, by using a hot file block filtering mechanism to replace full fetching, resource waste is reduced while ensuring container startup speed; on the other hand, by advancing the pre-fetching time to before container migration occurs, the waiting time for the target node to load the image is eliminated, achieving near-seamless startup of container migration and enhancing the real-time response capability of the business.

[0018] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0019] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein: Figure 1 This is a schematic diagram of the main steps of a container startup method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the main modules of a container startup device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the main modules of a container startup device according to another embodiment of the present invention; Figure 4 This is a schematic diagram of the operational logic of an exemplary system architecture according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0020] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0021] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0022] It should be noted that, unless otherwise specified, the embodiments of the present invention and the technical features thereof can be combined with each other.

[0023] Figure 1 This is a schematic diagram of the main steps of a container startup method according to an embodiment of the present invention.

[0024] like Figure 1 As shown, the container startup method of this embodiment mainly includes steps S101-S102, wherein, Step S101: Monitor the file blocks that each container needs to access and the access frequency of each file block while it is running, and filter out the hot file blocks that each container needs to access based on the access frequency. Step S102: Each node in the cluster is used as the target node for container migration, and the following operations are performed on the target node: Based on the container migration history events, it is predicted that the target container will be migrated to the target node within a preset time period in the future. The target hot file block is pre-pulled from the source node to which the target hot file block belongs, and the target hot file block is cached in the target node, so that the target container is started based on the target hot file block cached in the target node during the migration of the target container from the source node to the target node.

[0025] First, let's explain some of the technical terms used in this embodiment: "Container" refers to a lightweight virtualization technology that enables rapid cross-platform deployment and operation by packaging applications and their dependent environments together; "Container migration" refers to the process of transferring a running or stopped container from one compute node (source node) in a cluster to another compute node (target node); "Access popularity" refers to the frequency and intensity of read or write operations performed by containers on specific file blocks in the image within a preset time period. The higher the access frequency, the higher the popularity of the file block, which usually means that the file block is crucial for the startup and basic operation of the container.

[0026] The container startup method provided in this embodiment aims to solve the problem of slow full pull caused by the increase in container image size and runtime performance jitter caused by delayed loading. This embodiment is particularly suitable for large-scale container clusters, high-frequency container migration, or business scenarios that are sensitive to startup latency.

[0027] In practical implementation, a monitoring mechanism (e.g., using eBPF technology) is deployed at the kernel layer of each node to track the container's access requests to underlying files in real time. The timestamp and number of times each file block is accessed are recorded to calculate the access frequency of each file block. Based on this frequency, "hot" file blocks are selected. For example, an access frequency threshold is set, and file blocks whose access frequency exceeds this threshold are identified as "hot" file blocks. Hot file blocks typically contain core library files that must be loaded when the container starts, critical configuration information, and frequently called binary executable files. This embodiment divides the data in the container image into "hot data" and "cold data," thereby providing accurate data support for subsequent on-demand pre-pulling.

[0028] In addition, during the implementation process, a historical migration record library can be maintained to record container migration events. Container migration history events can be retrieved from this library, and the timing patterns and distribution characteristics of container migration between different nodes can be analyzed based on these events. If it is predicted that the target container has a high probability of migrating from the source node to the target node in the near future, then instead of pulling the entire image, only the target hot file blocks selected for the target container are pre-transmitted from the source node to the target node and stored in the target node's local cache. This way, when the target container actually migrates to the target node, there is no need to temporarily pull the complete image file or hot file blocks. The target container can be started using only the pre-cached target hot file blocks, reducing startup latency and achieving near-seamless container migration, ensuring real-time business responsiveness.

[0029] The following specific example better illustrates the container startup method of this embodiment: Assume container A is currently running on node 1 (source node). Based on historical patterns, it is predicted that container A may migrate to node 2 (target node) within the next ten minutes. In this case, the hot file blocks required for container A's startup (e.g., the core startup file that only accounts for 10% of the image size) can be transferred from node 1 to node 2 and cached in advance. When the migration command is issued and container A is officially transferred from node 1 to node 2, node 2 does not need to pull the huge complete image or the corresponding hot file blocks from the image repository again. Instead, it can immediately start container A using the already cached hot file blocks. During the container's operation after startup, other less frequently used cold file blocks are gradually pulled through background lazy loading.

[0030] This embodiment changes "full fetch" to "hot file block pre-fetch" and advances the fetch timing to before the migration occurs, enabling containers to start up almost seamlessly on the target node, thus improving the continuity of services during cluster scheduling.

[0031] In an optional embodiment of the present invention, monitoring the file blocks that each container needs to access and the access frequency of each file block during operation includes: loading a monitoring program in the kernel of each node, monitoring the access information of each container for each file block during operation through the monitoring program; and calculating the attenuation access frequency corresponding to each file block based on the access information.

[0032] To acquire file access data in real time without impacting business performance, a monitoring program is deployed in the kernel space of each node. Specifically, this "monitoring program" is a probe program based on eBPF (Extended Berkeley Packet Filter) technology. This monitoring program can be directly mounted on the kernel's file system I / O interface. Whenever a process within the container initiates a read or write request for a file block, the monitoring program intercepts and records the read or write operation in real time. During this process, the "access information" recorded for that file includes the file block index, timestamp, and operation type. The data included in this access information constitutes the original basis for filtering hot file blocks.

[0033] Furthermore, to avoid inaccurate identification of hot file blocks due to historical redundancy, this embodiment introduces a "decrease access frequency" calculation mechanism. In a real-world operating environment, some file blocks may be accessed frequently during startup but are no longer used during runtime. If only the access count is simply accumulated, expired file blocks will still be identified as hot file blocks, thus wasting storage and transmission resources. Therefore, this embodiment assigns a time weight to the access frequency through a decay algorithm: the more recent the access behavior, the higher its weight; and as time goes on, the weight of earlier access records will gradually decrease (decrease).

[0034] For example, suppose file block A was accessed 100 times one hour ago, while file block B was accessed 10 times one minute ago. In the traditional cumulative counting mode, file block A would be considered more important hot data; however, under the decay mechanism of this scheme, because the access to file block B occurred recently, its weight is amplified, while the access records of file block A are decayed due to the long time that has passed. Ultimately, the system will determine that file block B is the hot file block that urgently needs to be preloaded.

[0035] The above mechanism enables real-time calculation of the dynamic access frequency of each file block and the filtering of truly hot file blocks. Subsequently, the filtered hot file blocks are used as pre-pull targets, which are then transferred to the target node and cached before container migration or startup.

[0036] This embodiment utilizes kernel-level monitoring to reduce the performance overhead caused by frequent polling in user space; through a decay algorithm, it solves the problem that static hotspot analysis cannot adapt to dynamic operating environments, making the hotspot data identification results highly timely.

[0037] In an optional embodiment of the present invention, the hot file blocks that each container needs to access are filtered according to the access popularity, including: for each container: grouping the multiple file blocks included in the container image by image layer; sorting the multiple file blocks in each group according to the access popularity; and determining the hot file blocks from the multiple files in each group according to the sorting results.

[0038] To more accurately determine which file blocks are critical to container startup and operation, a filtering method based on image layering was adopted.

[0039] First, let's define the relevant concepts: "Image" refers to a read-only template that contains all the dependencies required to run an application (such as the operating system, library files, configuration files, and the application itself); while "image layer" refers to the way the image is organized. An image is not a single whole, but a stack structure composed of multiple layers (for example, the bottom layer is the operating system layer, the middle layer is the middleware layer, and the top layer is the application layer).

[0040] Specifically, when identifying hot file blocks, instead of performing a global sort across all file blocks in the entire image, the following hierarchical filtering steps are taken: The first step is to group all file blocks in the image according to their respective image layers. For example, file blocks belonging to the operating system layer are grouped together, file blocks belonging to the middleware layer are grouped together, and file blocks belonging to the application layer are grouped together.

[0041] The second step is to locally sort the file blocks within each independent mirror layer group based on access frequency.

[0042] The third step is to select a certain number of file blocks with the highest access frequency within each mirror layer group based on the sorting results of each group. These are called hot file blocks. The hot file blocks of each mirror layer group are then grouped together to form the hot file block set of the mirror.

[0043] For ease of understanding, the following example is provided: Suppose an image contains three layers: the OS layer (base system), the Lib layer (dependency libraries), and the App layer (business applications). If a "global sorting" approach is used, the extremely high file access frequency in the OS layer might cause the top 100 most frequently accessed file blocks to all originate from the OS layer, while crucial startup configuration files in the App layer, though accessed less frequently, are overlooked. However, with the "layered sorting" approach described in this solution, the system selects most frequently accessed file blocks separately from the OS layer, the Lib layer, and the App layer. This ensures that critical startup data is accurately covered at both the base environment and business logic levels.

[0044] This embodiment avoids the problem of critical business layer files being obscured due to excessive access to certain basic layer files, ensuring the representativeness of hot data sets; by independently filtering hot file blocks at each layer, it ensures that critical dependencies at each level required during container startup can be preloaded, thereby significantly improving container startup speed.

[0045] In an optional embodiment of the present invention, after caching the target hot file block to the target node and before performing the container migration operation, the method further includes: monitoring the resource pressure indicators of each node in the cluster; if the monitoring results indicate that the resource pressure indicators of the source node have reached the preset migration triggering conditions, determining the target container to be migrated from the source node and triggering the container migration operation.

[0046] This embodiment introduces a container migration triggering mechanism based on real-time status monitoring to ensure that container migration can be performed at the optimal time.

[0047] Specifically, after the target node completes the caching of hot file blocks, the container migration is not performed immediately. Instead, the running status of each node in the cluster is continuously monitored, with a focus on monitoring the resource pressure indicators of each node (including but not limited to key performance data such as CPU utilization, memory usage, disk I / O bandwidth, CPU scheduling latency, and memory reclamation frequency).

[0048] When the resource pressure index of the source node (i.e., the node currently hosting the target container) reaches or exceeds a preset threshold, the source node will be determined to be in an overloaded state, thus triggering a container migration operation. At this time, an optimal node can be selected from the target nodes that have pre-cached the relevant hot file blocks, and the target container will be migrated from the source node to that target node.

[0049] To illustrate the container migration triggering mechanism more intuitively, the following example is provided: Assuming the hot file blocks corresponding to container A are pre-cached on node B, during actual operation, real-time monitoring reveals that node A's resource pressure indicators exceed a preset threshold (e.g., the percentage of time spent blocking tasks due to CPU contention exceeds 40% in the past 10 seconds) and this duration exceeds 30 seconds. This indicates that node A can no longer support the efficient operation of container A. Therefore, a migration command is immediately triggered for container A, migrating it to node B where the corresponding hot file blocks have already been cached. Since node B has pre-loaded the hot file blocks required for container A's startup and operation, container A starts up quickly after migrating to node B, avoiding prolonged downtime or performance fluctuations caused by reloading image data.

[0050] This embodiment monitors resource pressure indicators to ensure that container migration is triggered only when the source node truly needs to alleviate pressure, thus avoiding the system overhead caused by frequent migrations. By migrating containers to target nodes with the basic data for container startup in a timely manner, the container startup speed is improved, startup latency is reduced, and performance fluctuations are avoided.

[0051] In an optional embodiment of the present invention, determining the target container to be migrated from the source node includes: determining the service type, access popularity, and latency sensitivity of each container in the source node; and determining the target container to be migrated from the multiple containers based on the service type, access popularity, and latency sensitivity corresponding to the multiple containers in the source node.

[0052] After triggering the container migration mechanism, this embodiment does not blindly migrate all containers or randomly select containers for migration. Instead, it prioritizes containers within the source node using multi-dimensional metrics to determine the most suitable migration targets. Specifically, three key metrics for each container can be collected and analyzed in real time: service type (e.g., computationally intensive batch processing tasks or real-time API services highly sensitive to response time); access popularity / load (i.e., the container's current resource utilization and the frequency of received access requests); and latency sensitivity (i.e., the tolerance for short downtime or network jitter that may occur during the migration process). By comprehensively evaluating these metrics, the containers most in need of migration are selected. For example, backend services with excessive load and a certain tolerance for latency are migrated first, while highly sensitive core real-time services are avoided during peak periods.

[0053] Here's a specific example: Suppose there are two containers in the cluster: Container A is a "batch processing task" that handles offline reports (low latency sensitivity, high resource consumption), and Container B is an "authentication service" for user login (high latency sensitivity, medium resource consumption). When the host machine experiences resource alerts, the system compares and finds that migrating Container A can most effectively alleviate the pressure without significantly impacting the user experience. Therefore, Container A is selected as the target container for migration.

[0054] This embodiment uses a multi-dimensional indicator screening mechanism to determine the containers to be migrated, avoiding core business interruptions caused by blind migration and ensuring the stability of the cluster during resource scheduling. By combining "service type, load conditions, and latency sensitivity", it achieves fine-grained resource scheduling, balancing the overall performance of the cluster with business continuity.

[0055] In an optional embodiment of the present invention, the method further includes: generating an initial memory snapshot during the migration of the target container from the source node to the target node, monitoring memory write pages in the source node, determining incremental data generated during the migration based on the memory write pages, and synchronizing the initial memory snapshot and incremental data to the target node.

[0056] To ensure container state consistency during migration, this solution introduces an incremental synchronization mechanism while transferring the container base image and initial memory snapshot to the target node. During migration execution, modified pages in the source node's container memory are continuously monitored; these modified portions are identified as dirty pages.

[0057] Specifically, by monitoring and recording memory write operations, incremental data generated during the migration process (i.e., data newly generated or modified during the migration) is captured in real time. Before switching service nodes, this incremental data is synchronized to the target node in batches and quickly until the memory states of the source node and the target node are highly consistent, at which point the final switch operation is performed, thereby compressing service interruption time to the millisecond level.

[0058] This embodiment improves container migration efficiency by combining "basic snapshots + incremental synchronization", ensuring seamless connection of business states before and after migration, achieving true online smooth migration, and ensuring high availability of business systems.

[0059] In an optional embodiment of the present invention, the connection request for the target container received by the source node is monitored, and the connection request is redirected to the target node.

[0060] During container or service migration, due to changes in network topology and delays in the effectiveness of service discovery mechanisms (such as DNS updates and load balancing configuration synchronization), clients may still send requests to the source node for a short period. To avoid request loss or service interruption during migration, this embodiment deploys a request redirection mechanism on the source node.

[0061] Specifically, when the target node has completed service startup and is ready to take over traffic, the source node will enter "forwarding mode." At this time, the source node continuously monitors all incoming network traffic destined for the migrated service. Once a request for the migrated service is detected, the source node no longer attempts to process the request locally, but instead transparently forwards it to the target node. Redirection refers to the source node, upon receiving a data packet, modifying the target address or establishing a proxy tunnel to redirect the user request to the target node in real time, where the target node executes the actual business logic and returns a response.

[0062] For example, the order service has been migrated from "Server A" to "Server B," but external user requests are still sent to "Server A" due to caching. "Server A" recognizes that the request belongs to the migrated order service, immediately intercepts it, and quickly forwards the request to "Server B." Users are unaware of the physical migration of the service on the front end, but their requests still receive normal responses, achieving zero downtime at the business level.

[0063] This embodiment solves the "time lag" problem caused by the service discovery mechanism during the update process, ensuring business continuity during the migration process; the client is unaware of the physical location change of the backend service, and does not need to re-establish a connection or update the configuration, thus improving the user experience.

[0064] In an optional embodiment of the present invention, the migration triggering condition includes: the resource pressure index is greater than or equal to a first preset threshold and the duration is not less than a preset target duration.

[0065] To ensure high stability in container migration decisions and avoid frequent and unnecessary container migrations due to momentary fluctuations in business systems, a triggering mechanism employing both numerical thresholds and time windows is adopted. Specifically, resource pressure metrics of the target node (such as CPU utilization, memory usage, disk I / O, CPU scheduling latency, and memory reclamation frequency) are monitored in real time. The container migration operation is formally triggered when the monitored metrics meet the following two conditions: Threshold trigger condition: The resource pressure index exceeds a preset threshold, which defines the critical point at which a node enters a "high load state".

[0066] Time trigger condition: The above high load state must continue to reach or exceed the preset target duration, such as 30 seconds.

[0067] This embodiment effectively eliminates false migration triggers caused by short-term bursts of traffic by introducing the dimension of duration, preventing frequent load migration between multiple nodes and ensuring the overall stability of the cluster.

[0068] In an optional embodiment of the present invention, the resource pressure index is obtained based on one or more of the following indicators: CPU pressure, memory pressure, I / O pressure, CPU scheduling latency, and memory reclamation frequency.

[0069] To comprehensively and objectively assess the load status of source nodes during operation, this embodiment constructs a multi-dimensional resource stress assessment mechanism. Specifically, the resource stress index is not a single resource utilization rate, but consists of a set of composite indicators characterizing the system's operational quality, aiming to assess the health status of nodes by quantifying the degree of resource contention.

[0070] Resource stress metrics include the following dimensions: compute resource stress, memory resource stress, and I / O resource stress.

[0071] Among them, computing resource pressure includes CPU pressure and CPU scheduling latency, which are used to measure the degree of blocking of processes while waiting for CPU time slices. Memory resource pressure includes memory pressure and memory reclamation frequency / intensity; I / O resource pressure includes disk / network I / O pressure, used to monitor the impact of I / O latency on overall system throughput.

[0072] In actual evaluation, the above indicators can be weighted or thresholded based on business characteristics. For example, by quantifying, normalizing, and weighting the various indicators, a resource pressure indicator can be obtained. Based on this resource pressure indicator, "sub-healthy" states caused by resource contention can be identified in advance before resource utilization reaches its peak. This embodiment enables the early triggering of container migration operations before significant service quality degradation occurs, ensuring business continuity and stability.

[0073] In an optional embodiment of the present invention, after caching the target hot file block to the target node and before performing the container migration operation, the method further includes: comparing the resource pressure index of each monitored node with a second preset threshold, and determining a plurality of candidate nodes whose resource pressure index is less than the second preset threshold; the second preset threshold is less than a first preset threshold; determining the target node that has cached the target hot file corresponding to the target container from the plurality of candidate nodes; and triggering a container migration operation to migrate the target container to the target node.

[0074] In a containerized environment, selecting a suitable "target node" is crucial when the source node triggers container migration due to excessive load. Considering only whether the target node has space while ignoring its current real-time load and the required data loading time may lead to the target node crashing rapidly after migration, or slow business startup due to large amounts of data loading. Therefore, this solution introduces a selection mechanism combining "dual threshold filtering" and "data readiness."

[0075] Before performing the migration, follow these steps to select the target node: First, the resource pressure indicators of all potential target nodes are compared with a second preset threshold, and nodes with resource pressure indicators lower than the second preset threshold are selected as candidate nodes. This second threshold is lower than a first preset threshold that triggers migration, ensuring that the target nodes are not only not overloaded but also have sufficient resource redundancy, thereby guaranteeing system stability after migration.

[0076] Secondly, within the aforementioned candidate node set, we further retrieve which nodes have pre-cached the hot file blocks required by the business to be migrated, and use these pre-cached hot file blocks as the target nodes for container migration. This avoids the need to temporarily load the data required for container startup when the container starts, shortens the startup time of the business on the target node, and achieves near-seamless container migration. The pre-caching of hot file blocks on the target node includes two scenarios: one is by pre-pulling the hot file blocks and caching them on the target node, and the other is that the images of other containers running on the target node include the hot file blocks required by the target container (therefore, there is no need to pull the corresponding hot file blocks again when starting the target container).

[0077] If none of the candidate target nodes have pre-cached the corresponding hot file blocks, then the node with the lowest resource pressure index will be selected as the target node for container migration.

[0078] In an optional embodiment of the present invention, after the target container migration is completed, while the target container is running, the resource pressure changes of the target node and the performance indicators of the target container are monitored, and the second preset threshold is adjusted according to the resource pressure changes and performance indicators.

[0079] After completing the container migration, the process is not simply ended, but rather a closed-loop mechanism of "migration-monitoring-feedback-optimization" is established. Specifically, after the target container is migrated to the target node and enters the running state, two dimensions of indicators will be continuously monitored in real time: first, the changes in resource pressure on the target node after taking over the container (such as changes in memory pressure, I / O pressure, and network throughput); and second, the actual running performance of the container on the target node (such as request processing time, packet loss rate, or service availability).

[0080] The real-time monitoring data is compared and analyzed with the state before migration and the preset migration trigger conditions. If the comparison and analysis results show that the performance improvement of the container after migration does not meet expectations, or the target node quickly enters a high-load state, the second preset threshold is lowered, thereby adjusting the selection strategy for the target node to optimize subsequent migration decisions. For example, nodes with less resource consumption (more remaining resources) will be selected as the target nodes for container migration.

[0081] This embodiment ensures that the ultimate goal of migration is to "improve user experience" by incorporating "performance metrics" into the feedback loop, which greatly enhances the robustness of the system. By adjusting the target node selection strategy, invalid container migrations are reduced, thereby reducing network bandwidth consumption and instantaneous performance jitter caused during the migration process.

[0082] In an optional embodiment of the present invention, the ratio of target hot file blocks pre-cached to the target node to the file blocks actually needed to be accessed when the target container is started on the target node is calculated, and the startup latency of the target container is calculated. Based on the ratio and the startup latency, the hot file block filtering strategy is adjusted.

[0083] To shorten startup time, some critical files, known as hot file blocks, are typically pre-cached on the target node. However, due to dynamic changes in workload, the pre-defined hot file blocks may not perfectly match the actual file blocks required during startup. If too few files are cached, frequent remote reads during startup will increase latency; if too many are cached, storage resources on the target node will be wasted. Therefore, a feedback mechanism based on actual runtime data is needed to dynamically optimize the hot file block selection strategy.

[0084] The specific steps are as follows: It records and collects a list of all files actually accessed by the target container during the startup process in real time, and synchronously measures the actual startup latency (startup time) from the issuance of the startup command to the full operation of the container.

[0085] By comparing the "list of actually accessed files" with the "list of pre-cached files," and calculating the ratio between the actually accessed files and the pre-cached files—the pre-hit rate—the accuracy of the current hot file filtering strategy can be evaluated. A high pre-hit rate indicates that the vast majority of pre-cached files have been used; a low pre-hit rate indicates that a large number of actually needed files have not been pre-cached. Therefore, the pre-hit rate can be used to determine whether the amount of hot file blocks cached has achieved the expected container startup and running effect.

[0086] In addition, the startup latency of the target container on the target node can be used to determine whether the current cache size has achieved the expected container startup and running effect. If the expected container startup and running effect has not been achieved, the hot file block filtering strategy can be adjusted. For example, if the pre-hit rate is low and the startup latency is large, the access heat threshold can be lowered and the range of hot file blocks for the next pre-cached session can be expanded to improve the pre-hit rate. If the pre-hit rate is extremely high and there is redundancy in the pre-cached hot file blocks, the access heat threshold can be appropriately increased to narrow the range of hot file blocks for the next pre-cached session.

[0087] This embodiment uses a dual feedback mechanism of "pre-hit rate" and "startup delay" to dynamically adjust the cache size, effectively solving the problem of wasted storage resources caused by blindly expanding the cache range, and achieving the best balance between service performance and storage space.

[0088] In an optional embodiment of the present invention, in order to minimize network bandwidth usage and time overhead during the migration process while ensuring data consistency, the system adopts a differentiated data synchronization strategy for different storage types.

[0089] First, regarding synchronization processing for shared storage (such as volumes based on the Container Storage Interface (CSI)). Since the data in shared storage is physically stored in an independent storage cluster, rather than bound to a specific node, migrating a target container from the source node to the target node does not require physical copying of the actual data in the storage volume. Only a mount operation needs to be performed on the target node to update the mount relationship between the target container and the shared storage volume, allowing the target container to directly access the original storage volume. This approach reduces the time complexity of data migration to constant level, shortening the migration cycle.

[0090] Secondly, the synchronization of temporary local data within the container (such as local storage like emptyDir) is addressed. Temporary data stored on the source node's local disk must be physically transferred because it lacks shared attributes. To avoid the significant overhead of full synchronization, this solution employs a differentiated transfer mechanism (e.g., using the rsync tool or a custom incremental synchronization algorithm). During the migration process, only file blocks that have changed or newly generated files after the migration has started are identified and transferred—that is, incremental data.

[0091] This embodiment optimizes resource utilization by distinguishing between "shared storage" and "local temporary storage"; for large-scale data volumes, it solves the problem of excessively long business interruption time caused by data synchronization during migration by avoiding repeated transmission.

[0092] In an optional embodiment of the present invention, after the target container starts, the final switchover is completed through the following steps: First, it is confirmed that the target container on the target node is running normally. Then, by updating the routing configuration, user requests are quickly switched from the source node to the target node. After the traffic has been smoothly transferred, the target container on the source node is shut down and its occupied resources are reclaimed. This "switch-before-release" mechanism, combined with real-time monitoring, effectively avoids service interruption and ensures a smooth transition during container migration.

[0093] The container startup method of this invention, on the one hand, uses a hot file block filtering mechanism to replace full fetching, which reduces resource waste while ensuring container startup speed; on the other hand, by advancing the pre-fetching time to before container migration occurs, it eliminates the waiting time for the target node to load the image, realizes near-seamless startup of container migration, and enhances the real-time response capability of the business.

[0094] Figure 2 This is a schematic diagram of the main modules of the container startup device 200 according to an embodiment of the present invention.

[0095] like Figure 2As shown, the container initiation device 200 of this embodiment includes: a screening module 201 and a prediction module 202, wherein, The filtering module 201 is used to monitor the file blocks that each container needs to access during its running state and the access frequency of each file block, and to filter out the hot file blocks that each container needs to access based on the access frequency. The prediction module 202 is used to take each node in the cluster as the target node for container migration and perform the following operations on the target node: based on the container migration history events, predict that the target container will be migrated to the target node within a preset time period in the future, pre-fetch the target hot file block from the source node to which the target hot file block belongs, cache the target hot file block in the target node, so that the target container can be started based on the target hot file block cached in the target node during the migration of the target container from the source node to the target node.

[0096] In an optional embodiment of the present invention, the filtering module 201 is further configured to load a monitoring program in the kernel of each node, and monitor the access information of each container for each file block in the running state through the monitoring program; and calculate the attenuation access frequency corresponding to each file block based on the access information.

[0097] In an optional embodiment of the present invention, the filtering module 201 is further configured to, for each container, group the multiple file blocks included in the container's image by image layer; sort the multiple file blocks in each group according to access popularity; and determine the hot file blocks from the multiple files in each group based on the sorting results.

[0098] In optional embodiments of the present invention, such as Figure 3 As shown, the container migration device also includes a container migration module 203. The container migration module 203 is further used to monitor the resource pressure indicators of each node in the cluster after the target hot file block is cached to the target node and before the container migration operation is performed. When the monitoring results indicate that the resource pressure indicators of the source node have reached the preset migration triggering conditions, the target container to be migrated is determined from the source node and the container migration operation is triggered.

[0099] In an optional embodiment of the present invention, the container migration module 203 is further configured to determine the service type, access popularity and latency sensitivity of each container in the source node; and to determine the target container to be migrated from the multiple containers according to the service type, access popularity and latency sensitivity corresponding to the multiple containers in the source node.

[0100] In an optional embodiment of the present invention, the container migration module 203 is further configured to generate an initial memory snapshot, monitor memory write pages in the source node, determine incremental data generated during the migration process based on the memory write pages, and synchronize the initial memory snapshot and incremental data to the target node during the migration process of the target container from the source node to the target node. And / or, Monitor the connection requests received by the source node for the target container and redirect the connection requests to the target node.

[0101] In an optional embodiment of the present invention, the migration triggering condition includes: the resource pressure index is greater than or equal to a first preset threshold and the duration is not less than a preset target duration; And / or, Resource stress metrics are derived from one or more of the following metrics: CPU stress, memory stress, I / O stress, CPU scheduling latency, and memory reclamation frequency.

[0102] In an optional embodiment of the present invention, the container migration module 203 is further configured to, after caching the target hot file block to the target node and before performing the container migration operation, compare the resource pressure index of each monitored node with a second preset threshold, and determine a number of candidate nodes whose resource pressure index is less than the second preset threshold; the second preset threshold is less than the first preset threshold; determine the target node that has cached the target hot file corresponding to the target container from the number of candidate nodes; and trigger the container migration operation to migrate the target container to the target node.

[0103] In an optional embodiment of the present invention, the container migration module 203 is further configured to monitor the resource pressure changes of the target node and the performance indicators of the target container while the target container is running after the target container migration is completed, and adjust the second preset threshold according to the resource pressure changes and performance indicators. And / or, Calculate the ratio of target hot file blocks pre-cached to the target node to the file blocks actually needed to be accessed when the target container starts on the target node, and calculate the startup latency of the target container. Based on the ratio and startup latency, adjust the hot file block filtering strategy.

[0104] The container startup device of this invention combines multiple data transmission protocols and multiple network interfaces, establishes multiple persistent connections based on the combination results, and binds multiple persistent connections. This allows the client to use any one or more persistent connections with high transmission performance when sending data to the server, and achieves seamless switching between different persistent connections, thereby improving the utilization of network resources, improving data transmission efficiency, and improving the user's data transmission experience.

[0105] Figure 4 Another exemplary system architecture 400 is shown where the container startup method or container startup apparatus of the present invention can be applied.

[0106] like Figure 4 As shown, system architecture 400 may include a cluster 401 with multiple nodes, a network 402, and a server 403 that performs container migration. Network 402 serves as the medium for providing a communication link between cluster 401 and server 403. Network 402 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0107] Cluster 401 interacts with server 403 via network 402 to receive or send data. Server 403 is responsible for monitoring the status of each node within cluster 401, predicting container startup, and migrating containers. Server 403 monitors the file blocks that each container within cluster 401 needs to access and the access frequency of each file block during its running state, and filters out the hot file blocks that each container needs to access based on the access frequency; it uses each node within cluster 401 as the target node for container migration and performs the following operations for the target node: based on historical container migration events, it predicts that the target container will migrate to the target node within a preset time period in the future; it pre-fetches the target hot file block from the source node to which the target hot file block belongs; and it caches the target hot file block on the target node. During the migration of the target container from the source node to the target node, it starts the target container based on the cached target hot file block on the target node, thereby achieving load balancing and ensuring that the cluster service responds to user needs in a timely manner.

[0108] It should be noted that the container startup method provided in this embodiment of the invention can be executed by server 403, and correspondingly, the container startup device can be set in server 403.

[0109] It should be understood that Figure 4 The number of clusters, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of clusters, networks, and servers can be used.

[0110] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing an electronic device according to embodiments of the present invention. Figure 5 The cluster shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0111] like Figure 5As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0112] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0113] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this invention.

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

[0115] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0116] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may include a filtering module and a prediction module. The names of these modules do not necessarily limit the module itself; for example, a prediction module may also be described as "a module that predicts that a target container will migrate to a target node within a preset time period in the future."

[0117] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: monitoring the file blocks that each container needs to access during its running state and the access frequency of each file block; filtering out the hot file blocks that each container needs to access based on the access frequency; designating each node in the cluster as a target node for container migration; and performing the following operations on the target node: based on container migration history events, predicting that the target container will migrate to the target node within a preset time period in the future; pre-fetching the target hot file block from the source node to which the target hot file block belongs; caching the target hot file block to the target node; and starting the target container based on the cached target hot file block during the migration of the target container from the source node to the target node.

[0118] According to the technical solution of the present invention, on the one hand, the hot file block filtering mechanism is used to replace the full pull, which reduces resource waste while ensuring the container startup speed; on the other hand, by advancing the pre-pull timing to before the container migration occurs, the waiting time for the target node to load the image is eliminated, realizing the near-seamless startup of the container migration and enhancing the real-time response capability of the business.

[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A container startup method, characterized in that, include: Monitor the file blocks that each container needs to access while it is running, as well as the access frequency of each file block, and filter out the hot file blocks that each container needs to access based on the access frequency. Each node in the cluster is used as the target node for container migration, and the following operations are performed on the target node: based on container migration history events, it is predicted that the target container will migrate to the target node within a preset time period in the future; the target hot file block corresponding to the target container is pre-fetched from the source node; the target hot file block is cached in the target node; so that during the process of migrating the target container from the source node to the target node, the target container is started based on the target hot file block cached in the target node.

2. The method according to claim 1, characterized in that, The monitoring of the file blocks that each container needs to access during operation, as well as the access frequency of each file block, includes: A monitoring program is loaded into the kernel of each node to monitor the access information of each container to each file block while it is running. Based on the access information, the attenuation access frequency corresponding to each file block is calculated.

3. The method according to claim 1 or 2, characterized in that, The process of filtering out the hot file blocks that each container needs to access based on access frequency includes: For each container: The image of the container is grouped into multiple file blocks by image layer; Sort the multiple file blocks within each group according to the access popularity; Based on the sorting results, hot file blocks are identified from multiple files within each group.

4. The method according to claim 1, characterized in that, After caching the target hot file block to the target node, and before performing the container migration operation, the method further includes: Monitor the resource pressure indicators of each node in the cluster. If the monitoring results indicate that the resource pressure indicator of the source node has reached the preset migration trigger condition, determine the target container to be migrated from the source node and trigger the container migration operation.

5. The method according to claim 4, characterized in that, The step of determining the target container to be migrated from the source node includes: The service type, access frequency, and latency sensitivity of each container within the source node are determined. Based on the service type, access frequency, and latency sensitivity of the multiple containers within the source node, the target container to be migrated is determined from the multiple containers.

6. The method according to claim 1, characterized in that, Also includes: During the migration of the target container from the source node to the target node, an initial memory snapshot is generated, memory write pages in the source node are monitored, incremental data generated during the migration is determined based on the memory write pages, and the initial memory snapshot and the incremental data are synchronized to the target node. And / or, Monitor the connection requests received by the source node for the target container, and redirect the connection requests to the target node.

7. The method according to claim 4, characterized in that, The migration triggering conditions include: the resource pressure index is greater than or equal to a first preset threshold and the duration is not less than a preset target duration; And / or, The resource pressure metrics are derived based on one or more of the following metrics: CPU pressure, memory pressure, I / O pressure, CPU scheduling latency, and memory reclamation frequency.

8. The method according to claim 4, characterized in that, After caching the target hot file block to the target node, and before performing the container migration operation, the method further includes: The resource pressure index of each node is compared with the second preset threshold, and multiple candidate nodes whose resource pressure index is less than the second preset threshold are identified; the second preset threshold is less than the first preset threshold. From the multiple candidate nodes, the target node that has cached the target hot file corresponding to the target container is determined; Trigger a container migration operation to migrate the target container to the target node.

9. The method according to claim 4, characterized in that, Also includes: After the target container migration is completed, while the target container is running, monitor the changes in resource pressure of the target node and the performance indicators of the target container, and adjust the second preset threshold according to the changes in resource pressure and the performance indicators; And / or, Calculate the ratio of target hot file blocks pre-cached to the target node to the file blocks actually needed to access when starting the target container on the target node, and calculate the startup latency of the target container. Based on the ratio and the startup latency, adjust the hot file block filtering strategy.

10. A container starting device, characterized in that, include: The filtering module and the prediction module, among which, The filtering module is used to monitor the file blocks that each container needs to access during its running state and the access frequency of each file block, and to filter out the hot file blocks that each container needs to access during its running state based on the access frequency. The prediction module is used to use each node in the cluster as the target node for container migration, and to perform the following operations on the target node: based on container migration history events, predict that the target container will migrate to the target node within a preset time period in the future; pre-fetch the target hot file block from the source node to which the target hot file block belongs; cache the target hot file block in the target node; so that during the process of migrating the target container from the source node to the target node, the target container is started based on the target hot file block cached in the target node.

11. An electronic device for container startup, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-9.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

13. A computer program product, comprising a computer program, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images