Cloud native application management method and management system and storage medium

Abstract

The invention provides a cloud native application management method and system and a storage medium, and the method comprises the steps: managing a target cloud native application, and obtaining an intermediate application state of the target cloud native application when the management is successful; performing user-defined resource ready check according to the intermediate application state; determining the final application state of the target cloud native application according to the check result; and performing operation and maintenance management on the target cloud native application according to the final application state. According to the mode, the precondition of resource ready check is customized in the management process of the cloud native application, and the life cycle management of the cloud native application is linked with the resource state of the cloud native application, so that the cloud native application has various management capabilities, and the expansion of the state of the cloud native application is realized.

Description

Technical Field

[0001] This application relates to the field of electronic circuits, and specifically to a management method, a management system, and a storage medium for cloud-native applications. Background Art

[0002] The Kubernetes (abbreviated as K8s) platform is a product-level container orchestration platform, and Helm is a technical framework based on K8s for package management of resource configuration files; cloud-native applications run on K8s and uniformly manage a class of resources through Helm or a few configuration management frameworks to form a complete application that can provide specific business scenarios externally, and it has the characteristics of life-cycle management; cloud-native application resources are descriptions of resources with a single business attribute in cloud-native applications, and they have state characteristics at a certain point in time. The existing management methods for cloud-native applications fail to achieve fine-grained management of the life cycle of user-defined resources, and the application life-cycle management and resource status monitoring are two relatively independent processes, lacking linkage between them. The resource status monitoring dimension stays at data collection and does not combine the resource status for application life-cycle management. Summary of the Invention

[0003] To solve the above problems, this application provides a management method, a management system, and a storage medium for cloud-native applications, which can link the life-cycle management of cloud-native applications with the status of cloud-native application resources in combination with the ready conditions of custom resources, so as to realize the expansion of cloud-native applications.

[0004] One technical solution adopted by this application is: to provide a management method for cloud-native applications, the method includes: managing a target cloud-native application, and when the management is successful, obtaining the intermediate application status of the target cloud-native application; performing a ready check for custom resources according to the intermediate application status; determining the final application status of the target cloud-native application according to the check result; and performing operation and maintenance management on the target cloud-native application according to the final application status.

[0005] In one embodiment, performing a ready check for custom resources according to the intermediate application status includes: obtaining the preconditions for the ready check for custom resources according to the intermediate application status; wherein, the preconditions are obtained through advance customization; in response to at least some resources involving the configuration parameters in the preconditions, parsing and running the preconditions to perform the ready check for custom resources.

[0006] In one embodiment, parsing and running the preconditions to perform the ready check for custom resources includes: determining the type of the preconditions according to the configuration parameters; obtaining the running result of the preconditions according to the type of the preconditions to determine the status of the resources.

[0007] In one embodiment, obtaining the operation result of the precondition according to the type of the precondition to determine the status of the resource includes: obtaining the identification information of the resource according to the type of the precondition; and performing a status evaluation on the resource according to the identification information to determine the status of the resource.

[0008] In one embodiment, obtaining the operation result of the precondition according to the type of the precondition to determine the status of the resource further includes: sending a request to the server where the resource is located according to the type of the precondition; obtaining the response time of each request; in response to the response time not exceeding a preset time threshold, retrying the failed request; and determining the status of the resource according to the retry result.

[0009] In one embodiment, after obtaining the precondition for the custom resource readiness check according to the intermediate application status, it further includes: performing a basic check on the precondition; in response to the precondition failing the basic check, performing operation and maintenance management on the target cloud-native application according to the final application status, and updating and reporting the management result.

[0010] In one embodiment, after determining the final application status of the target cloud-native application according to the check result, it further includes: when the check result indicates that the target cloud-native application is not ready and the unready time exceeds a preset threshold, performing operation and maintenance management on the target cloud-native application according to the final application status, and updating and reporting the management result.

[0011] In one embodiment, the method further includes: when the number of unreadiness conditions of the target cloud-native application exceeds a preset value, offloading the custom resource readiness check task to a new resource for execution, and performing the custom resource readiness check through a cache reporting mechanism.

