Container application management method and system

Abstract

The invention relates to the technical field of unified management of container resources, provides a container application management method and system, and solves the problem of complex multi-resource management in the prior art. The method comprises the steps of receiving an application request of a user for a target application, and determining corresponding sub-resources according to the application request; adding an application tag to a sub-resource related to the target application to update a resource affiliation relationship; and executing an operation of creating, deleting or updating the sub-resources according to an application request, generating a version snapshot of the target application, taking the version snapshot as a historical version resource of the target application, storing the version snapshot, and carrying out rollback according to the version snapshot. According to the method, the unified application labels are added, complex multi-resource management is simplified into single-resource operation, and the management complexity of the application resources is reduced. According to a mechanism of automatically generating the version snapshot, convenient version management is realized, rollback can be realized according to the version snapshot, and the integrity of version rollback is ensured.

Description

Technical Field

[0001] This invention relates to the field of cloud-native technology, and in particular to a container application management method and system. Background Technology

[0002] With the rapid development of cloud-native technologies, containerized application deployment has become a mainstream trend in modern software development. Kubernetes (K8S), as a mainstream container orchestration platform, provides enterprises with core capabilities such as container resource scheduling, service discovery, and automated operation and maintenance. Building upon K8S's native resource management, the industry has gradually developed unified container resource management technologies based on application definitions. These technologies aim to integrate underlying resources such as deployments and stateful sets through abstract models to achieve application-level lifecycle management.

[0003] However, existing technologies have shortcomings such as a lack of application-level overall version management and complexity in rolling back multiple resources. When it is necessary to roll back an application composed of multiple resources, the rollback operation needs to be performed on each resource separately, which is complex and prone to omissions. The rollback command of Kubernetes native resource management can only roll back a single deployed resource, and cannot guarantee the consistency of the rollback state of multi-resource applications.

[0004] Therefore, there is an urgent need for a container application management method that supports version control and version rollback to address the aforementioned technical deficiencies.

[0005] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method for overall version management of applications and overall resource rollback operations.

[0007] To achieve the above method, the present invention adopts the following technical solution: In a first aspect, the present invention provides a container application management method, comprising: Receive user application requests for a target application, and determine the corresponding sub-resources based on the application requests; Add application tags to the sub-resources involved in the target application to update the resource ownership relationship; Perform operations to create, delete, or update the sub-resources according to the application request; A version snapshot of the target application is generated and stored as a historical version resource of the target application for rollback.

[0008] Furthermore, the application request for application creation also includes: The application creation request is parsed to obtain configuration data, and the resource object is determined based on the configuration data; Based on the resource object, the sub-resources to be created are determined sequentially, and application tags associated with the target application are added to the sub-resources to establish the resource ownership relationship between the sub-resources and the target application; Based on the application tag, traverse the sub-resources associated with the target application and create corresponding sub-resources.

[0009] Furthermore, when the application request is an application update request: Receive an application update request from a user for a target application, and obtain the desired state of the target application based on the application update request; Obtain the resource difference between the desired state of the target application and the actual state of the target application; Based on the resource differences, a set of sub-resource differences is obtained. The corresponding sub-resources are updated based on the set of sub-resource differences, and the resource ownership relationship is updated.

[0010] Specifically, it receives a user's application deletion request for a target application, obtains the sub-resources associated with the target application based on the application tag of the target application, and deletes the corresponding sub-resources.

[0011] Furthermore, whenever the application changes, a version snapshot of the application is generated, and a unique application version number is generated for each version snapshot based on preset rules; When the number of application version numbers corresponding to an application exceeds the limit, delete the earlier generated version snapshots.

[0012] Furthermore, version rollback includes: Receive the rollback request from the application, and obtain the corresponding snapshot of the version to be rolled back based on the application version number specified in the rollback request; Obtain the rollback configuration data from the rollback version snapshot, construct an application update request based on the difference between the rollback configuration data and the application's current configuration data, and execute the application update request logic to achieve rollback.

