Container starting method and device, storage medium, program product and electronic device

By reading the container image's metadata from a cloud storage device and combining it with a multi-level caching mechanism, the problem of slow container startup speed is solved, and the container startup speed is accelerated.

CN120929185APending Publication Date: 2025-11-11UCLOUD TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510768366.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-09
Publication Date
2025-11-11

AI Technical Summary

Technical Problem

In existing technologies, container images start up slowly, especially as the image compressed package becomes larger and larger, and traditional methods cannot effectively speed up container startup.

Method used

Download the image's metadata address from a public image repository, and use a private cloud storage device to read the metadata to start the container. This combines a multi-level caching mechanism and incremental data processing to reduce the steps of downloading and decompressing image data.

Benefits of technology

By reducing the concurrency of metadata and increasing the read rate, the startup speed of containers is significantly accelerated, the frequency of reading image data from cloud storage devices is reduced, and the startup efficiency of containers is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120929185A_ABST
    Figure CN120929185A_ABST
Patent Text Reader

Abstract

The invention discloses a container starting method and device, a storage medium, a program product and an electronic device, and the method comprises the steps: downloading address information of a first mirror image from a public mirror image warehouse, the address information being used for indicating a storage address of metadata of the first mirror image in a private cloud storage device; reading the metadata from the storage address; and starting a container corresponding to the first mirror image based on the metadata. The scheme provided by the embodiment of the invention is beneficial to improving the starting speed of the container.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a container startup method and apparatus, storage medium, program product, and electronic device. Background Technology

[0002] A container is a virtualization technology used to encapsulate applications and all their dependencies (such as libraries, runtime environments, configuration files, etc.), enabling applications to run efficiently and consistently across different computing environments. A container image is a static, executable file package that contains the files required to run a container.

[0003] Traditional container startup methods require downloading the complete container image package from an image repository, decompressing the package, and then starting the container based on the image. To accelerate container startup, peer-to-peer (P2P) technology has been proposed to speed up the download process. While this approach can improve startup speed to some extent, the need for decompression still results in a relatively long startup time. Especially with technological advancements, container image packages are becoming increasingly large (e.g., exceeding 10 gigabytes), making the need for faster startup even more critical. Summary of the Invention

[0004] One of the technical objectives of this application is to provide a container startup method that can improve the startup speed of containers.

[0005] To address the aforementioned technical problems, this application provides a container startup method, the method comprising: downloading address information of a first image from a public image repository, the address information indicating the storage address of the metadata of the first image in a private cloud storage device; reading the metadata from the storage address; and starting the container corresponding to the first image based on the metadata.

[0006] Optionally, starting the container corresponding to the first image based on the metadata includes: creating a directory for the first image in the user-space file system; and mounting the first image to the directory based on the metadata.

[0007] Optionally, the method further includes: obtaining a read request, the read request being used to request target data in the first image; and reading the target data from the cloud storage device in response to the fact that neither the first-level cache nor the second-level cache contains the target data; wherein the first-level cache is a cache of the local operating system, and the second-level cache is a cache of the user-space file system.

[0008] Optionally, the first image is stored in the cloud storage device after being decompressed.

[0009] Optionally, the method further includes: acquiring incremental data, the incremental data being generated during the operation of the container; generating a second image based on the first image and the incremental data; and executing an image addition command for the second image; wherein executing the image addition command for the second image includes: storing the second image to the cloud storage device and generating metadata of the second image on the cloud storage device; and pushing the address information of the metadata of the second image on the cloud storage device to the image repository.

[0010] Optionally, the cloud storage device is shared by multiple clusters in the cluster group, and the image addition command is executed by the primary cluster among the multiple clusters in an idle state.

[0011] This application embodiment also provides a container startup device, the device comprising: an address download module, configured to download address information of a first image from a public image repository, the address information indicating the storage address of the metadata of the first image in a private cloud storage device; a data reading module, configured to read the metadata from the storage address; and a startup module, configured to start the container corresponding to the first image based on the metadata.

