Automatic construction device for Kubernetes resource object association relationship

Abstract

The invention discloses an automatic construction device and method for a Kubernetes resource object incidence relation, and can be used for the technical field of computers. The method comprises the following steps of: acquiring full-amount and incremental metadata of a resource object from a Kubernetes cluster through an Informer; according to a pre-configured rule, based on the metadata, calculating and constructing a first type of association relationship between the resource objects; extracting multi-dimensional features of a resource object from the metadata and carrying out vectorization processing; based on the vector distance of the vectorized features, constructing a second type of association relationship between the resource objects through a clustering algorithm; converting the vectorized features, inputting the converted vectorized features into a neural network model for calculation and classification, and constructing a third-class association relationship between the resource objects based on a classification result; and carrying out merging, duplicate removal and validity verification on the first type, the second type and the third type of association relationships to obtain resource object association relationship data.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, in particular to a device for automatically constructing association relationship of Kubernetes resource objects. BACKGROUND

[0002] Kubernetes (k8s) is an open-source container orchestration platform developed by Google, which provides a series of complete functions such as deployment and running of containerized applications, resource scheduling, service discovery and dynamic scaling, and improves the convenience of large-scale container cluster management. The resource objects of kubernetes are not isolated, but have association relationship. There are multiple resource objects in kubernetes, and kubernetes realizes flexibility and scalability by designing high abstraction, refining resource objects and realizing flexibility and scalability through association relationship, such as association of Service and Ingress objects, which makes network configuration more flexible and manageable; association of Pod and ReplicaSet, which provides elasticity and automatic expansion capability; association of Pod and Service, which provides load balancing and service discovery capability. Moreover, in actual application scenarios, there are some potential business association relationships among the resource objects of kubernetes.

[0003] The existing related technology mainly focuses on recording the change history of resources by using List-Watch mechanism, and does not involve automatic calculation and construction of association relationship among resource objects. At present, there is a lack of a solution that can systematically and automatically mine multi-level association relationship among Kubernetes resource objects. SUMMARY

[0004] To solve at least part of the above technical problems, the embodiments of the present application provide a device and method for automatically constructing association relationship of Kubernetes resource objects.

[0005] The embodiment of the application provides an automatic construction device of a Kubernetes resource object association relationship, which comprises: a metadata acquisition module configured to acquire full and incremental metadata of resource objects from a Kubernetes cluster based on a List-Watch mechanism through an Informer; a rule association construction module configured to calculate and construct a first type of association relationship between resource objects based on the metadata of the resource objects according to a preconfigured rule; a feature processing module configured to extract multi-dimensional features of the resource objects from the metadata and perform vectorization processing on the features; a clustering association construction module configured to construct a second type of association relationship between the resource objects by a clustering algorithm based on vector distances of the features after vectorization; a neural network association construction module configured to input the features after vectorization into a neural network model after transformation to perform calculation and classification, and construct a third type of association relationship between the resource objects based on a classification result; and a data fusion module configured to merge, remove duplicates and perform validity verification on the first type, the second type and the third type of association relationship, and output resource object association relationship data.

[0006] In some embodiments, the rule association construction module is specifically configured to: load and parse a pre-defined rule set, the rule set defining a source resource type, a target resource type, an association relationship type, a matching condition and an association logic of each rule; listen to a metadata change event of the resource object; when a type of the resource object matches the source resource type of a rule in the rule set, and the metadata of the resource object meets the matching condition defined by the rule, execute the association logic of the rule, wherein the association logic is: extracting target resource identification information from an explicitly declared association field of the current resource object, and querying a target resource object in the Kubernetes cluster according to the identification information; based on the current resource object and the queried target resource object, constructing association relationship data of the association relationship type defined by the rule.

[0007] In some embodiments, the explicitly declared association field comprises at least one of the following: a label selector field, a name direct reference field and an owner reference field.

[0008] In some embodiments, the clustering association construction module is specifically configured to: group feature vectors of the same category extracted from a plurality of resource objects into a feature vector set; calculate distances between vectors in the feature vector set by using a set clustering algorithm, and divide the resource objects into one or more clusters according to the vector distances; and establish the second type of association relationship between the resource objects divided into the same cluster.

[0009] In some embodiments, the neural network association construction module is specifically used to: input the vectorized features into a feature transformation network containing one or more fully connected layers for nonlinear feature transformation to obtain a higher-order feature representation; input the higher-order feature representation into a Softmax classifier for calculation and output the predicted probability of potential association between resource objects; and construct the third type of association between resource object pairs whose predicted probability exceeds a set threshold.

[0010] In some embodiments, the data fusion module is specifically used to: store the first, second, and third types of association relationships in a unified format of triples, wherein the triples include a source resource UID, an association type, and a target resource UID; generate a unique identifier based on the source resource UID, association type, and target resource UID in the triples, and merge and deduplicate association relationships with the same unique identifier; verify the validity of the deduplicated association relationship data, wherein the validity verification includes: verifying whether the resource objects pointed to by the source resource UID and the target resource UID exist in the current Kubernetes cluster; and output the resource object association relationship data that passes the validity verification.

[0011] In some embodiments, the apparatus further includes: an association model definition module for defining an association data model, the model including an association type, a unique identifier of a source resource object, and a unique identifier of a target resource object, wherein the association type includes at least one of infrastructure topology relationships, orchestration and scheduling relationships, observability relationships, and business relationships.

[0012] This application provides an automatic method for constructing association relationships among Kubernetes resource objects, comprising: obtaining full and incremental metadata of resource objects from a Kubernetes cluster using an Informer based on a List-Watch mechanism; calculating and constructing a first type of association relationship between resource objects based on the metadata of the resource objects according to pre-configured rules; extracting multi-dimensional features of resource objects from the metadata and vectorizing the features; constructing a second type of association relationship between resource objects based on the vector distance of the vectorized features using a clustering algorithm; transforming the vectorized features and inputting them into a neural network model for calculation and classification, and constructing a third type of association relationship between resource objects based on the classification results; merging, deduplicating, and validating the first, second, and third types of association relationships to obtain resource object association relationship data.

[0013] This application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the methods described in any of the above embodiments.

[0014] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0015] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0016] The apparatus and method for automatically constructing Kubernetes resource object relationships provided in this application propose a multi-level approach based on a rule engine, feature vectorized clustering, and neural network model classification. This approach can comprehensively uncover both intuitive and potential relationships between Kubernetes resource objects. The constructed multi-level relationship data can describe the cluster topology from multiple dimensions and can be used to quickly determine the impact range of resource changes and failures, significantly improving the data operation capabilities and operational efficiency of the Kubernetes cluster. Flexible configuration is achieved through the rule engine, and intelligent discovery is achieved through clustering and neural networks, balancing accuracy and intelligence in processing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art 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. In the drawings:

