Method and system for dynamically upgrading applications in a Kubernetes environment

Abstract

The present invention provides a method and system for dynamically upgrading applications in a kubernetes environment, and relates to the field of computer technology. The method comprises: step S1: defining a policy and configuring meta information of the policy; step S2: binding a container group to the policy; step S3: executing the policy, generating a dynamic container upgrade plan, scanning the bound container group, and performing a rolling upgrade; step S4: processing an intercepted container group rolling upgrade request, updating the container group template based on the policy, and deploying a container object. When the container object is started, the loading policy and the directory mapping policy are loaded, and the application image is loaded into the policy to complete the application container update. The present invention can reduce the complexity of dynamic container upgrades and realize the unified management function of dynamic upgrades of similar application images.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and system for dynamically upgrading applications in a Kubernetes environment. Background Art

[0002] Kubernetes is an open source container orchestration engine from Google that supports automated deployment, large-scale scalability, and containerized application management. When deploying an application in a production environment, you usually need to deploy multiple instances of the application to load balance application requests. In Kubernetes, we can create multiple containers, each of which runs an application instance, and then use the built-in load balancing strategy to manage, discover, and access this group of application instances, without requiring operations and maintenance personnel to perform complex manual configuration and processing.

[0003] The invention patent with publication number CN102843342A discloses a method and system for dynamic resource upgrade, including: a resource acquisition module receives resource acquisition request information sent by a client, and the resource acquisition request information contains the type and identifier of the resource that the client needs to obtain; the resource acquisition module obtains a resource object with the same type and identifier as the resource in the resource acquisition request information from the resource library, and the resource library stores resource objects generated by a resource processing module for a plug-in dynamically deployed in an open service gateway initiator OSGI service platform, and the resource object carries a type and an identifier; the resource acquisition module sends the acquired resource object to the client.

[0004] The existing technology has the following defects: 1. It is difficult to ensure the stability of unified dynamic upgrades for containers of different scopes; 2. It is impossible to determine whether the mount paths overlap; 3. It is difficult to ensure application integrity and high availability in situations such as unexpected container restarts, node crashes, and file loss. Summary of the invention

[0005] In view of the defects in the prior art, the present invention provides a method and system for dynamically upgrading applications in a Kubernetes environment.

[0006] According to a method and system for dynamically upgrading applications in a Kubernetes environment provided by the present invention, the scheme is as follows:

[0007] In a first aspect, a method for dynamically upgrading an application in a Kubernetes environment is provided, the method comprising:

[0008] Step S1: define the policy and configure the policy meta-information;

[0009] Step S2: Bind the container group to the policy;

[0010] Step S3: Execute the strategy, generate a dynamic container upgrade plan, scan the bound container group, and perform a rolling upgrade;

[0011] Step S4: Process the intercepted container group rolling upgrade request, update the container group template based on the policy, and deploy the container object. When the container object is started, load the mounting policy and directory mapping policy, load the application image into the policy, and complete the application container update.

[0012] Preferably, the step S1 comprises:

[0013] Step S1.1: configure the following meta-information in the policy: image, version, concurrent number of upgraded applications, interval time, and failure policy for dynamic container upgrades;

[0014] Step S1.2: configure the following meta information in the policy: configure the image loading path for container dynamic upgrade, the container dynamic upgrade root directory, the container dynamic upgrade feature file, generate the image loading command, the image loading check command and the directory mapping command.

[0015] Preferably, the step S2 specifically includes:

[0016] Configure the policy to associate the application at the application level, select the container group list to enable the function and update the policy meta information;

[0017] Configure the policy to associate applications at the system level, select the system where the feature is enabled, select the list of container groups in the system where the feature is not enabled, and update the policy meta information;

[0018] Configure the policy to associate the application at the cluster level, select the system list in the cluster where the function is not enabled, select the container group list in the cluster where the function is not enabled, and update the policy meta information.

[0019] Preferably, the step S3 specifically includes:

[0020] Non-mirror part of the upgrade strategy: map the concurrency number, upgrade rollback strategy, and mounting strategy in the configuration strategy to comments and update them to the comment field of the container group;

[0021] Upgrade the mirror part of the policy: Step S3.1: Back up the policy and update the annotation field of the policy;

[0022] Step S3.2: Selecting a policy to be executed at an application level, a system level, or a cluster level according to the scope of the policy;