[0012] This application also provides a computer-readable storage medium storing a computer program thereon, which, when run by a processor, performs the steps of the container startup method described above.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the container startup method described above.

[0014] This application also provides an electronic device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it performs the steps of the container startup method described above.

[0015] Compared with the prior art, the technical solution of this application embodiment has the following beneficial effects:

[0016] In the scheme of this application embodiment, the address information of the first image is downloaded from a public image repository. This address information indicates the storage address of the metadata of the first image in a private cloud storage device. The metadata is then read from the storage address. The container corresponding to the first image is started based on the metadata. In the above scheme, the image's metadata is stored in a private cloud storage server. When the container starts, the image's metadata is retrieved from the cloud storage server to start the container. Compared to storing metadata in a public image repository, since the cloud storage server is user-exclusive or private, the concurrency during metadata download is greatly reduced, thus increasing the metadata reading rate and consequently improving the container startup speed.

[0017] Furthermore, in the solution of this application embodiment, a read request is obtained, the read request being used to request target data in the first image; in response to the fact that neither the first-level cache nor the second-level cache contains the target data, the target data is read from the cloud storage device; wherein, the first-level cache is the cache of the local operating system, and the second-level cache is the cache of the user-space file system. That is, in the solution of this application embodiment, the virtual machine adopts a multi-level caching mechanism. Through the multi-level caching mechanism, the opportunity for the container to obtain image data from the virtual machine locally is increased, and the frequency of reading image data from the cloud storage device is reduced, which is beneficial to improving the speed of container reading image data.

[0018] Furthermore, in the solution of this application embodiment, the first image is stored in the cloud storage device after being decompressed. Therefore, when requesting target data from the cloud storage device, the virtual machine can directly obtain the decompressed target data without needing to decompress it after obtaining the data. This improves the speed at which the container reads image data.

[0019] Furthermore, in the solution of this application embodiment, after the second image is stored in the cloud storage device, metadata of the second image is generated in the cloud storage device, and the storage address of the metadata of the second image in the cloud storage device is pushed to the image repository. Therefore, when the virtual machine on the cloud platform restarts the first container, the virtual machine can still use the solution provided in this application embodiment to start and run the first container; that is, the image generated by iterative updates also supports accelerated startup. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating an application scenario of a container startup method according to an embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating a container startup method according to an embodiment of this application;

[0022] Figure 3This is a schematic diagram of the architecture of a cloud platform according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of a container starting device according to an embodiment of this application;

[0024] Figure 5 This is a schematic diagram illustrating the execution of a new image command in an embodiment of this application. Detailed Implementation

[0025] Currently, many AI model training and inference services run on Kubernetes (K8s) applications on virtual machines. K8s images are typically larger than 10 gigabytes, and downloading them from image repositories can take minutes. Furthermore, images are usually stored in compressed packages in image repositories, requiring decompression after download. When the concurrency of a cloud platform reaches a certain level, decompressing large-scale images can trigger performance bottlenecks, further extending container startup times.

[0026] As described in the background section, even though P2P technology has improved upon traditional container startup technology, its startup acceleration effect is not significant in cloud platform scenarios.

[0027] In another container startup method, the image is stored in an image repository in a special format (such as eStargz). When starting a container, only the necessary file indexes are read from the image repository and the container starts quickly. During container operation, when the actual image data is needed, the required data is downloaded from the image repository in real time and provided to the container, achieving on-demand loading. In this startup method, only the image's file index is downloaded from the image repository at startup, rather than the complete image, thus enabling faster container startup. However, in practical applications, this startup method still has shortcomings, and the container startup speed needs further improvement.

[0028] In view of this, this application provides a container startup method. In this embodiment, the address information of a first image is downloaded from a public image repository. This address information indicates the storage address of the first image's metadata in a private cloud storage device. The metadata is then read from the storage address, and the container corresponding to the first image is started based on the metadata. In this solution, the image's metadata is stored in a private cloud storage server. When the container starts, the image's metadata is retrieved from the cloud storage server to start the container. Compared to storing metadata in a public image repository, since the cloud storage server is user-exclusive or private, the concurrency during metadata download is greatly reduced, thus increasing the metadata reading rate and consequently improving the container startup speed.

