Cluster upgrading method, device and system, storage medium and computer program product

Abstract

The embodiment of the invention discloses a cluster upgrading method, which is applied to a management node, and comprises the following steps: if an upgrading request is detected, determining one or more target service clusters from at least one managed reference service cluster; wherein the upgrading request is used for requesting to carry out upgrading processing on one or more target service clusters; and sending a starting instruction to an upgrade control node corresponding to each target service cluster, so that the upgrade control node executes a cluster upgrade operation for the target service cluster based on the upgrade configuration file of the target service cluster. The embodiment of the invention also discloses a first cluster upgrading device, a second cluster upgrading device, a system, a storage medium and a computer program product.

Description

Technical Field

[0001] The present application relates to the field of computer application technology, and in particular to a cluster upgrade method, device, system, storage medium and computer program product. Background Art

[0002] With the development of Internet technology, the cloud computing concept of Everything as a Service (XaaS) has been gradually proposed, that is, providing various services and applications through the Internet. XaaS platforms provide users with traditional products, services or business functions in a service-oriented way. In this way, users can order and use these services on demand through the network according to their needs, without owning and maintaining the corresponding hardware and software. XaaS can include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and various other services. In the implementation process, these services provided by XaaS can be implemented using kubernetes (also known as K8S) clusters. However, when an enterprise operates multiple XaaS platforms, it is limited to the environmental barriers of different XaaS platforms or different service modules in the XaaS platform, and the upgrade granularity of the XaaS platform is limited to a single cluster. When upgrading the entire platform with common features, it is necessary to configure each environment one by one, which has poor operation and maintenance efficiency and brings high scale costs. Summary of the invention

[0003] In view of this, the embodiments of the present application hope to provide a cluster upgrade method, device, system, storage medium and computer program product, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade, and proposes a method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster, thereby reducing the complexity of development and management of the XaaS service cluster, realizing cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, and improving the adaptability and scalability of the upgrade operation.

[0004] To achieve the above purpose, the technical solution of this application is implemented as follows:

[0005] The present application provides a cluster upgrade method, which is applied to a management node and includes:

[0006] If an upgrade request is detected, determining one or more target service clusters from at least one reference service cluster managed; wherein the upgrade request is used to request upgrade processing for one or more target service clusters;

[0007] A start instruction is sent to an upgrade control node corresponding to each of the target service clusters, so that the upgrade control node performs a cluster upgrade operation for the target service cluster based on the upgrade configuration file of the target service cluster.

[0008] Optionally, before sending the start instruction to the upgrade control node corresponding to each target service cluster, the method further includes:

[0009] Detecting the working status of each of the target service clusters;

[0010] Correspondingly, the sending of the start instruction to the upgrade control node corresponding to each of the target service clusters includes:

[0011] If the working status is a currently unexecuted task status, obtaining a cluster upgrade configuration corresponding to the corresponding target service cluster;

[0012] Sending a startup instruction including the cluster upgrade configuration to the upgrade control node.

[0013] Optionally, the method further includes:

[0014] Obtaining the corresponding upgrade configuration parameters of the target service cluster;

[0015] Based on the upgrade configuration parameters, generate the cluster upgrade configuration;

[0016] The cluster upgrade configuration is stored in a configuration storage area.

[0017] Optionally, the method further includes:

[0018] If an upgrade registration request for the target service cluster is received, generating the cluster upgrade configuration based on the configuration parameters carried in the upgrade registration request;

[0019] The cluster upgrade configuration is stored in a configuration storage area.

[0020] Optionally, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0021] Optionally, the task process content includes at least the upgrade tasks in the upgrade process, the task unit content includes at least the task unit for implementing each of the upgrade tasks, and the specific execution task content includes at least the basic tasks included in each of the task units.

[0022] Optionally, the format of the upgrade configuration file includes at least: another markup language YAML format.

[0023] Optionally, the method further includes:

[0024] During the process in which the upgrade control node performs the cluster upgrade operation for the target service cluster, each upgrade step performed by the upgrade control node is recorded to obtain an execution record.

[0025] Optionally, recording each upgrade step executed by the upgrade control node to obtain an execution record includes:

[0026] Defining the upgrade operation of the target service cluster as a task flow;

[0027] Each of the upgrade steps is recorded in the task flow in the form of an activity to obtain the execution record.

[0028] Optionally, the method further includes:

[0029] Receive database configuration parameters;

[0030] The execution record is stored in the target database indicated by the database configuration parameter.

[0031] Optionally, the method further includes:

[0032] Determine the upgrade status of the upgrade control node to which the upgrade step currently executed belongs;

[0033] Based on the upgrade status, prompt information is generated.

[0034] The present application provides a cluster upgrade method, which is applied to upgrade a control node, and the method includes:

[0035] Receiving a startup instruction sent by a management node; wherein the startup instruction is generated by the management node based on an upgrade request for requesting an upgrade of a target service cluster;

[0036] In response to the startup instruction, obtain an upgrade configuration file of the corresponding target service cluster;

[0037] Based on the upgrade configuration file, a cluster upgrade operation is performed on the target service cluster.

[0038] Optionally, the responding to the startup instruction to obtain an upgrade configuration file of the corresponding target service cluster includes:

[0039] Responding to the startup instruction, obtaining a cluster upgrade configuration from the startup instruction;

[0040] After initialization processing is performed based on the cluster upgrade configuration, the upgrade configuration file is obtained.

[0041] Optionally, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0042] Optionally, the format of the upgrade configuration file includes at least: another markup language YAML format.

[0043] Optionally, the method further includes:

[0044] If a fault is detected during the execution of the cluster upgrade operation and a fault recovery is implemented, an execution record of the target service cluster is determined; wherein the execution record is used to record the execution steps of the cluster upgrade operation;

[0045] Based on the execution record, determining an execution interruption location;

[0046] Starting from the execution interruption position, the cluster upgrade operation is continued based on the upgrade configuration file.

[0047] Optionally, if a fault occurring during the cluster upgrade operation is detected and a fault recovery is implemented, determining the execution record of the target service cluster includes:

[0048] If a fault is detected during the execution of the cluster upgrade operation, a fault recovery is performed, and database configuration parameters of the target service cluster are determined;

[0049] Based on the database configuration parameters, determining a target database;

[0050] The execution record is obtained from the target database.

[0051] The present application provides a first cluster upgrade device, which is applied to a management node, and includes: a first determination unit and a first sending unit; wherein:

[0052] The first determining unit is configured to determine one or more target service clusters from at least one managed reference service cluster if an upgrade request is detected; wherein the upgrade request is used to request upgrade processing of one or more of the target service clusters;

[0053] The first sending unit is configured to send a start instruction to an upgrade control node corresponding to the target service cluster, so that the upgrade control node performs a cluster upgrade operation for the target service cluster based on an upgrade configuration file of the target service cluster.

[0054] The present application provides a second cluster upgrade device, which is applied to upgrade a control node, and is characterized in that the device comprises: a receiving unit, a second acquisition unit and an execution unit; wherein:

[0055] The receiving unit is used to receive a startup instruction sent by the management node;

[0056] The second acquisition unit is used to respond to the startup instruction and acquire the upgrade configuration file of the corresponding target service cluster;

[0057] The execution unit is configured to execute a cluster upgrade operation for the target service cluster based on the upgrade configuration file.

[0058] The present application provides a cluster upgrade system, the system comprising at least: a management node and at least one upgrade control node; wherein:

[0059] The management node is used to implement the steps of any of the above cluster upgrade methods;

[0060] The upgrade control node is used to implement the steps of any of the above cluster upgrade methods.

[0061] The present application provides a storage medium, on which a cluster upgrade program is stored. When the cluster upgrade program is executed by a processor, the steps of any of the above cluster upgrade methods are implemented.

[0062] The present application provides a computer program product, including a computer program, which implements the steps of any of the above cluster upgrade methods when executed by a processor.

[0063] The cluster upgrade method, device, system, storage medium and computer program product provided by the embodiments of the present application, if the management node detects an upgrade request for requesting an upgrade of the target service cluster, based on the upgrade request, one or more target service clusters are determined from at least one reference service cluster managed, and a startup instruction is sent to the upgrade control node corresponding to each target service cluster, the upgrade control node receives the startup instruction sent by the management node, responds to the startup instruction, obtains the upgrade configuration file of the corresponding target service cluster, and performs the cluster upgrade operation for the target service cluster based on the upgrade configuration file. In this way, the management node starts the upgrade control node used to manage and control the service cluster to control the corresponding target upgrade control node to perform a cluster upgrade operation on the corresponding target service cluster, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade, and proposes a method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster, which reduces the complexity of development and management of the XaaS service cluster, and achieves cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, thereby improving the adaptability and scalability of the upgrade operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1 Schematic diagram of the cluster upgrade method provided in this application embodiment Figure 1 ;

[0065] Figure 2 Schematic diagram of the cluster upgrade method provided in this application embodiment Figure 2 ;

[0066] Figure 3 The application scenario of the cluster upgrade method provided in the embodiment of the present application is shown as follows: Figure 1 ;

[0067] Figure 4 The application scenario of the cluster upgrade method provided in the embodiment of the present application is shown as follows: Figure 2 ;

[0068] Figure 5 The application scenario of the cluster upgrade method provided in the embodiment of the present application is shown as follows: Figure 3 ;

[0069] Figure 6 A schematic diagram of an upgrade process of a cluster upgrade method provided in an embodiment of the present application;

[0070] Figure 7 A schematic diagram of the structure of a first cluster upgrade device provided in an embodiment of the present application;

[0071] Figure 8A schematic diagram of the structure of a second cluster upgrade device provided in an embodiment of the present application;

[0072] Fig. 9 A schematic diagram of the structure of a cluster upgrade system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0074] The embodiment of the present application provides a cluster upgrade method, which is applied to a management node, referring to Figure 1 As shown, the method comprises the following steps:

[0075] Step 101: If an upgrade request is detected, one or more target service clusters are determined from at least one managed reference service cluster.

[0076] The upgrade request is used to request an upgrade process for one or more target service clusters.

[0077] In an embodiment of the present application, an upgrade request for requesting an upgrade of a target service cluster is obtained. The upgrade request may be request information generated by a user who applies or manages the target service cluster after operating the operation interface corresponding to the management node, and is used to request a cluster service upgrade for the target service cluster. The target service cluster belongs to a service cluster among multiple reference service clusters managed by the management node, and each reference service cluster can be used to provide different services. The upgrade request includes at least cluster information of one or more target service clusters that need cluster upgrade services, such as cluster identification information of the target service cluster, and the cluster identification information may be a cluster number, a cluster name, or a corresponding service name when the service provided by the cluster is single. The management node determines the target service cluster from at least one reference service cluster managed by the management node based on the cluster identification information included in the upgrade request. The reference service cluster includes the cluster where the management node is located. The management node can perform upgrade management on the cluster where the management node is located through this cluster upgrade method.

[0078] Step 102: Send a start instruction to the upgrade control node corresponding to each target service cluster.

[0079] The start instruction is sent to the upgrade control node corresponding to each target service cluster, so that the upgrade control node performs the cluster upgrade operation for the target service cluster based on the upgrade configuration file of the target service cluster.

[0080] In an embodiment of the present application, the upgrade control node is a node arranged to implement the upgrade operation on the target service cluster. After the management node determines the target service cluster, it sends a start instruction to the upgrade control node for performing the cluster upgrade operation of the target service cluster, so that the upgrade control node performs the cluster upgrade operation of the target service cluster to implement the service upgrade of the target service cluster.

[0081] Based on the foregoing embodiment, in other embodiments of the present application, before the management node executes step 102, it is further configured to execute the following steps: detecting the working status of each target service cluster;

[0082] Correspondingly, step 102 can be implemented by the following steps: if the working state is a currently unexecuted task state, obtaining a cluster upgrade configuration corresponding to the corresponding target service cluster; and sending a startup instruction including the cluster upgrade configuration to the upgrade control node.

[0083] In an embodiment of the present application, the cluster upgrade configuration includes upgrade configuration parameters for initializing the upgrade control node. The working state of the target service cluster can be determined by detecting whether the target service cluster is currently executing a task. When the target service cluster is in a state of not currently executing a task, the management node obtains the cluster upgrade configuration corresponding to the target service cluster, generates a startup instruction based on the cluster upgrade configuration, and sends the startup instruction to the upgrade control node. In this way, the upgrade control node controls the locally deployed service cluster to perform an upgrade process according to the parameters indicated in the cluster upgrade configuration, and after each upgrade, the upgrade control node suspends, and when a new startup instruction is received, the parameters are updated to update the corresponding service cluster again.

[0084] It should be noted that the method of assigning the cluster upgrade configuration to the upgrade control node is only exemplary. The cluster upgrade configuration can also be issued through independent instructions. The upgrade control node can retain the cluster upgrade configuration according to actual needs. The embodiment of the present application does not impose any restrictions on the method of issuing and saving the cluster upgrade configuration.

[0085] Based on the foregoing embodiments, in other embodiments of the present application, the management node is also used to perform the following steps: obtain the upgrade configuration parameters of the corresponding target service cluster; generate a cluster upgrade configuration based on the upgrade configuration parameters; and store the cluster upgrade configuration in the configuration storage area.

[0086] In an embodiment of the present application, a method for statically configuring cluster upgrade configuration is provided, that is, the user sets the parameters for cluster upgrade configuration for the target service cluster based on the operation interface corresponding to the management node, so that the management node can obtain the upgrade configuration parameters for cluster upgrade of the target service cluster. In some application scenarios, other operable terminals may also be connected to the cluster management node for communication and send the upgrade configuration parameters of the target service cluster to the management node. After the management node obtains the upgrade configuration parameters of the target service cluster, it generates the cluster upgrade configuration of the target service cluster according to the upgrade configuration parameters, and stores the generated cluster upgrade configuration. This process can be implemented when the target service cluster is first registered, or it can be implemented by updating the upgrade configuration parameters of the target service cluster at regular intervals after the target service cluster is registered, or by setting the upgrade configuration parameters when the target service cluster needs to be upgraded.