[0023] Step S3.3: Get all container groups in the upgrade list, verify the container group annotations, confirm the mapping correctness of the container dynamic upgrade base image, loading strategy, upgrade parallel quantity, and rollback strategy loading, and update the container group upgrade version, generate backup annotations for the original container group records, and update them to the container group annotation field;

[0024] Step S3.4: according to the update plan and the number of parallel upgrades, update the upgrade version number and the container group annotation, and perform batch rolling updates of the container group;

[0025] Step S3.5: When upgrading a single container group, start the rollback strategy. If the rollback strategy is to ignore the fault, then wait for the interval time before upgrading the next batch of container groups.

[0026] If the rollback strategy is to stop on failure, the system will wait for an interval and perform an interrupt upgrade or the next batch update based on the failure information;

[0027] The rollback strategy is failure rollback, waiting for an interval, and performing rollback or executing the next batch update based on the failure information;

[0028] Step S3.6: Execute the upgrade task, perform container group upgrade, inspection, and rollback operations according to the container group list, and record the full upgrade process.

[0029] Preferably, in step S3.2, the strategy is selected to be executed at one of the application level, system level or cluster level, specifically including:

[0030] The policy is at the application level: read the container group upgrade list according to the policy;

[0031] The policy is at the system level: Scan all container groups in the system to filter them, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the policy, and obtain the container group upgrade list;

[0032] The strategy is cluster-level: Scan all container groups in the system to filter container groups, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the strategy, read the system ignored in the strategy, scan all container groups in the system to obtain container group C, and obtain the container group upgrade list.

[0033] Preferably, step S3.5 includes a waiting time algorithm, which is as follows:

[0034] Tn represents the waiting time for checking the application upgrade status for the Nth time, and S represents the maximum waiting time for checking. If the waiting time exceeds the maximum time, the check and upgrade will be stopped, and the upgrade environment will be retained:

[0035] Wherein, N = n + 1;

[0036] Known:

[0037] T0 is the waiting time for the first check of application upgrade status;

[0038] T1 is the waiting time for the second check of the application upgrade status;

[0039] but:

[0040] Tn=T(n-1)+T(n-2);

[0041] S=T10.

[0042] Preferably, step S4 comprises:

[0043] Step S4.1: intercepting requests to create a container group and intercepting updates to the container group;

[0044] Step S4.2: Based on the initialization image template, the mount file template, and the label template, the initialization container template is loaded, and spec.initContainers{load-container}.image, spec.initContainers{load-container}.cmd, spec.initContainers{load-container}.volumeMount, and the shared storage load-dir of the loading container are updated;

[0045] Step S4.3: Based on the container image template and the mount file template, dynamically upgrade the container of the container group, and update spec.containers{container}.image and spec.containers{container}.volumeMount;

[0046] Step S4.4: Based on the container dynamic upgrade root directory and mount file template defined in the policy, perform path mapping, map the root directory and mount path into a directory tree, process the mounting of the container group template through subpath mapping, define the application image root path as A, the container dynamic upgrade root path as B, the mounted directory or file as C, define C = A / D, then map to B / D, otherwise no mapping is performed;

[0047] Step S4.5: Expand the generated loading command configuration file, add the copy media command, the verify media command, and the verify media path command to the startup command in the initialization container, and finally generate the startup command for the initialization container and the startup command for the dynamic upgrade of the container, and generate a configmap file;

[0048] Step S4.6: Determine whether this request is a creation request or the first time to enable dynamic upgrade of the container;

[0049] Step S4.7: after the container group is parsed, a container workload is generated, and the container is loaded and dynamically upgraded when the container workload is started;

[0050] Step S4.8: The container workload starts the initialization container, mounts the shared directory, and executes the generated startup command;

[0051] Step S4.9: The container workload starts the dynamic upgrade of the container, mounts the shared directory as the base directory for the dynamic upgrade of the container, executes the dynamic upgrade start command of the container, and completes the container startup process.

[0052] Preferably, the interception of the request to create a container group in step S4.1 will execute the following steps:

[0053] a. Intercept the request to create a container group, and generate the container group initialization container template and container dynamic upgrade template based on the annotation fields and policies of the container group;

[0054] b. Read the metadata in the container group annotation: read the base image for dynamic container upgrade, the command for dynamic container upgrade, the number of parallel upgrades, and the container rollback label, and generate a container image template, a mount file template, and a startup command template for updating the dynamic container upgrade template;

