K8s mirror image volume optimization upgrading method based on multi-container separation architecture

Abstract

The invention relates to the technical field of containerized deployment, in particular to a k8s mirror image volume optimization upgrading method based on a multi-container separation framework. Mirror image volume optimization and independent upgrading are realized through separation of a runtime mirror image and an application mirror image and a version number control mechanism, and the method comprises the following steps: S1, constructing the runtime mirror image, S2, constructing the application mirror image, S3, configuring a k8s service deployment file: configuring the k8s service deployment file, defining a collaborative operation rule of the runtime mirror image and the application mirror image, and configuring the k8s service deployment file; wherein the setting comprises the setting of a shared directory mounting mode and the determination of a version number identifier; and S4, executing an upgrading process: responding to a version number updating instruction of the application program mirror image. By separating the application mirror image from the runtime mirror image, a plurality of applications share the runtime mirror image, and the technical problems of large mirror image size, low upgrading efficiency, resource waste, poor system stability and compatibility and the like of the existing k8s mirror image are comprehensively solved.

Description

Technical Field

[0001] The present invention relates to the field of containerized deployment technology, in particular to container orchestration technology and image management technology, and specifically to a k8s image volume optimization and upgrade method based on a multi-container separation architecture. Background Art

[0002] In current application scenarios, a complete image is usually used, which embeds the operating environment and application. Without relying on the image repository (due to the lack of public network access, it is only available on the internal network of the enterprise), when updating the application, the image size is often large, usually exceeding 500MB. In addition, the file server resources are limited, and the download process will consume a lot of time. At present, there are some solutions: One way is to simplify the image file and reduce its size by removing unnecessary files and tools. However, most files are still indispensable, such as necessary runtime libraries, runtime environments, and some common tools. Even so, the optimized image size usually does not exceed 50% of the original size.

[0003] Another solution is to build an image on the client and transfer only the updated application, thereby minimizing the amount of transmission. However, this method is more cumbersome when updating, requires additional operations on the client, and version control is not easy to manage because what is transmitted is the file rather than the application image.

[0004] At present, the relevant technologies have at least the following deficiencies: 1. The build process is more complicated, especially in the case of client-side builds, which adds build steps on the client side. In addition, additional files and scripts are required to execute.

[0005] 2. Although using client-side build can significantly reduce the size of the transferred file, when rolling back to an old version, if the previous image has been deleted, you need to rebuild the image. And it is troublesome to manage the program files yourself, and the program file names are generally consistent, which is easy to cause errors.

[0006] 3. If you use a streamlined file or tool approach, you may need to reinstall it when you need to use it, which increases the complexity of the operation. In the absence of a public network, the installation process may be more complicated because these tools may depend on other tools. At the same time, the image size is not actually reduced much. Installing tools online may cause service interruptions, exceptions, and other problems. And you need to reinstall it every time you restart the application.

[0007] For example, in the existing related technologies, there are the following prior patents: 1. CN111078364A A method for realizing a small-volume base image (through a smaller base image, but still requiring files other than the program); 2. CN114879984A dynamically builds docker images to reduce offline file size (client-side construction and upgrades are a bit troublesome); 3. CN114595034A A method, storage device and device for reducing the size of a container image (by monitoring dependent files, remaking the used files into images, deleting some unnecessary files, but the dependent tools still exist in a separate image).

[0008] In summary, the existing Kubernetes (k8s) image management and application upgrade solutions are difficult to meet the needs of enterprises for efficient, stable and convenient application deployment and updates. An innovative method is urgently needed to solve these problems. Summary of the invention

[0009] In view of this, the purpose of the present invention is to overcome the shortcomings of the prior art and provide a k8s image volume optimization and upgrade method and system based on a multi-container separation architecture. By separating the application image from the runtime image, multiple applications share the runtime image, and comprehensively solve the technical problems of the existing k8s image, such as large image volume, low upgrade efficiency, waste of resources, and poor system stability and compatibility. The specific objectives are as follows: In terms of image building, common tools and debugging functions are integrated into the runtime image. Although the size of the runtime container increases, the container changes very rarely and is only transferred during the first deployment. There is no need for repeated transfers later, which effectively controls the transmission cost. At the same time, the construction process is moved outside the client, so that the upgrade steps are consistent with the single image upgrade process, which greatly simplifies the operation and maintenance operations. After the construction is completed, the image is exported and copied to the client, and the upgrade can be easily achieved by modifying the image version number.

[0010] In terms of improving upgrade efficiency, the version number control mechanism is used to split the image into runtime image and application image. During the upgrade, only the application image is updated, the upgrade content is greatly reduced, the transmission waiting time is significantly shortened, and network resources are saved, thereby achieving rapid upgrade of the application and ensuring business continuity and timeliness.

[0011] In terms of resource utilization, multiple application PODs share runtime images and optimize file resource sharing, avoiding repeated storage and transmission of common functional components, improving resource utilization efficiency, and reducing enterprise IT operation and maintenance costs.

[0012] In terms of system stability and compatibility, it provides a stable and consistent runtime environment for applications, reducing compatibility issues caused by environmental differences. During the upgrade process, the runtime image and application image are managed separately to ensure the stability of the system during the upgrade, avoid service interruptions or failures, and improve the reliability and availability of the system.

[0013] In terms of development and operation convenience, when you need to add public functions, you only need to add new tools or scripts to the runtime image. When transferring, you only need to transfer one runtime image, and there is no need to rebuild and transfer the image for each service, which saves a lot of time. The upgrade operation is simple and can be completed by simply adjusting the runtime image version number. The modular design simplifies the overall process, improves the convenience of development and operation, and accelerates the software development and delivery process.

[0014] To achieve the above purpose, the technical solution adopted by the present invention is: a k8s image volume optimization and upgrade method based on a multi-container separation architecture, characterized in that: image volume optimization and independent upgrade are achieved through the separation of runtime image and application image and version number control mechanism, specifically including the following steps: S1. Build runtime image: Build a runtime image that includes the basic dependency environment and debugging tools required for the application to run; S2. Build application image: Build application image including application files independently of runtime image; S3. Configure k8s service deployment file: Configure k8s service deployment file to define the collaborative operation rules of runtime image and application image, including the setting of shared directory mounting method and the determination of version number identification; S4. Execute the upgrade process: In response to the version number update instruction of the application image, based on the version number control mechanism, trigger the upgrade process of only transmitting and deploying the updated application image to complete the upgrade of the application.

[0015] Furthermore, the runtime image is constructed in step S1, specifically: Select an adapted operating system as the base image for the runtime image; Add the operating environment and dependent libraries to the basic image as the basic dependent environment; Adding a system tool as a debugging tool in the image; Create a startup script / usr / arges / start.sh and set it as the startup entry.

[0016] Furthermore, in step S2, an application image is constructed, a basic image is used to separately encapsulate the application, and a corresponding startup script is provided; specifically: Select scratch as the base image; Copy the compiled application file to the / usr / arges directory; Write a startup script start.sh in the / usr / arges directory to start the application. Select scratch as the base image to build the application image so that the application image only contains application files, further optimizing the image size and facilitating independent upgrades in a multi-container separation architecture.

[0017] Furthermore, after building the runtime image and application image, the image export and storage steps are also included: Specify labels for the runtime image and the application image respectively, and export the two images as files; The exported image file is uploaded to the file server for storage; the image repository in the file server is used to store runtime images and application images. The images in the image repository are distinguished and managed by specified tags to facilitate subsequent search, use and version control.

