Control method and device of cluster architecture, storage medium and electronic equipment

Abstract

The embodiment of the application provides a cluster architecture control method and device, a storage medium and an electronic device, the cluster architecture control method comprises the following steps: selecting a first management node as a management node of a target node cluster from a group of candidate management nodes in the target node cluster, wherein the management node of the target node cluster is used for controlling a group of working nodes in the target node cluster, and the group of candidate management nodes and the group of working nodes are used for running containerized applications; assigning a virtual Internet Protocol (IP) address to the first management node, wherein the virtual IP address is an IP address used by an external program to access the management node of the target node cluster; in the case that the first management node fails, selecting a second management node as the management node of the target node cluster from other candidate management nodes except the first management node in the group of candidate management nodes, and assigning a virtual IP address to the second management node.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computers, and more specifically, to a control method and device for a cluster architecture, a storage medium, and an electronic device. Background Art

[0002] With the development of a new technological era, cloud computing is playing an increasingly important role. Migrating businesses to the cloud is no longer a novelty, and container cloud has been implemented by companies large and small. Kubernetes (an open-source application for managing containers across multiple hosts in a cloud platform, abbreviated as Kubernetes) is a portable and scalable open-source container orchestration platform. Due to its ease of scalability, consistent control, and open source nature, it has gradually become the de facto standard for cloud computing. Whether it's business applications, middleware services, or even distributed computing tasks, Kubernetes clusters can easily handle them.

[0003] However, in an ordinary k8s cluster, the k8s cluster can only be guaranteed to be highly available when a working node fails. But when the management node fails, the k8s api-server (call service) is unavailable, resulting in the entire cluster being leaderless and unable to proceed to the next step of normal operation. The entire k8s cluster will crash.

[0004] It can be seen from this that the control method of the cluster architecture in the related art has the problem of low availability of the cluster architecture. Summary of the Invention

[0005] The embodiments of the present application provide a cluster architecture control method and device, a storage medium, and an electronic device to at least solve the problem of low availability of the cluster architecture in the cluster architecture control method in the related art.

[0006] According to one embodiment of the present application, a method for controlling a cluster architecture is provided, comprising: selecting a first management node from a group of candidate management nodes in a target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and the group of candidate management nodes and the group of working nodes are both used to run containerized applications; allocating a virtual Internet Protocol IP address to the first management node, wherein the virtual IP address is an IP address used by external programs to access the management node of the target node cluster; in the event that the first management node fails, selecting a second management node from the other candidate management nodes in the group of candidate management nodes except the first management node as the management node of the target node cluster, and allocating the virtual IP address to the second management node.

[0007] According to another embodiment of the present application, a control device for a cluster architecture is provided, including: a selection unit, used to select a first management node from a group of candidate management nodes in a target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and the group of candidate management nodes and the group of working nodes are both used to run containerized applications; an allocation unit, used to allocate a virtual Internet Protocol IP address to the first management node, wherein the virtual IP address is an IP address used by external programs to access the management node of the target node cluster; a first execution unit, used to select a second management node from other candidate management nodes in the group of candidate management nodes except the first management node as the management node of the target node cluster in the event that the first management node fails, and allocate the virtual IP address to the second management node.

[0008] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any one of the above method embodiments when run.

[0009] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments.

[0010] Through the embodiments of the present application, a method of deploying multiple candidate management nodes in a cluster architecture is adopted, and a first management node is selected from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and a group of candidate management nodes and a group of working nodes are both used to run containerized applications; a virtual Internet Protocol IP address is assigned to the first management node, wherein the virtual IP address is the IP address used by external programs to access the management node of the target node cluster; in the event of a failure of the first management node, a second management node is selected from a group of candidate management nodes other than the first management node as the management node of the target node cluster, and a virtual IP address is assigned to the second management node. Since when a running management node fails, other candidate management nodes can be used as backups to ensure the normal operation of the entire cluster, thereby achieving the technical effect of improving the availability of the cluster architecture, and further solving the problem of low availability of the cluster architecture in the control method of the cluster architecture in the related art. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 1 is a schematic diagram of a hardware environment for a cluster architecture control method according to an embodiment of the present application;

[0012] Figure 2 is a flow chart of a cluster architecture control method according to an embodiment of the present application;

[0013] Figure 3 is a schematic diagram of a control method for a cluster architecture according to an embodiment of the present application;

[0014] Figure 4 is a schematic diagram of another cluster architecture control method according to an embodiment of the present application;

[0015] Figure 5 is a schematic diagram of another cluster architecture control method according to an embodiment of the present application;

[0016] Figure 6 is a schematic diagram of another cluster architecture control method according to an embodiment of the present application;

[0017] Figure 7 is a flow chart of another cluster architecture control method according to an embodiment of the present application;

[0018] Figure 8 This is a structural block diagram of a control device of a cluster architecture according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0020] It should be noted that the terms "first", "second", etc. in the description and claims of the embodiments of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0021] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a server or a similar computing device. Taking running on a server as an example, Figure 1 FIG. 1 is a schematic diagram of a hardware environment of a cluster architecture control method according to an embodiment of the present application. Figure 1 As shown, the server may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data, wherein the above-mentioned server may also include a transmission device 106 for communication functions and an input and output device 108. It will be understood by those skilled in the art that Figure 1The structure shown is only for illustration and does not limit the structure of the above server. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0022] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the control method of the cluster architecture in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0023] The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned network may include a wireless network provided by the server's communications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0024] According to one aspect of an embodiment of the present application, a cluster architecture control method is provided. Taking the cluster architecture control method of this embodiment executed by a server as an example, Figure 2 is a flow chart of a cluster architecture control method according to an embodiment of the present application. Figure 2 As shown, the process includes the following steps:

[0025] Step S202: Select a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are used to run containerized applications.

