A method for associating development and application container images based on OCI specifications

Abstract

A method for associating development state and application state container images based on the OCI specification, including obtaining a list of containers in a Pod, pulling container images from a container image repository in a running state of the container; traversing the local container images of the node, unpacking the container images, and obtaining container image information corresponding to all nodes, including Image ID and Image Digest; performing corresponding association between the development state and the running state of the container image according to the container image information Image ID and Image Digest, and performing corresponding storage in the lists respectively. The present invention uses Image ID to identify the same container image, and reasonably handles the relationship between Image ID and Digest, thereby ensuring the accuracy and consistency of container image information between different container image repositories; by designing a table structure, effective association between development state and running state container images is achieved, facilitating the management and traceability of container images.

Description

Technical Field

[0001] The present invention relates to the technical field of container images, and more specifically, to a method for associating development-state and application-state container images based on the OCI specification. Background Art

[0002] In a cloud-native environment, applications go through different forms from development to operation, including code, products (such as container images, Helmchart), Pods (containers), processes, etc. Container images are key information that associates the development and operation states of applications and are crucial to the deployment and management of applications.

[0003] At present, the container image standard is mainly defined by OCI (OpenContainer Initiative), which includes three specifications: runtime-spec, image-spec, and distribution-spec. Among them, image-spec strictly defines the requirements of the container image format, including manifests (Manifest), configurations (ConfigJSON), a set of file system layers (Layers), and optional container image indexes (Indexormanifestlist).

[0004] However, in actual applications, there are the following problems: multiple container images contained in an application may be stored in different container image repositories, making it difficult to find a stable, immutable feature to associate development and running container images. For the same container image, there may be differences between the ImageID and Digest in different container image repositories, making the management and identification of container images complicated.

[0005] In the existing technology, there are some uncertainties in the behavior of container images in Kubernetes. For example, the parsing result of ContainerStatus.ImageID may be different under different container image pulling strategies and CRI (ContainerRuntimeInterface), which brings troubles to the use and management of container images.

[0006] Therefore, the problems existing in the prior art need to be further improved and developed. Summary of the invention

[0007] (I) Purpose of the invention: To solve the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide a method for associating development-state and application-state container images based on the OCI specification.

[0008] (II) Technical solution: In order to solve the above technical problems, this technical solution provides a method for associating development-state and application-state container images based on the OCI specification, which specifically includes:

[0009] Step 1: Get the list of containers in the Pod and pull the container image from the container image repository in the running state of the container;

[0010] Step 2: Traverse the local container images of the nodes, unpack the container images, and obtain the container image information corresponding to all nodes, including Image ID and Image Digest;

[0011] Step 3: According to the container image information Image ID and Image Digest, the development state and running state of the container image are associated with each other, and the lists are stored accordingly.

[0012] Preferably, the running container image information data is obtained from the local container image and ContainerStatus.ImageID; the ContainerStatus.ImageID is an ID used to represent the container image in Kubernetes, which is Image Digest or ConfigJSON Digest.

[0013] Preferably, the SHA256 hash value of the ConfigJSON is the Image ID.

[0014] Preferably, when the pull policy of the container image is Always, .status.containerStatuses[].imageID can always be parsed into a consistent Image Digest; when the container image repository is multi-architecture, different architecture nodes parse the Manifest Digest of the container image of the specified architecture system; when the container image repository is the same architecture, the container image of the architecture system is parsed into Image Digests;

[0015] When the container image pull strategy is IfNotPresent, if the Kubernetes node does not have the container image specified by PodSpec.Containers.Image, ContainerStatus.ImageID is resolved into ImageDigest. When the container image repository is multi-architecture, the Manifest Digest of the specified architecture container image resolved by different architecture nodes; when the container image repository is the same architecture, the architecture container image is resolved into ImageDigest; when the node has a container image and the container image is a manually imported container image extracted from the container image repository, it is resolved into ImageDigest; when the node has a container image and the container image is generated by local packaging, it is resolved into ImageID.

[0016] Preferably, the local container image of the node is traversed, and the container image is unpacked through .status.containerStatuses[].imageID to obtain the container information of all nodes and the corresponding container image information;

[0017] Preferably, the container information includes pod_id, name, and image; the container image information also includes container image name and tags.