[0029] To make the above-mentioned objectives, features and beneficial effects of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0030] Reference Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of a container startup method according to an embodiment of this application. The following is in conjunction with… Figure 1 The application scenarios of a container startup method in the embodiments of this application are described in detail.

[0031] like Figure 1 As shown, the container startup method provided in this application embodiment can be applied to cloud platform 1. A cloud platform refers to a digital infrastructure built by a cloud service provider based on cloud computing technology, providing scalable computing resources, storage, network, and various services on demand via the Internet. Cloud platform 1 virtualizes physical hardware resources to form a shared resource pool, and achieves efficient allocation and dynamic scheduling of resources through automated management and a distributed architecture. Specifically, cloud service providers can use virtualization technology to divide the physical servers of cloud platform 1 into multiple logically isolated virtual machines (VMs), each VM independently running an operating system (such as Linux, Windows, etc.) and applications.

[0032] In practical applications, cloud platform 1 can provide virtual machines 11 for one or more users respectively. In this embodiment of the application, "user" refers to the party using the cloud service.

[0033] In this article, "virtual machine" can be referred to as "node". In practical applications, virtual machines belonging to the same user can work collaboratively in a cluster to improve reliability and task execution efficiency. Specifically, multiple virtual machines can form a cluster. Further, multiple clusters can form a cluster group. In other words, a cluster group can include multiple clusters. For example, a cluster group belonging to the same user can be considered a cluster group. In specific implementations, a cluster group can include a master cluster and slave clusters. Specifically, one cluster in a cluster group can act as the master cluster, and the other clusters are slave clusters. The master cluster can be responsible for task scheduling and cluster group status management, while the slave clusters can be responsible for task execution and resource reporting.

[0034] Figure 1 Taking the first user and the second user as examples, cloud platform 1 provides multiple virtual machines for the first user and multiple virtual machines for the second user. The virtual machines of the first user form cluster group 121, and the virtual machines of the second user form cluster group 122. Cluster group 121 includes multiple clusters 1211, and cluster group 122 includes multiple clusters 1212.

[0035] In the embodiments of this application, containers can be started and run on each virtual machine 11. For example, users can use containers on virtual machines to train and infer artificial intelligence models, perform big data analysis, and develop web applications. It should be noted that the embodiments of this application do not limit the application scenarios of containers.

[0036] Furthermore, cloud platform 1 may also include: image repository 12 and cloud storage device. Image repository 12 is typically a device used for centralized storage, management, and distribution of container images. In specific implementations, image repository 12 is usually deployed on the storage server of cloud platform 1. Cloud storage device can be a device used for storage; for example, cloud storage device 13 can be deployed on the storage server of cloud platform 1.

[0037] In the embodiments of this application, the cloud storage device can be used to store images and image metadata. The image metadata refers to data describing the image. Specifically, an image may include multiple image layers, and each image layer may include multiple files. Further, each file may include multiple data blocks. The metadata may include at least one of the following: an index of the image layer, an index of the file, an index of the data block, the storage address of the image layer, the storage address of the file, and the storage address of the data block. It should be noted that the storage address in the metadata refers to the storage address on the cloud storage device, not the storage address in the image repository.

[0038] In a specific implementation, the cloud storage device may include a first storage module and a second storage module, wherein the first storage module is used to store the image's metadata, and the second storage module is used to store the image itself.

[0039] Furthermore, in the solution of this application embodiment, the image repository 12 can be used to store image information of multiple users. For example... Figure 1 As shown, the image repository 12 can store image information for a first user and image information for a second user. The image information can include image identification information and address information. The identification information can be used to uniquely identify and determine the image, and the address information can indicate the storage address of the image's metadata in the cloud storage device.