[0087] Based on the foregoing embodiments, in other embodiments of the present application, the management node is also used to perform the following steps: if an upgrade registration request for a target service cluster is received, generate a cluster upgrade configuration based on the configuration parameters carried in the upgrade registration request; and store the cluster upgrade configuration in a configuration storage area.

[0088] In an embodiment of the present application, a method for dynamically configuring cluster upgrade configuration is provided, and a target service cluster may send an upgrade registration request for requesting upgrade registration to a management node, so that the management node generates a corresponding cluster upgrade configuration according to the upgrade registration request of the target service cluster. The upgrade registration request sent by the target service cluster may include configuration parameters of the target service cluster related to cluster performance, so that the target service cluster may send an upgrade registration request to the management node each time a change in cluster performance is detected, or the target service cluster may also send it according to a preset time period. In this way, the configuration parameters in the upgrade registration request are related to the real-time status of the target service cluster, thereby realizing dynamic configuration.

[0089] Based on the foregoing embodiment, in other embodiments of the present application, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0090] Based on the foregoing embodiments, in other embodiments of the present application, the task process content includes at least the upgrade tasks in the upgrade process, the task unit content includes at least the task unit for implementing each upgrade task, and the specific execution task content includes at least the basic tasks included in each task unit.

[0091] In an embodiment of the present application, the task process content included in the upgrade configuration file is used to define the upgrade tasks that need to be performed during the upgrade process, that is, the various stages of the upgrade; the task unit content is used to define the task unit of each upgrade task in the task process content; the specific execution task content is used to define the specific basic tasks included in each task unit. In other words, the task process is first divided into task execution stages, and each stage is defined as an upgrade task. In this way, a task process can include multiple upgrade tasks. Furthermore, each upgrade task can be divided into multiple task units. Furthermore, each task unit can also be implemented by multiple most basic and smallest tasks.

[0092] Based on the foregoing embodiment, in other embodiments of the present application, the format of the upgrade configuration file at least includes: another markup language YAML format.

[0093] Based on the foregoing embodiment, in other embodiments of the present application, the management node is further used to perform the following steps: during the process in which the upgrade control node performs a cluster upgrade operation on the target service cluster, each upgrade step performed by the upgrade control node is recorded to obtain an execution record.

[0094] In an embodiment of the present application, during the process of the upgrade control node performing a cluster upgrade operation for the target service cluster, the management node also records each upgrade step operation of the upgrade control node, so that fault detection can be performed when a fault occurs later, or if an upgrade failure occurs during the upgrade process, the upgrade can be suspended and the upgrade process can be continued from the upgrade interruption point.

[0095] Based on the foregoing embodiments, in other embodiments of the present application, when the management node executes steps to record each upgrade step performed by the upgrade control node, it can be achieved through the following steps: defining the upgrade operation of the target service cluster as a task flow; and recording each upgrade step in the task flow in the form of an activity.

[0096] In an embodiment of the present application, when recording each upgrade step performed by the upgrade control node, the management node can define the upgrade operation of the entire target service cluster as a task flow workflow, and record each upgrade step in the form of an activity in the task flow, so that it is convenient to query later when needed.

[0097] Based on the foregoing embodiments, in other embodiments of the present application, the management node is also used to perform the following steps: during the cluster upgrade operation, if it is detected that the faulty cluster has recovered from the fault, a continue upgrade instruction is sent to the upgrade control node corresponding to the faulty cluster to control the faulty cluster to continue the upgrade operation.

[0098] In an embodiment of the present application, the management node monitors the status of the clusters in the cluster system. When the fault recovery of the faulty cluster is detected, the management node sends a continue upgrade instruction to the upgrade control node corresponding to the faulty cluster, thereby controlling the faulty cluster to continue the cluster upgrade operation until the faulty cluster upgrade is completed. In some application scenarios, multiple service cluster upgrade operations may be performed simultaneously. In this case, when a service cluster upgrade fails, it does not affect the upgrade operations of other clusters. In this case, after the management node detects the fault recovery of the faulty cluster, the management node directly controls the faulty cluster to continue the cluster upgrade. However, in some application scenarios, when the clusters in the cluster system are upgraded in sequence, when a cluster fails and the subsequent service clusters no longer perform the upgrade operation, after the fault recovery of the faulty cluster, the management node controls the cluster upgrade operation to continue starting from the faulty cluster.

[0099] It should be noted that when, during the process of the upgrade control node executing the cluster upgrade operation, an upgrade failure occurs in the service cluster or the upgrade control node, such as power outage, downtime, restart and other abnormal conditions, resulting in the interruption of the upgrade process, it may be that the upgrade control node notifies the management node that the cluster has a failure or the corresponding upgrade control node has a failure, or it may be that the management node actively monitors it. Similarly, when the corresponding failed cluster failure recovers, it may be that the corresponding upgrade control node notifies the management node, or it may be that the management node actively monitors it. The specific situation can be determined by the actual situation and is not specifically limited here.

[0100] Based on the foregoing embodiment, in other embodiments of the present application, the management node is further used to perform the following steps: receiving database configuration parameters; and storing execution records in a target database indicated by the database configuration parameters.

[0101] In an embodiment of the present application, the management node supports various types of databases. Therefore, after receiving the database configuration parameters specified by the user, the management node stores the generated execution records in the target database indicated by the database configuration parameters, so that when subsequent queries are needed, the activity under the task flow of the target service cluster can be queried from the target database for subsequent analysis.

[0102] Based on the foregoing embodiment, in other embodiments of the present application, the management node is further used to perform the following steps: determine the upgrade status of the upgrade step currently executed by the upgrade control node; and generate prompt information based on the upgrade status.

[0103] In an embodiment of the present application, when the upgrade control node performs a cluster upgrade operation for the target service cluster, the management node also determines the upgrade status of the current upgrade step executed by the upgrade control node, and generates prompt information based on the determined upgrade status. In this way, the user can determine the execution progress of the service upgrade process for the target service cluster.

[0104] The cluster upgrade method provided by the embodiment of the present application is that the management node obtains an upgrade request for requesting an upgrade of the target service cluster, determines one or more target service clusters from at least one reference service cluster managed based on the upgrade request, and sends a startup instruction to the upgrade control node corresponding to each target service cluster, so that the upgrade control node receives the startup instruction sent by the management node, responds to the startup instruction, obtains the upgrade configuration file of the corresponding target service cluster, and performs a cluster upgrade operation for the target service cluster based on the upgrade configuration file. In this way, the management node starts the upgrade control node used to manage and control the service cluster to control the corresponding target upgrade control node to perform a cluster upgrade operation on the corresponding target service cluster, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade, and proposes a method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster, which reduces the complexity of development and management of the XaaS service cluster, and achieves cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, thereby improving the adaptability and scalability of the upgrade operation.