[0055] c. Read the update request metadata: image file, mount path and mount file list, generate the initialization container template, mount file template, mount path template and startup command template for updating the initialization container.

[0056] Preferably, intercepting the request to update the container group in step S4.1 includes:

[0057] Update container groups are divided into three categories through update policies, container group labels, and container group templates. Perform the following steps respectively:

[0058] 1) The original cluster does not have the dynamic container upgrade function enabled. To enable this function for the first time, perform the same steps as creating a container group, as well as steps b and c;

[0059] 2) This upgrade is for the application part, so proceed to step c;

[0060] 3) This upgrade is a dynamic upgrade of the container, so proceed to step b.

[0061] In a second aspect, a system for dynamically upgrading applications in a Kubernetes environment is provided, the system comprising:

[0062] Module M1: define the strategy and configure the strategy metadata;

[0063] Module M2: Bind container groups to policies;

[0064] Module M3: Executes policies, generates dynamic container upgrade plans, scans bound container groups, and performs rolling upgrades;

[0065] Module M4: Processes intercepted container group rolling upgrade requests, updates container group templates based on policies, and deploys container objects. When container objects are started, they load the mounting policy and directory mapping policy, load the application image into the policy, and complete the application container update.

[0066] Compared with the prior art, the present invention has the following beneficial effects:

[0067] 1. The present invention realizes the full life cycle management of container release, upgrade, deletion, and rollback, and realizes a manager that manages dynamic upgrades of containers based on container loading technology;

[0068] 2. The present invention implements a container dynamic upgrade manager, which is used to manage the life cycle of containers at three different levels: cluster, system, and application, including publishing container dynamic upgrade metadata, binding containers, managing container application lists, upgrading containers, rolling back containers, and unbinding containers;

[0069] 3. The present invention has complete full life cycle management capabilities for dynamic container upgrades;

[0070] 4. The present invention optimizes the process of container creation, upgrade, and deletion based on the usage method of image loading, manages containers, reduces the complexity of dynamic upgrades of containers, and realizes a unified management function for dynamic upgrades of similar application images. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0072] Figure 1 A schematic diagram of meta information for dynamically upgrading a configuration container;

[0073] Figure 2 This is a schematic diagram of binding container groups and policies;

[0074] Figure 3 Schematic diagram of the execution strategy;

[0075] Figure 4 Diagram for handling intercepted container group rolling upgrade requests. DETAILED DESCRIPTION

[0076] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0077] The embodiment of the present invention provides a method for dynamically upgrading applications in a kubernetes environment. Figure 1 As shown, the method specifically comprises the following steps:

[0078] Step S1: configure the metadata of the dynamic upgrade of the container and define the dynamic upgrade strategy of the container (hereinafter referred to as strategy);

[0079] Specifically, step S1 includes the following steps:

[0080] Step S1.1: Configure the following meta-information in the policy: image, version, concurrent number of upgraded applications, interval time, and fault policy (including fault stop, fault ignore, and fault rollback) for dynamic container upgrades.

[0081] Step S1.2: configure the following meta information in the policy: configure the image loading path for container dynamic upgrade, the container dynamic upgrade root directory, the container dynamic upgrade feature file, generate the image loading command, the image loading check command and the directory mapping command.

[0082] Step S2: Refer to Figure 2 As shown, the application container group (hereinafter referred to as the container group) is bound to the policy;

[0083] Specifically, this step includes: configuring the policy to associate the application at the application level, selecting a container group list to enable the function, and updating the policy meta-information;

[0084] Configure the policy to associate applications at the system level, select the system where the feature is enabled, select the list of container groups in the system where the feature is not enabled, and update the policy meta information;

[0085] Configure the policy to associate the application at the cluster level, select the system list in the cluster where the function is not enabled, select the container group list in the cluster where the function is not enabled, and update the policy meta information.

[0086] Step S3: Refer to Figure 3 As shown, the strategy is executed, a dynamic container upgrade plan (hereinafter referred to as the plan) is generated, the bound container group is scanned, and a rolling upgrade is performed;

[0087] The step S3 specifically includes:

[0088] Scenario 1: Non-mirrored part of the upgrade strategy:

[0089] Map the concurrency number, upgrade rollback strategy, and mounting strategy in the configuration strategy to comments and update them to the comment field of the container group;

