A method and device for implementing declarative management of cloud components

Abstract

The present invention provides a method for implementing declarative management of cloud components, comprising the following steps: designing a cloud component resource and management model, designing a cloud component management control unit controller at the cluster level, designing a cloud component execution and monitoring unit executor at the node level, designing a logical scheme for parsing declarative resources to implement management functions, and designing a scheduling algorithm and an adaptation architecture for managing cloud component actions; the beneficial effects are: non-container applications on the cluster are defined as cloud components. This patent proposes a method and device for implementing declarative management of cloud components, which achieves: automated management of the entire life cycle of multi-node cloud components; declarative definition of the final form of components; selection of qualified nodes to manage cloud components through a scheduling algorithm based on component configuration; support for automatic retry after multiple actions of cloud components fail; simplification of manual operations, reduction of time for managing cloud components, and improvement of efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of cluster management, and in particular to a method and device for implementing declarative management of cloud components. Background Art

[0002] In recent years, Kubernetes, as an advanced container orchestration system, has developed rapidly and has been widely used in the fields of cloud computing and cloud services. With the development of various private clouds and government clouds, how to quickly and reasonably deploy and manage non-container applications on clusters has become increasingly important.

[0003] Currently, the management of non-container applications faces the problem of overly complex deployment and management, which is not user-friendly and places high demands on the operator's skills and experience. For example, Ansible has low execution performance, high resource usage on nodes, and no retry function after execution failure. Salt has a high learning cost and a long time to get started, and it is a separate system from Kubernetes.

[0004] Therefore, in the process of deploying and managing large-scale non-container application environments, traditional application deployment and management methods reduce work efficiency. Currently, management methods such as Ansble and Salt are two different systems from the native Kubernetes, which adds an additional complexity that is difficult to manage. Summary of the Invention

[0005] The purpose of the present invention is to provide a method and apparatus for implementing declarative management of cloud components to solve the problems raised in the above background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method and apparatus for implementing declarative management of cloud components, comprising the following steps:

[0007] Design cloud component resources and management models, including: cloud component metadata resources, cloud component cluster template resources, cloud component node entity resources, and cloud component list resources. Design a management model for these resources and an architecture that adapts to this management model, which is mainly divided into cluster-level controllers (server-side) and node-level executors (agent-side).

[0008] Design a cluster-level cloud component management control unit controller. After cluster initialization, the controller is deployed on the control node in a distributed and highly available manner. At the same time, it registers custom CRD resources into the Kubernetes cluster and monitors the creation and changes of cloud component resources. After successful initialization, the controller detects changes in cloud component resources through the registration and monitoring mechanism of Kube-Apiserver, parses the corresponding resource types, and processes differentiated actions of cloud components using different logical models. The controller creates a cluster-level cloud component template and instantiates a node-level component entity in the child node specified by the cloud component. By processing the cluster-level template of the cloud component, it triggers changes to the node-level component entity, thus realizing multiple logical processing.

[0009] Design a node-level cloud component execution and monitoring unit executor. The executor runs as a resident process on a single node. After the node is running, it monitors the cloud component entity of the current node. When the component entity changes, it performs relevant processing through the internal action processing model. The executor identifies the action type based on the entity status of the cloud component on the current node: deployment, expansion, reduction, update, upgrade, and deletion, and executes scripts using preset templates. Through the definition of declarative configuration files, the executor has the ability to access API servers in different clusters and perform multiple operations such as monitoring and changing component custom resources.

[0010] Design a logical solution for parsing declarative resources to implement management functions. When the controller monitors the creation of new component-related resources, it triggers the deployment logic and sequentially instantiates cluster-level component templates and node-level component entities to complete the deployment of cloud components.

[0011] Design a scheduling algorithm for managing cloud component actions. To achieve the shortest possible deployment and upgrade time for cloud components, this strategy ensures the shortest possible deployment and upgrade execution. Specifically, it performs logical calculations based on three dependency relationships: parent-child structure, V-shaped structure, and sequential structure. This determines the shortest path, which then forms the optimal solution for the critical path of inter-component scheduling. Scheduling strategies within a single component include: rolling action execution strategy, destructive action delayed execution strategy, and action execution node affinity strategy.

[0012] Adaptive architecture, adapt to three CPU architectures: x86, arm, and mips64el.

[0013] Preferably, in the step of designing cloud component resources and management models, cloud component metadata resources are designed based on Kubernetes' CRD technology. The resource contains the component's current component name, version, deployment image, business function image, and expected state. When the cloud component version is iterated, the cloud component metadata version iteration is completed by modifying the version, deployment image, and business function image.