[0105] Based on the above embodiments, the embodiments of the present application provide a cluster upgrade method, referring to Figure 2 As shown, the method is applied to upgrade the control node, and the method includes the following steps:

[0106] Step 201: Receive a startup instruction sent by a management node.

[0107] The start instruction is generated by the management node based on an upgrade request for requesting to upgrade the target service cluster.

[0108] In an embodiment of the present application, the management node and the upgrade control node may be two independent execution nodes, or two execution functions in one execution object. The specific details may be determined by the actual application scenario. The management node and the upgrade control node communicate through a communication channel between the two. After receiving the upgrade request of the target service cluster, the management node generates a corresponding startup instruction and sends the startup instruction to the upgrade control node.

[0109] In some application scenarios, the startup instruction can also be obtained by the upgrade control node from the management node in an access read manner. That is to say, at this time, the service cluster can be upgraded spontaneously, and the corresponding service cluster calls the corresponding upgrade control node, and the upgrade control node obtains the cluster upgrade configuration from the management node, and then performs subsequent upgrade operations. The corresponding subsequent upgrade steps are consistent with the steps of other embodiments. In this way, whether the cluster upgrade configuration is obtained by the startup instruction or the upgrade control node actively obtains it from the management node is implemented by the actual application scenario, and is not specifically limited here.

[0110] Step 202: Respond to the start instruction and obtain the upgrade configuration file of the corresponding target service cluster.

[0111] In the embodiment of the present application, the upgrade control node responds to the startup instruction, responds to the startup instruction, and obtains the upgrade configuration file corresponding to the target service cluster. In some application scenarios, the upgrade configuration file can be pre-stored in the corresponding storage area, or it can be obtained by the user uploading according to the upload prompt information after the upload prompt information is generated when the upgrade control node is executed. The specific method can be determined according to the actual situation.

[0112] Step 203: Based on the upgrade configuration file, perform a cluster upgrade operation on the target service cluster.

[0113] In the embodiment of the present application, after the upgrade control node obtains the upgrade configuration file, it performs cluster upgrade on the target service cluster according to the upgrade configuration file to implement upgrade processing on the target service cluster.

[0114] Based on the foregoing embodiment, in other embodiments of the present application, step 202 may be implemented by the following steps: responding to a startup instruction, obtaining a cluster upgrade configuration from the startup instruction; and obtaining an upgrade configuration file after initialization processing based on the cluster upgrade configuration.

[0115] In an embodiment of the present application, before the upgrade control node receives the startup instruction sent by the management node, the upgrade control node is in a dormant state, so that resource consumption can be reduced. After the upgrade control node receives the startup instruction sent by the management node, it parses the startup instruction and obtains the cluster upgrade configuration for the target service cluster. Then, the upgrade control node initializes itself according to the cluster upgrade configuration in the startup instruction, and after completing the initialization process, the upgrade control node obtains the upgrade configuration file. Among them, the upgrade configuration file can be sent by the management node to the upgrade control node, or it can be obtained by the upgrade control node from the storage area specified by the management node.

[0116] Based on the foregoing embodiment, in other embodiments of the present application, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0117] Based on the foregoing embodiment, in other embodiments of the present application, the format of the upgrade configuration file at least includes: another markup language YAML format.

[0118] Based on the foregoing embodiments, in other embodiments of the present application, the upgrade control node is further used to perform the following steps: after a target service cluster fails to become a faulty cluster and fails back, if a continue upgrade instruction sent by the management node is detected, a corresponding execution record is determined; wherein the execution record is used to record the execution steps of the cluster upgrade operation of the faulty cluster; based on the execution record, the execution interruption position is determined; starting from the execution interruption position, based on the upgrade configuration file, the cluster upgrade operation for the faulty cluster is continued.

[0119] In an embodiment of the present application, exemplarily, during the process of the upgrade control node executing the cluster upgrade operation, an upgrade failure occurs in the target service cluster or the upgrade control node, such as power outage, downtime, restart and other abnormal conditions, resulting in the interruption of the upgrade process, the upgrade control node monitors whether the failure is restored. If the failure is detected to be restored and a continue upgrade instruction is received from the management node, the upgrade control node determines the execution record during the upgrade of the faulty cluster, and then determines the execution interruption position when upgrading the faulty cluster based on the execution record, and continues to execute the cluster upgrade operation for the faulty cluster from the execution interruption position until the upgrade of the faulty cluster is completed.

[0120] Based on the foregoing embodiments, in other embodiments of the present application, when the upgrade control node executes the step of detecting a continue upgrade instruction sent by the management node and determining the corresponding execution record, it can be achieved through the following steps: if a continue upgrade instruction sent by the management node is detected, determine the database configuration parameters of the fault cluster indicated in the continue upgrade instruction; determine the target database based on the database configuration parameters; and obtain the execution record from the target database.

[0121] In an embodiment of the present application, when the execution record is stored in the database, the upgrade control node is also allowed to access the database. Therefore, when the upgrade control node receives a continue upgrade instruction after determining that the fault has been recovered, the cluster information of the fault cluster is determined from the continue upgrade instruction, and its database configuration parameters are determined based on the cluster information. Then, the target database can be determined through the database configuration parameters to obtain the execution record of the target service cluster upgrade from the target database. In this way, the upgrade control node continues the upgrade from the point where the fault was interrupted based on the execution record, thereby improving the cluster upgrade efficiency and ensuring the user experience.

[0122] In the cluster upgrade method provided by the embodiment of the present application, the upgrade control node receives the startup instruction sent by the management node, responds to the startup instruction, obtains the upgrade configuration file of the corresponding target service cluster, and executes the cluster upgrade operation for the target service cluster based on the upgrade configuration file. In this way, the management node starts the upgrade control node used to manage and control the service cluster to control the corresponding target upgrade control node to perform cluster upgrade operations on the corresponding target service cluster, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade. A method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster is proposed, which reduces the complexity of development and management of the XaaS service cluster, realizes cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, and improves the adaptability and scalability of the upgrade operation.

[0123] Based on the above embodiments, the present application embodiment provides an application scenario diagram of a management node and an upgrade control node, which is applied to an XaaS basic platform base that provides basic capabilities and general capabilities for upper-layer diversified XaaS services. For example, Figure 3 As shown, the XaaS basic platform base provides a container service platform, an artificial intelligence (AI) service platform and other XaaS service platforms. The container service platform includes service A and service B, the AI ​​service platform includes service C and service D, and other XaaS service platforms include service E and service F. The XaaS basic platform base also includes an upgrade framework service for upgrading the cluster, and the upgrade framework service is implemented by the management node and the upgrade control node. Among them, each service in each service platform is implemented by a cluster. Exemplarily, the container service platform manages multiple user clusters and belongs to a XaaS application platform that provides a container orchestration application platform, that is, it provides a k8s container platform to manage the user's containerized program. The AI ​​service platform is used to provide customers with an XaaS application platform for establishing a variety of heterogeneous AI computing power platforms. The AI ​​service platform may manage graphics processing unit (GPU) computing power clusters of various architectures. It should be noted that each cluster of each XaaS application platform supports independent upgrades.

