Container image distribution method and device for network block storage device

Abstract

The application discloses a container image distribution method and device for network block storage equipment, the method is executed in a container orchestration system, comprising: mounting an initial storage volume based on network block storage equipment in an initial Pod, and pulling a container image from an image warehouse, unfolding the container image into an image file system on the initial storage volume, obtaining an initial image storage volume containing the image file system, and the image file system containing all read-only layers of the container image; generating an image template snapshot based on the initial image storage volume; on the network block storage equipment, cloning multiple cloned image storage volumes based on the image template snapshot by using a copy-on-write mechanism, and mounting the multiple cloned image storage volumes into multiple new Pods respectively to obtain multiple user Pod instances, so that the multiple user Pod instances share all read-only layers of the container image stored on the container block storage equipment. Therefore, efficient distribution and sharing of the container image in the network block storage scene can be realized.

Description

Technical Field

[0001] This invention relates to the field of container image distribution technology, and in particular to a container image distribution method and apparatus for network block storage devices. Background Technology

[0002] In Kubernetes (K8s) container orchestration systems, the standard distribution process for container images is as follows: Container images are stored in remote image repositories (such as Harbor and Docker Hub) in the OCI standard format. When the K8s scheduler assigns a Pod to a worker node, the container runtime on that node (such as containerd or CRI-O) pulls the container image from the image repository to the node's local disk. Then, it overlays multiple read-only image layers of the container image using overlayfs (a union file system), adding a read-write layer (container layer) on top, thus forming the container's complete file system. In this standard architecture, the overlayfs image layers are stored on the node's local disk, and multiple containers using the same image on the same node can share these read-only layers, which is a natural advantage of overlayfs. However, this mechanism heavily relies on local node storage.

[0003] In AI computing, high-performance computing, and other scenarios, user containers need to persistently store the runtime file system state to ensure data integrity after container shutdown. To achieve this, existing technologies replace the underlying storage of containers with network block storage devices (such as Ceph RBD, AWS EBS, etc.), i.e., mounting a network block storage PVC in the Pod as the underlying storage for the container file system. However, network block storage devices typically only support ReadWriteOnce (RWO) access mode, meaning only one node can mount and read from it at a time. This limitation prevents multiple Pods from simultaneously sharing the image layers stored in the overlayfs on the network block storage device; therefore, each Pod needs to have its own complete copy of the image data.

[0004] According to existing technical solutions, each time a new Pod instance is created, the complete container image needs to be pulled from the image repository and expanded again. For AI training images of 10-30GB in size, each pull takes 5-10 minutes, which seriously affects user experience and cluster resource utilization efficiency. When the same image is used by a large number of users (such as dozens of students using the same development environment in a teaching scenario), this repeated pulling causes a huge waste of network bandwidth and time.

[0005] Currently, the industry mainly offers the following solutions for optimizing Kubernetes container image distribution: (1) Node-level image pre-caching scheme Open-source projects such as kube-fledged and warm-image pre-pull images to the local disk on each node. However, this approach still relies on the overlayfs sharing mechanism on the node's local disk and cannot solve the container image sharing problem in network block storage scenarios.

[0006] (2) Mirror repository proxy caching scheme Tools like kube-image-keeper deploy image repository proxies within the cluster, reducing access to external repositories. However, each Pod still needs to pull the complete image, failing to fundamentally solve the problem of duplicate pulls.

[0007] (3) P2P Mirror Distribution Scheme Solutions like Dragonfly and Kraken accelerate the distribution of images between nodes through P2P networks. While these solutions optimize transmission efficiency, they do not change the fundamental requirement that each node needs a complete copy of the image, and are not suitable for network block storage scenarios.

[0008] (4) Image lazy loading scheme Solutions like Stargz Snapshotter and SOCI accelerate container startup by loading image layers on demand. However, these solutions are still based on the overlayFS architecture, require specific support for image formats, and do not address the sharing issues inherent in block storage RWO limitations.

[0009] In summary, existing technical solutions are all based on the traditional "node local storage + overlayfs" architecture design, which fails to solve the core problem that container images cannot be shared across Pods in network block storage scenarios.

[0010] Therefore, a container image distribution method for network block storage devices is needed to solve the problems existing in the above technical solutions. Summary of the Invention

[0011] Therefore, the present invention provides a container image distribution method and apparatus for network block storage devices to solve or at least alleviate the problems mentioned above.

[0012] According to one aspect of the present invention, a method for distributing container images to network block storage devices is provided, executed in a container orchestration system, comprising: Mount an initial storage volume based on a network block storage device within the initial Pod, pull a container image from an image repository, expand the container image into an image file system on the initial storage volume, and obtain an initial image storage volume containing the image file system, wherein the image file system contains all read-only layers of the container image; Generate an image template snapshot based on the initial image storage volume; On the network block storage device, based on the image template snapshot, multiple cloned image storage volumes are cloned using the copy-on-write mechanism, and the multiple cloned image storage volumes are respectively mounted into multiple new Pods to obtain multiple user Pod instances, so that the multiple user Pod instances can share all read-only layers of the container image stored on the container block storage device.

[0013] Optionally, in the container image distribution method for network block storage devices according to the present invention, in the network block storage device, based on the image template snapshot, multiple cloned image storage volumes are cloned using a copy-on-write mechanism, and the multiple cloned image storage volumes are respectively mounted into multiple new Pods to obtain multiple user Pod instances, including: whenever a request to create a user Pod instance based on image information is received, obtaining the corresponding image template snapshot according to the image information and creating a new Pod; and in the network block storage device, cloning cloned image storage volumes based on the image template snapshot using a copy-on-write mechanism and mounting the cloned image storage volumes into the new Pods to obtain user Pod instances.

[0014] Optionally, the container image distribution method for network block storage devices according to the present invention further includes: if there is no image template snapshot corresponding to the image information, then: mount an initial storage volume based on the network block storage device in the initial Pod, pull the container image corresponding to the image information from the image repository, expand the container image in the initial storage volume into an image file system, and obtain an initial image storage volume containing the image file system.

