Control plane merging method and apparatus, electronic device, and storage medium

Abstract

The application relates to the technical field of distributed system control, and discloses a control plane merging method and device, electronic equipment and a storage medium. A global resource topology graph is constructed based on resource data of multiple source control planes to be merged. A differentiated merging strategy is generated based on the types of the resource data. The merging strategy is executed on the resource topology graph to generate a target control plane after merging. The application realizes smooth transition from multiple-source heterogeneous control planes to a unified target control plane, unifies the control capabilities of multiple management systems into one system, does not cause migration of the work load of the data plane, realizes smooth unification of the control plane, reduces management complexity and operation and maintenance cost, improves resource utilization, and solves the data island problem.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of distributed system control technology, and in particular to a control plane merging method, apparatus, electronic device and storage medium. Background Technology

[0002] In the construction of multi-site enterprise cloud, due to the independent construction of each resource pool in the early stage, multiple physically isolated multi-cluster control planes (such as Karmada, Rancher, and Open Cluster Management) are formed. These multi-cluster control planes mainly realize unified resource scheduling, policy distribution, multi-cluster orchestration and other capabilities, and adopt a layered architecture of control plane and data plane.

[0003] Enterprises often deploy multiple independent multi-cluster management systems at different sites to meet needs such as business isolation, geographical deployment, and disaster recovery, forming a "distributed control plane" architecture. For example: 1. Site 1's control plane - A manages member clusters {Cluster-1, Cluster-2} 2. Site 2's control plane - B manages member clusters {Cluster-3, Cluster-4} This distributed control plane architecture results in high management complexity, low resource utilization, high operation and maintenance costs, and severe data silos. Summary of the Invention

[0004] The purpose of this invention is to provide at least one control plane merging method, apparatus, electronic device, and storage medium, which can at least solve the technical problems of high management complexity, low resource utilization, high operation and maintenance costs, and severe data silos caused by the distributed control plane architecture of existing methods.

[0005] To address the aforementioned technical problems, at least one embodiment of this application provides a control plane merging method, comprising: Based on the resource data of multiple source control planes to be merged, construct a global resource topology graph; Generate differentiated merging strategies based on the types of the resource data mentioned above; The merging strategy is executed on the resource topology map to generate the merged target control surface.

[0006] At least one embodiment of this application also provides a control plane merging apparatus, comprising: The building module is used to construct a global resource topology graph based on the resource data of multiple source control planes to be merged; The strategy generation module is used to generate differentiated merging strategies based on the type of each resource data. The merging module is used to execute the merging strategy on the resource topology map and generate the merged target control plane.

[0007] At least one embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the control plane merging method described above.

[0008] At least one embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the control plane merging method described above.

[0009] The control plane merging method, apparatus, electronic device, and storage medium provided in this application construct a global resource topology map based on resource data from multiple source control planes to be merged. This comprehensively depicts the dependencies between different control planes and within the same control plane, fundamentally avoiding cascading failures caused by improper merging order and providing a deterministic sequence basis for subsequent merging operations. Secondly, generating differentiated merging strategies based on resource data types solves the technical challenge of a single merging strategy failing to accommodate multiple resource characteristics, avoiding redundancy, conflicts, or information loss caused by a "one-size-fits-all" approach to merging, and significantly improving the intelligence and automation level of merging. Finally, executing the merging strategy on the resource topology map organically combines sequence constraints with differentiated rules, achieving a smooth transition from multi-source heterogeneous control planes to a unified target control plane. This unifies the control capabilities of multiple management systems into one system without migrating the data plane workload. Thus, smooth unification of the control plane is achieved, reducing management complexity and operational costs, improving resource utilization, and solving the data silo problem.

[0010] In some optional embodiments, constructing a global resource topology graph includes: Based on the explicit dependencies between the strategy data, custom data, configuration data, and storage data in the resource data, establish a global initial directed graph structure; An implicit dependency chain is constructed between the resource data based on the reference type field in the resource data, and the implicit dependency chain is incorporated into the initial directed graph structure to obtain the resource topology graph.

[0011] In this embodiment, by simultaneously incorporating explicit dependencies and implicit dependency chains mined from reference fields, a more complete and accurate dependency graph is formed, avoiding merging order errors or cascading failures due to dependency omissions.

[0012] In some optional embodiments, the resource data type includes at least one of cluster metadata, instance data, policy data, and dependency association data, and the generation of differentiated merging strategies based on the type of each resource data includes: For the aforementioned cluster metadata type, a version overwrite strategy is used for updating; For the instance data, the strategy data, and the dependency association data, a conflict detection mechanism based on resource identifiers and content features is used to identify conflicts, and the corresponding merging strategy is executed based on the identification results.

