Container instance migration method, device and equipment based on hierarchical data block and medium

Abstract

This application provides a method, apparatus, device, and medium for migrating container instances based on hierarchical data blocks. The method includes: performing hierarchical processing on the container instances to be migrated based on a data modification frequency threshold and a cross-instance reuse threshold to obtain data blocks corresponding to each layer; constructing a source tag set for the container instances to be migrated based on the hash identifier of each data block; determining a set of data blocks to be migrated based on the source tag set and a global block identifier library; calculating a block heat value for each data block to be migrated that belongs to the intermediate layer or the user layer based on the data modification frequency and cross-cluster reuse count of the data block; and migrating each data block to be migrated to the target cloud-native cluster using a differentiated migration method based on the block heat value and the layer to which the data block belongs. This effectively reduces the amount of data to be migrated and improves migration efficiency.

Description

Technical Field

[0001] This application relates to the field of container migration technology, specifically to a method, apparatus, device, and medium for migrating container instances based on hierarchical data blocks. Background Technology

[0002] In existing cloud-native container cluster application scenarios, container instances often need to undergo cross-node or cross-cluster migration operations due to resource shortages, hardware failures, load balancing, or cluster scaling requirements. Current technologies typically involve packaging the container's running state and all file system layers on the source node into a complete image, pushing this complete image to a central image repository, then having the target node pull the complete image from the repository. Finally, the target node recreates and starts the container instance based on the pulled image to achieve the container instance migration operation. This migration method involves full data transmission, and since the full data includes a large amount of unchanging base and intermediate layer data that does not need to be transmitted repeatedly, it results in a significant waste of network bandwidth. This is especially true for microservice containers, where the complete image size can reach hundreds of MB to several GB, while the actual changed data that needs to be synchronized is only a few MB to tens of MB. Secondly, the entire process of packaging, pushing, and pulling the complete image is time-consuming, leading to high migration latency and a significantly extended service unavailability window, making it unsuitable for business scenarios with extremely high real-time requirements, such as financial transactions, online games, and industrial control. Therefore, it can be seen that existing instance migration methods suffer from resource waste and high migration latency. Summary of the Invention

[0003] To address the problems in the prior art, this application provides a container instance migration method, apparatus, device, and medium based on hierarchical data blocks, which can effectively reduce the amount of data migration for container instances, save migration resources, and improve migration efficiency.

[0004] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a container instance migration method based on hierarchical data blocks, comprising: obtaining a container instance to be migrated from a source cloud-native cluster; performing quantitative data hierarchical processing on the container instance to be migrated based on a data modification frequency threshold and a cross-instance reuse threshold to obtain multiple data blocks corresponding to the base layer, intermediate layer, and user layer respectively; calculating the hash identifier of each data block; updating the correspondence between each data block in a global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster; constructing a source tag set for the container instance to be migrated based on the hash identifier of each data block; and based on the source tag set and the hash identifier of each data block in the global block identifier library... The correspondence determines the set of data blocks to be migrated for the container instance to be migrated. For each data block to be migrated that belongs to the intermediate layer or the user layer in the set of data blocks to be migrated, the block heat value of the data block to be migrated is calculated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated. Data blocks to be migrated that belong to the basic layer or that have a block heat value higher than a preset block heat value are pre-cached to the target cloud-native cluster through a transport layer security protocol encrypted transmission link. For each data block to be migrated that has a block heat value not higher than the preset block heat value, the data block to be migrated is migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data block to be migrated belongs.

[0005] In some examples, the quantitative data layering processing of the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the base layer, intermediate layer, and user layer respectively includes: for each data block in the container instance to be migrated, obtaining the data modification frequency of the data block and calculating the cross-instance reuse of the data block in the source cloud-native cluster; classifying data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold as base layer data blocks; classifying data blocks whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold as user layer data blocks; and classifying data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold, or whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold, as intermediate layer data blocks.

[0006] In some examples, updating the correspondence between the data blocks in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster includes: for each data block of the container instance to be migrated, obtaining the data block identifier of the data block, and searching for the data block identifier in the global block identifier library; if found, adding the data modification frequency, hash identifier, and source identifier of the source cloud-native cluster of the data block to the correspondence between the data blocks; if not found, constructing the correspondence between the data blocks based on the data modification frequency, hash identifier, hierarchy identifier, data block identifier, and source identifier of the data blocks, and adding the correspondence to the global block identifier library.

[0007] In some examples, the set of data blocks to be migrated for the container instance to be migrated is determined based on the correspondence between the source tag set and each data block in the global block identifier library. This includes: for each hash identifier in the source tag set, searching for at least one end identifier corresponding to the hash identifier in the global block identifier library; if the at least one end identifier includes the source end identifier but does not include the target end identifier of the target cloud-native cluster, then the data block corresponding to the hash identifier is taken as the data block to be migrated, and the set of data blocks to be migrated is composed of at least one of the data blocks to be migrated.

[0008] In some examples, calculating the block popularity value of the data block to be migrated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated includes: obtaining the data modification frequency and at least one end identifier corresponding to the data block to be migrated from the global block identifier library, and using the number of at least one end identifier as the cross-cluster reuse count of the data block to be migrated; obtaining the layer weight, cross-cluster reuse weight, and data modification weight of the layer to which the data block to be migrated belongs; and using a layer weighted algorithm to calculate the data modification frequency, the cross-cluster reuse count, the layer weight, the cross-cluster reuse weight, and the data modification weight to obtain the block popularity value of the data block to be migrated.

[0009] In some examples, the layer migration method based on the layer to which the data block to be migrated belongs migrates the data block to the target cloud-native cluster. This includes: if the data block to be migrated belongs to the intermediate layer, then the data block to be migrated is compressed using a compression ratio algorithm that matches the block heat value of the data block to be migrated, resulting in a compressed data block. The compressed data block is then transmitted to the target cloud-native cluster using fragmented transmission and breakpoint resumption. If the data block to be migrated belongs to the user layer, then the data block to be migrated is migrated to the target cloud-native cluster. Incremental data is tracked in real-time using a copy-on-write mechanism. When the incremental data reaches a preset incremental threshold, or when the maximum latency of the incremental data reaches a duration threshold, the incremental data is transmitted as a data increment packet to the target cloud-native cluster.

