A method for multi-level federation cluster resource view compression and incremental synchronization

Abstract

The application relates to the computer technical field and discloses a multi-level federal cluster resource view compression and incremental synchronization method, which is applied to a primary federal cluster in a multi-level federal cluster. The method comprises the following steps: issuing a subscription rule to each secondary federal cluster, the subscription rule being used to indicate that the secondary federal cluster performs local aggregation and compression processing on fine-grained resource states collected by a tertiary federal cluster belonging to the secondary federal cluster to form an abstract resource view; receiving an abstract incremental event reported by at least one secondary federal cluster, the abstract incremental event being generated and reported by the secondary federal cluster when a resource state change amount meets a preset triggering condition; updating a global abstract resource view according to the abstract incremental event, the global abstract resource view being composed of abstract resource views corresponding to each secondary federal cluster; and performing cross-domain resource scheduling or capacity evaluation based on the global abstract resource view. The method can significantly reduce cross-domain control traffic and reduce the computing pressure of a central control plane.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method for compressing and incrementally synchronizing resource views in a multi-level federated cluster. Background Technology

[0002] With the continuous development of cloud-native platforms, edge computing platforms, and multi-campus computing networks, multi-level federated clusters spanning regions and network layers have become an important means of achieving unified resource management, cross-domain scheduling, and disaster recovery collaboration. In a typical deployment, the third-level federated cluster is located in edge data centers, branch campuses, or regional nodes, and is responsible for collecting the status of underlying resources such as nodes, container groups (Pods), storage, and networks; the second-level federated cluster is responsible for regional aggregation of the resource status of multiple third-level federated clusters; and the first-level federated cluster performs cross-domain resource scheduling, capacity decisions, and failover based on a global view.

[0003] Under strong network conditions, the upper-level control plane can typically meet global management needs by periodically pulling or continuously subscribing to obtain the resource status of lower-level clusters. However, in weak network scenarios with limited wide-area link bandwidth, high latency, significant jitter, or intermittent interruptions, if the first-level federated cluster still directly processes the full, fine-grained state uploaded by each third-level federated cluster, it will lead to problems such as excessive cross-domain synchronization traffic, high control plane object comparison overhead, delayed state updates, and slower scheduling response.

[0004] Existing multi-cluster resource synchronization solutions mainly fall into two categories: The first approach involves the primary federated cluster periodically fetching detailed information about nodes, Pods, storage volumes, and network status from all lower-level clusters. While this approach provides a complete view, it requires frequent transfers of massive amounts of state objects when there are many clusters and a large number of resource objects. This incurs significant overhead for serialization, deserialization, differential reconciliation, and index updates. Furthermore, it is prone to synchronization timeouts, outdated views, and cross-domain decision distortion, especially in weak network environments.

[0005] The second approach involves lower-level clusters pushing event streams to the upper-level cluster in real time when resource states change. While this approach avoids periodic full data fetching, it lacks resource summaries, change threshold filtering, and jitter suppression mechanisms. Consequently, numerous short-cycle, low-value state fluctuations from the edge side are directly transmitted to the upper-level control plane. For example, phenomena such as container CrashLoopBackOff, brief network jitter, and instantaneous storage reclamation can all cause frequent event storms, further amplifying the processing burden on the central control plane.

[0006] Therefore, there is an urgent need to propose a method for resource view compression and incremental synchronization of multi-level federated clusters under weak network conditions. Summary of the Invention

[0007] To address the aforementioned issues, this invention provides a method for compressing and incrementally synchronizing resource views in a multi-level federated cluster, which can significantly reduce cross-domain control traffic and decrease the computational pressure on the central control plane.

[0008] To achieve the above objectives, this invention provides a method for resource view compression and incremental synchronization in a multi-level federated cluster. The method is applied to a first-level federated cluster within a multi-level federated cluster. The multi-level federated cluster further includes at least one second-level federated cluster communicatively connected to the first-level federated cluster, and at least one third-level federated cluster communicatively connected to each second-level federated cluster. The method includes: Subscription rules are issued to each secondary federation cluster. These rules instruct the secondary federation clusters to perform local aggregation and compression processing on the fine-grained resource status collected by the tertiary federation clusters to which they belong, forming a summary resource view. Receive at least one summary increment event reported by a secondary federation cluster. The summary increment event is generated and reported by the secondary federation cluster when the change in resource status meets a preset trigger condition. The global summary resource view is updated based on the summary incremental event. The global summary resource view is composed of the summary resource views corresponding to each secondary federation cluster. Perform cross-domain resource scheduling or capacity assessment based on the global summary resource view.

