Method and device for starting and stopping cloud-native application

Abstract

The application provides a start-stop control method and device of a cloud-native application. The start-stop control method of the cloud-native application is applied to a cloud-native platform and includes the following steps: a communication link with a target cloud-native application is established; the application type of the target cloud-native application is determined according to a preset application running state object, wherein the preset application running state object includes resource start-stop expectation parameters and resource start-stop state parameters; a start-stop instruction for the target cloud-native application is received; and in response to the start-stop instruction, start-stop processing of the target cloud-native application is performed based on the application type and the preset application running state object. Through the method, start-stop management of a self-defined workload in a third-party application is realized through a preset application running state object.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud application, in particular to a start-stop control method of cloud native application. The present application also relates to a start-stop control device of cloud native application, a computing device and a computer readable storage medium. BACKGROUND

[0002] In a cloud native platform, application start-stop management is an important part of the application life cycle. A container cluster (such as Kubernetes) provides several built-in workload resources and several workload start-stop related methods. However, in the vast Kubernetes ecosystem, Kubernetes can also support third-party workload resources. By using custom resource definition (CRD), Kubernetes can complete the work that is not originally a core function of Kubernetes. When a third-party application connected to the cloud native platform uses CRD, the cloud native platform cannot effectively, quickly and conveniently control the start-stop of the third-party application. SUMMARY

[0003] Therefore, the present application provides a start-stop control method of cloud native application. The present application also relates to a start-stop control device of cloud native application, a computing device and a computer readable storage medium to solve the above problems in the prior art.

[0004] According to a first aspect of the present application, a start-stop control method of cloud native application is provided, applied to a cloud native platform, comprising:

[0005] establishing a communication link with a target cloud native application;

[0006] determining an application type of the target cloud native application according to a preset application running state object, wherein the preset application running state object includes resource start-stop expectation parameters and resource start-stop state parameters;

[0007] receiving a start-stop instruction for the target cloud native application;

[0008] in response to the start-stop instruction, performing start-stop processing of the target cloud native application based on the application type and the preset application running state object.

[0009] According to a second aspect of the present application, a start-stop control device of cloud native application is provided, applied to a cloud native platform, comprising:

[0010] a creating module configured to establish a communication link with a target cloud native application;

[0011] The determining module is configured to determine an application type of the target cloud-native application according to a preset application running state object, wherein the preset application running state object comprises a resource start-stop expectation parameter and a resource start-stop state parameter.

[0012] The receiving module is configured to receive a start-stop instruction for the target cloud-native application.

[0013] The control module is configured to perform start-stop processing on the target cloud-native application based on the application type and the preset application running state object in response to the start-stop instruction.

[0014] According to a third aspect of an embodiment of the present application, a computing device is provided, comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor executes the computer instructions to implement the steps of the start-stop control method of the cloud-native application.

[0015] According to a fourth aspect of an embodiment of the present application, a computer readable storage medium is provided, which stores computer instructions, wherein the computer instructions are executed by a processor to implement the steps of the start-stop control method of the cloud-native application.

[0016] The start-stop control method of the cloud-native application provided by the present application is applied to a cloud-native platform, comprising establishing a communication link with a target cloud-native application; determining an application type of the target cloud-native application according to a preset application running state object, wherein the preset application running state object comprises a resource start-stop expectation parameter and a resource start-stop state parameter; receiving a start-stop instruction for the target cloud-native application; and performing start-stop processing on the target cloud-native application based on the application type and the preset application running state object in response to the start-stop instruction.

[0017] An embodiment of the present application abstracts the elements required for resource start-stop, generates a preset application running state object, and performs start-stop processing on a third-party application according to whether the preset application running state object is deployed in the third-party application resource when the third-party application is interfaced, so that start-stop management of a custom workload in the third-party application can be completed with only a small amount of configuration or without configuration. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 is a start-stop control architecture diagram of a cloud-native application provided by an embodiment of the present application;

[0019] Figure 2 is a flowchart of a start-stop control method of a cloud-native application provided by an embodiment of the present application;

[0020] Figure 3is a processing flowchart of a start-stop control method of a cloud-native application applied to a first type of application provided by an embodiment of the present application;

[0021] Figure 4 is a processing flowchart of a start-stop control method of a cloud-native application applied to a second type of application provided by an embodiment of the present application;