[0026] The cluster architecture control method in this embodiment can be applied to scenarios where a cluster architecture is deployed on an operations and maintenance platform. To ensure that the operations and maintenance platform can provide services and products to users without any interruption, thereby effectively retaining customers and reducing churn, it is necessary to ensure that the server cluster and key components in the operations and maintenance platform are highly available. Here, a cluster is a group of computers that, as a whole, provide a set of network resources to users. These individual computer systems are called nodes in the cluster. Clusters provide the following key features: scalability, high availability, load balancing, and error recovery. High availability is one of the factors that must be considered in the design of distributed system architectures. It generally refers to reducing the time that a system is unable to provide services through design. Server availability refers to the proportion of time a server is operational per unit of time (usually one year). Single points of failure are the biggest enemy of system high availability and are often the greatest risk and enemy of system high availability. They should be avoided as much as possible during the system design process. Methodologically, the principle of ensuring high availability is "clustering" or "redundancy."

[0027] The goal of high availability, as described above, is to provide continuous service with minimal downtime. This means that if one component fails, another can immediately take over its functionality without materially interrupting service to system users. Furthermore, high availability is the ability to detect when one or more components have failed and then take corrective action to restore them to service. High availability is crucial for businesses. As more and more of the things businesses use become increasingly reliant on continuous connectivity to other things, high availability becomes increasingly important.

[0028] High availability is a relatively complex proposition. Any daily changes such as service upgrades, hardware updates, data migrations, and sudden increases in traffic may cause service damage or even unavailability. Designing and running an application that takes into account scalability, portability, and robustness is a very challenging task, especially when the complexity of the system is constantly growing. The architecture of the application or system itself greatly affects how it operates, its dependence on the environment, and the strength of its coupling with related components. High availability is a basic requirement for the underlying IT infrastructure, which means that the cloud infrastructure has three requirements: fault tolerance (even if some errors occur, the underlying system still works), service availability (that is, services running on the cloud must always be available), and data security (that is, the data on the cloud is guaranteed to be sound and available).

[0029] Kubernetes (i.e., k8s) is a portable, scalable, open source container orchestration platform for managing containerized workloads and services, facilitating declarative configuration and automation, and has gradually become the de facto standard for cloud computing due to its easy scalability, consistent deployment, and open source features. Kubernetes is a typical master-slave distributed architecture, such as Figure 3 As shown, it consists of a centralized management node (Master Node), distributed worker nodes (Worker Node, or Work Node) and auxiliary tools. Whether it is business applications or middleware services, or even distributed computing tasks, the k8s cluster can easily handle them. However, the stable and highly available k8s cluster deployment in enterprise scenarios is not without challenges. For example, how can we improve our availability in terms of architecture and capabilities to reduce the probability and impact of system failures? How can we make some breakthroughs in core link performance and architecture to support such complex and changing business scenarios and the general needs of business growth? How can we prevent problems from happening again, do a good job of prevention, and avoid emergencies? How can we quickly discover, diagnose, and stop losses when emergencies occur?

[0030] In order to at least partially solve the above technical problems, a k8s cluster can be used to deploy the server of the operation and maintenance platform. Considering that in an ordinary k8s cluster, although the k8s cluster is highly available when a working node fails, when the management node fails, the k8s api-server (call service) is unavailable, resulting in the entire cluster having no leader and being unable to proceed to the next normal operation. The entire k8s cluster will crash. In this embodiment, a group of management nodes can be deployed, such as Figure 4 As shown, (the dotted line represents the connection between the standby management node and the working node) even if a management node has a problem, it will not affect other management nodes.

[0031] In this embodiment, a first management node can be selected from a set of candidate management nodes in the target node cluster as the management node of the target node cluster. The target node cluster can be the aforementioned Kubernetes cluster. The management node of the target node cluster can be used to control a set of worker nodes in the target node cluster. The set of candidate management nodes and the set of worker nodes can both be used to run containerized applications.

[0032] Considering the potential for voting competition among multiple candidate management nodes when determining the target node cluster, the total number of management nodes in the candidate management node group can be an odd number to avoid situations where there are tied votes. Furthermore, since more management nodes require more servers, to minimize server costs, the total number of management nodes in the candidate management node group can be a smaller odd number greater than 1, such as 3.

[0033] Step S204 : Allocate a virtual Internet Protocol IP address to the first management node, wherein the virtual IP address is an IP address used by an external program to access the management node of the target node cluster.

[0034] To improve the availability and security of the cluster, after selecting the first management node as the target management node, a virtual Internet Protocol IP address can be assigned to the first management node (i.e., a virtual IP address is assigned to the server corresponding to the first management node). Thus, when the server of the first management node fails, the virtual IP address can be used to transfer requests to other servers to achieve failover. At the same time, the use of the virtual IP address can protect the real IP address of the secure access server, thereby improving the security of the server. Here, the virtual IP address can be the IP address used by external programs to access the management node of the target node cluster.

[0035] Step S206 , when the first management node fails, select a second management node from a group of candidate management nodes other than the first management node as the management node of the target node cluster, and allocate a virtual IP address to the second management node.

[0036] In the event that the first management node fails, a second management node may be selected from a group of candidate management nodes other than the first management node as the management node of the target node cluster, and a virtual IP address may be allocated to the second management node.

[0037] For example, the MASTER machine (i.e., the server corresponding to the management node) will be assigned a designated virtual IP, through which external programs can access this server. If this server fails (disconnected, restarted, etc.), a new machine will be selected from other backup machines (i.e., servers) to be the MASTER machine and assigned the same virtual IP to play the role of the previous MASTER machine.