[0012] In one embodiment, determining the final application status of the target cloud-native application according to the check result includes: in response to the status evaluation result indicating success, determining the final application status of the target cloud-native application as ready; in response to the status evaluation result indicating failure, determining the final application status of the target cloud-native application as not ready.

[0013] In one embodiment, determining the final application status of the target cloud-native application according to the check result further includes: in response to the retry result indicating that a response code is obtained from the server within a preset number of retries, determining the final application status of the target cloud-native application as healthy; in response to the retry result indicating that a response code cannot be obtained from the server after the preset number of retries, determining the final application status of the target cloud-native application as unhealthy.

[0014] The present application also provides a management system for cloud-native applications. The management system includes a processor and a memory. The memory is used to store program data, and the processor is used to execute the program data to implement the management method for cloud-native applications as described above.

[0015] The present application also provides a computer-readable storage medium, in which program data is stored. When the program data is executed by a processor, it is used to implement the management method of the cloud-native application as described above.

[0016] One technical solution adopted by the present application is: providing a management method for a cloud-native application, the method including: managing a target cloud-native application, and when the management is successful, obtaining the intermediate application state of the target cloud-native application; performing a custom resource readiness check according to the intermediate application state; determining the final application state of the target cloud-native application according to the check result; and performing operation and maintenance management on the target cloud-native application according to the final application state. By the above method, by customizing the preconditions for the resource readiness check during the management of the cloud-native application, the life cycle management of the cloud-native application is linked with the resource state of the cloud-native application, so that the cloud-native application has diverse management capabilities and realizes the expansion of the cloud-native application state. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0018] Among them:

[0019] Figure 1 is the first flowchart of the management method of the cloud-native application provided by some embodiments of the present application;

[0020] Figure 2 is provided by some embodiments of the present application Figure 1 is the sub-flowchart of step S12;

[0021] Figure 3 is provided by some embodiments of the present application Figure 2 is the sub-flowchart of step S122;

[0022] Figure 4 is provided by some embodiments of the present application Figure 3 is the sub-flowchart of step S1222;

[0023] Figure 5 is provided by some embodiments of the present application Figure 3 is the sub-flowchart of step S1222;

[0024] Figure 6 is provided by some embodiments of the present application Figure 1 is the sub-flowchart of step S13;

[0025] Figure 7 is the sub - process schematic diagram of step S13 provided by some embodiments of the present application Figure 1 in the method for managing cloud - native applications provided by some embodiments of the present application

[0026] Figure 8 is the second process schematic diagram of the method for managing cloud - native applications provided by some embodiments of the present application

[0027] Figure 9 is the structural schematic diagram of the management system of cloud - native applications provided by some embodiments of the present application

[0028] Figure 10 is the structural schematic diagram of the computer - readable storage medium provided by some embodiments of the present application Detailed implementation manners

[0029] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. Additionally, it should be noted that for the sake of description, only the parts related to the present application rather than all the structures are shown in the accompanying drawings. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application

[0030] The terms "first", "second", etc. in the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non - exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices

[0031] Referring to "embodiments" herein means that the specific features, structures or characteristics described in conjunction with the embodiments can be included in at least one embodiment of the present application. The phrase appears at various positions in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments

[0032] Cloud-native applications have the characteristics of lifecycle management, mainly involving actions such as deployment, upgrade, and deletion. Some have certain status description characteristics, mainly presenting ready and not ready. The ready state indicates that the cloud-native application or application component is ready to accept the workload, while the not ready state indicates that the cloud-native application or application component does not yet have the operating conditions.

[0033] As a package management tool for K8s, Helm greatly simplifies operations such as the deployment, upgrade, and rollback of cloud-native applications. However, traditional Helm management mainly focuses on the deployment configuration of applications and the basic management of their lifecycles, such as installation, upgrade, uninstallation, etc., while the specific state monitoring and processing during the runtime of cloud-native applications are relatively limited. To make up for this deficiency, this application provides a custom Helm application controller, which can not only perform basic Helm operations, but also introduce new state processing logic on the basis of the two basic states of the original cloud-native application being not ready and ready, and conduct more in-depth state management and processing of the actual state of cloud-native applications.

