A method for accelerating container startup based on cloud disk image cache

Abstract

This invention relates to the field of Kubernetes cloud platform technology, and in particular to a method for accelerating container startup by creating image caches based on cloud disks. The method includes: managing image caches using Kubernetes CustomResource and Operator modes; and creating and using image caches by utilizing cloud disk functions and cloud disk snapshot functions.

Description

Technical Field

[0001] This invention relates to the field of Kubernetes cloud platform technology, and in particular to a method for accelerating container startup by creating an image cache based on a cloud disk. Background Technology

[0002] Since the birth of container technology, image technology has greatly facilitated developers in creating and delivering cloud-native applications, allowing developers to package application files and components into lightweight software packages and publish them to image repositories for reuse. Image repositories are responsible for storing and distributing image files.

[0003] OCI Image Format, an open container image format standard, includes files such as manifest, config, index, and zip archive. These files work together to build the necessary files for the container's root directory. The process of creating an image and using it in a container is a forward and reverse operation; creating an image involves compressing and uploading files to a repository, while using an image involves downloading, parsing, and decompressing it.

[0004] containerd is a container runtime that provides OCI Image operation capabilities. It creates images according to the OCI standard and uses images to start containers. It provides the Container Runtime Interface (CRI) plugin. Kubernetes uses gRPC to call CRI to operate containers, including starting and destroying containers.

[0005] containerd snapshot, a plugin in containerd, is used to manage snapshots of container images on the file system, providing container with rootfs creation, mounting, and unmounting capabilities.

[0006] Container startup involves the following stages: 1. Pulling the image file from the image repository; 2. Parsing the image file and decompressing the image file archive; 3. Creating the container startup directory based on the image file; 4. Preparing the network environment... and starting the container. Pulling the image from the remote repository and decompressing the file depends on network connectivity and consumes a significant amount of time and CPU resources.

[0007] With the widespread adoption and development of the Kubernetes platform, serverless technology, which eliminates the need for developer management, is rapidly evolving. Based on the serverless cloud-native development model, developers can quickly build, deploy, and run applications. Compared to deploying hosts, creating a Kubernetes cluster, and then deploying Pods, serverless deployment allows developers to focus solely on the release and operation of business instances, enabling rapid scaling of cluster instances, elastic capacity expansion, and full utilization of Kubernetes orchestration capabilities. However, image pulling and preparation still consume significant time, reducing orchestration efficiency. Containerd has proposed solutions such as Stargz Snapshotter, but these require modification of image formats, introduction of new components, and increased system complexity and operational costs.

[0008] Cloud disks from cloud vendors are highly available, highly reliable, low-cost, and customizable block storage devices. They can be used as independent expansion disks for servers. Summary of the Invention

[0009] This patent proposes a method for accelerating container startup by creating an image cache based on cloud disks. For applications deployed on Serverless, the time spent pulling and parsing images to prepare the container's root filesystem is particularly significant. Furthermore, for instance scaling, pulling images, decompressing them, and preparing the container startup root directory are repetitive tasks; compressing or reducing these repetitive tasks can significantly reduce container instance startup time. Simultaneously, mounting Ceph-based distributed storage within the cluster enables low-latency access. Compared to accessing external network remote repositories, accessing internal network distributed storage takes negligible time, achieving high-speed file reading. When deploying applications on a Serverless platform, developers encounter the following problems: 1. Long waiting times when starting containers, pulling images, and preparing container images fail to meet the fast startup and elastic scaling characteristics of Serverless compared to ordinary Kubernetes clusters; 2. Inability to quickly add container instances to cope with traffic surges.

[0010] This patent attempts to use block storage snapshot capabilities to save a snapshot of the container's root directory. When starting the container, a cloud disk snapshot is used to generate a disk instance, which is then mounted to a local directory. The mounted disk is used to create the container's startup directory, reducing the time spent pulling and decompressing image files from a remote image repository, thus achieving container startup in seconds and elastic scaling.

[0011] The technical solution of the present invention is as follows:

[0012] A method for accelerating container startup by creating an image cache based on cloud disks, the method includes the following steps:

[0013] S1. Use Kubernetes CustomResource and Operator patterns for image cache management;

[0014] S2. Use cloud disk and cloud disk snapshot functions to create and use image cache.