[0009] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects: (1) The present invention provides a method for compressing and incrementally synchronizing resource views in a multi-level federated cluster. By uniformly distributing subscription rules from the first-level federated cluster to each second-level federated cluster, each second-level federated cluster performs local aggregation and compression processing on the fine-grained resource status collected by its subordinate third-level federated clusters to form a summary resource view. At the same time, it only receives summary incremental events reported by the second-level federated clusters when the resource status change meets the preset trigger conditions to update the global summary resource view. Based on this, cross-domain resource scheduling or capacity assessment is performed. This method eliminates the need for the first-level federated cluster to directly process the massive amounts of raw state data from each third-level federated cluster. Instead, it uses the summary resource view as the basis for global resource awareness, fundamentally reducing the amount of data that needs to be transmitted and processed across the cross-domain control plane. This significantly reduces the state synchronization traffic on wide-area links, alleviates the object comparison and state maintenance overhead of the central control plane of the first-level federated cluster, and improves the response speed and system throughput of large-scale multi-level federated clusters in resource scheduling and capacity assessment scenarios.

[0010] (2) The present invention provides a method for compressing and incrementally synchronizing resource views of multi-level federated clusters. By initiating an on-demand detailed query request to the target secondary federated cluster only when the primary federated cluster cannot complete cross-domain resource scheduling or capacity assessment based on the global summary resource view, and completing cross-domain resource scheduling or capacity assessment based on the returned local resource details, the primary federated cluster can complete most cross-domain scheduling and capacity decisions under normal circumstances by relying only on the summary resource view. Only in special scenarios (such as disaster recovery constraint verification, precise node status confirmation, etc.) will it obtain local precise details of specific areas on demand. Thus, while maintaining the advantages of low control traffic and lightweight global view, it also takes into account the ability to examine the detailed status of local precise resources, solves the problem of insufficient decision information under complex scheduling constraints of pure summary view, and achieves the effect of "high efficiency of macro scheduling under normal conditions and on-demand acquisition of local precise details". Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a method for compressing and incrementally synchronizing resource views in a multi-level federated cluster, provided as an embodiment of this application; Figure 2 An architecture diagram of a multi-level federated cluster provided for one embodiment of this application; Figure 3 This is a flowchart illustrating a method for compressing and incrementally synchronizing resource views in a multi-level federated cluster, as provided in another embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0014] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0015] like Figure 1 As shown, a method for resource view compression and incremental synchronization in a multi-level federated cluster is provided. This method is applicable to multi-level federated clusters. Figure 2 This is the architecture diagram of the multi-level federated cluster. (Example:) Figure 2 As shown, the multi-level federated cluster includes a first-level federated cluster, at least one second-level federated cluster communicating with the first-level federated cluster, and at least one third-level federated cluster communicating with each second-level federated cluster. Each second-level federated cluster acts as a data aggregation node for its respective region and establishes communication connections with one or more third-level federated clusters. The affiliation between the third-level federated clusters and the second-level federated clusters is defined by the cluster topology configuration.

[0016] The following steps are illustrated using an example of a method executed by a first-level federated cluster: Step 101: Issue subscription rules to each secondary federation cluster. The subscription rules are used to instruct the secondary federation cluster to perform local aggregation and compression processing on the fine-grained resource status collected by the tertiary federation clusters to which it belongs, and form a summary resource view. Step 102: Receive at least one summary increment event reported by a secondary federated cluster. The summary increment event is generated and reported by the secondary federated cluster when the change in resource status meets a preset trigger condition. Step 103: Update the global summary resource view based on the summary incremental event. The global summary resource view is composed of the summary resource views corresponding to each secondary federation cluster. Step 104: Perform cross-domain resource scheduling or capacity assessment based on the global summary resource view.