[0018] Furthermore, in step S3, a k8s service deployment file is created, in which two containers are defined, using a runtime image and an application image respectively, and the two containers work together by sharing a directory; the specific operations are as follows: Define containers: Define two containers in the k8s deployment file; one of the containers uses the previously built runtime image, which contains the basic dependency environment and debugging tools required for the application to run; the other container uses the application image, which only contains application files; Set up a shared directory: Configure the application image to share the / usr / arges directory; in order to facilitate reference and management of the shared directory in the deployment file, name it app; Mount the shared directory: For the runtime image, mount the shared directory named app to its own / usr / arges directory; the runtime image can access the files shared by the application image, thereby realizing file resource sharing between the two containers, allowing the application to run normally in the environment provided by the runtime image; The k8s cluster obtains images from the image repository to create and run containers. The runtime images are stored in the image repository. Multiple application PODs depend on the runtime images. The corresponding application containers in each application POD obtain their corresponding application images from the image repository. Through this image acquisition and dependency mechanism, multiple applications can share the runtime environment, reduce redundancy, improve resource utilization efficiency, and facilitate independent upgrades of applications.

[0019] Furthermore, before executing the upgrade process, the image upload and deployment steps are also included: Upload the runtime image file and the application image file to the application server. If the runtime image is not updated, only upload the application image file; Use the import command to import the application image file into Docker. If it is a cluster environment, publish the image to the local private server warehouse.

[0020] Furthermore, the upgrade process is performed in step S4, specifically: When receiving a version number update instruction for the application image, rebuild the application image and specify a new version number; Upload the upgraded application image file to the application server; Use the command to import the application image into Docker. If it is a cluster environment, publish the image to the local private server warehouse; Use the command to find and edit the previous k8s deployment file; use the command to stop the application; change the image version number of the application container to the new version number; Use the command to restart the application to complete the upgrade operation.

[0021] Furthermore, in the image building process, when executing steps S1 and S2, the following judgments and operations are required: Runtime update judgment: judging whether there is an update requirement for the runtime environment, which is used to determine whether the runtime image needs to be remade. The runtime environment needs to be updated due to one or more of the following situations: updating of the basic dependency library, adding and modifying the debugging tools; if the runtime environment is updated, step S1 is re-executed to rebuild the runtime image including the basic dependency environment and debugging tools required for the application to run according to the new requirements or changes, including adding new dependency libraries and / or updating system tools; Application update judgment: After step S1 is executed, if the runtime environment does not need to be updated, this judgment is performed directly; determine whether the application has been updated, and this judgment determines whether step S2 needs to be re-executed; if the application has been updated, re-execute step S2, encapsulate the compiled application files, and build an application image containing only the application files.

[0022] Furthermore, in the image update process, before executing step S4, the following judgment and operation are required: Whether the runtime image exists or is updated: Determine whether the runtime image exists or has been updated. This is the key to determine subsequent operations. If the runtime image exists or has been updated, pull the runtime image and modify the corresponding version number information in the configuration file to ensure that the system uses the latest runtime image and the configuration file can correctly identify and reference the image version. Application update judgment: After processing the runtime image, determine whether the application has been updated; if the application has been updated, pull the new application image and modify the version number of the application image in the configuration file to ensure that the application uses the latest version of the image; After completing the above judgment and operation, step S4 is executed again to republish the application so that the application runs under the new image configuration, thus completing the entire update process.

[0023] Furthermore, the runtime image contains the common functional components of the application. By separating the application image from the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and the image size during the update process. When the runtime image needs to be upgraded, a new runtime image is generated on the build server and then transferred to the client. The upgrade can be completed by simply modifying the runtime image version number in the deployment file on the client. The application image only contains the application itself, not the runtime environment, dependent libraries, or tools. When upgrading the application, you only need to change the application version and then republish the application.

[0024] The present invention also provides a k8s image volume optimization and upgrade system based on a multi-container separation architecture, comprising: Image building modules: These include runtime image building units and application image building units: Runtime image building unit: used to build a runtime image that contains the basic dependency environment and debugging tools required for the application to run, including selecting an adapted operating system as the basic image, adding the runtime environment and dependency libraries as the basic dependency environment in the basic image, adding system tools as debugging tools, and creating the startup script / usr / arges / start.sh and setting it as the startup entry; Application image building unit: independent of the runtime image building unit, it is used to build an application image containing application files. Specifically, it includes selecting scratch as the base image, copying the compiled application files to the / usr / arges directory, and writing a startup script start.sh in the / usr / arges directory to start the application. In this way, the application image only contains application files, achieving image size optimization and independent upgrade convenience.

[0025] Image management module: Image export and storage unit: After the runtime image building unit and the application image building unit are built, labels are specified for the runtime image and the application image respectively, the two images are exported as files, and the exported image files are uploaded to the file server for storage. The image warehouse in the file server is used to store the runtime image and each application image. The images in the image warehouse are distinguished and managed by the specified labels; Image upload and deployment unit: used to upload runtime image files and application image files to the application server. If the runtime image is not updated, only the application image file is uploaded. The application image file is imported into Docker using the import command. If it is a cluster environment, the image is published to the local private server warehouse.

[0026] k8s service deployment module: used to configure k8s service deployment files and define the collaborative operation rules of runtime images and application images, including: Container definition unit: define two containers in the k8s deployment file, one of which uses the runtime image built by the runtime image building unit. The image contains the basic dependency environment and debugging tools required for the application to run. The other container uses the application image built by the application image building unit. The image only contains application files. Shared directory configuration unit: configure the application image to share the / usr / arges directory and name it app for easy reference and management in deployment files; mount directory execution unit: mount the shared directory named app to the / usr / arges directory of the runtime image, so that the runtime image can access the files shared by the application image, and then realize the file resource sharing between the two containers, so that the application can run normally in the environment provided by the runtime image; at the same time, it is responsible for the k8s cluster to obtain images from the image repository to create and run containers, manage the runtime images stored in the image repository, and multiple application PODs depend on the runtime image. The corresponding application containers in each application POD obtain their corresponding application images from the image repository.

[0027] Upgrade control module: It includes upgrade judgment unit and upgrade execution unit: Upgrade judgment unit: including a runtime image existence or update judgment subunit, used to judge whether the runtime image exists or has been updated; and an application update judgment subunit, which judges whether the application has been updated after processing the runtime image; Upgrade execution unit: In response to the version number update instruction of the application image, based on the version number control mechanism, triggers the upgrade process of only transmitting and deploying the updated application image, specifically including rebuilding the application image and specifying a new version number when receiving the version number update instruction of the application image, uploading the upgraded application image file to the application server, using the command to import the application image into docker, if it is a cluster environment, publishing the image to the local private service warehouse, using the command to find and edit the previous k8s deployment file, using the command to stop the application, changing the image version number of the application container to the new version number, and restarting the application using the command to complete the upgrade operation.

[0028] Furthermore, after the application image construction unit in the image construction module completes the construction at runtime, if the runtime environment does not need to be updated, it starts the application update judgment. When it is determined that the application has been updated, the compiled application file is re-packaged to build an application image containing only the application file.