[0013] In this embodiment, by distinguishing resource types and adopting targeted processing methods, the loss of critical data caused by simple overwriting is prevented, and the redundancy and chaos caused by indiscriminate merging are avoided, effectively ensuring the integrity, consistency and manageability of the merged resources.

[0014] In some optional embodiments, the execution of the corresponding merging strategy based on the identification result includes: When resource data with the same identifier and identical content characteristics are detected in different source control planes, it is determined to be a duplicate resource, and deduplication is performed to retain one copy; When resource data with different identifiers but consistent content characteristics are detected in different source control planes, they are determined to be semantically equivalent resources, and version-based merging is performed. When resource data with different identifiers and inconsistent content characteristics are detected in different source control planes, and the target object sets of the policies overlap, it is determined to be a distribution policy conflict. The target object sets are then merged and the merging source is recorded.

[0015] In this embodiment, duplicate resources are deduplicated to avoid redundancy, the latest version of semantically equivalent resources is retained to ensure data timeliness, and conflicting distribution strategies are intelligently merged into target object sets and their sources are recorded, thereby maximizing the retention of effective configurations while ensuring data consistency.

[0016] In some optional embodiments, generating the merged target control surface includes: Detect whether there is target resource data with the same name under the same namespace in multiple source control planes; If so, it is determined to be a naming conflict, a renaming operation is performed to generate a new name, and all reference fields of other resource data that reference the target resource data are synchronously updated to the new name.

[0017] In this embodiment, by renaming the conflicting resources and synchronously updating the reference fields in all related resources, resource overwriting or incorrect references caused by naming conflicts are avoided, ensuring the uniqueness of the merged resources.

[0018] In some optional embodiments, it also includes: Select one of the multiple source control planes as the canary control plane, and create a test load independent of the source control plane in the member cluster managed by the canary control plane; The resource data of the canary control plane is imported into the target control plane in dependency order. The member cluster is deregistered from the canary control plane and re-registered to the target control plane to verify the feasibility of the target control plane through the test load.

[0019] In this embodiment, the canary verification method is used to discover potential problems in the merging process in advance with minimal impact, effectively reducing the trial and error cost of large-scale control plane merging and avoiding the global business interruption that may be caused by direct full merging.

[0020] In some optional embodiments, verifying the feasibility of the target control surface through the test load includes: Perform quality gating verification on the target control surface, and the verification indicators include at least one of the following: hosting rate, hosting effectiveness, distribution strategy effectiveness, end-to-end control link accessibility, and hosting continuity. If the quality gate verification meets the preset quality standard, it is judged as passed and the next source control surface is merged. If the quality gating verification fails to meet the preset quality standard, a rollback process is triggered to remove the management relationship with the target control surface and restore the original control surface.

[0021] In this embodiment, by setting clear pass thresholds and rollback paths, the hosting relationship is automatically terminated and the original control plane is restored when any indicator fails to meet the standard. This effectively avoids the risk of global failure caused by merger failure while ensuring business continuity, and improves the reliability of the control plane unification process. Attached Figure Description

[0022] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0023] Figure 1 This is a flowchart of a control plane merging method provided in one embodiment of this application. Figure 1 ; Figure 2 This is a flowchart of a control plane merging method provided in one embodiment of this application. Figure 2 ; Figure 3 This is a schematic diagram of a control surface merging device provided in another embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0025] The implementation details of the control plane merging method in this embodiment are described below. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0026] Example 1: The control plane merging method of this embodiment can be applied to electronic devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 1 As shown, it includes: Step 110: Based on the resource data of the multiple source control planes to be merged, construct a global resource topology graph; Specifically, a "source control plane" refers to multiple independently running management systems, each managing a group of member clusters (such as a Kubernetes cluster). Each source control plane stores various types of "resource data" it manages, including policies, CRDs (Custom Resource Definitions), configuration information, instance definitions, etc. These resource data have multiple "dependencies," such as a distribution policy depending on the existence of a certain CRD, or an instance depending on a specific configuration item. To merge these scattered source control planes into a unified target control plane, a "global resource topology graph" needs to be established first. By constructing this topology graph, the dependency order of all resources can be clearly defined, providing a sequential basis for subsequent merge operations and preventing merge failures due to dependency breaks.