[0018] Preferably, the Image Digest is an encrypted hash value of the container image content, usually a SHA256 hash; the Image Digest is a complete fingerprint of the container image content, ensuring the immutability and consistency of the container image; the Image Digest is calculated based on the container image layer and the configuration file, so as long as the container image content is the same, the Image Digest will remain unchanged;

[0019] The Image ID is a unique identifier for a container image and is a hash value of the container image content, but not necessarily a complete fingerprint of the content. In the same container image repository, the Image ID is unique and points to a specific container image. If the content of a container image changes, a new Image ID is generated.

[0020] Preferably, Image Digest is a stabilizing factor used to confirm the uniqueness of the container image. Different Image IDs contain the same set of Image Digests, which serve as an immutable feature for associating applications in development and running states.

[0021] Preferably, there is a one-to-one relationship between the container and the Image ID and / or Image Digest. The container information and the Image ID and / or Image Digest fields are correspondingly associated and stored as the kube_pod_containers table, which is used to determine the container image information of the current container running;

[0022] The relationship between Image ID and Image Digest is one-to-many. Image ID is consistent across multiple architectures and is stored separately as the kube_images table.

[0023] Image Digest is inconsistent for the same container image in multiple system architectures. It is stored separately as a kube_image_digests table to associate the digest with the Image ID.

[0024] Preferably, when the application queries for container association, it first obtains the digest information of the container image and queries the Image ID corresponding to the specified digest in the kube_image_digest table, and queries the detailed information of the specified container image in the kube_images table through the Image ID to obtain the precise container image used by the container, and completes the application association of the container image in the development state and the running state.

[0025] (III) Beneficial effects: The present invention provides a method for associating development-state and application-state container images based on the OCI specification. First, the same container image is identified by using the Image ID, and the relationship between the Image ID and the Digest is properly handled, thereby ensuring the accuracy and consistency of the container image information between different container image repositories, and avoiding management confusion caused by inconsistent container image information. Secondly, the behavior of container images in Kubernetes is clarified, especially the parsing result of ContainerStatus.ImageID, so that under different container image pulling strategies and CRIs, the use and management methods of container images can be accurately predicted, thereby improving the deployment and operation efficiency of applications. Finally, by designing a reasonable table structure, the effective association between the development-state and running-state container images is achieved, so that the Image ID can be accurately found from the running-state ContainerStatus.ImageID, and then associated with the development-state container image, which facilitates the management and traceability of container images. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a flowchart of the steps of a method for associating development state and application state container images based on the OCI specification of the present invention;

[0027] Figure 2 This is a summary of the ContainerStatus.ImageID field;

[0028] Figure 3 (a) shows the life cycle process of an application in the development state;

[0029] Figure 3 (b) shows the life cycle of an application in the running state. DETAILED DESCRIPTION

[0030] The present invention is further described in detail below in conjunction with preferred embodiments. More details are elaborated in the following description to facilitate a full understanding of the present invention. However, the present invention can obviously be implemented in a variety of other ways different from the description. Those skilled in the art can make similar generalizations and deductions based on actual application situations without violating the connotation of the present invention. Therefore, the protection scope of the present invention should not be limited by the content of this specific embodiment.

[0031] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that the drawings are only examples and are not drawn to scale, and should not be used to limit the actual protection scope of the present invention.

[0032] A method for associating development-state and application-state container images based on the OCI specification, such as Figure 1 As shown, the specific steps include:

[0033] Step 1. Get the list of containers in the Pod and pull the container image from the container image repository in the running state of the container.

[0034] Step 2: Traverse the local container images of the nodes, unpack the container images, and obtain the container image information corresponding to all nodes.

[0035] Step 3: Correlate the development state and running state of the container image based on the container image information.

[0036] The Pod is a basic unit in Kubernetes (K8s), representing a group of one or more containers running on the same node. The containers in the Pod share network and storage resources, and include not only the application itself, but also the entire environment required for the application to run. Kubernetes is an open source container orchestration platform for automated container deployment, expansion, and management.

[0037] The container is a virtualization technology based on operating system capabilities (namespace and cgroups), and is essentially a process running in a resource-constrained and isolated environment. The container is an application that packages runtime dependencies and configurations together; specifically, a container is a standard software unit whose goal is to encapsulate software and its dependencies in a self-describing and portable format so that any compatible runtime can run it, regardless of the underlying runtime environment and container contents.

