A kubernetes node intelligent maintenance method and device

Abstract

The application provides a Kubernetes node intelligent maintenance method and device. It relates to the field of Kubernetes node intelligent maintenance priority evaluation. The method obtains multi-dimensional state data of a target node; based on performance index time series data, the comprehensive load factor of the node is calculated; based on application metadata, the application key level factor is calculated. The application key level factor is assigned a basic score through QoS level, and is normalized after weighting according to user-defined business priority labels; based on abnormal event data and historical maintenance operation records, the event time series correlation factor and the historical reliability factor are calculated respectively, and the four factors are linearly weighted and fused according to the preset weight to generate the node maintenance priority score. The application can effectively fuse multi-dimensional heterogeneous data, realize dynamic and accurate evaluation of the Kubernetes node maintenance priority, and improve the system stability and operation efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of Kubernetes node intelligent maintenance priority assessment, and in particular to a Kubernetes node intelligent maintenance method and apparatus. Background Technology

[0002] In the field of modern cloud computing and distributed system operations (AIOps), Kubernetes, as a crucial component of container orchestration systems, is widely used in large-scale microservice architectures and dynamic resource scheduling scenarios. With the development of cloud-native technologies, the scale and complexity of Kubernetes clusters continue to increase, requiring operations and maintenance systems to prioritize node maintenance events in real-time and accurately from massive amounts of heterogeneous monitoring data. Among related technologies, a node status assessment technical system has been constructed through the collaborative operation of performance indicator collection, business metadata parsing, event correlation analysis, and historical operations and maintenance data. Specifically, this system covers the entire process from data collection to decision output, including key aspects such as resource load analysis, business value identification, event time-series modeling, and historical experience feedback. Among these, the resource load factor quantifies the physical stress on nodes, the business key factor reflects the business value of the applications hosted by the nodes, the event correlation factor identifies the synergy of concurrent abnormal events, and the historical reliability factor introduces a closed-loop feedback mechanism of operations and maintenance experience, thereby achieving multi-dimensional data fusion assessment.

[0003] However, existing node maintenance priority assessment methods directly rely on static rules or fixed thresholds for judgment, failing to integrate multi-dimensional heterogeneous data. This can lead to high false alarm rates, high false negative rates, or an inability to identify complex fault chains, thus impacting operational efficiency and system stability. Specifically, existing technologies typically set alarm thresholds based solely on single performance indicators such as CPU and memory, ignoring trends in resource consumption and the actual impact of applications running on nodes on business operations. Furthermore, traditional methods lack modeling of event correlations and historical operational results during the assessment process, making it impossible to identify potential risks from concurrent anomalies or optimize decision-making logic based on historical experience. The static, singular, and context-aware nature of this assessment model makes it difficult for operational systems to make accurate and efficient maintenance responses to dynamic business loads and complex fault scenarios, potentially leading to critical business interruptions or resource waste. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] This invention proposes a method for intelligent maintenance of Kubernetes nodes.

[0006] Another objective of this invention is to provide a smart maintenance device for Kubernetes nodes.

[0007] To achieve the above objectives, a first aspect of the present invention proposes a method for intelligent maintenance of Kubernetes nodes based on distributed locks and bimodal detection, comprising:

[0008] S1, obtain multi-dimensional status data of the target node, including time-series data of the node's performance indicators, application metadata deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status;

[0009] S2, based on the time series data of the performance indicators, calculate the comprehensive load factor L of the node. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and by normalization after weighted fusion of each key performance indicator with preset weights.

[0010] S3. Based on the application metadata, calculate the application key level factor P. The application key level factor P is assigned a base score through the QoS level of Kubernetes, and is obtained by weighting and normalizing according to the user-defined business priority label.

[0011] S4. Based on abnormal event data and historical maintenance operation records, calculate the event time-series correlation factor M and the historical reliability factor H respectively, and then linearly weight and fuse the four factors L, P, M and H according to preset weights to generate the node maintenance priority score.

[0012] In one embodiment of the present invention, obtaining the multidimensional state data of the target node further includes:

[0013] S11: Obtain time-series data of the node's CPU utilization, memory utilization, disk I / O wait time, and network bandwidth utilization in the last 15 minutes from the monitoring system.

[0014] S12 parses the QoS level and service priority label of each Pod deployed on the node from the Kubernetes metadata. The service priority label includes three types: critical, important, and normal.

[0015] In one embodiment of the present invention, the comprehensive load factor L of the computing node based on the performance index time-series data further includes:

[0016] S21. Calculate the time-weighted moving average (WMA) and growth rate (RoC) for each key performance indicator, and perform linear weighting according to the preset weights to obtain the original load score of the indicator.

[0017] S22, normalize the raw load scores of all key performance indicators using the Sigmoid function to ensure that their values ​​are in the range of [0,1], and then perform final weighted fusion according to the preset weights of each indicator.

[0018] In one embodiment of the present invention, calculating the application key level factor P based on the application metadata further includes:

[0019] S31 assigns a base score based on the QoS level of each Pod: 10 points for Guaranteed, 5 points for Burstable, and 1 point for BestEffort.

[0020] S32, multiply the base score by the business multiplier corresponding to the business priority label of the Pod, where critical corresponds to 3.0, important corresponds to 2.0, and normal corresponds to 1.0, to obtain the original key score of the Pod, and perform logarithmic normalization on the original key scores of all Pods to ensure that their value range is between [0,1].

[0021] In one embodiment of the present invention, the step of calculating the event time-series correlation factor M and the historical reliability factor H based on the abnormal event data and historical maintenance operation records further includes:

[0022] S41, using the timestamp of the current triggering event as the center, find all related events within a preset time window, and calculate the score of each related event using an exponential decay function based on the time difference between it and the triggering event;

[0023] S42. Sort the most recent 5 historical maintenance operation records from newest to oldest by time, assign each record a decreasing integer weight, calculate the weighted total score, and then divide the total score by the sum of the weights, 15, to obtain the normalized historical reliability factor H.

[0024] In one embodiment of the present invention, it further includes:

[0025] S5. The node maintenance priority score is compared with a preset priority threshold. If the score is greater than 0.7, the node is marked as a high-priority task and maintenance is performed immediately. If the score is greater than or equal to 0.4 and less than or equal to 0.7, the node is marked as a medium-priority task and submitted for manual review. If the score is less than or equal to 0.4, the node is marked as a low-priority task and recorded for subsequent analysis.

[0026] To achieve the above objectives, another aspect of the present invention proposes a Kubernetes node intelligent maintenance device based on distributed locks and bimodal detection, comprising:

[0027] The multi-dimensional status data acquisition module is used to acquire multi-dimensional status data of the target node. The data includes time-series data of the node's performance indicators, application metadata deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status.

[0028] The comprehensive load factor calculation module is used to calculate the comprehensive load factor L of the node based on the time series data of the performance indicators. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and by normalization after weighted fusion of each key performance indicator with preset weights.

[0029] The application key level factor evaluation module is used to calculate the application key level factor P based on the application metadata. The application key level factor P is assigned a base score through the QoS level of Kubernetes and is obtained by weighting and normalizing according to the user-defined business priority label.