[0015] Optionally, in the container image distribution method for network block storage devices according to the present invention, generating an image template snapshot based on the initial image storage volume includes: generating an image template snapshot based on the initial image storage volume in the network block storage device using a copy-on-write mechanism via a CSI driver; and cloning multiple cloned image storage volumes in the network block storage device based on the image template snapshot using a copy-on-write mechanism, including: calling the cloning interface of the network block storage device via a CSI driver to clone multiple cloned image storage volumes in the network block storage device based on the image template snapshot using a copy-on-write mechanism.

[0016] Optionally, in the container image distribution method for network block storage devices according to the present invention, pulling a container image from an image repository and expanding the container image into an image file system on the initial storage volume includes: setting the initial storage volume as the root directory for the image layer storage of the container engine; executing the image pull command of the container engine within the initial Pod to pull the container image from the image repository, and directly decompressing each layer of the container image and writing it into the file system of the initial storage volume, so as to form an expanded image file system on the initial storage volume.

[0017] Optionally, in the container image distribution method for network block storage devices according to the present invention, after mounting the cloned image storage volume into the new Pod, the method further includes: configuring the cloned image storage volume as an additional image read-only storage directory for the container engine, so that when a user container instance is started, the image file system is loaded from the additional image read-only storage directory without having to pull and expand the container image from the image repository.

[0018] Optionally, in the container image distribution method for network block storage devices according to the present invention, the initial image storage volume is configured with a corresponding combined label; before mounting the initial storage volume based on the network block storage device in the initial Pod, the method includes: performing an idempotency check based on the combined label to determine whether an initial image storage volume corresponding to the combined label already exists; if it does not exist, mounting the initial storage volume based on the network block storage device in the initial Pod, pulling the container image from the image repository, and expanding the container image into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system; if it already exists, generating an image template snapshot based on the initial image storage volume corresponding to the combined label; wherein, the combined label includes one or more of an image identifier, a storage type identifier, and a user group identifier.

[0019] Optionally, in the container image distribution method for network block storage devices according to the present invention, mounting an initial storage volume based on the network block storage device within an initial Pod, pulling a container image from an image repository, and expanding the container image into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system includes: responding to a request to create an initial image storage volume corresponding to each type of image information in a predetermined image information list triggered by a batch preheating interface, for each type of image information, mounting an initial storage volume based on the network block storage device within an initial Pod, pulling a container image corresponding to the image information from an image repository, and expanding the container image into an image file system on the initial storage volume to obtain an initial image storage volume corresponding to the image information containing the image file system.

[0020] Optionally, in the container image distribution method for network block storage devices according to the present invention, the container image is in OCI format; mounting an initial storage volume based on the network block storage device within an initial Pod, pulling a container image from an image repository, and expanding the container image into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system, includes: creating a Job controller for a container orchestration system, creating an initial Pod through the Job controller, mounting an initial storage volume based on the network block storage device within the initial Pod, pulling a container image from an image repository, and expanding the container image into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system.

[0021] Optionally, in the container image distribution method for network block storage devices according to the present invention, generating an image template snapshot based on the initial image storage volume includes: periodically querying the execution status of the Job controller; if the Job controller executes successfully, generating an image template snapshot based on the initial image storage volume; if the Job controller fails to execute or the polling times out, terminating the process and recording the error.

[0022] Optionally, in the container image distribution method for network block storage devices according to the present invention, generating an image template snapshot based on the initial image storage volume includes: generating a storage volume snapshot resource object based on the initial image storage volume through a storage volume snapshot resource interface, and using the storage volume snapshot resource object as an image template snapshot.

[0023] Optionally, the container image distribution method for network block storage devices according to the present invention further includes: establishing and maintaining a storage class mapping configuration file and a snapshot class mapping configuration file, wherein the storage class mapping configuration file is used to map user group identifiers to corresponding block storage class names, and the snapshot class mapping configuration file is used to map user group identifiers to corresponding storage volume snapshot class names; mounting an initial storage volume based on a network block storage device within an initial Pod includes: obtaining the corresponding block storage class name from the storage class mapping configuration file according to the user group identifier, and mounting the initial storage volume based on the network block storage device corresponding to the block storage class name within the initial Pod; generating an image template snapshot based on the initial image storage volume includes: obtaining the corresponding storage volume snapshot class name from the snapshot class mapping configuration file according to the user group identifier; and generating an image template snapshot based on the initial image storage volume using the storage volume snapshot class corresponding to the storage volume snapshot class name.

[0024] Optionally, in the container image distribution method for network block storage devices according to the present invention, before generating an image template snapshot based on the initial image storage volume, the method further includes: checking whether an image template snapshot corresponding to the initial image storage volume already exists; if it already exists, then no image template snapshot is generated based on the initial image storage volume; if it does not exist, then an image template snapshot is generated based on the initial image storage volume.

[0025] According to one aspect of the present invention, a container image distribution apparatus for network block storage devices is provided, deployed in a container orchestration system, and adapted to perform the method described above, the apparatus comprising: The image preheating module is suitable for mounting an initial storage volume based on a network block storage device within an initial Pod, pulling a container image from an image repository, expanding the container image into an image file system on the initial storage volume, and obtaining an initial image storage volume containing the image file system, wherein the image file system contains all read-only layers of the container image. The snapshot generation module is adapted to generate an image template snapshot based on the initial image storage volume; The clone distribution module is adapted to clone multiple clone image storage volumes based on the image template snapshot on the network block storage device using a copy-on-write mechanism, and to mount the multiple clone image storage volumes into multiple new Pods respectively to obtain multiple user Pod instances, so as to enable the multiple user Pod instances to share all read-only layers of the container image stored on the container block storage device.

[0026] According to one aspect of the present invention, a computing device is provided, comprising: at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing a container image distribution method for a network block storage device as described above.

[0027] According to one aspect of the present invention, a computer program product is provided, comprising computer program instructions, wherein the computer program instructions, when executed by a processor, implement the method as described above.

[0028] According to one aspect of the present invention, a readable storage medium storing program instructions is provided, which, when read and executed by a computing device, causes the computing device to perform the container image distribution method for network block storage devices as described above.