[0040] In the scheme of this application embodiment, the image repository 12 is public, specifically, the image repository 12 can be accessed by the virtual machines of each user of the cloud platform 1. The cloud storage device, however, is private. In other words, the cloud storage device is private to each user. Each user can only access their own private cloud storage device, but cannot access the private cloud storage devices of other users.

[0041] like Figure 1 As shown, cloud storage device 131 provides a private cloud storage device for the first user and a private cloud storage device for the second user. The virtual machine of the first user can access cloud storage device 131 but cannot access cloud storage device 132. The virtual machine of the second user can access cloud storage device 132 but cannot access cloud storage device 131.

[0042] It should be noted that multiple virtual machines belonging to the same user can share that user's private cloud storage device. In other words, the cloud storage device can be shared by multiple cluster groups, multiple clusters, or multiple virtual machines belonging to the same user.

[0043] Reference Figure 2 , Figure 2 This is a flowchart illustrating a container startup method according to an embodiment of this application. Figure 2 As shown, the container startup method in this application embodiment may include S201 to S205. The following is in conjunction with... Figure 2 The container startup method in the embodiments of this application is described in detail.

[0044] S201, the virtual machine sends its first request to the image repository.

[0045] Correspondingly, the image repository receives the first request. This first request may contain identification information for the first image, which may refer to the image the virtual machine expects to boot from. In specific implementations, the identification information for the first image may be its name or index.

[0046] S202, the image repository sends the address information of the first image to the virtual machine.

[0047] Correspondingly, the virtual machine downloads (or pulls) the address information of the first image from the image repository. Specifically, the address information of the first image can be used to indicate the storage address of the metadata of the first image in the cloud storage device. Therefore, in the solution of this application embodiment, the image repository can store the address information of each image without storing the complete image, which is beneficial to increasing the number of images that the image repository can manage and improving the performance of the image repository.

[0048] Specifically, the first image may include multiple image layers, and each image layer may include multiple files. Furthermore, each file may include multiple data blocks. Accordingly, the metadata of the first image may include at least one of the following: the index of each image layer of the first image, the storage address of each image layer of the first image in the cloud storage device, the index of each file of the first image, the storage address of each file of the first image in the cloud storage device, the index of each data block of the first image, and the storage address of each data block of the first image in the cloud storage device.

[0049] S203, the virtual machine reads the metadata of the first image from the cloud storage device.

[0050] As mentioned above, a cloud storage device can store multiple images and metadata for each image. A virtual machine can read the metadata of a first image from the cloud storage device based on the address information of that first image. In practice, a cloud storage device can be a storage system composed of multiple storage devices, and each image can be backed up multiple times across these devices. Therefore, the cloud storage device can provide more reliable storage, which is beneficial for improving the stability of image data access.

[0051] In one possible implementation, the image could be in eStargz format. This transforms traditional targz files into an indexable tree structure, storing this structure at the beginning of the file and optimizing for frequently accessed files by placing them earlier in the header for faster access. Furthermore, images in their original format (such as targz) can be pre-converted to eStargz, with compression parameters disabled during the conversion process. In other words, the image stored on the cloud storage device is an uncompressed file.

[0052] S204, The virtual machine starts the container corresponding to the first image based on the metadata of the first image.

[0053] It should be noted that there is a correspondence between images and containers, meaning that an image is an executable file required for a container to run. For ease of description, the "container corresponding to the first image" will be referred to as the "first container" below.

[0054] In one possible implementation, the virtual machine's operating system can be a Linux system, which may include a user-space file system (FUSE). The virtual machine can start a container through FUSE. FUSE allows users to implement a file system in user space.

[0055] Specifically, in S204, the virtual machine can create a directory for the first image in FUSE, and further, based on the metadata of the first image, mount the first image to the directory. After the first image is mounted, the container starts.

[0056] As mentioned above, the first image comprises multiple image layers, and each image layer contains multiple files. The target created by the virtual machine can include multiple subdirectories, with each subdirectory corresponding to one image layer. Since the metadata includes the indexes and storage addresses of each image layer and each file in the first image, the virtual machine can mount the files in each image layer to the corresponding subdirectory based on the metadata.

