An image building method of a containerd container-based kubernetes cluster

Abstract

This invention provides a method for building images for a Kubernetes cluster based on containerd containers, comprising the following steps: obtaining a base image by inheriting image information from the podman container; building application images for at least one programming language based on the base image; preparing a first configuration file for podman, the first configuration file including several image repositories and the storage location of each image repository; preparing a second configuration file for at least one programming language, the second configuration file including the configuration environment on which at least one programming language depends; mounting the directories specified by the first configuration file and the second configuration file to the host directory or distributed shared storage; writing an operation and maintenance feature configuration file for the application, the operation and maintenance feature configuration file including setting the basic operation and maintenance features of the application; and performing CI and CD processes for the application in the application deployment pipeline to achieve deployment in the Kubernetes cluster.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for building images of a Kubernetes cluster based on containerd containers. Background Technology

[0002] Because the Docker container engine was released earlier than the Kubernetes container engine, Docker itself is incompatible with the CRI (Container Runtime Interface), and the Docker team has no plans to implement CRI. Furthermore, Docker does not support some new container requirements, and the community wanted to move away from the high maintenance costs of Dockershim. Therefore, Kubernetes version 1.20 was released, and one important change was the declaration that support for Docker was deprecated and would be removed in the subsequent version 1.24. Consequently, the existing method of building images based on Docker will no longer work after replacing containerd, because containerd lacks the `build` command, making it impossible to directly build images in a Kubernetes environment. Tools such as Buildkit + nerdctl are required to build images.

[0003] Currently, after Kubernetes replaces the container runtime with a container, image building is typically achieved using BuildKit and nerdctl. The main difficulties or drawbacks are: firstly, a lack of documentation on the use of these two components, making the learning process difficult; secondly, the two introduced tools differ significantly from existing build tools, creating usage obstacles.

[0004] Therefore, those skilled in the art have great concerns and resistance to Kubernetes replacing container runtimes, resulting in many people being unwilling to upgrade to new versions of Kubernetes, and many new features being unavailable. Summary of the Invention

[0005] To overcome the above-mentioned technical defects, the purpose of this invention is to provide a method for building Kubernetes cluster images based on containerd containers to replace the existing container+buildkit+nerdctl method.

[0006] This invention discloses a method for building images for a Kubernetes cluster based on containerd containers, comprising the following steps: obtaining a base image by inheriting image information from the podman container; building an application image for at least one programming language based on the base image; preparing a first configuration file for podman, the first configuration file including several image repositories and the storage location of each image repository; preparing a second configuration file for at least one programming language, the second configuration file including the configuration environment on which at least one programming language depends; mounting the directories specified by the first configuration file and the second configuration file to the host directory or distributed shared storage; writing an operation and maintenance feature configuration file for the application, the operation and maintenance feature configuration file including setting the basic operation and maintenance features of the application; and performing the CI and CD processes of the application in the application deployment pipeline to achieve deployment in the Kubernetes cluster.

[0007] Preferably, the step of building an application image for at least one development language based on the base image includes: building at least one application image based on the base image; adding the compilation environment required for the at least one development language to each of the at least one application image, and marking the image build with a tag.

[0008] Preferably, the at least one development language includes at least one of Java, Node.js, and Golang; the compilation environment includes at least one of Maven, Gradle, noddenpm, and Go.

[0009] Preferably, the plurality of mirror repositories include domestic mirror repositories and local private mirror repositories.

[0010] Preferably, the preparation of a second configuration file for at least one development language includes configuring the local private repository and the domestic repository.

[0011] Preferably, the basic operation and maintenance features include any one or more of the following: port, tag, number of replicas, namespace, health check rules, and service exposure method.

[0012] Preferably, before performing the CI and CD processes in the application deployment pipeline, the method further includes: writing a Jenkinsfile to define the CI and CD processes.

[0013] Preferably, the CI process includes: performing source code retrieval and static code scanning; matching the compilation environment according to the basic operation and maintenance characteristics for compilation, wherein the compilation environment includes the development language environment and the development framework; completing image building based on the compilation results, and setting the image name and / or image identification tag for image retrieval; and pushing the built image to the image repository.

[0014] Preferably, pushing the constructed image to the image repository includes: obtaining access credentials for the image repository, the access credentials including a username and password; performing a security scan on the image and confirming it as secure.