[0029] According to the technical solution of this invention, a method for distributing container images to network block storage devices is provided. This method involves expanding the pulled container image into an image file system on an initial storage volume of the network block storage device to obtain an initial image storage volume. An image template snapshot is then generated based on this initial image storage volume. Subsequently, multiple cloned image storage volumes can be cloned on the network block storage device using a copy-on-write mechanism based on the image template snapshot. These cloned image storage volumes are then mounted into multiple new Pods to obtain multiple user Pod instances. This enables multiple user Pod instances to share the read-only layer of the container image stored on the container block storage device, solving the problem of container images not being shareable across Pods in network block storage scenarios. This allows multiple user Pod instances to share the same set of underlying data blocks in the storage backend, with only incremental storage space usage. Furthermore, when creating a user Pod instance, there is no need to repeatedly pull the container image from the image repository or wait for the container image to expand; cloning is completed instantly, reducing the time to create a user Pod instance from minutes to seconds (<10 seconds). Based on this, efficient distribution and sharing of container images in network block storage scenarios can be achieved.

[0030] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0031] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the principles disclosed herein may be practiced, and all aspects and their equivalents are intended to fall within the scope of the claimed subject matter. The foregoing and other objectives, features, and advantages of the invention will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings. Throughout the invention, the same reference numerals generally refer to the same parts or elements.

[0032] Figure 1 A schematic diagram of a computing device 100 provided according to an embodiment of the present invention is shown; Figure 2 A flowchart illustrating a container image distribution method 200 for network block storage devices according to an embodiment of the present invention is shown. Figure 3 A schematic diagram illustrating the principle of a container image distribution method for network block storage devices according to an embodiment of the present invention is shown. Figure 4 A schematic diagram of a storage structure for a copy-on-write mechanism according to some embodiments of the present invention is shown; Figure 5A schematic diagram of a container image distribution apparatus 500 for a network block storage device is shown according to an embodiment of the present invention. Detailed Implementation

[0033] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0034] For ease of understanding, the terms used in the embodiments of this invention will be explained below.

[0035] Pod: The smallest schedulable computing unit in container orchestration systems such as Kubernetes, which typically contains one or more containers.

[0036] PVC (Persistent Volume Claim): An abstraction in the container orchestration system (K8s) for requesting storage resources, used to mount the underlying persistent storage data volume in a Pod.

[0037] PV (Persistent Volume): The actual storage resource in a container orchestration system (Kubernetes).

[0038] CSI (Container Storage Interface): A standardized interface between Kubernetes and the storage backend.

[0039] COW (Copy-on-Write): A storage optimization technique that uses delayed copying.

[0040] OCI (Open Container Initiative): The standard specification for container images and runtimes.

[0041] RBD (RADOS Block Device): The block device interface of the Ceph distributed storage system.

[0042] RWO (ReadWriteOnce): The access mode for network block storage devices, which only allows single-node read and write mounting.

[0043] OverlayFS (Overlay Filesystem): The underlying storage technology for container images.

[0044] VolumeSnapshot: A storage volume snapshot resource in Kubernetes, one of the CSI standard features.

[0045] Harbor (Harbor Container Registry): An enterprise-grade open-source container image repository.

[0046] To address the technical problem in Kubernetes container orchestration systems where the underlying storage of containers is network block storage devices, the read-only layer of container images cannot be shared among multiple Pods due to the limitations of the ReadWriteOnce (RWO) access mode of network block storage devices. This necessitates pulling the complete image from the image repository again for each Pod instance creation. This invention provides a container image distribution method for network block storage devices. It converts the container image from the OCI standard format to the storage system's native storage volume snapshot format and utilizes the write-on-write replication cloning capability of the storage backend to replace the overlayfs layer sharing mechanism, enabling efficient distribution and sharing of container images in network block storage scenarios.

[0047] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0048] Figure 1 A schematic diagram of a computing device 100 according to an embodiment of the present invention is shown. Figure 1 As shown, in a basic configuration, computing device 100 includes at least one processing unit 102 and system memory 104. According to one aspect, depending on the configuration and type of the computing device, the processing unit 102 may be implemented as a processor. System memory 104 includes, but is not limited to, volatile memory (e.g., random access memory), non-volatile memory (e.g., read-only memory), flash memory, or any combination of such memories. According to one aspect, system memory 104 includes an operating system 105.

[0049] According to one aspect, operating system 105 is, for example, suitable for controlling the operation of computing device 100. Furthermore, examples are practiced in conjunction with graphics libraries, other operating systems, or any other applications, and are not limited to any particular application or system. Figure 1 The basic configuration is illustrated by the components within the dashed lines. According to one aspect, the computing device 100 has additional features or functions. For example, according to one aspect, the computing device 100 includes additional data storage devices (removable and / or non-removable), such as disks, optical discs, or magnetic tapes. This additional storage... Figure 1 The middle part is shown by removable storage device 109 and non-removable storage device 110.

[0050] As stated above, according to one aspect, program module 103 is stored in system memory 104. According to one aspect, program module 103 may include one or more applications. The present invention does not limit the type of application; for example, applications may include: email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, web browser applications, etc.

[0051] According to one aspect, program module 103 may include a plurality of program instructions adapted to perform the container image distribution method 200 for a network block storage device according to the present invention, such that computing device 100 is configured to perform the container image distribution method 200 for a network block storage device according to the present invention.

[0052] According to one aspect, program module 103 may include a container image distribution device 500 for a network block storage device, which may be configured to perform the container image distribution method 200 for a network block storage device of the present invention.

[0053] According to one aspect, examples can be practiced on circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, it can be practiced via wherein... Figure 1 Each or many of the components shown can be implemented as an example by integrating a System-on-a-Chip (SOC) on a single integrated circuit. According to one aspect, such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or “burned in”) as a single integrated circuit onto a chip substrate. When operating via the SOC, the functions described herein can be operated via dedicated logic integrated on a single integrated circuit (chip) with other components of the computing device 100. Embodiments of the invention can also be implemented using other techniques capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. Additionally, embodiments of the invention can be implemented within a general-purpose computer or in any other circuit or system.