[0014] Preferably, in the step of designing cloud component resources and management models, cloud component cluster template resources are designed based on Kubernetes' CRD technology. The resource contains the cloud component version used by the cloud component in the current cluster, cloud component configuration parameters, affinity nodes pointed to by the cloud component, the node entity list deployed by the cloud component, scheduling policy configuration, current status, and expected status. Modification of the resource triggers multiple component actions, version modification triggers upgrades, configuration parameter modification triggers updates, affinity node modification triggers expansion and contraction, and creation or deletion of the resource triggers deployment and deletion of cloud component actions.

[0015] Preferably, in the step of designing cloud component resources and management model, cloud component node entity resources are designed based on Kubernetes' CRD technology, and the resources contain cloud component version, cloud component configuration parameters, deployment node information of the current cloud component entity, current status, and expected status.

[0016] Preferably, in the step of designing cloud component resources and management model, a certain type of cloud component list resource is designed based on Kubernetes' CRD technology, and the resource contains a list of cloud component names and versions, the version of the cloud component list, and the expected state.

[0017] Preferably, in the step of designing a cloud component management control unit controller at the cluster level, among the components, the controller calculates the optimal node and the optimal order through the scheduling algorithm based on the declarative node configuration and scheduling strategy; within a single component, the controller calculates the optimal choice between multiple actions based on the declarative policy cluster, and obtains the optimal solution for the execution of differentiated actions.

[0018] Preferably, in the design of the cloud component execution and monitoring unit executor steps at the node level, in order to improve efficiency, the executor has a built-in retry mechanism. When the current action fails for some reason, the executor will automatically trigger the retry mechanism when it detects the action failure status, and the retry triggering time will be weighted and superimposed with the number of times to extend the execution time.

[0019] Preferably, in the step of designing a logical solution for parsing declarative resources to implement the management function, when the controller monitors that the number of node copies pointed to by the node selector of the component increases, the expansion logic is triggered by creating a new node component entity and modifying the entity state to the state to be expanded, and the component expansion is completed when the executor completes the execution of the expansion logic; when the controller monitors that the number of node copies pointed to by the node selector of the component decreases, the shrinkage logic is triggered by modifying the shrinkage node component entity to the state to be shrunk, and the component shrinkage is completed when the executor completes the execution of the shrinkage logic; when the controller monitors that the expected parameters of the cluster template of the component are modified, the update logic is triggered by modifying the cloud component child node entity to the state to be updated, and the component update is completed when the executor completes the execution of the update logic; when the controller monitors that the expected version of the cluster template of the component is modified, the upgrade logic is triggered by modifying the cloud component child node entity to the state to be upgraded, and the component upgrade is completed when the executor completes the execution of the upgrade logic; when the controller monitors that the cluster template of the component is deleted, the deletion logic is triggered by modifying all child node component entities to the state to be deleted, and the component deletion is completed when the executor completes the execution of the deletion logic.

[0020] Preferably, the action rolling execution strategy in the scheduling algorithm step of the cloud component action is designed: to ensure the high availability of the component function, this strategy ensures the external response capability of the component during the action execution process. Specifically, the action execution is carried out on each node entity in turn, and the action of the next entity will not be started until the previous node entity completes the action; the destructive action delayed execution strategy: to ensure the external availability of the component function, this strategy ensures that the triggering timing of the destructive action requires manual confirmation by a specific person at a specific time. Specifically, the weight ratio of the action execution is reduced to the lowest when the policy is verified when the action is triggered; the action execution node affinity strategy: to ensure that the component entity runs on the target node specified by the user, this strategy deploys the component entity on the target node according to the declarative node selection function. Specifically, according to the node declared by the component, the corresponding action is executed on the node.

[0021] A device for implementing a method for declaratively managing cloud components includes a CPU component, a controller, and an executor.

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

[0023] The method and device for implementing declarative management of cloud components proposed in the present invention solve the problems of difficult operation and maintenance and slow upgrade of large clusters by automatically managing the entire life cycle of multi-node cloud components; declaratively defining the final form of cloud components can simplify manual operations, reduce the time of managing cloud components, and improve efficiency; supporting automatic retry after multiple actions of cloud components fail to provide high availability capabilities; multiple declarative configurable strategies support free selection of multiple complex scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a schematic diagram of the overall architecture of the present invention;

[0025] Figure 2 Schematic diagram of the controller structure of the present invention;

[0026] Figure 3 Schematic diagram of the actuator structure of the present invention;

[0027] Figure 4 This is a schematic diagram of the controller execution deployment structure of the present invention;