[0017] The above-mentioned method for compressing and incrementally synchronizing resource views in multi-level federated clusters eliminates the need for the first-level federated cluster to directly process massive amounts of raw state data from each third-level federated cluster. Instead, it uses a summary resource view as the basis for global resource awareness, fundamentally reducing the amount of data that needs to be transmitted and processed across the cross-domain control plane. This significantly reduces the state synchronization traffic on wide-area links, alleviates the overhead of object comparison and state maintenance on the central control plane of the first-level federated cluster, and improves the response speed and system throughput of large-scale multi-level federated clusters in resource scheduling and capacity assessment scenarios.

[0018] In one embodiment, the above-mentioned method for compressing and incrementally synchronizing the resource view of a multi-level federated cluster further includes step 105: when cross-domain resource scheduling or capacity assessment cannot be completed based on the global summary resource view, an on-demand detailed query request is initiated to the target secondary federated cluster; the local resource details returned by the target secondary federated cluster in response to the on-demand detailed query request are received, and cross-domain resource scheduling or capacity assessment is completed based on the local resource details.

[0019] The target secondary federated cluster refers to a specific secondary federated cluster selected from multiple secondary federated clusters and subjected to an on-demand detailed query when the primary federated cluster is unable to complete resource matching, based on scheduling decision requirements (such as specified geographical range, resource type, or fault domain). The on-demand detailed query request may include target area identifiers and object scope limitation information. The target secondary federated cluster returns accurate resource details only within the requested area and object scope, and releases the temporary synchronization channel after the query is completed.

[0020] In this embodiment, by initiating an on-demand detailed query request to the target secondary federated cluster only when the primary federated cluster cannot complete cross-domain resource scheduling or capacity assessment based on the global summary resource view, and completing cross-domain resource scheduling or capacity assessment based on the returned local resource details, the primary federated cluster can complete most cross-domain scheduling and capacity decisions under normal circumstances by relying solely on the summary resource view. Only in special scenarios is the local precise details of a specific region obtained on demand, thereby achieving the effect of "high efficiency of macro-scheduling under normal circumstances and on-demand acquisition of local precise details".

[0021] In step 101 above, the summary resource view is formed by the following steps: the secondary federated cluster receives the subscription rules issued by the primary federated cluster, and performs local aggregation on the fine-grained resource status collected by the tertiary federated clusters to which it belongs, according to the subscription rules. The fine-grained resource status includes the original status of node resources, container group resources, storage resources and network resources in the tertiary federated clusters. The fine-grained resource status is mapped to capacity intervals according to resource type to form multiple discrete resource specification intervals. Using intervals as statistical grouping units, the fine-grained resource statuses falling into the same interval are merged and statistically analyzed, including at least one of the following: the number of available nodes, the number of schedulable container groups or the remaining capacity scale in each interval. The summary resource view is formed based on the merged and statistical results.

[0022] Subscription rules must include at least one or more of the following: business identifier, tag selector, geographic range, resource type, capacity range, or fault domain identifier. The business identifier distinguishes different business lines or applications, for example, using Kubernetes tags like app=nginx or business=finance. The tag selector filters resource objects with a specific set of tags. The geographic range limits the geographical region or availability zone to which the resource belongs. The resource type distinguishes different resource dimensions such as CPU, memory, storage, and network. The capacity range refers to the aforementioned discrete resource specification range (i.e., resource bucket), used to limit the range of resource capacity subscribed to. The fault domain identifier identifies the fault domain (such as rack or availability zone) to which the node belongs, used for disaster recovery isolation and fault detection.

[0023] In step 102 above, the method for generating the summary incremental event includes the secondary federated cluster selecting resource status data that meets the filtering conditions from the summary resource view corresponding to the secondary federated cluster according to the filtering conditions corresponding to the subscription rules, and filtering out resource status data that does not meet the filtering conditions; determining whether the change in resource status data meets the preset triggering conditions, and generating the corresponding summary incremental event if it does.

[0024] The preset trigger conditions are that the change in resource status data exceeds a preset threshold or the resource status level crosses a preset water level. The preset threshold is the relative change in the available capacity of the resource pool, for example, 5% to 15%. The preset water level is used to characterize the discrete levels of resource status, including four levels: sufficient, normal, strained, and alarm.

[0025] A summary incremental event must include at least the resource type, discrete resource specification range identifier, values ​​before and after the change, change timestamp, region, and version number of the corresponding summary resource view.