[0027] Step 120: Generate differentiated merging strategies based on the type of each resource data; Specifically, different types of resource data have different requirements when merging. This embodiment first classifies resources according to the "type of resource data", and then generates a "differentiated merging strategy" for each type of resource to solve the specific handling methods when each type of resource encounters duplication, conflict or semantic equivalence, improve the automation and accuracy of merging, and avoid data redundancy or conflict caused by a one-size-fits-all approach.

[0028] Step 130: Execute the merging strategy on the resource topology map to generate the merged target control plane.

[0029] Specifically, the "resource topology graph" provides the dependency order between resources, ensuring that dependent resources are merged first; the "merging strategy" specifies the handling methods for each type of resource when encountering duplication, conflict, or semantic equivalence. During execution, each resource is traversed according to the order of the topology graph, and the corresponding merging strategy is invoked based on the resource type. Ultimately, all valid resources from the source control planes are integrated into a unified "target control plane".

[0030] The target control plane inherits the resource definitions, configurations, and policies of each source control plane, enabling unified management of member clusters that were originally scattered across multiple source control planes, thus achieving smooth merging of control planes and unified operation and maintenance.

[0031] In summary, this embodiment constructs a global resource topology map based on resource data from multiple source control planes to be merged. This comprehensively depicts the dependencies between different control planes and within the same control plane, fundamentally avoiding cascading failures caused by improper merging order and providing a deterministic sequence basis for subsequent merging operations. Secondly, generating differentiated merging strategies based on resource data types solves the technical challenge of a single merging strategy failing to accommodate multiple resource characteristics, avoiding redundancy, conflicts, or information loss caused by a "one-size-fits-all" approach to merging, and significantly improving the intelligence and automation level of the merging process. Finally, executing the merging strategy on the resource topology map organically combines sequence constraints with differentiated rules, achieving a smooth transition from multi-source heterogeneous control planes to a unified target control plane. This unifies the control capabilities of multiple management systems into one system, without migrating the workload of the data plane. Thus, it achieves smooth unification of control planes, reduces management complexity and operational costs, improves resource utilization, and solves the data silo problem.

[0032] In some optional embodiments, constructing a global resource topology graph includes: establishing a global initial directed graph structure based on the explicit dependencies between policy data, custom data, configuration data, and storage data in the resource data; constructing implicit dependency chains between the resource data based on reference type fields in the resource data, and incorporating the implicit dependency chains into the initial directed graph structure to obtain the resource topology graph.

[0033] Specifically, the strategies, CRDs, configurations, and database data of each source control plane are scanned and acquired to analyze explicit dependencies between resources and construct a global initial directed graph structure. For implicit dependencies between resources, the following methods are used to identify them: (a) Parse the spec field of the resource and extract all field values ​​that may be reference types (such as ref, selector, target, etc.); (b) Establish the mapping relationship between field values ​​and target resources; (c) If a field of resource A references the identifier of resource B, and resource B has a reference to resource C, then construct an implicit dependency chain of A→B→C; (d) Incorporate all identified implicit dependencies into the topology graph to ensure that the merging order will not fail due to the breakage of implicit dependencies.

[0034] Finally, all identified implicit dependency chains are added as additional dependency edges to the initial directed graph structure, thus forming a complete resource topology graph. This avoids cascading failures caused by broken implicit dependencies, such as errors caused by a policy referencing a CRD that has not yet been created, or by an instance depending on a configuration that has not been imported.

[0035] In this embodiment, by simultaneously incorporating explicit dependencies and implicit dependency chains mined from reference fields, a more complete and accurate dependency graph is formed, avoiding merging order errors or cascading failures due to dependency omissions.

[0036] In some optional embodiments, the resource data type includes at least one of cluster metadata, instance data, policy data, and dependency association data. The generation of differentiated merging strategies based on the type of each resource data includes: for the cluster metadata type, using a version coverage strategy for updating; for the instance data, the policy data, and the dependency association data, using a conflict detection mechanism based on resource identifiers and content features for conflict identification, and executing the corresponding merging strategy based on the identification results.

[0037] Specifically, resources can be categorized into four types based on GVK information (the core metadata for Kubernetes resource identification): cluster metadata such as CRDs, instance data, policy data (generally indicating how instances are distributed across the cluster), and dependency association data, by traversing the source control plane's etcd (distributed key-value store). For different types of data, corresponding merging strategies are generated. For example, for cluster-level metadata, the latest version is retained; for instance data, policy data, and dependency associations, merging is required. During the merging process, conflicts are determined by checking the name (resource identifier) ​​and the hash value of the spec field (content characteristics).