[0022] Figure 5 is a structural schematic diagram of a start-stop control device of a cloud-native application provided by an embodiment of the present application;

[0023] Figure 6 is a structural block diagram of a computing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0024] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details, and it is understood that the present application is not limited to the embodiments described herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present application.

[0025] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of one or more embodiments of the present application. As used in one or more embodiments of the present application and the accompanying claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in one or more embodiments of the present application, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0026] It is to be understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. It is to be understood that the term "and / or" as used in one or more embodiments of the present application encompasses any and all possible combinations of one or more of the associated listed items, as well as the lack of any associated item. It is to be understood that although the terms first, second, etc. can be used herein to describe various information, but these

[0027] In a cloud native platform, application start-stop is an important part of the application life cycle, Kubernetes itself provides several built-in workload resources and corresponding workload start-stop methods. When using Kubernetes' own workload resources, resource start-stop can be implemented through Kubernetes. However, the resources in Kubernetes sometimes cannot meet the actual needs of users, and users will have their own resources. In the Kubernetes ecosystem, third-party workload resources can also be supported, that is, users develop custom resource definitions (CRD). Through the method of CRD, the structure and validity of resources such as Deployment and StatefulSet can be customized, thereby completing the functions not provided by Kubernetes. If the cloud native platform is deployed in Kubernetes and the third-party application connected uses CRD, the cloud native platform cannot effectively, quickly and conveniently control the start-stop of the third-party application.

[0028] Based on this, in the present application, a cloud native application start-stop control method is provided, and the present application also relates to a cloud native application start-stop control device, a computing device, and a computer readable storage medium, which are described in detail one by one in the following embodiments.

[0029] Figure 1 An application embodiment provides a cloud native application start-stop control architecture diagram, as shown in Figure 1 A cloud native platform, a third-party application 1 and a third-party application 2 are deployed in Kubernetes.

[0030] The cloud native platform is a distributed cloud based on distributed deployment and unified operation, and is a set of cloud technology product systems based on technologies such as containers, microservices and DevOps. The cloud native application is an application designed for the cloud. After using cloud native technology, developers do not need to consider the underlying technology implementation, and can fully utilize the elasticity and distributed advantages of the cloud platform to achieve rapid steps, on-demand scaling, uninterrupted delivery, etc.

[0031] Cloud native is a method of building and running applications, and cloud native platform is a platform for deploying and controlling applications. Cloud native is a combination of words, Cloud means that the application is located in the cloud rather than the traditional data center; Native means that the application considers the cloud environment from the design, and is designed for the cloud. It runs on the cloud in the best posture, fully utilizes and plays the elasticity and distributed advantages of the cloud platform.

[0032] Meanwhile, two third-party applications, third-party application 1 and third-party application 2, are deployed in the Kubernetes, and the two third-party applications add custom CRDs in the applications to realize their own functions. At present, the CRDs cannot be directly controlled in the cloud native platform deployed in the Kubernetes. The method provided in the application provides a start-stop control method for cloud native applications adding custom CRDs in a cloud native platform, and two elements, expected and finished, for controlling the start and stop of the applications are extracted. The expected field identifies the state expected by the third-party custom resource when the third-party custom resource is stopped. The finished field identifies whether the third-party custom resource has completed the expected state.

[0033] When the start-stop control of the third-party custom resource is implemented in the cloud native platform, there are two options: 1. When the third-party application is connected, the configuration of the start-stop definition of the third-party custom resource related to the cloud native platform is added; and 2. When the third-party provides a deployment package, the start-stop definition of the CRD is implemented in the deployment package, so that the third-party custom resource is deployed with the workload. In this way, the start-stop control of the third-party custom resource in the cloud native platform can be completed.