[0034] Refer to Figure 1 , Figure 1 Figure 10 is a schematic diagram of the first process of the management method of cloud-native applications provided by some embodiments of this application. The method includes:

[0035] Step S11: Manage the target cloud-native application, and when the management is successful, obtain the intermediate application state of the target cloud-native application.

[0036] Among them, before managing the target cloud-native application, prerequisite tasks need to be executed. These prerequisite tasks allow users to execute some custom scripts or commands before the actual execution stage of Helm operations to perform some necessary preparatory work. Managing the target cloud-native application can be to manage the non-dependent conditional resources of the cloud-native application. Non-dependent conditional resources refer to resources that can be used and managed by cloud-native applications without depending on specific hardware, operating systems, network environments, or other external conditions, such as cloud-native storage, network resources, etc. If the management of the non-dependent conditional resources of the cloud-native application is successful, a custom resource readiness check is performed; if problems such as resources cannot be correctly loaded or initialized, or resource access exceptions occur, it indicates that the management fails and the cloud-native application is unhealthy, and situations such as the cloud-native application cannot be correctly started or runs abnormally may occur.

[0037] Step S12: Perform a custom resource readiness check according to the intermediate application state.

[0038] Among them, the intermediate application state is a transitional state between unready and ready, which is an extension of the cloud-native application state, indicating that the cloud-native application is transitioning to the fully ready state but has not yet met all the ready conditions. Cloud-native applications typically rely on a series of external and internal resources to ensure their normal operation. These dependent resources may include databases, internal components, automation, and orchestration tools, etc. In the intermediate application state, it is necessary to combine the judgment logic of custom resource readiness detection to check the status of the cloud-native application's dependent resources.

[0039] Please refer to Figure 2 , the above step S12 may include the following steps:

[0040] Step S121: Obtain the preconditions for custom resource readiness check according to the intermediate application state; among them, the preconditions are obtained through advanced customization.

[0041] Among them, the readiness status of the cloud-native application's dependent resources is the key to ensuring the stable operation of the cloud-native application. Only when these dependent resources are all ready and in an available state can the cloud-native application run normally. When the state of the target cloud-native application is the intermediate application state, dynamically obtain the preconditions for custom resource readiness check, so as to determine the status of the cloud-native application's dependent resources.

[0042] Among them, as an automation and orchestration tool for cloud-native applications, K8s has a variety of resource objects. For example, it can provide Services resources with load balancing and service discovery functions, Deployments resources for managing the deployment and update of stateless applications, etc. K8s resource objects are usually defined through manifest files in YAML or JSON format. These files contain information such as the specification (Spec) and status (Status) of the resource objects. The specification information describes the expected state of the resource object, while the status information reflects the health status, running status, availability, and other important metrics of the resource object. Therefore, determining the status of K8s resource objects is an important step in custom resource readiness check.

[0043] Specifically, the preconditions can be represented in the form of custom K8s annotations to implement the custom resource readiness check logic. The value of this annotation may be a string in JSON, YAML, or other formats, containing detailed configuration parameters of the preconditions, defining the circumstances under which the resource is considered ready. In K8s, annotations are key-value pairs attached to resource objects (such as Pods, Deployments, Services, etc.), providing non-identifying metadata about these resources for storing additional information that can be read and processed by K8s itself, third-party tools, or applications at runtime.

[0044] Step S122: In response to at least some resources involving configuration parameters in the preconditions, parse and run the preconditions to perform a custom resource readiness check.

[0045] When performing a custom resource readiness check, for K8s resources (such as Pods, Deployments, etc.), it is necessary to check the annotation fields in their metadata to see if there are custom annotations. If some resources are involved, parse the annotation and, according to the configuration parameters of the parsed preconditions, execute the corresponding logic to perform a custom resource readiness check.

[0046] Please refer to Figure 3 , the above step S122 may include the following steps:

[0047] Step S1221: Determine the type of the precondition based on the configuration parameters.

