Distributed peer-to-peer multi-container cluster system

Abstract

The invention relates to the technical field of cooperative computing, in particular to a distributed peer-to-peer multi-container cluster system which comprises a basic resource layer composed of basic hardware resources of multiple nodes, and the basic hardware resources comprise a computing server, a storage server, network equipment, safety equipment and intelligent acceleration hardware; the operating system layer is composed of maneuvering edges corresponding to a plurality of nodes and provides resource and service operation support for the container application load; the cloud management layer is composed of a plurality of container cloud management platforms and is distributed and operated on each node according to a high-availability deployment architecture to realize unified collaborative scheduling of cluster resources and applications; the data synchronization module is used for ensuring the consistency of metadata among the container cloud management platforms by adopting a distributed consistency protocol; and the application scheduling module receives the application deployment request, and issues the target application and the distribution strategy to the corresponding target node or node cluster to complete the scheduling of the target application.

Description

Technical Field

[0001] The present invention relates to the field of collaborative computing technology, and in particular to a distributed peer-to-peer multi-container cluster system. Background Art

[0002] In recent years, cloud computing technology has gradually developed from a fixed-end central cloud system to a central cloud and mobile edge cloud collaborative integration system. The cloud-edge collaborative system makes full use of the computing power and flexibility of the edge cloud to relieve the pressure of the central cloud on massive data processing while improving the response speed of edge end applications. In the aerospace field, the cloud-edge collaborative system has become a key technology for coping with high real-time and high computing requirements. The edge cloud plays a vital role in this system, mainly by providing computing power close to the data source, alleviating the pressure of the central cloud in processing massive data, and improving the task response speed. Space missions, especially those with extremely high requirements for real-time data processing and low latency, have gradually transformed to this cloud-edge collaborative architecture. Under this architecture, edge computing nodes can autonomously perform data analysis and preliminary processing, and only upload tasks that require higher computing power to the central cloud for processing, avoiding the bottleneck of data transmission and improving the real-time nature of tasks and the stability of the system.

[0003] Due to the particularity of aerospace missions, nodes are often located in scenarios where the network environment is unstable or restricted. The traditional centralized architecture lacks sufficient fault tolerance mechanisms and self-recovery capabilities when encountering node failures or disconnections, which may lead to task interruptions or resource scheduling failures in the system. Existing nodes mostly rely on the central cloud for scheduling, which makes it difficult to ensure the overall stability of the system and task continuity when a node fails, especially under high real-time and high reliability requirements. In addition, under the multi-cluster architecture of aerospace cloud computing, cross-node task scheduling and resource sharing also face difficulties. Nodes cannot fully process tasks autonomously, resulting in excessive dependence on the network and cloud, which in turn affects the system's anti-destruction capabilities. When a node is damaged or a system fails, the efficiency of task migration and resource rescheduling is low, and the system is difficult to recover quickly after the failure occurs, affecting the overall operating efficiency and stability of task processing. Therefore, improving the autonomy of nodes and strengthening the flexibility and robustness of task distribution and scheduling are current problems that need to be solved in aerospace cloud computing, especially in ensuring that the system can continue to operate efficiently in the event of any single node failure or damage. Summary of the invention

[0004] The present invention provides a distributed peer-to-peer multi-container cluster system to solve the problems raised in the above background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions: A distributed peer-to-peer multi-container cluster system, comprising: The basic resource layer is composed of the basic hardware resources of multiple nodes, including computing servers, storage servers, network equipment, security equipment, and intelligent acceleration hardware; The operating system layer consists of mobile edges corresponding to multiple nodes, providing resource and service operation support for container application loads; The cloud management layer consists of multiple container cloud management platforms, which are distributed and run on each node according to the high-availability deployment architecture to achieve unified and coordinated scheduling of cluster resources and applications. The data synchronization module uses a distributed consistency protocol to ensure the consistency of metadata between various container cloud management platforms; The application scheduling module receives application deployment requests, sends the target application and distribution strategy to the corresponding target node or node cluster, and completes the scheduling of the target application.