[0034] Taking the third-party application 1 as an example, the third-party application 1 is deployed in the Kubernetes, and the custom CRD1 is configured. When the cloud native platform is connected with the third-party application 1, the cloud native platform receives the start-stop definition of the third-party custom resource sent by the third-party application, that is, when the expected field is 1, the third-party custom resource is started, and when the expected field is 0, the third-party custom resource is stopped; and when the finished field is True, it indicates that the expected state is completed, and when the finished field is False, it indicates that the expected state is not completed. The cloud native platform creates a custom Running State Handler according to the start-stop definition, and the custom Running State Handler is used to control the custom CRD1. The start-stop rule of the CRD1 is set in the custom Running State Handler. In the actual application process, the user sends a start instruction of the CRD1 to the start-stop module of the cloud native platform. The start-stop module sets the expected field of the custom CRD1 in the custom Running State Handler to 1, indicating that the custom CRD1 is started, and monitors the finished field of the custom CRD1 in the third-party application. When the finished field is marked as True, it can be determined that the custom CRD1 in the third-party application 1 is started successfully.

[0035] Taking the third-party application 2 as an example, when the third-party application 2 makes a deployment package, according to the custom control rule provided by the cloud-native platform, the third-party application 2 pre-makes a custom Running State Handler corresponding to the custom CRD2 in the deployment package, the custom Running State Handler is deployed in the third-party application 2 and can be directly connected with the cloud-native platform, the user sends a stop instruction of the CRD2 to the start-stop module of the cloud-native platform, the start-stop module can directly send the stop instruction to the custom Running State Handler in the third-party application 2, the expected field in the custom CRD2 is set to 0 through the custom Running State Handler, indicating that the custom CRD2 is to be closed, and the Finished field in the custom CRD2 is monitored, when the Finished field is marked as True, it can be determined that the custom CRD2 in the third-party application 2 is stopped successfully.

[0036] In the start-stop control method of the cloud-native application provided in the application, the elements required for resource start-stop are abstracted, the custom Running State Handler of the elements is completed by using Kubernetes custom resource definition, and the custom Running State Handler is published, when the custom resource of the third party is connected, if the custom Running State Handler is not deployed in the third-party application, only a small amount of configuration is required to generate the custom Running State Handler corresponding to the third-party application in the cloud-native platform, if the custom Running State Handler is deployed in the third-party application, the cloud-native platform can directly control the custom Running State Handler in the third-party application, and the start-stop control of the third-party application is realized. It is achieved that the start-stop management of the third-party custom work load can be completed only by simple configuration or without configuration.

[0037] Figure 2 A flowchart of a start-stop control method of a cloud-native application according to an embodiment of the application is shown, the method is applied to a cloud-native platform, and specifically includes the following steps:

[0038] Step 202: Establish a communication link with the target cloud-native application.

[0039] The method provided in the application is applied to a cloud-native platform, the cloud-native platform is a platform for deploying and controlling application programs, and the cloud-native platform is deployed in Kubernetes.

[0040] In the process of deployment of the cloud native platform, a built-in Running State Handler corresponding to a built-in workload resource of Kubernetes is deployed at the same time, and the built-in Running State Handler includes Deployment, StatefulSet, DaemonSet, etc.

[0041] Deployment is a self-repairing mechanism provided by Kubernetes, which is used to solve the problem of machine failure maintenance. Deployment is a Pod (container group) management method, which can instruct Kubernetes how to create and update a deployed application example.

[0042] StatefulSet is a replica controller, which manages the deployment, scaling, etc. of Pods, provides sequence and uniqueness guarantee for multiple Pods in a set, and assigns a unique and persistent Pod name, DNS resolution and persistent storage to each Pod in the set, and is responsible for sticking these identifiers to the Pod regardless of the node to which the Pod is scheduled.

[0043] DaemonSet is used to ensure that a Pod is running on a node. When a node is added to the cluster, a Pod is added. When a node is removed from the cluster, the Pod is manually drawn. Deleting DaemonSet will delete all the Pods created by DaemonSet.

[0044] In the method provided in the application, a custom preset application running state object (custom Running State Handler) is also pre-configured. In the application, the custom Running State Handler is abstracted into an object by using the CRD of Kubernetes. The object field includes the definition of two elements, which are: 1. How to represent the desired state of the custom resource definition (CRD) as stop running. 2. How to judge that the custom resource definition (CRD) has completed the coordination of the desired state (including start completion and stop completion).

[0045] In actual application, the preset application running state object is constructed by the following steps:

[0046] Determine resource start-stop expectation parameters and resource start-stop state parameters;

[0047] Based on the resource start-stop expectation parameters and the resource start-stop state parameters, a preset application running state object for the custom resource definition is constructed.