[0018] Figure 1 This is a schematic diagram of the structure of an automatic construction device for Kubernetes resource object association provided in an embodiment of this application.

[0019] Figure 2 This is a flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0020] Figure 3 This is a flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0021] Figure 4 This is a partial flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0022] Figure 5This is a partial flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0023] Figure 6 This is a partial flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0024] Figure 7 This is a partial flowchart illustrating an automatic construction method for Kubernetes resource object associations provided in an embodiment of this application.

[0025] Figure 8 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily arranged.

[0027] The terms “first,” “second,” etc., used in this document are not intended to specifically refer to order or sequence, nor are they used to limit this application; they are merely used to distinguish elements or operations described using the same technical terms.

[0028] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0029] The term "and / or" as used in this document includes any or all of the items mentioned.

[0030] Figure 1 This is a schematic diagram of the structure of an automatic construction device for Kubernetes resource object associations provided in an embodiment of this application. Figure 1 As shown in the figure, an automatic construction device for Kubernetes resource object associations provided in this application embodiment includes:

[0031] Metadata Acquisition Module 1 is used to obtain full and incremental metadata of resource objects from the Kubernetes cluster through Informer based on the List-Watch mechanism;

[0032] Specifically, Informer is a high-level abstraction provided by Kubernetes to simplify the use of the List-Watch mechanism. Informer automatically performs List and Watch operations in the background, transforming resource change events into objects that can be handled by the client. During the initialization phase, Informer performs List operations, loading the resource list into the local cache. Subsequently, it establishes a Watch connection, continuously receiving event notifications of resource changes and updating the local cache accordingly. Informer automatically handles connection issues with the API server, as well as the disconnection and reconstruction of Watch connections.

[0033] The List-Watch mechanism is used to monitor resource changes. It allows clients to establish a long-lived connection with the Kubernetes API server and subscribe to change events for specific resources. The List operation retrieves a list of specified resource types. The Watch operation is a continuous listening mechanism built on top of the List. Once a client subscribes to a Watch for a specific resource type, the Kubernetes API server will send a corresponding event notification to the client whenever that resource changes.

[0034] Metadata refers to the data in a Kubernetes resource object that describes information about itself. It mainly includes:

[0035] Identification information: name, namespace, uid.

[0036] Labels: Key-value pairs used to identify identifiable attributes of an object, and are the key basis for filtering and association (e.g., app:frontend).

[0037] Annotations: Key-value pairs used to store non-identifiable metadata for use by tools or libraries.

[0038] OwnerReferences: Explicitly declares which parent object owns and manages the object (e.g., a Pod is owned by a ReplicaSet).

[0039] Rule association construction module 2 is used to calculate and construct the first type of association relationship between resource objects based on the metadata of the resource objects according to the pre-configured rules;

[0040] Specifically, pre-configured rules refer to logical judgment statements defined in advance in the form of code or configuration files (such as YAML). In this solution, rules are used to describe "if a resource meets certain conditions, then it has a certain association with another resource." Example rule: "If a Service's selector field matches a Pod's labels, then establish an 'exposure' relationship between the Service and the Pod." Pre-configured rules solidify domain knowledge (such as Kubernetes design principles and business deployment specifications) to achieve automated and configurable discovery of associations.

[0041] The rule association building module 2 can be in the form of a rule engine. It can be implemented using a specific rule configuration language that the rule engine can understand. Based on the annotation field, label field, and volume and other association fields of Kubernetes resource objects, it can customize the association relationship calculation rules applicable to Kubernetes cluster resource objects and build association relationship data.

[0042] Feature processing module 3 is used to extract multi-dimensional features of resource objects from the metadata and to vectorize the features;

[0043] Specifically, it can extract all the features of Kubernetes resource objects, such as namespace and name data, creationTimestamp data, tag data, resource quota data, permission data, network configuration data, volume configuration data, permission configuration data, status information data, and custom resource object data. It can also obtain infrastructure data such as cluster information data to which the resource object belongs, business information data, and other feature data, and vectorize each feature data.

[0044] Vectorization refers to the process of converting unstructured, multi-dimensional feature data into numerical vectors that can be processed by computers. Example: A set of resource tags {"app":"nginx","env":"prod"} can be converted into a sparse vector [1, 0, 1, ...] using a bag-of-words model or encoding techniques. Only by converting features into numerical vectors can subsequent mathematical tools (clustering algorithms) and mathematical models (neural networks) be used for analysis and computation; this is a crucial prerequisite for achieving intelligent data mining.

[0045] Clustering association construction module 4 is used to construct the second type of association between resource objects based on the vector distance of vectorized features through a clustering algorithm;

[0046] Specifically, clustering algorithms are unsupervised learning algorithms that aim to divide samples in a dataset into several disjoint clusters, such that samples within the same cluster are similar to each other, while samples in different clusters are dissimilar. Common algorithms include K-Means and DBSCAN, which measure the similarity between samples by calculating vector distances (such as Euclidean distance and cosine distance). Through clustering algorithms, resources can be automatically discovered to "cluster" together in the feature space without predefined rules, thereby uncovering potential similarity-based relationships (e.g., which Pods might belong to the same batch processing task not covered by a Service).

[0047] The neural network association construction module 5 is used to transform the vectorized features and input them into the neural network model for calculation and classification, and to construct a third type of association between resource objects based on the classification results;

[0048] Specifically, neural network models can learn much more complex and abstract underlying patterns than rules and clustering. For example, by learning from historical data, it might discover a specific combination of resource quotas, creation timestamps, and network configurations that often indicates a close calling relationship between two microservices, even if they are not explicitly declared directly.

[0049] The data fusion module 6 is used to merge, deduplicate, and validate the first, second, and third types of association relationships, and output resource object association relationship data.

[0050] Specifically, the same association may be discovered simultaneously by different modules (such as rules and neural networks), requiring the generation of unique keys based on source, target, type, etc., for deduplication. Furthermore, it is necessary to check whether the resource objects pointed to by both ends of the association still exist in the cluster to filter out associations that have become invalid due to resource deletion. Therefore, ensuring the accuracy, uniqueness, and real-time nature of the final output is a key guarantee for the availability of the production environment.