[0038] Since the design from the perspective of the application running in k8s assumes that the nodes are unreliable, the more nodes there are, the higher the probability of software and hardware failures, which in turn lead to node unavailability. In order to avoid affecting the normal use of services during the process of Kubernetes rescheduling and creating services when business services fail or Node nodes fail, in this embodiment, the multi-instance deployment principle can be adopted, that is, multiple replicas are deployed for the service, and the value of replicas (number of replicas) is adjusted according to the actual situation. If the value is 1, there will inevitably be a single point of failure. Therefore, different multi-instance deployment schemes can be adopted according to the cluster scale, high availability safety level requirements, business conditions, etc. In addition, if the value is greater than 1 but all replicas are scheduled to the same node, there is still a single point of failure. Therefore, we must not only have a reasonable number of replicas, but also schedule these different replicas to different nodes (that is, multiple different services can be deployed on one server, and replicas of the same service can be deployed on different servers). Spread them out to avoid single points of failure. This can be achieved by using anti-affinity.

[0039] Through the above steps, a first management node is selected from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are used to run containerized applications; a virtual Internet Protocol IP address is allocated to the first management node, wherein the virtual IP address is the IP address used by external programs to access the management node of the target node cluster; in the event of a failure of the first management node, a second management node is selected from a group of candidate management nodes other than the first management node as the management node of the target node cluster, and a virtual IP address is allocated to the second management node, which can solve the problem of low availability of the cluster architecture in the control method of the cluster architecture in the related technology, and achieve the technical effect of improving the availability of the cluster architecture.

[0040] In an exemplary embodiment, after selecting the first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, the method further includes:

[0041] S11, obtaining data to be stored, wherein the data to be stored is data to be stored in a storage component of a management node of a target node cluster;

[0042] S12, selecting at least two candidate management nodes from a group of candidate management nodes to obtain at least two third management nodes, and pushing the data to be stored to the storage components of the at least two third management nodes for storage; or,

[0043] S13: Select a candidate management node from the group of candidate management nodes to obtain a fourth management node, and push the data to be stored to a storage component of the fourth management node for storage, so that the storage component of the fourth management node pushes the data to be stored to storage components of at least some of the candidate management nodes in the group of candidate management nodes other than the fourth management node for storage;

[0044] The candidate management nodes where the corresponding storage component stores data to be stored include the first management node.

[0045] Considering that in the k8s cloud platform, in order to support business deployment and efficient operation in AI scenarios, some key components in the cluster also need to have high availability to ensure that the entire life cycle, from birth and cluster access to each change and offline, is controlled within the system's tolerance range. Here, these key components can be components used to store different data, including but not limited to: Harbor (image warehouse, used to store image files of AI applications), Mariadb (used to store metadata of the cloud platform in AI scenarios, such as cluster name, business name, etc.), NFS (Network File System, network file system), Ceph (a storage system that, like NFS, can be used as a storage provider for PV objects in the k8s cluster), ntpd (component for time synchronization), Ldap (component for managing user groups and user information), HDFS (model warehouse, used to store model files of AI applications (such as pytorch, tensorflow model files, etc.)).

[0046] In this embodiment, the target cluster can obtain the data to be stored in real time. Here, the data to be stored can be data to be stored in the storage component of the management node of the target node cluster.

[0047] According to the data synchronization method of different components, for the acquired data to be stored, at least two candidate management nodes can be selected from a group of candidate management nodes to obtain at least two third management nodes, and the data to be stored can be pushed to the storage components of at least two third management nodes for storage.

[0048] In addition, for the acquired data to be stored, a candidate management node can also be selected from a group of candidate management nodes to obtain a fourth management node, and the data to be stored can be pushed to the storage component of the fourth management node for storage, so that the storage component of the fourth management node can push the data to be stored to the storage components of at least some of the candidate management nodes in a group of candidate management nodes except the fourth management node for storage.

[0049] It should be noted that the candidate management node whose corresponding storage component stores the data to be stored may include the aforementioned first management node, that is, the selected storage component that stores the above data to be stored may be the storage component on the aforementioned first management node.

[0050] Through this embodiment, for the acquired data to be stored, the availability of the components in the cluster can be improved by selecting a component on a management node to save and synchronize it to the components on other management nodes, or by directly selecting the same component on two management nodes to synchronize and save the data. This can thereby improve the availability of the cluster architecture.

[0051] In an exemplary embodiment, in the process of selecting a candidate management node to store the acquired component of the data to be stored, the management node may be selected by load balancing or randomly.

[0052] S21, selecting at least two candidate management nodes from a group of candidate management nodes to obtain at least two third management nodes, including: selecting at least two candidate management nodes from a group of candidate management nodes based on load balancing to obtain at least two third management nodes; or,

[0053] S22, selecting a candidate management node from a group of candidate management nodes to obtain a fourth management node, including: selecting a candidate management node from a group of candidate management nodes based on load balancing to obtain the fourth management node.

[0054] The load balancing can be determined based on the priority of the server corresponding to each candidate management node, or based on the resource occupancy rate of the server currently running on each candidate management node. Figure 5 As shown, load balancing can be achieved through haproxy (a proxy software that provides high availability, load balancing, and TCP (layer 4) and HTTP (layer 7) applications).

[0055] Through this embodiment, the flexibility of component selection can be improved by selecting the component of the management node that first stores the data to be stored through load balancing.

[0056] In an exemplary embodiment, selecting at least two candidate management nodes from a group of candidate management nodes to obtain at least two third management nodes includes:

[0057] S31, when the data to be stored is a resource object to be stored in a preset storage system of a management node of a target node cluster, at least two candidate management nodes are selected from a group of candidate management nodes to obtain at least two third management nodes.

[0058] In the case where the data to be stored is a resource object to be stored in the preset storage system of the management node to be stored in the target node cluster, at least two candidate management nodes can be selected from a group of candidate management nodes to obtain at least two third management nodes, and the storage components of the selected at least two third management nodes can be used to save the data to be stored.

[0059] The aforementioned preset storage system can be Ceph. The number of Ceph cluster data replicas can be customized and configured, and the physical storage location of the replicas can be specified using the Crush algorithm to separate failure domains. Ceph's strong data consistency makes it highly reliable, allowing it to tolerate multiple failure scenarios and automatically attempt parallel repairs. In this embodiment, for data to be stored corresponding to Ceph, if there are three management nodes corresponding to the Ceph cluster, two management nodes can be selected to store the data to be stored.

