Access management method of containerized application, storage medium and equipment
By integrating k3s clusters, Containerd image storage, BuildKit services, and Traefik routing, the deployment process for containerized applications is simplified, the flexibility and scalability issues of containerized applications in resource-constrained environments are resolved, and efficient and secure container image building and deployment are achieved.
Patent Information
- Application Number
- CN202511963091.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-05-01
AI Technical Summary
Traditional containerized application systems have high resource requirements, making them difficult to run on resource-constrained edge devices or small clusters. The deployment process is complex and time-consuming, affecting the system's flexibility and scalability.
By employing k3s clusters, Containerd image storage, BuildKit services, and Traefik routing, the Kubernetes deployment process is simplified. Through end-to-end automation, resource utilization and image building are optimized, enabling persistent storage and efficient deployment of container images.
It improves the flexibility and scalability of containerized applications, reduces deployment complexity, ensures high system security and reliability, and is suitable for resource-constrained environments and edge computing scenarios.
Smart Images
Figure CN121957774A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of containerized application technology, and more specifically, to an access management method, storage medium, and device for containerized applications. Background Technology
[0002] With the application and widespread adoption of internet technology, the maturity of containerized systems and applications is constantly improving, and the industry's demand for convenient and efficient control and management tools is also growing. Enterprises not only seek to simplify complex deployment processes, but also expect to accelerate development cycles, optimize resource utilization, and ensure the flexibility, scalability, and reliability of systems through automation.
[0003] However, traditional containerized application systems such as standard Kubernetes have high resource requirements and are difficult to run on resource-constrained edge devices or small clusters. At the same time, standard Kubernetes deployment requires manual configuration of etcd, certificates, networks, etc., which is a complex and time-consuming process. When building images with Docker, additional image repository configuration is required, and import and export operations are needed, which increases deployment complexity and results in poor scalability. Summary of the Invention
[0004] To address the problems existing in the prior art, this invention provides an access management method, storage medium, and device for containerized applications. By integrating k3s clusters, Containerd image storage, BuildKit services, and Traefik routing, it simplifies the complex Kubernetes deployment process, optimizes resource utilization, accelerates image building and deployment speed, enhances the flexibility and scalability of the access management system, and ensures high security and reliability.
[0005] To achieve the above technical objectives, the present invention adopts the following technical solution: An access management method for containerized applications includes the following steps: Step S1: Initialize the k3s cluster; Step S2: The user sends a container image build request to the BuildKit service, passes the build parameters to the BuildKit service, and the BuildKit service executes the container image build according to the build parameters; Step S3: Dynamically select the already built container image through form parameters, and generate the chart package according to the chart package generation rules; Step S4: Package the chart package into .tgz format, place it in the k3s-Server-static directory of the k3s cluster, and deploy the application to the k3s cluster through the HelmController service; Step S5: Configure the Traefik routing for the k3s cluster to generate externally accessible routes. External access enters the k3s cluster through the Traefik route, completes request processing, and returns a response.
[0006] Furthermore, the specific process of step S1 is as follows: The Supervisor process starts up the Server nodes of the k3s cluster, starts the control plane components, and deploys the basic services for network and container runtime. The Agent nodes of the k3s cluster establish communication with the Server nodes through a tunnel proxy, and the Kubelet and Kube Proxy components are started and added to the k3s cluster to form a distributed node cluster. Based on CoreDNS built into the k3s cluster, it provides domain name resolution capabilities for all components within the k3s cluster.
[0007] Further, step S2 includes the following sub-steps: Step S2.1: The user initiates a container image build request to the BuildKit service, submitting the Dockerfile and the basic information required for the build as a container image build request to the upload and build interface; Step S2.2: The Nerdctl client receives the container image build request from the upload and build interface and forwards it to the BuildKit service via Docker buildx; Step S2.3: The BuildKit service executes the container image build process based on the received container image build request, completing the compilation and packaging of the container image; Step S2.4: The BuildKit service pushes the built container image to the containerd image storage to achieve persistent storage of the container image.
[0008] Furthermore, the specific rules for generating the chart package in step S3 are as follows: one container image corresponds to one deployment workload file, one service network service file, and one ingress routing file.
[0009] Furthermore, step S4 includes the following sub-steps: Step S4.1: Set the application's chart configuration information, generate a values file from the chart configuration information, and synchronize it to the k3s-server-manifests directory; Step S4.2: When the values file under the k3s-server-manifests directory matches the chart package under the corresponding k3s-Server-static directory, the automatic update process is triggered. Step S4.3: After the automatic update is successful, trigger the automatic deployment command to associate the chart package with the corresponding values file; Step S4.4: The HelmController service receives the deployment instructions, reads the chart package in the k3s-Server-static directory and the values file in the k3s-server-manifests directory, and automatically deploys or updates the corresponding application in the k3s cluster.
[0010] Furthermore, the specific process of step S4.4 is as follows: The Helm Controller service pulls the container image built by BuildKit according to the deployment instructions and submits a deployment request to the k3sServer node. In a k3s cluster, the Scheduler schedules Pods to Server or Agent nodes, and the Kubelet calls containerd image storage to start the Pod and configures the Pod's network and the Service's network proxy. The k3s cluster encapsulates Pods as K8s Services, enabling load balancing and service discovery for Pods.
[0011] Furthermore, in step S5, the traefik-server of the built-in traefik route in the k3s cluster is modified to NodePort, and NodePort is configured to open ports 80 and 443, binding the K8s Service with the Traefik route to generate an externally accessible route.
[0012] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program that causes a computer to execute the access management method for the containerized application.
[0013] Furthermore, the present invention also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the access management method for the containerized application.
[0014] Compared with the prior art, the present invention has the following beneficial effects: This invention provides an efficient, lightweight, and easy-to-manage solution for building, deploying, and accessing containerized applications. By integrating k3s clusters, Containerd runtime, BuildKit services, and Traefik routing, it automates the entire process from development to production. This invention aims to simplify the complex Kubernetes deployment process, optimize resource utilization, accelerate image building and deployment speed, enhance system flexibility and scalability, and ensure high security and reliability. It is suitable for resource-constrained environments and edge computing, continuous deployment, and high-traffic access scenarios, and is particularly suitable for resource-constrained environments and edge computing scenarios, meeting the diverse needs of modern application management and deployment. Attached Figure Description
[0015] Figure 1 This is a flowchart of the access management method for containerized applications according to the present invention; Figure 2 This is a schematic diagram of the container image building process in this invention; Figure 3 This is a schematic diagram illustrating the generation of the chat package in this invention. Detailed Implementation
[0016] The technical solution of the present invention will be further explained and described below with reference to the accompanying drawings.
[0017] like Figure 1 This is a flowchart of the access management method for containerized applications according to the present invention. The access management method includes the following steps: Step S1: Initialize the k3s cluster. k3s is a lightweight Kubernetes distribution designed to provide an easy-to-deploy and manage Kubernetes platform for resource-constrained environments such as edge computing, IoT devices, and development environments, simplifying installation and maintenance. The specific process for initializing a k3s cluster is as follows: The Supervisor process starts up the Server nodes of the k3s cluster, starts control plane components such as API Server, Scheduler and Controller Manager, and deploys basic services for network and container runtime. The Agent nodes of the k3s cluster establish communication with the Server nodes through a tunnel proxy, and the Kubelet and Kube Proxy components are started and added to the k3s cluster to form a distributed node cluster. Based on CoreDNS built into the k3s cluster, it provides domain name resolution capabilities for all components within the k3s cluster.
[0018] Step S2: The user initiates a container image build request to the BuildKit service. The BuildKit service provides a more modern, efficient, and secure way to handle Dockerfile-based build processes. The user passes build parameters to the BuildKit service, which then executes the container image build based on those parameters. Figure 2 This includes the following sub-steps: Step S2.1: The user initiates a container image build request to the BuildKit service, submitting the Dockerfile and the basic information required for the build as a container image build request to the upload and build interface. The upload and build interface supports asynchronous task queues and breakpoint resume, which greatly improves the efficiency of operation. Step S2.2: The Nerdctl client receives the container image build request from the upload and build interface and forwards it to the BuildKit service via Docker buildx; Step S2.3: The BuildKit service executes the container image build process based on the received container image build request, completing the compilation and packaging of the container image; Step S2.4: The BuildKit service pushes the built container image to the containerd image storage to achieve persistent storage of the container image.
[0019] BuildKit is a modern Docker image building tool, while Nerdctl is a more powerful client tool than docker-cli. Together, they can be used with k3s' containerd runtime, providing an efficient image building experience. After the build is complete, the logs can be used to check if it was successful. If successful, the image information can be found in the local repository interface. Several operation APIs are encapsulated, such as image query, image building, image deletion, and image pushing, enabling full lifecycle API operations. A caching mechanism is added during the build process, adjusting the Dockerfile order to place infrequently changing steps first and frequently changing steps later, ensuring the basic layer cache does not expire. Dependency installations such as npm install / pip install are separated into a separate layer, with `--cache-from=local: / / my-cache` prioritizing the reuse of this layer's cache.
[0020] Step S3: As Figure 3By dynamically selecting pre-built container images through form parameters, and generating chart packages according to chart package generation rules, application configurations can be flexibly adjusted without manual writing or modification, significantly improving deployment efficiency. Furthermore, no modification to the underlying code is required, enhancing adaptability and scalability. Specifically, the chart package generation rules are as follows: one container image corresponds to one deployment workload file, one service network service file, and one ingress routing file, ensuring that the generated chart package is compatible with the Kubernetes native API and avoiding deployment failures or operational complexity caused by non-standard resource definitions.
[0021] Step S4: Package the chart package into .tgz format and place it in the k3s-Server-static directory of the k3s cluster. Deploy the application to the k3s cluster through the HelmController service. This avoids additional storage and transmission overhead, further optimizes resource utilization, and reduces human error. It includes the following sub-steps: Step S4.1: Set the application's chart configuration information, including: chart name, version and timeout. Generate the values file of the chart configuration information and synchronize it to the k3s-server-manifests directory. There is no need to repackage the chart, avoiding unnecessary container image rebuilds triggered by configuration changes. Step S4.2: When the values file under the k3s-server-manifests directory matches the chart package under the corresponding k3s-Server-static directory, the automatic update process is triggered to reduce manual intervention; Step S4.3: After the automatic update is successful, the automatic deployment command is triggered, associating the chart package with the corresponding values file to form a closed-loop process of "configuration change → automatic update → automatic deployment". This chain automation significantly shortens the deployment cycle. Step S4.4: The HelmController service receives the deployment instructions, reads the chart package in the k3s-Server-static directory and the values file in the k3s-server-manifests directory, and automatically deploys or updates the corresponding application in the k3s cluster. The operation is simple and fully automated, eliminating the need to manually execute Helm commands.
[0022] The Helm Controller service pulls the container image built by BuildKit according to the deployment instructions and submits the deployment request to the k3s Server node through the K8sAPI. In a k3s cluster, the Scheduler schedules Pods to Server or Agent nodes, and the Kubelet calls containerd image storage to start the Pod and configures the Pod's network and the Service's network proxy. The k3s cluster encapsulates Pods as K8s Services, enabling load balancing and service discovery for Pods.
[0023] Step S5: Configure the Traefik route for the k3s cluster. Specifically, change the `traefik-server` name of the built-in Traefik route in the k3s cluster to `NodePort`, and configure `NodePort` to open ports 80 and 443. Bind the `K8sService` to the Traefik route to generate an externally accessible route. External access enters the k3s cluster through the Traefik route, is forwarded by the Service to the backend Pod, completes request processing, and returns a response. This provides security protection for the application and avoids directly exposing the services inside the k3s cluster. The Traefik route can automatically proxy ingress resources and automatically convert them to HTTPS, and can also be accessed via HTTP. By integrating the Traefik application network registration query interface, it supports viewing the application's service address, traffic path, service call health status, etc. on the webpage. It also integrates Prometheus for real-time monitoring of metrics.
[0024] In one technical solution of this invention, a custom internal domain name resolution configMap file is installed in the kube-system namespace to achieve wildcard matching and IP address mapping from gpg123.vip to xx.xx.xx.xx, supporting use in both public and private network environments. The final result is that normal access to and pinging of the xx.gpg123.vip address can be found in any pod. The coreDns configuration file is encapsulated, allowing domain name management to be controlled via a web interface, so that when adding new services to the edge cluster, there is no need to log in to the server to modify the configuration, thus lowering the barrier to domain name configuration. Specifically: When a user initiates a domain name request, such as foo.bar.com, the domain name resolution is completed through CoreDNS of the k3s cluster, obtaining the service IP of the Ingress Controller; The request is sent to port 80 or 443, which is being listened to by the Ingress Controller, and enters the k3s cluster using the IP address obtained by resolution. The Ingress Controller matches the corresponding internal service within the cluster based on the requested domain name. If the requested domain name is foo.bar.com, it will be routed to the first Service. If the requested domain name is bar.bar.com, it will be routed to the second Service. Requests from other domains are routed to the third Service.
[0025] Each Service acts as the load balancing entry point for a Pod, distributing requests to its associated Pod instances.
[0026] This invention simplifies the complex Kubernetes deployment process, optimizes resource utilization, accelerates image building and deployment speed, enhances the flexibility and scalability of the access management system, and ensures high security and reliability by integrating k3s clusters, Containerd image storage, BuildKit services, and Traefik routing.
[0027] In one embodiment of the present invention, a computer-readable storage medium is also provided, storing a computer program that enables a computer to execute the access management method for containerized applications of the present invention.
[0028] In one technical solution of the present invention, an electronic device is also provided, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the access management method for containerized applications of the present invention.
[0029] In the embodiments disclosed in this application, a computer storage medium may be a tangible medium that may contain or store programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of computer storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0030] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0031] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.
Claims
1. A method for access management of containerized applications, characterized in that, The steps include: Step S1: Initialize the k3s cluster; Step S2: The user sends a container image build request to the BuildKit service, passes the build parameters to the BuildKit service, and the BuildKit service executes the container image build according to the build parameters; Step S3: Dynamically select the already built container image through form parameters, and generate the chart package according to the chart package generation rules; Step S4: Package the chart package into .tgz format, place it in the k3s-Server-static directory of the k3s cluster, and deploy the application to the k3s cluster through the HelmController service; Step S5: Configure the Traefik routing for the k3s cluster to generate externally accessible routes. External access enters the k3s cluster through the Traefik route, completes request processing, and returns a response.
2. The access management method for containerized applications according to claim 1, characterized in that, The specific process of step S1 is as follows: The Supervisor process starts up the Server nodes of the k3s cluster, starts the control plane components, and deploys the basic services for network and container runtime. The Agent nodes of the k3s cluster establish communication with the Server nodes through a tunnel proxy, and the Kubelet and Kube Proxy components are started and added to the k3s cluster to form a distributed node cluster. Based on CoreDNS built into the k3s cluster, it provides domain name resolution capabilities for all components within the k3s cluster.
3. The access management method for containerized applications according to claim 1, characterized in that, Step S2 includes the following sub-steps: Step S2.1: The user initiates a container image build request to the BuildKit service, submitting the Dockerfile and the basic information required for the build as a container image build request to the upload and build interface; Step S2.2: The Nerdctl client receives the container image build request from the upload and build interface and forwards it to the BuildKit service via Dockerbuildx; Step S2.3: The BuildKit service executes the container image build process based on the received container image build request, completing the compilation and packaging of the container image; Step S2.4: The BuildKit service pushes the built container image to the containerd image storage to achieve persistent storage of the container image.
4. The access management method for containerized applications according to claim 1, characterized in that, The specific rules for generating the chart package in step S3 are as follows: one container image corresponds to one deployment workload file, one service network service file, and one ingress routing file.
5. The access management method for containerized applications according to claim 1, characterized in that, Step S4 includes the following sub-steps: Step S4.1: Set the application's chart configuration information, generate a values file from the chart configuration information, and synchronize it to the k3s-server-manifests directory; Step S4.2: When the values file under the k3s-server-manifests directory matches the chart package under the corresponding k3s-Server-static directory, the automatic update process is triggered. Step S4.3: After the automatic update is successful, trigger the automatic deployment command to associate the chart package with the corresponding values file; Step S4.4: The HelmController service receives the deployment instructions, reads the chart package in the k3s-Server-static directory and the values file in the k3s-server-manifests directory, and automatically deploys or updates the corresponding application in the k3s cluster.
6. The access management method for containerized applications according to claim 5, characterized in that, The specific process of step S4.4 is as follows: The Helm Controller service pulls the container image built by BuildKit according to the deployment instructions and submits a deployment request to the k3sServer node. In a k3s cluster, the Scheduler schedules Pods to Server or Agent nodes, and the Kubelet calls containerd image storage to start the Pod and configures the Pod's network and the Service's network proxy. The k3s cluster encapsulates Pods as K8s Services, enabling load balancing and service discovery for Pods.
7. The access management method for containerized applications according to claim 6, characterized in that, In step S5, the traefik-server of the built-in traefik route in the k3s cluster is changed to NodePort, and NodePort is configured to open ports 80 and 443. The K8s Service is then bound to the traefik route to generate an externally accessible route.
8. A computer-readable storage medium storing a computer program, characterized in that, The computer program causes the computer to execute the access management method for containerized applications as described in any one of claims 1-7.
9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the access management method for a containerized application as described in any one of claims 1-7.