[0051] The automatic construction device for Kubernetes resource object associations provided in this application embodiment obtains full and incremental metadata of resource objects from the Kubernetes cluster using Informer based on the List-Watch mechanism; calculates and constructs a first type of association between resource objects based on the metadata of the resource objects according to pre-configured rules; extracts multi-dimensional features of resource objects from the metadata and vectorizes the features; constructs a second type of association between resource objects based on the vector distance of the vectorized features using a clustering algorithm; transforms the vectorized features and inputs them into a neural network model for calculation and classification, and constructs a third type of association between resource objects based on the classification results; merges, deduplicates, and verifies the validity of the first, second, and third types of associations, and outputs resource object association data. Thus, based on the multi-dimensional features of Kubernetes resource objects, a method based on a rule engine, feature vectorization clustering, and neural network model classification is proposed to mine multi-dimensional associations of Kubernetes resource objects, constructing a Kubernetes resource object topology structure that includes rule associations and potential business associations, thereby improving the data operation and maintenance capabilities of the Kubernetes cluster.

[0052] In some embodiments, the rule association construction module 2 is specifically used for: loading and parsing a predefined rule set, wherein the rule set defines the source resource type, target resource type, association relationship type, matching conditions, and association logic for each rule; listening for metadata change events of resource objects; and executing the association logic of the rule when the type of a resource object matches the source resource type of a rule in the rule set, and the metadata of the resource object satisfies the matching conditions defined by the rule. The association logic is as follows: extracting target resource identification information from the explicit declaration association field of the current resource object, and querying the target resource object in the Kubernetes cluster based on the identification information; and constructing association relationship data of the association relationship type defined by the rule based on the current resource object and the queried target resource object.

[0053] Specifically, a predefined rule set is a pre-configured collection of rules, which can exist as a file or configuration item in formats such as YAML or JSON. Each rule is an independent instruction that tells the rule engine how to handle a specific type of resource.

[0054] The source resource type and target resource type are the resource categories defined in the rule. The source resource type is the starting resource type from which the rule is triggered (such as Pod, Service), and the target resource type is the object type that the rule searches for that is associated with the source resource (such as Service, PersistentVolumeClaim). Example: A rule with a source type of Pod and a target type of Service means "find the corresponding Service for a Pod".

[0055] Relationship types describe the nature of the relationship. Examples: Owned-By, Uses-Volume, Exposed-By. This makes the output relational data easier to understand and utilize by other systems.

[0056] Matching conditions are a series of preconditions for determining whether to execute the current rule. They are usually based on the metadata of the source resource (such as Labels, Annotations, and whether the field exists). Example: metadata.labels.app exists (the app label exists), spec.volumes (a storage volume is defined).

[0057] Association logic is the core part of the rules, defining the specific steps and algorithms for finding the target resource from the source resource.

[0058] Explicitly declared association fields are those fields in the metadata of a Kubernetes resource object that directly and explicitly reference or point to other resources. This forms the basis for the execution of association logic. Explicitly declared association fields include at least one of the following: Label Selector fields: such as `Service.spec.selector`, which matches labels of other resources using key-value pairs; Direct Name Reference fields: such as `Pod.spec.volumes.persistentVolumeClaim.claimName`, which directly references another resource by name; OwnerReference fields: such as `Pod.metadata.ownerReferences`, which declares which parent resource owns the resource.

[0059] Target resource identification information is key information extracted from "Explicitly Declared Association Fields" used to uniquely or in batches locate target resources. Examples: the key-value pair {app:frontend} extracted from Service.spec.selector; the PVC name "nginx-pvc" extracted from the claimName field.

[0060] This demonstrates that by predefined rule sets, the domain knowledge of Kubernetes design principles and business architecture is solidified. The rule engine automatically listens for events, matches conditions, and executes logic, replacing the traditional method of manually querying kubectl or writing scripts. This greatly improves efficiency, avoids oversights and errors from manual operations, and achieves accurate relational discovery 24 / 7 unattended operation. It also fully leverages Kubernetes' native design to ensure the reliability and real-time nature of the results: the core of the relational logic is based on queries using explicitly declared relational fields in Kubernetes (such as selector and ownerReferences). These fields are part of the official Kubernetes API contract and form the basis of its control logic (such as service discovery, scaling, and garbage collection). This ensures that the constructed first-type relational relationships are highly accurate and completely consistent with the actual operating logic of the cluster. Combined with the mechanism of listening for change events, it can respond to cluster changes in real time, ensuring the timeliness of relational data. Furthermore, it provides excellent scalability and maintainability: the rule set is separated from the code. When adding new relational types or modifying existing logic, it is usually only necessary to add, delete, or modify rule entries in the configuration file, without rewriting and deploying the core code. This significantly reduces maintenance costs, enabling the device to flexibly adapt to different business scenarios, team specifications, and Kubernetes version evolution. Business developers can easily customize rules to describe business-specific relationships. Furthermore, it provides structured semantic data for upper-layer applications: the output is not a simple resource list, but standardized data with relationship types (such as (PodA, Uses-Volume, PVCX)). This structured, semantically rich data can be directly visualized into topology maps by visualization systems, used by operations and maintenance monitoring systems to accurately locate the scope of fault impact, and used by security audit systems to analyze access links, providing a solid data foundation for data-driven operations and governance.

[0061] Therefore, the rule association building module 2 implements an efficient, reliable, and scalable automatic discovery mechanism for associations by encoding domain knowledge into configurable rules and accurately utilizing explicit declaration fields provided by the native Kubernetes API.

[0062] In some embodiments, the clustering association construction module 4 is specifically used to: form a feature vector set from feature vectors of the same category extracted from multiple resource objects; calculate the distance between each vector in the feature vector set using a set clustering algorithm; divide the resource objects into one or more clusters based on the vector distance; and establish the second type of association relationship between resource objects divided into the same cluster.

[0063] Specifically, feature vectors of the same category refer to numerical vectors formed by extracting features representing the same attribute from different resource objects and vectorizing them. Examples include: label vectors, which aggregate all resource labels into a bag-of-words, where each resource can be represented as a vector, with each dimension representing the existence or importance of a specific label; resource request vectors, which extract the CPU and memory requests of each Pod, normalize them, and form a two-dimensional vector; and annotation vectors, similar to label vectors but dealing with information from annotations. Clustering features of the "same category" is only meaningful. Comparing the similarity of resource labels is meaningful, but comparing the labels of one resource with the CPU usage of another is meaningless.

[0064] The feature vector set is a collection of feature vectors from all the resource objects to be analyzed. This set constitutes a feature space, where each resource is a point in this space.

[0065] Vector distance is a mathematical metric used in feature space to measure the similarity or difference between two vectors (i.e., two resources). The closer the distance, the higher the similarity; the farther the distance, the greater the difference. Examples include Euclidean distance and cosine similarity.