[0013] Furthermore, when a user's stop command for the application is received, all sub-resources associated with the application are traversed through the application tag; The current number of replicas of the sub-resources is stored as annotations in their respective resource objects; Set the replica number field of the sub-resource to zero to stop it from running; When a user's command to launch an application is received, the application's associated sub-resources are traversed again using the application tag. Get the number of replicas before stopping from the annotations of the resource objects corresponding to each sub-resource, and restore the number of replicas of each sub-resource to the number of replicas before stopping; After each sub-resource starts successfully, the temporarily saved annotation information is cleared, and a status response indicating successful application startup is returned.

[0014] The application tags include one or more of the following: application name, resource type, component type, and component name.

[0015] Secondly, the present invention also provides a controller for container application management, comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to perform the container application management method described above.

[0016] Thirdly, the present invention also provides a container application management system, which includes a management cluster consisting of the controller and agent module described above and a business cluster consisting of at least one API server. The controller is used to receive application requests from users for target applications and determine corresponding sub-resources based on the application requests. The controller interacts with the API server through the proxy module, so that the API server performs operations to create, delete or update the sub-resources according to the application request.

[0017] Fourthly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the container application management method described in the first aspect.

[0018] Unlike existing technologies, the container application management method and system provided by this invention have at least the following beneficial effects: By adding a unified application tag, complex multi-resource management is simplified to single-resource operations, reducing the complexity of application resource management. The system automatically generates a version snapshot with each application change, requiring no manual intervention, thus improving the convenience and reliability of version management. Compared to traditional methods that require manual recording and management of versions, this reduces human error and improves operational efficiency. This invention can perform rollback based on a complete version snapshot, ensuring the integrity and consistency of the rollback operation. Compared to the traditional method of rolling back each resource separately, this invention avoids the application state inconsistency problem caused by partial rollback. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0020] Figure 1 This is a flowchart illustrating a container application management method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the instruction interaction of various modules in an application creation or update operation provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of a process for executing an application creation request provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of the instruction interaction of various modules for automatically generating version snapshots provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the instruction interaction of various modules in an application version rollback according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a one-click start / stop application provided by an embodiment of the present invention; Figure 7 This is a schematic diagram of the instruction interaction of various modules of a one-click start / stop application provided by an embodiment of the present invention; Figure 8 This is a schematic diagram of the architecture of an implementation device for a container application management method and system provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

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

[0024] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0025] In describing some embodiments, the terms "coupled," "coupled," and "connected," and their derivative expressions, may be used. For example, the term "connected" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact with each other. Similarly, the term "coupled" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact. However, the terms "connected" or "coupled" may also refer to two or more components that do not have direct contact with each other but still cooperate or interact with each other, such as "optical coupling," "wireless connection," etc. The embodiments disclosed herein are not necessarily limited to the scope of this invention.

[0026] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0027] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0028] Example 1: In modern cloud computing and containerized environments, applications typically consist of multiple interconnected and interdependent microservice components. These components are abstracted into various resources (such as Pods, Services, ConfigMaps, and Deployments) for management in container orchestration platforms such as Kubernetes (K8S).

[0029] The embodiments of this invention aim to provide an application-oriented, declarative management solution. By introducing application tags and a version snapshot mechanism, it organically aggregates scattered sub-resources into a logical whole. Through traversing application tags, sub-resources can be managed uniformly, thereby achieving refined and traceable unified management of the entire application lifecycle.

[0030] like Figure 1 As shown, Embodiment 1 of the present invention provides a container application management method, which includes: Step 10: Receive the user's application request for the target application, and determine the corresponding sub-resources based on the application request.

[0031] In this context, a target application refers to a complete, deliverable software service unit, which is a collection of multiple cooperating microservices, configurations, network rules, and storage declarations. Sub-resources refer to the individual, specific Kubernetes native resources that constitute the target application; a target application can consist of one or more sub-resources.

[0032] In this embodiment, the application request is typically a declarative configuration file that defines the final desired state of the target application. The application request contains the configuration data of the target application required by the user, defines various sub-resources, and constitutes the final desired state of the target application.

[0033] like Figure 2 As shown, the container application management method is implemented by a container application management system, which includes a management cluster consisting of controllers and agent modules, and a business cluster consisting of at least one API (Application Programming Interface) server. The controller receives application requests submitted by users. The controller parses the application request file submitted by the user, calculates the grouping type of each resource contained in the file, and can identify the sub-resources that need to be created or updated to run the target application and their interrelationships.