[0060] Optionally, in the case where the storage system is NFS, the data to be stored may also be the resource objects to be stored, but the data storage and synchronization method may be different from the above-mentioned Ceph storage method. It may be to select a candidate management node from a group of candidate management nodes to obtain a fourth management node, and push the resource objects to be stored to the preset storage system of the fourth management node for storage, so as to push the resource objects to be stored to the preset storage systems of at least some of the candidate management nodes in the group of candidate management nodes other than the fourth management node for storage. That is, notify (a Linux feature for monitoring file system operations, such as reading, writing, and creating) is used to detect the host (i.e., the server corresponding to the fourth management node). After detecting that there is a data transformation in the directory of the host, the transformed directory or file will be automatically synchronized to the backup machine (i.e., the server of at least some of the candidate management nodes in the group of candidate management nodes other than the fourth management node) in real time using rsync (data mirror backup tool), so as to achieve data unification and ensure data integrity.

[0061] Through this embodiment, corresponding data synchronization is performed between the preset storage systems of different management nodes according to the characteristics of the preset storage system, which can improve the availability of the preset storage system and thus improve the availability of the cluster architecture.

[0062] In an exemplary embodiment, selecting a candidate management node from a group of candidate management nodes to obtain a fourth management node, and pushing the data to be stored to a storage component of the fourth management node for storage, includes:

[0063] S41: When the data to be stored is an image to be stored in an image repository of a management node of a target node cluster, a candidate management node is selected from a group of candidate management nodes to obtain a fourth management node, and the image to be stored is pushed to the image repository of the fourth management node for storage. The image to be stored is pushed by the image repository of the fourth management node to the image repositories of all candidate management nodes except the fourth management node for storage based on the repository addresses of the image repositories of all candidate management nodes except the fourth management node in the group of candidate management nodes.

[0064] S42: If the data to be stored is metadata to be stored in a database of a management node of the target node cluster, select a candidate management node from a group of candidate management nodes to obtain a fourth management node, and push the metadata to be stored to the database of the fourth management node for storage. The metadata to be stored is pushed by the database of the fourth management node to the databases of all candidate management nodes except the fourth management node for storage.

[0065] S43: If the data to be stored is object data to be stored in the second control component of the management node of the target node cluster, a candidate management node is selected from a group of candidate management nodes to obtain a fourth management node, and the object data to be stored is pushed to the second control component of the fourth management node for storage. The second control component is a component for object data management, and the object data to be stored is pushed by the second control component of the fourth management node to the second control component of a candidate management node other than the fourth management node for storage.

[0066] S44. When the data to be stored is a model file to be stored in the model repository of the management node of the target node cluster, a candidate management node is selected from a group of candidate management nodes to obtain a fourth management node, and the model file to be stored is pushed to the model repository of the fourth management node for storage, wherein the model file to be stored is pushed by the model repository of the fourth management node to the model repository of a candidate management node other than the fourth management node for storage.

[0067] In the case of selecting a fourth management node from a group of candidate management nodes and pushing the data to be stored to the storage component of the fourth management node for storage, different data synchronization operations can be performed according to the data type of the data to be stored. In addition, considering the possibility of data split-brain (i.e., multiple copies of the same file with different data) for some types of data, in order to ensure that the data in the selected backup management node is complete or accurate when a management node failure occurs, the components corresponding to data prone to split-brain can be deployed on each candidate management node in the group of candidate management nodes, while the components corresponding to data not prone to split-brain can be deployed on only two candidate management nodes in the group of candidate management nodes.

[0068] In this embodiment, when the data to be stored is an image to be stored in the image repository of the management node of the target node cluster, a candidate management node can be selected from a group of candidate management nodes to obtain a fourth management node, and the image to be stored can be pushed to the image repository of the fourth management node for storage. The image repository of the fourth management node can then push the image to be stored to the image repositories of all candidate management nodes except the fourth management node in the stored group of candidate management nodes based on the repository addresses of the image repositories of all candidate management nodes except the fourth management node for storage. Here, the image repository can be deployed on each candidate management node.

[0069] For example, using Harbor as the mirror repository, you can install Harbor repositories on each of the three management nodes in the Kubernetes cluster (three groups, named Harbor-1, Harbor-2, and Harbor-3) and configure synchronization relationships between them. Specifically, define the target addresses for the Harbor-2 and Harbor-3 repositories in the Harbor-1 repository and create synchronization rules based on push-based replication and event-driven triggering. Similarly, complete similar definitions and configurations for the Harbor-2 and Harbor-3 repositories. This completes the multi-master replication configuration, which reuses master-slave synchronization to achieve bidirectional synchronization between multiple Harbor nodes to ensure data consistency. A load balancer is then placed in front of the multiple Harbor nodes to divert incoming requests to different instances. Whenever a new image is available in one instance, it is automatically replicated to the other instances. This achieves load balancing and avoids single points of failure, thus ensuring Harbor's high availability. When an image needs to be pushed to the Harbor warehouse, haproxy load balancing selects one of the three management nodes to complete the image push. The replication model of the Harbor warehouse completes the synchronization of the image in the three warehouses. Even if one or even two management nodes fail, it will not affect the normal operation of the harbor cluster.

[0070] In the case where the data to be stored is metadata to be stored in the database of the management node of the target node cluster, a candidate management node can be selected from a group of candidate management nodes to obtain a fourth management node, and the metadata to be stored can be pushed to the database of the fourth management node for storage. The database of the fourth management node then pushes the metadata to be stored to the databases of all candidate management nodes other than the fourth management node for storage. Here, the process of the fourth management node's database pushing the metadata to be stored to the databases of all candidate management nodes other than the fourth management node for storage can be achieved through broadcasting. Here, the database can be deployed on each candidate management node.