[0010] In some examples, the method further includes: after each of the data blocks to be migrated is cached or migrated to the target cloud-native cluster, adding the target identifier of the target cloud-native cluster to the mapping relationship of the data blocks to be migrated in the global block identifier library; after all the data blocks to be migrated in the set of data blocks to be migrated have been migrated to the target cloud-native cluster, obtaining multiple target mapping relationships corresponding to the container instance identifier of the container instance to be migrated from the global block identifier library; filtering out multiple first mapping relationships from the multiple target mapping relationships based on the source identifier, and constructing a source hash tree based on the data block identifier and hash identifier in the multiple first mapping relationships; filtering out multiple second mapping relationships from the multiple target mapping relationships based on the target identifier, and constructing a target hash tree based on the data block identifier and hash identifier in the multiple second mapping relationships; and using a hash tree root verification method to verify the source hash tree and the target hash tree. The target hash tree undergoes consistency verification. If the consistency verification passes, the data block corresponding to the container instance to be migrated is deleted from the source cloud-native cluster, and the source identifier is deleted from the correspondence of the container instance to be migrated in the global block identifier library. If the consistency verification fails, the first differential hash identifier in the source hash tree and the second differential hash identifier in the target hash tree are determined by comparing the nodes of the source hash tree and the target hash tree. The data block corresponding to the first differential hash identifier is re-migrated to the target cloud-native cluster using a directed retransmission method. The data block corresponding to the second differential hash identifier in the target cloud-native cluster is deleted, and the second differential hash identifier is deleted from the correspondence in the global block identifier library. After the directed retransmission is completed, a new source hash tree and a new target hash tree are reconstructed based on the global block identifier library, and consistency verification is performed until the verification passes or a preset verification count threshold is reached.

[0011] Secondly, this application provides a container instance migration device based on hierarchical data blocks, comprising: an acquisition unit, configured to acquire a container instance to be migrated from a source cloud-native cluster, perform quantitative data hierarchical processing on the container instance to be migrated based on a data modification frequency threshold and a cross-instance reusability threshold to obtain multiple data blocks corresponding to the base layer, intermediate layer, and user layer, calculate the hash identifier of each data block, update the correspondence of each data block in a global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster, and construct a source tag set of the container instance to be migrated based on the hash identifier of each data block; and a calculation unit, configured to calculate the hash identifier of each data block in the global block identifier library. The correspondence of data blocks determines the set of data blocks to be migrated for the container instance to be migrated. For each data block to be migrated belonging to the intermediate layer or the user layer in the set of data blocks to be migrated, the block heat value of the data block to be migrated is calculated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated. The migration unit is used to pre-cache the data blocks to be migrated belonging to the basic layer or the data blocks to be migrated with a block heat value higher than a preset block heat value to the target cloud-native cluster through a transport layer security protocol encrypted transmission link. For each data block to be migrated with a block heat value not higher than the preset block heat value, the data block to be migrated is migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data block to be migrated belongs.

[0012] Thirdly, this application provides an electronic 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 instance migration method based on hierarchical data blocks.

[0013] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the container instance migration method based on hierarchical data blocks.

[0014] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the container instance migration method based on hierarchical data blocks.

[0015] As can be seen from the above technical solutions, this application provides a container instance migration method, apparatus, device, and medium based on hierarchical data blocks. By quantitatively layering the container instance to be migrated according to the data modification frequency and cross-instance reusability, it accurately distinguishes the basic layer, intermediate layer, and user layer data blocks. Combined with the block heat value calculation, it adopts differentiated migration strategies for data blocks of different levels and heat values, pre-caches highly reusable and low-change data blocks to the target cloud-native cluster, and performs hierarchical adaptation migration for highly changeable and low-reusable data blocks. This is beneficial for optimizing the migration process, selecting a migration method that is compatible with the data blocks for migration, and avoiding the use of a one-size-fits-all full migration method to migrate all data blocks, which would cause a large amount of unchanging basic and intermediate layer data that does not need to be repeatedly transmitted to be repeatedly transmitted, resulting in excessive network bandwidth consumption and ineffective consumption of migration resources. Migrating using an appropriate migration method can improve the migration efficiency of different types of data blocks, reduce invalid data transmission links, avoid redundant data occupying migration bandwidth and slowing down the migration progress, thereby improving overall migration efficiency and shortening migration time. At the same time, by maintaining the correspondence of each data block through a global block identifier library, it is possible to quickly locate the data blocks to be migrated that exist in the source cloud-native cluster but not in the target cloud-native cluster, effectively avoiding redundant data transmission problems caused by full migration, significantly reducing the waste of network bandwidth and other resources, significantly shortening the entire process of image packaging, pushing, and pulling, reducing migration latency, and stably adapting to business scenarios with extremely high real-time requirements such as financial transactions, online games, and industrial control. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the container instance migration method based on hierarchical data blocks in an embodiment of this application. Figure 2 This is a structural diagram of a container instance migration device based on hierarchical data blocks in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0020] In view of the problems existing in the prior art, this application provides a container instance migration method, apparatus, device and medium based on hierarchical data blocks. By quantitatively hierarchically layering the container instance to be migrated according to the data modification frequency and cross-instance reusability, the basic layer, intermediate layer and user layer data blocks are accurately distinguished. Combined with the block heat value calculation, differentiated migration strategies are adopted for data blocks of different levels and different heat. Highly reusable and low-change data blocks are pre-cached to the target cloud-native cluster. Highly changeable and low-reusable data blocks are adapted and migrated according to the level. This is conducive to optimizing the migration process, selecting the migration method adapted to the data blocks for migration, and avoiding the use of a one-size-fits-all full migration method to migrate all data blocks. This avoids the repeated transmission of a large amount of unchanging basic layer and intermediate layer data that does not need to be transmitted repeatedly, resulting in excessive network bandwidth consumption and ineffective consumption of migration resources. Migrating using an appropriate migration method can improve the migration efficiency of different types of data blocks, reduce invalid data transmission links, avoid redundant data occupying migration bandwidth and slowing down the migration progress, thereby improving overall migration efficiency and shortening migration time. At the same time, by maintaining the correspondence of each data block through a global block identifier library, it is possible to quickly locate the data blocks to be migrated that exist in the source cloud-native cluster but not in the target cloud-native cluster, effectively avoiding redundant data transmission problems caused by full migration, significantly reducing the waste of network bandwidth and other resources, significantly shortening the entire process of image packaging, pushing, and pulling, reducing migration latency, and stably adapting to business scenarios with extremely high real-time requirements such as financial transactions, online games, and industrial control.