[0048] The resource start-stop expectation parameter is used to indicate that the state expected by the custom resource definition (CRD) is to stop running, and the resource start-stop state parameter is used to indicate that the custom resource definition (CRD) has completed the expected state.

[0049] The custom Running StateHandler is constructed by the resource start-stop expectation parameter and the resource start-stop state parameter, and in the custom Running StateHandler, field definitions are usually included, for example: spec.kind: identifies the third-party custom resource type; spec.apiVersion: identifies the third-party custom resource version; spec.expected: identifies the state expected by the field when the third-party custom resource stops; spec.finished: identifies whether the third-party custom resource has completed the expected state (supports go template expression), and the like.

[0050] The target cloud-native application is a third-party application, and when the target cloud-native application is deployed in Kubernetes, the target cloud-native application creates a communication link with the cloud-native platform, that is, the cloud-native platform and the target cloud-native application can communicate messages.

[0051] In the embodiments provided in the application, when the target cloud-native application is application 1, a communication link between the target cloud-native application 1 and the cloud application platform is established.

[0052] Step 204: Determine the application type of the target cloud-native application according to a preset application running state object, wherein the preset application running state object includes a resource start-stop expectation parameter and a resource start-stop state parameter.

[0053] After the communication link with the target cloud-native application is created, it is determined whether the application type of the target cloud-native application is set, and in the application, the application type of the target cloud-native application is used to determine whether the preset application running state object (custom Running State Handler) is set in the target cloud-native application.

[0054] The method provided in the application is used to control the start and stop of the target cloud-native application through the custom Running State Handler, and whether the custom Running StateHandler is included in the target cloud-native application is used to determine how to control the target cloud-native application.

[0055] In actual application, the custom Running State Handler at least includes the resource start-stop expectation parameter and the resource start-stop state parameter.

[0056] Specifically, the application type of the target cloud-native application is determined according to the preset application running state object, including:

[0057] It is judged whether the preset application running state object is deployed in the target cloud-native application.

[0058] If yes, it is determined that the target cloud-native application is a first type of application.

[0059] If no, it is determined that the target cloud-native application is a second type of application.

[0060] The most direct way to determine the target cloud-native application is to determine whether the custom Running State Handler is deployed in the target cloud-native application. If the custom Running State Handler is deployed in the target cloud-native application, the cloud-native platform can directly process the target cloud-native application through the custom Running State Handler, and the target cloud-native application is the first type of application, that is, the first type of application is an application with a preset application running state object built-in in the target cloud-native application. Correspondingly, if the custom Running State Handler is not deployed in the target cloud-native application, the cloud-native platform cannot directly read and control the custom Running State Handler in the target cloud-native application, and the target cloud-native application is the second type of application, that is, the second type of application is an application without a preset application running state object built-in in the target cloud-native application.

[0061] Step 206: receiving a start-stop instruction for the target cloud-native application.

[0062] The start-stop instruction specifically refers to a start or stop instruction of an application or resource issued by a user or other application. In actual application, due to the association relationship between businesses, the target cloud-native application may directly face the user, and the user controls the start-stop processing of the target cloud-native application. The user issues a start-stop instruction for the target cloud-native application in the cloud-native platform, and the cloud-native platform receives the start-stop instruction.

[0063] In addition, the target cloud-native application can also be an auxiliary application of other cloud-native applications. When other cloud-native applications are started or stopped, the start-stop of the target cloud-native application is automatically controlled. For example, cloud-native application A is an auxiliary application of cloud-native user B. When cloud-native application B is running, cloud-native application A needs to be started. The user starts cloud-native application B in the cloud-native platform, and through the dependency relationship between applications, cloud-native application B sends a start instruction for cloud-native application A to the cloud-native platform.

[0064] Step 208: In response to the start-stop instruction, perform start-stop processing on the target cloud-native application based on the application type and the preset application running state object.

[0065] After the cloud-native platform receives the start-stop instruction for the target cloud-native application, it needs to respond to the start-stop instruction and perform start-stop processing on the target cloud-native application according to the application type of the target cloud-native application and the custom Running State Handler. That is, in the process of performing start-stop processing on the target cloud-native application, the specific processing of the target cloud-native application is determined by the custom Running State Handler and the application type.