[0015] Preferably, the CD process includes: pulling images from the image repository and deploying the operation and maintenance feature configuration file to the Kubernetes cluster.

[0016] Compared with existing technologies, the above technical solution has the following advantages:

[0017] 1. This invention implements the image building and image pushing process by introducing the podman container into containerd. Since the usage of the podman container is basically consistent with the docker command, the introduction of podman will not increase the learning cost or usage obstacles. It can quickly switch to the new container to run, reduce the learning cost and usage cost, thereby reducing users' fear of upgrading Kubernetes and ensuring the ease of use and advanced nature of Kubernetes as infrastructure.

[0018] 2. The solution of this invention supports multiple languages ​​and generates different build container environments through different tool images, thereby enabling the construction of application images for multiple languages. Users can select the corresponding build environment based on tags. No third-party tools are required, reducing integration and learning costs. Furthermore, it supports caching within the container environment, achieving build data caching through directory mounting within the container, thereby reducing build time and improving build efficiency. The image construction of business applications is achieved by running a build tool container within the container. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the image building method for a Kubernetes cluster based on containerd provided by the present invention. Detailed Implementation

[0020] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0022] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0024] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0025] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0026] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0027] The container described in this invention is a standardized, standalone software package containing all the necessary elements that can run anywhere without customization, including application code and supporting libraries. Similar to a virtual machine, a process can be virtualized into a container, hosting application deployments, providing simple isolation mechanisms, and enabling efficient resource utilization as well as rapid packaging and deployment.

[0028] Docker is one of the most widely used container engines. It employs a client / server (C / S) architecture. The Docker Client acts as the client, interacting with the user. The Docker daemon, the daemon process for Docker containers, acts as the server, interacting with the Docker Client and managing Docker images and containers. A Docker image is a template used to create Docker containers, and a Docker container is a single, independently running application or a group of applications.

[0029] Like Docker, Podman is also a container engine, a tool for developing, managing, and running containers and container images.

[0030] As containerized applications become increasingly complex, developers need tools to coordinate the interactions between containers running on different virtual machines, and even on different physical machines. Such tools are called container orchestration platforms, and Kubernetes is one such platform. Kubernetes can work with any container that conforms to the Open Container Initiative (OCI) image specification; Podman's containers conform to this specification. Kubernetes is an open-source platform for managing containerized applications across multiple hosts in a cloud platform. Kubernetes aims to make deploying containerized applications simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance. Figuratively, Kubernetes can be understood as a centralized, integrated transportation tool.

[0031] Podman and Docker are generally compatible, partly due to their adherence to open standards, as both engines use OCI-compliant containers. You can create a container with Docker and modify it in Podman, or vice versa, and then deploy either container to Kubernetes.

[0032] Containerd is an industry-standard container with advantages such as simplicity, robustness, and portability. It can run as a daemon on Linux and Windows, and is mainly used to manage the complete lifecycle of containers on the host system.

[0033] Image building can be understood as turning an application into a container-readable file that includes the environment required by the application. However, containerd cannot build images; it focuses on a lower level (i.e., the complete lifecycle of containers on the host system mentioned above). Therefore, this invention solves the problem of container image building by introducing the podman container into the containerd runtime, thereby resolving the issue that Kubernetes cannot directly build images after replacing the container runtime with containerd.

[0034] For details, please see the appendix. Figure 1 This invention discloses a method for building an image of a Kubernetes cluster based on containerd, comprising the following steps:

[0035] S100: Obtain the base image by inheriting the image information of the podman container, and build an application image for at least one programming language based on the base image;

[0036] S200, prepare the first configuration file for podman. The first configuration file includes several image repositories and the storage location of each image repository.

[0037] S300. Prepare a second configuration file for at least one development language, the second configuration file including the configuration environment on which at least one development language depends;

[0038] S400, mount the directories specified in the first and second configuration files to the host directory or distributed shared storage;

[0039] S500: Write the application's operation and maintenance characteristic configuration file, which includes setting the application's basic operation and maintenance characteristics;

[0040] S600 performs CI and CD processes in the application deployment pipeline to enable deployment in the Kubernetes cluster.

[0041] The solution of this invention can be understood as including three main stages: the tool image building stage (i.e., the basic tool for building the application), the configuration file preparation stage, and the application deployment stage. Step S100 belongs to the tool image building stage, S200-S500 belong to the configuration file preparation stage, and S600 belongs to the application deployment stage.