[0066] A cluster is the output of a clustering algorithm, that is, a set of similar data points. In this scheme, a cluster represents a group of resource objects that are highly similar in a specific feature dimension.

[0067] The technical solution of the cluster association building module 4 has at least the following technical effects:

[0068] It enables intelligent discovery of potential and implicit relationships: Unlike rule engines that rely on "explicitly declared fields," clustering algorithms do not depend on any predefined association rules. They discover groups based on the distribution patterns (vector distances) of the data itself through pure mathematical calculations. This allows it to discover relationships that exist but have not been explicitly declared by developers. For example, it can group Pods belonging to different Deployments that are configured with the same special tag (such as backup:"true") or resource allocation into one cluster, thus discovering a potential association group based on a "backup" or "resource model"—something rule engines cannot do.

[0069] Highly automated and requiring no prior knowledge: This module is an unsupervised process, requiring no pre-prepared training data or defined complex rules. Once the feature vectors are extracted, the algorithm works automatically. This significantly lowers the barrier to entry and maintenance costs. Without needing to know all possible correlation patterns in advance, the device can automatically uncover unknown, valuable relationships, achieving true "data-driven" operation.

[0070] Provides data support for resource management optimization: Clustering results reveal the actual distribution and grouping of resources within the cluster. This provides crucial insights for many optimization operations. For example, resource optimization: if all Pods in a cluster request a large amount of CPU but the actual utilization is low, this may mean that resource request configuration needs to be optimized to save costs; fault diagnosis: if a faulty Pod belongs to a specific cluster, it is possible to quickly check whether other Pods in the same cluster also have similar risks, achieving accurate fault impact analysis; scheduling recommendations: scheduling closely related Pods within the same cluster to the same node or availability zone can reduce network overhead and improve performance.

[0071] Complementing the advantages of the rule engine, a multi-layered knowledge system is constructed: the rule engine outputs "deterministic" associations (A is definitely associated with B), while clustering outputs "probabilistic" or "similar" associations (A and B are very likely to be associated). The combination of these two approaches results in a resource association graph that includes both rigorous official contractual relationships (first-type associations) and flexible, statistically significant group relationships (second-type associations). This three-dimensional knowledge representation more comprehensively reflects the true state of complex systems, providing richer contextual information for intelligent operation and maintenance.

[0072] Therefore, it can be seen that the clustering association construction module 4 intelligently discovers potential grouping relationships between Kubernetes resources based on feature similarity through unsupervised learning methods. The core technical effect lies in breaking through the limitations of explicit rules and realizing the automated discovery of tacit knowledge. It complements the rule engine and together constitutes a multi-level, intelligent association construction system covering both "explicit" and "potential" associations.

[0073] In some embodiments, the neural network association construction module 5 is specifically used to: input the vectorized features into a feature transformation network containing one or more fully connected layers for nonlinear feature transformation to obtain a higher-order feature representation; input the higher-order feature representation into a Softmax classifier for calculation and output the predicted probability of potential association between resource objects; and construct the third type of association between resource object pairs whose predicted probability exceeds a set threshold.

[0074] Specifically, a fully connected layer is one of the most fundamental components of a neural network. Each neuron in this layer is connected to all neurons in the previous layer. Its core function is to perform linear combinations and weighted summations of features. Stacking multiple fully connected layers can progressively combine the original features into more complex, higher-order feature representations.

[0075] Nonlinear feature transformation refers to the application of an activation function (such as ReLU or Sigmoid) after the linear computation of a fully connected layer. This function introduces nonlinear operations. Without nonlinear transformation, no matter how many layers are stacked, the entire network ultimately becomes equivalent to a single-layer linear model, unable to learn complex patterns. Nonlinear transformation is key to the ability of neural networks to fit extremely complex functions, enabling the network to understand complex interactions between features (e.g., "pattern C will only appear if feature A exists and feature B does not exist").

[0076] Higher-order feature representations refer to original feature vectors (such as labels and resource quotas) that are "low-order" and direct observations. When these vectors are passed through multiple fully connected layers with non-linear activation functions, they are combined and abstracted into new features.

[0077] The Softmax classifier is a commonly used output layer function in neural networks, particularly suitable for multi-class classification problems. It transforms the network's final output value into a probability distribution. Suppose the model determines that there are three possible association types between two resources (e.g., "call," "dependency," "coexistence"). The Softmax classifier calculates a probability value for each of these three types, and the sum of all probabilities is 1. The type with the highest probability is the model's prediction.

[0078] The predicted probability is a value between 0 and 1 output by the Softmax classifier, representing the model's confidence that "there is a specific relationship between two resources".

[0079] The threshold is a predefined confidence level (e.g., 0.85). An association is considered valid only when the predicted probability exceeds this threshold. This is a crucial filtering mechanism used to balance precision and recall. A high threshold ensures that the final output of the third-class association is of high confidence and high quality, significantly reducing false positives.

[0080] The technical solution of the neural network association building module 5 has at least the following technical effects:

[0081] Neural networks possess the ability to discover complex, deep, and non-linear relationships: rule engines rely on manually defined linear logic (if A then B). Clustering algorithms rely on intuitive geometric distance (similarity). Neural networks, through multiple layers of non-linear transformations, can learn intricate interaction patterns and dependencies between features that are difficult for humans to describe directly. This allows them to discover deep relationships that the first two methods cannot capture. For example, it might learn that when a Pod's owner is a specific series of CronJobs, requests a specific amount of memory, and has a specific annotation, it is highly likely to have a hidden configuration dependency with a ConfigMap in another namespace. This kind of relationship is highly non-linear and cannot be covered by exhaustive rule enumeration.

[0082] It achieves true intelligent prediction and inference: the module is essentially a predictive model. It trains itself by analyzing massive amounts of historical data (such as past deployment relationships, call chain logs, and fault propagation records), thereby gaining the ability to "predict" whether there are relationships between resources. This means it can not only see current static relationships, but also infer potential, and even future, relationships based on patterns. For example, when deploying a new service, the model can predict which existing services it might have close call relationships with in the future based on its characteristics, thus enabling proactive operation and maintenance, and advance resource scheduling and network strategy planning.

[0083] The output results are highly reliable and actionable: the Softmax probability + threshold filtering mechanism ensures that the third type of association in the final output is no longer "possible" or "suspected," but rather "highly probable" according to the model. This high-confidence output can be directly used to drive automated systems without much human intervention. For example, security systems can automatically implement stricter network policies between services with high probability of association; monitoring systems can construct more accurate monitoring topology maps based on these associations, greatly improving the actionability and value of the output results.