[0029] Furthermore, the upgrade judgment unit in the upgrade control module, when judging that the runtime image exists or has been updated, pulls the runtime image and modifies the corresponding version number information in the configuration file to ensure that the system uses the latest runtime image and the configuration file can correctly identify and reference the image version; when judging that the application has been updated, pulls the new application image and modifies the version number of the application image in the configuration file to ensure that the application uses the latest version of the image.

[0030] Furthermore, the runtime image includes the common functional components of the application. By separating the application image from the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and the image size during the update process; when the runtime image needs to be upgraded, a new runtime image is generated on the build server and then transmitted to the client. The upgrade operation can be completed by simply modifying the runtime image version number in the deployment file on the client; the application image only includes the application itself, and does not include the operating environment, dependent libraries, and tools. When the application is upgraded, only the version of the application needs to be changed, and then the application is republished.

[0031] The k8s image volume optimization and upgrade method and system based on the multi-container separation architecture provided by the present invention effectively solves many problems existing in the existing k8s image during the application deployment and upgrade process, and has the following significant beneficial effects: 1. Image volume optimization By separating the application image from the runtime image, the application image only contains the application files, and multiple application PODs share the runtime image, reducing the duplicate storage of common functional components. This method can greatly reduce the image size, and the runtime image can be reused by multiple applications. The size of the application image is reduced from more than 500MB to a few hundred KB or more than 100 MB, which significantly reduces storage requirements and network transmission burdens, saves a lot of storage resources and network bandwidth, and effectively controls storage and transmission costs.

[0032] 2. Improved upgrade efficiency Version number control and precise upgrade: With the help of the version number control mechanism, only the application image is updated when the application is upgraded, avoiding unnecessary updates to the common functional components in the runtime image, achieving fast and precise upgrades, shortening the upgrade time, meeting the needs of frequent application updates, and ensuring business continuity.

[0033] Simplified upgrade process: Unlike ordinary k8s deployment file upgrades, this method only needs to modify the application image version number in the application configuration and redeploy during the upgrade, while ordinary deployment file upgrades require updating the entire large image and then modifying the version number and redeploying. This method effectively reduces the complexity and time cost of the upgrade by using two containers and a shared directory mechanism. The upgrade process is consistent with a single image upgrade, which greatly simplifies the operation and maintenance operations.

[0034] 3. Efficient resource utilization It enables multiple application PODs to share runtime images, reducing resource redundancy. At the same time, by properly configuring containers and shared directories, it optimizes file resource sharing, improves overall system resource utilization, and reduces enterprise IT operation and maintenance costs.

[0035] 4. System stability and compatibility It provides a stable and consistent runtime environment for applications, reducing compatibility issues caused by environmental differences. During the upgrade process, the runtime image and application image are managed separately to ensure the stability of the system during the upgrade, avoid service interruptions or failures, and improve system reliability and availability.

[0036] 5. Convenient development and operation Modular design simplifies the process: Through the image building module with clear division of labor, the standardized image management module, the concise k8s service deployment module and the intelligent upgrade control module, the image building, management, deployment and upgrade processes are simplified, the development and operation and maintenance difficulties are reduced, the development and operation and maintenance efficiency is improved, and the software development and delivery process is accelerated; Function reuse and enhanced extension: By adding new tools or scripts to the runtime image, you can easily add common functions to multiple applications without having to build each application separately. This enables efficient function reuse, enhances the scalability and flexibility of the system, and enables rapid response to changing business needs. Reduced O&M complexity: Only application images need to be built and upgraded, which avoids repeated processing of a large amount of redundant content such as the runtime environment, reduces the complexity of O&M personnel's work, reduces business interruption time caused by upgrades, and ensures business continuity and stability. Fast upgrade saves resources: When upgrading, only the application image is operated. Given its small size, it significantly shortens the transmission time, saves network resources, and achieves a fast and efficient upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0038] Figure 1 It is a flow chart of the k8s image volume optimization and upgrade method based on the multi-container separation architecture of the present invention.

[0039] Figure 2 It is a schematic diagram of the system architecture of the present invention.

[0040] Figure 3 It is a judgment and operation flow chart in the image building process of the present invention.

[0041] Figure 4 It is a judgment and operation flow chart in the image update process of the present invention. DETAILED DESCRIPTION

[0042] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0043] Embodiment 1

[0044] like Figure 1As shown, this embodiment provides a k8s image volume optimization and upgrade method based on a multi-container separation architecture, which realizes image volume optimization and independent upgrade through the separation of runtime image and application image and version number control mechanism. This method is particularly suitable for cloud computing and containerized deployment scenarios with high requirements on resource utilization efficiency and frequent application updates;

[0045] S1. Build runtime image: Build a runtime image that includes the basic dependency environment and debugging tools required for the application to run.

[0046] The runtime image provides the necessary basic environment and debugging tools for the application to run, ensuring that the application can run stably and facilitating troubleshooting. In some large distributed systems, a unified runtime image can ensure the consistency of the application running environment on each node and reduce compatibility issues caused by environmental differences.

[0047] As an implementation mode, building a runtime image in step S1 in this embodiment is specifically as follows: Select an adapted operating system as the base image for the runtime image. For example, select the CentOS7 operating system as the base image. CentOS7 has a wide range of software compatibility and stability, and can provide a good operating foundation for most applications. Its rich software sources make it more convenient to add the runtime environment and dependent libraries, saving configuration time and cost.

[0048] Add the runtime environment and dependent libraries to the basic image as the basic dependent environment. Taking a Java application as an example, you need to add the Java runtime environment (JRE) and related C++ dependent libraries. These dependent libraries can be database connection drivers, logging libraries, etc., to ensure that the application can call the required functions normally during runtime.

[0049] Add system tools as debugging tools in the image. Add system tools such as curl, netstat, tcpdump, etc. These tools can help developers debug and analyze when the application has network connection problems or performance bottlenecks, and improve the efficiency of troubleshooting. For example, developers can use the tcpdump tool to capture network data packets, analyze network transmission conditions, and quickly locate the problem.

[0050] Create a startup script / usr / arges / start.sh and set it as the startup entry. The startup script can contain the initialization commands required for application startup, such as setting environment variables and starting background services, to ensure that the application can be started in the predetermined way, improving the repeatability and stability of application deployment.

[0051] S2. Build application image: Build an application image containing application files independently of the runtime image.

[0052] Separating the application image from the runtime image makes the application image smaller and more flexible to update. In the microservice architecture, each microservice can have an independent application image. When a microservice needs to be updated, only the corresponding application image needs to be updated, without updating the entire runtime environment.

[0053] As an implementation mode, in step S2 of this embodiment, an application image is constructed, a basic image is used to separately encapsulate the application, and a corresponding startup script is provided; specifically: Select scratch as the base image. Scratch is an empty base image. Using it can ensure that the application image only contains the files of the application itself and does not contain any unnecessary system libraries and tools, thereby significantly reducing the image size. This makes the application image take up less resources during transmission and storage, saving a lot of bandwidth and storage costs in a cloud computing environment, while also speeding up the pulling and deployment of images.

[0054] Copy the compiled application files to the / usr / arges directory. This allows centralized management of application files, making subsequent operations and maintenance easier. When updating the application version, developers can quickly locate the files that need to be updated, improving the accuracy and efficiency of the update.