[0057] It should be noted that during the startup phase of the first container, FUSE does not contain the specific data of the first image. As the first container runs, it retrieves the data of the first image from the cloud storage device.

[0058] It should be noted that in other embodiments, the first container can also be started based on the metadata of the first image in other ways, and this embodiment is not limited to this.

[0059] Therefore, the container startup method provided in this application skips the image download and decompression process, and only reads and mounts metadata from a private cloud storage device when the container starts, which greatly improves the container startup speed. In actual test scenarios, starting a container corresponding to a 25 gigabyte image only takes 20 seconds.

[0060] Furthermore, Figure 2 The method shown may also include S205.

[0061] S205: The virtual machine reads the target data of the first container from the cloud storage device.

[0062] Specifically, after the first container starts, during its operation, the virtual machine can read the target data required by the first container from the cloud storage device on demand. Specifically, the virtual machine can read the target data of the first container from the cloud storage device through FUSE, which provides an interface for the container to access the image. Because FUSE does not involve switching between user mode and kernel mode, its access performance is relatively good.

[0063] In the solution of this application embodiment, the image is stored in a private cloud storage device. Since the private cloud storage device is only accessible to the user's virtual machine, compared with the solution of storing the image in an image repository and reading image data from the image repository, the solution of this application embodiment greatly reduces the concurrency of data reading and improves the speed and reliability of image data reading.

[0064] Specifically, during the operation of the first container, the virtual machine obtains a read request. For example, the read request may be generated locally by the virtual machine. The read request is used to request target data from the first image. For example, the read request may include identification information of the target data.

[0065] In the embodiments of this application, step S205 is optional. Specifically, the virtual machine can employ a caching mechanism to improve the speed at which the container reads image data.

[0066] In one possible implementation, the virtual machine may include a caching module, which can be used to cache frequently accessed data in the first image. For example, the caching module may reside within the virtual machine's operating system. In response to a read request, the target data can be requested from the caching module first. If the caching module contains the target data, it is read from the caching module, without needing to read the target data from cloud storage.

[0067] In another possible implementation, the virtual machine can employ a multi-level caching mechanism. Specifically, the virtual machine can include a first-level cache and a second-level cache, where the first-level cache is the operating system's cache, and the second-level cache is the FUSE cache. Both the first and second-level caches are used to cache frequently accessed data in the first image. After receiving a read request, the target data can be requested from the first-level cache first. If the first-level cache contains the target data, it is read from the first-level cache. If the first-level cache does not contain the target data, it is requested from the second-level cache. If the second-level cache contains the target data, it is read from the second-level cache; if the second-level cache does not contain the target data, it is requested from cloud storage. This multi-level caching mechanism increases the chances of the container obtaining image data locally from the virtual machine and reduces the frequency of reading image data from cloud storage, thus improving the speed of container image data reading.

[0068] In practice, after the first container starts, FUSE can record and analyze the access frequency of the first image's image data. Image data can refer to one or more of the following: image layers, files, or data blocks. Furthermore, the virtual machine can write image data whose access frequency reaches a first threshold into a second-level cache, so that subsequent image data can be read directly from the second-level cache, reducing the frequency of reading image data from cloud storage and thus improving the container's image data reading speed. The first threshold can be pre-configured.

[0069] For example, the validity period of image data in the second-level cache is a first duration. When the storage time of a certain image data in the second-level cache reaches the first duration, the image data is released. Release here can refer to deletion or erasure. The first duration can be pre-configured.

[0070] Furthermore, considering that the effective duration of data caching in the first-level cache is usually short, in the scheme of this application embodiment, the first duration can be greater than the effective duration of image data in the first-level cache. As a variation, if image data whose access frequency reaches a first threshold is written to the second-level cache, and if the access frequency of the image data further reaches a second threshold, the image data can be cached in the second-level cache until the first container finishes running. If the access frequency of the image data reaches the first threshold but not the second threshold, the image data can be released when the storage duration of the image data in the second-level cache reaches the first duration. This scheme can improve the hit rate of image data locally on the virtual machine and reduce the frequency of reading image data from the cloud storage device, thereby improving the speed at which the container reads image data. In one possible implementation, the first image is stored in the cloud storage device after being decompressed. Therefore, when requesting target data from the cloud storage device, the virtual machine can directly obtain the decompressed target data without decompressing it after obtaining the data. This improves the speed at which the container reads image data.