[0124] During the implementation process, the management node can be implemented by the upgrade module upgrade-manager to process user requests. After the upgrade module upgrade-manager receives the user request from the user interface (UI), it determines the target XaaS service platform to be upgraded according to the parameter serviceType passed in. The upgrade-manager will check whether there is a task being executed on the target XaaS service platform. If no task is being executed, the maintenance mode of the target XaaS service platform will be turned on. The specific process of turning on the target XaaS service platform is as follows: according to the serviceType parameter, the upgrade-manager determines the upgrade control node of the target XaaS service platform, and starts the upgrade control node of the control plane. When the upgrade control node is started, it reads the corresponding configuration file, which defines the configuration file of the XaaS control plane base. The upgrade control node can be implemented, for example, by the upgrade-server service, that is, the upgrade-server is an executor for upgrading the cluster included in the XaaS basic platform base.

[0125] In the above implementation process, if Figure 4 As shown, for different XaaS application platform data planes, i.e., corresponding user clusters, upgrade-manager identifies the type of XaaS service platform of the data plane, i.e., the user cluster, that needs to be upgraded based on the serviceType parameter passed in by the front-end UI. For example, upgrade-manager can start upgrade-server through the helm command, and execute different configuration files through parameters, so as to pull up upgrade-server in each user cluster as the upgrade executor of the XaaS application platform. The corresponding configuration file can be the upgrade package selected for upload in the user interface. After the upgrade package is uploaded, the user can click Next. In this way, upgrade-manager sends the upgrade package to upgrade-server, and upgrade-server can check and prepare the upgrade package. Differentiated checks and preparations are performed for upgrade packages of different platforms. All differences in the upgrade process are defined by the configuration files, and specific tasks are sent by the upgrade-server to the corresponding task center for execution.

[0126] When the upgrade-manager starts the upgrade-server, the upgrade-server needs to be initialized. Different XaaS service platforms have different upgrade configuration parameters, such as target XaaS upgrade service, upgrade task file, upgrade package storage location, system version file, and the way to enter maintenance mode. These are different parameters that may be required by different XaaS services in a certain XaaS service platform. Usually, these parameters can be saved in a database, such as a database that is suitable for all types. For example, Figure 5 As shown, the upgrade-manager specifies the XaaS service type serviceType that needs to be upgraded in the user request provided by the UI, for example, the upgrade request for the Hypertext Transfer Protocol (HTTP) service, and then the upgrade-manager reads the upgrade configuration parameters of the target XaaS service platform from the database according to the parameter serviceType in the user request, and then initializes the corresponding upgrade-server, and then starts the upgrade-server. Exemplarily, the serviceType parameter for the AI ​​service platform can be recorded as AICP, then the upgrade-server can obtain the upgrade configuration parameters of the AI ​​service platform from the corresponding database according to AICP, so that the upgrade-server is initialized according to the obtained upgrade configuration parameters to realize the upgrade service of the AI ​​service platform. In this way, through the above configuration, the upgrade-manager can be compatible with the upgrade services of multiple XaaS platforms at the same time.

[0127] Different XaaS service platforms have different upgrade configuration parameters, which can be configured and added in the following two ways:

[0128] (1) Add upgrade configuration parameters for different XaaS service platforms through static configuration. The specific implementation process can be: by modifying the configuration file of upgrade-manager, that is, modifying the upgrade-manager.yaml file read when upgrade-manager starts. This upgrade-manager.yaml configuration file includes fields for configuring upgrade configuration parameters for different XaaS service platforms. In this way, after modifying this upgrade-manager.yaml file, when upgrade-manager starts, it reads the configuration in the modified upgrade-manager.yaml file and writes it into the database. In this way, the static registration method is completed.

[0129] (2) Adding upgrade configuration parameters of different XaaS service platforms through dynamic configuration. The specific implementation process can be: after the upgrade-manager receives the dynamic registration request sent by the UI for dynamically registering new XaaS service upgrade configuration requirements, it registers new upgrade configuration parameters of the XaaS service platform according to the dynamic registration request. In other words, whenever a new XaaS service configuration is added, the new upgrade configuration parameters can be registered through the HTTP service request provided by the upgrade-manager, and the new XaaS service upgrade parameters can be added to the request body, i.e., the body parameter, in the HTTP service request.

[0130] In this way, through static registration and dynamic registration, the upgrade framework upgrade-manager can complete the upgrade service adaptation of the new XaaS service with very little workload.

[0131] When performing a service cluster upgrade, Figure 6 As shown in the figure, each cluster upgrade process at least includes the steps of entering the upgrade, checking the upgrade environment, uploading the upgrade package, verifying the upgrade package, starting the upgrade, and completing the upgrade. The upgrade-manager has an upgrade state machine transition mechanism for each cluster (including the control plane cluster and the user clusters of various XaaS services), and the control plane cluster and the user clusters of various XaaS services use the same upgrade state machine transition mechanism.

[0132] Exemplarily, the upgrade status of each cluster can be defined as the Pending state when it is to be upgraded. After the cluster enters the upgrade, the upgrade-manager starts the upgrade-server of each cluster according to the configuration file. At this time, it can be defined as the initEnving state. After the upgrade-server of a certain cluster is successfully started, it can be defined as the initEnvSuccess state. Then, the upgrade-server performs environmental detection operations for different clusters according to the configuration file. When the environmental detection is successful, it can be defined as the checkEnvSuccess state. Next, if the user clicks to upload the upgrade file to obtain the configuration file, in the process of uploading the upgrade file, it can be defined as the Uploading state. When waiting to upload the upgrade package to the target XaaS service cluster, it can be defined as the uploadSuccess state. Then, in the UI, when the user clicks to detect the upgrade package file and prepare for the upgrade, it can be defined as preparing. At this time, the upgrade-server executes the tasks of detecting the upgrade package file and preparing for the upgrade. After the upgrade-server successfully executes the tasks of detecting the upgrade package and preparing for the upgrade, it can be defined as the prepareSuccess state. If the user clicks Start Upgrade on the interface, it can be defined as the Upgrading state. After upgrade-server successfully executes the upgrade task, it can be defined as the upgradeSuccess state. When the upgrade is completed or when you click Exit Upgrade during the upgrade process, the cluster will be rolled back and cleaned up for all changes made during the upgrade, such as exiting maintenance mode, deleting upgrade package files, etc. At this time, it can be defined as the reverting state. After the cleanup is successful, it can be defined as the revertSuccess state, and then switch to the pending state.

[0133] The specific commonality and differences of different XaaS services can be reflected through configuration files. In one implementation process, the commonality of different XaaS services can be defined through three configuration sub-files, such as processes.yaml, units.yaml, and tasks.yaml, to define the tasks that need to be performed in the entire upgrade process. These three configuration sub-files can be registered to upgrade-manager and upgrade-server in a variety of ways: one way is to deploy them to different XaaS directories when installing the system; another way is to upload the upgrade package file, that is, the upgrade package will re-update and register these three files; the third way is for upgrade-manager to provide an application programming interface (API) registration form to dynamically register the three configuration files to the system.