[0066] Specifically, performing start-stop processing on the target cloud-native application based on the application type and the preset application running state object includes:

[0067] In the case where the target cloud-native application is a first type of application, adjust the preset application running state object to perform start-stop processing on the target cloud-native application.

[0068] In the case where the target cloud-native application is a second type of application, deploy the preset application running state object corresponding to the target cloud-native application, and adjust the preset application running state object to perform start-stop processing on the target cloud-native application.

[0069] As shown in the above steps, the first type of application is an application with a preset application running state object built-in in the target cloud-native application. Therefore, the cloud-native platform can perform start-stop processing on the target cloud-native application by adjusting the parameters of the custom Running State Handler built-in in the target cloud-native application.

[0070] The second type of application is an application without a preset application running state object built-in in the target cloud-native application. Therefore, the cloud-native platform needs to deploy a custom Running State Handler corresponding to the target cloud-native application in the cloud-native platform, and then adjust the parameters of the custom Running State Handler to perform start-stop processing on the target cloud-native application.

[0071] In summary, whether it is a first type of application or a second type of application, the parameters in the custom Running State Handler need to be adjusted. The difference is that the custom Running State Handler is located in different positions.

[0072] In a specific implementation provided in the present application, the preset application running state object is adjusted to perform start-stop processing on the target cloud-native application, including S2082-S2084:

[0073] S2082, the resource start-stop expectation parameter is adjusted to perform start-stop operation on the target cloud-native application.

[0074] In the custom Running State Handler, there are two important parameters, namely the resource start-stop expectation parameter and the resource start-stop state parameter. The resource start-stop expectation parameter is used to control the start-stop of the CRD, and the resource start-stop state parameter is used to represent whether the CRD has achieved the desired effect.

[0075] Therefore, when performing start-stop processing on the target cloud-native application, the resource start-stop expectation parameter in the custom Running State Handler is directly adjusted according to the start-stop. For example, when the resource start-stop expectation parameter is 1, it indicates that the target cloud-native application is in a start state, and when the resource start-stop expectation parameter is 0, it indicates that the target cloud-native application is in a stop state.

[0076] Based on this, the start-stop operation on the target cloud-native application also needs to determine whether the target cloud-native application is expected to start or stop according to the start-stop instruction. Accordingly, the resource start-stop expectation parameter is adjusted to perform start-stop operation on the target cloud-native application, including:

[0077] Obtaining the start-stop information carried in the start-stop instruction;

[0078] Adjusting the resource start-stop expectation parameter based on the start-stop information.

[0079] In the present embodiment, the start-stop information in the start-stop instruction is obtained, which is used to indicate whether the target cloud-native application is expected to start or stop. Then, the resource start-stop expectation parameter is adjusted according to the start-stop information. If the start-stop information carried in the start-stop instruction is start, the resource start-stop expectation parameter can be adjusted to 1. If the start-stop information carried in the start-stop instruction is stop, the resource start-stop expectation parameter can be adjusted to 0.

[0080] S2084, determining the start-stop state of the target cloud-native application according to the resource start-stop state parameter.

[0081] In actual application, when the target cloud native application receives the start-stop instruction, it is not enough to only adjust the resource start-stop expectation parameter. The target cloud native application needs to handle other associated resources, etc. Therefore, from changing the resource start-stop state parameter to the real start-stop of the target cloud native application, some time is needed. Therefore, the real start-stop state of the target cloud native application needs to be determined according to the resource start-stop state parameter. For example, when the resource start-stop state parameter is the confirmation state, the start-stop state of the target cloud native application can be confirmed.

[0082] Specifically, determining the start-stop state of the target cloud native application according to the resource start-stop state parameter includes:

[0083] reading the start-stop state information of the resource start-stop state parameter;

[0084] determining the start-stop state of the target cloud native application based on the start-stop state information.

[0085] In actual application, after adjusting the resource start-stop expectation parameter, the start-stop state information in the resource start-stop state parameter needs to be read in real time. When the start-stop state information changes from False to True, it can be determined that the start-stop state of the target cloud native application is successful.

[0086] The cloud native application start-stop control method provided in the application is applied to a cloud native platform, a communication link with a target cloud native application is established, the application type of the target cloud native application is determined according to a preset application running state object, the preset application running state object includes a resource start-stop expectation parameter and a resource start-stop state parameter, a start-stop instruction for the target cloud native application is received, and the start-stop processing of the target cloud native application is performed based on the application type and the preset application running state object in response to the start-stop instruction.