[0048] Among them, the configuration parameters contain fields representing the type of the precondition and fields describing the precondition. After parsing the precondition, the fields containing the type of the precondition in the annotation can be obtained, so as to execute the corresponding description fields according to different types to determine the status of the resource. In one embodiment, the types of the preconditions include checking the status of K8s resource objects and performing a custom health check on K8s resource objects.

[0049] In one application scenario, the precondition is represented by a compressed JSON string. The field "type" represents the type of the precondition, and the field "dependencies" represents the detailed precondition description. After parsing the JSON string to obtain the field "type": "gvk", the gvk type of the precondition is defined as checking the status of K8s resource objects. In another application scenario, after parsing the JSON string to obtain the field "type": "httpGet", the httpGet type of the precondition is defined as performing a custom health check on K8s resource objects.

[0050] Step S1222: Obtain the running result of the precondition according to the type of the precondition to determine the status of the resource.

[0051] Among them, different types of preconditions have different resource readiness check logics. For example, when checking the status of K8s resource objects, steps S12221 and S12222 are executed. When performing a custom health check on K8s resource objects, steps S12223 to S12226 are executed.

[0052] Refer to Figure 4 , the above step S1222 may include the following steps:

[0053] Step S12221: Obtain the identification information of the resource according to the type of the precondition.

[0054] Among them, to check the status of the K8s resource object, it is necessary to evaluate the performance and status of the resource object in a specific namespace in K8s. Specifically, first, it is necessary to obtain the identification information included in the configuration parameters. The identification information is located in the description field of the precondition, including but not limited to the task name, namespace, API version, resource type, and achievement condition, etc. These identification signals constitute the basic identity and classification information of the resource object. The resource object in the cluster can be uniquely identified and located through the task name and namespace; the compatibility between the resource definition and the API version is ensured through the API version, thus avoiding problems caused by version mismatch; different types of resource objects are distinguished through the resource type, and corresponding operations and processing logics are executed according to the type; the resource status is judged through the achievement condition.

[0055] Step S12222: Evaluate the status of the resource according to the identification information to determine the status of the resource.

[0056] In an application scenario, the precondition is represented by a compressed JSON string. Parsing the JSON string obtains the "type": "gvk" field and the "dependencies": [{"name": "my-service", "namespace": "test-namespace", "apiVersion": "v1", "kind": "Service", "success": ".status.succeed == 1"}] field, which means that the type of the precondition is to check the status of the K8s resource object. The dependencies contain the identification information. The above dependencies field means to evaluate the status of the service resource object named my-service in the test-namespace space and with the API version of v1, and determine that the status of the Service resource object is ready when the achievement condition satisfies that the succeed field is equal to 1.

[0057] Please refer to Figure 5 , the above step S1222 may further include the following steps:

[0058] Step S12223: Send a request to the server where the resource is located according to the type of the precondition.

[0059] Among them, a request is sent to the server where the resource is located to obtain the resource from the server. For example, a request is sent to the address described by the url through the GET method in the HTTP protocol. The url contains the address of the server where the resource is located and the specific location on the server. During the request process, the client will send a request message to the server. This message contains information such as the request method, the request url, the HTTP version, and some optional request headers. After receiving this request, the server will process and return a response message according to the content of the request. This message contains information such as the response status code, the response headers, and the response body.

[0060] Step S12224: Obtain the response time of each request.

[0061] Among them, after the request is sent, the response time of each request is obtained. The response time refers to the time interval from when the request is sent to when the server returns a response. It is an important indicator for measuring the server performance and the request processing efficiency.

[0062] Step S12225: In response to the response time not exceeding a preset time threshold, retry the failed request.

[0063] Among them, the preset time threshold is usually set according to the business requirements and the server performance. When the response time does not exceed the preset time threshold and the request is determined to be failed (for example, no expected response data is received), the system will retry the request according to the preset policy. The retry policy may include the number of retries, the retry interval, etc.

[0064] Step S12226: Determine the status of the resource based on the retry result.