[0042] Step S100 specifically includes: first, obtaining a base image by inheriting the image information of the podman container; then, building at least one application image based on the base image. For example, building the base image mainly inherits the image information of the podman container; building an image for at least one programming language, inheriting from the base image, so that the at least one programming language basically has the environment to run in podman (such as the JRE for Java, .NET for C#, etc., which are just examples and not limited); adding the required compilation environment for the at least one programming language and marking the image build tag. Based on the above steps, we can write an image for at least one programming language or development framework dependency environment. When there are multiple programming languages, this achieves the foundation for building images of multiple languages ​​in the podman container.

[0043] The programming language must include at least one of Java, Node.js, and Golang (but is not limited to these); the compilation environment must include at least one of Maven, Gradle, noddenpm, and Go (but is not limited to these). The corresponding tags for the programming language and compilation environment can be maven-jdk8, maven-jdk11, go1.16, nodeJs14, etc. (but are not limited to these).

[0044] For step S200, typically, image repositories include domestic image repositories and local private image repositories. In some cases, image repositories also include foreign image repositories. Domestic image repositories are faster at acquiring images than foreign image repositories, while local private image repositories are faster than domestic image repositories. Local private image repositories are mainly used to manage local images, but can also manage external public images.

[0045] The image repositories in this invention mainly include domestic image repositories and local private image repositories. Step S200 mainly configures the podman image repository and its storage location to prepare for subsequent image retrieval.

[0046] Step S300 primarily involves configuring the configuration environment for different language frameworks, such as the Java Maven source `setting.xml` configuration file. This configuration file is mainly used to configure the local private repository and domestic repositories of the dependent environment. In some cases, it can also be used to configure the foreign repositories of the dependent environment. For example, the Java Maven source `setting.xml` configuration file mentioned above is used to configure the local private Maven POM repository and the domestic Maven repository of the dependent environment, accelerating the retrieval speed of POM dependencies. In some embodiments, the local private repository is used first, followed by the domestic repository, and then the foreign repository, to improve the efficiency of obtaining repository files and reduce security risks.

[0047] For step S400, since all data will be lost after the container is restarted and rebuilt, rebuilding at this time will take time again. Therefore, to solve the problem of data loss within the container after it disappears and to address the slow compilation and build speed, important application directories are mounted (which can be understood as backing up to a local disk or cloud drive). This mainly includes mounting the directory containing the base image that the compilation and build in step S200 depends on, and the directory containing the configuration environment (such as the local library directories of Maven and Node.js) that the different language frameworks configured in step S300 depend on. This ensures that these base image files and downloaded dependency files can still be shared when the container build changes, reducing network consumption and improving build efficiency.

[0048] Directory mounting can typically be achieved by mounting a host directory or distributed shared storage. Mounting a host directory carries the risk of corruption; distributed shared storage involves sharing storage across multiple devices. The appropriate directory mounting method can be chosen based on your needs.

[0049] Step S500 primarily involves writing the application's basic operational characteristics. These characteristics include one or more of the following (but are not limited to): port, tag, number of replicas, namespace, health check rules, and service exposure methods. On the Kubernetes platform, the application's operational characteristic configuration file is a YAML file.

[0050] For step S600, which is the final application deployment stage, the application CI / CD process needs to be implemented in the DevOps application deployment pipeline. First, a Jenkinsfile is written to define the steps of the CI and CD processes. Furthermore, the Jenkinsfile can also define the shell commands to be executed.

[0051] Specifically, the CI process includes:

[0052] 1) Perform source code retrieval and static code scanning process, including: setting code path and branch / tag and credentials for source code retrieval, static code scanning and scanning rule settings;

[0053] 2) Match the compilation environment to the basic operation and maintenance characteristics for compilation. The compilation environment includes the development language environment and development framework (that is, match different application basic operation and maintenance characteristics according to different development language environments and development frameworks), and select the corresponding container tag (e.g., maven-jdk8, etc.) according to the application's basic operation and maintenance characteristics (e.g., name, port).