[0087] Through the method provided in the application, the elements required for resource start-stop are abstracted, the preset application running state object is generated, and when the custom resources of the third-party application are connected, the start-stop processing of the third-party application is performed according to whether the preset application running state object is deployed in the third-party application resource. The start-stop management of the custom workloads in the third-party application can be completed with a small amount of configuration or without configuration.

[0088] The following describes the cloud native application start-stop control method provided in the application in combination with the accompanying drawings. Figure 3 The cloud native application start-stop control method provided in the application is further described by taking the application of the cloud native application start-stop control method in the first type of application as an example. Wherein, Figure 3 FIG. 1 shows a processing flowchart of the cloud native application start-stop control method applied to the first type of application according to an embodiment of the application, which specifically includes the following steps:

[0089] Step 302: Deploy a cloud-native platform on Kubernetes.

[0090] Step 304: Deploy a built-in RunningStateHandler in the cloud-native platform.

[0091] In the built-in RunningStateHandler, there are basic parameters corresponding to the Kubernetes workload resources.

[0092] Step 306: Deploy a third-party application A, wherein a custom RunningStateHandler is deployed in the third-party application A.

[0093] The custom RunningStateHandler is used to control the start-stop process of the third-party application A.

[0094] Step 308: The user clicks to stop the third-party application A, and sends a stop instruction for the third-party application A to the cloud-native platform.

[0095] Step 310: The cloud-native platform queries the workload of the third-party application A, and queries the custom RunningStateHandler in the third-party application A through the start-stop module.

[0096] Step 312: Analyze the resource start-stop expectation parameter in the custom RunningStateHandler, and update the resource start-stop expectation parameter to stop.

[0097] Step 314: Determine whether the resource has reached the expected effect through the resource start-stop state parameter in the custom RunningStateHandler. If the resource start-stop state parameter becomes True, it means that the application has been stopped.

[0098] The following is a combination of the accompanying Figure 4 The cloud-native application start-stop control method provided in the present application is further described by taking the application of the cloud-native application start-stop control method in the second type of application start-stop control as an example. Wherein, Figure 4 Fig. 1 shows a processing flowchart of a cloud-native application start-stop control method applied to a second type of application according to an embodiment of the present application, which specifically includes the following steps:

[0099] Step 402: Deploy a cloud-native platform on Kubernetes.

[0100] Step 404: Deploy a built-in RunningStateHandler in the cloud-native platform.

[0101] Step 406: deploying the third-party application B, wherein the custom RunningStateHandler is not deployed in the third-party application B.

[0102] Step 408: obtaining parameter information about resource start-stop in the third-party application B.

[0103] Based on the parameter information, the custom RunningStateHandler of the third-party application B is completed, and the custom RunningStateHandler corresponding to the third-party application B is deployed to the cloud-native platform.

[0104] Step 410: the user clicks to start the third-party application B, and sends a start instruction for the third-party application B to the cloud-native platform.

[0105] Step 412: the cloud-native platform queries the workload of the third-party application B, and queries the custom RunningStateHandler deployed in the cloud-native platform through the start-stop module.

[0106] Step 414: the resource start-stop expectation parameter in the custom RunningStateHandler is parsed, and the resource start-stop expectation parameter is updated to start.

[0107] Step 416: whether the resource has reached the expected effect is judged through the resource start-stop state parameter in the custom RunningStateHandler, and if the resource start-stop state parameter becomes True, it means that the application has been started.

[0108] Corresponding to the method embodiments described above, the present application also provides an application start-stop control device for cloud-native application, Figure 5 A structural schematic diagram of an application start-stop control device for cloud-native application is shown. Figure 5 As shown in the figure, the device comprises:

[0109] A creation module 502 configured to establish a communication link with a target cloud-native application;

[0110] A determination module 504 configured to determine the application type of the target cloud-native application according to a preset application running state object, wherein the preset application running state object comprises a resource start-stop expectation parameter and a resource start-stop state parameter;

[0111] A receiving module 506 configured to receive a start-stop instruction for the target cloud-native application;