[0054] According to one aspect, computing device 100 may also have one or more input devices 112, such as a keyboard, mouse, pen, voice input device, touch input device, etc. It may also include output devices 114, such as a display, speaker, printer, etc. The foregoing devices are examples and other devices may also be used. Computing device 100 may include one or more communication connections 116 that allow communication with other computing devices 118. Examples of suitable communication connections 116 include, but are not limited to: RF transmitter, receiver and / or transceiver circuitry; Universal Serial Bus (USB), parallel and / or serial ports.

[0055] As used herein, the term computer-readable medium includes computer storage medium. Computer storage medium can include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information (e.g., computer-readable instructions, data structures, or program module 103). System memory 104, removable storage device 109, and non-removable storage device 110 are examples of computer storage media (i.e., memory storage). Computer storage media can include random access memory (RAM), read-only memory (ROM), electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and is accessible by computing device 100. According to one aspect, any such computer storage medium can be part of computing device 100. Computer storage media does not include carrier waves or other transmitted data signals.

[0056] According to one aspect, the communication medium is implemented by computer-readable instructions, data structures, program modules 103, or other data in a modulated data signal (e.g., a carrier wave or other transmission mechanism), and includes any information transmission medium. According to one aspect, the term "modulated data signal" describes a signal having one or more sets of characteristics or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0057] In an embodiment of the present invention, a computing device 100 is configured to execute a container image distribution method 200 for a network block storage device according to the present invention. The computing device 100 includes one or more processors and one or more readable storage media storing program instructions that, when executed by the one or more processors, cause the computing device to execute the container image distribution method 200 for a network block storage device according to the present invention.

[0058] In an embodiment of the present invention, the computing device 100 for executing the container image distribution method 200 for network block storage devices of the present invention may be a terminal or a server.

[0059] In an embodiment of the present invention, the container image distribution method 200 for network block storage devices can be executed in a container orchestration system (Kubernetes), which is deployed in a computing device (e.g., the aforementioned computing device 100), thereby enabling the container image distribution method 200 for network block storage devices of the present invention to be executed in the container orchestration system of the computing device 100.

[0060] Figure 2 A flowchart illustrating a container image distribution method 200 for network block storage devices provided according to an embodiment of the present invention is shown. Figure 3 A schematic diagram illustrating the principle of a container image distribution method for network block storage devices according to an embodiment of the present invention is shown below. Figure 2 and Figure 3 The following is a detailed description of the container image distribution method 200 for network block storage devices in this embodiment of the invention.

[0061] like Figure 2 As shown, the container image distribution method 200 for network block storage devices includes the following steps 210-230.

[0062] Step 210: Mount an initial storage volume (initial PVC) based on a network block storage device within the initial Pod (initial Pod object), and pull a container image from the image repository (the container image can be pulled from the image repository based on the image information). Expand the container image into an image file system on the initial storage volume, thereby obtaining an initial image storage volume containing the image file system (i.e., the initial image storage volume corresponding to the above container image). This image file system contains all read-only layers of the container image (the target structure of all read-only layers).

[0063] It should be noted that step 210 is the image preheating step. The container image pulled from the image repository is in OCI format (standard image format). Step 210 enables the container image to be converted from the OCI standard image format to the expanded local file system format on the storage volume.

[0064] In some embodiments, an initial storage volume based on a network block storage device can be pre-created to store the expanded image file system. The capacity of the initial storage volume can be allocated according to the container image size; for example, the capacity of the initial storage volume can be set to 300 GiB. Subsequently, in step 210, the initial storage volume based on the network block storage device can be mounted within the initial Pod.

[0065] In some embodiments, before executing step 210, a Job controller (Kubernetes Job controller) of the container orchestration system can be pre-created, and then step 210 can be executed through the Job controller. Specifically, in step 210, an initial Pod can be created through the Job controller, and an initial storage volume based on a network block storage device can be mounted in the initial Pod (i.e., the initial Pod in the Job controller). Container images can be pulled from the image repository, and the container images can be expanded into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system.

[0066] It should be noted that during the container image pulling process, the container image can be expanded on the initial storage volume. After the container image is pulled, a complete, expanded image file system can be formed on the initial storage volume, thus obtaining an initial image storage volume containing the image file system.

[0067] In some embodiments, before pulling container images from the image repository, a container engine (e.g., Podman) can be configured within the initial Pod, setting the initial storage volume as the image layer storage root directory (graphroot) of the container engine. Specifically, the initial storage volume can be mounted to the path pointed to by the graphroot parameter in the container engine configuration file. Subsequently, the Job controller can execute the container engine's image pull command (pull command) within the initial Pod. By executing the container engine's image pull command, container images can be pulled from the image repository. During the container image pull process, each layer of the container image can be directly decompressed and written to the file system of the initial storage volume. After the container image is pulled, a complete, expanded image file system can be formed on the initial storage volume, thus obtaining an initial image storage volume containing the image file system.

[0068] In some embodiments, the image pull command contains image information, and the container image corresponding to the image information can be pulled from the image repository (e.g., Harbor) by executing the image pull command.

[0069] In some embodiments, after successfully executing step 210 to obtain an initial mirror storage volume containing a mirror file system, the ready state of the initial mirror storage volume can be marked by setting a ready state tag for the initial mirror storage volume (i.e., marking that the initial mirror storage volume contains a complete mirror file system).

[0070] Step 220: Generate an image template snapshot based on the initial image storage volume obtained in step 210.

[0071] In some embodiments, after determining that the initial image storage volume is ready based on the ready status label of the initial image storage volume, step 220 can be performed to generate an image template snapshot based on the initial image storage volume.

[0072] In some embodiments, before executing step 220, the execution status of the Job controller can be periodically queried to determine whether the Job controller has successfully executed step 210 (whether the execution was successful); if the Job controller executes successfully, then proceed to step 220 (generating an image template snapshot based on the initial image storage volume); if the Job controller fails to execute or the polling times out, then terminate the process and record the error.