[0021] To improve container instance migration efficiency and reduce resource waste during migration, this application provides an embodiment of a container instance migration method based on hierarchical data blocks. See [link to relevant documentation]. Figure 1 The container instance migration method based on hierarchical data blocks specifically includes the following: Step S110: Obtain the container instance to be migrated from the source cloud-native cluster. Perform quantitative data layering processing on the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the basic layer, intermediate layer and user layer respectively. Calculate the hash identifier of each data block. Update the correspondence between each data block in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster. Construct the source tag set of the container instance to be migrated based on the hash identifier of each data block.

[0022] Here, "container instance to be migrated" refers to a container instance that needs to be migrated from the node where it resides to another node. "Source cloud-native cluster" refers to a cloud-native cluster with Kubernetes as its core and containing the container instance to be migrated. "Data modification frequency threshold" is a quantitative standard set to determine whether a data block is frequently or infrequently modified. "Cross-instance reuse threshold" is a quantitative standard set to determine the degree to which a data block is reused by container instances. A data block is the smallest processing unit of data in a container instance. "Base layer data block" refers to data blocks in a container instance that are modified infrequently but have high instance reuse; these are often data blocks related to the container instance's runtime environment, operating system layer, and common dependencies. "Middle layer data block" refers to data blocks in a container instance that are modified infrequently and have low instance reuse, or data blocks that are modified frequently but have high instance reuse; these are often relatively stable data blocks such as application dependencies and framework libraries. "User layer data block" refers to data blocks in a container instance that are modified frequently and have low instance reuse; these are often top-level data blocks in a container instance that frequently change, such as user data, logs, configurations, and runtime states. A hash identifier is a unique identifier string obtained by hashing a data block, used to quickly determine whether data blocks are identical. An endpoint identifier is used to identify a cloud-native cluster; for example, the endpoint identifier of a source cloud-native cluster identifies the source cloud-native cluster itself. A global block identifier library refers to a globally unified index library that maintains data blocks from multiple cloud-native clusters.

[0023] Specifically, in step S110, the quantitative data layering processing of the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the base layer, intermediate layer, and user layer respectively includes: for each data block in the container instance to be migrated, obtaining the data modification frequency of the data block and calculating the cross-instance reuse of the data block in the source cloud-native cluster; classifying data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold as base layer data blocks; classifying data blocks whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold as user layer data blocks; and classifying data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold, or whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold, as intermediate layer data blocks.

[0024] Among these, data modification frequency refers to the number of times a data block is written, updated, or modified per unit of time, used to measure the degree of modification of the data block. Cross-instance reusability refers to the number or proportion of times a data block is used and shared by multiple different container instances within the cluster, used to measure the generality of the data block. Quantitative data stratification refers to automatically and objectively dividing data blocks into different levels through statistically quantifiable and calculable numerical indicators, rather than relying on manual or experience-based judgment.

[0025] In addition, the identifier of the container instance to be migrated can be added to the mapping relationship of each data block of the container instance to be migrated in the global block identifier library. The identifier of the container instance to be migrated is a unique identifier for the container instance to be migrated.

[0026] Therefore, by employing dual thresholds of data modification frequency and cross-instance reusability for quantitative layering, fine-grained and automated classification of container instance data can be achieved, avoiding biases caused by subjective segmentation. This layering approach can accurately distinguish between basic layer data blocks, intermediate layer data blocks, and user layer data blocks, providing a clear hierarchical basis for subsequent migration processes. This facilitates the adoption of migration strategies adapted to the characteristics of data blocks at each layer. By matching suitable migration strategies to data blocks at different layers, the migration efficiency of data blocks at each layer can be improved in a targeted manner, effectively reducing invalid data transmission steps, saving transmission time, and thus improving the overall efficiency of container instance migration.

[0027] Specifically, in the aforementioned step S110, updating the correspondence between each data block in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster includes: for each data block of the container instance to be migrated, obtaining the data block identifier of the data block, and searching for the data block identifier in the global block identifier library; if found, adding the data modification frequency, hash identifier, and source identifier of the source cloud-native cluster of the data block to the correspondence between the data blocks; if not found, constructing the correspondence between the data blocks based on the data modification frequency, hash identifier, hierarchy identifier, data block identifier, and source identifier of the data blocks, and adding the correspondence to the global block identifier library.

[0028] Among them, the data block identifier refers to the unique number of the data block itself. It is the core index for retrieving and locating data blocks in the global block identifier library and is used to quickly match existing data blocks. The layer identifier refers to the unique identifier that marks the layer (basic layer, intermediate layer, user layer) to which the data block belongs, providing a basis for differentiated migration of subsequent layers.

[0029] After obtaining the hash identifiers of each data block, the system retrieves the corresponding data block's identifier from the global block identifier library to find its stored mapping. This mapping is then expanded by adding new data block information, such as the hash identifier, the source identifier of the source cloud-native cluster, and the latest data modification frequency of the data block. If no mapping is found in the global block identifier library, a mapping is constructed using relevant information, such as the data modification frequency, hash identifier, hierarchy identifier, data block identifier, and the source identifier. This mapping is then added to the global block identifier library for unified maintenance of the data block.

[0030] Therefore, by using data block identifiers as the retrieval basis, and selectively updating the correspondences of existing data blocks or creating correspondences for new data blocks in the global block identifier library, the integrity, real-time performance, low redundancy, and accuracy of all data block information in the global block identifier library can be ensured, providing reliable global data support for container instance migration. Specifically, for existing data blocks, only key information is updated, eliminating the need to repeatedly store complete data, effectively saving storage resources in the global block identifier library and avoiding data redundancy. Simultaneously, the latest modification status and source location of data blocks are synchronized, ensuring accurate location of data blocks and rapid determination of whether data blocks need to be migrated during subsequent migration processes, thereby reducing duplicate data transmission, lowering network overhead, and improving migration efficiency. Furthermore, for new data blocks, their correspondences are fully entered and globally registered, laying a solid foundation for subsequent cross-instance and cross-cluster data deduplication and differentiated migration, effectively avoiding migration failures and data corruption caused by missing data information, and significantly improving the overall efficiency, stability, and reliability of cloud-native cluster container instance migration.

[0031] Step S120: Based on the correspondence between the source tag set and each data block in the global block identifier library, determine the set of data blocks to be migrated for the container instance to be migrated. For each data block to be migrated that belongs to the intermediate layer or the user layer in the set of data blocks to be migrated, calculate the block heat value of the data block to be migrated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated.