[0112] A control module 508 configured to respond to the start-stop instruction, and execute start-stop processing of the target cloud-native application based on the application type and the preset application running state object.

[0113] Optionally, the determining module 504 is further configured to:

[0114] determine whether the preset application running state object is deployed in the target cloud native application;

[0115] if yes, determine that the target cloud native application is a first type of application;

[0116] if no, determine that the target cloud native application is a second type of application.

[0117] Optionally, the control module 508 is further configured to:

[0118] if the target cloud native application is the first type of application, adjust the preset application running state object to perform start-stop processing on the target cloud native application;

[0119] if the target cloud native application is the second type of application, deploy the preset application running state object corresponding to the target cloud native application, and adjust the preset application running state object to perform start-stop processing on the target cloud native application.

[0120] Optionally, the control module 508 is further configured to:

[0121] adjust the resource start-stop expected parameter to perform start-stop operation on the target cloud native application;

[0122] determine the start-stop state of the target cloud native application according to the resource start-stop state parameter.

[0123] Optionally, the control module 508 is further configured to:

[0124] obtain start-stop information carried in the start-stop instruction;

[0125] adjust the resource start-stop expected parameter based on the start-stop information.

[0126] Optionally, the control module 508 is further configured to:

[0127] read start-stop state information of the resource start-stop state parameter;

[0128] determine the start-stop state of the target cloud native application based on the start-stop state information.

[0129] Optionally, the apparatus further comprises:

[0130] a parameter determining module configured to determine a resource start-stop expected parameter and a resource start-stop state parameter;

[0131] A construction module is configured to construct a preset application running state object for a customized resource definition based on the resource start-stop expectation parameter and the resource start-stop state parameter.

[0132] The cloud-native application start-stop control apparatus provided by the application is applied to a cloud-native platform, a communication link with a target cloud-native application is established, an application type of the target cloud-native application is determined according to a preset application running state object, wherein the preset application running state object includes a resource start-stop expectation parameter and a resource start-stop state parameter, a start-stop instruction for the target cloud-native application is received, and start-stop processing of the target cloud-native application is performed based on the application type and the preset application running state object in response to the start-stop instruction.

[0133] By the apparatus provided by the application, elements required for resource start-stop are abstracted, a preset application running state object is generated, and when a custom resource of a third-party application is interfaced, start-stop processing of the third-party application is performed according to whether the preset application running state object is deployed in the third-party application resource, and start-stop management of a custom workload in the third-party application can be completed with a small amount of configuration or without configuration.

[0134] The above is a schematic scheme of the cloud-native application start-stop control apparatus of the embodiment. It should be noted that the technical scheme of the cloud-native application start-stop control apparatus belongs to the same concept as the technical scheme of the cloud-native application start-stop control method described above, and the details of the technical scheme of the cloud-native application start-stop control apparatus that are not described in detail can be seen from the description of the technical scheme of the cloud-native application start-stop control method.

[0135] Figure 6 A structural block diagram of a computing device 600 according to an embodiment of the application is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 through a bus 630, and a database 650 is used to save data.

[0136] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 640 can include one or more of any type of network interface (e.g., a network interface card (NIC)) such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a near-field communication (NFC) interface, and the like, wired or wireless.

[0137] In an embodiment of the present application, the above-mentioned components of the computing device 600, as well as other components not shown in FIG. 6, can be connected to each other through a bus. It should be understood that Figure 6 the above-mentioned components of the computing device 600, as well as other components not shown in FIG. 6, can be connected to each other through a bus. It should be understood that Figure 6 The computing device structure diagram shown is only for the purpose of example, and is not a limitation on the scope of the present application. Those skilled in the art can add or replace other components as needed.

[0138] The computing device 600 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. The computing device 600 can also be a mobile or stationary server.

[0139] wherein the processor 620 implements the steps of the cloud-native application start-stop control method when executing the computer instructions.

[0140] The above is a schematic scheme of a computing device of the present embodiment. It should be noted that the technical scheme of the computing device belongs to the same concept as the technical scheme of the cloud-native application start-stop control method described above, and the details of the technical scheme of the computing device that are not described in detail can be referred to the description of the technical scheme of the cloud-native application start-stop control method described above.

[0141] The present embodiment also provides a computer readable storage medium storing computer instructions, which, when executed by a processor, implement the steps of the cloud-native application start-stop control method as described above.