[0030] The multi-factor fusion evaluation module is used to calculate the event time-series correlation factor M and the historical reliability factor H based on the abnormal event data and historical maintenance operation records, and to linearly weight and fuse the four factors L, P, M and H according to preset weights to generate a node maintenance priority score.

[0031] The Kubernetes node intelligent maintenance method and apparatus of this invention can integrate multi-dimensional heterogeneous data such as physical load, business value, event correlation and historical experience to achieve dynamic and accurate evaluation of Kubernetes node maintenance priorities, thereby improving system operation and maintenance efficiency and critical business assurance capabilities.

[0032] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0033] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0034] Figure 1 This is a flowchart of a Kubernetes node intelligent maintenance method according to an embodiment of the present invention;

[0035] Figure 2 This is a flowchart of a method for an end-to-end closed-loop management system according to an embodiment of the present invention;

[0036] Figure 3 This is a structural diagram of a Kubernetes node intelligent maintenance device according to an embodiment of the present invention. Detailed Implementation

[0037] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0039] The following description, with reference to the accompanying drawings, illustrates a method and apparatus for intelligent maintenance of Kubernetes nodes according to embodiments of the present invention.

[0040] Figure 1 This is a flowchart of a Kubernetes node intelligent maintenance method according to an embodiment of the present invention, such as... Figure 1 As shown, it includes:

[0041] S1. Obtain multi-dimensional status data of the target node. The data includes time-series data of the node's performance indicators, metadata of applications deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status.

[0042] Specifically, this step aims to acquire multidimensional state data of the target node, including time-series data of the node's performance metrics, application metadata deployed on the node, abnormal event data within a preset time window, and historical maintenance operation records similar to the current state. This step is the core data input for the dynamic priority evaluation algorithm in this invention, providing basic data support for subsequent multidimensional factor calculations (L, P, M, H).

[0043] At the technical implementation level, the system first collects time-series performance metrics data of nodes through integrated monitoring components (such as Prometheus and KubernetesMetrics Server), covering key performance indicators (KPIs) such as CPU utilization, memory utilization, disk I / O latency, and network bandwidth utilization. The sampling frequency is typically set to once every 30 seconds, with a time window of the most recent 15 minutes. By calculating the time-weighted moving average (WMA) and growth rate (RoC) of these time-series data, the system can identify the persistence and deterioration trend of resource consumption. Secondly, the system obtains Pod information deployed on the node through the Kubernetes API, including its QoS level (Guaranteed, Burstable, BestEffort) and user-defined business priority annotations, such as `biz: "business-priority"`, with values ​​of `critical`, `important`, and `normal`, corresponding to business multipliers of 3.0, 2.0, and 1.0, respectively, used to calculate the application criticality factor P.

[0044] Furthermore, the system extracts abnormal event data that occurred within a preset time window (e.g., 3 minutes before and after) from the event buffer, including OOM, node unreachability, Pod restarts, etc., and calculates the event time-series correlation factor M by combining the time difference and event weight with an exponential decay function. Simultaneously, the system accesses the operations and maintenance knowledge base, matches historical maintenance operation records based on "problem signatures," extracts the results of the most recent N operations (e.g., N=5), assigns decreasing weights (5, 4, 3, 2, 1) in chronological order, and generates a historical reliability factor H by combining this with normalization processing.

[0045] In practical applications, this step is widely used in automated operation and maintenance systems for Kubernetes clusters, especially in large-scale, high-concurrency cloud-native environments, to identify node failure risks in real time and prioritize them. Through the collection and processing of multi-dimensional data, the system can achieve a comprehensive understanding of node status, providing a data foundation for subsequent intelligent decision-making. The technical value of this step lies in its effective integration of four dimensions—physical performance, business value, event correlation, and historical experience—through a structured and standardized data collection mechanism, significantly improving the accuracy and intelligence of fault response.

[0046] Furthermore, S1 includes:

[0047] S11: Obtain time-series data from the monitoring system on the node's CPU utilization, memory utilization, disk I / O wait time, and network bandwidth utilization over the past 15 minutes.

[0048] In some implementations, monitoring data collection is accomplished by integrating monitoring components such as Prometheus, Kubernetes MetricsServer, or eBPF, supporting high-frequency sampling of real-time performance metrics for each node in the cluster. The sampling frequency is typically set to once every 30 seconds to ensure at least 30 data points are acquired within a 15-minute window, thus meeting the minimum sample size requirement for time series analysis. The collected data format conforms to the OpenMetrics standard for easy subsequent parsing and processing.

[0049] Furthermore, the collected raw data needs to be preprocessed, including data cleaning, outlier removal, and missing value imputation. For example, if a node has more than 3 missing values ​​within 15 minutes, linear interpolation or moving average methods are used to imput them to ensure the continuity of the time series. Subsequently, the system will calculate the time-weighted moving average (WMA) and growth rate (RoC) for each KPI. The WMA uses an exponentially weighted average algorithm, with the weighting coefficient α typically set to 0.2 to enhance the influence of recent data; the RoC is calculated by the difference between adjacent time points to reflect the rate of change in resource usage trends.

[0050] Optionally, to improve computational efficiency, the system can employ a streaming processing framework (such as Apache Flink or Kafka Streams) to aggregate and analyze monitoring data in real time, ensuring that preliminary processing of all KPIs can be completed within 1 second after the 15-minute window ends. The output of this step is a structured time-series feature vector, which serves as the input for calculating the subsequent load factor L, thereby providing a dynamic and trend-based basis for evaluating the physical resource status of nodes for maintenance priority assessment.

[0051] S12 parses the QoS level and service priority label of each Pod deployed on the node from the Kubernetes metadata. The service priority label includes three types: critical, important, and normal.

[0052] Specifically, this step involves extracting the QoS level and service priority label for each Pod deployed on the Kubernetes node from the node's metadata. The service priority label includes three types: critical, important, and normal. This step is one of the core input components of the "business value-driven" priority evaluation model in this invention, and its technical implementation is based on the Kubernetes API's metadata access mechanism and the parsing logic of custom annotations.

[0053] In some implementations, this step retrieves resource usage and metadata information for all Pods running on the node via Kubernetes' Kubelet interface or API Server (such as ` / api / v1 / nodes / {node-name} / proxy / stats / summary`). Each Pod's QoS level is automatically categorized by Kubernetes based on its resource requests and limits, into three classes: Guaranteed, Burstable, and BestEffort. Guaranteed Pods have explicit resource requests and limits that are equal; Burstable Pods have resource requests but have not reached their limits; and BestEffort Pods have no resource requests or limits set.

[0054] Furthermore, the business-priority annotation is metadata that users add customly through the Kubernetes Annotations field when deploying a Pod, for example, `annotations: {"business-priority": "critical"}`. This annotation expresses the urgency of the business being handled by the Pod, with values ​​of critical, important, or normal, corresponding to business multipliers of 3.0, 2.0, and 1.0, respectively. In practice, this annotation is typically injected during deployment by operations personnel or CI / CD processes to ensure the system can recognize its business value.

[0055] Optionally, the system parses the Pod description file in YAML or JSON format, extracts the `business-priority` value from the `annotations` field, and combines it with the Pod's QoS level to assign each Pod a base score (Guaranteed=10, Burstable=5, BestEffort=1) multiplied by a business multiplier. This result serves as input for subsequent calculations of the business criticality factor (P). This process must adhere to Kubernetes API specifications (such as the v1.Pod interface) and ensure compatibility with different versions of Kubernetes clusters.