[0134] Among the three configuration sub-files, one file is used to define the task process, such as processes.yaml file, which specifically defines the upgrade stage, such as pre-check, upgrade, exit upgrade and other processes. Another file is used to define task units, such as units.yaml file, which specifically represents what task units are to be performed in each stage, such as pre-check, upgrade, exit upgrade and other stages. For example, in the pre-check stage, different units can be divided according to different check items. For example, checking whether the machine resources are sufficient can be used as a unit, and checking whether the machine version supports upgrade can be used as a unit. The third file is used to define the specific tasks to be performed, such as tasks.yaml, that is, each unit can contain multiple tasks. For example, checking whether the machine resources are sufficient can be used as a task, checking the central processing unit (CPU) resources of the machine can be used as a task, checking the memory resources of the machine can be used as a task, checking the storage space of the machine can be used as a task, and so on. It should be noted that the upgrade framework, including upgrade-manager and upgrade-server, has the following requirements for the configuration files of different XaaS services: First, there needs to be a configuration file including the above three aspects to define the upgrade steps of the entire system. When the task is not needed, tasks.yaml can be defined as an empty script; second, the format of the configuration file must conform to the format of the yaml suffix file. In the above three configuration sub-files, the multiple units defined in processes.yaml need to be found in units.yaml, and the multiple tasks defined in units.yaml need to find the corresponding specific definitions in tasks.yaml. In this way, by calling the above configuration files, the differentiated task requirements of different XaaS service platforms can be met.

[0135] Furthermore, in the upgrade scenario, the upgrade process of each cluster can be defined as a workflow, and each upgrade step can be defined as an activity, and each activity has a fine granularity and can be reentrant. In this way, if the cluster encounters abnormal events such as power outage, downtime, and restart during the upgrade process, after the abnormal recovery, the upgrade framework can automatically restore the upgrade workflow of the cluster and resume running from the breakpoint. In other words, each request and step of the upgrade is defined as a workflow at the upgrade-manager level of the upgrade framework, and each workflow contains multiple activities. The purpose of defining it as a workflow is to ensure that after a workflow is created, it will be executed to completion, whether it is successfully executed or failed. For example, when workflowA is started, the task engine will record the startup status of workflowA in the local database. If workflowA encounters abnormal situations such as power outage, machine restart, downtime, etc. when executing activityB, the local database will record that activityB of workflowA has not been completed. After abnormal recovery, the upgrade-manager will first identify the cluster that has not completed the cluster upgrade, and then notify the task engine of the upgrade-server of the cluster to traverse the database, continue to execute all unfinished workflows, and recover at the breakpoint. In this way, it has sufficient robustness and recovery mechanism, reduces the impact on the business, and ensures the stability and fault tolerance of the upgrade process.

[0136] Furthermore, in order to make the upgrade framework more universal and adaptable to various types of databases, the configuration file can be used to define what type of database the upgrade framework uses to record the upgrade records of each cluster. That is, the database abstraction layer of the upgrade framework, such as upgrade-manager, allows different types of databases to be selected according to the configuration file. In this way, the upgrade framework can be compatible with various databases to meet the needs of different environments.

[0137] In this way, the service upgrade framework of the management node and the upgrade control node can be applied to the upgrade application of any XaaS service, and can effectively improve the development efficiency in the subsequent expansion of the XaaS service platform. Through minimal code modification and registration mechanism, the upgrade framework service can be quickly applied to the upgrade of new XaaS services, saving a lot of development time and cost; and the upgrade framework supports concurrent upgrades of multiple clusters, heterogeneous cluster upgrades, cascade upgrades between clusters, cluster expansion upgrades, node expansion upgrades and other functions; further, the upgrade framework supports component upgrades of multiple clusters, including component upgrades of container management platforms such as kubernetes / Docker Swarm / Mesos / OpenShift / Rancher / Portainer, cluster version upgrades, system component upgrades, operating system (Operating System, OS) upgrades, driver upgrades, etc. of the above container management platforms; it realizes the decoupling of business upgrade tasks and framework upgrade tasks, so that business development and framework development can pay more attention to the development and evolution of their own modules, and also realizes the task level, host level, and cluster level upgrade task orchestration, solving the upgrade dependency problem of traditional upgrade frameworks. During the implementation process, the upgrade framework has good robustness. When abnormal recovery is achieved after abnormalities such as host downtime, host power outage, and host restart, the upgrade task can be automatically continued from the upgrade breakpoint. Because the upgrade framework is highly versatile, it can be widely used in other XaaS service platforms, providing the industry with a flexible and efficient upgrade solution. There is no need to develop and maintain the upgrade framework separately for each platform, thereby reducing the complexity of development and management. At the same time, the framework also supports differential configuration, which can be flexibly configured according to the characteristics and requirements of different platforms, improving the adaptability and scalability of the upgrade. Such a universal upgrade framework will greatly reduce manpower and time costs, improve development efficiency and system maintainability.

[0138] Based on the above embodiments, the present application provides a first cluster upgrade device, which is applied to a management node. The first cluster upgrade device 3 can be applied to Figures 1-2 And the corresponding embodiments, refer to Figure 7 As shown, the first cluster upgrade device 3 includes: a first determination unit 31 and a first sending unit 32; wherein:

[0139] A first determining unit 31 is configured to determine one or more target service clusters from at least one managed reference service cluster if an upgrade request is detected; wherein the target service cluster includes at least one cluster for providing different services; and an upgrade request for requesting an upgrade of the target service cluster;

[0140] The first sending unit 32 is configured to send a start instruction to an upgrade control node corresponding to each target service cluster, so that the upgrade control node performs a cluster upgrade operation for the target service cluster based on the upgrade configuration file of the target service cluster.

[0141] In other embodiments of the present application, before the first sending unit, the first cluster upgrading device further includes: a detection unit; wherein:

[0142] A detection unit, used to detect the working status of each target service cluster;

[0143] Correspondingly, the first sending unit is specifically used to implement the following steps:

[0144] If the working status is the current unexecuted task status, obtain the cluster upgrade configuration corresponding to the corresponding target service cluster;

[0145] Send a startup instruction including the cluster upgrade configuration to the upgrade control node.

[0146] In other embodiments of the present application, the first cluster upgrade device further includes: a first acquisition unit, a first generation unit and a first storage unit; wherein:

[0147] A first acquisition unit, used to acquire the upgrade configuration parameters of the corresponding target service cluster;

[0148] A first generating unit, configured to generate a cluster upgrade configuration based on the upgrade configuration parameters;

[0149] The first storage unit is used to store the cluster upgrade configuration in the configuration storage area.

[0150] In other embodiments of the present application, the first cluster upgrade device further includes: a second generation unit and a second storage unit; wherein:

[0151] A second generating unit is configured to generate a cluster upgrade configuration based on configuration parameters carried in the upgrade registration request if an upgrade registration request for a target service cluster is received;

[0152] The second storage unit is used to store the cluster upgrade configuration in the configuration storage area.