[0034] Step 20: Add application tags to the sub-resources involved in the target application to update the resource ownership relationship.

[0035] In this embodiment, the controller adds a unified application tag to all sub-resources belonging to the same target application. The application tag includes one or more of the following: application name, resource type, component type, and component name.

[0036] Using these application tags, the system can easily query, filter, and manage all sub-resources belonging to the target application, thereby enabling the binding and updating of resource ownership relationships. During the creation or updating of sub-resources, a unified application tag is added to all sub-resources involved in the target application.

[0037] Step 30: Perform the operation of creating, deleting or updating the sub-resource according to the application request.

[0038] The controller encapsulates the parsed application requests, generating declarative resource data (i.e., the desired state of the target application) that conforms to the Kubernetes API specification. For example... Figure 2 As shown, the controller submits the aforementioned declarative resource data to the API server of the business cluster through a dedicated proxy module.

[0039] After the API server receives and stores this declarative resource data, the corresponding controller begins its work. The controller's built-in reconciliation logic continuously monitors the cluster, collects the actual state of the sub-resources, and compares it with the expected state stored in the API server. Once a state inconsistency is detected (for example, the number of application instances does not reach the expected state), the controller will execute specific create, delete, or update operations through the API server, driving the actual state of the cluster to converge towards the expected state until the operation is complete.

[0040] The creation operation is for sub-resources that exist in the user-defined expected state but do not exist in the current actual state; the API server performs the resource instantiation process. The deletion operation is for sub-resources that no longer exist in the expected state but still exist in the current actual state; the API server performs the resource cleanup process. The update operation is for when a sub-resource exists in both the expected state and the actual state, but its configuration data (such as image version, environment variables, resource quotas, etc.) differs; the API server drives the sub-resource in the actual state to converge towards its expected state.

[0041] It's important to note that the operations described above—creating, deleting, and updating sub-resources—are specific operation types performed within the API server. Typically, when a user needs to update a target application, a series of creation, deletion, and update operations are performed, ultimately returning the desired target application to the user. When a user needs to create a target application, the API server only needs to perform the sub-resource creation operation, creating application instances of the sub-resources required by the target application. Once creation is complete, the API server returns the successfully created target application to the user.

[0042] Through a combination of the three types of sub-resource operations described above, the system ultimately ensures that the overall state of the cluster aligns with the desired state of the target application requested by the user. Once convergence to the desired state is achieved, the API server sends a success response to the controller.

[0043] Step 40: Generate a version snapshot of the target application, store the version snapshot as a historical version resource of the target application, and perform rollback based on the version snapshot.

[0044] A version snapshot refers to a global record and saving of the complete configuration definition of all sub-resources under a target application at a specific point in time (such as after the application is created or updated).

[0045] like Figure 2As shown in this embodiment, after each successful application creation or update operation, the controller detects that the application has changed, and the system automatically triggers the version snapshot generation process to create a historical version of the application. The system uses a selector to query all sub-resources with application tags in the current cluster, collects their complete configuration definitions, and packages them into a single version snapshot file.

[0046] The aforementioned version snapshot is stored as an immutable application history version resource in a distributed key-value store (called etcd) in Kubernetes. During storage, it is assigned a new application history version number.

[0047] When a rollback is needed, the user only needs to specify the application's historical version number, and the system can retrieve the corresponding version snapshot from etcd and accurately rebuild the application environment according to the complete configuration definition in the version snapshot, ensuring the accuracy and consistency of the rollback.

[0048] In this embodiment, in Kubernetes, the controller receives application requests from users for a target application, parses the application requests, and obtains the corresponding information. The application request contains configuration data for each sub-resource and describes the final expected state of the application.

[0049] When Kubernetes receives this application request, it determines the corresponding sub-resources required to execute the user request based on the application request, and performs operations such as creation and update, and schedules it to run on the appropriate node.

[0050] like Figure 3 As shown, when the application request input by the user is an application creation request, the process is as follows: Step 301: Parse the application creation request to obtain configuration data, and determine the resource object based on the configuration data.

[0051] The controller parses the file requested by the application to obtain the target application's configuration data. Based on this configuration data, the controller generates corresponding resource objects. The resource object generation process includes: converting the application's configuration data into a specific resource list conforming to the Kubernetes API specification; and identifying the resource objects that must be created, configured, and managed to run the target application based on the resource list.