[0056] The technical value of this step lies in its ability to achieve "business awareness" of node maintenance tasks by incorporating business priorities and QoS levels into the priority evaluation model. In real-world operation and maintenance scenarios, such as financial transaction systems and real-time data processing platforms, where business continuity requirements are high, this step can effectively identify Pods carrying critical business functions. This ensures their operational stability in the event of resource anomalies or failures, thereby improving the overall operational efficiency and business continuity assurance level of the system.

[0057] S2, based on the time series data of performance indicators, calculate the comprehensive load factor L of the node. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and normalization after weighted fusion of each key performance indicator with preset weights.

[0058] In some implementations, this step first collects time-series data of key performance indicators (KPIs) for the nodes over the past 15 minutes from a monitoring system (such as Prometheus). This includes CPU utilization, memory utilization, disk I / O latency, and network bandwidth utilization. These KPIs are typically stored in time-series format, with a sampling frequency set to once every 10 seconds to ensure sufficient time-series resolution. Subsequently, a time-weighted moving average (WMA) and a rate of increase (RoC) are calculated for each KPI. The WMA uses a linear weighting strategy. The RoC quantifies the rate of change in resource usage by calculating the ratio of the difference between the current value and the previous value to the time interval.

[0059] This step is widely used in practical applications for node health assessment and intelligent maintenance decisions in Kubernetes clusters, especially in scenarios involving resource contention, sudden load spikes, or potential fault warnings. It effectively identifies nodes with abnormal resource usage and deteriorating trends, thereby improving the timeliness and accuracy of system response. By introducing a time-series analysis and normalization fusion mechanism, this invention overcomes the limitations of traditional static threshold judgments, achieving dynamic perception and quantitative assessment of node load status. This provides crucial input for subsequent priority decisions, demonstrating significant engineering practical value and innovation.

[0060] Furthermore, S2 includes:

[0061] S21. Calculate the time-weighted moving average (WMA) and growth rate (RoC) for each key performance indicator, and perform linear weighting according to the preset weights to obtain the original load score of the indicator.

[0062] Specifically, at the technical implementation level, WMA calculation adopts a sliding window mechanism, which usually takes KPI data within the most recent 15 minutes. The window length can be configured to 15 minutes, 10 minutes or shorter, depending on the system's real-time requirements.

[0063] At the parameter level, WMA and RoC calculations must meet certain accuracy requirements. For example, WMA has a calculation window length of 15 minutes, a sampling frequency of once per minute, and a total of 15 data points. Weight allocation can use preset static weights or be dynamically adjusted according to the system load pattern. RoC calculation needs to consider the magnitude of change per unit time, usually measured by percentage change rate; for example, a 5% increase in CPU utilization per minute is considered a significant deterioration.

[0064] At the application level, this step is widely used in node health assessments of Kubernetes clusters, especially in identifying resource overload, performance bottlenecks, or potential failures. By analyzing trends in KPIs such as CPU, memory, disk I / O, and network bandwidth, the system can identify nodes with abnormal resource usage, avoiding misjudgments due to momentary fluctuations. For example, when a node's memory usage continues to rise and RoC is positive, the system will determine that the node has a memory leak risk and needs to be addressed first.

[0065] From a technical perspective, this step effectively enhances the dynamic adaptability of load assessment by introducing time-weighted analysis. Compared to traditional static threshold methods, this solution can more accurately reflect the health trend of nodes, reduce false positives and false negatives, and improve the intelligence level of operation and maintenance response. Furthermore, by linearly weighting and fusing the WMA and RoC of multiple KPIs, the system can comprehensively evaluate the multidimensional load status of nodes, providing a reliable data foundation for subsequent priority calculations.

[0066] S22, normalize the raw load scores of all key performance indicators using the Sigmoid function to ensure that their values ​​are in the range of [0,1], and then perform final weighted fusion according to the preset weights of each indicator.

[0067] Specifically, this step involves normalizing the raw load scores of all key performance indicators (KPIs) using the Sigmoid function and then weighting and fusing them according to the preset weights of each indicator to generate a unified comprehensive load factor L. This step is one of the core components of the dynamic priority evaluation algorithm of this invention, aiming to map raw load data from different dimensions to a unified [0,1] interval, thereby achieving standardized fusion of multi-source heterogeneous data and improving the accuracy and interpretability of node maintenance priority evaluation.

[0068] At the technical implementation level, firstly, the system collects key performance indicator data of nodes from a monitoring system (such as Prometheus) over the past 15 minutes, including CPU utilization, memory utilization, disk I / O latency, and network bandwidth utilization. The raw load score for each KPI is calculated using a combination of time-weighted moving average (WMA) and growth rate (RoC) to reflect the persistence and deterioration trend of resource pressure. Subsequently, the system inputs these raw scores into a Sigmoid function for non-linear normalization. The mathematical expression for the Sigmoid function is... Its function is to compress the unbounded original scores to the [0,1] interval, making high load values ​​closer to 1 and low load values ​​closer to 0, thereby enhancing the model's sensitivity to abnormal states.

[0069] At the parameter level, the Sigmoid function takes the raw load scores of each KPI as input and outputs the normalized load values. The normalized scores are then summed according to preset weights, such as CPU weight 0.4, memory weight 0.3, disk I / O weight 0.2, and network weight 0.1. These weights can be dynamically adjusted according to the actual business scenario to adapt to the system requirements of different resource sensitivities.

[0070] At the application level, this step is widely used in Kubernetes clusters for node health assessment, automated maintenance decisions, and resource scheduling optimization. For example, when a node experiences a continuous increase in CPU utilization, the system can more accurately determine whether it constitutes a high-priority maintenance event through normalization and weighted fusion, thereby triggering the corresponding automated processing flow.

[0071] In terms of technical effectiveness, this step, through Sigmoid normalization and a weighted fusion mechanism, effectively solves the fusion bias problem caused by inconsistent indicator dimensions in traditional methods, thus improving the robustness and comparability of load assessment. Simultaneously, by introducing time trend analysis, it enhances the predictive ability for potential failures, providing a reliable data foundation for subsequent priority calculation.

[0072] S3. Based on application metadata, calculate the application critical level factor P. The application critical level factor P is assigned a base score through the QoS level of Kubernetes, and then normalized after weighting according to the user-defined business priority label.

[0073] Specifically, this step involves calculating application key level factors based on application metadata. Its core lies in combining Kubernetes' native QoS (Quality of Service) levels with user-defined business priority labels, and through weighted calculation and normalization, achieving a quantitative assessment of the value of applications running on nodes. This factor It is a key component of the entire dynamic priority evaluation model, used to reflect the importance of business context in node maintenance priority decisions.

[0074] At the technical implementation level, firstly, when deploying a Kubernetes application, users need to add a custom business priority label to the Pod's metadata, such as `biz: "business-priority"`, where `business-priority` can take the values ​​`critical`, `important`, or `normal`, representing high, medium, and low business priorities, respectively. Secondly, the system iterates through all Pods on the node and assigns a base score based on their QoS level: `Guaranteed`, `Burstable`, and `BestEffort` correspond to 10, 5, and 1, respectively. Simultaneously, a corresponding business multiplier is assigned based on the business label: `critical`, `important`, and `normal` correspond to 3.0, 2.0, and 1.0, respectively. The original key score for each Pod... It is the product of the QoS base score and the service multiplier.