[0073] After the Job controller successfully completes step 210 and before executing step 220, the initial image storage volume can be marked as containing a complete image file system (image data) by setting a ready status label on the initial image storage volume. In this way, the ready status of the initial image storage volume can be determined based on the ready status label of the initial image storage volume.

[0074] In some embodiments, in step 220, a snapshot operation can be performed on the network block storage device (storage backend) via the CSI driver. Specifically, the snapshot operation can employ a copy-on-write (COW) mechanism. That is, a mirror template snapshot can be generated on the network block storage device based on the initial mirror storage volume using the copy-on-write mechanism via the CSI driver. Because the snapshot uses the COW mechanism, the snapshot creation process is almost instantaneous and does not occupy an additional amount of storage space equal to that of the initial mirror storage volume, thus avoiding the need for additional storage space.

[0075] In some embodiments, when generating an image template snapshot based on an initial image storage volume, a storage volume snapshot resource object (VolumeSnapshot object) can be generated based on the initial image storage volume by calling the storage volume snapshot resource interface (Kubernetes VolumeSnapshot API), and the storage volume snapshot resource object can be used as the image template snapshot.

[0076] In one specific implementation, when generating a storage volume snapshot resource object (VolumeSnapshot object) based on the initial image storage volume through the storage volume snapshot resource interface (KubernetesVolumeSnapshot API), the snapshot.storage.k8s.io API group can be specified, the VolumeSnapshotClassName can be set to the snapshot class of the corresponding network block storage device (i.e., the storage backend) (e.g., csi-rbdplugin-snapclass corresponding to Ceph RBD), and the source.persistentVolumeClaimName can be pointed to the initial image storage volume obtained in step 210.

[0077] In some embodiments, after generating an image template snapshot based on the initial image storage volume, the snapshot's metadata (including the project it belongs to, image ID, system version, etc.) can be recorded using snapshot tags to facilitate subsequent searching and management. After generating the image template snapshot, the original initial image storage volume can be retained (e.g., it can be used later for direct PVC cloning scenarios) or cleaned up according to a policy.

[0078] Step 230: On the network block storage device, based on the image template snapshot, use the copy-on-write mechanism (COWClone) to clone multiple cloned image storage volumes, and mount these cloned image storage volumes into multiple new Pods (new Pod objects) to obtain multiple user Pod instances. This allows multiple user Pod instances to share all read-only layers of the container image stored on the container block storage device; that is, multiple user Pod instances can share the same set of underlying data blocks on the container block storage device (storage backend), with only incremental (modified data blocks) additional space required.

[0079] Figure 4 A schematic diagram of a storage structure for a copy-on-write mechanism according to some embodiments of the present invention is shown. For example... Figure 4 As shown, multiple cloned mirror storage volumes (including cloned mirror storage volume A, cloned mirror storage volume B, and cloned mirror storage volume C) cloned using the copy-on-write mechanism can share a set of underlying data blocks (read-only). Only the modified data blocks (incremental) occupy additional space.

[0080] It's important to note that because the copy-on-write mechanism operates at the storage backend level, the cloned image storage volume logically contains the exact same data as the image template snapshot, but physically, no data blocks are copied (modified data blocks are only copied during subsequent writes). Since there's no actual data copying involved, the cloning process can be completed within 10 seconds. When creating a user Pod instance, the cloned image storage volume is created based on the image template snapshot using the copy-on-write mechanism. There's no need to repeatedly pull container images from the image repository or wait for the container image to expand; the cloning is instantaneous, reducing the time to create a user Pod instance from minutes to seconds (<10 seconds). Furthermore, all cloned image storage volumes share the same set of underlying data blocks, storing only incrementally modified data blocks, thus saving over 90% of storage space.

[0081] In some embodiments, in step 230, the cloning interface of the network block storage device (i.e., the storage backend, such as Ceph RBD) can be called through the CSI driver to clone multiple cloned image storage volumes based on the image template snapshot using the copy-on-write mechanism.

[0082] In some embodiments, step 230 is executed as follows: whenever a request to create a user Pod instance based on image information is received, the corresponding image template snapshot can be found and obtained according to the image information, and a new Pod can be created. Also, (by calling the cloning interface of the network block storage device through the CSI driver) the clone image storage volume is cloned on the network block storage device based on the image template snapshot using the copy-on-write mechanism, and the clone image storage volume is mounted into the new Pod to obtain the user Pod instance.

[0083] Here, if an image template snapshot corresponding to the image information is obtained (meaning an image template snapshot corresponding to the image information has been pre-generated), a new Pod can be created, and a cloned image storage volume can be cloned on the network block storage device based on the image template snapshot using the copy-on-write mechanism. This cloned image storage volume is then mounted into the new Pod to obtain the user Pod instance. If no image template snapshot corresponding to the image information is found (no image template snapshot exists), the user Pod instance can be obtained by executing steps 210-330. Specifically, when executing step 210, an initial storage volume based on the network block storage device can be mounted within the initial Pod, and the container image corresponding to the image information can be pulled from the image repository. The container image is then expanded into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system. That is, step 210 is automatically executed when the user first requests to create a user Pod instance based on the image information.

[0084] In this way, as long as an image template snapshot corresponding to the image information already exists, the creation process of all user Pod instances using the same container image (based on the same image information) is exactly the same. They can be cloned using the copy-on-write mechanism based on the image template snapshot, and the cloning time is consistent (less than 10 seconds). The user container instance only takes about 30 to 40 seconds to start completely. Furthermore, due to the COW mechanism, all cloned image storage volumes share the same set of underlying data blocks, and only the parts that are modified by each individual need to occupy additional storage space.

[0085] It should be noted that, in some embodiments of the present invention, step 210 supports the following two triggering modes.