[0153] In other embodiments of the present application, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0154] In other embodiments of the present application, the task process content includes at least the upgrade tasks in the upgrade process, the task unit content includes at least the task unit for implementing each upgrade task, and the specific execution task content includes at least the basic tasks included in each task unit.

[0155] In other embodiments of the present application, the format of the upgrade configuration file at least includes: another markup language YAML format.

[0156] In other embodiments of the present application, the first cluster upgrade device further includes: a recording unit; wherein:

[0157] The recording unit is used to record each upgrade step executed by the upgrade control node during the cluster upgrade operation performed by the upgrade control node on the target service cluster to obtain an execution record.

[0158] In other embodiments of the present application, the first sending unit is further used to send a continue upgrade instruction to the upgrade control node corresponding to the faulty cluster to control the faulty cluster to continue the upgrade operation if it is detected that the faulty cluster has recovered during the cluster upgrade operation.

[0159] In other embodiments of the present application, the recording unit is specifically used to implement the following steps:

[0160] Define the upgrade operation of the target service cluster as a task flow;

[0161] Record each upgrade step into the task flow in the form of an activity.

[0162] In other embodiments of the present application, the first cluster upgrade device further includes: a third storage unit; wherein:

[0163] The first acquisition unit is further used to receive database configuration parameters;

[0164] The third storage unit is used to store the execution record in the target database indicated by the database configuration parameter.

[0165] In other embodiments of the present application, the first determining unit is further used to determine the upgrade state to which the upgrade control node currently executes the upgrade step;

[0166] The generating unit is further used to generate prompt information based on the upgrade status.

[0167] It should be noted that the information interaction process between the units and modules in this embodiment can refer to the information interaction process described in the aforementioned method embodiment, which will not be repeated here.

[0168] In the first cluster upgrade device provided by the embodiment of the present application, the management node obtains an upgrade request for requesting an upgrade of the target service cluster, determines one or more target service clusters from at least one reference service cluster managed based on the upgrade request, and sends a startup instruction to the upgrade control node corresponding to each target service cluster, so that the upgrade control node receives the startup instruction sent by the management node, responds to the startup instruction, obtains the upgrade configuration file of the corresponding target service cluster, and performs a cluster upgrade operation for the target service cluster based on the upgrade configuration file. In this way, the management node starts the upgrade control node used to manage and control the service cluster to control the corresponding target upgrade control node to perform a cluster upgrade operation on the corresponding target service cluster, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade, and proposes a method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster, which reduces the complexity of development and management of the XaaS service cluster, and achieves cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, thereby improving the adaptability and scalability of the upgrade operation.

[0169] Based on the above embodiment, the embodiment of the present application provides a second cluster upgrade device, which is applied to upgrade the control node. The second cluster upgrade device 4 can be applied to Figures 1-2 And the corresponding embodiments, refer to Figure 8 As shown, the second cluster upgrade device 4 includes: a receiving unit 41, a second acquisition unit 42 and an execution unit 43; wherein:

[0170] The receiving unit 41 is used to receive a startup instruction sent by the management node;

[0171] The second acquisition unit 42 is used to respond to the start instruction and acquire the upgrade configuration file of the corresponding target service cluster;

[0172] The execution unit 43 is used to execute a cluster upgrade operation for the target service cluster based on the upgrade configuration file.

[0173] In other embodiments of the present application, the second acquisition unit is specifically used to implement the following steps:

[0174] Respond to the startup instruction and obtain the cluster upgrade configuration from the startup instruction;

[0175] After initialization processing based on the cluster upgrade configuration, obtain the upgrade configuration file.

[0176] In other embodiments of the present application, the upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

[0177] In other embodiments of the present application, the format of the upgrade configuration file at least includes: another markup language YAML format.

[0178] In other embodiments of the present application, the second cluster upgrading device further includes: a second determining unit and a third determining unit; wherein:

[0179] A second determination unit is configured to determine a corresponding execution record if a continue upgrade instruction sent by the management node is detected after the target service cluster fails and becomes a faulty cluster and recovers from the failure; wherein the execution record is used to record the execution steps of the cluster upgrade operation of the faulty cluster;

[0180] The third determining unit is further used to determine the execution interruption position based on the execution record;

[0181] The execution unit is also used to continue the cluster upgrade operation from the execution interruption position based on the upgrade configuration file.

[0182] In other embodiments of the present application, the second determining unit is specifically used to implement the following steps:

[0183] If a continue upgrade instruction sent by the management node is detected, determining the database configuration parameters of the fault cluster indicated in the continue upgrade instruction;

[0184] Determine the target database based on database configuration parameters;

[0185] Get the execution records from the target database.

[0186] It should be noted that the information interaction process between the units and modules in this embodiment can refer to the information interaction process described in the aforementioned method embodiment, which will not be repeated here.

[0187] In the second cluster upgrade device provided by the embodiment of the present application, the upgrade control node receives the startup instruction sent by the management node, responds to the startup instruction, obtains the upgrade configuration file of the corresponding target service cluster, and performs the cluster upgrade operation for the target service cluster based on the upgrade configuration file. In this way, the management node starts the upgrade control node used to manage and control the service cluster to control the corresponding target upgrade control node to perform cluster upgrade operations on the corresponding target service cluster, which solves the problem that the code of the XaaS service cluster needs to be changed to achieve service upgrade. A method for cluster upgrading the corresponding service cluster without changing the code of the XaaS service cluster is proposed, which reduces the complexity of development and management of the XaaS service cluster, realizes cluster upgrade through flexible configuration according to the characteristics and requirements of different service clusters, and improves the adaptability and scalability of the upgrade operation.

[0188] Based on the above embodiments, the embodiments of the present application provide a cluster upgrade system, which can be applied to Figures 1-2 And the corresponding embodiments, refer to Fig. 9 As shown, the cluster upgrade system 5 at least includes: a management node 51 and at least one upgrade control node 52; wherein:

[0189] Management node 51 is used to implement Figures 1-2 The cluster upgrade method provided in the corresponding embodiment will not be described in detail here;

[0190] Upgrade control node 52, used to implement Figures 1-2 The cluster upgrade method provided by the corresponding embodiment will not be described in detail here.

[0191] It should be noted that the upgrade control node can be deployed locally in the user cluster, and the corresponding management node can be deployed in the control plane cluster. The management node and the upgrade control node can communicate through the cloud ladder agent. This deployment scheme enables the upgrade control node to communicate locally with the user cluster locally in the user cluster, reducing the communication delay between the upgrade control node and the user cluster, and improving the upgrade efficiency of the user cluster. Alternatively, in some application scenarios, both the upgrade control node and the management node can be deployed on the control plane cluster. Here, when the management node and the upgrade control node are deployed on the control plane cluster, there is no need to communicate through the cloud ladder, which reduces the communication delay and ensures the communication efficiency between the two. The above deployment method can be determined by the actual application scenario and is not specifically limited here.

[0192] During the application implementation process, the management node and the upgrade control node can be implemented through a hardware module or a software module. The specific application implementation method of the management node and the upgrade control node can be determined by the actual application scenario and is not specifically limited here.