[0142] The above is a schematic scheme of a computer readable storage medium of the present embodiment. It should be noted that the technical scheme of the storage medium belongs to the same concept as the technical scheme of the cloud-native application start-stop control method described above, and the details of the technical scheme of the storage medium that are not described in detail can be referred to the description of the technical scheme of the cloud-native application start-stop control method described above.

[0143] The above describes a specific embodiment of the present application. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims can be performed in a different order than those in the embodiments and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

[0144] The computer readable medium can include any entity or apparatus capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, software distribution medium, etc. It should be noted that the computer readable medium can include appropriate additions or subtractions according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0145] It should be noted that for the foregoing method embodiments, in order to facilitate description, they are all expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0146] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0147] The preferred embodiments of the present application disclosed above are only used to help explain the present application. The alternative embodiments do not describe all the details and do not limit the application to the specific embodiments described. Obviously, according to the content of the present application, many modifications and changes can be made. The present application selects and describes these embodiments in order to better explain the principles and practical applications of the present application, so that those skilled in the art can well understand and utilize the present application. The present application is limited by the claims and their entire scope and equivalents.

Claims

1. A method for starting and stopping cloud-native applications, characterized in that, Applied to cloud-native platforms, including: Establish a communication link with the target cloud-native application, which is a third-party application; Determine whether a preset application running status object is deployed in the target cloud-native application. If yes, the target cloud-native application is determined to be a first type of application; otherwise, the target cloud-native application is determined to be a second type of application. The preset application running status object includes resource start / stop expectation parameters and resource start / stop status parameters. Receive start / stop commands for the target cloud-native application; In response to the start / stop command, if the target cloud-native application is a first type of application, the preset application running state object is adjusted to perform start / stop processing on the target cloud-native application. If the target cloud-native application is a second type of application, the preset application running state object corresponding to the target cloud-native application is deployed, and the preset application running state object is adjusted to perform start / stop processing on the target cloud-native application.

2. The method as described in claim 1, characterized in that, Adjusting the preset application running state object to perform start / stop processing for the target cloud-native application includes: Adjust the desired start / stop parameters for the resources to perform start / stop operations on the target cloud-native application; The start / stop status of the target cloud-native application is determined based on the resource start / stop status parameters.

3. The method as described in claim 2, characterized in that, Adjusting the desired resource start / stop parameters to perform start / stop operations on the target cloud-native application includes: Obtain the start / stop information carried in the start / stop command; The expected parameters for resource start / stop are adjusted based on the start / stop information.

4. The method as described in claim 2, characterized in that, Determining the start / stop status of the target cloud-native application based on the resource start / stop status parameters includes: Read the start / stop status information of the resource start / stop status parameters; The start / stop status of the target cloud-native application is determined based on the start / stop status information.

5. The method as described in claim 1, characterized in that, The preset application running state object is constructed through the following steps: Determine the expected parameters for resource start / stop and the resource start / stop status parameters; Based on the resource start / stop expectation parameters and the resource start / stop status parameters, a preset application running status object is constructed for the customized resource definition.

6. A start / stop control device for cloud-native applications, characterized in that, Applied to cloud-native platforms, including: A module is created and configured to establish a communication link with a target cloud-native application, which is a third-party application. The determination module is configured to determine whether a preset application running status object is deployed in the target cloud-native application. If yes, the target cloud-native application is determined to be a first type of application; otherwise, the target cloud-native application is determined to be a second type of application. The preset application running status object includes resource start / stop expectation parameters and resource start / stop status parameters. The receiving module is configured to receive start / stop commands for the target cloud-native application; The control module is configured to respond to the start / stop command by adjusting the preset application running state object to perform start / stop processing on the target cloud-native application when the target cloud-native application is a first type of application, and by deploying the preset application running state object corresponding to the target cloud-native application and adjusting the preset application running state object to perform start / stop processing on the target cloud-native application when the target cloud-native application is a second type of application.

7. A computing device, comprising a memory, a processor, and computer instructions stored in the memory and executable on the processor, characterized in that, When the processor executes the computer instructions, it implements the steps of the method according to any one of claims 1-5.

8. A computer-readable storage medium storing computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1-5.

Images