[0086] 1) Preheating Trigger Mode: Administrators can proactively trigger the creation request for the initial image storage volume corresponding to each image information in a pre-defined image information list (containing image information of various commonly used container images) through a batch preheating interface for popular and frequently used container images. This allows for the batch generation of the initial image storage volume corresponding to each image information (container image) through step 210 (and subsequently, the generation of the image template snapshot corresponding to each image information through step 220). In other words, step 210 can be specifically implemented as follows: The computing device (container orchestration system) can respond to the creation request for the initial image storage volume corresponding to each image information in the pre-defined image information list (containing image information of various commonly used container images) triggered through the batch preheating interface. For each image information, an initial storage volume based on a network block storage device is mounted in the initial Pod, and the container image corresponding to that image information is pulled from the image repository. The container image is then expanded into an image file system on the initial storage volume, resulting in the initial image storage volume corresponding to that image information containing the image file system.

[0087] 2) On-demand trigger mode: Step 210 is automatically triggered when a user first requests to create a user Pod instance based on image information (image information of a container image). That is, when the computing device (container orchestration system) receives a request to create a user Pod instance based on image information, if there is no image template snapshot corresponding to the image information, step 210 is triggered.

[0088] In some embodiments, a corresponding combined label can be configured for the initial mirrored storage volume obtained in step 210. The combined label may include one or more of the following: mirror identifier, storage type identifier, and user group identifier.

[0089] Before each execution of step 210, an idempotency check can be performed based on the combined tag (e.g., image identifier and storage type identifier) ​​to determine if an initial image storage volume corresponding to the combined tag already exists. If no initial image storage volume corresponding to the combined tag exists, then step 210 is executed: mount the initial storage volume based on the network block storage device within the initial Pod, pull the container image from the image repository, and expand the container image into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system. If an initial image storage volume corresponding to the combined tag already exists, then step 210 is skipped, and the process proceeds directly to step 220 (generating an image template snapshot based on the initial image storage volume corresponding to the combined tag) or 230. This avoids repeatedly pulling the same container image. Here, the combined tag can include both an image identifier and a storage type identifier.

[0090] In some embodiments, before performing step 220 (generating an image template snapshot based on the initial image storage volume), it can be checked whether an image template snapshot corresponding to the initial image storage volume already exists. If an image template snapshot corresponding to the initial image storage volume does not exist, then step 220 (generating an image template snapshot based on the initial image storage volume) is performed. If an image template snapshot corresponding to the initial image storage volume already exists, then step 220 (generating an image template snapshot based on the initial image storage volume is skipped) is skipped, and step 230 is performed directly based on that image template snapshot.

[0091] In some embodiments, the combined label may also include a user group identifier. In this way, the image warm-up results (initial image storage volume) and image template snapshots of different user groups can be distinguished by the user group identifier, so that the same container image can maintain its own initial image storage volume and image template snapshot on different storage backends (network block storage devices) without interference.

[0092] In one implementation, a storage class mapping configuration file and a snapshot class mapping configuration file can be pre-established and maintained. The storage class mapping configuration file maps user group identifiers to corresponding block storage class names (corresponding network block storage devices), and the snapshot class mapping configuration file maps user group identifiers to corresponding storage volume snapshot class names. In step 210, when mounting an initial storage volume based on a network block storage device within the initial Pod, the corresponding block storage class name can be obtained from the storage class mapping configuration file based on the user group identifier to use the network block storage device corresponding to the block storage class name. That is, an initial storage volume based on the network block storage device corresponding to the block storage class name can be mounted within the initial Pod. When generating an image template snapshot based on the initial image storage volume, the corresponding storage volume snapshot class name can be obtained from the snapshot class mapping configuration file based on the user group identifier, and then the storage volume snapshot class corresponding to the storage volume snapshot class name can be used to generate an image template snapshot based on the initial image storage volume.

[0093] In some embodiments, in step 230, the cloned image storage volume is mounted into the new Pod in Filesystem mode as an additional image read-only storage directory for the container engine. Specifically, after mounting the cloned image storage volume into the new Pod, it can be configured as an additional image read-only storage directory for the container engine (i.e., the additionalImageStores path) so that when a user container instance starts, the image file system (each read-only layer of the container image) is loaded from this additional image read-only storage directory without having to pull and expand the container image from the image repository.

[0094] Figure 5 A schematic diagram of a container image distribution apparatus 500 for a network block storage device according to an embodiment of the present invention is shown. The container image distribution apparatus 500 for a network block storage device can be deployed in a computing device 100, specifically in the container orchestration system of the computing device 100, and the container image distribution apparatus 500 for a network block storage device is configured to execute the container image distribution method 200 for a network block storage device of the present invention.

[0095] like Figure 5 As shown, in an embodiment of the present invention, a container image distribution device 500 for network block storage devices includes an image preheating module 510, a snapshot generation module 520, and a clone distribution module 530 that are connected in series.

[0096] The image preheating module 510 is used to mount an initial storage volume based on a network block storage device within the initial Pod, pull container images from the image repository, expand the container images into an image file system on the initial storage volume, and obtain an initial image storage volume containing the image file system, which contains all read-only layers of the container image.

[0097] The snapshot generation module 520 is used to generate an image template snapshot based on the initial image storage volume.

[0098] The clone distribution module 530 is used to clone multiple clone image storage volumes on a network block storage device based on an image template snapshot and using a copy-on-write mechanism. The multiple clone image storage volumes are then mounted into multiple new Pods to obtain multiple user Pod instances, so that multiple user Pod instances can share all read-only layers of the container image stored on the container block storage device.

[0099] It should be noted that the image preheating module 510, the snapshot generation module 520, and the clone distribution module 530 are used to execute the aforementioned steps 210 to 230, respectively. The specific execution logic of each module can be found in the description of steps 210 to 230 in method 200 above, and will not be repeated here.