[0055] Write a startup script start.sh in the / usr / arges directory to start the application; select scratch as the base image to build the application image, so that the application image only contains the application files, further optimizing the image size and facilitating independent upgrades under the multi-container separation architecture. This method makes application deployment and upgrades more efficient and reduces unnecessary resource waste. In the multi-container separation architecture, each container can be run and managed independently. When an application needs to be upgraded, it will not affect the normal operation of other applications, thereby improving the availability of the entire system.

[0056] As an implementation method, after building the runtime image and the application image, this embodiment also includes the image export and storage steps: Assign tags to the runtime image and the application image respectively, and export the two images as files. Tags can contain information such as the image version number and build time, which facilitates the management and identification of images. For example, assign a tag of "runtime-v1.0-20250204" to the runtime image and "app-v2.1-20250204" to the application image. In this way, in a large-scale image repository, operation and maintenance personnel can quickly find the required images based on tags, improving the efficiency of image management.

[0057] The exported image file is uploaded to the file server for storage; the image repository in the file server is used to store runtime images and application images. The images in the image repository are distinguished and managed by specified tags to facilitate subsequent search, use and version control. By storing images in the image repository, centralized management and sharing of images can be achieved. Different development teams or deployment environments can obtain the required images from the image repository, which improves the efficiency of development and deployment. In multiple projects of a large enterprise, different projects can share common runtime images, reducing the cost of repeated construction and storage, and also facilitating unified management and maintenance of image versions.

[0058] S3. Configure k8s service deployment file: Configure k8s service deployment file to define the collaborative operation rules of runtime image and application image, including the setting of shared directory mounting method and the determination of version number identification.

[0059] The k8s service deployment file is the key to achieving the collaboration between the runtime image and the application image. By properly configuring this file, you can ensure that the application runs stably in the k8s cluster. In large-scale containerized deployments, accurate configuration can improve cluster resource utilization and application availability. In large-scale containerized deployments, such as large social networking platforms, there are massive user requests every day. Accurate configuration can improve cluster resource utilization and application availability, ensure that users can quickly load pages, send messages, etc., and improve user stickiness.

[0060] As an implementation method, in step S3 of this embodiment, a k8s service deployment file is created, in which two containers are defined, respectively using a runtime image and an application image, and the two are coordinated by sharing a directory; the specific operations are as follows: Define containers: Define two containers in the k8s deployment file; one of the containers uses the previously built runtime image, which contains the basic dependency environment and debugging tools required for the application to run; the other container uses the application image, which only contains the application files. In this way, the runtime environment and the application are separated, making it easier to update and maintain the application. When iterating application functions, you only need to update the application image without reconfiguring the runtime environment, which greatly shortens the update cycle.

[0061] Set up a shared directory: Configure the application image to share the / usr / arges directory; in order to facilitate reference and management of the shared directory in the deployment file, name it app. The setting of the shared directory enables file sharing between the runtime image and the application image, realizing data interaction and collaborative work. For example, the log files generated by the application can be stored in the storage environment provided by the runtime image through the shared directory, which is convenient for unified management and analysis.

[0062] Mount a shared directory: For the runtime image, mount the shared directory named app to its own / usr / arges directory; the runtime image can access the files shared by the application image, thereby realizing file resource sharing between the two containers, allowing the application to run normally in the environment provided by the runtime image. The operation of mounting a shared directory ensures that the application can use the basic environment and tools provided by the runtime image, and can also access its own file resources. In actual applications, this enables the application to run efficiently in a stable operating environment, improving the performance and stability of the application.

[0063] The k8s cluster obtains images from the image warehouse to create and run containers. The runtime images are stored in the image warehouse. Multiple application PODs depend on the runtime images. The corresponding application containers in each application POD obtain their corresponding application images from the image warehouse. Through this image acquisition and dependency mechanism, multiple applications can share the runtime environment, reduce redundancy, improve resource utilization efficiency, and facilitate independent upgrades of applications. In the IT systems of large enterprises, multiple business applications can share the same runtime image, reducing the cost of duplicate storage and management of images and improving resource utilization. For example, multiple internal applications such as the company's financial system and human resources system can share runtime images, which reduces the company's IT operation and maintenance costs while ensuring the normal operation of each application.

[0064] like Figure 2 As shown in the figure, the image warehouse is used as a carrier for storing images, including application images, runtime images, etc. Its function is similar to the application market of mobile phones, providing image resources for k8s clusters.

[0065] A container image can be compared to an application installation program, such as the installation packages of common applications such as QQ, WeChat, and Alipay, which carry the files and configurations required for the application to run.

[0066] The k8s cluster is the environment in which the client runs containers, similar to how a mobile phone can run various applications, providing the basic conditions and management functions for the containers to run.

[0067] The application POD runs in the k8s cluster, just like opening QQ, WeChat and other applications and enabling them to provide services. In this optimization solution, the image structure of the application is optimized.

[0068] Specifically, the application image is split into two parts: the runtime image and the image of the application itself. The runtime image contains the common functional components of the application, such as the sharing and push capabilities in WeChat and QQ. By extracting these common functional components into the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and image size during the update process.

[0069] In a k8s cluster, there is only one runtime image, and multiple application pods depend on it. This eliminates the need for each application pod to carry common functional components in its own image, improves resource utilization efficiency, and avoids resource redundancy.

[0070] from Figure 2 As can be seen in the figure, the image warehouse contains the runtime image and three runtime images (running program image 1, running program image 2, and running program image 3). The runtime image provides the basic operating environment for the running program image.

[0071] k8s cluster: Located on the right, it contains three application PODs (application POD1, application POD2, and application POD3). Each POD has a similar structure, consisting of its own application container (including application 1 container, application 2 container, and application 3 container) and a shared runtime container: Application container: contains Java .jar files and C++ binary files, which is the core code part of the application.

[0072] Runtime container: Contains system files, C++ libraries (.so / .a), Java runtime (Jre), and tools (curl / net-tool), providing system-level support and tools required for the application container to run.

[0073] The image warehouse is like the application market of a mobile phone. It is a carrier for storing images. It is used to store various images such as application images and runtime images, and provides image resources for the k8s cluster. The container image is similar to the application installation program, carrying the files and configurations required for the application to run.

[0074] The k8s cluster is the environment for clients to run containers, similar to how mobile phones can run various applications, providing basic operating conditions and management functions for containers. Application PODs run in the k8s cluster, just like opening QQ, WeChat and other applications and enabling them to provide services.

[0075] In this optimization solution, the application image is split into two parts: the runtime image and the application image itself. The runtime image contains the public functional components of the application, such as the sharing and push capabilities in WeChat and QQ. When the application version is updated, there is no need to update the public functional components in the runtime image, which reduces the amount of data transmission and image size during the update.

[0076] As can be seen from the figure, there are runtime images and multiple running program images in the image warehouse. The k8s cluster contains three application PODs, each of which consists of an application container and a runtime container. The application container contains core codes such as java .jar files and c++ binary files; the runtime container contains system files, c++ libraries, java runtimes, and tools, etc., providing system-level support for the application container. In addition, in the k8s cluster, there is only one runtime image, and multiple application PODs rely on the runtime image, which improves resource utilization efficiency and avoids resource redundancy.