[0065] Among them, after the retry mechanism is executed, the status of the resource is determined according to the retry result. When the retry result meets the custom conditions, the resource status is determined to be healthy; otherwise, it is unhealthy. The custom conditions can be set according to whether a response code is obtained within the number of retries, etc.

[0066] In an application scenario, the precondition is represented as a compressed JSON string. Parsing the JSON string yields the fields "type": "httpGet" and "dependencies": [{"url": "http: / / test-svc.test-namespace.svc.cluster.local:8080 / api / ", "httpHeaders": {"key-1": "value-1", "key-2": "value-2"}}, "periodSeconds": 30, "failureThreshold": 3, "timeoutSeconds": 10]. This indicates that the type of the precondition is to perform a custom health check on a K8s resource object. The above "dependencies" field means to send an httpGet request to the server address described by the url and pass in the key-value configuration in the httpHeaders as the request header information. If the response time for each request does not exceed 10 seconds, and after 3 failures (with a 30s interval between each failure) without a response code being returned, or if a response code has been obtained during the 3 retries, it is determined that the status of the K8s resource object is healthy.

[0067] Step S13: Determine the final application status of the target cloud-native application based on the inspection result.

[0068] In an embodiment, when checking the status of a K8s resource object, after performing the steps of obtaining the identification information of the resource according to the type of the precondition and evaluating the status of the resource based on the identification information to determine the status of the resource, steps S131 and S132 are executed according to the result of the resource status evaluation, and the ready status of the resource can be determined, thereby determining the final application status of the target cloud-native application. When performing a custom health check on a K8s resource object, after performing the steps of sending a request to the server where the resource is located according to the type of the precondition, obtaining the response time of each request, retrying the request failure in response to the response time not exceeding the preset time threshold, and determining the status of the resource based on the retry result, steps S133 and S134 are executed according to the retry result, and the health status of the resource can be determined, thereby determining the final application status of the target cloud-native application.

[0069] Please refer to Figure 6 , the above step S13 may further include the following steps:

[0070] Step S131: In response to the status evaluation result indicating success, determine that the final application status of the target cloud-native application is ready.

[0071] Step S132: In response to the status evaluation result being characterized as a failure, determine that the final application status of the target cloud-native application is not ready.

[0072] Among them, if the result of the status evaluation of the resource is characterized as successful, it is determined that the resource is in a ready state, and the final application status of the target cloud-native application is ready; otherwise, the resource is not ready, and the final application status of the target cloud-native application is not ready.

[0073] Please refer to Figure 7 , the above step S13 may further include the following steps:

[0074] Step S133: In response to the retry result being characterized as obtaining a response code from the server within the preset number of retries, determine that the final application status of the target cloud-native application is healthy.

[0075] Step S134: In response to the retry result being characterized as failing to obtain a response code from the server after the preset number of retries, determine that the final application status of the target cloud-native application is unhealthy.

[0076] Among them, if the retry result is characterized as obtaining a response code from the server within the preset number of retries, it is determined that the resource is in a healthy state, and the final application status of the target cloud-native application is healthy; otherwise, it is determined that the resource is in an unhealthy state, and the final application status of the target cloud-native application is unhealthy.

[0077] Step S14: Perform operation and maintenance management on the target cloud-native application according to the final application status.

[0078] Among them, the management of the cloud-native application is linked with the status of the cloud-native application resources. By determining the status of the cloud-native application resources, the final application status of the target cloud-native application is determined. Thus, after the cloud-native application resources are completely ready, the cloud-native application is further operated and maintained to implement operations such as resource repair, configuration adjustment, and application restart, so as to achieve the complete readiness of the cloud-native application, thereby improving application stability, optimizing resource utilization, and enhancing management efficiency.

[0079] In some embodiments, please refer to Figure 8 , after obtaining the preconditions for custom resource readiness check according to the intermediate application status, it further includes:

[0080] Step S81: Perform a basic check on the preconditions.

[0081] Among them, the basic check aims to ensure whether the request description or resource description in the preconditions is accurate, legal, and meets the requirements of K8s.

[0082] Step S82: In response to the preconditions failing the basic check, perform operation and maintenance management on the target cloud-native application according to the final application status, and update and report the management results.