[0071] Reference Figure 3 , Figure 3 This is a schematic diagram of the architecture of a cloud platform according to an embodiment of this application.

[0072] like Figure 3 As shown, the virtual machine may include container components and interface components. The container components may include a content layer and a root file system (rootfs), while the interface components include a snapshotter layer, a control layer, and a FUSE. The cloud storage device may include a first storage module and a second storage module. The first storage module stores the image's metadata, and the second storage module stores the image itself.

[0073] During container startup, the content layer can obtain the address information of the first image. Furthermore, the content layer can send the address information of the first image to the Snapshotter layer. After obtaining the address information of the first image, the Snapshotter layer can pass it to the control layer. The control layer then reads the metadata of the first image from the first storage module in the cloud storage device based on the address information of the first image.

[0074] Furthermore, the control layer sends the metadata of the first image to FUSE, and the virtual machine can create the directory of the first image in FUSE and mount the first image to that directory.

[0075] During the operation of the first container, if the target data is not contained locally on the virtual machine, FUSE can read the target data from the first storage module in the cloud storage device and send the read target data to the rootfs.

[0076] In practice, the various components of a virtual machine can be managed through the SYSTEMD service. When a component malfunctions, the SYSTEMD service can issue an alert and restart the component.

[0077] In practical implementation, the virtual machine can also acquire incremental data, which can be data generated during the operation of the first container. Based on the first image and the incremental data, the virtual machine can obtain a second image. Furthermore, it can execute the image addition command for the second image. It should be noted that the container corresponding to the second image is also the first container; compared to the first image, the second image contains more executable files required by the first container. The second image can be considered as an iterative and optimized version of the first image. Specifically, when the image addition command for the second image is executed, the second image is stored on a cloud storage device, and metadata for the second image is generated on the cloud storage device. In practical implementation, the virtual machine can send incremental data to the cloud storage device to append incremental data to the first image; that is, incremental data can be added to the first image as a new image layer, thus obtaining the second image. Furthermore, metadata for the incremental data can be appended to the metadata of the first image, thus obtaining the metadata of the second image. Finally, the storage address of the second image's metadata on the cloud storage device is pushed to the image repository. Therefore, when the virtual machine on the cloud platform restarts the first container, the virtual machine can still use the solution provided in the embodiments of this application to start and run the first container. That is, the image generated by iterative updates also supports accelerated startup.

[0078] Reference Figure 5 , Figure 5 This is a schematic diagram illustrating the execution of a new image command in an embodiment of this application. The first image includes N image layers, namely image layer 0, image layer 1, image layer 2, ..., image layer N-1. Figure 5 As shown, the directories in FUSE correspond one-to-one with the image layers of the first image. Directory 0 is mounted with image layer 0, directory 1 with image layer 1, directory 2 with image layer 2, and so on, until directory N-1 is mounted with image layer N-1. After the virtual machine obtains the incremental data, directory N can be created, and the incremental data can be written to directory N. Further, the virtual machine sends the incremental data to the cloud storage device, and the incremental data is appended to the first image as image layer N, thus obtaining the second image.

[0079] In practical implementation, after obtaining the second image, each slave cluster in the cluster group can generate an image addition command and send it to the master cluster. The master cluster can execute the image addition command for the second image when it is idle. This approach helps reduce concurrency risks and improve reliability in multi-cluster scenarios.

[0080] It is understandable that, in specific implementation, the above method can be implemented using a software program that runs in the processor integrated inside the chip or chip module; or, the method can be implemented using hardware or a combination of hardware and software, such as using a dedicated chip or chip module, or using a dedicated chip or chip module combined with a software program.