[0026] For example, the secondary federated cluster determines whether the change in resource status data meets the preset triggering conditions. If it does, it generates a corresponding summary incremental event. The secondary federated cluster also absorbs and processes multiple state changes that occur within a preset time window locally. The absorption and processing includes one or more of the following: time window smoothing, event deduplication, minimum retention time filtering, and merged reporting. After absorption and processing, it determines whether the change in resource status data after absorption and processing meets the preset triggering conditions. If it does, it generates a corresponding summary incremental event.

[0027] In one embodiment, the above-described method for multi-level federated cluster resource view compression and incremental synchronization further includes a view... Figure 1 Consistency recovery steps: Obtain the version number of the summary resource view maintained by each secondary federated cluster and the version number of the global summary resource view maintained by the primary federated cluster; when the network is restored after an interruption, compare the version number of the global summary resource view with the version number of the summary resource view of the corresponding secondary federated cluster to obtain the version difference; if the version difference is not greater than the replay window, request the secondary federated cluster to resend the missing summary incremental events to restore consistency; if the version difference is greater than the replay window, the primary federated cluster requests the corresponding secondary federated cluster to resend the current complete summary resource view.

[0028] In one embodiment, such as Figure 3 As shown, the method for compressing and incrementally synchronizing resource views in a multi-level federated cluster includes the following steps: Step S1: The third-level federated cluster collects fine-grained resource status. Each third-level federated cluster periodically or event-drivenly collects fine-grained resource status, including the original status of node resources, container group (Pod) resources, storage resources, and network resources in the cluster, and sends the collection results to its corresponding second-level federated cluster (i.e., the second-level federated cluster with which it communicates).

[0029] Specifically, fine-grained resource status includes continuous or discrete values ​​such as the CPU allocability, memory allocability, remaining disk capacity, network bandwidth utilization, Pod running status and fault count, storage volume capacity and utilization, and network interface traffic status for each node.

[0030] Step S2: The secondary federated cluster performs local aggregation and compression. The secondary federated cluster categorizes the fine-grained resource status of multiple tertiary federated clusters according to the resource type, capacity range, geographical scope, tag set, and fault domain given in the subscription rules, and maps continuous resource values ​​to discrete resource specification ranges to form a summary resource view. The summary resource view preferably includes a resource utilization summary, an available capacity range summary, a topology summary, and a fault domain summary.

[0031] This step proposes a multi-level federated cluster resource view compression mechanism for weak network conditions. The continuous fine-grained resource status of the third-level federated cluster is mapped to discrete resource specification ranges by the second-level federated cluster, and a summary resource view for scheduling decision is formed, which reduces the number of cross-domain synchronization objects from the root.

[0032] Step S3: The secondary federated cluster generates and reports incremental summary events according to subscription rules and triggering conditions. The secondary federated cluster filters the summary resource view based on subscription rules such as business tags, resource types, geographical ranges, or fault domains issued by the primary federated cluster. For the filtered summary resources, when the change in resource status data exceeds a preset threshold or the resource status level crosses a preset water level, the corresponding incremental summary event is generated and reported.

[0033] Preferably, it also includes a jitter suppression step: the secondary federated cluster absorbs and processes multiple state changes that occur within a preset time window locally. The absorption and processing includes one or more of the following: time window smoothing, event deduplication, minimum retention time filtering, and merged reporting; if the state change that is not triggered to be reported after the absorption and processing, no summary incremental event is generated.

[0034] This step proposes a subscription filtering model based on business tags, resource types, geographical scope, or fault domains. This allows the secondary federated cluster to dynamically prune the data structure of reported summary incremental events according to the scheduling intentions of the primary federated cluster, improving the consistency between synchronized data and business requirements. This step also proposes a joint threshold triggering and waterline triggering strategy suitable for federated clusters, combined with a jitter suppression mechanism. This effectively isolates high-frequency, low-value state changes in edge clusters, preventing noise from propagating to the central control plane of the upper-level federated cluster.

[0035] Step S4: The first-level federated cluster receives the incremental digest event and updates the global digest resource view. The incremental digest event preferably includes at least the resource type, resource bucket identifier, values ​​before and after the change, change timestamp, region, and version number. The global digest resource view is composed of the digest resource views corresponding to each second-level federated cluster.