[0090] Scenario 2, mirroring part in the upgrade strategy:

[0091] Step S3.1: Back up the policy and update the annotation field of the policy;

[0092] Step S3.2: Select a policy to be executed at the application level, system level, or cluster level according to the scope of policy impact; specifically:

[0093] The policy is at the application level: read the container group upgrade list (hereinafter referred to as the upgrade list) according to the policy;

[0094] The policy is at the system level: Scan all container groups in the system to filter them, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the policy, and obtain the container group upgrade list;

[0095] The strategy is cluster-level: Scan all container groups in the system to filter container groups, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the strategy, read the system ignored in the strategy, scan all container groups in the system to obtain container group C, and obtain the container group upgrade list.

[0096] Step S3.3: Get all container groups in the upgrade list, verify the container group annotations, confirm the mapping correctness of the container dynamic upgrade base image, loading strategy, upgrade parallel quantity, and rollback strategy loading, and update the container group upgrade version, generate backup annotations for the original container group records, and update them to the container group annotation field.

[0097] Step S3.4: Update the upgrade version number and container group annotation according to the update plan and the number of parallel upgrades, and perform batch rolling updates of the container groups.

[0098] Step S3.5: When upgrading a single container group, start the rollback strategy. If the rollback strategy is to ignore the fault, then wait for the interval time before upgrading the next batch of container groups. If the rollback strategy is to stop the fault, then wait for the interval time, interrupt the upgrade or perform the next batch update according to the fault information. If the rollback strategy is to rollback on fault, wait for the interval time, and perform the rollback or the next batch update according to the fault information.

[0099] The waiting time algorithm is as follows:

[0100] Tn represents the waiting time for checking the application upgrade status for the Nth time, and S represents the maximum waiting time for checking. If the waiting time exceeds the maximum time, the check and upgrade will be stopped, and the upgrade environment will be retained:

[0101] Wherein, N = n + 1;

[0102] Known:

[0103] T0 is the waiting time for the first check of application upgrade status;

[0104] T1 is the waiting time for the second check of the application upgrade status;

[0105] but:

[0106] Tn=T(n-1)+T(n-2);

[0107] S=T10.

[0108] Step S3.6: Execute the upgrade task, perform container group upgrade, inspection, and rollback operations according to the container group list, and record the full upgrade process.

[0109] Step S4: Refer to Figure 4 As shown, the intercepted container group rolling upgrade request (hereinafter referred to as intercept request) is processed, the container group template is updated based on the policy, and the container object is deployed. When the container object is started, the mounting policy and directory mapping policy are loaded, the application image is loaded into the policy, and the application container update is completed.

[0110] Specifically, step S4 includes the following steps:

[0111] Step S4.1: intercepting requests to create a container group and intercepting updates to the container group;

[0112] Among them, intercepting the request to create a container group will perform the following steps:

[0113] a. Intercept the request to create a container group (hereinafter referred to as the update request), and generate the container group initialization container template and container dynamic upgrade template based on the annotation fields and policies of the container group;

[0114] b. Read the metadata in the container group annotation: read the base image for dynamic container upgrade, the command for dynamic container upgrade, the number of parallel upgrades, and the container rollback label, and generate a container image template, a mount file template, and a startup command template for updating the dynamic container upgrade template;

[0115] c. Read the update request metadata: image file, mount path and mount file list, generate the initialization container template, mount file template, mount path template and startup command template for updating the initialization container.

[0116] Intercepting requests to update a container group include:

[0117] Update container groups are divided into three categories through update policies, container group labels, and container group templates. Perform the following steps respectively:

[0118] 1) The original cluster does not have the dynamic container upgrade function enabled. To enable this function for the first time, perform the same steps as creating a container group, as well as steps b and c;

[0119] 2) This upgrade is for the application part, so proceed to step c;

[0120] 3) This upgrade is a dynamic upgrade of the container, so proceed to step b.

[0121] Step S4.2: Based on the initialization image template, the mount file template, and the label template, the initialization container template is loaded, and spec.initContainers{load-container}.image, spec.initContainers{load-container}.cmd, spec.initContainers{load-container}.volumeMount, and the shared storage load-dir of the loading container are updated;

[0122] Step S4.3: Based on the container image template and the mount file template, dynamically upgrade the container of the container group, and update spec.containers{container}.image and spec.containers{container}.volumeMount;