[0081] Reference Figure 4 , Figure 4 This is a schematic diagram of the structure of a container starting device according to an embodiment of this application. Figure 4 The apparatus shown may include:

[0082] Address download module 41 is used to download the address information of the first image from a public image repository. The address information is used to indicate the storage address of the metadata of the first image in a private cloud storage device.

[0083] Data reading module 42 is used to read the metadata from the storage address;

[0084] The startup module 43 is used to start the container corresponding to the first image based on the metadata. For more information on the working principle, method, and beneficial effects of the container startup device in this embodiment, please refer to the above description of the container startup method; further details will not be repeated here.

[0085] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is run by a computer, the above-described method is executed. The storage medium may include read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. The storage medium may also include non-volatile memory or non-transitory memory, etc.

[0086] This application also provides an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it performs the steps of the method described above. The electronic device may be a computing device such as a cloud platform server.

[0087] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is run by a processor, it performs the steps of the container startup method described above. The storage medium may include ROM, RAM, a disk, or an optical disk, etc. The storage medium may also include non-volatile memory or non-transitory memory, etc.

[0088] It should be understood that in the embodiments of this application, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0089] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0090] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means.

[0091] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatus, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or in a combination of hardware and software functional units. For example, for various devices or products applied to or integrated into a chip, each module / unit can be implemented using hardware such as circuits, or at least some modules / units can be implemented using software programs running on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware such as circuits; for various devices or products applied to or integrated into a chip module, each module / unit can be implemented using hardware such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0093] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article indicates that the preceding and following related objects have an "or" relationship.

[0094] In this application's embodiments, "multiple" refers to two or more. The descriptions of "first," "second," etc., appearing in this application's embodiments are merely illustrative and for distinguishing the described objects; they do not indicate any order and do not imply a specific limitation on the number of devices in this application's embodiments, nor do they constitute any limitation on the embodiments of this application. Although this application discloses the above, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

[0095] While this application discloses the above information, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application shall be determined by the scope defined in the claims.

Claims

1. A container startup method, characterized in that, The method includes: Download the address information of the first image from a public image repository. The address information is used to indicate the storage address of the metadata of the first image in a private cloud storage device. Read the metadata from the storage address; The container corresponding to the first image is started based on the metadata.

2. The container startup method according to claim 1, characterized in that, Starting the container corresponding to the first image based on the metadata includes: Create a directory for the first image in the user-space file system; Based on the metadata, the first image is mounted to the directory.

3. The container startup method according to claim 2, characterized in that, The method further includes: Obtain a read request, the read request being used to request target data in the first image; If the target data is not found in either the first-level cache or the second-level cache, the target data is read from the cloud storage device. The first-level cache is the operating system cache, and the second-level cache is the cache of the user-space file system.

4. The container startup method according to claim 1, characterized in that, The first image is stored in the cloud storage device after being decompressed.

5. The container startup method according to claim 1, characterized in that, The method further includes: Acquire incremental data, which is generated during the operation of the container; A second image is generated based on the first image and the incremental data; Execute the command to add a new image for the second image; The execution of the image addition command for the second image includes: The second image is stored in the cloud storage device, and metadata of the second image is generated in the cloud storage device; The metadata of the second image is pushed to the image repository from the storage address of the cloud storage device.

6. The container startup method according to claim 5, characterized in that, The cloud storage device is shared by multiple clusters in the cluster group, and the image addition command is executed by the main cluster among the multiple clusters in an idle state.

7. A container starting device, characterized in that, The device includes: The address download module is used to download the address information of the first image from a public image repository. The address information is used to indicate the storage address of the metadata of the first image in a private cloud storage device. A data reading module is used to read the metadata from the storage address; The startup module is used to start the container corresponding to the first image based on the metadata.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it performs the steps of the container startup method according to any one of claims 1 to 6.

9. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the container startup method according to any one of claims 1 to 6.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor runs the computer program, it performs the steps of the container startup method according to any one of claims 1 to 6.