[0006] Preferably, the data synchronization process of the data synchronization module includes the following steps: S1. Data change trigger: When the metadata of a cloud management platform changes, the leader node records the operation log and broadcasts the change to all follower nodes; S2, Data replication: The Follower node verifies and writes the local log and confirms with the Leader node. After receiving confirmation from the majority of nodes, the Leader node commits the change and notifies other nodes to complete the update; S3, conflict resolution: For possible write conflicts, version number management or last write priority strategy can be used to resolve the conflicts; S4, Fault recovery: If a node fails to synchronize in time due to a fault, the data change will be completed by reading the latest change log after recovery.

[0007] Preferably, the Leader node is elected by all nodes. If the current Leader node fails, a new Leader will be selected through re-election and data synchronization will be restored.

[0008] Preferably, the data synchronization module stores the metadata in shards: Divide into multiple shards by resource type or geographic location, and each shard is managed by a specific node group to prevent a single node from carrying too much data; Resource types include computing resources, storage resources, and network resources, and geographical locations include different regions or data centers.

[0009] Preferably, the data synchronization module uses a dynamic load balancing strategy to distribute metadata, and the dynamic load balancing strategy includes: Through dynamic sharding adjustment combined with consistent hashing algorithm, shards with higher load are redistributed to other nodes; Dynamically adjust the number of virtual nodes or migrate hotspot data by monitoring node load conditions; Through request routing optimization technology, data requests are directed to the corresponding shards, reducing the overhead of cross-shard communication.

[0010] Preferably, the consistent hashing algorithm includes: The entire hash space is abstracted into a ring structure, and each physical node and its multiple virtual nodes are evenly mapped to the ring structure through the hash function; The unique identifier of the metadata is calculated by the hash function and assigned to the physical node corresponding to the first virtual node on the ring structure that is greater than or equal to its hash value; When nodes are added or removed, only a small number of virtual nodes and their corresponding data shards need to be adjusted to ensure the lowest data migration cost.

[0011] Preferably, the application scheduling module includes a plurality of federated components, and the plurality of federated components include a request component API-Server, an execution component Controller-Manager, and a scheduling component Scheduler; The scheduling process of the application scheduling module includes the following steps: S1. Resource registration and discovery: Each node or node cluster reports and registers its own resource information to the request component API-Server. The resource information will be stored in the database, which records the correspondence between resources and nodes or clusters in detail. S2, resource binding and scheduling: Use templates to create resource objects and distribution strategies. The execution component Controller-Manager binds resource objects with distribution strategies and generates binding relationships. The binding relationships include resource information and corresponding node or node cluster information. All binding relationships are stored in the database. S3, the scheduling component Scheduler calculates the best resource distribution plan and issues scheduling commands based on the distribution strategy and the available status of the corresponding node or node cluster resources; S4. When the corresponding node or node cluster receives the scheduling command, it will independently execute the resource deployment operation, synchronize the status back to the execution component Controller-Manager, and store it in the database.

[0012] Preferably, step S3 specifically includes: S31, receiving the distribution strategy, adding the corresponding binding relationship to the work queue, taking out one binding relationship from the queue for processing every second, and processing the work queue in a loop until the work queue processing is completed; S32. Obtain the distribution rule of the distribution strategy according to the name of the distribution strategy in the annotation in the binding relationship; S33, comparing the new and old distribution rules, determining whether scheduling is required and calculating the number of replicas allocated to the node or node cluster; S34. Determine whether the node or node cluster matches the condition through the filtering plug-in to obtain the matching node or matching cluster; calculate the score of the matching node or matching cluster through the scoring plug-in to obtain the priority of the matching node or matching cluster; S35. According to the topology distribution constraint rule, the final member cluster to be sent is obtained; S36, using a replica scheduling strategy of replication and / or segmentation to distribute replicas to member clusters; S37. Update the cluster field in the binding relationship and set it to the calculated number of copies allocated to the member cluster.

[0013] Preferably, the filtering plug-in filters out nodes or node clusters that do not meet the distribution strategy through a node filtering interface; The scoring plug-in calculates a score for each filtered node or node cluster through a node scoring interface, and selects a node or node cluster as a scheduling result according to the score.