[0123] Step S4.4: Based on the container dynamic upgrade root directory and mount file template defined in the policy, perform path mapping, map the root directory and mount path into a directory tree, process the mounting of the container group template through subpath mapping, define the application image root path as A, the container dynamic upgrade root path as B, the mounted directory or file as C, define C = A / D, then map to B / D, otherwise no mapping is performed;

[0124] Step S4.5: Expand the generated loading command configuration file, add the copy media command, the verify media command, and the verify media path command to the startup command in the initialization container, and finally generate the startup command for the initialization container and the startup command for the dynamic upgrade of the container, and generate a configmap file;

[0125] The command generation methods for each part are as follows:

[0126] Copy media command: Based on the cp command, the initialization container is copied to the shared storage load-dir, and then the shared storage load-dir is mounted to the base directory of the container dynamic upgrade. The media verification is performed before the entire copy media command is executed. If the target directory is empty or the media verification is inconsistent, the copy command is executed.

[0127] Verify media command: Based on the SMS3 algorithm, perform feature value algorithm on the target directory and source directory. The whole algorithm is divided into three steps: first, select the feature value file, generate a random number n, obtain the nth leaf node of the source directory tree for executing the second step, obtain the nth leaf node of the target directory tree, if the target directory tree does not have the leaf node, execute the second step based on the empty file wheel, and select the container dynamic upgrade feature file to execute the second step; then execute the SMS3 algorithm on the files filtered out in the first step to generate feature codes S1, S2, D1, D2; finally, execute SMS3 (S1+S2) and SMS3 (D1+D2) to generate feature values ​​of the target directory and source directory. If the two feature values ​​are exactly the same, it indicates that the media verification is the same.

[0128] Verify media path command: This command verifies whether the copied media will not be overwritten by the files and directories mounted by the container dynamic upgrade through sub-path matching. It traverses the files and directories mounted by the container dynamic upgrade and matches the sub-paths with the container dynamic upgrade root directory in turn. If no match is successful, the media path verification is successful.

[0129] Step S4.6: Determine whether this request is a creation request or the first time to enable dynamic upgrade of the container, and perform the following steps:

[0130] Step S4.6.a: This interception request is a creation request or the first time to enable dynamic upgrade and update of the container; execute the spec field in the update request, perform replace on contianer, perform add on initContainer, map the configuration file of the container loading command to generate a configmap object, create a configmap, and the entire update request interception process is completed.

[0131] Step S4.6.b: This interception request is a policy update or an application update; execute the spec field in the update request, perform replace on contianer, perform replace on initContainer, map the configuration file of the container loading command to generate a configmap object, and merge and update the configmap.

[0132] Step S4.7: After the container group is parsed, a container workload is generated, and the container is loaded and dynamically upgraded when the container workload is started.

[0133] Step S4.8: The container workload starts the initialization container, mounts the shared directory, and executes the generated startup command.

[0134] Step S4.9: The container workload starts the dynamic upgrade of the container, mounts the shared directory as the base directory for the dynamic upgrade of the container, executes the dynamic upgrade start command of the container, and completes the container startup process.

[0135] The embodiment of the present invention provides a method and system for dynamically upgrading applications in a Kubernetes environment. The method solves the problem of controlling dynamic upgrades of containers in different ranges by adopting a structure in which a dynamic upgrade strategy of containers is divided into fields and levels; the method solves the problem of stability of unified dynamic upgrades by adopting a structure of batch updates, rollback strategies, and waiting time; the method solves the problem of determining whether mount paths overlap by adopting a directory tree diagram and a sub-path mapping mechanism; the method solves the problem of application integrity and high availability in situations such as unexpected restart of containers, node downtime, and file loss by adopting a structure in which copy media, verification media, and verification media path commands are used to assemble the structure; the method solves the problem of assembling business containers and basic containers at runtime by adopting a structure in which initialization containers and runtime containers interactively load images through shared storage.