[0077] As an implementation method, this embodiment further includes image uploading and deployment steps before executing the upgrade process: Upload the runtime image file and the application image file to the application server. If the runtime image is not updated, only the application image file is uploaded. This method can reduce unnecessary image transmission and improve upgrade efficiency. In a cloud computing environment, a large amount of network bandwidth resources is saved, especially when the application is frequently updated. The advantage is more obvious.

[0078] Use the import command to import the application image file into Docker. If it is a cluster environment, publish the image to the local private server warehouse. The import command here can be the "dockerload-i" command, which imports the application image file into the local Docker environment. In a cluster environment, publishing the image to the local private server warehouse can facilitate each node in the cluster to obtain the image. Improve the efficiency of image distribution and ensure that all nodes in the cluster can quickly obtain the latest application image.

[0079] S4. Execute the upgrade process: In response to the version number update instruction of the application image, based on the version number control mechanism, trigger the upgrade process of only transmitting and deploying the updated application image to complete the upgrade of the application.

[0080] The version number control mechanism is the core of independent application upgrades. By managing the version number of the application image, the updated application can be accurately identified and deployed. When the function of the product display page needs to be quickly updated, the version number of the application image can be updated to achieve rapid deployment. In the promotion activities of the e-commerce platform, when the function of the product display page needs to be quickly updated, the version number of the application image can be updated to achieve rapid deployment. For example, before large-scale promotion activities such as "Double 11", the e-commerce platform can quickly update the application, add limited-time discounts, full-reduction activities and other functions, and through the version number control mechanism, ensure that all users can experience the latest functions in a timely manner, while ensuring the stability and compatibility of the system.

[0081] As an implementation mode, the upgrade process is performed in step S4 in this embodiment, specifically: When receiving the version number update instruction of the application image, the application image is rebuilt and a new version number is specified. The new version number can reflect the updated content and time of the application, for example, the version number is updated from "v2.1" to "v2.2". In this way, developers and operation and maintenance personnel can quickly understand the update status of the application through the version number, which is convenient for version management and rollback operations.

[0082] Upload the upgraded application image file to the application server. Ensure that the application server has the latest version of the application image to prepare for subsequent deployment and operation.

[0083] Use the command to import the application image into Docker. If it is a cluster environment, publish the image to the local private server warehouse. The command used here can also be the "dockerload-i" command to import the upgraded application image into the Docker environment and publish it to the private server warehouse in the cluster environment. This step ensures the deployability of the image in different environments, whether it is a single-machine test environment or a large-scale cluster production environment, the application image can be deployed smoothly.

[0084] Use the command to find and edit the previous k8s deployment file; use the command to stop the application; change the image version number of the application container to the new version number. You can use the "kubectleditdeployment" command to find and edit the k8s deployment file, use the "kubectlscaledeployment[deployment-name]--replicas=0" command to stop the application, and then change the image version number of the application container to the new version number. The use of these commands makes the application upgrade operation more standardized and controllable, reducing the occurrence of human errors.

[0085] Use the command to restart the application to complete the upgrade. Use the "kubectlscaledeployment [deployment-name] --replicas=[desired-replicas]" command to restart the application so that the application runs under the new image version. The combination of these commands realizes the automatic upgrade of the application and improves the efficiency and accuracy of the upgrade.

[0086] like Figure 3 As shown, this patent requires building an additional runtime image that integrates necessary components such as the runtime environment, common tools, and dependent libraries. This image is usually kept stable, and changes are mainly reflected in the application image.

[0087] For runtime image updates, a new runtime image will be generated on the build server and transferred to the client. On the client, the upgrade can be completed by simply changing the runtime version number in the deployment file.

[0088] As for the application update, you only need to deal with the image containing the application itself, which does not include the operating environment, dependent libraries and tools, so the image file size is small and easy to upgrade. When updating, you only need to change the version number of the application and re-publish the application.

[0089] like Figure 3 As shown, as an implementation method, in the image building process of this embodiment, when executing steps S1 and S2, the following judgments and operations are required: Runtime update judgment: judge whether there is an update requirement for the runtime environment. This judgment is used to determine whether the runtime image needs to be remade. The runtime environment needs to be updated due to one or more of the following situations: updating the basic dependency library, adding debugging tools, and modifying them. If the runtime environment is updated, step S1 is re-executed to rebuild the runtime image containing the basic dependency environment and debugging tools required for the application to run according to the new requirements or changes, including adding new dependency libraries and / or updating system tools. For example, when a security vulnerability in the basic dependency library is found to need to be updated, or a new debugging tool needs to be added, the runtime image needs to be remade to ensure the security and debuggability of the application.

[0090] Application update judgment: After step S1 is executed, if the runtime environment does not need to be updated, this judgment is performed directly; whether the application has been updated, this judgment determines whether step S2 needs to be re-executed; if the application has been updated, step S2 is re-executed to encapsulate the compiled application files and build an application image containing only the application files. When the application code changes, such as adding new features or fixing bugs, the application image needs to be rebuilt. In social media applications, users' demand for new features is constantly changing. Timely updates of applications can meet user needs and increase user activity and loyalty.

[0091] like Figure 4 As shown, as an implementation mode, in the image update process described in this embodiment, before executing step S4, the following judgment and operation are required: Whether the runtime image exists or is updated: Determine whether the runtime image exists or has been updated. This is the key to determine subsequent operations. If the runtime image exists or has been updated, pull the runtime image and modify the corresponding version number information in the configuration file to ensure that the system uses the latest runtime image and the configuration file can correctly identify and reference the image version. When upgrading an application, first ensure the availability and latestness of the runtime image to avoid problems with the runtime image causing the application to not run properly.

[0092] Application update judgment: After processing the runtime image, determine whether the application has been updated; if the application has been updated, pull the new application image and modify the version number of the application image in the configuration file to ensure that the application uses the latest version of the image. By judging and processing application updates, the latest application functions can be deployed to the production environment in a timely manner. In mobile application development, timely push of application updates can fix known problems, add new features, and improve user satisfaction.

[0093] After completing the above judgment and operation, step S4 is executed again to republish the application so that the application runs under the new image configuration, thus completing the entire update process.

[0094] In the process of conventional application deployment, upgrades usually require updating the image and modifying the application image version before redeploying. However, due to the large size of the image, this upgrade process takes a long time.

[0095] The configuration method proposed in this patent involves modifying the application image version number in the application configuration file and performing a redeployment operation.

[0096] This configuration uses two containers and shares the application files with the runtime program by sharing the directory, thus merging the two images.

[0097] If you need to integrate the log collection component in all services, you only need to add it in the runtime container, download it to the client after the build is complete, and update the runtime image version number. This process does not require the operation of building, downloading, and modifying the application image version number for each application separately.

[0098] As an implementation mode, the runtime image in this embodiment includes the common functional components of the application. By separating the application image from the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and the image size during the update process; When the runtime image needs to be upgraded, a new runtime image is generated on the build server and then transferred to the client. The upgrade can be completed by simply modifying the runtime image version number in the deployment file on the client. The application image only contains the application itself, not the runtime environment, dependent libraries, or tools. When upgrading the application, you only need to change the application version and then republish the application.

[0099] In this embodiment, two images are built, namely the runtime image and the application image. When building a runtime container, the company's development language is usually fixed, but the number of projects is large, and the runtime image achieves the goal of reuse. As long as the runtime image exists, any number of projects can be released. Under normal circumstances, the size of the runtime image is about 300MB, and each project can save about 300MB of storage space.