[0052] In this embodiment, the resource object carries the corresponding sub-resources, and the resource object fully defines all the sub-resources required to run the target application through its specification field (Spec).

[0053] Step 302: Based on the resource object, determine the sub-resources to be created in sequence, and add application tags associated with the target application to the sub-resources to establish the resource ownership relationship between the sub-resources and the target application.

[0054] Based on the resource objects determined in step 101, the controller sequentially plans the sub-resources to be created and pre-assigns an application tag associated with the target application to each sub-resource. By adding a unified application tag to all scattered sub-resources belonging to the same target application, the controller establishes a clear resource ownership relationship between physically independent sub-resources. This lays the foundation for subsequent unified application-level operations (such as one-click start / stop, version management, and version rollback).

[0055] Step 303: Traverse the sub-resources associated with the target application based on the application tag, and create the corresponding sub-resources.

[0056] The controller uses the application tags added in step 302 as the selection criterion to traverse and confirm all sub-resources that need to be created. Subsequently, by calling the API server, application instances of these sub-resources are created sequentially or concurrently.

[0057] It's important to note that the creation operation here refers to the initial state of the resource reconciliation process in a broad sense. In actual execution, the system submits a list of sub-resources tagged with application tags to the API server. The API server then drives the cluster's actual state to match the expected state based on the list. For non-existent sub-resources, application instances are created; for existing resources with misconfigurations, their configuration data is updated. All successfully created sub-resources carry a unified application tag, allowing them to be perceived and managed by the system as a logical whole—the target application.

[0058] In one embodiment, when the application request entered by the user is an application update request, the process is as follows: Receive an application update request from a user for a target application, and obtain the desired state of the target application based on the application update request.

[0059] The controller receives application update requests from users for target applications. These requests typically include a new declarative configuration file. The controller parses the application update request to obtain the desired state of the target application after the update.

[0060] Obtain the resource difference between the desired state of the target application and the actual state of the target application.

[0061] The controller obtains the actual state of the target application in the cluster. The controller queries the application tags of the target application through a selector to filter out all sub-resources currently associated with the current application. The current configuration set of these sub-resources constitutes the actual state.

[0062] The controller then performs a differential comparison between the parsed expected state and the queried actual state. This differential comparison is performed on a resource-by-resource basis, aiming to accurately identify sub-resources that need to be created, modified, or deleted, thereby obtaining a detailed resource discrepancy report.

[0063] Based on the resource differences, a set of sub-resource differences is obtained. The corresponding sub-resources are updated based on the set of sub-resource differences, and the resource ownership relationship is updated.

[0064] Based on the resource differences, the controller precisely calculates the set of sub-resource differences that require operation. The set of sub-resource differences specifically includes: New sub-resources: Resources that exist in the expected state but do not exist in the actual state.

[0065] Modified sub-resources: Resources that exist in both the expected and actual states, but whose configuration specifications (such as container image version, environment variables, number of replicas, etc.) have changed.

[0066] Deprecated sub-resources: Resources that exist in the actual state but have been deleted in the expected state.

[0067] Based on the set of differences among sub-resources, the system calls the API server to create, update, or delete the corresponding sub-resources, driving the cluster state to converge towards the desired state. During this process, the system ensures that a unified application tag is added to all newly added sub-resources, and that the original application tags are maintained for all changed sub-resources. At the same time, the application tags in removed sub-resources are also removed, thereby dynamically updating and maintaining accurate resource ownership relationships.

[0068] In one embodiment, when the application request entered by the user is an application update request, the process is as follows: Receive a user's application deletion request for a target application, obtain the sub-resources associated with the target application based on the application tag of the target application, and delete the corresponding sub-resources.

[0069] The system receives an application deletion request from a user targeting a specific application. Based on the application tag of the target application, the system queries the API server to accurately retrieve all sub-resources in the current cluster associated with the application tag of the target application. This mechanism ensures the integrity and accuracy of the deletion operation, effectively avoiding resource residues or accidental deletions that may result from manual management.