[0036] It should be noted that the global summary resource view in this embodiment refers to the overall resource overview of the primary federation cluster, which is composed of the summary resource views reported by each secondary federation cluster. Logically, this global summary resource view can be considered a unified view; however, in physical implementation, the primary federation cluster does not need to maintain a centralized, complete copy of the data locally. Instead, it maintains the aggregated state of the summary views of each region locally by receiving incremental summary events reported by each secondary federation cluster. All implementations conforming to the characteristics of this solution fall within the protection scope of this invention.

[0037] In this step, the first-level federated cluster updates the global summary resource view based on the summary incremental event, without processing the full amount of raw detailed data (i.e., fine-grained resource status) of each third-level federated cluster.

[0038] Step S5: The primary federated cluster performs resource scheduling based on the summary resource view. The primary federated cluster combines business objectives, regional preferences, disaster recovery strategies, and filtering conditions corresponding to subscription rules to screen candidate regions or candidate clusters, and completes macro-level scheduling decisions or capacity assessments.

[0039] Step S6: Initiate an on-demand detailed query when necessary, and the secondary federated cluster returns local resource details. When the primary federated cluster cannot make a deterministic decision based solely on the global summary resource view, it initiates an on-demand detailed query request to the target secondary federated cluster; the secondary federated cluster returns local resource details only within the requested region and object scope, and releases the temporary synchronization channel after the query is completed.

[0040] The inability to make deterministic decisions includes, but is not limited to, the following situations: when the disaster recovery strategy of the application to be scheduled requires the deployment of instances in different fault domains, but the global summary resource view only contains resource capacity range summaries and resource utilization summaries, and does not contain detailed information at the fault domain granularity; or when the number of candidate clusters selected based on the global summary resource view is lower than a preset threshold, and more accurate node status information is needed to confirm the availability of candidate nodes. In the above situations, the scheduler of the first-level federated cluster cannot complete cross-domain resource scheduling based solely on the global summary resource view, thus triggering on-demand detailed queries.

[0041] Preferably, the above method further includes viewing Figure 1 Consistency recovery steps: The secondary federated cluster maintains the version number of the digest resource view (hereinafter referred to as the digest view version number), and the primary federated cluster maintains the version number of the global digest resource view divided by subscription dimension (hereinafter referred to as the global view version number). When the network is restored after an interruption, the global view version number of the primary federated cluster is compared with the corresponding digest view version number of each secondary federated cluster to obtain the version difference; if the version difference is within a preset range (i.e., not greater than the replay window), consistency is restored through missing incremental replay (i.e., requesting the secondary federated cluster to resend the missing digest incremental events); if the version difference exceeds the replay window, the primary federated cluster requests the corresponding secondary federated cluster to resend the current digest snapshot (i.e., the complete digest resource view) to ensure eventual consistency of multi-level views.

[0042] In this step, a visual method combining summary snapshots and incremental playback is proposed. Figure 1 The consistency recovery solution can quickly restore the consistent state of multi-level resource views in scenarios such as weak network interruption, link recovery, and window loss.

[0043] The method for compressing and incrementally synchronizing resource views in a multi-level federated cluster provided in this embodiment has the following beneficial effects: (1) It can significantly reduce cross-domain control traffic. Since the first-level federated cluster only receives the summary resource view and summary incremental events, it processes the aggregate macro view oriented to scheduling by default, rather than the full fine details of each third-level federated cluster. This avoids the full transmission of nodes, Pods, storage and network objects. Compared with the periodic full pull scheme, it can significantly reduce the amount of data for cross-domain state synchronization.

[0044] (2) It can reduce the computational pressure on the central control plane. The first-level federated cluster processes resource bucket statistics, capacity range and fault domain summaries, rather than massive fine-grained objects, which reduces the computational overhead of object comparison, index construction and scheduling pre-screening, and improves the throughput and decision response speed of the control plane.

[0045] (3) It can improve system stability in weak network scenarios. Through threshold triggering, cross-water level triggering and jitter suppression, this embodiment can suppress the surge of noise events and prevent instantaneous fluctuations at the edge of the third-level federated cluster from causing avalanche on the control surface of the first-level federated cluster.