[0015] A further improvement of the present invention is that the image cache management in S1 includes the following specific steps:

[0016] S11. Create the Kubernetes ImageCache CustomResourceDefinition configuration file and load it into the Kubernetes cluster;

[0017] S12. When creating a Pod, query the ImageCache list and compare it with the Pod image. If the image name and version are the same, the image cache is matched and the ImageCache status is updated. Otherwise, if they do not match, a new image cache ImageCache is created.

[0018] S13. Delete the image cache. Use the Kubernetes kubectl delete command to delete CustomResource and delete the cloud disk snapshot.

[0019] S14. Delete expired image cache. Start a CronJob container independently in the Kubernetes cluster, compare the CreateTime + retentionDays of ImageCache with the current time, and if they are greater than the current time, update the status to delete and perform the deletion operation.

[0020] A further improvement of the present invention is that, in S1, CustomResource defines the necessary attributes of the image cache, specifically including the image cache ID, image name, and required disk capacity.

[0021] A further improvement of the present invention is that the Operator in S1 is responsible for managing the lifecycle of CustomResource and performing different tasks in different states.

[0022] A further improvement of the present invention is that the image cache creation in S2 includes the following specific steps:

[0023] S21. When creating a new Pod, mark the container with Pod Annotation to create a new image cache or use the image cache operation;

[0024] S22. Create a new image cache. Create a new ImageCache CustomResource. After receiving the CustomResource event, ImageCacheOperator will start the construction of the image cache.

[0025] A further improvement of the present invention is that the specific content of the operation of marking the container with Pod Annotation to create a new image cache or use the image cache in S21 is as follows: if the image cache is hit, an Annotation is added with the key example.com / matched-image-cache and the value image cache ID; when creating a new image cache, an Annotation is added with the key example.com / imc-id and the value image cache ID.

[0026] A further improvement of the present invention is that step S22 includes the following specific steps:

[0027] S221. Generate a new cloud disk instance and mount it to the host image cache directory ` / data / imc-xxx` where the Pod is located;

[0028] S222. After the Pod container starts, query the container snapshot information, copy the snapshot subdirectory to ` / data / imc-xxx / snapshots`, and copy the snapshot component metadata.db file to the image cache directory;

[0029] S223. Use the `ctr image export` command to export the image archive to the ` / data / imc-xxx` directory;

[0030] S224. Use the ` / data / imc-xxx` directory file to generate a cloud disk snapshot.

[0031] A further improvement of the present invention is that the specific content used in the image cache in S2 is as follows: the ImageCache CustomResource LastMatched field is updated to PodName, and after the ImageCache Operator receives the update event, it starts construction to prepare the image cache for the container.

[0032] A further improvement of the present invention is that the use of the image cache in S2 includes the following specific steps:

[0033] S225. Query the cloud disk snapshot by image cache ID and generate a cloud disk instance from the cloud disk snapshot;

[0034] S225. Mount the cloud disk instance to the host directory where the Pod is located, ` / data / imc-xxx`;

[0035] S226. Use the `ctr image import` command to import the image. Use ` / data / imc-xxx` as the mount information for the container's rootfs directory.

[0036] A further improvement of the present invention is that, when the image cache is used in S2, a cloud disk instance is generated from the image cache cloud disk snapshot and mounted on the host where the Node is located, and containerd uses the cloud disk instance file to create the container rootfs.

[0037] The technical effects of this invention are as follows:

[0038] This paper proposes a method to accelerate container startup by creating an image cache based on cloud disks. Compared with the native image parsing method of container and the lazy loading of image layers by containerd Stargz Snapshotter, this method enables the reuse of image snapshot layers, avoids time-consuming operations such as pulling and parsing images, and achieves container startup in seconds. It also implements ImageCache Operator to manage CustomResources without intruding into Kubernetes and leverages Kubernetes extension capabilities for development. The image cache is accessed based on the internal network, which avoids the impact of external network connectivity quality. The container rootfs read-only layer is accessed remotely, which breaks through the local disk access density limit. Attached Figure Description

[0039] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0040] Figure 1 This is a flowchart illustrating a method for accelerating container startup based on cloud disk image caching, according to an embodiment of the present invention.