[0032] The target cloud-native cluster refers to the cloud-native cluster to which the container instance to be migrated needs to be migrated. The set of data blocks to be migrated refers to the set of data blocks for the container instance to be migrated that exist in the source cloud-native cluster but not in the target cloud-native cluster, selected by comparing the source tag set with the global block identifier library. By removing duplicate data blocks between the target and source cloud-native clusters, the amount of data to be migrated is significantly reduced. A single data block in the set of data blocks to be migrated is the actual data block that needs to be migrated during the migration process of the container instance. Cross-cluster reuse count refers to the number of times the data block is referenced in multiple different cloud-native clusters, reflecting the cluster universality and global value of the data block. The block popularity score is a quantitative score calculated based on the data modification frequency and cross-cluster reuse count, used to characterize the data stability of the data block. The higher the score, the higher the data stability of the data block, and the more suitable it is to be pre-cached to the target to improve migration efficiency.

[0033] Specifically, in the aforementioned step S120, determining the set of data blocks to be migrated for the container instance to be migrated based on the correspondence between the source tag set and each data block in the global block identifier library includes: for each hash identifier in the source tag set, searching for at least one end identifier corresponding to the hash identifier in the global block identifier library; if the at least one end identifier includes the source end identifier but does not include the target end identifier of the target cloud-native cluster, then the data block corresponding to the hash identifier is taken as the data block to be migrated, and the set of data blocks to be migrated is composed of at least one of the data blocks to be migrated.

[0034] Therefore, by using the hash identifiers in the source tag set as indexes, the corresponding relationships are found in the global block identifier library. By comparing the end identifiers in the relationships with the distribution of data blocks in the source and target cloud-native clusters, the system can accurately identify the missing data blocks of the container instance to be migrated in the target cloud-native cluster. Duplicate data blocks already existing in the target cloud-native cluster are automatically removed, achieving global data deduplication during container instance migration. This facilitates subsequent migration of the container instance from the source cloud-native cluster to the target cloud-native cluster based on the set of data blocks to be migrated. This method significantly reduces the total amount of data that needs to be transferred, lowers network bandwidth usage and migration time, improves container instance migration efficiency, and effectively avoids unnecessary waste of migration resources.

[0035] Specifically, in step S120 above, calculating the block heat value of the data block to be migrated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated includes: obtaining the data modification frequency and at least one end identifier corresponding to the data block to be migrated from the global block identifier library, and using the number of at least one end identifier as the cross-cluster reuse count of the data block to be migrated; obtaining the layer weight, cross-cluster reuse weight, and data modification weight of the layer to which the data block to be migrated belongs; and using a layer weighted algorithm to calculate the data modification frequency, the cross-cluster reuse count, the layer weight, the cross-cluster reuse weight, and the data modification weight to obtain the block heat value of the data block to be migrated.

[0036] Among them, layer weight refers to the weight coefficient assigned according to the layer (intermediate layer, user layer) to which the data block belongs, used to identify the influence of the layer on the block popularity value. Cross-cluster reuse weight refers to the preset weight coefficient used to adjust the proportion of cross-cluster reuse frequency in the block popularity value calculation. Data modification weight refers to the preset weight coefficient used to adjust the proportion of data modification frequency in the block popularity value calculation.

[0037] For example, a layer-weighted algorithm is used to calculate the data modification frequency, the number of cross-cluster reuses, the layer weight, the cross-cluster reuse weight, and the data modification weight to obtain the block heat value of the data block to be migrated, as shown in the following formula: H=(α×n) + (β×(1 / (1+f)))×ω1, Where α is the cross-cluster reuse weight; n is the number of cross-cluster reuses; β is the data modification weight, α+β=1; ω1 is the layer weight, with the intermediate layer ω1 being less than the user layer ω1; and f is the data modification frequency.

[0038] Therefore, by automatically obtaining the data modification frequency and at least one end identifier of the data block to be migrated from the global block identifier library, and quantifying the number of cross-cluster reuses using the number of end identifiers, the block heat value of the data block is calculated by combining the layer weight of the data block's layer, the preset cross-cluster reuse weight, and the data modification weight. This allows for an objective and accurate quantitative assessment of the data stability and data change level of the data block to be migrated. This method fully considers the hierarchical characteristics, global reuse value, and dynamic change level of the data block, enabling the block heat value to accurately characterize the stability, change frequency, and global importance of the data block. This provides a scientific and reliable basis for the formulation of subsequent differentiated migration strategies, and is conducive to the targeted matching and adaptation of data transmission methods for data block migration, improving migration efficiency and reducing resource consumption. Furthermore, based on the aforementioned layering of data blocks according to data modification frequency and cross-instance reusability, data modification frequency and layer weight are further integrated into the calculation of block popularity value. Through dual quantization (layer quantization and popularity quantization), fine-grained control over the data blocks to be migrated is achieved. This takes into account both the commonalities of the data block hierarchy and highlights the individual differences of individual data blocks. It enables secondary fine-grained differentiation of different data blocks within the same layer, allowing data in the same layer to be migrated according to the same layer migration method, or to be migrated differently according to the block popularity value. This ensures the hierarchical adaptability of the migration strategy and enhances the flexibility of data migration within the same layer. It effectively avoids the resource waste and migration efficiency loss caused by a uniform and single migration method, and significantly improves the flexibility and efficiency of cloud-native cluster container instance migration.

[0039] Step S130: The data blocks to be migrated belonging to the basic layer or the data blocks to be migrated with a block popularity value higher than the preset block popularity value are pre-cached to the target cloud-native cluster through the encrypted transmission link of the transport layer security protocol; for each data block to be migrated with a block popularity value not higher than the preset block popularity value, the data blocks to be migrated are migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data blocks to be migrated belong.

[0040] The preset block heat value refers to a pre-configured critical threshold used to distinguish between data blocks with high and low data stability. The Transport Layer Security (TLS) encrypted transmission link is a secure communication link that encrypts and authenticates data at the transport layer, ensuring the confidentiality and integrity of container instance data during cross-cluster migration. Pre-caching refers to asynchronously transmitting and caching the base layer data blocks, as well as high-stability data blocks from the intermediate and user layers, to the target cloud-native cluster before the formal migration of the container instance begins. This reduces migration interruption time and improves migration efficiency. The layer migration method refers to differentiated migration strategies based on the hierarchical characteristics of different data blocks. Specifically, in step S130 above, the layer migration method based on the layer to which the data block to be migrated belongs migrates the data block to the target cloud-native cluster, including: if the data block to be migrated belongs to the intermediate layer, then the data block to be migrated is compressed using a compression ratio algorithm that matches the block heat value of the data block to be migrated to obtain a compressed data block, and the compressed data block is transmitted to the target cloud-native cluster using fragmented transmission and breakpoint resume transmission; if the data block to be migrated belongs to the user layer, then the data block to be migrated is migrated to the target cloud-native cluster, and incremental data is tracked in real time using a copy-on-write mechanism. When the incremental data reaches a preset incremental threshold, or the maximum latency transmission time of the incremental data reaches a duration threshold, the incremental data is transmitted to the target cloud-native cluster as a data incremental packet.