[0084] Forming cognitions that transcend human experience and discovering unknown patterns: Neural networks can process massive amounts of high-dimensional features and find hidden patterns within them, exceeding the cognitive limits of human experts. They may discover correlations that defy "common sense" but are real, such as the implicit correlation between the version number of a seemingly unrelated infrastructure component and a specific application failure. This provides a new, data-driven perspective for root cause analysis, performance tuning, and architecture governance, helping users discover unknown vulnerabilities in their systems.

[0085] Therefore, it is evident that the neural network association construction module 5 represents the highest level of intelligence in this device. It no longer relies on explicit rules or surface similarity, but instead, by simulating complex nonlinear relationships, it possesses the capabilities for in-depth analysis, intelligent prediction, and high-confidence inference. The third type of association it discovers is often the most insightful and valuable, revealing the deepest and most unexpected dependencies and connections within the system, thereby elevating the operation and management of Kubernetes clusters from an "experience-based" approach to a new level of "AI-based prediction."

[0086] In some embodiments, the data fusion module 6 is specifically used to: store the first, second, and third types of association relationships in a unified format of triples, wherein the triples include a source resource UID, an association type, and a target resource UID; generate a unique identifier based on the source resource UID, association type, and target resource UID in the triples, and merge and deduplicate association relationships with the same unique identifier; verify the validity of the deduplicated association relationship data, wherein the validity verification includes: verifying whether the resource objects pointed to by the source resource UID and the target resource UID exist in the current Kubernetes cluster; and output the resource object association relationship data that passes the validity verification.

[0087] Specifically, a uniformly formatted triple refers to a standardized data structure used to represent a relationship. A triple contains exactly three elements:

[0088] Source resource UID (from UID): A globally unique identifier for the resource that initiated the relationship. The UID is a unique string automatically assigned by the Kubernetes system when a resource is created. It is more reliable than the name and will not cause conflicts due to duplicate names.

[0089] Association type: Defines the semantics of the relationship, indicating the nature of the relationship between the "source" and the "target" (e.g., Owned-By, Serviced-By, Similar-To, Co-Located-With).

[0090] Target resource UID (to UID): A globally unique identifier for the resource to which the relationship points.

[0091] Example: (PodA-UID, 'Serviced-By', ServiceB-UID)

[0092] The unified format triple standardizes the various associations from different algorithms into a unified format, which is the basis for all subsequent processing (deduplication, verification, storage, and consumption).

[0093] A unique identifier is a string used to uniquely identify a relationship. Its generation logic is based on the content of the triple itself. Generation method: It can be generated by concatenating the three elements of the triple and then calculating the hash value (such as MD5, SHA256). For example: Hash(source resource UID + relationship type + target resource UID), this hash value serves as the "digital fingerprint" of the relationship. As long as the triple content is exactly the same, the generated hash value will definitely be the same, thus enabling fast and accurate comparison and deduplication.

[0094] Merging and deduplication refers to the process of eliminating duplicate relationships. The same relationship might be calculated by different modules simultaneously. For example, the relationship between a Service and a Pod could be discovered by a rule engine using selector rules (type 1), or it might be grouped into the same cluster by a clustering algorithm because their label vectors are very similar (type 2). The generated "unique identifier" is used to determine if two relationships are duplicates. If the identifiers are the same, it is considered a duplicate, and only one relationship is retained.

[0095] Validation (verifying the existence of resource objects): A crucial step in checking whether a relationship is still valid in the current Kubernetes cluster. Kubernetes clusters are highly dynamic, and resources can be deleted at any time. Therefore, previously calculated relationships may become invalid if the target or source resource is deleted. The module maintains an up-to-date resource cache from Informer. During validation, it uses the source resource UID and target resource UID from the triple to query this cache to see if the corresponding resource object still exists.

[0096] The technical solution of data fusion module 6 has at least the following technical effects:

[0097] Ensuring the uniqueness and simplicity of output data: By using hash-based unique identifiers to deduplicate relationships from three independent computing engines, the final output association graph is guaranteed to be free of completely duplicated redundant relationships. This avoids data redundancy, eliminating the need for downstream systems (such as visualization tools and analysis platforms) to process duplicate data, reducing storage and computational overhead, and ensuring the clarity and simplicity of the graph.

[0098] Ensuring the accuracy and real-time nature of output data: The validity verification mechanism directly addresses a core issue in dynamic environments—resource lifecycle. By querying the real-time resource cache to verify the validity of UIDs, it can accurately filter out outdated associations that have become invalid due to resource deletion. This is the core step in ensuring the reliability of the entire device's output results. It ensures that every association provided to the user is "alive" and traceable. This provides a reliable guarantee for critical operation and maintenance operations such as fault location and impact analysis based on this data.

[0099] Achieving unified governance and standardized output of results from multiple algorithms: A unified triplet format acts as a "common language," standardizing the three different levels of abstraction and origins of relationships—the "logical relationships" of rule engines, the "similarity relationships" of clustering algorithms, and the "predictive relationships" of neural networks—into a unified, semantic expression. This makes subsequent storage, querying, and consumption exceptionally simple. No matter how complex the algorithm, its final output becomes regular and consistent. This significantly reduces the design complexity at the end of the entire system's data pipeline, laying a solid foundation for building a unified relationship query API or data products.

[0100] Enhancing the robustness and usability of the entire system: As the "final quality checkpoint" in the entire data processing flow, this module can correct problems that may arise from the different algorithm characteristics of preceding modules (such as duplicate calculations and failure to detect resource deletion in a timely manner). It compensates for the limitations of a single algorithm and enhances the robustness of the entire system in a real production environment. This ensures that the final delivery is not just some raw results of algorithms, but a cleaned, deduplicated, and verified high-value data product that can be directly used to drive business processes.

[0101] Therefore, it is clear that Data Fusion Module 6 is far more than a simple "data collector"; it is a crucial data governance and quality assurance center. Through three core operations—standardization, deduplication, and validity verification—it processes the raw, potentially redundant, and noisy data generated by the three intelligent engines into a clean, accurate, real-time, and unified high-quality dataset of relational relationships. This is a critical step in transforming cutting-edge algorithms into stable and reliable enterprise-level applications with practical production value, and it is the ultimate guarantee for the credibility and usability of the entire device's output.

[0102] In some embodiments, the apparatus further includes: an association model definition module for defining an association data model, the model including an association type, a unique identifier of a source resource object, and a unique identifier of a target resource object, wherein the association type includes at least one of infrastructure topology relationships, orchestration and scheduling relationships, observability relationships, and business relationships.