[0038] In this embodiment, by distinguishing resource types and adopting targeted processing methods, the loss of critical data caused by simple overwriting is prevented, and the redundancy and chaos caused by indiscriminate merging are avoided, effectively ensuring the integrity, consistency and manageability of the merged resources.

[0039] In some optional embodiments, the execution of the corresponding merging strategy based on the identification result includes: when resource data in different source control planes are detected to have the same identifier and consistent content characteristics, they are determined to be duplicate resources, and deduplication is performed to retain one copy; when resource data in different source control planes are detected to have different identifiers but consistent content characteristics, they are determined to be semantically equivalent resources, and version-based merging is performed; when resource data in different source control planes are detected to have different identifiers and inconsistent content characteristics, and are also policy data and the target object sets affected by the policies overlap, they are determined to be distribution policy conflicts, the target object sets are merged, and the merging source is recorded.

[0040] Specifically, if the content of the same resource data in two control planes is exactly the same (name and spec hash value are the same), it is determined to be a duplicate, and the duplicate is directly removed and one copy is retained; if the names are different but the spec hash values ​​are the same, it is determined to be semantically equivalent, and the newer version is selected and retained; if the names are different and the spec hash values ​​are also different, but the resource type is a distribution strategy and the target cluster sets overlap, it is determined to be a distribution strategy conflict, and the semantic resolution process is initiated: the target cluster sets are merged and the source of the merge is recorded.

[0041] In this embodiment, duplicate resources are deduplicated to avoid redundancy, the latest version of semantically equivalent resources is retained to ensure data timeliness, and conflicting distribution strategies are intelligently merged into target object sets and their sources are recorded, thereby maximizing the retention of effective configurations while ensuring data consistency.

[0042] In some optional embodiments, generating the merged target control plane includes: detecting whether there is target resource data with the same name under the same namespace in the multiple source control planes; if so, it is determined to be a naming conflict, a renaming operation is performed to generate a new name, and the reference fields of all other resource data that reference the target resource data are synchronously updated to the new name.

[0043] Specifically, it detects various conflicts (naming, ID, version, semantics), distinguishes between duplicates and genuine conflicts through semantic analysis, and executes corresponding resolution measures and metadata cleansing. For naming conflict scenarios, the specific processing logic is as follows: (a) When multiple control planes detect resources with the same name in the same namespace, it is determined to be a naming conflict; (b) The conflicting resource is renamed, with the new name format being "original name - source control plane identifier"; (c) Related resource synchronization is performed: the reference fields of all other resources referencing the conflicting resource are synchronously updated to the new name; (d) For distribution strategy resources, the resource references in their target cluster list also need to be synchronously updated. Data exported from the source control plane generally contains some useless fields, such as resourceVersion and the resource's UUID in the source control plane, which need to be cleaned before importing into the new control plane.

[0044] In this embodiment, by renaming the conflicting resources and synchronously updating the reference fields in all related resources, resource overwriting or incorrect references caused by naming conflicts are avoided, ensuring the uniqueness of the merged resources.

[0045] In some optional embodiments, the method further includes: selecting one of the multiple source control planes as a canary control plane; creating a test load independent of the source control plane in the member cluster managed by the canary control plane; importing the resource data of the canary control plane into the target control plane in a dependency order; and deregistering the member cluster from the canary control plane and re-registering it to the target control plane, so as to verify the feasibility of the target control plane through the test load.

[0046] Specifically, a source control plane with appropriate resource size, a small number of managed clusters, and low business priority should be selected as a canary control plane instance. Test workloads should be created in the member clusters managed by this canary control plane to verify business continuity and the accessibility of the management and control links after control plane merging. The test workloads should cover the following scenarios: (a) Deploy the test application and verify that Pod scheduling and operation are normal; (b) Create a test service and verify that Service access is normal; (c) Create a test configuration and verify that configuration distribution is normal; (d) Create a test policy and verify that policy distribution is normal. The lifecycle of the test workload should be independent of the source control plane and used only for verification purposes.

[0047] Next, when importing the resource data of the canary control plane into the target control plane in dependency order, the following application conflict resolution strategy is executed: (a) Deregister the member cluster from the source control plane: Perform a cluster deregistration operation on the source control plane to terminate the management relationship between the member cluster and the source control plane; (b) Re-register member clusters to the target control plane: Perform cluster registration operations on the target control plane to establish a hosting relationship between the member clusters and the target control plane; (c) Import the canary control plane resource data into the new control plane according to the topology graph order: First, import the cluster-level metadata (such as CRD) that has no dependencies, and then import other resources in the order of dependencies, ensuring that dependent resources are imported after the resources that are depended upon. (d) Waiting for the target control plane to take over the resources: After the target control plane successfully takes over, verify that the target control plane can normally issue management and control instructions to the member cluster.