[0046] (4) It can balance macro scheduling efficiency and local accuracy. The first-level federated cluster can complete most capacity judgments and candidate region screenings based on the summary resource view. It only initiates on-demand detailed queries on local clusters when necessary. Therefore, it ensures both scheduling speed and the ability to conduct detailed checks on the precise resource status.

[0047] (5) It has good scalability. Through the parameterized design of resource buckets, subscription rules and version synchronization windows, this embodiment can adapt to federated cluster systems of different levels, regions and resource forms, and is suitable for public cloud, private cloud, edge cloud and hybrid cloud scenarios.

[0048] In one embodiment, a system for multi-level federated cluster resource view compression and incremental synchronization is also provided, the system including at least the following functional modules: 1. The Level 3 Federated Cluster Status Acquisition Module is used to collect the raw status of node resources, Pod resources, storage resources, and network resources in this cluster. The collected status includes continuous values ​​or discrete statuses such as CPU allocability, memory allocability, remaining disk capacity, network bandwidth utilization, Pod running status, and fault count.

[0049] 2. The Level 2 Federated Cluster Summary Generation Module is used to perform local aggregation and compression processing on the original resource states of multiple Level 3 Federated Clusters belonging to this Level 2 Federated Cluster. This module maps continuous resource values ​​to discrete resource specification ranges (also called resource buckets) according to the resource type and capacity range given in the subscription rules. Preferably, resource buckets are used, for example, memory is divided into [2G, 4G), [4G, 8G), [8G, 16G), and CPU is divided into [1 core, 2 cores), [2 cores, 4 cores), [4 cores, 8 cores). The module also counts the number of available nodes, the number of schedulable Pods, or the remaining capacity in each resource bucket to form a summary resource view.

[0050] 3. An event filtering module is used to determine whether the summary resource view needs to report incremental summary events to the primary federated cluster based on preset thresholds and preset water level lines. The preset threshold can be set to a relative change in the available capacity of a resource pool exceeding 5% to 15%, preferably 10%. The preset water level line is used to characterize resource status ranges, such as four levels: sufficient, normal, strained, and alarm. Events are triggered when the resource status crosses different water level lines.

[0051] 4. The jitter suppression module is used to locally absorb state changes (such as short-cycle, high-frequency, low-value state changes) that occur multiple times within a preset time window. For frequent state changes caused by container restarts, CrashLoopBackOff, temporary network fluctuations, instantaneous capacity reclamation, etc., the noise is absorbed within the secondary federated cluster through time window smoothing, event deduplication, minimum retention time, and merging reporting mechanisms, preventing low-value noise from being propagated to the primary federated cluster.

[0052] 5. Subscription filtering module, used to distribute subscription rules from the primary federated cluster to the secondary federated cluster. Subscription rules must include at least one or more of the following: service identifier, tag selector, geographic range, resource type, capacity range, or fault domain identifier. The secondary federated cluster generates incremental summary events only for summary resources that conform to the subscription rules.

[0053] 6. The on-demand detailed query module is used to send an on-demand detailed query request to the target secondary federated cluster when the primary federated cluster cannot make deterministic decisions related to cross-domain resource scheduling or capacity assessment based solely on the summary resource view. The secondary federated cluster then establishes a temporary high-frequency synchronization channel and returns local resource details, including local detailed resource views, related node details, target Pod status, or fault domain details.

[0054] The aforementioned system for multi-level federated cluster resource view compression and incremental synchronization is applicable to multi-level federated clusters (also known as hierarchical resource management systems) consisting of a first-level federated cluster, a second-level federated cluster, and a third-level federated cluster. Its core idea is as follows: the third-level federated cluster collects fine-grained resource status of nodes, Pods, storage, and networks. The second-level federated cluster performs local aggregation, discrete mapping, and summary compression on the continuous fine-grained resource status of its subordinate third-level federated clusters to form a summary resource view. It only reports incremental summary events to the first-level federated cluster when the available capacity changes beyond a threshold or crosses a water level. The first-level federated cluster, by default, only subscribes to the summary resource views and incremental summary events reported by the second-level nodes. Only when necessary (e.g., when precise details are required for resource scheduling, troubleshooting, or disaster recovery) does it initiate on-demand detailed query requests to the corresponding second-level federated cluster. This achieves the goal of reducing cross-domain control traffic and control plane load, and also allows for the acquisition of precise local resource details when needed.