[0071] For example, taking MariaDB as an example, Galera (a type of cluster) is a multi-master high-availability solution for MariaDB. This cluster features features such as all nodes being able to read and write to the database simultaneously, automatic membership control (failed nodes are removed from the cluster), automatic replication of data when new nodes join, true parallel replication, and zero-delay replication. Each MariaDB instance in the cluster stores a complete copy of the database, and clients can read and write data through any instance. In addition, each node in the cluster stores a complete copy of the data, providing high data backup security. It works as follows: When a transaction is committed on the node currently writing, the transaction is broadcast to other nodes in the same cluster. After receiving the write-set transaction, other nodes perform a feasibility check on the transaction and return a message indicating that the transaction was successfully submitted to the client. Using Galera to synchronize databases between different databases effectively avoids the problem of single data failures.

[0072] If the data to be stored is object data to be stored by the second control component of the management node of the target node cluster, a candidate management node can be selected from a group of candidate management nodes to obtain a fourth management node, and the object data to be stored can be pushed to the second control component of the fourth management node for storage. The second control component of the fourth management node then pushes the object data to be stored to the second control component of a candidate management node other than the fourth management node for storage. Here, the second control component can be a component for object data management. The object data can include, but is not limited to, user groups and user information. Here, the second control component can be deployed only on two candidate management nodes from the group of candidate management nodes.

[0073] For example, consider Ldap, a lightweight directory access protocol (LDAP) that can be used as an account module in the Kubernetes platform. Its high-availability design can be implemented in three ways: Mirror mode and N-way multi-master mode. Since Mirror mode is an active / active hot standby mode with data synchronization between masters, it offers improved fault recovery capabilities, can automatically complete data and time synchronization, and offers performance close to that of a single master. In this embodiment, Mirror mode can be used (i.e., two sets of LDAP components are deployed on the master1 and master2 nodes of the Kubernetes cluster, respectively), with load balancing used to distribute data to the LDAP service. Furthermore, it is necessary to ensure that the two LDAP services maintain time synchronization and that domain names between the nodes can be mutually resolved. Therefore, when new user group or user creation information needs to be saved to LDAP, the load balancer selects one of the master1 and master2 nodes to save the data. The mirror-mode replication model synchronizes data between the two LDAP nodes. Even if one management node fails, the normal operation of the account component will not be affected.

[0074] If the data to be stored is a model file to be stored in the model repository of a management node in the target node cluster, a candidate management node can be selected from a group of candidate management nodes to obtain a fourth management node, and the model file to be stored can be pushed to the model repository of the fourth management node for storage. The model repository of the fourth management node can then push the model file to be stored to the model repository of a candidate management node other than the fourth management node for storage. In this case, the model repository can be deployed on only two candidate management nodes from the group of candidate management nodes.

[0075] For example, if the model repository is HDFS, multiple NameNodes (metadata nodes) can be configured in a cluster, each running on a separate physical node. At any given time, only one NameNode is in the Active state, while the others are in the Standby state. The Active NameNode is responsible for all client operations, while the Standby NameNode synchronizes the Active NameNode's state information to provide rapid fault recovery. To ensure that the Active and Standby node states are synchronized, that is, that metadata remains consistent, a set of independent daemons are required to synchronize information and data. In addition, NameNode states must switch automatically. When multiple NameNodes start, they register a temporary node with the state switching process. If a NameNode goes down (i.e., the node is not functioning properly), this temporary node disappears, and another node is selected to become Active, and the down node is transferred to the Standby state. Therefore, when a model file needs to be pushed to the HDFS model warehouse, the haproxy load balancing selects a node from the master1 node and the master2 node to complete the image push, and the copy model of the harbor warehouse completes the file synchronization in the two model warehouses. Even if one management node fails, it will not affect the normal operation of the AI ​​model warehouse.

[0076] Through this embodiment, different data synchronization operations are performed according to the data type of the data to be stored, which can ensure that the data on the same key component of different nodes in the cluster are the same, thereby improving the availability of the key component.

[0077] In an exemplary embodiment, after selecting the first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, the method further includes:

[0078] S51, synchronizing incremental data on the first management node to at least some candidate management nodes other than the first management node in real time through a first control component of the first management node, wherein the first control component is a component for performing data synchronization;

[0079] S52, monitoring the Network File System (NFS) process of the first management node through the hot backup software;

[0080] S53: When the NFS process of the first management node is started abnormally, determine that the first management node fails.

[0081] After selecting a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, the incremental data on the first management node can be synchronized in real time to at least some of the candidate management nodes other than the first management node through a first control component of the first management node. Here, the first control component can be a component for performing data synchronization, and can be an etcd component (a core component in the k8s cluster) in the k8s cluster.

[0082] For the NFS component, the network file system NFS process of the first management node can be monitored by hot backup software. In the case that the NFS process of the first management node is abnormally started, it can be determined that the first management node has a fault.

[0083] The above hot backup software can be keepalived (a high-performance server high availability or hot backup solution), such as Figure 6 As shown, it can be used to prevent service interruptions caused by single point failure of the server. Keepalived uses the master-slave mode, which requires at least two servers to work properly. For example, keepalived builds three servers into a cluster and provides a unique IP to the outside world. Under normal circumstances, only one server can see the virtual network card of this IP. If this service is abnormal, keepalived will immediately move the IP to one of the remaining two servers so that the IP can be used normally.

[0084] In this embodiment, keepalived can monitor the NFS process. When the master's NFS main process crashes and cannot be started, the virtual IP address drifts from the management node to the slave node (the slave node can be other management nodes in this embodiment), and the NFS of the slave node takes over and continues to work.

[0085] Optionally, in the aforementioned embodiment, when other components of the first management node are abnormal, it can also be determined that the first management node has a fault.

[0086] Through this embodiment, the synchronization of incremental data is achieved through the first control component, which can improve the availability of the cluster, and the monitoring of the NFS process by the hot backup software can avoid the temporary suspension of the server caused by the abnormality of the NFS process.