[0048] In this embodiment, the canary verification method is used to discover potential problems in the merging process in advance with minimal impact, effectively reducing the trial and error cost of large-scale control plane merging and avoiding the global business interruption that may be caused by direct full merging.

[0049] In some optional embodiments, verifying the feasibility of the target control plane through the test load includes: performing quality gating verification on the target control plane, with verification indicators including at least one of hosting rate, hosting effectiveness, distribution strategy effectiveness, end-to-end control link accessibility, and hosting continuity; if the quality gating verification meets the preset quality standard, it is determined to pass and the next source control plane is merged; if the quality gating verification does not meet the preset quality standard, a rollback process is triggered to terminate the hosting relationship with the target control plane and restore the original control plane.

[0050] Specifically, the verification metrics include: (a) Managed hosting rate verification: Count the number of member clusters successfully registered to the target control plane, and calculate the managed hosting rate = number of successfully managed clusters / total number of clusters. The managed hosting rate must reach a preset threshold (e.g., 100%) to proceed to the next stage; (b) Managed hosting efficiency verification: Verify the validity of managed connections for each member cluster by issuing probe commands through the target control plane, and calculate the efficiency = number of valid managed clusters / total number of managed clusters. The efficiency must reach a preset threshold (e.g., 100%); (c) Distribution strategy validity verification: Execute distribution strategy tests on the target control plane to verify that the strategy can be correctly distributed to the target cluster. All tested strategies must be effective; (d) End-to-end management link verification: Use test load to verify that management commands from the target control plane to the member clusters can be correctly transmitted, with no Pod restarts and no service interruptions; (e) Managed hosting continuity verification: Count the service interruption time during the switchover process, requiring zero interruption time. If all the above quantitative metrics reach the preset threshold, the quality gate is considered passed; if any one fails, a rollback process is triggered.

[0051] Based on the verification results of the quantitative indicators, the following judgments are made: (a) If all quantitative indicators of quality gate control pass (management rate = 100%, management effectiveness = 100%, all distribution strategies are effective, end-to-end management link is accessible, and management continuity is zero interruption), determine whether there are any control surfaces to be merged: if there are control surfaces to be merged, continue to merge the next control surface (a gray-scale strategy can be used to accelerate, such as canary → 30% → 100%); if there are no control surfaces to be merged, proceed to step S8 to perform global testing and formal takeover.

[0052] (b) If any quality gate fails to pass the preset threshold, the rollback process is triggered: the new control plane management relationship is terminated, the original control plane management relationship is restored, the original resource reference relationship is restored, the test load is deleted, the current unification operation is terminated and the reason for failure is recorded.

[0053] Verify all member clusters using the same steps described above, execute a global test, and if successful, officially stop all old control planes, with the unified control plane officially taking over, and delete the test loads created during the test.

[0054] In this embodiment, by setting clear pass thresholds and rollback paths, the hosting relationship is automatically terminated and the original control plane is restored when any indicator fails to meet the standard. This effectively avoids the risk of global failure caused by merger failure while ensuring business continuity, and improves the reliability of the control plane unification process.

[0055] Example 2: Based on the above embodiments, this embodiment provides an application example of a control plane merging method. For example... Figure 2The diagram shown illustrates the overall flow of the control plane merging method provided in this embodiment. The system architecture for control plane merging in this embodiment consists of three layers: the source environment, the processing module layer, and the target environment. The source environment is located at the top and contains multiple independent source control plane instances (control plane 1, control plane 2 to control plane n), each managing its own member cluster. These distributed control plane instances are the starting point for unification.

[0056] The processing module layer contains five core modules, which process data sequentially according to the data flow: 1. The control plane resource scanning and dependency analysis module mainly analyzes and obtains the control plane's policies, configurations, and metadata, and constructs a resource dependency topology graph; 2. The resource analysis module classifies resources according to their type and generates differentiated merging rules and migration order plans for each type of resource. For example, only one copy of cluster-level metadata is needed, and its migration order is higher than that of namespace-level resources. 3. Multi-source data conflict detection and resolution module, which handles naming conflicts, ID conflicts and other issues, and cleans up other useless and redundant metadata such as timestamps and UUIDs of resources in the source control plane; 4. The canary verification module performs resource migration, merging, and smooth transfer of managed services on the control plane; 5. The managed relationship status inspection module mainly performs quantitative evaluation of the results after migration and merging, checks the integrity of resources, the integrity of managed status, and the effectiveness of policies, and ensures that instances under the original canary can be managed by the new control plane. At the same time, corresponding policies are set to calculate the above results (such as weighting) to determine whether the overall migration quality meets the standards. If it meets the standards, the process continues to iterate and migrate other control planes. If it does not meet the standards, a rollback is performed, which mainly involves removing the new control plane from the managed plane and restoring the original control plane from the managed plane.