[0055] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0056] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0057] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of embodiments of this disclosure upon considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

[0058] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0059] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for compressing and incrementally synchronizing resource views in a multi-level federated cluster, characterized in that, A method applicable to a first-level federated cluster in a multi-level federated cluster, wherein the multi-level federated cluster further includes at least one second-level federated cluster communicatively connected to the first-level federated cluster, and at least one third-level federated cluster communicatively connected to each second-level federated cluster, the method comprising: Subscription rules are issued to each secondary federation cluster. The subscription rules are used to instruct the secondary federation cluster to perform local aggregation and compression processing on the fine-grained resource status collected by the tertiary federation clusters to which it belongs, so as to form a summary resource view. Receive at least one summary increment event reported by a secondary federation cluster, wherein the summary increment event is generated and reported by the secondary federation cluster when the change in resource status meets a preset trigger condition; The global summary resource view is updated based on the summary incremental event, and the global summary resource view is composed of the summary resource views corresponding to each secondary federation cluster. Perform cross-domain resource scheduling or capacity assessment based on the global summary resource view; The summary resource view is formed by the following steps: a secondary federated cluster receives subscription rules from the primary federated cluster. These subscription rules include at least one or more of the following: service identifier, tag selector, geographic range, resource type, capacity range, or fault domain identifier. Based on these subscription rules, local aggregation is performed on the fine-grained resource status collected by the tertiary federated clusters to which it belongs. This fine-grained resource status includes the original status of node resources, container group resources, storage resources, and network resources in the tertiary federated clusters. The fine-grained resource status is then mapped to the capacity range according to the resource type, forming multiple discrete resource specification ranges. Using these ranges as statistical grouping units, fine-grained resource statuses falling into the same range are merged and statistically analyzed. The summary resource view is then formed based on the merged statistical results. The method for generating the summary incremental event includes the secondary federated cluster selecting resource status data that meets the filtering conditions from the summary resource view corresponding to the subscription rule according to the filtering conditions, and filtering out resource status data that does not meet the filtering conditions; determining whether the change in resource status data meets the preset triggering conditions, and generating the corresponding summary incremental event if it does.

2. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 1, characterized in that, Also includes: When the cross-domain resource scheduling or capacity assessment cannot be completed based on the global summary resource view, an on-demand detailed query request is initiated to the target secondary federated cluster. Receive the local resource details returned by the target secondary federated cluster in response to the on-demand detailed query request, and complete the cross-domain resource scheduling or the capacity assessment based on the local resource details.

3. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 1, characterized in that, The determination of whether the change in resource status data meets the preset triggering conditions, and if so, generating a corresponding summary increment event, includes: The secondary federated cluster locally absorbs and processes multiple state changes that occur within a preset time window. The absorption and processing includes one or more of the following: time window smoothing, event deduplication, minimum retention time filtering, and merged reporting. After the absorption process, it is determined whether the change in the resource status data after the absorption process meets the preset triggering conditions. If it does, a corresponding summary increment event is generated.

4. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 1, characterized in that, The preset triggering condition is that the change in resource status data exceeds a preset threshold or the resource status level crosses a preset water level line.

5. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 4, characterized in that, The preset threshold is the relative change in the available capacity of the resource pool.

6. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 4, characterized in that, The preset water level is used to characterize the discrete levels of resource status, including four levels: sufficient, normal, strained, and alarm.

7. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 1, characterized in that, The summary incremental event includes at least the resource type, discrete resource specification range identifier, values ​​before and after the change, change timestamp, region, and version number of the corresponding summary resource view.

8. The method for multi-level federated cluster resource view compression and incremental synchronization as described in claim 1, characterized in that, It also includes view consistency restoration steps: Obtain the version number of the summary resource view maintained by each secondary federated cluster, and obtain the version number of the global summary resource view maintained by the primary federated cluster; When the network is restored after an interruption, the version number of the global summary resource view is compared with the version number of the summary resource view of the corresponding secondary federated cluster to obtain the version difference; If the version difference is not greater than the replay window, then request the secondary federated cluster to resend the missing digest incremental events to restore consistency; If the version difference is greater than the replay window, then the first-level federated cluster requests the corresponding second-level federated cluster to retransmit the current complete summary resource view.

Images