[0075] In application scenarios, this step is widely applicable to node maintenance priority decision-making systems in cloud-native environments. For example, in scenarios with extremely high business continuity requirements, such as finance and e-commerce, the system can dynamically adjust maintenance strategies based on the type of business running on the node (such as payment, order processing, log collection, etc.), prioritizing the stability of high-value businesses. By combining business priority with QoS levels, the system can accurately identify the business value of nodes, thereby prioritizing the processing of nodes carrying critical businesses when resources are scarce or anomalies occur.

[0076] The technical advantage of this step lies in its significant improvement in the accuracy and rationality of node maintenance decisions by introducing a business context-aware mechanism. Compared to traditional methods that rely solely on resource metrics or static rules, this solution achieves intelligent prioritization driven by business value, effectively avoiding resource waste or damage to critical business operations caused by unclear business priorities. Furthermore, this method boasts excellent scalability, supporting user-defined business priority strategies to meet the differentiated operational needs of various industries and business scenarios.

[0077] Furthermore, S3 includes:

[0078] S31 assigns a base score based on the QoS level of each Pod: 10 points for Guaranteed, 5 points for Burstable, and 1 point for BestEffort.

[0079] In some implementations, Kubernetes classifies Pods into three QoS levels: Guaranteed, Burstable, and BestEffort, representing resource guarantee levels from high to low. This invention, based on this classification, assigns different base scores to each QoS level to reflect its priority weight within the system. Specifically, Guaranteed Pods, due to their hard limitations on resource usage, typically handle critical business processes and are assigned 10 points; Burstable Pods offer some resource elasticity and are suitable for medium-priority business processes, and are assigned 5 points; BestEffort Pods have no resource guarantees and are suitable for non-critical tasks, and are assigned 1 point. This base score setting aligns with the priority logic of Kubernetes resource scheduling and provides standardized input for the subsequent weighted calculation of business multipliers (such as 3.0, 2.0, and 1.0).

[0080] Furthermore, the operational process of this step includes: First, the system obtains the QoS level information of all Pods on the node through the Kubernetes API; second, according to the preset mapping rules, a corresponding base score is assigned to each Pod; finally, the base score is multiplied by the business priority multiplier to obtain the Pod's original key score. This process must comply with Kubernetes QoS classification standards (such as Guaranteed requiring CPU and memory limits to be set and equal), and ensure that the business priority label (such as `biz: "business-priority"`) in the `annotations` field is correctly parsed in the Pod metadata.

[0081] This step has significant technical value in this invention. By combining QoS levels with service priorities, the system can prioritize Pods running on nodes from two dimensions: resource guarantee mechanisms and service context. This enables "service value-driven" intelligent prioritization in node maintenance decisions. This method overcomes the limitations of traditional operation and maintenance systems that rely solely on resource indicators or static labels, improving the accuracy of fault response and service assurance capabilities.

[0082] S32, multiply the base score by the business multiplier corresponding to the business priority label of the Pod, where critical corresponds to 3.0, important corresponds to 2.0, and normal corresponds to 1.0, to obtain the original key score of the Pod, and perform logarithmic normalization on the original key scores of all Pods to ensure that their value range is between [0,1].

[0083] Specifically, this step involves quantifying the criticality level of Pod services in Kubernetes. Its technical implementation is based on a dual weighting mechanism of service priority labeling and QoS level, aiming to transform service value information into a calculable numerical factor, thereby providing crucial input for node maintenance priority assessment. Specifically, the system first assigns a base score to the Pod based on its QoS level (Guaranteed, Burstable, BestEffort), which is 10, 5, and 1 respectively. Then, the system reads the custom service priority label (`biz: "business-priority"`) from the Pod's metadata. This label can take values ​​of `critical`, `important`, and `normal`, corresponding to service multipliers of 3.0, 2.0, and 1.0 respectively. In some implementations, this label can be configured through Kubernetes' Annotations mechanism, for example, `annotations: {"business-priority": "critical"}`. The raw criticality score (`raw_criticality_score`) of each Pod is the product of the base score and the service multiplier, i.e., `raw_criticality_score = base_score × business_multiplier`. Furthermore, the system sums the raw criticality scores of all Pods on a node to obtain the node's raw total criticality score (`total_raw_criticality`). To prevent this total score from becoming incomparable across nodes of different sizes and to highlight the influence of critical business Pods, the system employs logarithmic normalization, mapping `total_raw_criticality` to the [0,1] interval. The normalization function can optionally be a logarithmic function or a piecewise linear function, and its design must satisfy the monotonically increasing characteristic to ensure that the contribution of high-value business Pods is still significantly reflected after normalization.

[0084] S4. Based on abnormal event data and historical maintenance operation records, calculate the event time-series correlation factor M and the historical reliability factor H respectively, and then linearly weight and fuse the four factors L, P, M and H according to preset weights to generate the node maintenance priority score.

[0085] Specifically, this step calculates the event time-series correlation factor M and the historical reliability factor H based on abnormal event data and historical maintenance operation records. Then, the four factors—L (load factor), P (business factor), M, and H—are linearly weighted and fused according to preset weights to generate a node maintenance priority score. This step is the core execution link of the dynamic priority evaluation algorithm of this invention. Its technical implementation integrates time-series analysis, business awareness, event correlation, and historical feedback mechanisms, exhibiting a high degree of intelligence and adaptability.

[0086] At the technical implementation level, the calculation of the event time-series correlation factor M is based on concurrent abnormal events within a time window. When a high-weight event (such as an OOM log) occurs, the system searches for other abnormal events (such as CPU overload, memory overflow, network latency, etc.) within a ±3-minute time window, centered on the timestamp of that event. Each correlated event is assigned a basic weight according to its type (e.g., 0.8 for OOM, 0.6 for CPU overload), and its correlation score is calculated using an exponential decay function, combined with the time difference between it and the triggering event. After all scores are accumulated, they are mapped to the [0,1] interval using a normalization function (such as Min-Max or Sigmoid) to obtain the final M value.

[0087] The historical reliability factor H is calculated by querying the operation and maintenance knowledge base for the N most recent (e.g., N=5) historical records similar to the current problem, assigning them linearly decreasing weights in reverse chronological order (e.g., 5, 4, 3, 2, 1), and calculating a weighted sum based on the maintenance result (+1 for success, -1 for failure). The final H value is obtained by normalizing the sum by dividing it by the weighted sum (which is 15), and its value ranges from [-1, 1], reflecting the reliability of historical processing strategies.

[0088] Regarding parameter settings, the weight coefficients of each factor need to be optimized according to the actual business scenario. For example, the weights of L, P, M, and H can be set to 0.3, 0.4, 0.2, and 0.1, respectively. In the Kubernetes node maintenance system, this step is used to dynamically generate priority scores for maintenance tasks, thereby guiding the execution path of automated operation and maintenance strategies and significantly improving fault response efficiency and resource utilization.