[0057] The target environment is located at the bottom and serves as a unified control plane, centrally managing all member clusters (member cluster 1 to member cluster n), thus realizing the architectural transformation from a distributed control plane to a centralized control plane.

[0058] The specific implementation steps of the control plane merging method are as follows: Step 1: Scan and acquire the policies, CRDs, configurations, and database data of each control plane, analyze the dependencies between resources, and construct a control plane resource topology map.

[0059] In step S2, the parser traverses the etcd of the source control plane and marks resources into four categories based on GVK information: cluster metadata such as CRDs, instance data, policy data (generally indicating how instances are distributed to the cluster), and dependency association data. Corresponding merging strategies are generated for different types of data. For example, for cluster-level metadata, the latest version is retained; for instance data, policy data, and dependency associations, merging is required. During the merging process, conflicts are determined by checking the name and the hash value of the spec field. In addition, for distribution strategies in policy-type resources, it is also necessary to analyze the cluster target list in its spec field to identify distribution strategy conflicts between different controllers for the same resource.

[0060] In addition, implicit dependencies between resources are identified using the following methods: (a) parsing the spec field of a resource and extracting all possible reference type field values ​​(such as ref, selector, target, etc.); (b) establishing a mapping relationship between field values ​​and target resources; (c) if a field of resource A references the identifier of resource B, and resource B in turn references resource C, then construct an implicit dependency chain of A→B→C; (d) incorporating all identified implicit dependencies into the topology graph to ensure that the merging order will not fail due to implicit dependency breaks.

[0061] Furthermore, the semantic analysis module determines the conflict type: if the content of the same resource in two control planes is exactly the same (name and spec hash value are the same), it is determined to be a duplicate, and one copy is directly deduplicated and retained; if the names are different but the spec hash values ​​are the same, it is determined to be semantically equivalent, and the newer version is selected and retained; if the names are different and the spec hash values ​​are also different, but the resource type is a distribution strategy and the target cluster sets overlap, it is determined to be a distribution strategy conflict, and the semantic resolution process is initiated: the target cluster sets are merged, and the source of the merge is recorded; other cases are determined to be normal merge objects.

[0062] Step S3, Multi-source Data Conflict Detection and Preprocessing: Detect various conflicts (naming, ID, version, semantics), distinguish between duplicates and genuine conflicts through semantic analysis, and execute corresponding resolution measures and metadata cleaning. For naming conflict scenarios, the specific processing logic is as follows: (a) When multiple control planes detect resources with the same name under the same namespace, it is determined to be a naming conflict; (b) Rename the conflicting resource, with the new name format being "original name - source control plane identifier"; (c) Perform associated resource synchronization: synchronously update the reference fields of all other resources referencing the conflicting resource to the new name; (d) For distribution strategy resources, it is also necessary to synchronously update the resource references in their target cluster list. Data exported from the source control plane generally contains some useless fields, such as resourceVersion, the resource's UUID in the source control plane, etc., which need to be cleaned before importing into the new control plane.

[0063] Step S4: Select a control plane with appropriate resource size, a small number of managed clusters, and low business priority as a canary control plane instance. Create test workloads in the member clusters it manages to verify business continuity and accessibility of the management and control links after control plane merging. The test workloads should cover the following scenarios: (a) Deploy the test application and verify that Pod scheduling and operation are normal; (b) Create a test service and verify that Service access is normal; (c) Create a test configuration and verify that configuration distribution is normal; (d) Create a test policy and verify that policy distribution is normal. The lifecycle of the test workload should be independent of the source control plane and used only for verification purposes.

[0064] Unlike traditional application deployment canary verification (such as Argo Rollouts), the canary verification in this application is aimed at control plane merging scenarios: - The verification objects differ: Application deployment verifies data plane resources such as Pods / Services; this application verifies the integrity of control plane resources, the validity of hosting relationships, and the correctness of policy distribution. - Different quality metrics: Application releases focus on error rate and latency; this application focuses on management rate, effectiveness, and end-to-end control link accessibility. - Different rollback mechanisms: Traditional methods usually involve rolling back the application release version; this application rolls back the management relationship and resource references.