[0100] When building an application image, only the application files are included, and their sizes range from a few hundred KB to more than a hundred MB. This image only contains the application, which can save the storage space of the runtime image for multiple application environments. At the same time, it also saves a lot of hard disk resources.

[0101] When updating, since the application image is small in size, it can be deployed quickly, saving resources.

[0102] This k8s image volume optimization and upgrade method based on a multi-container separation architecture shows significant advantages in cloud computing and containerized deployment scenarios, and has the following beneficial effects: Optimize image building and storage: When building a runtime image, choose an adaptive operating system as the base image, add the operating environment, dependent libraries and debugging tools, and set up a startup script to provide a stable operating environment for the application. For example, in a large distributed system, ensure that the operating environment of each node is consistent to reduce compatibility issues. When building an application image, use a scratch base image so that the image only contains application files, which significantly reduces the size, saves a lot of bandwidth and storage costs during transmission and storage, and speeds up pulling and deployment. When exporting and storing images, differentiate management by specifying tags to achieve centralized management and sharing of images. Different projects can share runtime images to reduce repeated construction and storage costs.

[0103] Improve service deployment and collaboration efficiency: Configure k8s service deployment files, define the collaborative operation rules of runtime images and application images, and realize file resource sharing between the two by setting shared directories and mounting operations to improve application performance and stability. In large-scale containerized deployments, such as large social networking platforms, accurate configuration can improve cluster resource utilization and application availability. At the same time, multiple application PODs can rely on the same runtime image, reducing redundancy, improving resource utilization efficiency, facilitating independent upgrades of applications, and reducing enterprise IT operation and maintenance costs.

[0104] Accelerate the upgrade process: Based on the version number control mechanism, respond to the application image version number update instruction, only transmit and deploy the updated application image, and realize automatic upgrade. In scenarios such as e-commerce platform promotion activities, the application functions can be updated quickly to ensure that users can experience new functions in time while ensuring system stability and compatibility. And the judgment operation before the upgrade avoids unnecessary image transmission and update, improving the upgrade efficiency.

[0105] Resource saving: Runtime images can be reused. For companies with a fixed development language and many projects, each project can save about 300MB of storage space. The application image only contains application files, which saves a lot of hard disk resources in a multi-application environment. When updating, the application image is small in size and can be deployed quickly, saving resources.

[0106] Embodiment 2

[0107] The second embodiment is a system adapted by the method in the first embodiment. The second embodiment provides a k8s image volume optimization and upgrade system based on a multi-container separation architecture. The system can efficiently build, manage and upgrade runtime images and application images, and is suitable for cloud computing and containerized deployment environments of various scales. It includes: Image building blocks: Runtime image building unit: used to build a runtime image that contains the basic dependency environment and debugging tools required for the application to run. Specifically, it includes selecting an adapted operating system as the basic image, adding the operating environment and dependency libraries as the basic dependency environment in the basic image, adding system tools as debugging tools, and creating the startup script / usr / arges / start.sh and setting it as the startup entry. The function of the runtime image building unit ensures that the application has a stable and reliable operating environment, and provides debugging tools to facilitate developers to troubleshoot and optimize performance. The runtime image building unit builds a stable operating foundation for the entire system. The adapted operating system and carefully selected dependency environment can meet the operating requirements of different types of applications. Taking big data analysis applications as an example, they have specific requirements for system resource management and data processing libraries. The runtime image building unit can accurately configure the basic image, add big data processing dependency libraries such as Hadoop and Spark, as well as system performance analysis tools such as top and iostat, to ensure that resource allocation and performance monitoring of big data analysis applications at runtime can be achieved, thereby improving the efficiency and accuracy of data analysis.

[0108] Application image building unit: independent of the runtime image building unit, used to build an application image containing application files, including selecting scratch as the basic image, copying the compiled application files to the / usr / arges directory, and writing the startup script start.sh in the / usr / arges directory to start the application. In this way, the application image only contains the application files, realizing image volume optimization and independent upgrade convenience. With the popularization of container orchestration technology, the role of the application image building unit has become increasingly prominent. In the IoT application scenario, a large number of edge devices need to run lightweight applications to realize data collection and preliminary processing. The application image building unit uses the scratch basic image to encapsulate the IoT application into a very small image, which not only reduces the limited storage space occupied by the edge device, but also can quickly complete the image pulling and deployment when the network condition is poor, ensuring that the IoT device is put into operation in time, and improving the response speed and stability of the IoT system.

[0109] Image management module: Image export and storage unit: After the runtime image building unit and the application image building unit are built, specify labels for the runtime image and the application image respectively, export the two images as files, and upload the exported image files to the file server for storage. The image warehouse in the file server is used to store the runtime image and each application image. The images in the image warehouse are distinguished and managed by the specified labels. In the multi-cloud deployment architecture of large enterprises, cloud platforms in different regions may need to use the same image. The image export and storage unit makes it possible to reuse images in different cloud environments through standardized label management and centralized storage. For example, when an enterprise deploys the same business application on domestic and foreign cloud servers, operation and maintenance personnel can quickly obtain the corresponding version of the runtime image and application image according to the label from the unified image warehouse, avoiding repeated construction and transmission, greatly shortening the business deployment cycle, and improving the efficiency of business expansion in the global market.

[0110] Image upload and deployment unit: used to upload runtime image files and application image files to the application server. If the runtime image is not updated, only the application image file is uploaded. The application image file is imported into Docker using the import command. If it is a cluster environment, the image is published to the local private server warehouse. In the agile development mode, the development team needs to frequently deploy newly built images to the test environment and production environment. The intelligent judgment mechanism of the image upload and deployment unit, that is, only uploading updated application image files, greatly improves the deployment efficiency. For example, in a fast-iteration mobile application development project, developers may update the application many times a day. Through the image upload and deployment unit, only the updated part needs to be uploaded each time it is deployed, which reduces waiting time, makes the development, testing and deployment processes smoother, accelerates the development cycle of mobile applications, and enables products to be brought to market faster.

[0111] k8s service deployment module: used to configure k8s service deployment files and define the collaborative operation rules of runtime images and application images, including: Container definition unit: define two containers in the k8s deployment file, one of which uses the runtime image built by the runtime image building unit. The image contains the basic dependency environment and debugging tools required for the application to run, and the other container uses the application image built by the application image building unit. The image only contains application files. The container definition unit ensures that the runtime image and the application image can be correctly deployed and run in the k8s cluster, realizing the separation of the runtime environment and the application. In the deployment of distributed storage systems, the container definition unit ensures the stable operation and flexible upgrade of storage services by clearly dividing the containers of the runtime image and the application image. For example, the Ceph distributed storage system, its runtime image provides the basic environment such as the operating system and file system management, while the application image focuses on the implementation of the Ceph storage service. When the Ceph storage service needs to upgrade its function, it only needs to update the application image without affecting the stable operation of the runtime image, ensuring the continuity and reliability of data storage.

[0112] Shared directory configuration unit: Configure the application image to share the / usr / arges directory and name it app for easy reference and management in deployment files. The shared directory configuration unit provides configuration support for file sharing between the runtime image and the application image, allowing the two containers to work together. The shared directory configuration unit plays an important role in containerized artificial intelligence model inference services. For example, in the image recognition service, the recognition result file generated by the application needs to be stored in a location accessible to the runtime image for further processing and transmission to the user. The shared directory configuration unit shares the / usr / arges directory of the application image and names it app. By mounting this directory, the runtime image can obtain image recognition results in a timely manner, conduct subsequent result analysis and display, realize data interaction between the application and the runtime environment, and improve the overall performance of the artificial intelligence service.