[0070] Subsequently, the controller iterates through the associated sub-resources and calls the API server to delete all associated sub-resources in turn. This deletion operation is cascading; for derived resources such as Pods managed by controllers such as deployment and stateful collections, they will be cleaned up together according to their defined deletion policies.

[0071] The above details the implementation process of executing application creation, update, and deletion requests. The API server executes various application request operations and sends a success response to the controller upon completion. Upon receiving the response, the controller detects the application change and automatically generates a corresponding version snapshot. The mechanism for automatically generating version snapshots will be explained in detail below.

[0072] In one embodiment, whenever the application changes, a version snapshot of the application is generated, and a unique application version number is generated for each version snapshot based on preset rules.

[0073] like Figure 4 As shown, in this embodiment, after successfully executing the operations of creating, updating, or deleting all sub-resources within the cluster, the controller detects an application change and triggers the version snapshot mechanism. The controller automatically records and saves the complete configuration definition of all sub-resources under the changed target application, generating a version snapshot of the target application. Based on the system's preset version number update rules, the controller generates a unique application historical version number for each newly generated version snapshot. According to the generated version snapshot, historical version resources are created on the K8S cluster and stored in etcd within the K8S cluster.

[0074] In a preferred embodiment, the system increments the current application's historical version number using an incremental rule to obtain the next version number.

[0075] When the number of application version numbers corresponding to an application exceeds the limit, delete the earlier generated version snapshots.

[0076] In this embodiment, the historical version resources saved by the system for the application are not accumulated indefinitely. To prevent unlimited growth of storage space, and based on the general understanding that more recent historical versions are more important in most business scenarios, the system introduces an automated version retention and cleanup strategy. The quantity limit can be determined according to the actual situation and is not specifically limited here.

[0077] The system has a preset upper limit on the number of historical versions of an application (for example, the default upper limit is 6). Whenever a new version snapshot is successfully generated and an application version number is assigned to it, the system immediately checks the total number of historical version resources associated with the target application.

[0078] Once the system detects that the total number of current application historical versions exceeds the preset limit, it will automatically trigger a cleanup process. The system sorts all application historical versions in ascending order according to the generation order of the application version numbers (in embodiments using an incremental rule, the numerical value of the version number represents the order of generation), thereby determining the relationship between the old and new versions.

[0079] The system calculates the number of old versions that need to be deleted. For example, if there are currently 7 versions and the maximum is 6, then the oldest version needs to be deleted. The system performs the deletion operation sequentially, starting with the oldest (or several) version snapshots, according to the sorting results. The old version snapshot data is deleted from etcd, which stores historical version resources. In the Kubernetes cluster, the corresponding application historical version resource custom objects are deleted to maintain the cleanliness and consistency of the resource list.

[0080] After completing the above operations, the controller receives a response indicating that the target application has been successfully changed, and finally the controller returns the changed target application to the user.

[0081] In this embodiment, the mechanism of automatically generating version snapshots is to achieve more efficient version management. Users can roll back to the desired target application based on the corresponding application version number, ensuring the integrity and consistency of the rollback operation. The version rollback process is as follows: Figure 5 As shown below, the implementation process of version rollback will be explained in detail.

[0082] The controller receives the rollback request from the application and obtains the corresponding snapshot of the version to be rolled back based on the application version number specified in the rollback request.

[0083] The controller receives an application rollback request submitted by the user. The application rollback request is a declarative configuration file, and its core parameter is an application version number. The controller first performs security and validity checks on the application rollback request, ensuring that the target application specified in the request exists and that the specified application version number is genuinely available in the application's historical version records.

[0084] After successful verification, the system uses the application version number as a unique index key to retrieve the corresponding snapshot of the version to be rolled back from etcd.

[0085] It's important to explain in detail that a version snapshot is not simply a version number label, but a structured data archive. It completely and accurately records the full configuration definitions of all sub-resources that constitute the target application at that historical point in time.

[0086] Obtain the rollback configuration data from the rollback version snapshot, construct an application update request based on the difference between the rollback configuration data and the application's current configuration data, and execute the application update request logic to achieve rollback.

[0087] The system extracts all historical version resources of the target application from the retrieved snapshots of the versions to be rolled back. Based on the obtained historical version resources, it retrieves the corresponding custom resource objects through the API server and converts them into specific application historical resource types, which contain the rollback configuration data required to roll back to the target application.