[0041] Figure 2 This is a diagram illustrating the image cache creation architecture of a method for accelerating container startup based on cloud disk image cache according to an embodiment of the present invention.

[0042] Figure 3 This is a diagram illustrating the image cache architecture of a method for accelerating container startup based on cloud disk image cache according to an embodiment of the present invention.

[0043] Figure 4 This is a flowchart illustrating a method for accelerating container startup based on cloud disk image caching, according to an embodiment of the present invention.

[0044] Figure 5This is a diagram illustrating the state transition process of the image cache CustomResource, which is a method for accelerating container startup based on cloud disk image cache according to an embodiment of the present invention. Detailed Implementation

[0045] Example

[0046] This embodiment proposes a method for accelerating container startup by creating an image cache based on cloud disks. By comparing the native image parsing method of container and the lazy loading method of containerd Stargz Snapshotter, it realizes the reuse of image snapshot layers, avoids time-consuming operations such as pulling and parsing images, and achieves container startup in seconds. It enables ImageCache Operator to manage CustomResources without intruding into Kubernetes and utilizes Kubernetes extension capabilities for development. The image cache is accessed based on the internal network, which avoids the impact of external network connectivity quality. The container rootfs read-only layer is accessed remotely, breaking through the local disk access density limit.

[0047] Specifically, such as Figure 1 As shown in the figure, this embodiment proposes a method for accelerating container startup by creating an image cache based on a cloud disk, which includes the following specific steps:

[0048] S1. Use Kubernetes CustomResource and Operator patterns for image cache management;

[0049] S2. Use cloud disk and cloud disk snapshot functions to create and use image cache.

[0050] In this embodiment, the image cache management in S1 includes the following specific steps: Prepare 5 hosts with 16GB of memory and 8-core CPUs, and deploy a highly available Kubernetes cluster (3 Master nodes); deploy the container runtime containerd on each node; create a Kubernetes ImageCache CustomResourceDefinition configuration file and load it into the Kubernetes cluster; create an available Ceph cluster to provide the same block storage functionality as a cloud disk; when creating a Pod, query the ImageCache list and compare it with the Pod image. If the image name and version are the same, the image cache is matched, and the ImageCache status is updated; otherwise, if they do not match, a new image cache ImageCache is created; delete the image cache by using the Kubernetes kubectl delete command to delete the CustomResource and delete the cloud disk snapshot; delete expired image cache by starting a CronJob container independently within the Kubernetes cluster, comparing whether the ImageCache's CreateTime + retentionDays is greater than the current time, and if so, updating it to a deleted status and performing the deletion operation.

[0051] In this embodiment, in S1, CustomResource defines the necessary attributes for the image cache, including the image cache ID, image name, and required disk capacity.

[0052] In this embodiment, the Operator in S1 is responsible for managing the lifecycle of CustomResource and performing different tasks in different states.

[0053] In this embodiment, the image cache creation in S2 includes the following specific steps: when creating a new Pod, the container is marked with PodAnnotation to create a new image cache or use an image cache operation; a new image cache is created by creating a new ImageCache CustomResource, and the ImageCache Operator starts creating the image cache after receiving the CustomResource event.

[0054] In this embodiment, the specific content of marking the container with Pod Annotation to create a new image cache or use the image cache is as follows: if the image cache is hit, an Annotation is added with the key example.com / matched-image-cache and the value image cache ID; when creating a new image cache, an Annotation is added with the key example.com / imc-id and the value image cache ID.

[0055] In this embodiment, the specific implementation of creating a new image cache is as follows: A new cloud disk instance is generated and mounted to the image cache directory ` / data / imc-xxx` on the host where the Pod resides; after the Pod container starts, the container snapshot information is queried, the snapshot subdirectory is copied to ` / data / imc-xxx / snapshots`, and the snapshot component metadata.db file is copied to the image cache directory; the image compressed package is exported to the ` / data / imc-xxx` directory using the `ctr image export` command; and a cloud disk snapshot is generated using the files in the ` / data / imc-xxx` directory.

[0056] In this embodiment, the specific content used in S2 for image caching is as follows: the ImageCacheCustomResource LastMatched field is updated to PodName. After receiving the update event, the ImageCache Operator starts construction to prepare image caching for the container. When the image caching is used, a cloud disk instance is generated from the image cache cloud disk snapshot and mounted on the host where the Node is located. containerd uses the cloud disk instance file to create the container rootfs.