[0028] Figure 5 Schematic diagram of the logic structure of the controller for capacity expansion according to the present invention;

[0029] Figure 6 Schematic diagram of the logic structure of the controller executing scaling-down in the present invention;

[0030] Figure 7 Schematic diagram of the logic structure of the controller executing the update of the present invention;

[0031] Figure 8 Schematic diagram of the controller performing upgrade logic structure of the present invention;

[0032] Figure 9 Schematic diagram of the deletion logic structure executed by the controller of the present invention. DETAILED DESCRIPTION

[0033] In order to clearly and completely describe the objectives and technical solutions of the present invention and make the advantages more clearly understood, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, not all of them, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0034] In the description of the present invention, it should be noted that the terms "center," "middle," "upper," "lower," "left," "right," "inner," "outer," "top," "bottom," "side," "vertical," "horizontal," and the like, indicating positions or location relationships, are based on the positions or location relationships shown in the accompanying drawings and are intended only to facilitate the description of the present invention and simplify the description. They are not intended to indicate or imply that the devices or components referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limiting the present invention. Furthermore, the terms "one," "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0035] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediate medium; and internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on the specific circumstances.

[0036] For the purpose of simplicity and illustration, the principles of the embodiments are described primarily with reference to examples. In the following description, many specific details are provided to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that these embodiments may not be limited to these specific details in practice. In some instances, well-known methods and structures are not described in detail to avoid unnecessarily obscuring the understanding of these embodiments. In addition, all embodiments may be used in combination with each other.

[0037] See also Figures 1 to 9 The present invention provides a technical solution: a method for implementing declarative management of cloud components, characterized by comprising the following steps:

[0038] Design cloud component resources and management models, including: cloud component metadata resources, cloud component cluster template resources, cloud component node entity resources, cloud component list resources, design a management model for managing such resources, and design an architecture that adapts to this management model, which is mainly divided into cluster-level controllers (Server side) and node-level executors (Agent side); design cloud component metadata resources based on Kubernetes' CRD technology, which contains the component's current component name, version, deployment image, business function image, and expected state. When the cloud component version is iterated, the cloud component's metadata version iteration is completed by modifying the version, deployment image, and business function image; design cloud component cluster template resources based on Kubernetes' CRD technology, which contains the cloud component's current status in the cluster. The cloud component version used in the group, cloud component configuration parameters, affinity nodes pointed to by the cloud component, the node entity list deployed by the cloud component, scheduling policy configuration, current status, and expected status. Modifications to this resource trigger multiple component actions, such as version modification triggering upgrades, configuration parameter modification triggering updates, affinity node modification triggering expansion and contraction, and creation or deletion of this resource triggering deployment and deletion of cloud component actions. Design cloud component node entity resources based on Kubernetes' CRD technology. This resource contains the cloud component version, cloud component configuration parameters, deployment node information of the current cloud component entity, current status, and expected status. Design a certain type of cloud component list resource based on Kubernetes' CRD technology. This resource contains a list of cloud component names and versions, the version of the cloud component list, and the expected status.

[0039] Design a cluster-level cloud component management control unit controller. After the cluster is initialized, the controller is deployed on the control node in a distributed and highly available manner. At the same time, the custom CRD resources are registered in the Kubernetes cluster to monitor the creation and changes of cloud component resources. After the controller is successfully initialized, when changes in cloud component resources are discovered through the registration and monitoring mechanism of Kube-Apiserver, the corresponding resource type is parsed to handle differentiated actions of cloud components with different logical models. The controller creates a cluster-level cloud component template and instantiates a node-level component entity in the child node specified by the cloud component. By processing the cluster-level template of the cloud component, the node-level component entity is triggered to change, thereby realizing multiple logical processing. Among the components, the controller calculates the optimal node and the optimal order based on the declarative node configuration and scheduling strategy through the scheduling algorithm. Within a single component, the controller calculates the optimal choice between multiple actions based on the declarative policy cluster, and obtains the optimal solution for the execution of differentiated actions.

[0040] Design a cloud component execution and monitoring unit executor at the node level. The executor runs on a single node as a resident process. After the node is running, it monitors the cloud component entity of the current node. When the component entity changes, it performs relevant processing through the internal action processing model. The executor identifies the action category based on the entity status of the cloud component on the current node: deployment, expansion, reduction, update, upgrade, deletion, and executes the script through the preset template. The executor has the ability to access API servers in different clusters through the definition of declarative configuration files, and can perform multiple operations such as monitoring and changing component custom resources. To improve efficiency, the executor has a built-in retry mechanism. When the current action fails for some reason, the executor will automatically trigger the retry mechanism when it detects the action failure status, and the retry triggering time will be weighted and superimposed with the number of times to extend the execution time.