[0041] The compression ratio algorithm refers to selecting different compression ratios based on the block popularity value of data blocks to reduce the transmission volume of data blocks. Specifically, for data blocks with high block popularity values, a high compression ratio algorithm is used, while for data blocks with low block popularity values, a low compression ratio algorithm is used. A compressed data block is a data block whose size is reduced after compression. Fragmented transmission refers to splitting compressed data blocks into multiple smaller data fragments and transmitting them sequentially, improving transmission stability. Resume interrupted transmission means that transmission can resume from the point of interruption without starting from the beginning, improving transmission reliability and efficiency in weak network environments. Copy-on-write mechanism means that new data is only copied when data is modified, tracking data changes in real time without affecting the reading and writing of the original data. Incremental data refers to newly modified or newly written data content generated during the migration process. Preset incremental threshold refers to a pre-set critical value for the amount of incremental data. Maximum delayed transmission time refers to the maximum time that incremental data waits to be packaged and transmitted. Duration threshold refers to a pre-set critical value for the delayed transmission time of incremental data. A data increment packet is a data packet that encapsulates incremental data over a period of time.

[0042] Therefore, a layered migration strategy highly adapted to the data characteristics of the intermediate layer and user layer data blocks is adopted respectively. Adaptive dynamic compression is achieved for intermediate layer data blocks based on block popularity values: high compression ratio algorithms are used for intermediate layer data blocks with high data stability and high block popularity values ​​to minimize transmission volume and shorten transmission time; low compression ratio algorithms are used for intermediate layer data blocks with low data stability and low block popularity values ​​to reduce compression computation overhead, thus achieving an optimal balance between transmission time and compression overhead. Simultaneously, by combining fragmented transmission with breakpoint resumption, the reliability and continuity of data transmission under weak network conditions are further improved, effectively reducing network bandwidth consumption and minimizing the waste of transmission resources. For frequently changing user layer data, a write-on-write replication mechanism is used to track incremental data generated during the migration process in real time without affecting the normal read and write operations of the source end business. Batch packet transmission is performed according to preset incremental or duration thresholds, ensuring the stable operation of user services throughout the migration process and guaranteeing real-time consistency of user layer data. This also avoids the significant network overhead and connection loss caused by frequent small packet transmissions, effectively solving the migration synchronization problem caused by frequent changes in user layer data. In summary, this layered migration strategy achieves a balance between transmission efficiency, data integrity, and business continuity during container instance migration, significantly improving the overall performance, stability, and robustness of cross-cluster migration of container instances in cloud-native clusters, and adapting to complex operating scenarios of multiple cloud-native clusters.

[0043] For example, the container instance migration method based on hierarchical data blocks proposed in this solution is applicable not only to container instance migration across cloud-native clusters but also to container instance migration between different nodes within the same cloud-native cluster, demonstrating strong versatility. When the source and target cloud-native clusters are different clusters, this solution can pre-deduplicate data blocks and calculate block popularity values ​​based on a global block identifier library. High-population-value data blocks in the base layer, intermediate layer, and user layer are pre-cached in the target cloud-native cluster. Then, layer-differentiated migration is performed on the remaining data blocks in the intermediate and user layers, achieving secure and efficient cross-cluster container instance migration. When the source and target cloud-native clusters are the same cluster, the set of data blocks to be migrated can be precisely determined, avoiding redundant data transfer. Layer-differentiated migration is performed only on the data blocks to be migrated in the intermediate and user layers, effectively reducing the consumption of internal cluster storage and network resources and improving the flexibility and efficiency of container instance scheduling and migration within the same cluster.

[0044] In some examples, the method further includes: after each of the data blocks to be migrated is cached or migrated to the target cloud-native cluster, adding the target identifier of the target cloud-native cluster to the mapping relationship of the data blocks to be migrated in the global block identifier library; after all the data blocks to be migrated in the set of data blocks to be migrated have been migrated to the target cloud-native cluster, obtaining multiple target mapping relationships corresponding to the container instance identifier of the container instance to be migrated from the global block identifier library; filtering out multiple first mapping relationships from the multiple target mapping relationships based on the source identifier, and constructing a source hash tree based on the data block identifier and hash identifier in the multiple first mapping relationships; filtering out multiple second mapping relationships from the multiple target mapping relationships based on the target identifier, and constructing a target hash tree based on the data block identifier and hash identifier in the multiple second mapping relationships; and using a hash tree root verification method to verify the source hash tree and the target hash tree. The target hash tree undergoes consistency verification. If the consistency verification passes, the data block corresponding to the container instance to be migrated is deleted from the source cloud-native cluster, and the source identifier is deleted from the correspondence of the container instance to be migrated in the global block identifier library. If the consistency verification fails, the first differential hash identifier in the source hash tree and the second differential hash identifier in the target hash tree are determined by comparing the nodes of the source hash tree and the target hash tree. The data block corresponding to the first differential hash identifier is re-migrated to the target cloud-native cluster using a directed retransmission method. The data block corresponding to the second differential hash identifier in the target cloud-native cluster is deleted, and the second differential hash identifier is deleted from the correspondence in the global block identifier library. After the directed retransmission is completed, a new source hash tree and a new target hash tree are reconstructed based on the global block identifier library, and consistency verification is performed until the verification passes or a preset verification count threshold is reached.

[0045] The target mapping relationship refers to the mapping relationship of all data blocks related to the container instance to be migrated in the global block identifier library. The first mapping relationship refers to the mapping relationship of data blocks existing in the source cloud-native cluster, selected from the target mapping relationship. The second mapping relationship refers to the mapping relationship of data blocks existing in the target cloud-native cluster, selected from the target mapping relationship. The source hash tree is a hash tree constructed from the hash identifiers of all data blocks belonging to the container instance to be migrated in the source cloud-native cluster. The target hash tree is a hash tree constructed from the hash identifiers of all data blocks belonging to the container instance to be migrated in the target cloud-native cluster. The hash tree root verification method is a method to quickly verify data consistency by comparing the root node value of the hash tree. The first difference hash identifier is a hash identifier that exists in the source hash tree but not in the target hash tree. The second difference hash identifier is a redundant or erroneous hash identifier that exists in the target hash tree but not in the source hash tree. The targeted retransmission method refers to accurately retransmitting only missing or abnormal data blocks, rather than retransmitting the entire data. The preset verification count threshold is the maximum number of consistency verification retries allowed to avoid infinite loops.