[0100] According to the container image distribution method 200 for network block storage devices in this embodiment of the invention, an initial image storage volume is obtained by expanding the pulled container image into an image file system on the initial storage volume of the network block storage device. An image template snapshot is then generated based on the initial image storage volume. Subsequently, multiple cloned image storage volumes can be cloned on the network block storage device using a copy-on-write mechanism based on the image template snapshot. These cloned image storage volumes are then mounted into multiple new Pods to obtain multiple user Pod instances. This enables multiple user Pod instances to share the read-only layer of the container image stored on the container block storage device, solving the problem of container images not being shareable across Pods in network block storage scenarios. This allows multiple user Pod instances to share the same set of underlying data blocks in the storage backend, with only incremental storage space usage. Furthermore, when creating a user Pod instance, there is no need to repeatedly pull the container image from the image repository or wait for the container image to expand; cloning is completed instantly, reducing the time to create a user Pod instance from minutes to seconds (<10 seconds). Based on this, efficient distribution and sharing of container images in network block storage scenarios can be achieved.

[0101] Furthermore, according to the technical solution of this invention, by replacing traditional image pulling with COW cloning, the image cloning time is reduced from 5-10 minutes to less than 10 seconds, and the complete Pod startup time is approximately 30-40 seconds, representing an improvement of more than 10 times. For AI computing scenarios requiring rapid elastic scaling (such as teaching and competitions), the user experience is significantly improved.

[0102] Based on the COW mechanism, 100 user Pod instances using the same container image only need to store one complete image data plus their respective incremental modifications, instead of 100 complete copies. For a 30GB container image, the traditional solution requires 3TB of storage space, while this invention only requires 30GB plus a small amount of incremental storage, saving more than 90% of storage space.

[0103] Moreover, according to the technical solution of the present invention, each container image only needs to be pulled from the remote repository once, and all subsequent user Pod instances are cloned locally through the storage backend, avoiding repeated network transmission.

[0104] Furthermore, according to the technical solution of this invention, the native snapshot and cloning mechanism of the storage system is innovatively used to replace the layer sharing function of overlayfs, fundamentally solving the problem that ReadWriteOnce block storage cannot share the read-only layer of container images among multiple Pod instances.

[0105] Furthermore, this invention is based on the Kubernetes standard CSI interface and VolumeSnapshot API, and does not depend on a specific storage backend or container runtime. It is applicable to all network block storage devices that support CSI snapshot functionality (such as CephRBD, AWS EBS, Azure Disk, etc.).

[0106] It should also be pointed out that the industry's optimization efforts for container image distribution have long focused on the overlayfs framework (such as lazy loading, P2P distribution, and node pre-caching), resulting in a fixed technical bias that "image distribution is simply pulling the image to the local node." This invention breaks free from the overlayfs framework, fundamentally replacing the layer sharing function of overlayfs by utilizing the native capabilities of the storage system (snapshots and COW cloning), representing an innovation that overcomes technical bias.

[0107] Table 1 compares the test data of the technical solution of this invention and the traditional solution in a real production environment. Test environment: Kubernetes v1.28 cluster, storage backend is Ceph RBD (network block storage device), and the test image is the AI ​​training environment image.

[0108] Table 1. Comparison of Test Data

[0109] As shown in Table 1, the technical solution of this invention achieves orders-of-magnitude improvements in three dimensions: image preparation time, storage space usage, and network bandwidth consumption. The advantages become more pronounced with a larger number of instances. Particularly in large-scale, homogeneous environment deployments such as teaching and competitions, storage space savings of up to 98% can be achieved with 100 instances, demonstrating significant technical effectiveness.

[0110] The various techniques described herein can be implemented in combination with hardware or software, or a combination thereof. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embedded in a tangible medium, such as a removable hard disk, USB flash drive, floppy disk, CD-ROM, or any other machine-readable storage medium, wherein when the program is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the present invention.

[0111] When the program code is executed on a programmable computer, the mobile terminal generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. The memory is configured to store program code; the processor is configured to execute the container image distribution method for network block storage devices according to instructions in the program code stored in the memory.

[0112] By way of example, and not limitation, readable media include readable storage media and communication media. Readable storage media stores information such as computer-readable instructions, data structures, program modules, or other data. Communication media generally embodies computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals such as carrier waves or other transmission mechanisms, and includes any information delivery medium. Any combination of the above is also included within the scope of readable media.

[0113] In the specification provided herein, the algorithms and displays are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used with the examples of this invention. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0114] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0115] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof.

[0116] Those skilled in the art will understand that modules, units, or components of the devices disclosed in the examples herein can be arranged in the devices described in this embodiment, or alternatively, can be located in one or more devices different from the devices in this example. The modules in the foregoing examples can be combined into a single module or, in addition, can be divided into multiple sub-modules.

[0117] Unless otherwise specified, the use of ordinal numbers such as “first,” “second,” “third,” etc., to describe ordinary objects merely indicates different instances of similar objects and is not intended to imply that the objects being described must have a given order in time, space, ordering, or any other manner.

Claims

1. A method for distributing container images to network block storage devices, executed in a container orchestration system, comprising: Mount an initial storage volume based on a network block storage device within the initial Pod, pull a container image from an image repository, expand the container image into an image file system on the initial storage volume, and obtain an initial image storage volume containing the image file system, wherein the image file system contains all read-only layers of the container image; Generate an image template snapshot based on the initial image storage volume; On the network block storage device, based on the image template snapshot, multiple cloned image storage volumes are cloned using the copy-on-write mechanism, and the multiple cloned image storage volumes are respectively mounted into multiple new Pods to obtain multiple user Pod instances, so that the multiple user Pod instances can share all read-only layers of the container image stored on the container block storage device.

2. The method as described in claim 1, wherein, On the network block storage device, based on the image template snapshot, multiple cloned image storage volumes are cloned using a copy-on-write mechanism, and these cloned image storage volumes are mounted into multiple new Pods to obtain multiple user Pod instances, including: Whenever a request to create a user Pod instance based on image information is received, the corresponding image template snapshot is obtained according to the image information, a new Pod is created, and on the network block storage device, a cloned image storage volume is cloned using the copy-on-write mechanism based on the image template snapshot, and the cloned image storage volume is mounted into the new Pod to obtain the user Pod instance.

3. The method as described in claim 2, wherein, Also includes: If there is no image template snapshot corresponding to the image information, then: mount an initial storage volume based on a network block storage device in the initial Pod, pull the container image corresponding to the image information from the image repository, expand the container image into an image file system in the initial storage volume, and obtain an initial image storage volume containing the image file system.