[0038] As shown in Figure 3 (a) and Figure 3 (b), it is an entire life cycle process of an application from development state to running state, and emphasizes the container image as its key associated feature. Figure 3 (a) shows the entire process of development state, while Figure 3 (b) shows the entire process of running state.

[0039] The development state includes: 1. Code submission: The developer pushes the code to the Git repository in the code management system (CSM). 2. Static code analysis: The code is subjected to static code analysis after submission to ensure code quality and compliance. 3. CI / CD process: The CI runner executes CI tasks, builds and pushes container images to the container image repository, such as JFrog; these container images comply with the OCI (Open Container Initiative) specification. 4. Container image synchronization: The container image is synchronized between different container image repositories to ensure that it is available in the running environment.

[0040] The running state includes: 5. Application deployment: The operation and maintenance personnel deploy the application to the Kubernetes cluster through CI / CD tools such as Jenkins. 6. Kubernetes API call: The operation and maintenance personnel interact with kubelet through Kubernetes ControlPlane. 7. Pod creation: First, kubelet creates a Pod through CRI (Container RuntimeInterface) gRPC call; secondly, the container running state pulls the container image from the container image repository and unpacks the container image into a container package; finally, runc creates a container according to the OCI running state specification. Finally, the container runs in the Pod, including the application process.

[0041] The OCI (Open Container Initiative) is an open source project that aims to develop and maintain open standards for container runtimes and images. The OCI specifications include runtime-spec (container runtime specification), image-spec (image specification) and distribution-spec (distribution specification), ensuring the interoperability and consistency of container images and runtimes.

[0042] The sources of running container image information include: container image repository, local container image, and ContainerStatus.ImageID. For container image repository, in theory, the application does not obtain any information from the running container image repository, so it only needs to obtain the running container image information data from the local container image and ContainerStatus.ImageID.

[0043] like Figure 2 As shown, the ContainerStatus.ImageID refers to the ID used to represent the container image in Kubernetes, which may be Image Digest or ConfigJSON Digest, depending on the container image pulling strategy and the implementation of the Container Runtime Interface (CRI).

[0044] The ConfigJSON refers to a container image configuration file, which includes metadata of the container image, such as environment variables, commands, etc. The SHA256 hash value of the ConfigJSON is the Image ID.

[0045] Regarding the definition of Pod, there are three types of container images related to containers, namely:

[0046] 1. .spec.containers[].image: Defined in the specification (spec) section of the Pod and can be modified by a third-party admission controller. Used to specify the container image that should be used when the container is started. When creating a Pod, this field tells Kubernetes where to get the container image to start the container. This is an expected configuration and is the container image version that the user wants the container to run. It is a key part of the Pod configuration and is used to initialize the container image source for the container. This configuration is static and will not change unless the Pod definition is updated, and the value of this field determines the container image to be pulled and run when the container is first started.

[0047] 2. .status.containerStatuses[].image: Located in the status section of the Pod, it is usually the same as the Image defined in PodSpec.Containers. The container image name of the Docker Hub will be normed. It reflects the container image currently being used by the container. When the container is started, this field will display the actual running container image. It is mainly used to view the container image actually used by the container in the running state.

[0048] 3. .status.containerStatuses[].imageID: Also defined in the status part of the Pod, it will be parsed into different forms of IDs by kubelet, which are related to the pull strategy and CRI. It provides a unique identifier for the container image. This identifier is usually a hash value of the container image or a similar unique identifier. For example, in Docker, the container image ID is a sha256 hash string that can accurately identify a specific container image version. This field is used to more accurately track the container image used by the container. It is very useful when you need to accurately distinguish different versions of container images, which helps to perform more sophisticated container image management and troubleshooting in the container image repository or container runtime environment. The source and history of the container image can be traced through this unique ID.

[0049] In summary: .spec.containers[].image is the user-defined expected container image as a static configuration. .status.containerStatuses[].image is the container image ID information used when the container image is started, and it will not be updated after the container image is updated. .status.containerStatuses[].imageID is the container image ID information used in the running state, which provides a more accurate container image location information ID.

[0050] Therefore, when the pull policy of the container image is Always, .status.containerStatuses[].imageID can always be resolved into a consistent Image Digest. It depends on whether the repository is a multi-architecture container image. When the container image repository is multi-architecture, different architecture nodes resolve the ManifestDigest of the container image of the specified architecture system; when the container image repository is the same architecture, the architecture system container image is resolved into Image Digests.