[0014] Preferably, the replica scheduling strategy of the replication includes deploying the same number of resource replicas as the template in each sending member cluster; The replica scheduling strategies for the sharding include weight priority and aggregation priority. The weight priority performs sharding according to the weight ratio, and the aggregation priority determines whether to expand or shrink replicas according to the total number of replicas, and then allocates the number of replicas according to the maximum number of available replicas of the member cluster.

[0015] Compared with the prior art, the present invention has the following beneficial effects: The present invention provides a distributed peer-to-peer multi-container cluster system, a new mobile edge cloud technology based on a peer-to-peer distributed architecture, which realizes distributed decentralized resource management between nodes, unified resource management of cloud and edge clusters, and forms an agile resource pool with flexible node aggregation and efficient cloud-edge collaboration, supporting efficient sharing and dynamic scheduling of multiple nodes and multiple clusters. In particular, the present invention has a certain anti-damage capability for the instability of edge scenarios, realizes anti-damage reconstruction of task applications between nodes, and ensures the normal operation of edge operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A schematic diagram of the structure of a distributed peer-to-peer multi-container cluster system provided by an embodiment of the present invention; Figure 2 A framework diagram of an application scheduling module in a distributed peer-to-peer multi-container cluster system provided by an embodiment of the present invention; Figure 3A scheduling flow chart of an application scheduling module in a distributed peer-to-peer multi-container cluster system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0018] Figure 1 A schematic diagram of the structure of a distributed peer-to-peer multi-container cluster system provided by an embodiment of the present invention. Figure 1 As shown, an embodiment of the present invention provides a distributed peer-to-peer multi-container cluster system, including: The basic resource layer is composed of the basic hardware resources of multiple nodes, including computing servers, storage servers, network equipment, security equipment, and intelligent acceleration hardware; The operating system layer consists of mobile edges corresponding to multiple nodes, providing resource and service operation support for container application loads; The cloud management layer consists of multiple container cloud management platforms, which are distributed and run on each node according to the high-availability deployment architecture to achieve unified and coordinated scheduling of cluster resources and applications. The data synchronization module uses a distributed consistency protocol to ensure the consistency of metadata between various container cloud management platforms; The application scheduling module receives application deployment requests, sends the target application and distribution strategy to the corresponding target node or node cluster, and completes the scheduling of the target application.

[0019] The present invention realizes the unified scheduling and management capabilities of multi-node and multi-cluster resources by building a cloud-native "peer distribution" collaborative architecture, allowing nodes to reuse cloud management capabilities, directly control edge services, improve business agility and resource utilization, and when a node goes offline, users can roam and log in to the cloud management at other nodes to continue issuing tasks. At the same time, there is no superior-subordinate relationship between nodes, and any node can be elected as a leader to collaboratively manage all nodes.

[0020] In one embodiment of the present invention, the data synchronization process of the data synchronization module includes the following steps: S1. Data change trigger: When the metadata of a cloud management platform changes, the leader node records the operation log and broadcasts the change to all follower nodes; S2, Data replication: The Follower node verifies and writes the local log and confirms with the Leader node. After receiving confirmation from the majority of nodes, the Leader node commits the change and notifies other nodes to complete the update; S3, conflict resolution: For possible write conflicts, version number management or last write priority strategy can be used to resolve the conflicts; S4, Fault recovery: If a node fails to synchronize in time due to a fault, the data change will be completed by reading the latest change log after recovery.

[0021] In an embodiment of the present invention, metadata includes: Resource metadata: including computing resources, storage resources, network configuration, etc.

[0022] User information: including user’s basic information, role, account status, etc.

[0023] User permissions: include user access rights and operation permissions to resources.

[0024] Furthermore, the Leader node is elected by all nodes. If the current Leader node fails, a new Leader will be selected through re-election and data synchronization will be restored.

[0025] In order to improve synchronization efficiency and fault tolerance, each node stores multiple copies of data to avoid data loss caused by single point failures. If the leader node fails, the cluster will elect a new leader and restore data synchronization. At the same time, the system will detect the survival status of the node through a health check mechanism. After the failed node recovers, it will quickly restore consistency by reading the latest change log or synchronizing the latest copy, ensuring high reliability and high availability of the distributed system.