[0083] Among them, if the basic check fails, for example, the resource type described in the preconditions does not match the internal definition in K8s, the request format is incorrect, or it contains illegal characters, etc., then the operation and maintenance management of the target cloud-native application will be directly performed according to the final application status, so as to avoid wasting the computing resources of the core controller, and an event will be generated at the application dimension. This event may include the operation and maintenance management results, the specific reasons for failing the basic check, etc. By reporting and updating these events, system administrators can monitor the situations that do not meet the basic check in real time and take corresponding measures to handle them, thereby improving the efficiency and stability of the system and facilitating problem tracking and management.

[0084] In some embodiments, after determining the final application status of the target cloud-native application according to the check results, it further includes: when the check results indicate that the target cloud-native application is not ready and the non-readiness time exceeds a preset threshold, perform operation and maintenance management on the target cloud-native application according to the final application status, and update and report the management results.

[0085] Among them, the preset threshold can be controlled by cluster parameters and can be adjusted as needed. When the non-readiness time exceeds the preset threshold set by default, it is determined that the relevant cloud-native application or service has an abnormality. The operation and maintenance management of the target cloud-native application will be directly performed according to the final application status. At the same time, an event resource will be generated at the application dimension. This event resource may include the operation and maintenance management results, detailed information about the non-readiness of the cloud-native application, such as the start time of non-readiness, the duration, and possible error information, etc. By reporting and updating these event resources, the status changes of the cloud-native application can be monitored in real time and corresponding measures can be taken to handle them, thereby improving the stability and reliability of the system, optimizing resource utilization, and enhancing the maintainability of the system.

[0086] In some embodiments, the management method of the cloud-native application further includes: when the number of non-readiness conditions of the target cloud-native application exceeds a preset value, unload the custom resource readiness check task to a new resource for execution, and perform the custom resource readiness check through a cache reporting mechanism.

[0087] Among them, the number of unready conditions is generally default and controlled by cluster parameters. When the number of unready conditions exceeds the preset value, it means that processing related tasks will bring too much computational load to the core controller. Therefore, a resource protection mechanism is started to offload the custom resource readiness check task to a new task resource for processing, and the preconditions for the custom resource readiness check are determined through the cache reporting mechanism to ensure that the precondition information for the custom resource readiness check can be obtained quickly without querying from the core controller every time, reducing the computational load of the core controller, effectively protecting the core controller resources, optimizing the overall business performance, and improving the scalability, stability, and reliability of the system.

[0088] One technical solution adopted in this application is: to provide a management method for cloud-native applications, the method includes: managing a target cloud-native application, and when the management is successful, obtaining the intermediate application state of the target cloud-native application; performing a custom resource readiness check based on the intermediate application state; determining the final application state of the target cloud-native application based on the check result; and performing operation and maintenance management on the target cloud-native application based on the final application state. In the above manner, by customizing the preconditions for the custom resource readiness check during the management process of cloud-native applications, the lifecycle management of cloud-native applications is linked with the resource state of cloud-native applications, so that cloud-native applications have diverse management capabilities and the expansion of the cloud-native application state is realized.

[0089] Refer to Figure 9 , Figure 9 is a schematic structural diagram of a management system for cloud-native applications provided in some embodiments of this application. The management system 100 includes a processor 91 and a memory 92. The memory 92 is used to store program data, and the processor 91 is used to execute the program data to implement the following management method for cloud-native applications:

[0090] Managing a target cloud-native application, and when the management is successful, obtaining the intermediate application state of the target cloud-native application; performing a custom resource readiness check based on the intermediate application state; determining the final application state of the target cloud-native application based on the check result; and performing operation and maintenance management on the target cloud-native application based on the final application state.

[0091] In one embodiment, the processor 91 is further configured to execute: obtaining the preconditions for the custom resource readiness check based on the intermediate application state; wherein, the preconditions are obtained by customizing in advance; in response to at least some resources being involved in the configuration parameters in the preconditions, parsing and running the preconditions to perform the custom resource readiness check.