[0051] When the container image pull strategy is IfNotPresent, the situation is a bit complicated. If the k8s node does not have the container image specified by PodSpec.Containers.Image, it will try to pull it from the container image warehouse. ContainerStatus.ImageID is resolved into Image Digest, depending on whether the warehouse is a multi-architecture container image. When the container image warehouse is multi-architecture, the ManifestDigest of the specified architecture container image is resolved by different architecture nodes; when the container image warehouse is the same architecture, the architecture container image is resolved into Image Digest. When the node has a container image and the container image is a container image extracted from the manually imported container image warehouse, it is resolved into ImageDigest; when the node has a container image and the container image is generated by local packaging, it is resolved into ImageID.

[0052] Traverse the local container images of the nodes, unpack the container images through .status.containerStatuses[].imageID, and obtain the container information of all nodes and the corresponding container image information.

[0053] The container information includes pod_id, name, image, etc. The container image information includes Image ID, Image Digest, container image name, tags, etc.

[0054] The Image Digest is an encrypted hash of the container image content, usually a SHA256 hash. The Image Digest is a complete fingerprint of the container image content, ensuring the immutability and consistency of the container image. The Image Digest is calculated based on the container image layers and configuration files, so as long as the container image content is the same, the Image Digest will remain unchanged. The Image Digest ensures that the pulled container image matches the expected content.

[0055] The Image ID is a unique identifier for a container image, usually a hash value of the container image content, but it is not necessarily a complete fingerprint of the content. The Image ID is usually generated during the container image build process and remains unchanged during the life cycle of the container image. In the same container image repository, the Image ID is unique and points to a specific container image. If the content of the container image changes, a new Image ID is generated.

[0056] The tags are custom, human-readable manifest identifiers.

[0057] Image IDs may be different in different container image repositories, even for container images with the same content. This is because different build tools or repositories may generate different Image IDs. The labels of container images are also mutable, and different repositories may adopt different naming conventions and version management strategies. Image Digest is immutable, and the Image Digest is consistent for container images with the same content. This means that if two different repositories store the same container image content, the Image Digest of the same container image content stored in these two repositories is the same. The content of the container image itself is immutable, and any changes to the container image will result in a new container image and a new Image ID and Image Digest.

[0058] Therefore, Image Digest is a stabilizing factor that can be used to confirm the uniqueness of a container image. Different Image IDs can contain the same set of Image Digests, which can be used as an immutable feature to associate applications in development and running states.

[0059] More specifically, the step 3 specifically includes:

[0060] The container information is associated with the container image information, and the lists are stored accordingly.

[0061] There is a one-to-one relationship between the container and the Image ID and / or Image Digest. As shown in Table 1, the container information and the Image ID and / or Image Digest fields are associated with each other and stored as a kube_pod_containers table to determine the container image information of the current container.

[0062] Table 1 kube_pod_containers

[0063]

[0064] The relationship between Image ID and Image Digest is one-to-many. Image ID is consistent for multiple architectures and is stored separately as a kube_images table, as shown in Table 2.

[0065] Table 2: kube_images

[0066]

[0067] Image Digest is inconsistent for the same container image in multiple system architectures, and is stored separately as a kube_image_digests table, as shown in Table 3, which associates digest with Image ID. The kube_image_digests table is independent of the node, and the cluster_id and digest fields need to establish unique constraints (theoretically, digest can be globally unique).

[0068] The cluster_id is the ID of the Kubernetes cluster, which is used to mark the relationship between Pod and Cluster under multiple clusters, facilitating the unified management of multiple clusters by the system. The Pod_id is a database foreign key association field.

[0069] Table 3: kube_image_digests

[0070]

[0071] When the application queries the container association, it first obtains the digest information of the container image and queries the Image ID corresponding to the specified digest in the kube_image_digest table. Then, it queries the detailed information of the specified container image in the kube_images table through the Image ID to obtain the precise container image used by the container, thereby completing the application association of the container image in the development state and the running state.

[0072] The present invention is a method for associating development-state and application-state container images based on the OCI specification. First, by using Image ID to identify the same container image, and reasonably handling the relationship between Image ID and Digest, the accuracy and consistency of container image information between different container image repositories are ensured, and management confusion caused by inconsistent container image information is avoided. Secondly, the behavior of container images in Kubernetes is clarified, especially the parsing result of ContainerStatus.ImageID, so that under different container image pull strategies and CRI, the use and management methods of container images can be accurately predicted, and the deployment and operation efficiency of applications are improved. Finally, by designing a reasonable table structure, the effective association of development-state and running-state container images is achieved, so that the ImageID can be accurately found from the running-state ContainerStatus.ImageID, and then associated with the development-state container image, which facilitates the management and tracing of container images.