[0087] In an exemplary embodiment, the method further includes:

[0088] S61, selecting a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, including: selecting, by hot standby software, the first management node from the group of candidate management nodes as the management node of the target node cluster, wherein the first management node is a candidate management node with the highest node weight among the group of candidate management nodes, and directing, via application proxy software, application program interface (API) requests from a group of working nodes to the management node of the target node cluster to the first management node assigned a virtual IP address, wherein the application proxy software is proxy software for load balancing;

[0089] S62, in the event that the first management node fails, select a second management node from a group of candidate management nodes other than the first management node as the management node of the target node cluster, including: in the event that the first management node fails, the hot backup software selects the second management node from a group of candidate management nodes other than the first management node as the management node of the target node cluster, wherein the second management node is the candidate management node with the highest weight among the other candidate management nodes, and an API request from a group of working nodes to the management node of the target node cluster is directed to the second management node assigned to the virtual IP address through the application proxy software.

[0090] In this embodiment, hot backup software and application proxy software can be used to achieve high availability for the target cluster. Specifically, the hot backup software provides a stable external access point, while the application proxy software balances the internal load. The operating principle can be that the hot backup software selects a first management node from a set of candidate management nodes as the management node for the target node cluster. Application program interface (API) requests from a group of working nodes to the management node of the target node cluster can be directed by the application proxy software to the first management node assigned to the virtual IP address. The application proxy software can be used as a proxy software for load balancing.

[0091] The hot backup software can be the aforementioned keepalived, and the application proxy software can be haproxy, which is a proxy software that provides high availability, load balancing, and TCP (Layer 4) and HTTP (Layer 7) applications. It supports virtual hosts and is a free, fast, and reliable solution. Use haproxy to load balance the backend service to achieve high service availability.

[0092] Considering that haproxy runs on the k8s-management node, when the management node is abnormal, the haproxy service will also stop. In order to avoid this situation, the haproxy service can be deployed on each management node to achieve the purpose of high availability of the haproxy service.

[0093] If the first management node fails, the hot standby software can select a second management node from a set of candidate management nodes other than the first management node as the management node for the target node cluster. Here, the second management node can be the candidate with the highest weight among the other candidate management nodes. A group of working nodes can direct API requests to the management node of the target node cluster, using the application proxy software, to the second management node assigned a virtual IP address.

[0094] For example, all working nodes' API requests to the master are directed to the virtual IP (keepalived) through load balancing (haproxy), and this virtual P is elected by all master nodes through priority. Keepalived selects a hot standby server as the MASTER machine through priority (that is, the weight set by the server). The MASTER machine will be assigned a specified virtual IP, and external programs can access this server through the virtual IP. If this server fails (disconnected, restarted, or keepalived crashes on this machine, etc.), Keepalived will reselect a machine from other backup machines (still depending on the weight set by the server) to be the MASTER and assign the same virtual IP to act as the previous MASTER.

[0095] Through this embodiment, the use of management nodes in the target cluster is managed by hot backup software and application agent software, which can improve the efficiency of selecting candidate management nodes.

[0096] The control method of the cluster architecture in the embodiment of the present application is explained below with reference to optional examples.

[0097] This optional example provides a high-availability architecture solution for a Kubernetes cluster, encompassing both cluster high-availability design and key component high-availability design. This covers both cluster high-availability design and full-component high-availability design, ensuring fault tolerance, service availability, and data security. The cluster high-availability design primarily aims to improve the types and volume of services supported by the entire cluster through performance optimization and architectural upgrades. The full-component high-availability design primarily addresses the entire component lifecycle from a standardized perspective, ensuring that the entire lifecycle, from launch and cluster admission to every change and decommissioning, remains within the system's tolerances.

[0098] The process of the control method of the cluster architecture in this optional example can be as follows: Figure 7 As shown, the following steps may be included:

[0099] Step S702: keepalived selects a hot standby server as the MASTER machine through priority election.

[0100] In step S704, the MASTER machine will be assigned to a specified virtual IP.

[0101] Step S706: If the selected MASTER machine fails (network disconnection, restart, or keepalived crashes on this machine, etc.), keepalived reselects a machine from other backup machines to be the MASTER.

[0102] This optional example improves the types and volume of services supported by the entire cluster from the perspective of performance optimization and architecture upgrade. It also implements the standardization throughout the component's lifecycle, improving the availability of key components within the cluster and its architecture.

[0103] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0104] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the embodiment of the present application is essentially 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, magnetic disk, optical disk), including a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the method of each embodiment of the present application.

[0105] According to another aspect of the embodiments of the present application, a control device for a cluster architecture is also provided, which is used to implement the control method for the cluster architecture provided in the above embodiments. Details that have been described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

[0106] Figure 8is a structural block diagram of a control device of a cluster architecture according to an embodiment of the present application, such as Figure 8 As shown, the device includes:

[0107] A selection unit 802 is configured to select a first management node from a group of candidate management nodes in the target node cluster as a management node of the target node cluster, wherein the management node of the target node cluster is configured to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are configured to run containerized applications;

[0108] an allocating unit 804, configured to allocate a virtual Internet Protocol IP address to the first management node, wherein the virtual IP address is an IP address used by an external program to access the management node of the target node cluster;

[0109] The first execution unit 806 is configured to select a second management node as the management node of the target node cluster from a group of candidate management nodes except the first management node when the first management node fails, and allocate a virtual IP address to the second management node.

[0110] Through the embodiments of the present application, a first management node is selected from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are used to run containerized applications; a virtual Internet Protocol IP address is assigned to the first management node, wherein the virtual IP address is the IP address used by external programs to access the management node of the target node cluster; in the event of a failure of the first management node, a second management node is selected from a group of candidate management nodes other than the first management node as the management node of the target node cluster, and a virtual IP address is assigned to the second management node, which can solve the problem of low availability of the cluster architecture in the control method of the cluster architecture in the related art and improve the availability of the cluster architecture.