[0089] The Kubernetes node maintenance priority evaluation method based on multi-dimensional heterogeneous data fusion in this invention can effectively integrate multi-dimensional heterogeneous data such as physical load, business value, event correlation and historical experience to achieve dynamic priority evaluation of Kubernetes node maintenance tasks, thereby improving the accuracy of fault response and the utilization efficiency of operation and maintenance resources.

[0090] Furthermore, S4 includes:

[0091] S41: Using the timestamp of the current triggering event as the center, search for all related events within a preset time window, and calculate the score of each related event using an exponential decay function based on the time difference between it and the triggering event.

[0092] Specifically, this step involves performing time-series correlation analysis on triggered events in the Kubernetes node intelligent maintenance system and calculating the scores of correlated events using an exponential decay function. This is part of the process of constructing the Temporal Correlation Factor (M). The core technical principle of this step is based on time-series event correlation modeling. By using time window filtering and a time difference decay function, the concurrent relationship of multiple abnormal events in the time dimension is quantified, thereby improving the system's ability to identify complex faults.

[0093] In some implementations, when a high-weight event (such as an OOM log) occurs, the system first obtains the timestamp of the event. And using that timestamp as the center, within a preset time window Retrieves all related events within the time window. The default setting is 3 minutes (180 seconds). This parameter can be dynamically adjusted based on the actual system response speed and event density to ensure that critical concurrent events are captured without introducing excessive noise. Related events can originate from sources including, but not limited to, system logs, monitoring metrics, and alarm information, and are stored in an event buffer to support high-throughput real-time queries.

[0094] In practical applications, this step is widely used for root cause analysis and priority assessment in cloud-native environments. For example, in a Kubernetes cluster, when a node experiences an OutOfMemory (OOM) event, the system can identify concurrent events such as memory overflow, CPU spikes, and network latency within a 3-minute window, and assign different weights to them using an exponential decay function, thereby comprehensively determining whether the node is in a complex fault state. This method complies with the ITIL event management specification's requirements for handling event correlations, while also improving the AIOps system's ability to perceive complex fault chains.

[0095] The technical advantage of this step lies in the fact that, by introducing a time decay mechanism, the system can more accurately identify abnormal events that are highly correlated with the current event in time, thereby enhancing the ability to identify complex faults and avoiding misjudgments caused by viewing a single event in isolation. Furthermore, this method supports parameterized configuration, possesses good adjustability and adaptability, and provides a crucial temporal dimension for subsequent priority calculation.

[0096] S42. Sort the most recent 5 historical maintenance operation records from newest to oldest by time, assign each record a decreasing integer weight, calculate the weighted total score, and then divide the total score by the sum of the weights, 15, to obtain the normalized historical reliability factor H.

[0097] Specifically, this step involves weighted processing and normalization calculation of historical maintenance operation records for Kubernetes nodes to generate a historical reliability factor H. Its core purpose is to provide experience-driven prioritization for current maintenance tasks through quantitative analysis of historical data. In some implementations, this step first retrieves the five most recent maintenance operation records with similar characteristics to the current issue from the operations knowledge base and sorts them from newest to oldest according to their timestamps, forming an ordered historical record list. Each record represents the contextual information of a maintenance operation, including a description of the issue characteristics, the executed maintenance strategy, the operation timestamp, and the maintenance result (success or failure).

[0098] Furthermore, to reflect the decay effect over time, the system assigns a decreasing integer weight to each record, with the newest record having a weight of 5, decreasing sequentially to the oldest record having a weight of 1. This weight allocation method conforms to the Linear Decaying Weighting Model, ensuring that recent operations have a greater impact on current decisions, thereby enhancing the algorithm's sensitivity to the latest operational experience. Optionally, the weight allocation can be adjusted according to actual business needs, such as using exponential decay or other nonlinear models, but in this invention, decreasing integer weights are used to simplify calculations and ensure interpretability.

[0099] At the parameter level, the maintenance result (Outcome) for each historical record is quantified as +1 (success) or -1 (failure), and multiplied by its corresponding weight to obtain a weighted result. All weighted results are summed to obtain the weighted total score (Hraw). To map this total score to the standardized interval [-1, 1], the system divides Hraw by the sum of the weights, 15, to obtain the normalized historical reliability factor (H). This normalization process follows the linear normalization principle to ensure that the H values ​​are comparable and consistent.

[0100] In application scenarios, this step is embedded in the H-factor calculation module of the dynamic priority evaluation algorithm to assist the decision engine in determining the priority of the current maintenance task. For example, when a node experiences concurrent anomalies such as CPU overload or memory overflow, the system uses the H-factor to evaluate the reliability of historical maintenance strategies, thereby deciding whether to adopt the same strategy or avoid potential failure scenarios. This step plays a crucial role in the closed-loop feedback mechanism; the maintenance operation results are recorded and fed back to the knowledge base, providing data support for subsequent H-factor calculations and enabling the system to self-learn and continuously optimize.

[0101] From a technical perspective, this step significantly improves the intelligence level of maintenance decisions by introducing quantitative evaluation based on historical experience. Compared to traditional static rules or single-dimensional evaluation methods, the introduction of the H factor enables the system to dynamically adjust maintenance strategies, avoiding the repeated execution of failed operations, thereby improving operational efficiency and system stability. Furthermore, this method exhibits good scalability and adaptability in cloud-native environments such as Kubernetes, making it suitable for automated operation and maintenance scenarios involving large-scale node clusters.

[0102] The Kubernetes node maintenance priority evaluation method based on multi-dimensional heterogeneous data fusion in this invention can effectively integrate multi-dimensional heterogeneous data such as physical load, business value, event correlation and historical experience to achieve dynamic priority evaluation of Kubernetes node maintenance tasks, thereby improving the accuracy of fault response and the utilization efficiency of operation and maintenance resources.

[0103] Furthermore, it also includes:

[0104] S5. Compare the node maintenance priority score with a preset priority threshold. If the score is greater than 0.7, mark the node as a high-priority task and immediately perform maintenance operations.

[0105] Specifically, this step is a decision-making and execution mechanism based on a dynamic priority evaluation model. Its core lies in comparing the node maintenance priority score with a preset priority threshold and triggering corresponding maintenance operations based on the comparison result. In some implementations, this step serves as a key control node in the entire intelligent maintenance system, directly determining the response strategy for node maintenance tasks, thereby achieving efficient scheduling of operation and maintenance resources and prioritizing critical business operations.

[0106] At the technical implementation level, the node maintenance priority score is calculated by fusing four core factors (L, P, M, H) using a weighted linear model, with an output range of [0, 1]. Here, L is the node's overall load factor, P is the application criticality level factor, M is the event time-series correlation factor, and H is the historical reliability factor. In this step, the system compares the calculated Priority value with a preset high-priority threshold (0.7). If Priority > 0.7, the system determines that the node is in a high-risk state and requires immediate maintenance. Maintenance operations may include, but are not limited to, node restart, Pod migration, resource expansion, log collection and analysis, etc. The specific operation is automatically selected by the operation and maintenance strategy engine based on the fault type and system configuration.