[0092] In one embodiment, the processor 91 is further configured to execute: determining the type of the preconditions based on the configuration parameters; obtaining the operation result of the preconditions based on the type of the preconditions to determine the state of the resources.

[0093] In one embodiment, the processor 91 is further configured to execute: obtaining identification information of a resource according to the type of precondition; and performing a status evaluation on the resource according to the identification information to determine the status of the resource.

[0094] In one embodiment, the processor 91 is further configured to execute: sending a request to the server where the resource is located according to the type of precondition; obtaining the response time of each request; in response to the response time not exceeding a preset time threshold, retrying the failed request; and determining the status of the resource according to the retry result.

[0095] In one embodiment, the processor 91 is further configured to execute: performing a basic check on the precondition; in response to the precondition not passing the basic check, performing operation and maintenance management on the target cloud native application according to the final application status, and updating and reporting the management result.

[0096] In one embodiment, the processor 91 is further configured to execute: when the check result indicates that the target cloud native application is not ready and the unready time exceeds a preset threshold, performing operation and maintenance management on the target cloud native application according to the final application status, and updating and reporting the management result.

[0097] In one embodiment, the processor 91 is further configured to execute: when the number of unready conditions of the target cloud native application exceeds a preset value, offloading the custom resource readiness check task to a new resource for execution, and performing a custom resource readiness check through a cache reporting mechanism.

[0098] In one embodiment, the processor 91 is further configured to execute: in response to the status evaluation result indicating success, determining that the final application status of the target cloud native application is ready; in response to the status evaluation result indicating failure, determining that the final application status of the target cloud native application is not ready.

[0099] In one embodiment, the processor 91 is further configured to execute: in response to the retry result indicating that a response code is obtained from the server within a preset number of retries, determining that the final application status of the target cloud native application is healthy; in response to the retry result indicating that a response code cannot be obtained from the server after the preset number of retries, determining that the final application status of the target cloud native application is unhealthy.

[0100] Referring to Figure 10 , Figure 10 FIG. is a schematic structural diagram of a computer-readable storage medium provided in some embodiments of the present application. Program data 110 is stored in the computer-readable storage medium 1000, and when the program data 110 is executed by a processor, it is used to implement the following management method for cloud native applications:

[0101] Manage the target cloud-native application, and when the management is successful, obtain the intermediate application status of the target cloud-native application; perform a custom resource readiness check based on the intermediate application status; determine the final application status of the target cloud-native application based on the check result; perform operation and maintenance management on the target cloud-native application based on the final application status.

[0102] In one embodiment, when executed by a processor, the program data 110 is used to implement: obtain the preconditions for the custom resource readiness check based on the intermediate application status; wherein, the preconditions are obtained through advance customization; in response to at least some resources involving the configuration parameters in the preconditions, parse and run the preconditions to perform the custom resource readiness check.

[0103] In one embodiment, when executed by a processor, the program data 110 is used to implement: determine the type of the preconditions based on the configuration parameters; obtain the operation result of the preconditions based on the type of the preconditions to determine the status of the resources.

[0104] In one embodiment, when executed by a processor, the program data 110 is used to implement: obtain the identification information of the resources based on the type of the preconditions; perform a status assessment on the resources based on the identification information to determine the status of the resources.

[0105] In one embodiment, when executed by a processor, the program data 110 is used to implement: send a request to the server where the resources are located based on the type of the preconditions; obtain the response time of each request; in response to the response time not exceeding the preset time threshold, retry the request failure; determine the status of the resources based on the retry result.

[0106] In one embodiment, when executed by a processor, the program data 110 is used to implement: perform a basic check on the preconditions; in response to the preconditions not passing the basic check, perform operation and maintenance management on the target cloud-native application based on the final application status, and update and report the management result.

[0107] In one embodiment, when executed by a processor, the program data 110 is used to implement: when the check result indicates that the target cloud-native application is not ready and the unready time exceeds the preset threshold, perform operation and maintenance management on the target cloud-native application based on the final application status, and update and report the management result.