[0026] The data synchronization module is a key technical means to maintain data consistency and high availability among multiple nodes in a distributed system through a data synchronization mechanism. In order to ensure that metadata such as user information, resource configuration, and permissions are synchronized between different nodes, a combination of distributed consistency protocols and event-driven mechanisms is required. First, the system implements strong consistency data writing through distributed protocols (such as Raft or Paxos). Each write operation will be responsible for the elected Leader node, which synchronizes the data changes to other Follower nodes in the form of logs. The Leader node needs to obtain confirmation from the majority of nodes before submitting the changes, which ensures that all nodes have consistent copies of the data. When the metadata changes, the event queue (such as Kafka) distributes the change event to each node, and each node asynchronously updates the data according to the change log.

[0027] In one embodiment of the present invention, the data synchronization module stores metadata in fragments: Divide into multiple shards by resource type or geographic location, and each shard is managed by a specific node group to prevent a single node from carrying too much data; Resource types include computing resources, storage resources, and network resources, and geographical locations include different regions or data centers.

[0028] Furthermore, the data synchronization module uses a dynamic load balancing strategy to distribute metadata. The dynamic load balancing strategy includes: Through dynamic sharding adjustment combined with consistent hashing algorithm, shards with higher load are redistributed to other nodes; Dynamically adjust the number of virtual nodes or migrate hotspot data by monitoring node load conditions; Through request routing optimization technology, data requests are directed to the corresponding shards, reducing the overhead of cross-shard communication.

[0029] Specifically, the consistent hashing algorithm includes: The entire hash space is abstracted into a ring structure, and each physical node and its multiple virtual nodes are evenly mapped to the ring structure through the hash function; The unique identifier of the metadata is calculated by the hash function and assigned to the physical node corresponding to the first virtual node on the ring structure that is greater than or equal to its hash value; When nodes are added or removed, only a small number of virtual nodes and their corresponding data shards need to be adjusted to ensure the lowest data migration cost.

[0030] The present invention not only improves the scalability and data synchronization efficiency of the system through shard storage and dynamic load balancing strategies, but also effectively avoids the performance bottleneck and data inconsistency problems of a single node, ensures the synchronization performance in a large-scale environment, and improves the fault tolerance and response speed of the system, thereby adapting to complex distributed scenario requirements.

[0031] Figure 2 A framework diagram of an application scheduling module in a distributed peer-to-peer multi-container cluster system provided by an embodiment of the present invention. Figure 2As shown, in one embodiment of the present invention, the application scheduling module includes multiple federal components, and the multiple federal components include a request component API-Server, an execution component Controller-Manager and a scheduling component Scheduler; wherein the request component API-Server is responsible for receiving and managing API requests for multi-cluster resource objects; the execution component Controller-Manager is responsible for resource binding, execution of distribution strategies and scheduling decisions; the scheduling component Scheduler is responsible for calculating the optimal distribution plan of resources based on the distribution strategy and cluster status.

[0032] Figure 3 The present invention provides a scheduling flow chart of an application scheduling module in a distributed peer-to-peer multi-container cluster system. Figure 3 As shown, in one embodiment of the present invention, the scheduling process of the application scheduling module includes the following steps: S1. Resource registration and discovery: Each node or node cluster reports and registers its own resource information (such as CPU, memory, storage, etc.) to the request component API-Server. The resource information will be stored in the database, which records the correspondence between resources and nodes or clusters in detail; S2, Resource Binding and Scheduling: Use templates to create resource objects (such as Deployment) and distribution policies (Propagation Policy). The execution component Controller-Manager binds the resource objects with the distribution policy and generates a binding relationship (Resource Binding). The binding relationship includes resource information and corresponding node or node cluster information. All binding relationships are stored in the database; S3, the scheduling component Scheduler calculates the best resource distribution plan and issues scheduling commands based on the distribution strategy and the available status of the corresponding node or node cluster resources; S4. When the corresponding node or node cluster receives the scheduling command, it will independently execute the resource deployment operation, synchronize the status back to the execution component Controller-Manager, and store it in the database.

[0033] At this point, the multi-node or cross-edge application distribution deployment is completed, and users can access and query applications through a unified control interface.