[0193] Based on the foregoing embodiments, the embodiments of the present application provide a computer-readable storage medium, referred to as a storage medium, which stores one or more cluster upgrade methods. The one or more cluster upgrade methods can be executed by one or more processors to implement the following. Figure 1 and corresponding embodiments, or Figure 2 The cluster upgrade method provided by the corresponding embodiment will not be described in detail here.

[0194] Based on the foregoing embodiments, the embodiments of the present application provide a computer-readable storage medium, referred to as a storage medium, which stores one or more programs, and the one or more programs can be executed by one or more processors to implement reference Figure 1 and corresponding embodiments, or Figure 2The implementation process of the method provided in the corresponding embodiment will not be repeated here.

[0195] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0196] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0197] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, ..., an air conditioner, or a network communication link device, etc.) to execute the methods described in each embodiment of the present application.

[0198] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0199] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0200] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0201] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A cluster upgrade method, characterized in that: The method is applied to a management node, and the method comprises: If an upgrade request is detected, determining one or more target service clusters from at least one reference service cluster being managed; wherein the upgrade request is used to request upgrade processing of one or more of the target service clusters; A start instruction is sent to an upgrade control node corresponding to each of the target service clusters, so that the upgrade control node performs a cluster upgrade operation for the target service cluster based on the upgrade configuration file of the target service cluster.

2. The method according to claim 1, characterized in that Before sending the start instruction to the upgrade control node corresponding to each target service cluster, the method further includes: Detecting the working status of each of the target service clusters; Correspondingly, the sending of the start instruction to the upgrade control node corresponding to each of the target service clusters includes: If the working status is a currently unexecuted task status, obtaining a cluster upgrade configuration corresponding to the corresponding target service cluster; Sending a startup instruction including the cluster upgrade configuration to the upgrade control node.

3. The method according to claim 2, characterized in that The method further comprises: When static configuration is adopted, obtaining the upgrade configuration parameters of the corresponding target service cluster; Based on the upgrade configuration parameters, generate the cluster upgrade configuration; The cluster upgrade configuration is stored in a configuration storage area.

4. The method according to claim 2, characterized in that: The method further comprises: When dynamic configuration is adopted, if an upgrade registration request for the target service cluster is received, generating the cluster upgrade configuration based on the configuration parameters carried in the upgrade registration request; The cluster upgrade configuration is stored in a configuration storage area.

5. The method according to claim 1, characterized in that The upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

6. The method according to claim 5, characterized in that The task process content includes at least the upgrade tasks in the upgrade process, the task unit content includes at least the task unit for implementing each of the upgrade tasks, and the specific execution task content includes at least the basic tasks included in each of the task units.

7. The method according to claim 1, characterized in that The method further comprises: During the process in which the upgrade control node performs the cluster upgrade operation for the target service cluster, each upgrade step performed by the upgrade control node is recorded to obtain an execution record.

8. The method according to claim 7, characterized in that The recording of each upgrade step executed by the upgrade control node to obtain the execution record includes: Defining the upgrade operation of the target service cluster as a task flow; Each of the upgrade steps is recorded in the task flow in the form of an activity to obtain the execution record.

9. The method according to claim 8, characterized in that The method further comprises: During the cluster upgrade operation, if it is detected that the faulty cluster recovers from the fault, a continue upgrade instruction is sent to the upgrade control node corresponding to the faulty cluster to control the faulty cluster to continue the upgrade operation.

10. The method according to claim 7, characterized in that The method further comprises: Receive database configuration parameters; The execution record is stored in the target database indicated by the database configuration parameter.

11. The method according to claim 7, characterized in that The method further comprises: Determine the upgrade status of the upgrade control node to which the upgrade step currently executed belongs; Based on the upgrade status, prompt information is generated.

12. A cluster upgrade method, characterized in that: The method is applied to upgrading a control node, and the method comprises: Receiving a startup instruction sent by a management node; wherein the startup instruction is generated by the management node based on an upgrade request for requesting an upgrade of a target service cluster; In response to the startup instruction, obtain an upgrade configuration file of the corresponding target service cluster; Based on the upgrade configuration file, a cluster upgrade operation is performed on the target service cluster.

13. The method according to claim 12, characterized in that The step of responding to the startup instruction and obtaining the upgrade configuration file of the corresponding target service cluster includes: Responding to the startup instruction, obtaining a cluster upgrade configuration from the startup instruction; After initialization processing is performed based on the cluster upgrade configuration, the upgrade configuration file is obtained.

14. The method according to claim 12, characterized in that The upgrade configuration file includes at least the following three parts: task process content, task unit content and specific execution task content.

15. The method according to claim 12, characterized in that The method further comprises: After the target service cluster fails and becomes a faulty cluster and recovers from the failure, if a continue upgrade instruction sent by the management node is detected, a corresponding execution record is determined; wherein the execution record is used to record the execution steps of the cluster upgrade operation of the faulty cluster; Based on the execution record, determining an execution interruption location; Starting from the execution interruption position, based on the upgrade configuration file, the cluster upgrade operation for the faulty cluster is continued.

16. The method according to claim 15, characterized in that If the continuing upgrade instruction sent by the management node is detected, determining the execution record of the corresponding fault cluster includes: If a continue upgrade instruction sent by the management node is detected, determining the database configuration parameters of the fault cluster indicated in the continue upgrade instruction; Based on the database configuration parameters, determining a target database; The execution record is obtained from the target database.

17. A first cluster upgrade device, characterized in that: The device is applied to a management node, and comprises: a first determining unit and a first sending unit; wherein: The first determining unit is configured to determine one or more target service clusters from at least one managed reference service cluster if an upgrade request is detected; wherein the upgrade request is used to request upgrade processing of one or more of the target service clusters; The first sending unit is configured to send a start instruction to an upgrade control node corresponding to the target service cluster, so that the upgrade control node performs a cluster upgrade operation for the target service cluster based on an upgrade configuration file of the target service cluster.

18. A second cluster upgrade device, characterized in that: The device is applied to upgrade the control node, and is characterized in that the device comprises: a receiving unit, a second obtaining unit and an executing unit; wherein: The receiving unit is used to receive a startup instruction sent by the management node; The second acquisition unit is used to respond to the startup instruction and acquire the upgrade configuration file of the corresponding target service cluster; The execution unit is configured to execute a cluster upgrade operation for the target service cluster based on the upgrade configuration file.

19. A cluster upgrade system, characterized in that: The system at least comprises: a management node and at least one upgrade control node; wherein: The management node is used to implement the steps of the cluster upgrade method according to any one of claims 1 to 11; The upgrade control node is used to implement the steps of the cluster upgrade method according to any one of claims 12 to 16.

20. A storage medium, characterized in that: The storage medium stores a cluster upgrade program, and when the cluster upgrade program is executed by the processor, the steps of the cluster upgrade method according to any one of claims 1 to 11 or claims 12 to 16 are implemented.

21. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the steps of the cluster upgrade method according to any one of claims 1 to 11 or claims 12 to 16.

Images