[0107] At the parameter level, the threshold of 0.7 is set based on a large amount of historical operational data and business impact analysis, aiming to balance false alarm rate and response timeliness. In actual deployment, this threshold can be configured as an adjustable parameter, supporting dynamic adjustment according to cluster size, business type, and operational strategies. Furthermore, the execution of maintenance operations must comply with Kubernetes scheduling specifications; for example, when performing Pod migration, the Pod Disruption Budget (PDB) policy must be followed to ensure business continuity.

[0108] At the application level, this step is widely applicable to automated operation and maintenance systems in cloud-native environments, especially in large-scale Kubernetes clusters, to identify and prioritize nodes carrying critical business functions (such as financial transactions and real-time data processing). For example, when a node carrying a Guaranteed QoS-level Pod experiences multiple anomalies in CPU, memory, and network simultaneously, and historical records show that similar problems have caused service interruptions, the system will quickly calculate Priority > 0.7, thereby triggering an emergency maintenance process to avoid business interruption.

[0109] In terms of technical effectiveness, this step, through a quantitative threshold judgment mechanism, achieves a shift from "passive response" to "proactive intervention," significantly improving the system's response speed and accuracy to critical nodes. Simultaneously, by incorporating the historical learning factor H, the system can continuously optimize maintenance strategies, reduce repetitive erroneous operations, and improve overall operational efficiency and system stability.

[0110] Example 2

[0111] This invention provides a method for integrating heterogeneous, multi-dimensional node status information (physical indicators, business value, event concurrency, and historical experience) into a unified quantitative model. This enables the priority assessment process to dynamically perceive the criticality level of the business carried by each node, achieving intelligent ranking driven by "business value." By introducing a closed-loop feedback mechanism, the algorithm possesses self-learning and self-optimization capabilities, continuously improving the accuracy of the assessment based on historical operational performance.

[0112] Specifically, the technical solution of this invention includes a system for implementing the algorithm of this invention, and a priority evaluation algorithm as the core of the system. This algorithm is embedded in an end-to-end closed-loop management system, such as... Figure 2 As shown.

[0113] Data input: The system's input layer is responsible for collecting raw data from various sources for the four factors (L, P, M, H) of the algorithm.

[0114] Core Decision: All data is aggregated into the decision engine, the core of which is the "dynamic priority algorithm" of this invention, which is responsible for calculating the final Priority score.

[0115] Output and use of decisions: The Priority value calculated by the algorithm will send the data to the processing flow to determine whether to execute, review or observe.

[0116] Feedback loop: After the maintenance task is completed, the operation results are written back to the operation and maintenance knowledge base to provide the latest data for the calculation of factor H during the next algorithm run, thus forming a learning loop.

[0117] Understandably, the system's algorithm abstracts the instantaneous state and historical behavior of a node into a multi-dimensional state vector, and maps this vector to a continuous, standardized priority score through a weighted linear model. The core mathematical model of the algorithm is as follows: in , , , , The values ​​are 0.3, 0.4, 02, and 01 respectively. This is a random item.

[0118] Specifically, this invention designs a dynamic priority evaluation algorithm, whose top-level mathematical model is as follows:

[0119]

[0120] The core lies in the precise quantification and fusion of the four factors: L, P, M, and H. Below, this invention will demonstrate, through derivation, how each factor is derived from raw data, undergoes step-by-step calculations, and ultimately forms its mathematical expression, along with the implementation steps.

[0121] In one embodiment of the present invention, factor L (Node Load Factor) - the overall node load factor:

[0122] a) Design Philosophy: Traditional load assessment only considers instantaneous values ​​(such as whether the CPU is currently at 90%), which is prone to misjudgment. The L-factor is designed based on the idea that a node's "pathological" load is not reflected in a single instantaneous peak, but rather in the "persistence" and "deteriorating trend" of resource pressure over a period of time. Therefore, this factor aims to capture these unhealthy resource consumption patterns that foreshadow problems through time-series analysis.

[0123] b) Calculation process and formula derivation:

[0124] Step 1: Raw Data Acquisition. This invention obtains time-series data of key performance indicators (KPIs) of nodes over the past 15 minutes from a monitoring system (such as Prometheus), including CPU utilization, memory utilization, disk I / O wait time, and network bandwidth utilization.

[0125] Step 2: Calculate the raw load score for each KPI. To measure trends, this invention calculates the time-weighted moving average (WMA) and rate of change (RoC) for each KPI. Then, this invention combines these two to calculate a raw load score that reflects the current state and the trend of change, which is denoted as... .

[0126] The calculation method is as follows: For example, for the CPU, its raw load score is... ;

[0127] Step 3: Normalize the original load score. The score obtained in the previous step... Since x is an unbounded value, this invention uses a non-linear function N(x) (such as the Sigmoid function) to map it to the interval [0, 1] for easier subsequent fusion. The output of this process is denoted as... .

[0128] Step 4: Weighted fusion to obtain the final factor L. Finally, this invention calculates the normalized scores of all KPIs according to preset weights. The weighted summation yields the final comprehensive load factor L. This final fusion step is mathematically expressed by the following formula:

[0129]

[0130] Where L: the final node comprehensive load factor, which is a floating-point number between [0, 1], and the higher the value, the greater the physical pressure. The preset weights for each key performance indicator, for example: It is 0.4. It is 0.3. It is 0.2. At 0.1, memory stress is often more fatal than CPU stress. The sigmoid function is used to smoothly map input values ​​to the range of 0 to 1. The raw load score of a single KPI, such as It is calculated from the WMA and RoC of this indicator.

[0131] In one embodiment of the invention, Factor P (Pod Criticality Factor) – applying a critical rank factor:

[0132] a) Design philosophy: The design philosophy of the P factor is to inject a business value perspective into the technology evaluation, so that the algorithm can understand "weighing the pros and cons" and prioritize the most important business.

[0133] b) Calculation process and formula derivation:

[0134] Step 1: When creating a workload, users add "business-priority" to the biz list, where business-priority can be critical, important, or normal, representing the importance of the business.

[0135] Step 2: Calculate the raw key score for a single Pod.

[0136] This invention iterates through each Pod on the node and assigns a base score based on its QoS level. (The native QoS has three types: Guaranteed Burstable, BestEffort, and is assigned values ​​of 10, 5, and 1 respectively), and then a service multiplier is assigned according to its service label. (The business logic has three values: critical, important, and normal, assigned values ​​of 3.0, 2.0, and 1.0 respectively.) The original key score for this Pod. It is the product of these two.

[0137] Step 3: Summing to obtain the node's original total score. This invention sums the original key scores of all Pods on a node to obtain the node's original business key score, denoted as... ;

[0138] Step 4: Normalization yields the final factor P. To prevent the score from growing indefinitely and to highlight the impact of key applications, this invention uses a logarithmic normalization function. Will Mapping to the interval [0, 1] yields the final P value. The complete mathematical expression of this normalization step is the following formula:

[0139]

[0140] Where: P is the final application criticality level factor, a floating-point number in the range [0, 1], and the final output calculated in this part. n: the total number of Pods on the node.

[0141] In one embodiment of the present invention, factor M (Temporal Correlation Factor) is an event temporal correlation factor.

[0142] a) Design philosophy: The design philosophy of the M factor is an operations version of "Sherlock Holmes". It firmly believes that the clustering of abnormal events of different dimensions in a short period of time is a "symptom cluster" of deep-seated faults, rather than a coincidence.