[0041] Design a logical solution for parsing declarative resources to implement management functions. When the controller monitors the creation of new component-related resources, it triggers the deployment logic and instantiates the cluster-level component template and node-level component entity in sequence to complete the deployment capability of the cloud component. When the controller monitors the increase in the number of node copies pointed to by the component's node selector, it triggers the expansion logic by creating a new node component entity and modifying the entity state to the state to be expanded. When the executor completes the execution of the expansion logic, the component expansion is completed. When the controller monitors the decrease in the number of node copies pointed to by the component's node selector, it triggers the reduction logic by modifying the reduced node component entity to the state to be reduced. The component scaling is completed when the executor finishes executing the scaling-in logic. When the controller detects that the expected parameters of the component's cluster template have been modified, it triggers the update logic, modifies the cloud component's child node entity to the pending update state, and completes the component update when the executor finishes executing the update logic. When the controller detects that the expected version of the component's cluster template has been modified, it triggers the upgrade logic, modifies the cloud component's child node entity to the pending upgrade state, and completes the component upgrade when the executor finishes executing the upgrade logic. When the controller detects that the component's cluster template has been deleted, it triggers the deletion logic, modifies all child node component entities to the pending deletion state, and completes the component deletion when the executor finishes executing the deletion logic.

[0042] Design a scheduling algorithm for managing cloud component actions. To achieve the shortest time deployment and upgrade of cloud component functions, the existence of this strategy can ensure the shortest time deployment and upgrade action execution method. Specifically, it is based on three dependency relationships: parent structure, V-shaped structure, and sequential structure. After logical calculation, the shortest path is obtained, forming the optimal solution for the key path scheduling between components. For a single component, the scheduling strategies include: action rolling execution strategy, destructive action delayed execution strategy, and action execution node affinity strategy. Action rolling execution strategy: To ensure the high availability of component functions, this strategy ensures the external responsiveness of the component during the action execution process. Action execution is performed on each node entity in sequence, and the action of the next entity will not be started until the previous node entity completes the action; Destructive action delayed execution strategy: To ensure the external availability of component functions, this strategy ensures that the triggering timing of destructive actions must be manually confirmed by specific personnel at a specific time. Specifically, the weight ratio of action execution is reduced to the lowest when the strategy is verified when the action is triggered; Action execution node affinity strategy: To ensure that the component entity runs on the target node specified by the user, this strategy deploys the component entity on the target node based on the declarative node selection function. Specifically, the corresponding action is executed on the node declared by the component;

[0043] Adaptive architecture, adapt to three CPU architectures: x86, arm, and mips64el.

[0044] A device for implementing a method for declaratively managing cloud components includes a CPU component, a controller, and an executor.

[0045] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A method for implementing declarative management of cloud components, characterized in that: The following steps are involved: Design cloud component resources and management models, including: cloud component metadata resources, cloud component cluster template resources, cloud component node entity resources, and cloud component list resources. Design a management model for these resources and an architecture that adapts to the management model, divided into cluster-level controller servers and node-level executor agents. Design a cluster-level cloud component management control unit controller. After cluster initialization, the controller is deployed on the control node in a distributed and highly available manner. At the same time, it registers custom CRD resources into the Kubernetes cluster and monitors the creation and changes of cloud component resources. After successful initialization, the controller detects changes in cloud component resources through the registration and monitoring mechanism of Kube-Apiserver, parses the corresponding resource types, and processes differentiated actions of cloud components using different logical models. The controller creates a cluster-level cloud component template and instantiates a node-level component entity in the child node specified by the cloud component. By processing the cluster-level template of the cloud component, it triggers changes to the node-level component entity, thus realizing multiple logical processing. Design a node-level cloud component execution and monitoring unit executor. The executor runs as a resident process on a single node. After the node is running, it monitors the cloud component entity of the current node. When the component entity changes, it performs relevant processing through the internal action processing model. The executor identifies the action type based on the entity status of the cloud component on the current node: deployment, expansion, reduction, update, upgrade, and deletion, and executes scripts using preset templates. Through the definition of declarative configuration files, the executor has the ability to access API servers in different clusters and monitor and change component custom resources. Design a logical solution for parsing declarative resources to implement management functions. When the controller monitors the creation of new component-related resources, it triggers the deployment logic and sequentially instantiates cluster-level component templates and node-level component entities to complete the deployment of cloud components. Design a scheduling algorithm for managing cloud component actions. To achieve the shortest possible deployment and upgrade time for cloud component functions, the algorithm ensures the shortest possible deployment and upgrade execution. Specifically, it performs logical calculations based on three dependency relationships: parent-child structure, V-shaped structure, and sequential structure. The shortest path is then calculated to form the optimal solution for the critical path of inter-component scheduling. Scheduling strategies within a single component include: rolling action execution strategy, destructive action delayed execution strategy, and action execution node affinity strategy. Adaptive architecture, adapt to three CPU architectures: x86, arm, and mips64el.