[0103] Specifically, the correlation model definition module is a design-time component that runs during the initialization or configuration phase of the device. Its core task is not to process real-time data, but to establish a unified and standardized data model for the concept of "correlation" that the entire device will handle. It defines the components that constitute "a correlation," as well as the data type and meaning of each component.

[0104] Relationship Data Model: A structured data specification defined by the Relationship Model Definition Module to describe and represent a relationship. It specifies the format and fields that all relationship data must follow, and serves as the data standard for both internal device operation and external output.

[0105] Unique identifiers for source / target resource objects: Specifically, this refers to the globally unique identifier (UID) assigned to each resource object by Kubernetes. Unlike resource names, UIDs are absolutely unique throughout the cluster's lifecycle; even if a resource with the same name is deleted and then recreated, its UID will be different. Using UIDs instead of names to identify resources allows for absolutely precise and unambiguous location of both ends of the relationship, effectively avoiding relationship confusion caused by duplicate resource names or reconstructions, and ensuring data accuracy and permanence.

[0106] The association type, a key enumeration value defined in the association relationship model definition module, is used to assign explicit semantics to the association relationship. It represents "the nature of the relationship between the source resource and the target resource." Several predefined types are included in this scheme:

[0107] Infrastructure topology: Describes the connectivity of resources at the infrastructure level. For example, the runtime relationship between a Pod and the Node that runs it; the pointer relationship between a Service and Endpoints.

[0108] Orchestration and scheduling relationships: Describes the orchestration hierarchy managed by the Kubernetes controller. For example, the management relationship between Deployment and ReplicaSet; the ownership relationship between ReplicaSet and Pod.

[0109] Observability relationships: Describe the relationships related to observable data such as monitoring, logging, and tracing. For example, the log writing relationship between a Pod and the Logstore where its output logs are stored; the exposure metric relationship between a Service and its monitoring metrics.

[0110] Business relationships: Describes the relationships created by business logic or architecture. For example, the calling relationship between a front-end service and a back-end service; the usage configuration relationship between an application and the configuration ConfigMap it uses.

[0111] The technical solution for the relationship model definition module has at least the following technical effects:

[0112] This module achieves data standardization and unified governance: it defines a mandatory data contract at the device's top level. Regardless of whether the relationships are discovered by a rule engine, clustering algorithm, or neural network, they must ultimately be "shaped" into a unified (source UID, type, target UID) triple format. This achieves data standardization. It enables relationship data from diverse sources and using different algorithms to be processed, stored, and consumed consistently, completely eliminating the chaos caused by data heterogeneity and providing a stable and reliable foundation for the entire device's data pipeline.

[0113] Enriching data with rich semantics enhances its understandability and usability: By introducing association types, this module injects clear business and operational semantics into cold machine data (UIDs). A triple containing type calls is far more valuable than a record containing only two Pod UIDs. This significantly improves data interpretability. Downstream systems (such as topology visualization and impact analysis engines) can easily differentiate and display data based on different association types. For example, in visualization, different colored lines can represent different types of relationships such as "orchestration" and "call," making the graph immediately clear. This upgrades the output data from "machine-readable" to "understandable by both humans and machines."

[0114] It offers high scalability and flexibility: association types are designed as scalable enumerations ("including...at least one"). This means that new association types (such as security dependencies, cost attribution relationships) can be easily added in the future to meet new business scenarios without changing the core data model structure and processing flow. This makes the entire device highly adaptable, capable of evolving with technological developments and changing business needs, protecting technological investments. New algorithms only need to output data according to the established model to seamlessly integrate into the existing system.

[0115] Laying the foundation for building a data ecosystem: A standardized, semantically rich relational data model itself becomes a valuable data asset. This enables the device's output to become a standardized data service, easily consumed and used by various tools and platforms both inside and outside the cluster (such as operation and maintenance platforms, security middleware, and cost accounting systems), thereby building a rich data ecosystem around the device and unlocking more cross-domain application possibilities.

[0116] While the relational model definition module doesn't directly process real-time data, it is the cornerstone and soul of the entire device. By defining a precise, semantic, and scalable data model, it achieves standardized governance of relational relationships, transforming chaotic data into well-structured, meaningful, high-value information assets. It not only ensures the orderliness of the device's internal processing flow but, more importantly, significantly improves the usability and operability of the output data, providing powerful empowerment for upper-layer applications. This is the key to maximizing the value of the entire technical solution.

[0117] In summary, the core of this application's device lies in its adoption of a multi-level, multi-technology framework for discovering correlations. For example... Figure 1 and Figure 2 As shown, after the device starts up, it first establishes a connection with the Kubernetes API server through the metadata acquisition module 1. The metadata acquisition module 1 utilizes the Informer client library provided by Kubernetes, based on the List-Watch mechanism, to first acquire all data for the specified resource type and cache it locally. Then, it listens for incremental change events of the resource (such as Added, Updated, and Deleted) through a long connection, and serializes the acquired resource object metadata before pushing it to the downstream processing module. This process is event-driven, ensuring the real-time nature of the data.

[0118] Rule association module 2 is responsible for handling intuitive, pre-defined relationships. This module loads predefined rule sets (configurable via YAML files). A rule can include the source resource type (e.g., Pod), target resource type (e.g., Service), relationship type (e.g., Serviced-By), matching conditions (e.g., the existence of a specific Pod tag), and association logic. Rule association module 2 listens to the metadata stream. When a new Pod is created or updated, it iterates through all rules. If it finds a rule whose source resource type is Pod, and the Pod's metadata (e.g., Labels) meets the rule's matching conditions, it triggers the execution of the association logic. The core of the association logic is extracting key information from specific fields of the current resource (i.e., "explicitly declared association fields"). For example:

[0119] Tag selector field: Extracts key-value pairs from Service.spec.selector, used to query all Pods that match this selector.

[0120] Directly reference the field by name: Extract the PVC name from Pod.spec.volumes[].persistentVolumeClaim.claimName, which is used to query the PVC in the namespace where the Pod is located.

[0121] Owner reference field: Extracts the name and Kind of the ReplicaSet to which it belongs from Pod.metadata.ownerReferences, which is used to query the ReplicaSet.

[0122] After the target resource is found, the rule association construction module 2 generates an association relationship data from the source resource UID to the target resource UID according to the association type defined in the rule.