[0143] b) Calculation process and formula derivation:

[0144] Step 1: Identify the triggering event and related events. When a high-weight event... When an OOM (Out of Memory) event occurs, this invention uses its timestamp. Centered on this event, within a preset time window (e.g., 3 minutes before and after), find all other related events from the event buffer. ;

[0145] Step 2: Calculate the score for each associated event. For each found associated event... Preset event weights Based on the event weight and the time difference of the triggering event The correlation score is calculated using an exponential decay function.

[0146]

[0147] Step 3: Summing and normalizing to obtain the final factor M. This invention sums the scores of all related events and then normalizes the sum. This yields the final value of M. The complete calculation process can be mathematically expressed as the following formula:

[0148]

[0149] Where M is the final event time-series correlation factor; K is the number of correlated events; The normalization function maps the accumulated score to the interval [0, 1]. The base weight of the i-th associated event. The decay constant controls the influence of time distance; For the timestamps of the associated and triggering events.

[0150] In one embodiment of the present invention, factor H (Historical Reliability Factor) – a factor for historical reliability and self-learning:

[0151] a) Design philosophy: The design philosophy of the H factor is to implant "memory" and "experience" into the algorithm, so that it can learn from the successes and failures of the past, realize the intelligent "seeking advantages and avoiding disadvantages", and avoid making the same mistakes repeatedly.

[0152] b) Calculation process and formula derivation:

[0153] Step 1: Obtain the most recent N historical records. When a new problem occurs, this invention queries the "Operations and Maintenance Knowledge Base" for the most recent N (e.g., N=5) operation records that match this problem. These records are then sorted by time from newest to oldest. Output: An ordered list, such as [Record 1 (newest), Record 2, Record 3, Record 4, Record 5 (oldest)].

[0154] Step 2: Assign simple integer weights. This invention assigns a simple, decreasing integer weight to each record in this ordered list. The newest record has the highest weight, and the oldest record has the lowest weight.

[0155] Record 1 (latest) -> Weight 5; Record 2 -> Weight 4; Record 3 -> Weight 3;

[0156] Record 4 -> Weight 2; Record 5 (oldest) -> Weight 1;

[0157] Step 3: Calculate the weighted total score. This invention multiplies the "outcome" (+1 for success, -1 for failure) of each record by its weight, and then sums them all to obtain a weighted total score. :

[0158]

[0159] Step 4: Normalize to obtain the final factor H. To constrain Hraw within the interval [-1, 1], this invention simply divides it by the "highest possible score". The highest score is the sum of all weights. Sum of weights (maximum possible score): 5 + 4 + 3 + 2 + 1 = 15; the final H value is... The mathematical expression for this final normalization step is the following simplified formula: .

[0160] Where H is the final historical reliability factor; N is the number of historical records queried, which is fixed at 5; and i is the order of the historical records. The result of the i-th historical record is +1 for success and -1 for failure. The linearly decreasing weight of the i-th record; The sum of all weights (normalized denominator); when N=5, this value is 1+2+3+4+5 =15. This is a fixed value.

[0161] Furthermore, the output layer through The formula prioritizes tasks based on performance metrics, application metadata, system events, and historical records from the operations and maintenance knowledge base. When the priority is greater than 0.7, the task is considered a high-priority task and needs to be executed immediately; when the priority is greater than or equal to 0.4 and less than or equal to 0.7, the task is considered a medium-priority task and requires manual review; when the priority is less than or equal to 0.4, the task is considered a low-priority task and requires observation of records for further judgment.

[0162] For tasks involving node maintenance, the operation results are written back to the operation and maintenance knowledge base, providing the latest data for the calculation of factor H during the next algorithm run, thus forming a learning loop.

[0163] Example 3

[0164] To achieve the above embodiments, such as Figure 3 As shown, this embodiment also provides a Kubernetes node intelligent maintenance device 10, including:

[0165] The multidimensional status data acquisition module 100 is used to acquire multidimensional status data of the target node. The data includes time-series data of the node's performance indicators, application metadata deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status.

[0166] The comprehensive load factor calculation module 200 is used to calculate the comprehensive load factor L of the node based on the time series data of the performance indicators. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and by normalization after weighted fusion of each key performance indicator with preset weights.

[0167] The application key level factor evaluation module 300 is used to calculate the application key level factor P based on the application metadata. The application key level factor P is assigned a base score through the QoS level of Kubernetes and is obtained by weighting and normalizing according to the user-defined business priority label.

[0168] The multi-factor fusion evaluation module 400 is used to calculate the event time-series correlation factor M and the historical reliability factor H based on the abnormal event data and historical maintenance operation records, and to linearly weight and fuse the four factors L, P, M and H according to preset weights to generate a node maintenance priority score.

[0169] Furthermore, the multidimensional state data acquisition module is also used for:

[0170] Obtain time-series data of node CPU usage, memory usage, disk I / O wait time, and network bandwidth utilization over the past 15 minutes from the monitoring system;

[0171] The QoS level and service priority label of each Pod deployed on the node are parsed from the Kubernetes metadata. The service priority label includes three types: critical, important, and normal.

[0172] Furthermore, the comprehensive load factor calculation module is also used for:

[0173] For each key performance indicator, calculate its time-weighted moving average (WMA) and growth rate (RoC), and then perform linear weighting according to preset weights to obtain the original load score of the indicator.

[0174] The raw load scores of all key performance indicators are normalized using the Sigmoid function to ensure that their values ​​are in the range of [0,1], and then finally weighted and merged according to the preset weights of each indicator.

[0175] Furthermore, the key ranking factor assessment module is also used for:

[0176] Each Pod is assigned a base score based on its QoS level: Guaranteed level is assigned 10 points, Burstable level is assigned 5 points, and BestEffort level is assigned 1 point.

[0177] The base score is multiplied by the business multiplier corresponding to the business priority label of the Pod, where critical corresponds to 3.0, important corresponds to 2.0, and normal corresponds to 1.0, to obtain the original key score of the Pod. The original key scores of all Pods are then logarithmically normalized to ensure that their value range is between [0,1].

[0178] Furthermore, the multi-factor fusion assessment module is also used for:

[0179] Centered on the timestamp of the current triggering event, find all related events within a preset time window, and calculate the score of each related event using an exponential decay function based on the time difference between it and the triggering event.

[0180] Sort the five most recent historical maintenance operation records from newest to oldest by time, assign each record a decreasing integer weight, calculate the weighted total score, and then divide the total score by the sum of the weights, 15, to obtain the normalized historical reliability factor H.

[0181] Furthermore, it also includes:

[0182] The priority determination module is used to compare the maintenance priority score of the node with a preset priority threshold. If the score is greater than 0.7, the node is marked as a high-priority task and maintenance is performed immediately. If the score is greater than or equal to 0.4 and less than or equal to 0.7, the node is marked as a medium-priority task and submitted for manual review. If the score is less than or equal to 0.4, the node is marked as a low-priority task and recorded for subsequent analysis.