[0088] The controller parses the rollback configuration data in the snapshot of the version to be rolled back, iterates through all sub-resources associated with the target application based on the application tag, and constructs an application update request.

[0089] This constructed application update request is logically equivalent to the user manually submitting a completely new application configuration request, hoping to restore a previous version of the application. The system submits the application update request to the API server and executes the application update request logic according to the process described above.

[0090] Upon receiving this update request, the API server's built-in reconciliation loop begins to work, driving the actual state of the entire cluster to converge towards the desired state defined by the snapshot to be rolled back. This ultimately ensures that the overall state of the target application is completely consistent with the specified historical application version, thus achieving precise and automated application rollback.

[0091] The above content details the complete automated process of application rollback. The entire process begins with the controller receiving a rollback request containing a specific application version number. After the rollback request is submitted to the API server, it triggers its built-in reconciliation loop. Through comparison and driving, the system ultimately converges the actual state of the cluster to the expected state defined by the version snapshot, thereby achieving precise and automated version rollback.

[0092] In existing technologies, when an application needs to be temporarily stopped, the replica count configuration of each resource must be manually recorded and adjusted. Restarting is cumbersome and error-prone. This embodiment provides an intelligent, state-preserving application start-up and shutdown management mechanism. This mechanism solves the technical problem of temporarily pausing applications on a container orchestration platform to save resources and quickly and accurately restoring the application to its original running state when needed. Traditional manual start-up and shutdown operations are cumbersome and error-prone, especially for complex applications composed of multiple microservices, where it is difficult to record and restore the precise original state of each component. This solution achieves secure and reliable one-click start-up and shutdown through automated processes and state preservation technology. The one-click start-up and shutdown process is as follows: Figure 6 As shown below, the implementation process will be described in detail.

[0093] Step 1101: When a user's stop command for the application is received, all sub-resources associated with the application are traversed through the application tag.

[0094] like Figure 7 As shown, the controller receives a stop command from the user for the target application. The controller uses the application tag of the target application to query sub-resources, sends a request to the API server, and iterates through and retrieves all sub-resources associated with the application tag.

[0095] Step 1102: Store the current number of replicas of the sub-resources in the form of annotations in their respective resource objects.

[0096] For each sub-resource obtained in step 1101, the system reads the current replica count configuration of the sub-resource. The system stores this key runtime status information (mainly the replica count) as key-value pairs as annotations in the metadata of the current sub-resource object.

[0097] Step 1103: Set the replica digital field of the sub-resource to zero to stop its operation.

[0098] After successfully saving the original state, the system begins the shutdown process. The controller iterates through all sub-resources and sets the replica count field of each sub-resource to 0. Once this operation is submitted to the API server, the cluster's reconciliation loop responds immediately. For the workload controller, it detects that the expected replica count has become 0 and then begins terminating all running Pod instances.

[0099] Ultimately, all business Pods of the application will be terminated, ceasing to consume CPU and memory resources, thus achieving the effect of stopping operation. However, the critical runtime information of all sub-resource objects will still be completely retained in the cluster.

[0100] Step 1104: When a user's launch command for the application is received, the sub-resources associated with the application are traversed again through the application tag.

[0101] In this embodiment, when the controller receives a user's launch command for the same target application, it repeats the logic of step 1101, again traversing and retrieving all associated sub-resources through the application tag. This ensures that even if the cluster state changes during application downtime, the set of target sub-resources that need to be restored can be accurately located.

[0102] Step 1105: Obtain the number of replicas before stopping from the annotations of the resource objects corresponding to each sub-resource, and restore the number of replicas of each sub-resource to the number of replicas before stopping.

[0103] For each found sub-resource, the system performs the core recovery operation. It retrieves the previously stored original copy value from the sub-resource object's annotations and resets the saved copy value to the sub-resource's copy number field.

[0104] Once this operation is submitted, the controller will detect the change in the desired state again and immediately begin scheduling and starting the corresponding number of new Pod instances, thereby restoring the application to its previous running scale.

[0105] Step 1106: After each sub-resource starts successfully, clean up the temporarily saved annotation information and return a status response indicating that the application has started successfully.