[0136] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0137] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A method for dynamically upgrading an application in a kubernetes environment, characterized in that: include: Step S1: define the policy and configure the policy meta-information; Step S2: Binding the container group to the policy; Step S3: Execute the strategy, generate a dynamic container upgrade plan, scan the bound container group, and perform a rolling upgrade; Step S4: Process the intercepted container group rolling upgrade request, update the container group template based on the policy, and deploy the container object. When the container object is started, load the loading policy and directory mapping policy, load the application image into the policy, and complete the application container update; The step S2 specifically includes: Configure the policy to associate applications at the application level, select the container group list to enable the function, and update the policy meta information; Configure the policy to associate applications at the system level, select the system where the feature is enabled, select the list of container groups in the system where the feature is not enabled, and update the policy meta information; Configure the policy to associate the application at the cluster level, select the system list in the cluster where the function is not enabled, select the container group list in the cluster where the function is not enabled, and update the policy meta information; The step S3 specifically includes: Non-mirror part of the upgrade strategy: map the concurrency number, upgrade rollback strategy, and mounting strategy in the configuration strategy to comments and update them to the comment field of the container group; Upgrade the mirror part of the policy: Step S3.1: Back up the policy and update the annotation field of the policy; Step S3.2: Selecting a policy to be executed at an application level, a system level, or a cluster level according to the scope of the policy; Step S3.3: Get all container groups in the upgrade list, verify the container group annotations, confirm the mapping correctness of the container dynamic upgrade base image, loading strategy, upgrade parallel quantity, and rollback strategy loading, and update the container group upgrade version, generate backup annotations for the original container group records, and update them to the container group annotation field; Step S3.4: according to the update plan and the number of parallel upgrades, update the upgrade version number and the container group annotation, and perform batch rolling updates of the container group; Step S3.5: When upgrading a single container group, start the rollback strategy. If the rollback strategy is to ignore the failure, then wait for the interval time before upgrading the next batch of container groups. If the rollback strategy is to stop on failure, the system will wait for an interval and perform an interrupt upgrade or the next batch update based on the failure information; The rollback strategy is failure rollback, waiting for an interval, and performing rollback or executing the next batch update based on the failure information; Step S3.6: Execute the upgrade task, perform container group upgrade, inspection, and rollback operations according to the container group list, and record the full upgrade process.

2. The method for dynamically upgrading applications in a kubernetes environment according to claim 1, characterized in that: The step S1 comprises: Step S1.1: configure the following meta-information in the policy: image, version, concurrent number of upgraded applications, interval time, and failure policy for dynamic container upgrades; Step S1.2: configure the following meta information in the policy: configure the image loading path for container dynamic upgrade, the container dynamic upgrade root directory, the container dynamic upgrade feature file, generate the image loading command, the image loading check command and the directory mapping command.

3. The method for dynamically upgrading applications in a kubernetes environment according to claim 1, characterized in that: In step S3.2, the strategy is selected to be executed at one of the application level, system level or cluster level, specifically including: The policy is at the application level: read the container group upgrade list according to the policy; The policy is at the system level: Scan all container groups in the system to filter them, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the policy, and obtain the container group upgrade list; The strategy is cluster-level: Scan all container groups in the system to filter container groups, obtain container group A according to the upgrade policy number label, read container group B that needs to be ignored in the strategy, read the system ignored in the strategy, scan all container groups in the system to obtain container group C, and obtain the container group upgrade list.

4. The method for dynamically upgrading applications in a kubernetes environment according to claim 1, characterized in that: The step S3.5 includes a waiting interval time algorithm, which is as follows: Tn represents the waiting interval for checking the application upgrade status for the Nth time, and S represents the maximum waiting time for checking. If the waiting time exceeds the maximum time, the check and upgrade will be stopped, and the upgrade environment will be retained: Wherein, N = n + 1; Known: T0 is the waiting interval for the first check of the application upgrade status; T1 is the waiting interval for the second check of the application upgrade status; but: Tn=T(n-1)+T(n-2); S=T10.