[0183] The Kubernetes node intelligent maintenance device according to embodiments of the present invention can effectively integrate multi-dimensional heterogeneous data such as physical load, business value, event correlation and historical experience to realize dynamic priority evaluation of Kubernetes node maintenance tasks, thereby improving the accuracy of fault response and the utilization efficiency of operation and maintenance resources.

[0184] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0185] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A method for intelligent maintenance of Kubernetes nodes, characterized in that, include: S1, obtain multi-dimensional status data of the target node, including time-series data of the node's performance indicators, application metadata deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status; S2, based on the time series data of the performance indicators, calculate the comprehensive load factor L of the node. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and by normalization after weighted fusion of each key performance indicator with preset weights. S3. Based on the application metadata, calculate the application key level factor P. The application key level factor P is assigned a base score through the QoS level of Kubernetes, and is obtained by weighting and normalizing according to the user-defined business priority label. The business priority label is metadata that users add customally through the Kubernetes Annotations field when deploying a Pod. It is used to express the urgency of the business carried by the Pod, and different business priority labels have corresponding business multipliers. S4. Based on abnormal event data and historical maintenance operation records, calculate the event time-series correlation factor M and the historical reliability factor H respectively, and linearly weight and fuse the four factors L, P, M and H according to preset weights to generate node maintenance priority scores. The calculation of the event time-series correlation factor M and the historical reliability factor H based on abnormal event data and historical maintenance operation records includes: S41, taking the timestamp of the current triggering event as the center, find all related events within a preset time window, and calculate the score of each related event using an exponential decay function based on the time difference between the event and the triggering event. After accumulating the scores of each related event, obtain the event time-series correlation factor M through a normalization function. S42, sort the most recent N historical maintenance operation records from newest to oldest by time, assign each record a decreasing integer weight, calculate the weighted total score, and divide the total score by the sum of the weights to obtain the normalized historical reliability factor H, where N is a positive integer.

2. The method as described in claim 1, characterized in that, The acquisition of multidimensional state data of the target node also includes: S11: Obtain time-series data of the node's CPU utilization, memory utilization, disk I / O wait time, and network bandwidth utilization in the last 15 minutes from the monitoring system. S12 parses the QoS level and service priority label of each Pod deployed on the node from the Kubernetes metadata. The service priority label includes three types: critical, important, and normal.

3. The method as described in claim 1, characterized in that, The comprehensive load factor L of the computing node, based on the time-series data of the performance indicators, further includes: S21. Calculate the time-weighted moving average (WMA) and growth rate (RoC) for each key performance indicator, and perform linear weighting according to the preset weights to obtain the original load score of the indicator. S22, normalize the raw load scores of all key performance indicators using the Sigmoid function to ensure that their values ​​are in the range of [0,1], and then perform final weighted fusion according to the preset weights of each indicator.

4. The method as described in claim 1, characterized in that, The calculation of the application critical level factor P based on the application metadata also includes: S31 assigns a base score based on the QoS level of each Pod: 10 points for Guaranteed, 5 points for Burstable, and 1 point for BestEffort. S32, multiply the base score by the business multiplier corresponding to the business priority label of the Pod, where critical corresponds to 3.0, important corresponds to 2.0, and normal corresponds to 1.0, to obtain the original key score of the Pod, and perform logarithmic normalization on the original key scores of all Pods to ensure that their value range is between [0,1].

5. The method as described in claim 1, characterized in that, Also includes: S5. The node maintenance priority score is compared with a preset priority threshold. If the score is greater than 0.7, the node is marked as a high-priority task and maintenance is performed immediately. If the score is greater than or equal to 0.4 and less than or equal to 0.7, the node is marked as a medium-priority task and submitted for manual review. If the score is less than or equal to 0.4, the node is marked as a low-priority task and recorded for subsequent analysis.

6. A Kubernetes node intelligent maintenance device, characterized in that, include: The multi-dimensional status data acquisition module is used to acquire multi-dimensional status data of the target node. The data includes time-series data of the node's performance indicators, application metadata deployed on the node, abnormal event data that occurred within a preset time window, and historical maintenance operation records similar to the current status. The comprehensive load factor calculation module is used to calculate the comprehensive load factor L of the node based on the time series data of the performance indicators. The comprehensive load factor L is obtained by trend analysis through time-weighted moving average and growth rate, and by normalization after weighted fusion of each key performance indicator with preset weights. The application key level factor evaluation module is used to calculate the application key level factor P based on the application metadata. The application key level factor P is assigned a base score through the QoS level of Kubernetes and is obtained by weighting and normalizing according to the user-defined business priority label. The business priority label is metadata that users add customally through the Kubernetes Annotations field when deploying a Pod. It is used to express the urgency of the business carried by the Pod, and different business priority labels have corresponding business multipliers. The multi-factor fusion evaluation module is used to calculate the event time-series correlation factor M and the historical reliability factor H based on abnormal event data and historical maintenance operation records, and to linearly weight and fuse the four factors L, P, M and H according to preset weights to generate a node maintenance priority score. The multi-factor fusion evaluation module is specifically used to find all related events within a preset time window, centered on the timestamp of the current triggering event, and calculate the score of each related event using an exponential decay function based on the time difference between the event and the triggering event. After accumulating the scores of each related event, the event time-series correlation factor M is obtained through a normalization function. Sort the most recent N historical maintenance operation records from newest to oldest by time, assign each record a decreasing integer weight, calculate the weighted total score, and then divide the total score by the sum of the weights to obtain the normalized historical reliability factor H, where N is a positive integer.

7. The apparatus as claimed in claim 6, characterized in that, The multidimensional state data acquisition module is also used for: Obtain time-series data of node CPU usage, memory usage, disk I / O wait time, and network bandwidth utilization over the past 15 minutes from the monitoring system; The QoS level and service priority label of each Pod deployed on the node are parsed from the Kubernetes metadata. The service priority label includes three types: critical, important, and normal.

8. The apparatus as claimed in claim 6, characterized in that, The comprehensive load factor calculation module is also used for: For each key performance indicator, calculate its time-weighted moving average (WMA) and growth rate (RoC), and then perform linear weighting according to preset weights to obtain the original load score of the indicator. The raw load scores of all key performance indicators are normalized using the Sigmoid function to ensure that their values ​​are in the range of [0,1], and then finally weighted and merged according to the preset weights of each indicator.

9. The apparatus as claimed in claim 6, characterized in that, The application key level factor evaluation module is also used for: Each Pod is assigned a base score based on its QoS level: Guaranteed level is assigned 10 points, Burstable level is assigned 5 points, and BestEffort level is assigned 1 point. The base score is multiplied by the business multiplier corresponding to the business priority label of the Pod, where critical corresponds to 3.0, important corresponds to 2.0, and normal corresponds to 1.0, to obtain the original key score of the Pod. The original key scores of all Pods are then logarithmically normalized to ensure that their value range is between [0,1].

10. The apparatus as claimed in claim 6, characterized in that, Also includes: The priority determination module is used to compare the maintenance priority score of the node with a preset priority threshold. If the score is greater than 0.7, the node is marked as a high-priority task and maintenance is performed immediately. If the score is greater than or equal to 0.4 and less than or equal to 0.7, the node is marked as a medium-priority task and submitted for manual review. If the score is less than or equal to 0.4, the node is marked as a low-priority task and recorded for subsequent analysis.

Images