[0106] The system monitors the startup process of each sub-resource, waiting for its Pod instances to successfully enter the running state. After confirming that the application as a whole has started successfully, the system performs a cleanup operation. This deletes the annotation information previously created on each sub-resource object to temporarily store the replica count. This cleanup operation is performed to keep the sub-resource objects clean and avoid the accumulation of metadata. Finally, the system returns a status response indicating that the application has started successfully to the user, completing the entire start-up and shutdown cycle.

[0107] The application start / stop management mechanism provided in this embodiment simplifies the complex multi-resource start / stop process into a one-click operation, greatly improving user experience and operational efficiency. It uses annotations to losslessly preserve the precise running state of the application, avoiding errors or omissions that may occur with manual recording, and ensuring that the application is completely consistent with its state before stopping each time it starts. During the stop period, computing resource consumption is reduced to almost zero, which helps to optimize costs.

[0108] The embodiments of this invention bring significant comprehensive benefits through automated version management, version rollback, and unified application resources: each application change instantly generates a version snapshot without manual intervention, eliminating errors from manual recording and greatly improving operational efficiency; once a historical application version needs to be rolled back, it can be restored with one click based on the complete version snapshot, solving the partial failures and state inconsistencies caused by traditional resource rollback, and ensuring business continuity; at the same time, multiple resources are abstracted into a single resource, greatly simplifying complex operations, significantly reducing the threshold for use and management complexity, and achieving efficient, reliable, and easy-to-maintain full lifecycle management.

[0109] Example 2: This embodiment provides a container application management system, which includes two main parts: a management cluster and a service cluster. The management cluster includes a controller and a proxy module, responsible for receiving and processing user requests; the service cluster consists of at least one API server, used to perform specific resource operations. Figure 2 , Figure 4 , Figure 5 and Figure 7 As shown, the various implementation steps in Example 1 are carried out in coordination through the above-mentioned system.

[0110] Table 1 provides an explanation of various relevant terms in the Kubernetes system.

[0111] Table 1 provides explanations of various related terms in the Kubernetes system. In one embodiment, the controller, as the core control unit of the system, receives application requests submitted by users for a target application, parses and schedules these requests, and determines the corresponding sub-resources that need to be operated on. The controller interacts with the API server through a proxy module, transforming user requests into specific operation instructions for the Kubernetes cluster, thereby driving the API server to perform creation, deletion, or update operations on the sub-resources. The container application management system comprises three core components that work together to achieve complete application management functionality: Application Definition (CRD), Application History Definition (CRD), and Controller.

[0112] Application Definition (CRD): Defines a unified application resource model, providing fundamental support for the entire application lifecycle management. This CRD is implemented based on Kubernetes' extension mechanism, supporting complete management functions including one-click start / stop and status monitoring. The application definition specification adopts the standard Kubernetes CRD structure, and its core fields are shown in Table 2.

[0113] Table 2 Top-level fields defined by the application

[0114] The core fields defined in the application include: metadata, specifications, and status. The specification field describes the expected state of the application, including the number of replicas, image version, and resource configuration. The status field records the current actual state of the object, facilitating user monitoring of application operation.

[0115] In one embodiment, the metadata primarily defines the application version and annotations, with key field definitions shown in Table 3. The specification fields are mainly used to define which resources the application includes, as shown in Table 4.

[0116] Table 3 Metadata Field Definitions

[0117] Table 4 Definition of Canonical Fields

[0118] Application History CRD: Defines a unified resource for application history versions, providing support for application version control and rollback functionality. This CRD maintains the same top-level fields as the Application CRD, with its core definition located in the specification section. It fully stores a snapshot of the application and its related components at a specific point in time, including a complete history of application configuration, version association information for each component, and metadata required for version rollback.

[0119] Table 5 illustrates the definitions of each field defined in the historical version of the application.

[0120] Table 5 Field definitions for application history versions

[0121] The Archon Controller (or simply Controller) acts as the system's execution engine, responsible for implementing application lifecycle management and version control. The Controller continuously monitors the cluster status to ensure the actual application state matches the expected state, and automatically performs corrective actions when deviations are detected. Simultaneously, the Controller manages application version history, supporting users in version queries and rollback operations.