[0113] Mounting directory execution unit: mounts the shared directory named app to the / usr / arges directory of the runtime image, so that the runtime image can access the files shared by the application image, and then realize the file resource sharing between the two containers, so that the application can run normally in the environment provided by the runtime image; at the same time, it is responsible for the k8s cluster to obtain images from the image warehouse to create and run containers, manage the runtime image storage in the image warehouse, and multiple application PODs rely on the runtime image. The corresponding application containers in each application POD obtain their corresponding application images from the image warehouse. The mounting directory execution unit ensures the actual mounting and use of the shared directory, as well as the acquisition and management of the image by the k8s cluster, improving the running stability and resource utilization of the application.

[0114] Upgrade control module: Upgrade judgment unit: including a runtime image existence or update judgment subunit, which is used to judge whether the runtime image exists or has been updated; and an application update judgment subunit, which judges whether the application has been updated after processing the runtime image. The upgrade judgment unit provides a basis for subsequent upgrade operations by judging the update status of the runtime image and the application image, ensuring that the upgrade is only performed when necessary, avoiding unnecessary waste of resources. In a continuous integration / continuous deployment (CI / CD) software development process, the upgrade judgment unit is the key to ensuring stable system upgrades. For example, in an online music playback platform, the runtime image may need to be updated regularly to fix system vulnerabilities or improve performance, while the application image may be frequently updated based on user feedback and new function development. The upgrade judgment unit can accurately identify the update requirements of the runtime image and the application image, avoid unnecessary upgrade operations, and ensure that the music playback platform provides users with new functions and optimized experience in a timely manner on the basis of stable operation.

[0115] Upgrade execution unit: In response to the version number update instruction of the application image, based on the version number control mechanism, trigger the upgrade process of only transmitting and deploying the updated application image, which specifically includes rebuilding the application image and specifying the new version number when receiving the version number update instruction of the application image, uploading the upgraded application image file to the application server, using the command to import the application image into docker, if it is a cluster environment, then publish the image to the local private server warehouse, use the command to find and edit the previous k8s deployment file, use the command to stop the application, modify the image version number of the application container to the new version number, and restart the application with the command to complete the upgrade operation. The upgrade execution unit realizes the automatic upgrade of the application, improves the accuracy and efficiency of the upgrade, and reduces the risk of manual intervention. In high-concurrency Internet application scenarios, such as online live broadcast platforms, the efficiency and accuracy of the upgrade execution unit are crucial. When the live broadcast platform needs to add new interactive functions, such as virtual gift special effects, the upgrade execution unit can quickly respond to the version number update instructions of the application image, and complete the deployment of new functions in a short time through an automated upgrade process, ensuring that during the live broadcast, the anchor and the audience can experience the new functions in a timely manner, thereby improving the competitiveness and user stickiness of the live broadcast platform, and ensuring the uninterrupted operation of the live broadcast service, avoiding live broadcast interruptions caused by upgrades and affecting the user experience.

[0116] As an implementation mode, the runtime image building unit in the image building module described in this embodiment, when building the runtime image, also has a runtime update judgment mechanism. When it is judged that the runtime environment has an update requirement due to one or more of the basic dependency library update, debugging tool addition, and modification, the runtime image containing the basic dependency environment and debugging tools required for the application to run is rebuilt, including adding new dependency libraries and / or updating system tools. In financial transaction systems, security and compliance requirements are extremely high. When the encryption algorithm library in the basic dependency library needs to be updated to meet the latest security standards, or when a new network security monitoring tool needs to be added, the runtime update judgment mechanism can trigger the reconstruction of the runtime image in time. The newly constructed runtime image can provide a safer operating environment for the financial transaction system, ensure the encrypted transmission of transaction data and the stable operation of the system, prevent financial risks caused by security vulnerabilities, and maintain the stability of the financial market and the safety of users' funds.

[0117] As an implementation method, the application image building unit in the image building module described in this embodiment, after the runtime image building unit completes the construction, if the runtime environment does not need to be updated, the application update judgment is started. When it is determined that the application has been updated, the compiled application file is repackaged to build an application image containing only the application file. In the short video social platform, users' demand for new functions and interface optimization changes rapidly. When the development team completes the development of new short video special effects functions or interface interaction optimization, the application update judgment mechanism can detect the update of the application in time and quickly repackage the application image. The new application image can be quickly deployed to the production environment, allowing users to experience new functions and optimized interfaces for the first time, increase users' liking and frequency of use of the platform, and enhance the platform's competitiveness in the short video market.

[0118] As an implementation method, the upgrade judgment unit in the upgrade control module described in this embodiment, when judging that the runtime image exists or has been updated, pulls the runtime image and modifies the corresponding version number information in the configuration file to ensure that the system uses the latest runtime image and the configuration file can correctly identify and reference the image version; when judging that the application has been updated, pulls a new application image and modifies the version number of the application image in the configuration file to ensure that the application uses the latest version of the image. In a cross-platform office software application scenario, the runtime image and the application image may be adaptively updated according to different operating systems and hardware environments. When the upgrade judgment unit detects that the runtime image is optimized for the new operating system version, or the application image has added new office functions, it promptly pulls and updates the image version number information to ensure that the office software can run stably on different devices and provide the latest functions, meet the needs of enterprises and individual users for efficient office work, and improve office efficiency and software user experience.

[0119] As an implementation method, the runtime image described in this embodiment includes the common functional components of the application. By separating the application image from the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and the image volume during the update process; when the runtime image needs to be upgraded, a new runtime image is generated on the build server and then transmitted to the client. The upgrade operation can be completed by simply modifying the runtime image version number in the deployment file on the client; the application image only includes the application itself, and does not include the operating environment, dependent libraries, and tools. When the application is upgraded, only the version of the application needs to be changed and then the application is republished. In the field of game development, a large-scale multiplayer online game may have many server nodes and clients. The separation of the runtime image and the application image makes it necessary to update only the game content in the application image when the game is updated, such as adding new maps, characters, etc., without updating the common functional components in the runtime image, such as the network communication module, server management tools, etc., which greatly reduces the amount of updated data and reduces the bandwidth pressure of the server and client. At the same time, when the runtime image needs to be upgraded, it can be upgraded by simply modifying the version number, ensuring the stable operation of the game service, providing players with a continuous and smooth gaming experience, and increasing the user retention rate and activity of the game.

[0120] This k8s image volume optimization and upgrade system based on multi-container separation architecture has the following significant beneficial effects: Flexible adaptation of image construction: In the image construction module, the runtime image construction unit can accurately configure the basic image according to different application requirements, add exclusive dependency libraries and tools, and create a stable operating environment for the application. For example, big data analysis applications can efficiently allocate resources and monitor performance; the application image construction unit uses the scratch basic image to make the application image small and independent, which has obvious advantages when deployed on IoT edge devices, reducing storage usage and speeding up deployment.

[0121] Image management is efficient and convenient: In the image management module, the image export and storage units are managed through standardized tags to achieve image reuse in multi-cloud environments and shorten the enterprise business deployment cycle; the intelligent judgment mechanism of the image upload and deployment unit only uploads updated application images in agile development, accelerating the development, testing and deployment processes and helping products to be launched quickly.