[0057] In this embodiment, the image cache usage in S2 includes the following specific steps: querying the cloud disk snapshot using the image cache ID, generating a cloud disk instance from the cloud disk snapshot; mounting the cloud disk instance to the host directory ` / data / imc-xxx` where the Pod is located; importing the image using the `ctr image import` command, with the container rootfs directory using ` / data / imc-xxx` as the mount information.

Claims

1. A method for accelerating container startup by creating an image cache based on cloud disks, characterized in that: The specific steps include the following: S1. Utilize Kubernetes CustomResource and Operator patterns for image cache management; S2. Use cloud disk functionality and cloud disk snapshot functionality to create and use image cache; The image cache management in S1 includes the following specific steps: S11. Create the Kubernetes ImageCache CustomResourceDefinition configuration file and load it into the Kubernetes cluster; S12. When creating a Pod, query the ImageCache list and compare it with the Pod image. If the image name and version are the same, the image cache is matched and the ImageCache status is updated. Otherwise, if they do not match, a new image cache ImageCache is created. S13. Delete the image cache. Use the Kubernetes kubectl delete command to delete CustomResource and delete the cloud disk snapshot. S14. Delete expired image cache. Start a CronJob container independently in the Kubernetes cluster, compare whether the ImageCache's CreateTime + retentionDays is greater than the current time, and if so, update it to the deleted status and perform the deletion operation. The creation of the image cache in S2 includes the following specific steps: S21. When creating a new Pod, mark the container with Pod Annotation to create a new image cache or use the image cache operation; S22. Create a new image cache. Create a new ImageCache CustomResource. After receiving the CustomResource event, the ImageCache Operator will start the construction of the image cache.

2. The method for accelerating container startup based on cloud disk image caching according to claim 1, characterized in that: In S1, CustomResource defines the necessary attributes for the image cache, including the image cache ID, image name, and required disk capacity.

3. The method for accelerating container startup based on cloud disk image caching according to claim 1, characterized in that: In S1, the Operator is responsible for managing the lifecycle of CustomResource and performing different tasks in different states.

4. The method for accelerating container startup based on cloud disk image caching according to claim 1, characterized in that: The specific content of S21, which marks the container with Pod Annotation to create a new image cache or use an image cache, is as follows: If the image cache is hit, an Annotation is added with the key example.com / matched-image-cache and the value image cache ID. When creating a new image cache, an Annotation is added with the key example.com / imc-id and the value image cache ID.

5. The method for accelerating container startup based on cloud disk image caching according to claim 4, characterized in that: S22 includes the following specific steps: S221. Generate a new cloud disk instance and mount it to the host image cache directory ` / data / imc-xxx` where the Pod is located; S222. After the Pod container starts, query the container snapshot information, copy the snapshot subdirectory to ` / data / imc-xxx / snapshots`, and copy the snapshot component metadata.db file to the image cache directory; S223. Use the `ctr image export` command to export the image archive to the ` / data / imc-xxx` directory; S224. Use the ` / data / imc-xxx` directory file to generate a cloud disk snapshot.

6. The method for accelerating container startup based on cloud disk image caching according to claim 5, characterized in that: The specific content used in the image cache in S2 is as follows: update the ImageCache CustomResource LastMatched field to PodName, and after receiving the update event, the ImageCache Operator starts construction to prepare the image cache for the container.

7. The method for accelerating container startup based on cloud disk image caching according to claim 6, characterized in that: The use of the image cache in S2 includes the following specific steps: S225. Query the cloud disk snapshot by image cache ID and generate a cloud disk instance from the cloud disk snapshot; S225. Mount the cloud disk instance to the host directory where the Pod is located, ` / data / imc-xxx`; S226. Use the `ctr image import` command to import the image. Use ` / data / imc-xxx` as the mount information for the container's rootfs directory.

8. The method for accelerating container startup based on cloud disk image caching according to claim 7, characterized in that: When the image cache in S2 is used, a cloud disk instance is generated from the image cache cloud disk snapshot and mounted on the host where the Node is located. containerd uses the cloud disk instance file to create the container rootfs.

Images