[0073] The above content is an explanation of the preferred embodiments of the present invention, which can help those skilled in the art to more fully understand the technical solution of the present invention. However, these embodiments are merely illustrative, and it cannot be determined that the specific implementation methods of the present invention are limited to the description of these embodiments. For ordinary technicians in the technical field to which the present invention belongs, without departing from the concept of the present invention, several simple deductions and transformations can be made, which should be regarded as belonging to the protection scope of the present invention.

Claims

1. A method for associating development state and application state container images based on the OCI specification, characterized in that: Specifically include: Step 1: Get the list of containers in the Pod and pull the container image from the container image repository in the container application state. Step 2: traverse the local container image of the node, unpack the container image, and obtain the container image information corresponding to all nodes, including the container image ID and the container image summary information; when the pull policy of the container image is Always, when the container image repository is multi-architecture, different architecture nodes parse the container image list summary information of the specified architecture system container image as the container image ID; when the container image repository is the same architecture, the architecture node parses the container image summary information of the architecture system container image as the container image ID; When the container image pull strategy is If Not Present, if the Kubernetes node does not have the container image specified in the Pod definition, i.e., PodSpec.Containers.Image, and when the container image repository is multi-architecture, different architecture nodes parse the container image manifest summary information of the specified architecture container image as the container image ID; when the container image repository is the same architecture, the architecture node parses the container image summary information of the architecture system container image as the container image ID; when the node has a container image and the container image is manually imported and extracted from the container image repository, the container image summary information is parsed as the container image ID; when the node has a container image and the container image is generated by local packaging, the container image ID is parsed as the container image ID; Step 3: According to the container image information, container image ID and container image summary information, the container image development state and application state are correspondingly associated, and the lists are stored respectively; the container and the container image ID and / or container image summary information are one-to-one, and the container information and the container image ID and / or container image summary information are correspondingly associated and stored as the kube_pod_containers table; The container image ID and the container image summary information are in a one-to-many relationship. The container image ID is consistent for multiple architectures and is stored separately as the kube_images table. The container image summary information is inconsistent for the same container image in multiple system architectures. It is stored separately as the kube_image_digests table to associate the container image summary information with the container image ID. When the application queries the container association, it first obtains the container image summary information of the container image, queries the container image ID corresponding to the specified container image summary information in the kube_image_digest table, and queries the detailed information of the specified container image in the kube_images table through the container image ID to complete the application association of the container image in the development state and the application state.

2. According to a method for associating development state and application state container images based on OCI specification according to claim 1, it is characterized in that: The container image information data of the application state is obtained from the local container image and the container image ID of the application state container state, namely ContainerStatus.ImageID; the container image ID of the application state container state is an ID used to represent the container image in Kubernetes, which is the summary information of the container image or the summary information of the container image configuration file ConfigJSON.

3. According to a method for associating development state and application state container images based on OCI specification according to claim 2, it is characterized in that: The SHA256 hash value of the container image configuration file ConfigJSON is the container image ID.

4. According to a method for associating development state and application state container images based on OCI specification according to claim 1, it is characterized in that: Traverse the local container images of the node, unpack the container images through the container image ID of each container in the application state container status set, that is, .status.containerStatuses[].imageID, and obtain the container information of all nodes and the corresponding container image information.

5. According to a method for associating development state and application state container images based on OCI specification according to claim 4, it is characterized in that: The container information includes pod_id, container name, and container image; the container image information also includes container image name and manifest identifier.

6. According to a method for associating development state and application state container images based on OCI specification according to claim 1, it is characterized in that: The container image summary information is an encrypted hash value of the container image content; the container image summary information is calculated based on the container image layer and the configuration file, so as long as the container image content is the same, the container image summary information will remain unchanged; The container image ID is a unique identifier of the container image. In the same container image repository, the container image ID is unique and points to a specific container image. If the content of the container image changes, a new container image ID will be generated.

7. According to the method for associating development state and application state container images based on the OCI specification of claim 6, it is characterized in that: Different container image IDs contain the same set of container image summary information, which is used as an immutable feature to associate applications in development and application states.

Images