[0034] In one embodiment of the present invention, step S3 specifically includes: S31, receiving the distribution strategy, adding the corresponding binding relationship to the work queue, taking out one binding relationship from the queue for processing every second, and processing the work queue in a loop until the work queue processing is completed; S32. Obtain the distribution rule of the distribution strategy according to the name of the distribution strategy in the annotation in the binding relationship; S33, comparing the new and old distribution rules, determining whether scheduling is required and calculating the number of replicas allocated to the node or node cluster; S34. Determine whether the node or node cluster matches the condition through the filtering plug-in to obtain the matching node or matching cluster; calculate the score of the matching node or matching cluster through the scoring plug-in to obtain the priority of the matching node or matching cluster; S35. According to the topology distribution constraint rule, the final member cluster to be sent is obtained; S36, using a replica scheduling strategy of replication and / or segmentation to distribute replicas to member clusters; S37. Update the cluster field in the binding relationship and set it to the calculated number of copies allocated to the member cluster.

[0035] Furthermore, the filtering plug-in filters out nodes or node clusters that do not meet the distribution strategy through a node filtering interface; The scoring plug-in calculates a score for each filtered node or node cluster through a node scoring interface, and selects a node or node cluster as a scheduling result according to the score.

[0036] Furthermore, the replica scheduling strategy of the replication includes deploying the same number of resource replicas as the template in each of the distributed member clusters; The replica scheduling strategies for the sharding include weight priority and aggregation priority. The weight priority performs sharding according to the weight ratio, and the aggregation priority determines whether to expand or shrink replicas according to the total number of replicas, and then allocates the number of replicas according to the maximum number of available replicas of the member cluster.

[0037] The present invention incorporates multi-cloud management, multi-nodes and end-side devices into a unified resource pool by designing a distributed peer-to-peer multi-container cluster system, breaking the limitation of single cloud centralization. The nodes in the distributed peer-to-peer multi-container cluster system have the ability to independently process tasks without relying entirely on the central cloud; at the same time, there is no superior-subordinate relationship between the nodes, and any node can be elected as a leader. The data synchronization module maintains data consistency and high availability among multiple nodes in the distributed system through the data synchronization mechanism, and the global scheduling of tasks and resources is achieved through the application scheduling module, while having a certain degree of anti-destruction. The design and implementation of the distributed peer-to-peer multi-container cluster system can alleviate the computing power pressure and data transmission pressure brought by the current aerospace cloud application data processing being highly dependent on the central cloud, and enhance the mobility, flexibility and agile collaboration capabilities of aerospace cloud applications.

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

Claims

1. A distributed peer-to-peer multi-container cluster system, characterized in that: include: The basic resource layer is composed of the basic hardware resources of multiple nodes, including computing servers, storage servers, network equipment, security equipment, and intelligent acceleration hardware; The operating system layer consists of mobile edges corresponding to multiple nodes, providing resource and service operation support for container application loads; The cloud management layer consists of multiple container cloud management platforms, which are distributed and run on each node according to the high-availability deployment architecture to achieve unified and coordinated scheduling of cluster resources and applications. The data synchronization module uses a distributed consistency protocol to ensure the consistency of metadata between various container cloud management platforms; The application scheduling module receives application deployment requests, sends the target application and distribution strategy to the corresponding target node or node cluster, and completes the scheduling of the target application.

2. The distributed peer-to-peer multi-container cluster system according to claim 1, characterized in that: The data synchronization process of the data synchronization module includes the following steps: S1. Data change trigger: When the metadata of a cloud management platform changes, the leader node records the operation log and broadcasts the change to all follower nodes; S2, Data replication: The Follower node verifies and writes the local log and confirms with the Leader node. After receiving confirmation from the majority of nodes, the Leader node commits the change and notifies other nodes to complete the update; S3, conflict resolution: For possible write conflicts, version number management or last write priority strategy can be used to resolve the conflicts; S4, Fault recovery: If a node fails to synchronize in time due to a fault, the data change will be completed by reading the latest change log after recovery.

3. The distributed peer-to-peer multi-container cluster system according to claim 2, characterized in that: The Leader node is elected by all nodes. If the current Leader node fails, a new Leader will be selected through re-election and data synchronization will be restored.