[0123] Feature processing module 3 is responsible for preparing data for clustering analysis and machine learning methods. It extracts a wide range of multi-dimensional features from metadata, such as: basic resource information (namespace, name, creationTimestamp), labels, annotations, resource quotas (resource requests / limits), permission data, permission configuration data, volume configuration data, status information (status.phase), network configuration (podIP, hostIP), storage volume information, and business attribute information such as the cluster and project to which it belongs. These heterogeneous features need to be preprocessed and vectorized, for example, converting the label set into a multi-dimensional vector, standardizing numerical features, and performing one-hot encoding on categorical features, ultimately representing each resource object as a high-dimensional feature vector.

[0124] The Clustering Association Construction Module 4 discovers associations based on unsupervised learning. It receives feature vectors, typically operating on features of the same category (such as the label vectors of all resources). It sets the feature vectors of all resources together and then uses a predefined clustering algorithm (such as K-Means or DBSCAN) to calculate the distances between vectors (e.g., Euclidean distance or cosine distance), dividing resource objects into different clusters based on their distance. The basic principle of clustering is "like attracts like"; resources within the same cluster are more similar in feature space and are therefore considered to have potential associations. The Clustering Association Construction Module 4 establishes a second type of association between all resource objects within the same cluster.

[0125] Neural Network Association Building Module 5 discovers more complex latent associations based on supervised learning. It inputs vectorized features into a neural network model. This network typically includes a feature transformation subnetwork, composed of multiple fully connected layers and non-linear activation functions (such as ReLU), used to perform complex non-linear feature transformations and combinations to obtain higher-order, more abstract feature representations. These higher-order features are then fed into a classifier (such as a Softmax classifier) ​​for computation. This classifier can be trained to determine whether a certain association exists between any two resource objects and outputs a predicted probability. Neural Network Association Building Module 5 sets a probability threshold (e.g., 0.9) and constructs a third type of association for resource object pairs whose predicted probabilities exceed this threshold.

[0126] Data fusion module 6 is the output hub of the device. It receives relationship data from the three channels mentioned above. First, it standardizes all relationships into a triple format of (source resource UID, relationship type, target resource UID). Then, it generates a unique identifier based on the triple content and merges duplicate relationships. Next, it performs validity verification on the deduplicated data, most importantly verifying whether the resource objects pointed to by the source resource UID and target resource UID in the triple still exist in the current Kubernetes cluster, thus filtering out outdated relationships that have become invalid due to resource deletion. Finally, it outputs verified, accurate, and real-time relationship data, which can be used by visualization topology systems, impact analysis systems, or operation and maintenance platforms.

[0127] To ensure the entire device can continuously respond to cluster changes, it may also include a polling control module. This module is responsible for coordinating and driving the continuous operation of the entire process. It listens for event notifications received by the metadata acquisition module, and once a resource change event (including the addition, deletion, or modification of resource objects) occurs, it automatically triggers the subsequent rule calculation, feature extraction, clustering, and neural network analysis processes to ensure that the constructed relationship topology graph can be kept synchronized with the actual state of the Kubernetes cluster in real time.

[0128] In addition, the device includes an association model definition module, which operates during the system initialization phase and defines the standard format for the entire device's output data. It stipulates that each association data entry must contain three core elements: association type (e.g., "Serviced-By", "Owned-By", "Co-Located-With"), a globally unique identifier (UID) of the source resource object, and the UID of the target resource object. This ensures that association data generated by different modules can be processed and understood uniformly.

[0129] Based on the same inventive concept, this application also provides an automatic method for constructing associations of Kubernetes resource objects. Figure 3 This application also provides a flowchart illustrating a method for automatically constructing associations between Kubernetes resource objects, as shown in the embodiments below. Figure 3 As shown, the method includes:

[0130] S1. Obtain full and incremental metadata of resource objects from the Kubernetes cluster using Informer based on the List-Watch mechanism;

[0131] S2. Based on the pre-configured rules and the metadata of the resource objects, calculate and construct the first type of association between the resource objects;

[0132] S3. Extract multi-dimensional features of resource objects from the metadata and vectorize the features;

[0133] S4. Based on the vector distance of the vectorized features, a second type of association between resource objects is constructed using a clustering algorithm;

[0134] S5. After transforming the vectorized features, input them into the neural network model for calculation and classification, and construct a third type of association between resource objects based on the classification results;

[0135] S6. Merge, deduplicate, and validate the first, second, and third types of associations to obtain resource object association data.

[0136] The automatic construction method for Kubernetes resource object associations provided in this application obtains full and incremental metadata of resource objects from the Kubernetes cluster using an Informer based on a List-Watch mechanism. Based on pre-configured rules and the metadata of the resource objects, it calculates and constructs a first type of association between resource objects. It extracts multi-dimensional features of the resource objects from the metadata and vectorizes these features. Based on the vector distance of the vectorized features, it constructs a second type of association between resource objects using a clustering algorithm. The vectorized features are then transformed and input into a neural network model for calculation and classification. Based on the classification results, a third type of association between resource objects is constructed. The first, second, and third types of associations are merged, deduplicated, and validated to output resource object association data. Thus, based on the multi-dimensional features of Kubernetes resource objects, a method based on a rule engine, feature vectorization clustering, and neural network model classification is proposed to mine multi-dimensional associations of Kubernetes resource objects, constructing a Kubernetes resource object topology that includes rule associations and potential business associations, thereby improving the data operation and maintenance capabilities of the Kubernetes cluster.

[0137] like Figure 4 As shown, in some embodiments, calculating and constructing a first type of association between resource objects based on the metadata of the resource objects according to pre-configured rules includes:

[0138] S21. Load and parse the predefined rule set, which defines the source resource type, target resource type, association relationship type, matching conditions and association logic for each rule;

[0139] S22, Listen for metadata change events of resource objects;

[0140] S23. When the type of a resource object matches the source resource type of a rule in the rule set, and the metadata of the resource object satisfies the matching conditions defined by the rule, the association logic of the rule is executed. The association logic is as follows: extract the target resource identification information from the explicit declaration association field of the current resource object, and query the target resource object in the Kubernetes cluster based on the identification information.

[0141] S24. Based on the current resource object and the target resource object obtained by query, construct the association relationship data of the association relationship type defined by the rule.

[0142] In some embodiments, the explicitly declared associated fields include at least one of the following: a tag selector field, a name direct reference field, and an owner reference field.

[0143] like Figure 5 As shown, in some embodiments, the construction of a second type of association between resource objects based on the vector distance of vectorized features using a clustering algorithm includes:

[0144] S41. A feature vector set is formed by extracting feature vectors of the same category from multiple resource objects;

[0145] S42. Calculate the distance between each vector in the feature vector set using the set clustering algorithm, and divide the resource objects into one or more clusters based on the vector distance;