[0065] Step S5: Export the resources and data of the canary control plane, apply the conflict resolution strategy, and perform the following operations: (a) Deregister the member clusters from the source control plane: Perform a cluster deregistration operation on the source control plane to terminate the management relationship between the member clusters and the source control plane; (b) Re-register the member clusters to the target control plane: Perform a cluster registration operation on the target control plane to establish a management relationship between the member clusters and the target control plane; (c) Import the resource data of the canary control plane into the new control plane according to the topology graph order of dependencies: First, import the cluster-level metadata (such as CRD) without dependencies, and then import other resources in the order of dependencies to ensure that dependent resources are imported after the resources they depend on; (d) Wait for the target control plane to take over the resources: After the target control plane successfully takes over, verify that the target control plane can issue control commands to the member clusters normally.

[0066] Step S6, Managed Status Check, specifically includes the following quantitative indicator verifications: (a) Managed Rate Verification: Count the number of member clusters successfully registered to the target control plane, calculate the managed rate = number of successfully managed clusters / total number of clusters. The managed rate must reach a preset threshold (e.g., 100%) before proceeding to the next stage; (b) Managed Efficiency Verification: Verify the validity of managed connections for each member cluster by issuing probe commands through the target control plane, calculate the efficiency = number of valid managed clusters / total number of managed clusters. The efficiency must reach a preset threshold (e.g., 100%); (c) Distribution Policy Validity Verification: Execute distribution policy tests on the target control plane to verify that the policy can be correctly distributed to the target cluster. All tested policies must be effective; (d) End-to-End Management Link Verification: Use test load to verify that management commands from the target control plane to the member clusters can be correctly transmitted, and that Pods do not restart or services are not interrupted; (e) Managed Continuity Verification: Count the service interruption time during the switchover process. The interruption time must be zero. If all the above quantitative indicators reach the preset threshold, the quality gate is considered passed; if any one fails, a rollback process is triggered.

[0067] Step S7, Quality Gating Judgment: Based on the quantitative indicator verification results of Step S6, the following judgments are performed: (a) If all quantitative indicators of quality gating pass (management rate = 100%, management effectiveness = 100%, all distribution strategies are effective, end-to-end management link is accessible, and management continuity is zero interruption), determine whether there are any control planes to be merged: If there are control planes to be merged, return to Step S1 to continue merging the next control plane (a gray-scale strategy can be used to accelerate this, such as canary → 30% → 100%); if there are no control planes to be merged, proceed to Step S8 to perform global testing and formal takeover. (b) If any quality gating item fails to pass the preset threshold, a rollback process is triggered: the new control plane management relationship is released, the original control plane management relationship is restored, the original resource reference relationship is restored, the test load is deleted, the current unification operation is terminated, and the reason for failure is recorded.

[0068] Step S8: Verify all member clusters using the same steps described above, execute a global test, and if successful, officially stop all old control planes, with the unified control plane officially taking over, and delete the test loads created during the test.

[0069] In summary, the control surface merging method of this embodiment has at least the following beneficial effects: 1. Achieve intelligent classification and implicit dependency analysis of control plane resources: Identify implicit dependencies between resources through semantic analysis, construct a complete resource topology graph containing direct and implicit dependencies, and merge them according to a safe dependency order to avoid cascading failures.

[0070] 2. Provide a semantic resolution mechanism for multi-source distribution strategy conflicts: Based on semantic analysis, determine the type of distribution strategy conflict (such as target cluster set conflict, distribution priority conflict), generate semantically equivalent merging strategies, and ensure that the merged distribution strategy is complete and effective.

[0071] 3. Enable automatic synchronization and modification of associated resources: When a resource needs to be renamed due to a conflict, automatically identify and synchronously modify all associated resources that reference that resource to ensure that the reference relationship is complete and unbroken after the merger.

[0072] 4. Establish a quality verification system for control plane hosting status: Define quantitative indicators for hosting rate (number of successfully hosted clusters / total number of clusters), hosting effectiveness (number of clusters with valid hosting relationships / total number of clusters), and hosting continuity (zero business interruption time during the switchover process). Verify through three stages: canary verification, gray-scale iteration, and full switchover to ensure the business continuity of control plane merging.

[0073] 5. Provides a fine-grained rollback mechanism: When quality verification fails, the complete rollback process of "removing the new control plane management - restoring the original control plane management - restoring the original resource reference relationship" is automatically executed.