4. The distributed peer-to-peer multi-container cluster system according to claim 3, characterized in that: The data synchronization module stores metadata in shards: Divide into multiple shards by resource type or geographic location, and each shard is managed by a specific node group to prevent a single node from carrying too much data; Resource types include computing resources, storage resources, and network resources, and geographical locations include different regions or data centers.

5. The distributed peer-to-peer multi-container cluster system according to claim 4, characterized in that: The data synchronization module uses a dynamic load balancing strategy to distribute metadata. The dynamic load balancing strategy includes: Through dynamic sharding adjustment combined with consistent hashing algorithm, shards with higher load are redistributed to other nodes; Dynamically adjust the number of virtual nodes or migrate hotspot data by monitoring node load conditions; Through request routing optimization technology, data requests are directed to the corresponding shards, reducing the overhead of cross-shard communication.

6. The distributed peer-to-peer multi-container cluster system according to claim 5, characterized in that: The consistent hashing algorithm includes: The entire hash space is abstracted into a ring structure, and each physical node and its multiple virtual nodes are evenly mapped to the ring structure through the hash function; The unique identifier of the metadata is calculated by the hash function and assigned to the physical node corresponding to the first virtual node on the ring structure that is greater than or equal to its hash value; When nodes are added or removed, only a small number of virtual nodes and their corresponding data shards need to be adjusted to ensure the lowest data migration cost.

7. The distributed peer-to-peer multi-container cluster system according to claim 1, characterized in that: The application scheduling module includes multiple federated components, including a request component API-Server, an execution component Controller-Manager, and a scheduling component Scheduler; The scheduling process of the application scheduling module includes the following steps: S1. Resource registration and discovery: Each node or node cluster reports and registers its own resource information to the request component API-Server. The resource information will be stored in the database, which records the correspondence between resources and nodes or clusters in detail. S2, resource binding and scheduling: Use templates to create resource objects and distribution strategies. The execution component Controller-Manager binds resource objects with distribution strategies and generates binding relationships. The binding relationships include resource information and corresponding node or node cluster information. All binding relationships are stored in the database. S3, the scheduling component Scheduler calculates the best resource distribution plan and issues scheduling commands based on the distribution strategy and the available status of the corresponding node or node cluster resources; S4. When the corresponding node or node cluster receives the scheduling command, it will independently execute the resource deployment operation, synchronize the status back to the execution component Controller-Manager, and store it in the database.

8. The distributed peer-to-peer multi-container cluster system according to claim 7, characterized in that: Step S3 specifically includes: S31, receiving the distribution strategy, adding the corresponding binding relationship to the work queue, taking out one binding relationship from the queue for processing every second, and processing the work queue in a loop until the work queue processing is completed; S32. Obtain the distribution rule of the distribution strategy according to the name of the distribution strategy in the annotation in the binding relationship; S33, comparing the new and old distribution rules, determining whether scheduling is required and calculating the number of replicas allocated to the node or node cluster; S34. Determine whether the node or node cluster matches the condition through the filtering plug-in to obtain the matching node or matching cluster; calculate the score of the matching node or matching cluster through the scoring plug-in to obtain the priority of the matching node or matching cluster; S35. According to the topology distribution constraint rule, the final member cluster to be sent is obtained; S36, using a replica scheduling strategy of replication and / or segmentation to distribute replicas to member clusters; S37. Update the cluster field in the binding relationship and set it to the calculated number of copies allocated to the member cluster.

9. The distributed peer-to-peer multi-container cluster system according to claim 8, characterized in that: The filtering plug-in filters out nodes or node clusters that do not meet the distribution strategy through the node filtering interface; The scoring plug-in calculates a score for each filtered node or node cluster through a node scoring interface, and selects a node or node cluster as a scheduling result according to the score.

10. The distributed peer-to-peer multi-container cluster system according to claim 8, characterized in that: The replica scheduling strategy of the replication includes deploying the same number of resource replicas as the template in each distributed member cluster; The replica scheduling strategies for the sharding include weight priority and aggregation priority. The weight priority performs sharding according to the weight ratio, and the aggregation priority determines whether to expand or shrink replicas according to the total number of replicas, and then allocates the number of replicas according to the maximum number of available replicas of the member cluster.

Images