[0146] S43. Establish the second type of association between resource objects that are assigned to the same cluster.

[0147] like Figure 6 As shown, in some embodiments, the step of transforming the vectorized features and inputting them into a neural network model for calculation and classification, and constructing a third type of association between resource objects based on the classification results, includes:

[0148] S51. Input the vectorized features into a feature transformation network containing one or more fully connected layers to perform nonlinear feature transformation and obtain a higher-order feature representation.

[0149] S52. Input the higher-order feature representation into the Softmax classifier for calculation, and output the predicted probability that there is a potential relationship between resource objects;

[0150] S53. Construct the third type of association between resource object pairs whose predicted probability exceeds a set threshold.

[0151] like Figure 7 As shown, in some embodiments, the process of merging, deduplicating, and validating the first, second, and third types of associations to obtain resource object association data includes:

[0152] S61. Store the first, second, and third types of associations in a unified format of triples, wherein the triples include the source resource UID, the association type, and the target resource UID;

[0153] S62. Generate a unique identifier based on the source resource UID, association type, and target resource UID in the triple, and merge and deduplicate associations with the same unique identifier.

[0154] S63. Verify the validity of the deduplicated association data. The validity verification includes: verifying whether the resource objects pointed to by the source resource UID and the target resource UID exist in the current Kubernetes cluster.

[0155] S64. Output the resource object association data that has passed the validity check.

[0156] In some embodiments, the method further includes: defining a relational data model, the model including a relational type, a unique identifier of a source resource object, and a unique identifier of a target resource object, wherein the relational type includes at least one of infrastructure topology relation, orchestration relation, observability relation, and business relation.

[0157] The embodiments of the methods provided in this application can be used to execute the processing flow of the above-described device embodiments, and will not be repeated here. Please refer to the detailed description of the above-described device embodiments.

[0158] Figure 8 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application, as shown below. Figure 8 As shown, the electronic device may include a processor 301, a communications interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communications interface 302, and the memory 303 communicate with each other via the communication bus 304. The processor 301 may call logical instructions in the memory 303 to execute the methods described in any of the above embodiments.

[0159] Furthermore, the logical instructions in the aforementioned memory 303 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) 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.

[0160] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments.

[0161] This embodiment provides a computer-readable storage medium storing a computer program that causes the computer to perform the methods provided in the above-described method embodiments.

[0162] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0163] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0164] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0165] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0166] In the description of this specification, the references to terms such as "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0167] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An apparatus for automatically constructing association relationships of Kubernetes resource objects, characterized in that, The method comprises the following steps: A metadata acquisition module is used to acquire full and incremental metadata of resource objects from a Kubernetes cluster based on a List-Watch mechanism through an Informer; A rule association construction module is used to calculate and construct a first type of association relationship between resource objects based on the metadata of the resource objects according to preconfigured rules; A feature processing module is used to extract multi-dimensional features of resource objects from the metadata and perform vectorization processing on the features; A clustering association construction module is used to construct a second type of association relationship between resource objects through a clustering algorithm based on the vector distance of the vectorized features; A neural network association construction module is used to input the transformed vectorized features into a neural network model for calculation and classification, and construct a third type of association relationship between resource objects based on the classification results; A data fusion module is used to merge and remove duplicates and perform validity verification on the first, second and third types of association relationships, and output resource object association relationship data.

2. The apparatus of claim 1, wherein, The rule association construction module is specifically used to: Load and parse a predefined rule set, which defines the source resource type, target resource type, association relationship type, matching condition and association logic of each rule; Listen to metadata change events of resource objects; When the type of a resource object matches the source resource type of a rule in the rule set, and the metadata of the resource object meets the matching condition defined by the rule, execute the association logic of the rule, wherein the association logic is to extract target resource identification information from the explicit declaration association field of the current resource object, and query the target resource object in the Kubernetes cluster according to the identification information; Based on the current resource object and the queried target resource object, construct the association relationship data of the association relationship type defined by the rule.

3. The apparatus of claim 2, wherein, The explicit declaration association field includes at least one of the following: a label selector field, a name direct reference field, and an owner reference field.

4. The apparatus of claim 1, wherein, The clustering association construction module is specifically used to: Group feature vectors of the same category extracted from multiple resource objects into a feature vector set; Calculate the distance between vectors in the feature vector set using a set clustering algorithm, and divide the resource objects into one or more clusters according to the vector distance; Establish the second type of association relationship between resource objects in the same cluster.

5. The apparatus of claim 1, wherein, The neural network association construction module is specifically used to: Input the vectorized features into a feature transformation network containing one or more fully connected layers to perform nonlinear feature transformation and obtain high-order feature representations; Input the high-order feature representations into a Softmax classifier for calculation, and output the prediction probability of the potential association relationship between resource objects; Construct the third type of association relationship between resource object pairs with a prediction probability exceeding a set threshold.

6. The apparatus of claim 1, wherein, The data fusion module is specifically used to: Store the first, second and third types of association relationships in the form of triples in a unified format, wherein the triples include source resource UID, association type and target resource UID; generate a unique identifier based on the source resource UID, the association type, and the target resource UID in the triple, and merge and deduplicate association relationships with the same unique identifier; verify the effectiveness of the deduplicated association relationship data, and the effectiveness verification includes: verifying whether the resource objects pointed to by the source resource UID and the target resource UID exist in the current Kubernetes cluster; output resource object association relationship data that passes the effectiveness verification.

7. The apparatus of claim 1, wherein, The apparatus further includes: An association relationship model definition module for defining an association relationship data model, which includes an association type, a unique identifier of a source resource object, and a unique identifier of a target resource object, wherein the association type includes at least one of an infrastructure topology relationship, an orchestration scheduling relationship, an observability association relationship, and a business association relationship.

8. An automatic construction method of a Kubernetes resource object association relationship, characterized in that, It includes: obtaining full and incremental metadata of resource objects from a Kubernetes cluster based on a List-Watch mechanism through an Informer; According to the pre-configured rules, based on the metadata of the resource object, calculate and construct the first type of association relationship between the resource objects; extract multi-dimensional features of resource objects from the metadata, and perform vectorization processing on the features; Based on the vector distance of the vectorized features, the second type of association relationship between the resource objects is constructed through a clustering algorithm; transform the vectorized features and input them into a neural network model for calculation and classification, and construct the third type of association relationship between the resource objects based on the classification results; merge and deduplicate the first type, the second type, and the third type of association relationship and perform effectiveness verification to obtain resource object association relationship data.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the method of claim 8.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the steps of the method of claim 8.

Images