[0122] Collaborative and stable service deployment: In the k8s service deployment module, the container definition unit clearly divides the containers of runtime images and application images to ensure stable operation and flexible upgrades of services, such as the Ceph distributed storage system; the shared directory configuration unit and the mount directory execution unit work together to achieve file resource sharing between containers, improve application operation stability and resource utilization, and perform well in artificial intelligence model inference services and e-commerce order processing systems.

[0123] Intelligent and precise upgrade control: In the upgrade control module, the upgrade judgment unit accurately identifies the image update requirements, avoids resource waste, and ensures stable system upgrades; the upgrade execution unit realizes automatic application upgrades based on the version number control mechanism. In high-concurrency Internet application scenarios, it can quickly complete the deployment of new functions, ensure uninterrupted services, and improve user experience.

[0124] Overall performance is improved: By separating the application image from the runtime image, the amount of update data and image size are reduced, and the bandwidth pressure is reduced. Whether in the field of game development or other application scenarios, while ensuring the stable operation of the service, it can quickly respond to business changes, improve system scalability and flexibility, meet the diverse business needs of different industries, and enhance the competitiveness of enterprises in the market.

[0125] Although the embodiments of the present invention have been shown and described above, it will be appreciated that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, substitute and vary the above embodiments within the scope of the present invention.

Claims

1. A k8s image volume optimization and upgrade method based on a multi-container separation architecture, characterized by: The image size optimization and independent upgrade are achieved through the separation of runtime image and application image and the version number control mechanism, which includes the following steps: S1. Build runtime image: Build a runtime image that includes the basic dependency environment and debugging tools required for the application to run; S2. Build application image: Build application image including application files independently of runtime image; S3. Configure k8s service deployment file: Configure k8s service deployment file to define the collaborative operation rules of runtime image and application image, including the setting of shared directory mounting method and the determination of version number identification; S4. Execute the upgrade process: In response to the version number update instruction of the application image, based on the version number control mechanism, trigger the upgrade process of only transmitting and deploying the updated application image to complete the upgrade of the application.

2. The method according to claim 1, characterized in that: The step S1 is to build a runtime image, specifically: Select an adapted operating system as the base image for the runtime image; Add the operating environment and dependent libraries to the basic image as the basic dependent environment; Adding a system tool as a debugging tool in the image; Create a startup script / usr / arges / start.sh and set it as the startup entry.

3. The method according to claim 2, characterized in that: In step S2, an application image is constructed, a basic image is used to encapsulate the application separately, and a corresponding startup script is provided; specifically: Select scratch as the base image; Copy the compiled application file to the / usr / arges directory; Write a startup script start.sh in the / usr / arges directory to start the application. Select scratch as the base image to build the application image so that the application image only contains application files, further optimizing the image size and facilitating independent upgrades in a multi-container separation architecture.

4. The method according to claim 1, characterized in that: After building the runtime image and application image, the image export and storage steps are also included: Specify labels for the runtime image and the application image respectively, and export the two images as files; The exported image file is uploaded to the file server for storage; the image repository in the file server is used to store runtime images and application images. The images in the image repository are distinguished and managed by specified tags to facilitate subsequent search, use and version control.

5. The method according to claim 1, characterized in that: In step S3, a k8s service deployment file is created. Two containers are defined in the file, which use a runtime image and an application image respectively, and realize the collaborative work of the two by sharing a directory. The specific operations are as follows: Define containers: Define two containers in the k8s deployment file; one of the containers uses the previously built runtime image, which contains the basic dependency environment and debugging tools required for the application to run; the other container uses the application image, which only contains application files; Set up a shared directory: Configure the application image to share the / usr / arges directory; in order to facilitate reference and management of the shared directory in the deployment file, name it app; Mount the shared directory: For the runtime image, mount the shared directory named app to its own / usr / arges directory; the runtime image can access the files shared by the application image, thereby realizing file resource sharing between the two containers, allowing the application to run normally in the environment provided by the runtime image; The k8s cluster obtains images from the image warehouse to create and run containers. The runtime images are stored in the image warehouse. Multiple application PODs depend on the runtime images. The corresponding application containers in each application POD obtain their corresponding application images from the image warehouse. Through this image acquisition and dependency mechanism, multiple applications can share the runtime environment, reduce redundancy, improve resource utilization efficiency, and facilitate independent upgrades of applications.

6. The method according to claim 5, characterized in that: Before executing the upgrade process, the image upload and deployment steps are also included: Upload the runtime image file and the application image file to the application server. If the runtime image is not updated, only upload the application image file; Use the import command to import the application image file into Docker. If it is a cluster environment, publish the image to the local private server warehouse.

7. The method according to claim 6, characterized in that: The upgrade process is performed in step S4, specifically: When receiving a version number update instruction for the application image, rebuild the application image and specify a new version number; Upload the upgraded application image file to the application server; Use the command to import the application image into Docker. If it is a cluster environment, publish the image to the local private server warehouse; Use the command to find and edit the previous k8s deployment file; use the command to stop the application; change the image version number of the application container to the new version number; Use the command to restart the application to complete the upgrade operation.

8. The method according to any one of claims 1 to 7, characterized in that: In the image building process, when executing steps S1 and S2, the following judgments and operations are required: Runtime update judgment: judging whether there is an update requirement for the runtime environment, which is used to determine whether the runtime image needs to be remade. The runtime environment needs to be updated due to one or more of the following situations: updating of the basic dependency library, adding and modifying the debugging tools; if the runtime environment is updated, step S1 is re-executed to rebuild the runtime image including the basic dependency environment and debugging tools required for the application to run according to the new requirements or changes, including adding new dependency libraries and / or updating system tools; Application update judgment: After step S1 is executed, if the runtime environment does not need to be updated, this judgment is performed directly; determine whether the application has been updated, and this judgment determines whether step S2 needs to be re-executed; if the application has been updated, re-execute step S2, encapsulate the compiled application files, and build an application image containing only the application files.

9. The method according to claim 8, characterized in that: In the image update process, before executing step S4, the following judgment and operation are required: Whether the runtime image exists or is updated: Determine whether the runtime image exists or has been updated. This is the key to determine subsequent operations. If the runtime image exists or has been updated, pull the runtime image and modify the corresponding version number information in the configuration file to ensure that the system uses the latest runtime image and the configuration file can correctly identify and reference the image version. Application update judgment: After processing the runtime image, determine whether the application has been updated; if the application has been updated, pull the new application image and modify the version number of the application image in the configuration file to ensure that the application uses the latest version of the image; After completing the above judgment and operation, step S4 is executed again to republish the application so that the application runs under the new image configuration, thus completing the entire update process.

10. The method according to claim 9, characterized in that: The runtime image contains the common functional components of the application. By separating the application image from the runtime image, when the application version is updated, there is no need to update the common functional components in the runtime image, thereby reducing the amount of data transmission and image size during the update process; When the runtime image needs to be upgraded, a new runtime image is generated on the build server and then transferred to the client. The upgrade can be completed by simply modifying the runtime image version number in the deployment file on the client. The application image only contains the application itself, not the runtime environment, dependent libraries, or tools. When upgrading the application, you only need to change the application version and then republish the application.

Images