[0046] After each data block to be migrated is cached or migrated to the target cloud-native cluster, whenever a data block to be migrated is successfully cached or migrated to the target cloud-native cluster, the target identifier is updated in the global block identifier library to mark that the data block to be migrated has been migrated to the target cloud-native cluster, thus achieving global state synchronization. After all data blocks to be migrated in the set have been migrated to the target cloud-native cluster, a consistency check is performed on the data blocks of the container instance to be migrated in the source cloud-native cluster and the data blocks of the container instance to be migrated in the target cloud-native cluster using a hash tree root verification method. If the check passes, it means that there are data blocks in the target cloud-native cluster that are identical to all data blocks of the container instance to be migrated in the source cloud-native cluster. At this point, it means that the container instance to be migrated can be restarted in the target cloud-native cluster, and the migration of the container instance to be migrated is successful. After passing the consistency check, the data block corresponding to the container instance to be migrated is deleted from the source cloud-native cluster, and the source identifier in the correspondence of the container instance to be migrated is deleted from the global block identifier library to ensure global data consistency. If the consistency check fails, the source hash tree and the target hash tree are compared node by node to determine the first differential hash identifier in the source hash tree and the second differential hash identifier in the target hash tree. A directed retransmission method is then used to re-migrate the data block corresponding to the first differential hash identifier to the target cloud-native cluster. The data block corresponding to the second differential hash identifier in the target cloud-native cluster is deleted, and the second differential hash identifier is removed from the corresponding relationship in the global block identifier library. After the directed retransmission is completed, a new source hash tree and a new target hash tree are reconstructed based on the global block identifier library, and a consistency check is performed until the check passes or a preset check count threshold is reached. When the preset check count threshold is reached, automatic repair is stopped, and relevant technical personnel are notified to conduct manual troubleshooting and anomaly handling to prevent the abnormal state from continuing to spread and to ensure the overall stability of the cluster operation.

[0047] Therefore, by updating the target identifier in the global block identifier library in real time after the data block migration is completed, the accuracy of the data block information in the global block identifier library is ensured. This provides reliable data support for subsequent data consistency verification of the source and target container instances to be migrated based on the global block identifier library, thereby efficiently and accurately verifying whether the container instances to be migrated have achieved complete and correct migration. When the verification fails, by comparing the nodes of the source hash tree and the target hash tree, missing, redundant, or abnormal data blocks can be accurately located. Instead of retransmitting all data blocks, a combination of targeted retransmission and redundant data cleanup is used for local repair, effectively avoiding the problems of network bandwidth occupation, computing resource waste, and increased migration time caused by full retransmission. At the same time, through a cyclic retry limit mechanism, the number of automatic repairs is controlled within the preset verification threshold range, avoiding excessive cluster resource occupation and migration process deadlock caused by unlimited automatic repairs. This ensures the normal operation of the cloud-native cluster, balances the reliability of migration repair with the stability of cluster operation, and further improves the overall controllability and efficiency of container instance migration.

[0048] In some examples, the method further includes: if the consistency check passes, reconstructing the container instance to be migrated in the target cloud-native cluster based on the data block identifier and hierarchy identifier of each data block of the container instance to be migrated in the target cloud-native cluster, and starting the container instance to be migrated.

[0049] In summary, this solution quantifies and layers container instances to be migrated based on data modification frequency and cross-instance reusability, accurately distinguishing data blocks in the basic, intermediate, and user layers. Combined with block popularity calculations, it employs differentiated migration strategies for data blocks at different levels and with varying popularity. Highly reusable and low-change data blocks are pre-cached in the target cloud-native cluster, while highly changeable and low-reusable data blocks are migrated layer by layer. This optimizes the migration process, selects migration methods suitable for the data blocks, and avoids a one-size-fits-all approach that migrates all data blocks, preventing the repeated transmission of large amounts of unchanging basic and intermediate layer data that doesn't require retransmission, leading to excessive network bandwidth consumption and ineffective migration resource consumption. Migrating using an appropriate migration method can improve the migration efficiency of different types of data blocks, reduce invalid data transmission links, avoid redundant data occupying migration bandwidth and slowing down the migration progress, thereby improving overall migration efficiency and shortening migration time. At the same time, by maintaining the correspondence of each data block through a global block identifier library, it is possible to quickly locate the data blocks to be migrated that exist in the source cloud-native cluster but not in the target cloud-native cluster, effectively avoiding redundant data transmission problems caused by full migration, significantly reducing the waste of network bandwidth and other resources, significantly shortening the entire process of image packaging, pushing, and pulling, reducing migration latency, and stably adapting to business scenarios with extremely high real-time requirements such as financial transactions, online games, and industrial control.

[0050] To improve container instance migration efficiency and reduce resource waste during migration, this application provides an embodiment of a hierarchical data block-based container instance migration apparatus for implementing all or part of the hierarchical data block-based container instance migration method. See [link to relevant documentation]. Figure 2 The container instance migration device based on hierarchical data blocks specifically includes the following components: The acquisition unit 10 is used to acquire the container instance to be migrated from the source cloud-native cluster, perform quantitative data layering processing on the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the basic layer, intermediate layer and user layer respectively, calculate the hash identifier of each data block, update the correspondence of each data block in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster, and construct the source tag set of the container instance to be migrated based on the hash identifier of each data block.

[0051] The calculation unit 20 is used to determine the set of data blocks to be migrated for the container instance to be migrated based on the correspondence between the source tag set and each data block in the global block identifier library. For each data block to be migrated that belongs to the intermediate layer or the user layer in the set of data blocks to be migrated, the block heat value of the data block to be migrated is calculated based on the data modification frequency and cross-cluster reuse times of the data block to be migrated.

[0052] Migration unit 30 is used to pre-cache data blocks to be migrated belonging to the base layer or data blocks to be migrated with a block popularity value higher than a preset block popularity value to the target cloud-native cluster via a transport layer security protocol encrypted transmission link; for each data block to be migrated with a block popularity value not higher than the preset block popularity value, the data block to be migrated is migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data block to be migrated belongs.