2. A method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing cloud component resources and management models, cloud component metadata resources are designed based on Kubernetes' CRD technology. This resource contains the component's current component name, version, deployment image, business function image, and expected state. When the cloud component version is iterated, the cloud component metadata version iteration is completed by modifying the version, deployment image, and business function image.

3. The method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing cloud component resources and management models, cloud component cluster template resources are designed based on Kubernetes' CRD technology. This resource contains the cloud component version used by the cloud component in the current cluster, cloud component configuration parameters, affinity nodes pointed to by the cloud component, the node entity list deployed by the cloud component, scheduling policy configuration, current status, and expected status. Modifications to this resource can trigger multiple component actions: version modification triggers upgrades, configuration parameter modification triggers updates, affinity node modification triggers expansion and contraction, and creating or deleting this resource triggers deployment and deletion of cloud component actions.

4. The method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing cloud component resources and management models, cloud component node entity resources are designed based on Kubernetes' CRD technology. This resource contains the cloud component version, cloud component configuration parameters, deployment node information of the current cloud component entity, current status, and expected status.

5. The method and apparatus for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing cloud component resources and management models, a certain type of cloud component list resource is designed based on Kubernetes' CRD technology. This resource contains a list of cloud component names and versions, the version of the cloud component list, and the expected status.

6. A method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing the cloud component management control unit controller at the cluster level, among each component, the controller calculates the optimal node and the optimal order based on the declarative node configuration and scheduling strategy through the scheduling algorithm; within a single component, the controller calculates the optimal choice between multiple actions based on the declarative policy cluster, and obtains the optimal solution for the execution of differentiated actions.

7. The method for implementing declarative management of cloud components according to claim 1, characterized in that: In the design of the node-level cloud component execution and monitoring unit executor steps, in order to improve efficiency, the executor has a built-in retry mechanism. When the current action fails for some reason, the executor will automatically trigger the retry mechanism when it detects the action failure status, and the retry trigger time will be weighted and superimposed with the number of times to extend the execution time.

8. The method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing and parsing the logical solution for declarative resources to implement management functions, when the controller detects that the number of node replicas pointed to by the node selector of the component has increased, the expansion logic is triggered by creating a new node component entity and modifying the entity state to the pending expansion state. The component expansion is completed when the executor completes the execution of the expansion logic. When the controller detects that the number of node replicas pointed to by the node selector of the component has decreased, the shrinkage logic is triggered by modifying the shrinkage node component entity to the pending shrinkage state. The component shrinkage is completed when the executor completes the execution of the shrinkage logic. When the controller detects that the expected parameters of the cluster template of the component have been modified, the update logic is triggered by modifying the cloud component child node entity to the pending update state. The component update is completed when the executor completes the execution of the update logic. When the controller detects that the expected version of the cluster template of the component has been modified, the upgrade logic is triggered by modifying the cloud component child node entity to the pending upgrade state. The component upgrade is completed when the executor completes the execution of the upgrade logic. When the controller detects that the cluster template of the component has been deleted, the deletion logic is triggered by modifying all child node component entities to the pending deletion state. The component deletion is completed when the executor completes the execution of the deletion logic.

9. The method for implementing declarative management of cloud components according to claim 1, characterized in that: In the step of designing the scheduling algorithm for managing cloud component actions, the action rolling execution strategy: in order to ensure the high availability of component functions, the strategy ensures the external response capability of the component during the action execution process. Specifically, the action execution is carried out on each node entity in turn, and the action of the next entity will not be started until the previous node entity completes the action; the destructive action delayed execution strategy: in order to ensure the external availability of component functions, the strategy ensures that the triggering timing of destructive actions requires manual confirmation by personnel. Specifically, when the action is triggered, the weight ratio of the action execution is reduced to the lowest when the strategy is verified; the action execution node affinity strategy: in order to ensure that the component entity runs on the target node specified by the user, the strategy deploys the component entity on the target node according to the declarative node selection function. Specifically, according to the node declared by the component, the corresponding action is executed on the node.

10. A device based on the method of claim 1, characterized in that: It includes CPU components, controllers and actuators.

Images