[0111] Optionally, the above device further includes:

[0112] an acquiring unit, configured to, after selecting a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, acquire data to be stored, wherein the data to be stored is data to be stored in a storage component of the management node of the target node cluster;

[0113] The second execution unit is configured to select at least two candidate management nodes from a group of candidate management nodes, obtain at least two third management nodes, and push the data to be stored to the storage components of the at least two third management nodes for storage; or

[0114] a third execution unit, configured to select a candidate management node from the group of candidate management nodes to obtain a fourth management node, and push the data to be stored to the storage component of the fourth management node for storage, so that the storage component of the fourth management node pushes the data to be stored to the storage components of at least some of the candidate management nodes in the group of candidate management nodes other than the fourth management node for storage;

[0115] The candidate management nodes where the corresponding storage component stores data to be stored include the first management node.

[0116] Optionally, the second execution unit includes: a first selection module, configured to select at least two candidate management nodes from a group of candidate management nodes based on load balancing to obtain at least two third management nodes; or

[0117] The third execution unit includes: a second selection module, configured to select a candidate management node from a group of candidate management nodes based on load balancing to obtain a fourth management node.

[0118] Optionally, the second execution unit includes:

[0119] The third selection module is used to select at least two candidate management nodes from a group of candidate management nodes to obtain at least two third management nodes when the data to be stored is a resource object to be stored in the preset storage system of the management node of the target node cluster.

[0120] Optionally, the third execution unit includes:

[0121] a first execution module, configured to, when the data to be stored is an image to be stored in an image repository of a management node of a target node cluster, select a candidate management node from a group of candidate management nodes to obtain a fourth management node, and push the image to be stored to the image repository of the fourth management node for storage, wherein the image to be stored is pushed by the image repository of the fourth management node to the image repositories of all candidate management nodes except the fourth management node for storage based on the repository addresses of the image repositories of all candidate management nodes except the fourth management node in the group of candidate management nodes that are stored;

[0122] a second execution module, configured to, when the data to be stored is metadata to be stored in a database of a management node of a target node cluster, select a candidate management node from a group of candidate management nodes to obtain a fourth management node, and push the metadata to be stored to the database of the fourth management node for storage, wherein the metadata to be stored is pushed by the database of the fourth management node to the databases of all candidate management nodes except the fourth management node for storage;

[0123] a third execution module, configured to, when the data to be stored is object data to be stored in the second control component of the management node of the target node cluster, select a candidate management node from a group of candidate management nodes to obtain a fourth management node, and push the object data to be stored to the second control component of the fourth management node for storage, wherein the second control component is a component for object data management, and the object data to be stored is pushed by the second control component of the fourth management node to the second control component of a candidate management node other than the fourth management node for storage;

[0124] The fourth execution module is used to select a candidate management node from a group of candidate management nodes to obtain a fourth management node when the data to be stored is a model file to be stored in the model warehouse of the management node of the target node cluster, and push the model file to be stored to the model warehouse of the fourth management node for storage, wherein the model file to be stored is pushed by the model warehouse of the fourth management node to the model warehouse of a candidate management node other than the fourth management node for storage.

[0125] Optionally, the above device further includes:

[0126] a synchronization unit, configured to, after selecting a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, synchronize, via a first control component of the first management node, incremental data on the first management node to at least some of the candidate management nodes other than the first management node in real time, wherein the first control component is a component for performing data synchronization;

[0127] A monitoring unit, configured to monitor the Network File System (NFS) process of the first management node through hot backup software;

[0128] The determining unit is configured to determine that a fault occurs on the first management node when an NFS process of the first management node is started abnormally.

[0129] Optionally, the selection unit includes: a fourth selection module, configured to select, by the hot backup software, a first management node from a group of candidate management nodes as the management node of the target node cluster, wherein the first management node is a candidate management node with the highest node weight among the group of candidate management nodes, and an application program interface API request from a group of working nodes to the management node of the target node cluster is directed to the first management node assigned to the virtual IP address through application proxy software, wherein the application proxy software is proxy software for load balancing;

[0130] The first execution unit includes: a fifth selection module, which is used to select a second management node as the management node of the target node cluster from a group of candidate management nodes other than the first management node by the hot backup software when the first management node fails, wherein the second management node is the candidate management node with the highest weight among the other candidate management nodes, and the API requests of a group of working nodes to the management node of the target node cluster are directed to the second management node assigned to the virtual IP address through the application proxy software.

[0131] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0132] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the steps of any of the above method embodiments when run.

[0133] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0134] According to another aspect of the embodiments of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments.

[0135] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0136] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail here.

[0137] Obviously, those skilled in the art should understand that the various modules or steps of the above-mentioned embodiments of the present application can be implemented using a general-purpose computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented using program codes executable by the computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be performed in a different order than herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0138] The above description is only a preferred embodiment of the present application and is not intended to limit the embodiments of the present application. For those skilled in the art, the embodiments of the present application may be modified and varied in various ways. Any modifications, equivalent substitutions, improvements, etc. made within the principles of the embodiments of the present application shall be included in the scope of protection of the embodiments of the present application.

Claims

1. A control method for a cluster architecture, characterized in that: include: Selecting a first management node from a group of candidate management nodes in a target node cluster as a management node of the target node cluster, wherein the management node of the target node cluster is used to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are used to run containerized applications; Allocating a virtual Internet Protocol (IP) address to the first management node, wherein the virtual IP address is an IP address used by external programs to access the management node of the target node cluster; In the event that the first management node fails, selecting a second management node from the set of candidate management nodes other than the first management node as the management node of the target node cluster, and assigning the virtual IP address to the second management node; Wherein, after selecting the first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, the method further includes: obtaining data to be stored, wherein the data to be stored is data to be stored in the storage component of the management node of the target node cluster; selecting at least two candidate management nodes from the group of candidate management nodes to obtain at least two third management nodes, and pushing the data to be stored to the storage components of the at least two third management nodes for storage; or selecting a candidate management node from the group of candidate management nodes to obtain a fourth management node, and pushing the data to be stored to the storage component of the fourth management node for storage, so that the storage component of the fourth management node pushes the data to be stored to the storage components of at least some of the candidate management nodes in the group of candidate management nodes other than the fourth management node for storage; wherein, the candidate management nodes whose corresponding storage components store the data to be stored include the first management node.