[0053] To further illustrate this solution, this application also provides a specific application example of implementing the container instance migration method based on hierarchical data blocks using the above-described container instance migration device based on hierarchical data blocks, which specifically includes the following: In some examples, when the device is used to perform quantified data layering processing on the container instance to be migrated based on a data modification frequency threshold and a cross-instance reuse threshold to obtain multiple data blocks corresponding to the base layer, intermediate layer, and user layer, it is specifically used to: for each data block in the container instance to be migrated, obtain the data modification frequency of the data block and calculate the cross-instance reuse of the data block in the source cloud-native cluster; classify data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold as base layer data blocks; classify data blocks whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold as user layer data blocks; classify data blocks whose data modification frequency is not higher than the data modification frequency threshold and whose cross-instance reuse is not higher than the cross-instance reuse threshold, or whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold, as intermediate layer data blocks.

[0054] In some examples, when the device is used to update the correspondence between the data blocks in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster, it is specifically used to: for each data block of the container instance to be migrated, obtain the data block identifier of the data block, and search for the data block identifier in the global block identifier library; if found, add the data modification frequency, hash identifier, and source identifier of the source cloud-native cluster of the data block to the correspondence between the data blocks; if not found, construct the correspondence between the data blocks based on the data modification frequency, hash identifier, hierarchy identifier, data block identifier, and source identifier of the data blocks, and add the correspondence to the global block identifier library.

[0055] In some examples, when the device is used to determine the set of data blocks to be migrated for the container instance to be migrated based on the correspondence between the source tag set and each data block in the global block identifier library, it is specifically used to: for each hash identifier in the source tag set, search for at least one end identifier corresponding to the hash identifier in the global block identifier library; if the at least one end identifier includes the source end identifier but does not include the target end identifier of the target cloud-native cluster, then the data block corresponding to the hash identifier is taken as the data block to be migrated, and the set of data blocks to be migrated is composed of at least one of the data blocks to be migrated.

[0056] In some examples, when the device is used to calculate the block heat value of the data block to be migrated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated, it is specifically used to: obtain the data modification frequency and at least one end identifier corresponding to the data block to be migrated from the global block identifier library, and use the number of at least one end identifier as the cross-cluster reuse count of the data block to be migrated; obtain the layer weight, cross-cluster reuse weight, and data modification weight of the layer to which the data block to be migrated belongs; and use a layer weighted algorithm to calculate the data modification frequency, the cross-cluster reuse count, the layer weight, the cross-cluster reuse weight, and the data modification weight to obtain the block heat value of the data block to be migrated.

[0057] In some examples, when the device is used to migrate the data block to the target cloud-native cluster based on the layer migration method of the layer to which the data block to be migrated belongs, it is specifically used as follows: if the data block to be migrated belongs to the intermediate layer, the data block to be migrated is compressed using a compression ratio algorithm that matches the block heat value of the data block to be migrated to obtain a compressed data block, and the compressed data block is transmitted to the target cloud-native cluster using fragmented transmission and breakpoint resume transmission; if the data block to be migrated belongs to the user layer, the data block to be migrated is migrated to the target cloud-native cluster, and incremental data is tracked in real time using a copy-on-write mechanism. When the incremental data reaches a preset incremental threshold, or the maximum latency transmission time of the incremental data reaches a duration threshold, the incremental data is transmitted to the target cloud-native cluster as a data incremental packet.

[0058] In some examples, the apparatus is further configured to: after each of the data blocks to be migrated is cached or migrated to the target cloud-native cluster, add the target identifier of the target cloud-native cluster to the mapping relationship of the data blocks to be migrated in the global block identifier library; after all the data blocks to be migrated in the set of data blocks to be migrated have been migrated to the target cloud-native cluster, obtain multiple target mapping relationships corresponding to the container instance identifier of the container instance to be migrated from the global block identifier library; based on the source identifier, select multiple first mapping relationships from the multiple target mapping relationships, and construct a source hash tree based on the data block identifier and hash identifier in the multiple first mapping relationships; based on the target identifier, select multiple second mapping relationships from the multiple target mapping relationships, and construct a target hash tree based on the data block identifier and hash identifier in the multiple second mapping relationships; and use a hash tree root verification method to verify the source hash tree and the target hash tree. The target hash tree undergoes consistency verification. If the consistency verification passes, the data block corresponding to the container instance to be migrated is deleted from the source cloud-native cluster, and the source identifier is deleted from the correspondence of the container instance to be migrated in the global block identifier library. If the consistency verification fails, the first differential hash identifier in the source hash tree and the second differential hash identifier in the target hash tree are determined by comparing the nodes of the source hash tree and the target hash tree. The data block corresponding to the first differential hash identifier is re-migrated to the target cloud-native cluster using a directed retransmission method. The data block corresponding to the second differential hash identifier in the target cloud-native cluster is deleted, and the second differential hash identifier is deleted from the correspondence in the global block identifier library. After the directed retransmission is completed, a new source hash tree and a new target hash tree are reconstructed based on the global block identifier library, and consistency verification is performed until the verification passes or a preset verification count threshold is reached.

[0059] This invention also provides 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 container instance migration method based on hierarchical data blocks.

[0060] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described container instance migration method based on hierarchical data blocks.

[0061] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described container instance migration method based on hierarchical data blocks.

[0062] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0063] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0064] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0065] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0066] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A container instance migration method based on hierarchical data blocks, characterized in that, The method includes: Obtain the container instance to be migrated from the source cloud-native cluster. Perform quantitative data layering processing on the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the basic layer, intermediate layer and user layer respectively. Calculate the hash identifier of each data block. Update the correspondence of each data block in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster. Construct the source tag set of the container instance to be migrated based on the hash identifier of each data block. Based on the correspondence between the source tag set and each data block in the global block identifier library, the set of data blocks to be migrated for the container instance to be migrated is determined. For each data block to be migrated that belongs to the intermediate layer or the user layer in the set of data blocks to be migrated, the block heat value of the data block to be migrated is calculated based on the data modification frequency and cross-cluster reuse times of the data block to be migrated. Data blocks to be migrated that belong to the base layer or whose block popularity value is higher than the preset block popularity value are pre-cached to the target cloud-native cluster through a transport layer security protocol encrypted transmission link; for each data block to be migrated whose block popularity value is not higher than the preset block popularity value, the data block to be migrated is migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data block belongs.

2. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, The process involves quantizing and layering the data of the container instance to be migrated based on a data modification frequency threshold and a cross-instance reusability threshold, resulting in multiple data blocks corresponding to the base layer, intermediate layer, and user layer, respectively, including: For each data block in the container instance to be migrated, obtain the data modification frequency of the data block, and calculate the cross-instance reuse of the data block in the source cloud-native cluster; Data blocks whose data modification frequency is no higher than the data modification frequency threshold and whose cross-instance reusability is higher than the cross-instance reusability threshold are classified as basic layer data blocks; Data blocks whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reusability is not higher than the cross-instance reusability threshold are classified as user-layer data blocks; Data blocks whose data modification frequency is no higher than the data modification frequency threshold and whose cross-instance reuse is no higher than the cross-instance reuse threshold, or data blocks whose data modification frequency is higher than the data modification frequency threshold and whose cross-instance reuse is higher than the cross-instance reuse threshold, are classified as intermediate layer data blocks.

3. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, The correspondence between the data blocks in the global block identifier library is updated based on the hash identifier of each data block and the source identifier of the source cloud-native cluster, including: For each data block of the container instance to be migrated, obtain the data block identifier of the data block and search for the data block identifier in the global block identifier library. If found, add the data modification frequency, hash identifier, and source identifier of the source cloud-native cluster of the data block to the corresponding relationship of the data block. If not found, the correspondence between the data blocks is constructed based on the data modification frequency, hash identifier, hierarchy identifier, data block identifier, and source identifier of the data block, and the correspondence is added to the global block identifier library.

4. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, Based on the correspondence between the source tag set and each data block in the global block identifier library, the set of data blocks to be migrated for the container instance to be migrated is determined, including: For each hash identifier in the source identifier set, at least one end identifier corresponding to the hash identifier is searched in the global block identifier library. If the at least one end identifier includes the source end identifier but does not include the target end identifier of the target cloud-native cluster, then the data block corresponding to the hash identifier is taken as the data block to be migrated, and at least one of the data blocks to be migrated forms a set of data blocks to be migrated.

5. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, The calculation of the block heat value of the data block to be migrated based on the data modification frequency and cross-cluster reuse count of the data block to be migrated includes: Obtain the data modification frequency and at least one end identifier corresponding to the data block to be migrated from the global block identifier library, and use the number of at least one end identifier as the number of times the data block to be migrated is reused across the cluster. Obtain the layer weight, cross-cluster reuse weight, and data modification weight of the layer to which the data block to be migrated belongs; The block heat value of the data block to be migrated is obtained by using a layer weighted algorithm to calculate the data modification frequency, the number of cross-cluster reuses, the layer weight, the cross-cluster reuse weight, and the data modification weight.

6. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, The layer migration method based on the layer to which the data block to be migrated belongs migrates the data block to the target cloud-native cluster, including: If the data block to be migrated belongs to the intermediate layer, the data block to be migrated is compressed using a compression ratio algorithm that matches the block heat value of the data block to be migrated to obtain a compressed data block. The compressed data block is then transmitted to the target cloud-native cluster using fragmented transmission and breakpoint resume transmission. If the data block to be migrated belongs to the user layer, the data block to be migrated will be migrated to the target cloud-native cluster, and the incremental data will be tracked in real time using the copy-on-write mechanism. When the incremental data reaches the preset incremental threshold, or when the maximum delay transmission time of the incremental data reaches the duration threshold, the incremental data will be transmitted to the target cloud-native cluster as a data incremental packet.

7. The container instance migration method based on hierarchical data blocks according to claim 1, characterized in that, The method further includes: After each of the data blocks to be migrated is cached or migrated to the target cloud-native cluster, the target identifier of the target cloud-native cluster is added to the correspondence of the data blocks to be migrated in the global block identifier library; After all the data blocks to be migrated in the set of data blocks to be migrated have been migrated to the target cloud-native cluster, the multiple target correspondences corresponding to the container instance identifiers of the container instances to be migrated are obtained from the global block identifier library; Based on the source identifier, multiple first correspondences are selected from multiple target correspondences, and a source hash tree is constructed based on the data block identifier and hash identifier in the multiple first correspondences. Based on the target identifier, multiple second correspondences are selected from multiple target correspondences, and a target hash tree is constructed based on the data block identifier and hash identifier in the multiple second correspondences. The consistency of the source hash tree and the target hash tree is verified using the hash tree root verification method. If the consistency verification passes, the data block corresponding to the container instance to be migrated is deleted from the source cloud-native cluster, and the source identifier in the correspondence of the container instance to be migrated is deleted from the global block identifier library. If the consistency check fails, the first differential hash identifier in the source hash tree and the second differential hash identifier in the target hash tree are determined by comparing the nodes of the source hash tree and the target hash tree. The data block corresponding to the first differential hash identifier is then re-migrated to the target cloud-native cluster using a directed retransmission method. The data block corresponding to the second differential hash identifier in the target cloud-native cluster is then deleted, and the second differential hash identifier is also deleted from the correspondence in the global block identifier library. After the directed retransmission is completed, a new source hash tree and a new target hash tree are reconstructed based on the global block identifier library and a consistency check is performed until the check passes or the preset check count threshold is reached.

8. A container instance migration device based on hierarchical data blocks, characterized in that, The device includes: The acquisition unit is used to acquire the container instance to be migrated from the source cloud-native cluster, perform quantitative data layering processing on the container instance to be migrated based on the data modification frequency threshold and the cross-instance reuse threshold to obtain multiple data blocks corresponding to the basic layer, intermediate layer and user layer respectively, calculate the hash identifier of each data block, update the correspondence of each data block in the global block identifier library based on the hash identifier of each data block and the source identifier of the source cloud-native cluster, and construct the source tag set of the container instance to be migrated based on the hash identifier of each data block. The calculation unit is used to determine the set of data blocks to be migrated for the container instance to be migrated based on the correspondence between the source tag set and each data block in the global block identifier library. For each data block to be migrated that belongs to the intermediate layer or the user layer in the set of data blocks to be migrated, the block heat value of the data block to be migrated is calculated based on the data modification frequency and cross-cluster reuse times of the data block to be migrated. The migration unit is used to pre-cache the data blocks to be migrated belonging to the base layer or the data blocks to be migrated with a block popularity value higher than a preset block popularity value to the target cloud-native cluster through a transport layer security protocol encrypted transmission link; for each data block to be migrated with a block popularity value not higher than the preset block popularity value, the data block to be migrated is migrated to the target cloud-native cluster based on the layer migration method of the layer to which the data block to be migrated belongs.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the container instance migration method based on hierarchical data blocks as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the container instance migration method based on hierarchical data blocks as described in any one of claims 1 to 7.

Images