5. The method for dynamically upgrading applications in a kubernetes environment according to claim 1, characterized in that: The step S4 comprises: Step S4.1: intercepting requests to create a container group and intercepting updates to the container group; Step S4.2: Based on the initialization image template, the mount file template, and the label template, the initialization container template is loaded, and spec.initContainers{load-container}.image, spec.initContainers{load-container}.cmd, spec.initContainers{load-container}.volumeMount, and the shared storage load-dir of the loading container are updated; Step S4.3: Based on the container image template and the mount file template, dynamically upgrade the container of the container group, and update spec.containers{container}.image and spec.containers{container}.volumeMount; Step S4.4: Based on the container dynamic upgrade root directory and mount file template defined in the policy, perform path mapping, map the root directory and mount path into a directory tree, process the mounting of the container group template through sub-path mapping, define the application image root path as A, the container dynamic upgrade root path as B, the mounted directory or file as C, define C = A / D, then map to B / D, otherwise no mapping is performed; Step S4.5: Expand the generated loading command configuration file, add the copy media command, the verify media command, and the verify media path command to the startup command in the initialization container, and finally generate the startup command for the initialization container and the startup command for the dynamic upgrade of the container, and generate a configmap file; Step S4.6: Determine whether this request is a creation request or the first time to enable dynamic upgrade of the container; Step S4.7: after the container group is parsed, a container workload is generated, and the container is loaded and dynamically upgraded when the container workload is started; Step S4.8: The container workload starts the initialization container, mounts the shared directory, and executes the generated startup command; Step S4.9: The container workload starts the dynamic upgrade of the container, mounts the shared directory as the base directory for the dynamic upgrade of the container, executes the dynamic upgrade start command of the container, and completes the container startup process.

6. The method for dynamically upgrading applications in a kubernetes environment according to claim 5, characterized in that: The interception of the request to create a container group in step S4.1 will execute the following steps: a. Intercept the request to create a container group, and generate the container group initialization container template and container dynamic upgrade template based on the annotation fields and policies of the container group; b. Read the metadata in the container group annotation: read the basic image, dynamic upgrade command, parallel upgrade quantity and container rollback label for container dynamic upgrade, generate container image template, mount file template and startup command template for updating the dynamic upgrade template of container; c. Read the update request metadata: image file, mount path and mount file list, generate the initialization container template, mount file template, mount path template and startup command template for updating the initialization container.

7. The method for dynamically upgrading applications in a kubernetes environment according to claim 6, characterized in that: The interception of the request to update the container group in step S4.1 includes: Update container groups are divided into three categories through update policies, container group labels, and container group templates. Perform the following steps respectively: 1) The original cluster does not have the dynamic container upgrade function enabled. To enable this function for the first time, perform the same steps as creating a container group, as well as steps b and c; 2) This upgrade is for the application part, so proceed to step c; 3) This upgrade is a dynamic upgrade of the container, so proceed to step b.

8. A system for dynamically upgrading applications in a kubernetes environment, characterized in that: include: Module M1: define the strategy and configure the strategy metadata; Module M2: Bind container groups to policies; Module M3: Executes policies, generates dynamic container upgrade plans, scans bound container groups, and performs rolling upgrades; Module M4: Processes intercepted container group rolling upgrade requests, updates container group templates based on policies, and deploys container objects. When container objects are started, they load the mounting policy and directory mapping policy, load the application image into the policy, and complete the application container update. The module M2 specifically includes: Configure the policy to associate the application at the application level, select the container group list to enable the function and update the policy meta information; Configure the policy to associate applications at the system level, select the system where the feature is enabled, select the list of container groups in the system where the feature is not enabled, and update the policy meta information; Configure the policy to associate the application at the cluster level, select the system list in the cluster where the function is not enabled, select the container group list in the cluster where the function is not enabled, and update the policy meta information; The module M3 specifically includes: Non-mirror part of the upgrade strategy: map the concurrency number, upgrade rollback strategy, and mounting strategy in the configuration strategy to comments and update them to the comment field of the container group; Upgrade the mirror part of the strategy: Module M3.1: Backup strategy, update the annotation field of the strategy; Module M3.2: Select the policy to be executed at the application level, system level, or cluster level based on the scope of the policy impact; Module M3.3: Get all container groups in the upgrade list, verify the container group annotations, confirm the mapping correctness of the container dynamic upgrade base image, loading strategy, upgrade parallel quantity, and rollback strategy loading, and update the container group upgrade version, generate backup annotations for the original container group records, and update them to the container group annotation field; Module M3.4: Update the upgrade version number and container group annotation according to the update plan and the number of parallel upgrades, and perform batch rolling updates of container groups; Module M3.5: When upgrading a single container group, start the rollback strategy. If the rollback strategy is to ignore the fault, the next batch of container groups will be upgraded after waiting for an interval. If the rollback strategy is to stop on failure, the system will wait for an interval and perform an interrupt upgrade or the next batch update based on the failure information; The rollback strategy is failure rollback, waiting for an interval, and performing rollback or executing the next batch update based on the failure information; Module M3.6: Execute the upgrade task, perform container group upgrade, inspection, and rollback operations according to the container group list, and record the full upgrade process.

Images