[0122] Through the orderly collaboration of the above components, this system has jointly implemented the various implementation steps described in Example 1, and completed the fully automated management of the entire process from application deployment and operation monitoring to version management, providing users with a complete and reliable container application management solution.

[0123] Example 3: like Figure 8 The diagram shown is an architectural schematic of a controller for container application management according to an embodiment of the present invention. The controller in this embodiment includes one or more processors 21 and a memory 22. Figure 8 Take a processor 21 as an example.

[0124] Processor 21 and memory 22 can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0125] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the container application management method and system in Embodiments 1 and 2. The processor 21 executes the container application management method by running the non-volatile software programs and instructions stored in the memory 22.

[0126] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0127] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they execute a container application management method and system as described in Embodiments 1 and 2 above, for example, executing the above-described... Figure 1 , Figure 3 and Figure 6 The steps shown.

[0128] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0129] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0130] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A container application management method characterized by comprising: The method comprises the following steps: receiving an application request of a target application from a user, determining corresponding sub-resources according to the application request; adding application labels to the sub-resources involved in the target application to update the resource ownership relationship; performing operations of creating, deleting or updating the sub-resources according to the application request; generating a version snapshot of the target application, storing the version snapshot as a historical version resource of the target application, and rolling back according to the version snapshot.

2. The container application management method according to claim 1, wherein The application request is an application creation request, and the method further comprises: parsing the application creation request to obtain configuration data, and determining a resource object according to the configuration data; determining sub-resources to be created in sequence according to the resource object, adding application labels associated with the target application to the sub-resources, and establishing a resource ownership relationship between the sub-resources and the target application; traversing the sub-resources associated with the target application according to the application labels, and creating corresponding sub-resources.

3. The container application management method according to claim 1, wherein The application request is an application update request, and the method further comprises: receiving an application update request of a target application from a user, obtaining an expected state of the target application according to the application update request; obtaining resource differences between the expected state of the target application and an actual state of the target application; obtaining a sub-resource difference set according to the resource differences, updating corresponding sub-resources according to the sub-resource difference set, and updating the resource ownership relationship.

4. The container application management method according to Claim 1, wherein The application request is an application deletion request, and the method further comprises: receiving an application deletion request of a target application from a user, obtaining sub-resources associated with the target application according to application labels of the target application, and deleting corresponding sub-resources.

5. The container application management method according to Claim 1, wherein The method further comprises: generating a version snapshot of the application whenever the application changes, and generating a unique application version number for each version snapshot based on a preset rule; when the application version number corresponding to the application exceeds the number limit, deleting the version snapshot generated earlier.

6. The container application management method according to claim 5, wherein The method further comprises: receiving a rollback request of the application, and obtaining a to-be-rolled-back version snapshot corresponding to an application version number specified in the rollback request; obtaining to-be-rolled-back configuration data from the to-be-rolled-back version snapshot, constructing an application update request according to the difference between the to-be-rolled-back configuration data and the current configuration data of the application, executing the logic of the application update request to realize rollback.

7. The container application management method according to any one of claims 1 to 6, characterized by, The method further comprises: when receiving a stop instruction of the application from a user, traversing all sub-resources associated with the application through the application labels; storing the current number of copies of the sub-resources in the form of annotations in their respective resource objects; setting the copy number field of the sub-resources to zero to stop running; when receiving a start instruction of the application from a user, traversing the sub-resources associated with the application through the application labels again; obtaining the number of copies before stopping from the annotations of the resource objects corresponding to each sub-resource, and restoring the copy number field of each sub-resource to the number of copies before stopping; after the start of each sub-resource is successful, cleaning up the temporarily saved annotation information, and returning a state response that the application starts successfully.

8. The container application management method according to any one of claims 1 to 6, characterized by, The application tag includes one or more of an application name, a resource type, a component type, and a component name.

9. A controller for container application management, characterized by, Comprise: At least one processor; And a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for executing the container application management method of any one of claims 1-8.

10. A container application management system characterized by comprising: The container application management system comprises a management and control cluster composed of the controller and the agent module as claimed in claim 9 and a business cluster composed of at least one API server; The controller is configured to receive an application request of a target application from a user, determine corresponding sub-resources according to the application request; The controller interacts with the API server through the agent module to enable the API server to perform operations of creating, deleting, or updating the sub-resources according to the application request.

Images