2. The method according to claim 1, characterized in that The selecting at least two candidate management nodes from the group of candidate management nodes to obtain at least two third management nodes includes: selecting at least two candidate management nodes from the group of candidate management nodes based on load balancing to obtain the at least two third management nodes; or The selecting a candidate management node from the group of candidate management nodes to obtain the fourth management node includes: selecting a candidate management node from the group of candidate management nodes based on load balancing to obtain the fourth management node.

3. The method according to claim 1, characterized in that The selecting at least two candidate management nodes from the group of candidate management nodes to obtain at least two third management nodes includes: In the case where the data to be stored is a resource object to be stored in a preset storage system of the management node of the target node cluster, at least two candidate management nodes are selected from the group of candidate management nodes to obtain the at least two third management nodes.

4. The method according to claim 1, wherein The selecting a candidate management node from the group of candidate management nodes to obtain a fourth management node, and pushing the data to be stored to a storage component of the fourth management node for storage, includes: In a case where the data to be stored is an image to be stored in an image repository of a management node of the target node cluster, a candidate management node is selected from the group of candidate management nodes to obtain a fourth management node, and the image to be stored is pushed to the image repository of the fourth management node for storage, wherein the image to be stored is pushed by the image repository of the fourth management node to the image repositories of all candidate management nodes except the fourth management node for storage based on the stored repository addresses of the image repositories of all candidate management nodes except the fourth management node in the group of candidate management nodes; In a case where the data to be stored is metadata to be stored in a database of a management node of the target node cluster, a candidate management node is selected from the group of candidate management nodes to obtain a fourth management node, and the metadata to be stored is pushed to the database of the fourth management node for storage, wherein the metadata to be stored is pushed by the database of the fourth management node to the databases of all candidate management nodes except the fourth management node for storage; In a case where the data to be stored is object data to be stored in the second control component of the management node of the target node cluster, a candidate management node is selected from the group of candidate management nodes to obtain a fourth management node, and the object data to be stored is pushed to the second control component of the fourth management node for storage, wherein the second control component is a component for object data management, and the object data to be stored is pushed by the second control component of the fourth management node to the second control component of a candidate management node other than the fourth management node for storage; In a case where the data to be stored is a model file to be stored in the model repository of the management node of the target node cluster, a candidate management node is selected from the group of candidate management nodes to obtain a fourth management node, and the model file to be stored is pushed to the model repository of the fourth management node for storage, wherein the model file to be stored is pushed by the model repository of the fourth management node to the model repository of a candidate management node other than the fourth management node for storage.

5. The method according to claim 1, wherein After selecting the first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster, the method further includes: Synchronizing the incremental data on the first management node to at least some candidate management nodes other than the first management node in real time through a first control component of the first management node, wherein the first control component is a component for performing data synchronization; Monitoring the Network File System (NFS) process of the first management node through hot backup software; When the NFS process of the first management node is started abnormally, it is determined that the first management node fails.

6. The method according to any one of claims 1 to 5, characterized in that The selecting a first management node from a group of candidate management nodes in the target node cluster as the management node of the target node cluster includes: hot backup software selecting the first management node from the group of candidate management nodes as the management node of the target node cluster, wherein the first management node is the candidate management node with the highest node weight among the group of candidate management nodes, and the application program interface API requests of the group of working nodes to the management node of the target node cluster are directed to the first management node to which the virtual IP address is assigned through application proxy software, and the application proxy software is proxy software for load balancing; The method of selecting a second management node as the management node of the target node cluster from the other candidate management nodes in the group of candidate management nodes except the first management node in the case of a failure of the first management node includes: in the case of a failure of the first management node, selecting the second management node as the management node of the target node cluster from the other candidate management nodes in the group of candidate management nodes except the first management node by the hot backup software, wherein the second management node is the candidate management node with the highest weight among the other candidate management nodes, and the API requests of the group of working nodes to the management node of the target node cluster are directed to the second management node to which the virtual IP address is assigned through the application proxy software.

7. A control device for a cluster architecture, characterized in that: include: a selection unit, configured to select a first management node from a group of candidate management nodes in a target node cluster as a management node of the target node cluster, wherein the management node of the target node cluster is configured to control a group of working nodes in the target node cluster, and both the group of candidate management nodes and the group of working nodes are configured to run containerized applications; an allocating unit, configured to allocate a virtual Internet Protocol IP address to the first management node, wherein the virtual IP address is an IP address used by an external program to access the management node of the target node cluster; a first execution unit, configured to, when the first management node fails, select a second management node from the set of candidate management nodes other than the first management node as the management node of the target node cluster, and assign the virtual IP address to the second management node; In which, the device also includes: an acquisition unit, used to acquire the data to be stored after selecting the first management node as the management node of the target node cluster from a group of candidate management nodes in the target node cluster, wherein the data to be stored is the data of the storage component to be stored in the management node of the target node cluster; a second execution unit, used to select at least two candidate management nodes from the group of candidate management nodes, obtain at least two third management nodes, and push the data to be stored to the storage components of the at least two third management nodes for storage; or, a third execution unit, used to select a candidate management node from the group of candidate management nodes, obtain a fourth management node, and push the data to be stored to the storage component of the fourth management node for storage, so that the storage component of the fourth management node pushes the data to be stored to the storage components of at least some of the candidate management nodes in the group of candidate management nodes except the fourth management node for storage; wherein the candidate management nodes whose corresponding storage components store the data to be stored include the first management node.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method described in any one of claims 1 to 6 when executed by a processor.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

Images