[0054] 3) Build the image based on the compilation results. This involves writing a Dockerfile (setting the application's dependencies and copying the compiled application files to the image). Executing the Dockerfile completes the image build process and sets the image name and / or image identification marker for image retrieval. In some embodiments, the image name and / or image identification marker may be a time value plus a random number; this is not limited here.

[0055] 4) Push the built image to the image repository, preferably a local private image repository; when entering the repository, you also need the repository account and password, and you also need to perform a security scan on the image to ensure image security.

[0056] The CD process includes: pulling images from the image repository and deploying the operation and maintenance feature configuration files to the Kubernetes cluster, specifically including:

[0057] 1) Write a common application operation and maintenance feature configuration file app.yaml. To allow more applications to use the same template and reduce the maintenance cost of the template file, extract common parameters from the application and set them as variables. When executing or using the application, these variables will be replaced with the specific application's basic operation and maintenance features. Finally, store the configuration file in a file storage service (e.g., Alibaba Cloud OSS or a local file server).

[0058] 2) Configure pipeline parameters, that is, set the specific basic operation and maintenance characteristics of the application when running the pipeline (e.g., set the application port number parameter to 8080, set the name to myapp, set the image name to myapp:v1.0, etc.); It should be noted that the parameters of the operation and maintenance characteristic configuration file can also be modified here. This modification can be made before deployment or during deployment.

[0059] 3) Based on the specific application and basic operation and maintenance characteristics, download the corresponding operation and maintenance characteristic configuration file app.yaml;

[0060] 4) Configure the security credentials for the Kubernetes cluster and execute app.yaml. If the parameters are not replaced at this point, you need to replace the variables in app.yaml according to the set parameters. Then, pull the image from the image repository and start the image to achieve container deployment.

[0061] This completes the entire process of the present invention, enabling an application to run in a Kubernetes cluster using containerd as the runtime container, without the use of third-party tools for deployment or image building, significantly reducing the difficulty of replacing containers.

[0062] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A method for building images of a Kubernetes cluster based on containerd, characterized in that, Includes the following steps: The base image is obtained by inheriting the image information of the podman container, and an application image for at least one programming language is built based on the base image. Prepare the first configuration file for podman, which includes several image repositories and the storage location of each image repository; Prepare a second configuration file for at least one development language, the second configuration file including the configuration environment on which at least one development language depends; Mount the directories specified in the first configuration file and the second configuration file to the host directory or distributed shared storage; Write an operation and maintenance feature configuration file for the application, which includes setting the basic operation and maintenance features of the application; The application deployment pipeline performs CI and CD processes to enable deployment in the Kubernetes cluster. The process of building an application image for at least one programming language based on the base image includes: At least one application image is built based on the base image; Add the compilation environment required for the at least one development language to each of the at least one application image, and tag the image build.

2. The image building method for a Kubernetes cluster based on containerd according to claim 1, characterized in that, The at least one development language includes at least one of Java, Node.js, and Golang; the compilation environment includes at least one of Maven, Gradle, noddenpm, and Go.

3. The image building method for a Kubernetes cluster based on containerd according to claim 1, characterized in that, The aforementioned mirror repositories include domestic mirror repositories and local private mirror repositories.

4. The image building method for a Kubernetes cluster based on containerd according to claim 1, characterized in that, The basic operation and maintenance characteristics include any one or more of the following: port, label, number of replicas, namespace, health check rules, and service exposure method.

5. The image building method for a Kubernetes cluster based on containerd according to claim 1, characterized in that, Prior to the CI and CD processes in the application deployment pipeline, the following is also included: Write a Jenkinsfile to define the steps of the CI and CD processes.

6. The image building method for a Kubernetes cluster based on containerd according to claim 1 or 5, characterized in that, The CI process includes: Perform source code retrieval and static code scanning; The compilation environment is matched to the basic operation and maintenance characteristics for compilation, and the compilation environment includes the development language environment and the development framework. The image is built based on the compilation results, and the image name and / or image identification tag are set for image retrieval. The constructed image is pushed to the image repository.

7. The image building method for a Kubernetes cluster based on containerd according to claim 6, characterized in that, The step of pushing the constructed image to the image repository includes: Obtain access credentials for the mirror repository, the access credentials including username and password; Perform a security scan on the image and confirm it is in a safe state.

8. The image building method for a Kubernetes cluster based on containerd according to claim 1 or 5, characterized in that, The CD process includes: Pull the image from the image repository and deploy the operation and maintenance feature configuration file to the Kubernetes cluster.

Images