[0074] 6. Provides a universal control plane unified framework: suitable for various multi-cluster management systems such as Karmada, Rancher, and OCM.

[0075] Example 3: Another embodiment of this application relates to a control plane merging device. The implementation details of the control plane merging device in this embodiment are described below. The following implementation details are provided for ease of understanding and are not essential for implementing this solution. A schematic diagram of the control plane merging device in this embodiment can be seen as follows: Figure 3 As shown, it includes a construction module 310, a strategy generation module 320, and a merging module 330.

[0076] Module 310 is used to construct a global resource topology map based on the resource data of multiple source control planes to be merged. The strategy generation module 320 is used to generate differentiated merging strategies based on the type of each resource data. The merging module 330 is used to execute the merging strategy on the resource topology map to generate the merged target control surface.

[0077] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0078] In some alternative embodiments, the control plane merging apparatus can implement the control plane merging method described in any of the above embodiments.

[0079] Example 4: Another embodiment of this application relates to an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the control plane merging methods described in the above embodiments.

[0080] In this embodiment, the memory and processor are connected via a bus, which can include any number of interconnected buses and bridges, connecting various circuits of one or more processors and the memory together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0081] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0082] Example 5: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0083] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0084] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A control surface merging method, characterized in that, include: Based on the resource data of multiple source control planes to be merged, construct a global resource topology graph; Generate differentiated merging strategies based on the types of the resource data mentioned above; The merging strategy is executed on the resource topology map to generate the merged target control surface.

2. The control surface merging method according to claim 1, characterized in that, The construction of the global resource topology graph includes: Based on the explicit dependencies between the strategy data, custom data, configuration data, and storage data in the resource data, establish a global initial directed graph structure; An implicit dependency chain is constructed between the resource data based on the reference type field in the resource data, and the implicit dependency chain is incorporated into the initial directed graph structure to obtain the resource topology graph.

3. The control surface merging method according to claim 1, characterized in that, The resource data types include at least one of cluster metadata, instance data, policy data, and dependency association data. The generation of differentiated merging strategies based on the types of each resource data type includes: For the aforementioned cluster metadata type, a version overwrite strategy is used for updating; For the instance data, the strategy data, and the dependency association data, a conflict detection mechanism based on resource identifiers and content features is used to identify conflicts, and the corresponding merging strategy is executed based on the identification results.

4. The control surface merging method according to claim 3, characterized in that, The execution of the corresponding merging strategy based on the identification results includes: When resource data with the same identifier and identical content characteristics are detected in different source control planes, it is determined to be a duplicate resource, and deduplication is performed to retain one copy; When resource data with different identifiers but consistent content characteristics are detected in different source control planes, they are determined to be semantically equivalent resources, and version-based merging is performed. When resource data with different identifiers and inconsistent content characteristics are detected in different source control planes, and the target object sets of the policies overlap, it is determined to be a distribution policy conflict. The target object sets are then merged and the merging source is recorded.

5. The control surface merging method according to claim 1, characterized in that, The generation of the merged target control surface includes: Detect whether there is target resource data with the same name under the same namespace in multiple source control planes; If so, it is determined to be a naming conflict, a renaming operation is performed to generate a new name, and all reference fields of other resource data that reference the target resource data are synchronously updated to the new name.

6. The control surface merging method according to claim 1, characterized in that, Also includes: Select one of the multiple source control planes as the canary control plane, and create a test load independent of the source control plane in the member cluster managed by the canary control plane; The resource data of the canary control plane is imported into the target control plane in dependency order. The member cluster is deregistered from the canary control plane and re-registered to the target control plane to verify the feasibility of the target control plane through the test load.

7. The control surface merging method according to claim 6, characterized in that, Verifying the feasibility of the target control surface through the test load includes: Perform quality gating verification on the target control surface, and the verification indicators include at least one of the following: hosting rate, hosting effectiveness, distribution strategy effectiveness, end-to-end control link accessibility, and hosting continuity. If the quality gate verification meets the preset quality standard, it is judged as passed and the next source control surface is merged. If the quality gating verification fails to meet the preset quality standard, a rollback process is triggered to remove the management relationship with the target control surface and restore the original control surface.

8. A control surface merging device, characterized in that, include: The building module is used to construct a global resource topology graph based on the resource data of multiple source control planes to be merged; The strategy generation module is used to generate differentiated merging strategies based on the type of each resource data. The merging module is used to execute the merging strategy on the resource topology map and generate the merged target control plane.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the control plane merging method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the control plane merging method according to any one of claims 1 to 7.

Images