[0108] In one embodiment, when executed by a processor, the program data 110 is used to implement: when the number of unready conditions of the target cloud-native application exceeds the preset value, unload the custom resource readiness check task to a new resource for execution, and perform the custom resource readiness check through a cache reporting mechanism.

[0109] In one embodiment, when the program data 110 is executed by a processor, it is used to implement: in response to the state evaluation result being characterized as successful, determining that the final application state of the target cloud-native application is ready; in response to the state evaluation result being characterized as failed, determining that the final application state of the target cloud-native application is not ready.

[0110] In one embodiment, when the program data 110 is executed by a processor, it is used to implement: in response to the retry result being characterized as obtaining a response code from the server within a preset number of retries, determining that the final application state of the target cloud-native application is healthy; in response to the retry result being characterized as failing to obtain a response code from the server after the preset number of retries, determining that the final application state of the target cloud-native application is unhealthy.

[0111] In several implementation manners provided by the present application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation manners described above are merely illustrative. For example, the division of the modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0112] The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0113] In addition, each functional unit in various embodiments of the present application can be integrated in one processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0114] The above are only the implementation manners of the present application, and do not limit the patent scope of the present application accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A management method for cloud-native applications, characterized in that, The method includes: Managing a target cloud-native application, and when the management is successful, obtaining the intermediate application status of the target cloud-native application; Performing a custom resource readiness check based on the intermediate application status; Determining the final application status of the target cloud-native application based on the check result; Performing operation and maintenance management on the target cloud-native application based on the final application status.

2. The management method of the cloud-native application according to claim 1, characterized in that, The performing a custom resource readiness check based on the intermediate application status includes: Obtaining the preconditions for the custom resource readiness check based on the intermediate application status; wherein, the preconditions are obtained through advance customization; In response to at least some of the resources involving the configuration parameters in the preconditions, parsing and running the preconditions to perform the custom resource readiness check.

3. The management method of the cloud-native application according to claim 2, wherein, The parsing and running the preconditions to perform the custom resource readiness check includes: Determining the type of the preconditions based on the configuration parameters; Obtaining the running result of the preconditions based on the type of the preconditions to determine the status of the resources.

4. The management method of the cloud-native application according to claim 3, wherein The obtaining the running result of the preconditions based on the type of the preconditions to determine the status of the resources includes: Obtaining the identification information of the resources based on the type of the preconditions; Performing a status assessment on the resources based on the identification information to determine the status of the resources.

5. The management method of the cloud-native application according to claim 3, characterized in that, The obtaining the running result of the preconditions based on the type of the preconditions to determine the status of the resources further includes: Sending a request to the server where the resources are located based on the type of the preconditions; Obtaining the response time of each request; In response to the response time not exceeding a preset time threshold, retrying the request failure; Determining the status of the resources based on the retry result.

6. The management method of the cloud-native application according to claim 4, wherein, The determining the final application status of the target cloud-native application based on the check result includes: In response to the status assessment result indicating success, determining that the final application status of the target cloud-native application is ready; In response to the status assessment result indicating failure, determining that the final application status of the target cloud-native application is not ready.

7. The management method of the cloud-native application according to claim 5, characterized in that, The determining the final application status of the target cloud-native application based on the check result further includes: In response to the retry result indicating that a response code is obtained from the server within a preset number of retries, determining that the final application status of the target cloud-native application is healthy; In response to the retry result indicating that a response code cannot be obtained from the server after the preset number of retries, determining that the final application status of the target cloud-native application is unhealthy.

8. The management method of the cloud-native application according to claim 1, wherein The method further includes: When the number of unreadiness conditions of the target cloud-native application exceeds a preset value, offloading the custom resource readiness check task to a new resource for execution, and performing the custom resource readiness check through a cache reporting mechanism.

9. A management system for cloud-native applications, characterized in that, The system includes a processor and a memory, the memory is used for storing program data, and the processor is used for executing the program data to implement the management method of the cloud-native application according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, Program data is stored in the computer-readable storage medium, and when the program data is executed by a processor, it is used to implement the management method of the cloud-native application according to any one of claims 1-8.

Images