4. The method according to any one of claims 1-3, wherein, Generating an image template snapshot based on the initial image storage volume includes: Driven by CSI, a mirror template snapshot is generated on the network block storage device using a copy-on-write mechanism based on the initial mirror storage volume. On the network block storage device, based on the image template snapshot, multiple cloned image storage volumes are cloned using a copy-on-write mechanism, including: By calling the cloning interface of the network block storage device through the CSI driver, multiple cloned image storage volumes are cloned on the network block storage device based on the image template snapshot using the copy-on-write mechanism.

5. The method according to any one of claims 1-4, wherein, Pulling a container image from the image repository and expanding the container image into an image file system on the initial storage volume includes: Set the initial storage volume as the root directory for the container engine's image layer storage; The container engine's image pull command is executed within the initial Pod to pull container images from the image repository, and each layer of the container image is directly decompressed and written to the file system of the initial storage volume to form an expanded image file system on the initial storage volume.

6. The method of claim 2, wherein, After mounting the cloned image storage volume into the new Pod, the process also includes: Configure the cloned image storage volume as an additional image read-only storage directory for the container engine so that the image file system is loaded from the additional image read-only storage directory when a user container instance is started, without having to pull and expand the container image from the image repository.

7. The method according to any one of claims 1-6, wherein, The initial image storage volume is configured with a corresponding combined tag; before mounting the initial storage volume based on the network block storage device within the initial Pod, the following steps are included: An idempotency check is performed based on the combined tag to determine whether an initial mirror storage volume corresponding to the combined tag already exists. If it does not exist, mount the initial storage volume based on the network block storage device in the initial Pod, pull the container image from the image repository, expand the container image into an image file system in the initial storage volume, and obtain the initial image storage volume containing the image file system. If it already exists, generate an image template snapshot based on the initial image storage volume corresponding to the combined label; The combined label includes one or more of the following: image identifier, storage type identifier, and user group identifier.

8. The method according to any one of claims 1-7, wherein, An initial storage volume based on a network block storage device is mounted within the initial Pod, and a container image is pulled from an image repository. The container image is then expanded into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system, including: In response to a request to create an initial image storage volume corresponding to each image information in a predefined image information list triggered by a batch preheating interface, for each image information, an initial storage volume based on a network block storage device is mounted in the initial Pod, and the container image corresponding to the image information is pulled from the image repository. The container image is then expanded into an image file system in the initial storage volume to obtain the initial image storage volume corresponding to the image information containing the image file system.

9. The method according to any one of claims 1-8, wherein, The container image is in OCI format; an initial storage volume based on a network block storage device is mounted within the initial Pod, and the container image is pulled from the image repository. The container image is then expanded into an image file system on the initial storage volume, resulting in an initial image storage volume containing the image file system, including: A Job controller for a container orchestration system is created. An initial Pod is created through the Job controller, and an initial storage volume based on a network block storage device is mounted in the initial Pod. A container image is pulled from an image repository, and the container image is expanded into an image file system on the initial storage volume to obtain an initial image storage volume containing the image file system.

10. The method of claim 9, wherein, Generating an image template snapshot based on the initial image storage volume includes: The execution status of the Job controller is periodically queried. If the Job controller executes successfully, an image template snapshot is generated based on the initial image storage volume. If the Job controller fails to execute or the polling times out, the process is terminated and the error is logged.

11. The method according to any one of claims 1-10, wherein, Generating an image template snapshot based on the initial image storage volume includes: Through the storage volume snapshot resource interface, a storage volume snapshot resource object is generated based on the initial image storage volume, and the storage volume snapshot resource object is used as an image template snapshot.

12. The method according to any one of claims 1-11, wherein, Also includes: Establish and maintain storage class mapping configuration files and snapshot class mapping configuration files. The storage class mapping configuration files are used to map user group identifiers to corresponding block storage class names, and the snapshot class mapping configuration files are used to map user group identifiers to corresponding storage volume snapshot class names. Mounting an initial storage volume based on a network block storage device within the initial Pod includes: Based on the user group identifier, obtain the corresponding block storage class name from the storage class mapping configuration file, and mount the initial storage volume of the network block storage device corresponding to the block storage class name in the initial Pod; Generating an image template snapshot based on the initial image storage volume includes: Based on the user group identifier, obtain the corresponding storage volume snapshot class name from the snapshot class mapping configuration file; Using the storage volume snapshot class corresponding to the storage volume snapshot class name, an image template snapshot is generated based on the initial image storage volume.

13. The method according to any one of claims 1-12, wherein, Before generating an image template snapshot based on the initial image storage volume, the process also includes: Check if an image template snapshot corresponding to the initial image storage volume already exists; If it already exists, then no image template snapshot will be generated based on the initial image storage volume; If it does not exist, an image template snapshot is generated based on the initial image storage volume.

14. A container image distribution apparatus for network block storage devices, deployed in a container orchestration system, adapted to perform the method as described in any one of claims 1-13, the apparatus comprising: The image preheating module is suitable for mounting an initial storage volume based on a network block storage device within an initial Pod, pulling a container image from an image repository, expanding the container image into an image file system on the initial storage volume, and obtaining an initial image storage volume containing the image file system, wherein the image file system contains all read-only layers of the container image. The snapshot generation module is adapted to generate an image template snapshot based on the initial image storage volume; The clone distribution module is adapted to clone multiple clone image storage volumes based on the image template snapshot on the network block storage device using a copy-on-write mechanism, and to mount the multiple clone image storage volumes into multiple new Pods respectively to obtain multiple user Pod instances, so as to enable the multiple user Pod instances to share all read-only layers of the container image stored on the container block storage device.

15. A computing device, comprising: At least one processor; and A memory storing program instructions, wherein the program instructions are configured to be processed by the at least one processor, the program instructions including instructions for processing the method as claimed in any one of claims 1-13.

16. A computer program product comprising computer program instructions, wherein, When the computer program instructions are executed by the processor, they implement the method as described in any one of claims 1-13.

17. A readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-13.

Images