A kubernetes resource profiling and cost optimization method and system

Abstract

The application belongs to the technical field of cloud computing and container orchestration resource management, and discloses a Kubernetes resource portrait and cost optimization method and system, which comprises the following steps: obtaining container resource index original data; performing aggregation to obtain aggregated data; using a resource portrait engine to classify services and generate service resource portraits; performing multi-dimensional anomaly detection according to the service resource portraits to obtain an abnormal service list; generating adjustment suggestions based on the abnormal service list to obtain an optimization suggestion set; adopting a differentiated merging request submission strategy according to the risk level of the optimization suggestion set to output a merging request; comparing resource usage data and service running indexes before and after merging to generate an optimization effect verification report; and using a capacity predictor to predict resource demand of the service resource portrait, and generating a capacity warning and calibrating the predictor when the predicted value exceeds a threshold value. The application solves the deficiencies of the prior art in pattern recognition, risk management and capacity planning.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and container orchestration resource management technology, and in particular to a Kubernetes resource profiling and cost optimization method and system. Background Technology

[0002] Kubernetes, as a mainstream container orchestration platform, adopts a declarative resource management model, requiring users to explicitly declare resource requests and limits for each container. This resource configuration directly determines the cluster's resource utilization efficiency, service stability, and infrastructure costs. However, existing resource management technologies still have the following limitations in practical applications: Traditional resource allocation methods driven by manual experience rely heavily on subjective estimates from operations or development personnel. This fails to effectively integrate dynamic changes in service load, cyclical fluctuations in business operations, and historical operational data, leading to significant discrepancies between resource allocation and actual usage. In real-world production environments, resource requests for many services far exceed actual usage, resulting in overall cluster resource utilization typically below 30%, causing severe waste of computing resources and increased costs. Furthermore, this approach lacks differentiated allocation strategies based on resource usage patterns, making it difficult to provide matching resource guarantees for services with different characteristics such as stable, cyclical, and bursty nature, leading to frequent stability issues for highly volatile or high-risk services.

[0003] Existing native Kubernetes autoscaling mechanisms (such as VPA and HPA) also have significant limitations. VPA generates resource recommendations based on simple statistics (such as mean and percentiles), lacking deep identification capabilities for service resource usage patterns. Recommendations for periodic or sudden loads are often inaccurate. Furthermore, VPA resource adjustments require Pod restarts, posing an interruption risk to stateful or highly available services, and it lacks risk assessment and differentiated execution mechanisms. HPA only addresses load changes by adding or removing Pod replicas, failing to solve the problem of unreasonable resource configuration within a single Pod. Its scaling threshold relies on manual setting and lacks adaptive capabilities, and when working in conjunction with VPA, it is prone to causing resource adjustment oscillations.

[0004] Furthermore, existing monitoring tools (such as Prometheus and Grafana) only provide visualization of raw metrics and static alerts, lacking the ability to intelligently analyze and classify resource usage patterns. Operations personnel must manually interpret numerous charts to make optimization decisions. The resource optimization process cannot form an automated closed loop with the GitOps workflow: resource adjustment suggestions are difficult to automatically translate into YAML configuration changes in the Git repository, there is a lack of change review integration and post-deployment effect verification, and anomaly rollbacks rely on manual intervention. This results in the inability to form a complete closed loop from data collection to intelligent analysis to suggestion generation to automatic deployment to effect verification.

[0005] Meanwhile, existing technical solutions generally lack automated change mechanisms for risk perception, lack quantitative risk assessment models that comprehensively consider factors such as OOM event frequency, CPU throttling ratio, and resource reserves, and cannot adopt differentiated execution strategies based on risk levels (automatic execution for low-risk, manual review for high-risk). Furthermore, they fail to distinguish the different risk characteristics of stateless and stateful services during resource adjustments. Existing solutions also lack predictive capacity planning capabilities: they passively respond based solely on current or recent data, failing to identify long-term growth trends in resource usage, effectively separating periodic fluctuations from trend changes, and lacking quantitative expressions of prediction confidence intervals and model self-calibration mechanisms, making it difficult to support forward-looking capacity decisions.

[0006] Furthermore, there is a lack of deep integration between resource optimization and the observability system. The execution process of optimization operations lacks structured audit logs, making it impossible to trace the complete decision-making chain of each resource change (including profile data, anomaly detection results, optimization suggestion basis, change execution results, and effect verification data); there is a lack of dedicated visualization dashboards for resource optimization scenarios, making it difficult for operations and maintenance personnel to intuitively grasp the overall status of cluster resource optimization; and there is no standardized integration interface between optimization audit data and existing log systems (such as Loki), making it impossible to utilize existing log query and analysis capabilities for in-depth auditing.

[0007] Therefore, how to provide a Kubernetes resource profiling and cost optimization method and system is an urgent problem to be solved. Summary of the Invention

[0008] This invention provides a Kubernetes resource profiling and cost optimization method and system to address the problems in the prior art.

[0009] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or to describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0010] According to a first aspect of the present invention, a method for Kubernetes resource profiling and cost optimization is provided.

[0011] In one embodiment, a Kubernetes resource profiling and cost optimization method includes: Periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on preset query statements to obtain the raw indicator dataset. Based on the original indicator dataset, the data is aggregated according to preset dimensions to obtain aggregated indicator data. Based on the aggregated indicator data, the resource profiling engine is used to classify the resource usage patterns of each service and generate service resource profiles. Based on the service resource profile, multi-dimensional anomaly detection is performed using an anomaly detector to obtain a list of abnormal services and the corresponding anomaly detection results. Based on the list of abnormal services and service resource profiles, the optimization advisor generates adjustment suggestions for resource requests and resource limits for each abnormal service, resulting in a set of optimization suggestions. The MR generator is used to transform the set of optimization suggestions into change patches for the deployment configuration file, and a differentiated merge request submission strategy is adopted according to the risk level to output the merge request; Based on the merge request, compare resource usage data and service operation metrics before and after the merge, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, automatically roll back the merge request and send an alarm notification. The capacity predictor is used to predict resource demand based on the service resource profile and obtain the predicted value. When the predicted value exceeds the set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is calibrated based on the comparison between the actual value and the predicted value.

[0012] In one embodiment, based on the original indicator dataset, aggregated metrics are obtained according to preset dimensions; based on the aggregated indicator data, a resource profiling engine is used to classify the resource usage patterns of each service and generate a service resource profile, including the following steps: After removing extreme outliers from the obtained raw metric dataset using the interquartile range method, the dataset is then aggregated hierarchically according to the three dimensions of namespace, deployment unit, and container to obtain the aggregated metric data for each service. Based on the aggregated metric data, calculate the four percentile statistics of each service in terms of CPU and memory dimensions: P50, P95, P99 and maximum value. The aggregated indicator data is input into the feature extraction layer of the resource profiling engine, where statistical features for pattern classification are extracted in both the CPU and memory dimensions. The feature normalization layer of the resource profiling engine is then used to fuse similar features from the CPU and memory dimensions to obtain fused feature data. The statistical features include the coefficient of variation, the maximum value of the autocorrelation coefficient, the slope of the normalization trend, and the peak-to-peak ratio. The fused feature data is input into the hierarchical decision layer of the resource profiling engine, and the resource usage patterns of each service are classified according to the preset judgment priority to obtain the corresponding resource usage pattern type. By combining aggregated metric data, percentile statistics, resource usage pattern types, number of container memory overflow termination events, and CPU throttling ratio, a service resource profile is constructed.

[0013] In one embodiment, the fused feature data is input into the hierarchical decision layer of the resource profiling engine, and the resource usage patterns of each service are classified according to a preset decision priority to obtain the corresponding resource usage pattern types, including: Determine whether a service simultaneously satisfies the conditions that its coefficient of variation is below the first threshold and its peak value is below the second threshold. If so, classify the service as stable. If the stable condition is not met, then it is further determined whether the normalization trend slope is higher than the third threshold. If it is met, the service is classified as growth type. If the growth-type criteria are not met, then it is further determined whether the maximum value of the autocorrelation coefficient is higher than the fourth threshold. If it is met, then the service is classified as cyclical. If none of the three criteria are met, the service will be classified as a sudden occurrence.

[0014] In one embodiment, the process of performing multi-dimensional anomaly detection based on service resource profiles and anomaly detectors to obtain a list of abnormal services and corresponding anomaly detection results includes the following steps: Based on service resource profiles, an anomaly detector is used to calculate the waste score for each service. When the waste score exceeds the first alarm threshold, the service is marked as a resource waste state and waste quantification data is recorded. Based on service resource profiles, an anomaly detector is used to calculate the risk score for each service; when the risk score exceeds the second alarm threshold, the service is marked as resource-insufficient and a high-priority alarm is generated. Based on the service resource profile, an anomaly detector is used to perform pattern drift detection on each service. When the current value of any resource dimension deviates from the historical mean by more than twice the standard deviation, it is determined that a pattern drift has occurred, a pattern drift alarm is generated, and the service resource profile is regenerated. Based on the service resource profiles of all services under the same namespace, the anomaly detector is used to calculate the resource usage correlation between service pairs. When the correlation coefficient in the CPU or memory dimension exceeds the preset correlation threshold, it is determined that there is a resource contention mode and the competing service combination is recorded. Services marked as resource waste, resource shortage, pattern drift, or resource contention are integrated to form a list of abnormal services and corresponding anomaly detection results.

[0015] In one embodiment, the waste score is obtained by weighted averaging the percentage of waste in the CPU and memory dimensions by comparing the resource request value of the service with the actual usage of P95. The risk score is obtained by weighted summation of three risk factors: the number of OOM termination events, the CPU throttling ratio, and the insufficient resource margin factor.

[0016] In one embodiment, based on the list of abnormal services and service resource profiles, an optimization recommender generates adjustment suggestions for resource requests and resource limits for each abnormal service, resulting in a set of optimization suggestions, including the following steps: Based on each abnormal service in the abnormal service list, and combined with the corresponding service resource profile, the workload type of each service is determined, resulting in stateless services and stateful services. Based on the P99 resource usage in the service resource profile, differentiated safety margin coefficients are applied for stateless and stateful services to calculate the resource request recommendation value for each abnormal service; and based on the resource request recommendation value and the proportion coefficient of the corresponding service type, the resource limit recommendation value is calculated. In the case of multiple abnormal services under the same namespace, the total resource request suggestion value of all abnormal services is calculated in combination with the resource quota constraint of the namespace. If the total resource request suggestion value exceeds the resource quota limit, the optimization suggestions are trimmed and optimized in order from low to high according to the preset priority score, and the safety lower limit constraint of each service is preserved in the trimming process to obtain the final adjustment suggestion. Estimate the monthly cost savings for each recommendation in the final adjustment recommendations, and assess the risk level of each recommendation based on the scope of resource adjustments, workload type, historical anomalies, and stability of resource usage patterns; Integrate all final adjustment recommendations, cost saving estimates, and risk levels to form an optimization recommendation set.

[0017] In one embodiment, the differentiated merge request submission strategy includes: For low-risk optimization suggestions, automatically create a merge request in normal state, and improve the optimization basis, configuration change comparison, estimated cost savings and risk assessment information in the request description; For medium-risk optimization suggestions, create a merge request in draft status, mark it as requiring manual review, and automatically assign a reviewer; For high-risk optimization suggestions, create a merge request in draft form, attach a complete rollback plan, and merge after approval by the reviewer.

[0018] In one embodiment, a capacity predictor is used to predict resource demand based on a service resource profile, yielding predicted values. When the predicted value exceeds a set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is then calibrated based on a comparison between the actual and predicted values, including the following steps: Based on at least 30 days of historical service resource profile data, the capacity predictor is used to perform time series decomposition on the resource usage time series in the CPU and memory dimensions respectively, decomposing the original series into trend components, periodic components and residual components, and obtaining the data of each component after decomposition. Based on linear regression extrapolation of trend components and periodic extrapolation of periodic components, resource demand forecasts for three time windows of 30 days, 60 days and 90 days are generated. Confidence intervals at two levels, 80% and 95%, are calculated based on the standard deviation of the residual components to obtain the forecast values ​​and corresponding confidence intervals. When the predicted value shows that the resource usage of a namespace will exceed the preset ratio of the current resource quota limit of the namespace in the next 30 days, a capacity warning message is generated and an expansion plan is recommended. After acquiring new actual resource usage data, the predicted values ​​are compared with the actual values, the prediction error is calculated, and the capacity predictor is iteratively updated using the prediction error.

[0019] In one embodiment, after acquiring new actual resource usage data, comparing the predicted value with the actual value, calculating the prediction error, and using the prediction error to iteratively update the capacity predictor includes the following steps: The capacity predictor model parameters are updated online using an exponentially weighted moving average method to obtain calibrated capacity predictor model parameters; wherein, the calibrated capacity predictor model parameters include trend slope, residual standard deviation, periodic component template, and intercept. Based on the calibrated capacity predictor model parameters, the prediction accuracy of the capacity predictor is evaluated, and the mean absolute percentage error is calculated. When the mean absolute percentage error exceeds a preset accuracy threshold, or the cumulative number of incremental updates since the last complete training exceeds a preset upper limit, the capacity predictor is automatically retrained to retrain the model parameters and complete the iterative update of the capacity predictor.

[0020] According to a second aspect of the present invention, a Kubernetes resource profiling and cost optimization system is provided.

[0021] In one embodiment, a Kubernetes resource profiling and cost optimization system includes: The data acquisition module is used to periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on preset query statements to obtain the raw indicator dataset. The profile building module is used to aggregate the original indicator dataset according to preset dimensions to obtain aggregated indicator data; based on the aggregated indicator data, the resource profile engine is used to classify the resource usage patterns of each service and generate service resource profiles. The anomaly detection module is used to perform multi-dimensional anomaly detection based on the service resource profile and the anomaly detector, and obtain a list of abnormal services and the corresponding anomaly detection results. The suggestion generation module is used to generate adjustment suggestions for resource requests and resource limits for each abnormal service based on the list of abnormal services and service resource profiles, and to obtain an optimization suggestion set. The change submission module is used to convert the set of optimization suggestions into change patches for the deployment configuration file using the MR generator, and to output the merge request by adopting a differentiated merge request submission strategy based on the risk level. The effect verification module is used to compare resource usage data and service operation metrics before and after the merge request, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, the merge request is automatically rolled back and an alarm notification is sent. The capacity prediction module is used to predict resource demand based on the service resource profile using a capacity predictor and obtain predicted values. When the predicted value exceeds a set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is also calibrated based on the comparison between the actual value and the predicted value.

[0022] According to a third aspect of the present invention, a computer device is provided.

[0023] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described above.

[0024] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.

[0025] In one embodiment, a computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the above method.

[0026] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: 1. This invention uses PromQL to query Prometheus to collect resource usage metrics for containers across multiple dimensions, including CPU, memory, network I / O, and disk I / O. Data is aggregated at three levels: namespace, deployment unit, and container, calculating multi-level statistical features such as P50, P95, P99, and maximum values ​​to construct a structured service resource profile. Based on this, an AI model automatically categorizes the resource usage patterns of each service into four typical types: stable, cyclical, bursty, and growing. Differentiated optimization strategies are then developed for each type. This invention enables resource optimization suggestions to accurately match the actual usage characteristics of services, overcoming the blindness and inaccuracy of traditional manual experience-based configuration. It provides a precise data foundation and scientific decision-making basis for resource optimization, transforming resource configuration from subjective experience-driven to objective data-driven.

[0027] 2. The MR generator of this invention can automatically convert optimization suggestions into Deployment YAML configuration change patches, which are submitted to the GitOps code repository in the form of Merge Requests. This fully leverages the team's existing code review process to ensure the quality of resource changes. After the MR is merged, the configuration changes are automatically synchronized to the Kubernetes cluster using the ArgoCD declarative continuous deployment tool. After deployment, the system automatically compares resource usage data and service performance metrics before and after deployment within 24 hours, generating an optimization effect verification report. When service anomalies are detected, i.e., the error rate increases by more than 5% or latency increases by more than 20%, the system automatically creates a rollback MR and sends an alarm notification. This invention achieves full-process automation from data collection to configuration optimization, significantly reducing maintenance manpower costs, improving optimization execution efficiency, and ensuring the security of changes through automated post-deployment verification and anomaly rollback mechanisms.

[0028] 3. This invention comprehensively evaluates resource status using two quantitative indicators: waste score and risk score. The waste score is a weighted average of CPU and memory performance. The risk score is calculated based on three factors: OOM event frequency, CPU throttling ratio, and resource margin. Based on this, the system assigns a risk level to each optimization suggestion and adopts a differentiated MR submission strategy accordingly. Furthermore, this invention employs differentiated safety margin strategies for stateless and stateful services. This invention maximizes automation while ensuring service stability, achieving an optimal balance between security and efficiency.

[0029] 4. The capacity predictor of this invention is based on at least 30 days of historical resource profile data. It uses a time-series decomposition method to separate resource usage data into three components: a periodic component, a long-term trend component, and a residual component. By extrapolating the trend component, the uncertainty of the prediction results is quantified. When the prediction result shows that the resource usage of a namespace will exceed 80% of the current quota within the next 30 days, the system automatically generates a capacity warning and recommends expansion solutions. Furthermore, this invention establishes a continuous self-calibration mechanism for the prediction model: when new actual data arrives, the system automatically compares the predicted value with the actual value, continuously calibrating the parameters of the prediction model. This invention enables operations teams to shift from passively responding to resource problems to proactively predicting and planning capacity requirements, effectively avoiding service interruptions due to insufficient capacity, while ensuring that prediction accuracy continuously improves over time through continuous self-calibration.

[0030] 5. This invention records all optimization operations performed by the system as structured audit logs through an audit logger. Each log entry contains complete information such as operation timestamp, operation type, target service, operation parameters, and operation result, and is written to the Loki log aggregation system. The system supports querying the complete optimization timeline by service dimension, enabling full-link traceability of each optimization operation. Combined with the fault-tolerance mechanism for log writing, it ensures zero loss of audit data. This technical solution meets the requirements of enterprise-level compliance auditing for operational transparency, traceability, and controllability, providing complete audit assurance for system operation.

[0031] 6. This invention systematically addresses the shortcomings of existing Kubernetes resource management technologies in terms of intelligent identification of resource usage patterns, automated closed-loop optimization processes, risk-aware change management, and predictive capacity planning through four core innovations: AI-driven resource profiling and classification, GitOps closed-loop optimization, risk-aware MR strategy, and time-series decomposition and prediction. It achieves a technological leap from human experience-driven to data intelligence-driven Kubernetes container resource management.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0034] Figure 1 This is a flowchart illustrating a Kubernetes resource profiling and cost optimization method according to an exemplary embodiment; Figure 2This is a schematic diagram illustrating the principle of a Kubernetes resource profiling and cost optimization system according to an exemplary embodiment; Figure 3 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment; Figure 4 This is an overall architecture diagram of a Kubernetes resource profiling and cost optimization system, illustrated according to an exemplary embodiment. Figure 5 This is an end-to-end data flow timing diagram illustrated according to an exemplary embodiment; Figure 6 This is a complete construction flowchart of a resource profiling engine illustrated according to an exemplary embodiment; Figure 7 This is a flowchart illustrating anomaly detection and optimization suggestion generation based on an exemplary embodiment; Figure 8 This is a flowchart illustrating the GitOps closed-loop optimization process according to an exemplary embodiment; Figure 9 This is a complete flowchart illustrating a capacity prediction algorithm according to an exemplary embodiment. Detailed Implementation

[0035] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0036] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0037] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0038] Figure 1 An embodiment of the Kubernetes resource profiling and cost optimization method of the present invention is shown.

[0039] In this optional embodiment, the Kubernetes resource profiling and cost optimization method includes: S101. Periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on the preset query statement to obtain the raw indicator dataset. S102. Based on the original indicator dataset, aggregate it according to preset dimensions to obtain aggregated indicator data; based on the aggregated indicator data, use the resource profiling engine to classify the resource usage patterns of each service and generate service resource profiles. S103. Based on the service resource profile, perform multi-dimensional anomaly detection using the anomaly detector to obtain a list of abnormal services and the corresponding anomaly detection results. S104. Based on the list of abnormal services and the service resource profile, use the optimization advisor to generate adjustment suggestions for resource requests and resource limits for each abnormal service, and obtain an optimization suggestion set; S105. Use the MR generator to convert the optimization suggestion set into change patches for the deployment configuration file, and adopt a differentiated merge request submission strategy based on the risk level to output the merge request. S106. Based on the merge request, compare the resource usage data and service operation indicators before and after the merge, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, automatically roll back the merge request and send an alarm notification. S107. Use the capacity predictor to predict resource demand based on the service resource profile and obtain the predicted value; when the predicted value exceeds the set threshold, generate a capacity warning and recommend expansion plan, and calibrate the capacity predictor based on the comparison between the actual value and the predicted value.

[0040] In practical applications, during the execution process from S101 to S107, each operation can be recorded as a structured audit log entry and written to the Loki log aggregation system through the audit logger.

[0041] In this optional embodiment, based on the original indicator dataset, the data is aggregated according to preset dimensions to obtain aggregated indicator data; based on the aggregated indicator data, the resource usage patterns of each service are classified using a resource profiling engine to generate a service resource profile, including the following steps: After removing extreme outliers from the obtained raw metric dataset using the interquartile range method, the dataset is then aggregated hierarchically according to the three dimensions of namespace, deployment unit, and container to obtain the aggregated metric data for each service. Based on the aggregated metric data, calculate the four percentile statistics of each service in terms of CPU and memory dimensions: P50, P95, P99 and maximum value. The aggregated indicator data is input into the feature extraction layer of the resource profiling engine, where statistical features for pattern classification are extracted in both the CPU and memory dimensions. The feature normalization layer of the resource profiling engine is then used to fuse similar features from the CPU and memory dimensions to obtain fused feature data. The statistical features include the coefficient of variation, the maximum value of the autocorrelation coefficient, the slope of the normalization trend, and the peak-to-peak ratio. The fused feature data is input into the hierarchical decision layer of the resource profiling engine, and the resource usage patterns of each service are classified according to the preset judgment priority to obtain the corresponding resource usage pattern type. By combining aggregated metric data, percentile statistics, resource usage pattern types, number of container memory overflow termination events, and CPU throttling ratio, a service resource profile is constructed.

[0042] In this optional embodiment, the fused feature data is input into the hierarchical decision layer of the resource profiling engine, and the resource usage patterns of each service are classified according to a preset decision priority to obtain the corresponding resource usage pattern types, including: Determine whether a service simultaneously satisfies the conditions that its coefficient of variation is below the first threshold and its peak value is below the second threshold. If so, classify the service as stable. If the stable condition is not met, then it is further determined whether the normalization trend slope is higher than the third threshold. If it is met, the service is classified as growth type. If the growth-type criteria are not met, then it is further determined whether the maximum value of the autocorrelation coefficient is higher than the fourth threshold. If it is met, then the service is classified as cyclical. If none of the three criteria are met, the service will be classified as a sudden occurrence.

[0043] In this optional embodiment, the process of performing multi-dimensional anomaly detection based on the service resource profile and anomaly detector to obtain an anomaly service list and corresponding anomaly detection results includes the following steps: Based on service resource profiles, an anomaly detector is used to calculate the waste score for each service. When the waste score exceeds the first alarm threshold, the service is marked as a resource waste state and waste quantification data is recorded. Based on service resource profiles, an anomaly detector is used to calculate the risk score for each service; when the risk score exceeds the second alarm threshold, the service is marked as resource-insufficient and a high-priority alarm is generated. Based on the service resource profile, an anomaly detector is used to perform pattern drift detection on each service. When the current value of any resource dimension deviates from the historical mean by more than twice the standard deviation, it is determined that a pattern drift has occurred, a pattern drift alarm is generated, and the service resource profile is regenerated. Based on the service resource profiles of all services under the same namespace, the anomaly detector is used to calculate the resource usage correlation between service pairs. When the correlation coefficient in the CPU or memory dimension exceeds the preset correlation threshold, it is determined that there is a resource contention mode and the competing service combination is recorded. Services marked as resource waste, resource shortage, pattern drift, or resource contention are integrated to form a list of abnormal services and corresponding anomaly detection results.

[0044] In this optional embodiment, the waste score is obtained by weighted averaging the percentage of waste in the CPU and memory dimensions by comparing the resource request value of the service with the actual usage of P95. The risk score is obtained by weighted summation of three risk factors: the number of OOM termination events, the CPU throttling ratio, and the insufficient resource margin factor.

[0045] In this optional embodiment, based on the list of abnormal services and service resource profiles, the optimization recommender generates adjustment suggestions for resource requests and resource limits for each abnormal service, resulting in an optimization suggestion set, including the following steps: Based on each abnormal service in the abnormal service list, and combined with the corresponding service resource profile, the workload type of each service is determined, resulting in stateless services and stateful services. Based on the P99 resource usage in the service resource profile, differentiated safety margin coefficients are applied for stateless and stateful services to calculate the resource request recommendation value for each abnormal service; and based on the resource request recommendation value and the proportion coefficient of the corresponding service type, the resource limit recommendation value is calculated. In the case of multiple abnormal services under the same namespace, the total resource request suggestion value of all abnormal services is calculated in combination with the resource quota constraint of the namespace. If the total resource request suggestion value exceeds the resource quota limit, the optimization suggestions are trimmed and optimized in order from low to high according to the preset priority score, and the safety lower limit constraint of each service is preserved in the trimming process to obtain the final adjustment suggestion. Estimate the monthly cost savings for each recommendation in the final adjustment recommendations, and assess the risk level of each recommendation based on the scope of resource adjustments, workload type, historical anomalies, and stability of resource usage patterns; Integrate all final adjustment recommendations, cost saving estimates, and risk levels to form an optimization recommendation set.

[0046] In this optional embodiment, the differentiated merge request submission strategy includes: For low-risk optimization suggestions, automatically create a merge request in normal state, and improve the optimization basis, configuration change comparison, estimated cost savings and risk assessment information in the request description; For medium-risk optimization suggestions, create a merge request in draft status, mark it as requiring manual review, and automatically assign a reviewer; For high-risk optimization suggestions, create a merge request in draft form, attach a complete rollback plan, and merge after approval by the reviewer.

[0047] In this optional embodiment, a capacity predictor is used to predict resource demand based on the service resource profile to obtain predicted values. When the predicted value exceeds a set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is then calibrated based on a comparison between the actual value and the predicted value, including the following steps: Based on at least 30 days of historical service resource profile data, the capacity predictor is used to perform time series decomposition on the resource usage time series in the CPU and memory dimensions respectively, decomposing the original series into trend components, periodic components and residual components, and obtaining the data of each component after decomposition. Based on linear regression extrapolation of trend components and periodic extrapolation of periodic components, resource demand forecasts for three time windows of 30 days, 60 days and 90 days are generated. Confidence intervals at two levels, 80% and 95%, are calculated based on the standard deviation of the residual components to obtain the forecast values ​​and corresponding confidence intervals. When the predicted value shows that the resource usage of a namespace will exceed the preset ratio of the current resource quota limit of the namespace in the next 30 days, a capacity warning message is generated and an expansion plan is recommended. After acquiring new actual resource usage data, the predicted values ​​are compared with the actual values, the prediction error is calculated, and the capacity predictor is iteratively updated using the prediction error.

[0048] In this optional embodiment, after acquiring new actual resource usage data, comparing the predicted value with the actual value, calculating the prediction error, and iteratively updating the capacity predictor using the prediction error includes the following steps: The capacity predictor model parameters are updated online using an exponentially weighted moving average method to obtain calibrated capacity predictor model parameters; wherein, the calibrated capacity predictor model parameters include trend slope, residual standard deviation, periodic component template, and intercept. Based on the calibrated capacity predictor model parameters, the prediction accuracy of the capacity predictor is evaluated, and the mean absolute percentage error is calculated. When the mean absolute percentage error exceeds a preset accuracy threshold, or the cumulative number of incremental updates since the last complete training exceeds a preset upper limit, the capacity predictor is automatically retrained to retrain the model parameters and complete the iterative update of the capacity predictor.

[0049] Figure 2 An embodiment of the Kubernetes resource profiling and cost optimization system of the present invention is shown.

[0050] In this optional embodiment, the Kubernetes resource profiling and cost optimization system includes: Data acquisition module 201 is used to periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on preset query statements to obtain the raw indicator dataset. The profile building module 202 is used to aggregate the original indicator dataset according to preset dimensions to obtain aggregated indicator data; based on the aggregated indicator data, the resource profile engine is used to classify the resource usage patterns of each service and generate service resource profiles. The anomaly detection module 203 is used to perform multi-dimensional anomaly detection based on the service resource profile and the anomaly detector to obtain a list of abnormal services and the corresponding anomaly detection results. The suggestion generation module 204 is used to generate adjustment suggestions for resource requests and resource limits for each abnormal service based on the list of abnormal services and service resource profiles, and obtain an optimization suggestion set. The change submission module 205 is used to convert the set of optimization suggestions into change patches for the deployment configuration file using the MR generator, and to output a merge request by adopting a differentiated merge request submission strategy based on the risk level. The effect verification module 206 is used to compare resource usage data and service operation indicators before and after the merge request, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, the merge request is automatically rolled back and an alarm notification is sent. The capacity prediction module 207 is used to predict resource demand based on the service resource profile using the capacity predictor and obtain the predicted value; when the predicted value exceeds the set threshold, a capacity warning is generated and an expansion plan is recommended, and the capacity predictor is calibrated based on the comparison between the actual value and the predicted value.

[0051] The Kubernetes resource profiling and cost optimization method and system of the present invention will now be explained and described with reference to specific embodiments.

[0052] The Kubernetes Resource Profiling and Cost Optimization System is deployed within a Kubernetes cluster using a Python microservice architecture. It triggers analysis cycles periodically via CronJob and deeply integrates with the user's existing GitOps technology stack (GitLab, Jenkins, ArgoCD, Grafana, Prometheus) to build an end-to-end intelligent resource optimization system containing six core functional components.

[0053] (I) Overall system architecture.

[0054] Figure 4This is an overall architecture diagram of the AI-driven Kubernetes resource profiling and cost optimization system described in this invention. Figure 4 As can be seen from the diagram, this system consists of four layers: a data layer, a core engine layer, an execution layer, and an external system integration layer. The data layer includes a Prometheus metrics collection and storage system, a PostgreSQL relational database, and a Loki log aggregation system. The core engine layer includes four core analysis components: a resource profiler, an anomaly detector, an optimization advisor, and a capacity predictor. The execution layer includes two execution components: an MR generator and a deployment verifier. The external system integration layer includes three external system interfaces: GitLab API, ArgoCD API, and Grafana Dashboard. These components form an end-to-end closed-loop data flow: Prometheus to the resource profiler, to PostgreSQL, to the anomaly detector, to the optimization advisor, to the MR generator, to GitLab, to ArgoCD, to the deployment verifier, and back to PostgreSQL.

[0055] Specifically, the data layer includes: the Prometheus metrics collection and storage system, used to collect multi-dimensional resource usage metrics at the container level; a PostgreSQL relational database, used to persistently store structured data such as resource profiles, optimization suggestions, prediction results, and verification reports; and the Loki log aggregation system, used to store structured audit logs.

[0056] The core engine layer comprises four core analytics components: the Resource Profiler, which collects data from Prometheus and builds service resource profiles; the Anomaly Detector, which identifies resource waste and insufficiency; the Optimization Advisor, which generates resource configuration optimization suggestions; and the Capacity Predictor, which predicts future resource demands.

[0057] The execution layer consists of two execution components: the MR Generator, which is responsible for converting optimization suggestions into GitLab Merge Requests; and the Deploy Verifier, which is responsible for monitoring the deployment status and verifying the optimization effects.

[0058] The external system integration layer includes: GitLab API for creating and managing Merge Requests; ArgoCD API for monitoring configuration synchronization and deployment status; and Grafana Dashboard for displaying resource profile overviews, anomaly detection results, and capacity alerts.

[0059] The data flow between the above components is as follows: Prometheus provides raw metric data to the resource profiling engine; the resource profiling engine stores the constructed resource profiles in PostgreSQL; the anomaly detector and capacity predictor read historical profile data from PostgreSQL for analysis; the anomaly detector passes anomaly reports to the optimization advisor; the optimization advisor passes optimization suggestions to the MR generator; the MR generator creates a Merge Request via the GitLab API; after the MR is merged, ArgoCD is triggered to synchronize the configuration; the deployment validator monitors the synchronization status via the ArgoCD API and stores the verification results in PostgreSQL; the capacity predictor and anomaly detector push alerts to the Grafana Dashboard; and the resource profiling engine writes the full-process audit logs to Loki.

[0060] (ii) End-to-end data flow and processing flow.

[0061] Figure 5 This is an end-to-end data flow sequence diagram of the system described in this invention, illustrating the complete data processing flow from timed triggering to effect verification completion. The entire data flow is divided into five stages: data acquisition and profile building, anomaly detection and scoring, optimization suggestion generation, GitOps closed-loop execution, and effect verification and rollback. Specifically, it includes the following steps: Step 1: Scheduled Triggering and Data Collection. The analysis cycle is triggered periodically (once daily by default) using Kubernetes CronJob. The resource profiling engine sends query requests to Prometheus via PromQL queries to obtain raw data on multi-dimensional resource usage metrics for all containers in the cluster over the past 7 days, including CPU utilization, memory usage, network I / O throughput, and disk I / O.

[0062] Step Two: Multi-Dimensional Aggregation and Profile Construction. The resource profiling engine aggregates the collected raw indicator data according to three dimensions: namespace, deployment, and container. It calculates statistical feature values ​​such as P50 (median), P95 (95th percentile), P99 (99th percentile), and Max (maximum value) for each dimension. Based on this, an AI model is used to automatically classify the resource usage patterns of each service (stable, cyclical, bursty, or growing), generating a structured service resource profile. This profile data is persistently stored in a PostgreSQL database, retaining at least 90 days of historical profiles for trend analysis.

[0063] Step 3: Anomaly Detection and Scoring. The anomaly detector reads the latest resource profile data from PostgreSQL and performs the following checks on each service: (1) Compare the service's resource request configuration (requests / limits) with the actual usage to calculate the waste score (Waste_Score). When the score exceeds the threshold of 60, the service is marked as a resource waste; (2) Calculate the risk score (Risk_Score) by combining the OOM event frequency, CPU throttling ratio, and resource reserves. When the score exceeds the threshold of 70, a high-priority alarm is generated; (3) Detect whether the resource usage pattern deviates from the historical profile by more than 2 standard deviations and trigger a pattern drift alarm; (4) Evaluate the resource usage correlation of all services under the same namespace and identify resource contention patterns.

[0064] Step 4: Optimization Recommendation Generation. The optimization recommender receives the list of anomalous services from the anomaly detector and, combined with service resource profile data, generates specific requests / limits adjustment recommendations for each anomalous service. The calculation of recommendation values ​​follows a differentiated safety margin strategy: the recommended value for stateless services (Deployment) is no less than 1.2 times the P99 resource usage, and the recommended value for stateful services (Stateful Set) is no less than 1.5 times the P99 resource usage. Simultaneously, optimization recommendations for multiple services are coordinated under the resource quota constraints of the same namespace to ensure that the total number of recommendations does not exceed the quota limit. Each optimization recommendation includes an estimated monthly cost saving amount and a risk level assessment (low / medium / high). High-risk recommendations also include rollback plans and monitoring indicator thresholds.

[0065] Step 5: MR Creation and Risk Awareness Submission. The MR generator converts optimization suggestions into resource change patches (YAML Patch) in the Deployment YAML configuration file and adopts differentiated MR submission strategies based on risk level: low-risk suggestions automatically create a regular Merge Request in the GitOps repository, with the MR description including complete optimization basis, estimated savings, and risk assessment information; medium-risk and high-risk suggestions create Draft Merge Requests, with the MR description indicating that manual review is required; high-risk MRs also include detailed rollback plans.

[0066] Step Six: Deployment Monitoring and Effect Verification. After the MapReduce merge, the system monitors the deployment progress of configuration changes through ArgoCD's synchronization status API. Within 24 hours of deployment completion, the deployment validator compares resource usage data and service performance metrics (error rate, latency, etc.) before and after deployment, generating an optimization effect verification report. When a service anomaly is detected (error rate increases by more than 5% or latency increases by more than 20%), the system automatically creates a rollback MapReduce and sends an alarm notification, achieving automated and rapid recovery from anomalies.

[0067] Step Seven: Capacity Forecasting and Early Warning. The capacity forecaster uses at least 30 days of historical resource profile data and employs time series decomposition to separate periodic patterns (daily and weekly cycles) and long-term growth trends, generating resource demand forecasts for three time windows: 30, 60, and 90 days. It provides confidence intervals of 80% and 95% for each forecast. When the forecast indicates that resource usage in a namespace will exceed 80% of the current quota within the next 30 days, a capacity warning is automatically generated, and expansion plans are recommended. Simultaneously, the system continuously compares the predicted values ​​with actual values ​​to calibrate the forecasting model parameters. When the model's mean absolute percentage error (MAPE) exceeds 25%, model retraining is automatically triggered.

[0068] Step 8: Full-Process Audit Recording. During the execution of all the above steps, the audit logger records each operation (profile generation, anomaly detection, suggestion generation, MR creation, deployment verification) as a structured audit log entry. Each log entry includes the operation timestamp, operation type, target service, operation parameters, and operation result, and is written to the Loki log aggregation system. When Loki write fails, the log is cached locally and retried upon recovery, ensuring zero audit data loss. The system supports querying the complete optimization timeline by service dimension.

[0069] (III) Six core functional components.

[0070] The technical solution of this invention includes the following six core functional components, which work together to form a complete intelligent resource optimization system: Core functional component one: Resource Profiler.

[0071] The resource profiling engine is the data foundation component of this invention, responsible for collecting container resource usage metrics from the Prometheus monitoring system and constructing service-level resource profiles. This component collects multi-dimensional data through predefined PromQL query templates, including CPU utilization (calculated based on the rate of the `container_cpu_usage_seconds_total` metric), memory usage (based on the `container_memory_working_set_bytes` metric), CPU throttling ratio (calculated based on the ratio of `container_cpu_cfs_throttled_seconds_total` to `container_cpu_cfs_periods_total`), and OOM termination events (based on the `kube_pod_container_status_last_terminated_reason` metric).

[0072] The collected raw data undergoes three-level dimensional aggregation (namespace to deployment to container) and four-level percentile statistics (P50, P95, P99, Max). Based on the time-series characteristics of the resource usage data, an AI model automatically categorizes the usage patterns of each service into four types: stable, periodic, bursty, or growing. The generated resource profiles are persistently stored in a PostgreSQL database, retaining at least 90 days of historical data. When a Prometheus query fails or returns incomplete data, the system logs an error and uses the most recently successfully collected data as a fallback solution to ensure system fault tolerance.

[0073] The architecture, training process, and parameter settings of the AI ​​model used in the aforementioned resource profiling engine are detailed below: (A) Architecture of AI classification model.

[0074] The resource usage pattern classification model of this invention adopts a hierarchical rule-based decision tree architecture based on statistical features. This architecture is chosen based on the following technical considerations: (1) Kubernetes resource management scenarios have extremely high requirements for the interpretability of classification decisions, and operations and maintenance personnel need to understand the specific basis for each classification decision; (2) The four resource usage patterns have clear separability in the statistical feature space, without the need for complex nonlinear models; (3) The inference latency of the rule-based decision tree is extremely low (microsecond level), which meets the real-time classification requirements of hundreds of services in a large-scale cluster.

[0075] The AI ​​classification model consists of three layers: a feature extraction layer, a feature normalization layer, and a hierarchical decision layer.

[0076] Feature Extraction Layer: Receives resource usage time series data after three-level dimensional aggregation and four-level percentile processing, and calculates four core statistical feature vectors F=[CV,ACF_max,β_normalized,PeakRatio]. Here, F is the feature vector, an ordered array containing four statistical features, serving as input to the classification model; CV is the coefficient of variation, measuring the fluctuation of resource usage relative to the mean; ACF_max is the larger of the daily and weekly autocorrelation coefficients, measuring the periodicity of the time series; β_normalized is the normalized trend slope, used to measure the long-term growth trend of resource usage; and PeakRatio is the peak-to-peak ratio, used to measure the deviation of extreme peaks from typical levels.

[0077] Among them, the coefficient of variation CV = σ / μ is used to measure the relative fluctuation of resource usage, and the computational complexity is O(N); the autocorrelation coefficient ACF is calculated for the daily periodic lag (lag = 288, corresponding to the number of data points in 24 hours with a 5-minute sampling step) and the weekly periodic lag (lag = 2016, corresponding to the number of data points in 7 days), and the larger value is taken, ACF_max = max(ACF(288), ACF(2016)), with a computational complexity of O(N×lag_max); the normalized trend slope β_normalized = β×N / μ is obtained by fitting the original slope β through least squares linear regression and then normalizing it, with a computational complexity of O(N).

[0078] Peak ratio (PeakRatio) = Max / P50 is calculated directly using the percentile statistics, with a computational complexity of O(1). The feature extraction layer independently calculates feature vectors for the CPU and memory resource dimensions, outputting two sets of features: F_cpu and F_mem.

[0079] Feature normalization layer: fuses feature vectors from two resource dimensions. For CV and PeakRatio, the larger value of CPU and memory is taken (max fusion) to capture significant fluctuations in either dimension; for ACF_max, the larger value of both dimensions is taken to capture periodic signals in either dimension; for β_normalized, the larger absolute value is taken while preserving the sign to capture the most significant trend direction. The fused output is a single feature vector, which serves as the input to the decision layer. F_merged=[CV_merged,ACF_merged,β_merged,PeakRatio_merged]; Wherein, F_merged is the fused feature vector (merging the features from the CPU and memory dimensions into a single vector); CV_merged is the fused coefficient of variation (taking the larger value of the coefficients of variation from the CPU and memory dimensions); ACF_merged is the fused autocorrelation coefficient (taking the larger value of the autocorrelation coefficients from the two dimensions); β_merged is the fused normalized trend slope (taking the larger absolute value from the two dimensions and retaining its positive or negative sign); PeakRatio_merged is the fused peak ratio (taking the larger value of the peak ratios from the two dimensions); the _merged suffix in each field indicates that the feature value is a comprehensive result after fusing the features from both the CPU and memory dimensions.

[0080] Hierarchical decision layer: Based on the fused feature vectors, four classification rule nodes are evaluated sequentially from highest to lowest priority, with a fixed decision tree depth of 3 layers. The first layer determines stable types (CV < 0.15 and PeakRatio < 2.0); the second layer determines growing types (β_normalized > 0.20); the third layer determines periodic types (ACF_max > 0.5); bursty types are output by default if any of the above conditions are not met. Each classification result is accompanied by a complete decision path record, including the feature values ​​and threshold comparison results of each rule node, and written to the `classification_evidence` field of the resource profile.

[0081] (B) The training process of AI classification models.

[0082] The AI ​​classification model employs a data-driven threshold optimization training method, determining the optimal threshold parameters for each classification rule node through statistical analysis of the labeled dataset. The training process consists of three stages: Phase 1 (Construction of labeled dataset): Collect at least 90 days of historical resource usage data from Prometheus of the target Kubernetes cluster, covering all namespaces and deployed containers in the cluster; perform feature extraction on the resource usage time series of each service.

[0083] Calculate the four-dimensional feature vector F=[CV,ACF_max,β_normalized,PeakRatio], and have platform engineers with Kubernetes operation and maintenance experience manually label the resource usage patterns of each service (labeling categories are stable, periodic, bursty or growing). Each service is independently labeled by at least two engineers, and a third engineer will arbitrate if the labels are inconsistent.

[0084] Construct a labeled dataset D={(F_i,y_i)}, i=1,2,...,M. It is recommended that the labeled dataset contain at least 100 service samples, and that the ratio of samples from the four categories does not exceed 5:1. Here, D is the labeled dataset (containing all labeled service samples); F_i is the four-dimensional statistical feature vector of the i-th service (i.e., [CV,ACF_max,β_normalized,PeakRatio]); y_i is the manually labeled category label of the i-th service (values ​​can be one of stable, periodic, bursty, or growing); and M is the total number of service samples in the labeled dataset.

[0085] Phase Two (Grid Search Threshold Optimization): Define the search ranges for four threshold parameters—CV threshold search range [0.05, 0.30] step size 0.01, PeakRatio threshold search range [1.5, 3.0] step size 0.1, β_normalized threshold search range [0.10, 0.40] step size 0.02, and ACF_max threshold search range [0.30, 0.70] step size 0.02.

[0086] For each threshold combination θ = [CV_th, PeakRatio_th, β_th, ACF_th] in the search space, hierarchical decision tree classification is performed on the labeled dataset, and the classification accuracy Accuracy(θ) is calculated. Here, θ is the vector of threshold parameter combinations to be optimized; CV_th is the coefficient of variation threshold; PeakRatio_th is the peak-to-peak ratio threshold; β_th is the normalized trend slope threshold; ACF_th is the autocorrelation coefficient threshold; and Accuracy(θ) is the classification accuracy of the model on the labeled dataset (i.e., the proportion of correctly classified samples out of the total number of samples) under a given threshold combination θ.

[0087] The threshold combination that maximizes accuracy is θ* = argmax_θAccuracy(θ), where argmax_θ is the operator that finds the parameter value that maximizes the objective function (i.e., the combination that achieves the highest classification accuracy among all candidate threshold combinations), and θ* is the optimal threshold parameter combination. When multiple combinations with the same accuracy exist, the combination that maximizes the minimum F1-Score for each class is prioritized (max-minF1 strategy). F1-Score is the harmonic mean of precision and recall (a comprehensive measure of classification performance for a single class, F1 = 2 × Precision × Recall / (Precision + Recall)). The max-minF1 strategy selects the combination that maximizes the lowest F1 score among the four classes to ensure a balanced distribution of classification performance across the classes.

[0088] Phase 3 (5-fold cross-validation): The labeled dataset is randomly divided into 5 subsets using stratified sampling. Each subset is used as the validation set and the rest as the training set. Threshold optimization is performed and the validation accuracy is calculated. The 5-fold average accuracy (CV_Accuracy) and standard deviation (CV_Std) are calculated.

[0089] Wherein, CV_Accuracy is the average classification accuracy of 5-fold cross-validation (i.e., the arithmetic mean of the classification accuracy in 5 validations, measuring the overall classification performance of the model); CV_Std is the standard deviation of the 5-fold cross-validation accuracy (measuring the degree of fluctuation in the model's classification performance under different data partitions; the smaller the value, the more stable the model's generalization ability). When CV_Accuracy ≥ 85% and CV_Std ≤ 5%, the model is considered to have sufficient generalization ability, and training is complete. The training results (optimal threshold θ*, cross-validation metric, and training data statistical summary) are persistently stored in JSON format in the PostgreSQL table `classification_models`.

[0090] (C) Parameter settings for AI classification models.

[0091] Default values ​​and setting basis for classification threshold parameters: CV threshold defaults to 0.15, meaning that when the standard deviation of resource usage does not exceed 15% of the mean, it is judged as low volatility. In actual production, the CV of stable services is usually between 0.03 and 0.12, while that of periodic and bursty services is usually above 0.20; PeakRatio threshold defaults to 2.0, which is used in conjunction with CV to determine stability. The peak ratio of stable services is usually between 1.1 and 1.8, while that of bursty services is usually above 3.0; β_normalized threshold defaults to 0.20, meaning that when the cumulative growth of resources within the observation window exceeds 20% of the mean, it is judged as growth. Services with rapid business growth are usually between 0.30 and 1.50, while those without growth are usually between -0.10 and 0.15; ACF_max threshold defaults to 0.5. An autocorrelation coefficient of 0.5 is the dividing point between moderate and strong correlation. Web applications with obvious periodicity are usually between 0.60 and 0.95, while services without periodicity are usually between -0.20 and 0.35.

[0092] The hierarchical classification priority is Stable > Growth > Cyclical > Emergent (default), based on the following: Stable has the strictest judgment conditions (two conditions) and the lowest risk of misjudgment; Growth has the highest business value for capacity planning; Emergent is the default classification to ensure completeness.

[0093] Model maintenance parameters: Threshold parameters are recommended to be re-optimized every quarter (90 days) based on the latest labeled data; Classification result consistency monitoring - when the classification result of a service changes more than 3 times in 7 consecutive analysis periods, an unstable classification alarm is generated.

[0094] (D) Verification of technical effectiveness (experimental data and comparative analysis).

[0095] To verify the actual technical effectiveness of the AI ​​classification model, an experiment was conducted on a production-grade Kubernetes cluster containing 312 microservices.

[0096] 1) Experimental environment and dataset.

[0097] The experimental cluster ran across three namespaces (production, pre-release, and infrastructure), comprising 312 independent services (268 stateless Deployment services and 44 stateful Set services). 90 days of CPU and memory usage data were collected using Prometheus (sampling step of 5 minutes, approximately 181,440 data points per service). After data preprocessing (IQR outlier filtering, missing value handling, and validity checks), the data quality of 289 services met the training requirements (≥100 valid data points), while 23 services were excluded due to severe data loss.

[0098] Three platform engineers with over three years of Kubernetes operation and maintenance experience manually labeled 289 services. The Cohen's Kappa coefficient among the labelers was 0.83 (approaching near-complete consistency). The labeling results were categorized as follows: stable 98 services (33.9%), cyclical 87 services (30.1%), bursty 62 services (21.5%), and growing 42 services (14.5%).

[0099] 2) Classification accuracy assessment.

[0100] Using 5-fold hierarchical cross-validation, the optimal threshold combination obtained by grid search is θ*=[CV_th=0.15,PeakRatio_th=2.0,β_th=0.20,ACF_th=0.50] (consistent with the default values, verifying the rationality of the default parameters).

[0101] Wherein, θ* (thetastar) is the optimal combination of threshold parameters that maximizes classification accuracy; CV_th is the coefficient of variation threshold (used to determine whether the fluctuation range of resource usage is low); PeakRatio_th is the peak-to-peak ratio threshold (used to determine the degree of deviation between extreme peaks and typical levels); β_th is the normalized trend slope threshold (used to determine whether resource usage shows an increasing trend); and ACF_th is the autocorrelation coefficient threshold (used to determine whether resource usage has a periodic pattern).

[0102] The average accuracy of 5-fold cross-validation was 91.7% (CV_Std = 2.3%), meeting the passing criteria of CV_Accuracy ≥ 85% and CV_Std ≤ 5%. Here, CV_Accuracy is the average classification accuracy of 5-fold cross-validation (i.e., the arithmetic mean of the proportion of samples correctly classified by the model in 5 validations); CV_Std is the standard deviation of the 5-fold cross-validation accuracy (measuring the stability of the model's classification performance under different data partitions; the smaller the value, the more stable the model's generalization ability).

[0103] Detailed metrics for each category (50% average): For the stable type, Precision = 95.8%, Recall = 93.9%, F1 = 94.8%, with misclassification mainly occurring at the boundary with the cyclical type; for the cyclical type, Precision = 89.5%, Recall = 92.0%, F1 = 90.7%, with misclassification mainly occurring at the boundary with the burst type; for the burst type, Precision = 87.1%, Recall = 85.5%, F1 = 86.3%, with relatively low precision as the default category; for the growth type, Precision = 92.9%, Recall = 92.9%, F1 = 92.9%, attributed to the high discriminative power of the trend slope feature. Among them, Precision is the proportion of samples that the model predicts to belong to a certain class but actually belong to that class, measuring the accuracy of the classification result. A higher value indicates fewer false positives. Recall is the proportion of samples that actually belong to a certain class but are correctly predicted by the model, measuring the completeness of the classification result. A higher value indicates fewer false negatives. F1 is the harmonic mean of precision and recall, a single indicator that comprehensively measures classification performance. F1 = 2 × Precision × Recall / (Precision + Recall). A higher value indicates better classification performance.

[0104] 3) Comparative analysis with alternative solutions.

[0105] The hierarchical rule-based decision tree of this invention is compared with three alternative classification schemes on the same dataset: Option 1 (K-Means unsupervised clustering, K=4): Optimal matching accuracy 72.3%. K-Means is an unsupervised clustering algorithm based on distance metrics that automatically divides data into K clusters. K=4 indicates that services are clustered into 4 categories, corresponding to four resource usage patterns. The main drawback is that the clustering results are sensitive to the initial centroids and cannot guarantee a one-to-one correspondence between clusters and the four predefined pattern types.

[0106] Option 2 (Random Forest Classifier, n_estimators=100, max_depth=5): The average accuracy of 5-fold cross-validation is 93.4%, which is 1.7 percentage points higher than the present invention; however, the time taken for a single inference is 2.1 milliseconds, which is about 20 times longer than the <0.1 milliseconds of the present invention, and the classification decision is not interpretable. Here, n_estimators=100 indicates that the random forest contains 100 decision trees, and max_depth=5 indicates that the maximum depth of each decision tree is limited to 5 layers to control model complexity and prevent overfitting.

[0107] Option 3 (Support Vector Machine (SVM), RBF kernel, C=1.0): The average accuracy of 5-fold cross-validation is 92.1%, which is 0.4 percentage points higher than the present invention; the time per inference is 0.8 milliseconds, and it also lacks decision interpretability. Here, the RBF kernel is a radial basis function kernel, a kernel function that maps data to a high-dimensional space to achieve non-linear classification. C=1.0 is a regularization parameter used to control the penalty for classification errors; the larger the C value, the stricter the penalty for misclassification, and the more the model tends to fit the training data.

[0108] Comparative Conclusion: The hierarchical rule-based decision tree of this invention achieves classification accuracy within 2 percentage points compared to random forests and SVMs (91.7% vs 93.4% / 92.1%), but exhibits significant advantages in inference speed (more than 20 times faster) and decision interpretability (complete decision path traceability). Considering the rigid requirements for interpretability and real-time performance in Kubernetes resource management scenarios, the hierarchical rule-based decision tree is the optimal architecture choice.

[0109] 4) Verification of the impact of classification results on downstream optimization effects.

[0110] To verify the actual impact of classification results on the quality of optimization suggestions generated by the optimization proposer, a comparative experiment was set up: the experimental group adopted differentiated safety margin coefficients for different service modes based on the classification results (1.2 times for stable type, 1.5 times for burst / growth type, etc.); the control group uniformly adopted a safety margin coefficient of P99×1.35 for all services (without distinguishing between modes).

[0111] The comparison results across 289 services showed that the experimental group achieved an average resource request reduction of 34.2%, while the control group achieved 28.7%. The experimental group saved 5.5 percentage points more, primarily due to a more aggressive security margin applied to stable services. Regarding security, the experimental group had an OOM (Out of Memory) event rate of 0.3% (1 / 289) during the 30-day observation period after optimization, compared to 0.7% (2 / 289) in the control group. The lower OOM rate in the experimental group was attributed to a more conservative strategy for bursty and rapidly growing services.

[0112] Overall assessment: By accurately identifying the resource usage patterns of services, the AI ​​classification model enables the optimization suggestionr to achieve a higher resource saving rate without compromising security, thus verifying the positive contribution of pattern classification to the optimization effect.

[0113] Core functional component two: Anomaly Detector.

[0114] The anomaly detector is responsible for identifying two types of abnormal states based on resource profile data: resource waste and resource insufficiency. This component implements the following four detection capabilities: (1) Waste Score Calculation: The waste score (Waste_Score) is calculated by comparing the resource request configuration of the service with the actual usage. The calculation formula is as follows: waste_cpu=(cpu_request-cpu_p95) / cpu_request×100; waste_mem=(mem_request-mem_p95) / mem_request×100; The total score is a weighted average of CPU and memory waste scores (each accounting for 50%). Specifically, `waste_cpu` represents the percentage of resource waste in the CPU dimension; `cpu_request` is the current CPU resource request configuration value, in units of CPU cores; `cpu_p95` is the 95th percentile of CPU usage; `waste_mem` represents the percentage of resource waste in the memory dimension; `mem_request` is the current memory resource request configuration value (in bytes); and `mem_p95` is the 95th percentile of memory usage. When `Waste_Score` exceeds the threshold of 60, the service is marked as "wasting resources," and an alert containing quantitative waste data is generated.

[0115] (2) Risk score calculation: The risk score (Risk_Score) is calculated by combining three risk factors: OOM event factor = min(oom_count_7d×15,40); maximum contribution of 40 points; CPU throttling factor = min(throttle_ratio×200,30); maximum contribution of 30 points; insufficient margin factor = max(0,(p99 / limit-0.7))×100; maximum contribution of 30 points.

[0116] Here, `oom_count_7d` represents the cumulative number of OOM (Out of Memory) events that occurred in the service within the past 7 days; 15 is the weight of each OOM event; the `min` function takes the smaller of the two parameters (used to set the upper limit of the factor score); `throttle_ratio` is the CPU throttling ratio (i.e., the ratio of time throttled by the CFS scheduler to the total scheduling cycle time, ranging from 0.0 to 1.0); 200 is the amplification factor; `p99` is the 99th percentile of resource usage; `limit` is the current resource limit configuration value; 0.7 is the margin safety threshold, i.e., scoring starts when P99 usage exceeds 70% of the limit value; the `max` function takes the larger of the two parameters to ensure that the score is not negative. When `Risk_Score` exceeds the threshold of 70, a high-priority alarm is generated and pushed to the Grafana alarm channel.

[0117] (3) Pattern drift detection: The resource usage value of the current resource profile is compared with the historical profile sequence. When the current value deviates from the historical average by more than 2 standard deviations, a pattern drift alarm is generated and the profile reconstruction process is triggered.

[0118] (4) Resource contention pattern identification: During each detection period, the resource usage correlation of all services under the same namespace is evaluated simultaneously to identify the resource contention pattern between services.

[0119] Core functional component three: Optimization Advisor.

[0120] The optimization recommender is responsible for generating specific resource configuration optimization suggestions for each anomalous service based on resource profiling and anomaly detection results. This component implements the following core functions: (1) Differentiated security margin strategy: Different security margin coefficients are adopted according to the workload type of the service. For stateless services (Deployment), the recommended resource request value is no less than 1.2 times the P99 resource usage of the service; for stateful services (Stateful Set), considering the higher risk characteristics of persistent data and state maintenance, the recommended value is no less than 1.5 times the P99 resource usage.

[0121] (2) Namespace quota coordination optimization: When there are multiple services that need to be optimized under the same namespace, the system comprehensively considers the resource quota constraints of the namespace and coordinates the optimization suggestions of multiple services to ensure that the total resource requests of all suggestions do not exceed the quota limit.

[0122] (3) Cost estimation: Calculate the estimated monthly cost savings for each optimization suggestion, enabling the operations team to quantify and evaluate the economic benefits of the optimization.

[0123] (4) Risk assessment and rollback plan: Assess the risk level (low / medium / high) for each optimization suggestion. When the risk level is high, attach a detailed rollback plan and the threshold of indicators that need to be monitored to ensure the safe execution of subsequent tasks.

[0124] Core functional component four: MR Generator and Deploy Verifier.

[0125] The MR generator is responsible for converting optimization suggestions into GitLab Merge Requests, enabling seamless integration of optimization suggestions with the GitOps workflow; the Deploy Verifier is responsible for monitoring deployment status and verifying optimization effects. These components implement the following core functionalities: (1) YAML Patch Generation: Automatically generate change patches for the resources.requests and resources.limits fields in the Deployment YAML configuration file based on optimization suggestions, ensuring that the configuration values ​​after the patch is applied are exactly consistent with the suggested values.

[0126] (2) Risk-aware MR creation strategy: Differentiated MR creation strategies are adopted according to the risk level of the optimization suggestion. Low-risk suggestions automatically create ordinary Merge Requests, and the MR description includes complete optimization basis, comparison between current configuration and suggested configuration, estimated savings amount and risk assessment information; medium-risk and high-risk suggestions create Draft Merge Requests, and the MR description clearly indicates that manual review is required. High-risk MRs also include rollback plans.

[0127] (3) Deployment monitoring: After MR is merged, the deployment progress of configuration changes is continuously monitored through ArgoCD's synchronization status API, and the deployment status changes are recorded.

[0128] (4) Optimization effect verification: Within 24 hours after deployment, compare the resource usage data (percentage change in CPU and memory usage) and service operation indicators (percentage change in error rate and latency) before and after deployment, and generate an optimization effect verification report.

[0129] (5) Automatic rollback: When the verification report shows that the service is abnormal (error rate increases by more than 5% or latency increases by more than 20%), an automatic rollback MR is created to restore the original resource configuration and an alarm notification is sent.

[0130] Core functional component five: Capacity Predictor.

[0131] The capacity forecaster is responsible for predicting future resource demand based on historical resource profile data, enabling forward-looking capacity planning. This component implements the following core functions: (1) Time series decomposition: Historical resource usage data is decomposed into three components: periodic components (daily cycle, weekly cycle), long-term trend components, and residual components, effectively separating the interference of periodic fluctuations on trend judgment.

[0132] (2) Multi-time window forecast: Based on the extrapolation of trend components, resource demand forecasts for three time windows of the next 30 days, 60 days and 90 days are generated.

[0133] (3) Confidence interval calculation: Provide two levels of confidence intervals, 80% and 95%, for each prediction to quantify the uncertainty of the prediction result. The 95% confidence interval contains the 80% confidence interval, and the 80% confidence interval contains the point prediction value.

[0134] (4) Capacity warning: When the prediction results show that the resource usage of a namespace will exceed 80% of the current quota in the next 30 days, a capacity warning will be automatically generated and an expansion plan will be recommended.

[0135] (5) Model self-calibration: When new actual data arrives, the predicted value is automatically compared with the actual value, and the prediction model parameters are continuously calibrated. When the mean absolute percentage error (MAPE) of the model exceeds 25%, the model retraining process is automatically triggered and the operation and maintenance personnel are notified.

[0136] Core functional component six: Audit Logger.

[0137] The audit logger is responsible for recording structured audit logs of all system optimization operations, ensuring traceability and auditability throughout the entire process. This component implements the following core functions: (1) Structured audit logs: Each operation performed by the system (profile generation, anomaly detection, suggestion generation, MR creation, deployment verification) is recorded as a structured audit log entry. Each log entry contains five necessary fields: operation timestamp, operation type, target service identifier, operation parameters, and operation result. These are written to the Loki log aggregation system.

[0138] (2) Service optimization timeline query: Supports querying the complete optimization timeline by service dimension, returning all optimization operation records of the service, sorted in ascending order by timestamp, including the suggested content, execution results and effect verification data of each optimization.

[0139] (3) Log writing fault tolerance: When Loki log writing fails, the log is cached to local storage and automatically retried after the Loki service recovers, ensuring zero loss of audit data.

[0140] The technical solution of this invention will be described in detail with reference to the specific algorithm and each core functional component.

[0141] Figure 6 The complete flowchart for building the resource profiling engine demonstrates the end-to-end processing flow from CronJob scheduled triggering to persistent storage of resource profiles, including seven core steps: data collection, IQR outlier filtering, three-level dimension aggregation, four-level percentile statistics, statistical feature extraction, AI pattern classification, and profile storage.

[0142] The technical solution for the resource profiling engine is as follows: The Resource Profiler is the core data infrastructure component of this invention. It is responsible for collecting container resource usage metrics from the Prometheus monitoring system, constructing multi-dimensional aggregated statistical features, and intelligently classifying service resource usage patterns using artificial intelligence algorithms. The technological innovation of this component lies in: elevating traditional single-dimensional resource monitoring to multi-dimensional, multi-layered structured resource profiling; and introducing machine learning classification methods based on statistical features to achieve deep pattern recognition and automatic classification of service resource usage behavior.

[0143] The resource profiling engine workflow consists of four core stages: data collection (collect_metrics), multi-dimensional aggregation (aggregate_metrics), pattern classification (classify_pattern), and profile building (build_profile).

[0144] Each stage is executed sequentially, ultimately outputting a structured service resource profile, which serves as the data foundation for subsequent steps such as anomaly detection, optimization suggestion generation, and capacity prediction.

[0145] I. Data collection methods are as follows: (a) PromQL query strategy.

[0146] The resource profiling engine initiates data query requests to the Prometheus monitoring system using predefined PromQL (Prometheus Query Language) query templates, collecting multi-dimensional resource usage metrics for all containers in the cluster over the past 7 days (default time window, configurable). This invention designs PromQL query templates for four core metrics: CPU utilization is collected based on the `container_cpu_usage_seconds_total` counter metric, using a rate function to calculate CPU consumption per unit time. The query template is `rate(container_cpu_usage_seconds_total{namespace=~"$ns"}[5m])`. Here, `rate()` is a built-in Prometheus rate calculation function used to calculate the average growth rate per second of a counter-type metric within a specified time window; `container_cpu_usage_seconds_total` is the total cumulative CPU usage time of the container, in seconds, and is a counter that only increments, recording the total CPU time consumed by the container since startup; `namespace` is a Kubernetes namespace label used to filter containers by namespace; `$ns` is a regular expression variable for the namespace name, supporting wildcard matching, used to dynamically specify the target namespace range for the query; `[5m]` is a 5-minute time window range selector, specifying the length of the backtracking time window used by the `rate()` function to calculate the rate. The `rate()` function calculates the average growth rate of the counter within the 5-minute window, and the return value is in the number of CPU cores. The 5-minute rate calculation window achieves the optimal balance between data smoothness and timeliness.

[0147] Memory usage is collected based on the `container_memory_working_set_bytes` metric. `container_memory_working_set_bytes` is the container's working set of bytes (i.e., the amount of memory currently actively used by the container, measured in bytes, reflecting the actual amount of memory occupied by the container that cannot be reclaimed by the operating system). This metric excludes reclaimable cache and buffer memory. `working_set_bytes` is chosen instead of `usage_bytes` because the latter includes kernel-reclaimable page cache, which could lead to an overestimation of memory usage. `working_set_bytes` is the same memory metric used by Kubernetes' OOM (Out of Memory) determination mechanism.

[0148] CPU throttling ratio acquisition: The ratio of throttled time in the CFS scheduler to the total scheduling cycle time is calculated using rate(container_cpu_cfs_throttled_seconds_total[5m]) / rate(container_cpu_cfs_periods_total[5m]), resulting in a throttling ratio value between 0.0 and 1.0. Here, container_cpu_cfs_throttled_seconds_total is the cumulative total time the container's CPU is throttled by the CFS scheduler, in seconds, recording the total time the container is forcibly suspended due to exceeding its CPU quota; container_cpu_cfs_periods_total is the cumulative total time of the container's CPU and CFS scheduling cycles, in seconds, recording the total scheduling cycle time allocated to the container by the CFS scheduler. The ratio of these two rates is the CPU throttling ratio.

[0149] OOMKilled event collection: Based on the kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} metric, the cumulative number of OOMKilled events that occurred for each service in the past 7 days is counted.

[0150] Among them, kube_pod_container_status_last_terminated_reason is the indicator of the most recent termination reason of the Pod container, which is exposed by the kube-state-metrics component and records the reason label of the most recent abnormal termination of the container; reason="OOMKilled" is a filter condition, which means that only container events that are forcibly terminated by the Linux kernel OOMKiller due to memory overflow (Out of Memory) are selected.

[0151] (ii) Data acquisition time window and sampling strategy.

[0152] This invention uses 7 days as the default data collection time window. This choice is based on the following considerations: covering the complete weekly cycle (weekdays + weekends); generating approximately 2,016 data points with a 5-minute sampling step size to meet percentile calculation requirements; and ensuring that the profile data reflects the recent resource usage status of the service.

[0153] (iii) Fault tolerance and degradation mechanism for data acquisition.

[0154] To address scenarios where Prometheus queries may fail, this invention designs a robust fault-tolerance mechanism: Scenario 1 (Query completely fails): Record structured error logs, read the most recently successfully collected data from PostgreSQL as the degraded data source, and mark the data source as degraded data in the profile.

[0155] Scenario 2 (Returning Incomplete Data): For short holes (<1 hour), linear interpolation is used to fill them; for long holes (≥1 hour), they are marked as unavailable and calculations are performed only based on valid data segments.

[0156] Scenario 3 (Insufficient Data Points): When there are fewer than 100 valid data points, skip the profile generation for this service and record a warning log.

[0157] II. The multi-dimensional aggregation algorithm is as follows: (a) Three-dimensional aggregation system.

[0158] This invention designs a three-level dimensional aggregation system from namespace to deployment to container: Level 1 (Namespace Dimension): Aggregates resource usage data for all containers within the same namespace for namespace-level resource quota assessment and capacity alerts.

[0159] The second level (deployment dimension) aggregates data from containers with the same name in all Pods of the same deployment, eliminating fluctuations caused by changes in the number of Pod replicas. It is the main input for anomaly detection and optimization suggestion generation.

[0160] The third level (container dimension): statistical aggregation of time-series data for a single container, directly corresponding to the resource configuration fields in the Deployment YAML.

[0161] Each service's resource profile is uniquely identified by the namespace / deployment / container triple (service_id).

[0162] (ii) Four-level percentile statistical algorithm.

[0163] For each aggregation dimension, calculate the percentile statistics at four levels: P50 (Median): Reflects the typical level of service resource usage. P95 (95th Percentile): Reflects the upper limit of resource usage for the vast majority of the time; it is the core input for waste scoring calculations. P99 (99th Percentile): Reflects the upper limit of resource usage for almost all of the time; it is the core benchmark value for generating optimization suggestions. Max (Maximum Value): Reflects extreme peak values; used to assess the reasonableness of resource constraints.

[0164] The fourth percentile statistics must satisfy the invariant constraint: P50≤P95≤P99≤Max.

[0165] (iii) Outlier filtering mechanism.

[0166] The interquartile range (IQR) method is used to filter extreme outliers: Q1 and Q3 are calculated to determine the outlier boundaries (Q1 - 1.5 × IQR to Q3 + 1.5 × IQR). Data points exceeding these boundaries are removed before calculating the percentile statistics. Here, Q1 is the first quartile (i.e., the 25th percentile, representing 25% of the data points below this value), Q3 is the third quartile (i.e., the 75th percentile, representing 75% of the data points below this value), IQR is the interquartile range (i.e., Q3 - Q1, measuring the middle 50% of the data distribution), and 1.5 is the multiplier for outlier detection. The IQR method does not rely on the normality assumption and is suitable for the right-skewed distribution characteristics of resource usage data.

[0167] III. The classification method for AI usage patterns is as follows: (a) Classification system.

[0168] This invention categorizes service resource usage behavior into four typical patterns: Stable: Resource usage remains relatively constant with minimal fluctuations. Typical scenarios: configuration services, caching proxies, etc. Periodic: Exhibits a clear daily or weekly cyclical fluctuation pattern. Typical scenarios: user-facing web applications, API gateways, etc. Bursty: Remains at a low level most of the time, with occasional short-term spikes. Typical scenarios: batch processing tasks, event-driven services, etc. Growing: Shows a continuous upward trend. Typical scenarios: data storage services, services whose load increases with user growth, etc.

[0169] (ii) Statistical feature extraction.

[0170] Four core statistical features were extracted from the aggregated resource usage time series: 1. Coefficient of variation (CV) = σ / μ, where CV is the coefficient of variation, which measures the fluctuation of resource usage relative to the mean and is dimensionless; σ is the sample standard deviation of the resource usage time series, which measures the dispersion of the data; and μ is the arithmetic mean of the resource usage time series.

[0171] 2. Autocorrelation Coefficient (ACF): Calculate the autocorrelation coefficient for daily lag (lag=288, corresponding to the number of data points in 24 hours with a 5-minute sampling step) and weekly lag (lag=2016, corresponding to the number of data points in 7 days), and take the larger value, ACF_max. Here, ACF is the autocorrelation coefficient, measuring the degree of correlation between a time series and itself at a specific time lag, with a value ranging from -1 to 1. lag represents the time lag (number of data points), and ACF_max is the larger value of the autocorrelation coefficient for both daily and weekly lags.

[0172] 3. Normalized trend slope β_normalized = β × N / μ, where β_normalized is the normalized trend slope, representing the cumulative change in resource usage relative to the mean over the entire observation window, and is dimensionless; β is the original trend slope obtained by least squares linear regression fitting, in units of resource usage / time step; N is the total number of data points in the time series; and μ is the arithmetic mean of resource usage.

[0173] 4. Peak Ratio = Max / P50, where Peak Ratio is the peak ratio, which measures the deviation of extreme peak values ​​from typical usage levels and is dimensionless; Max is the maximum value of resource usage; and P50 is the 50th percentile of resource usage (i.e., the median, representing typical usage levels).

[0174] (III) Classification and Judgment Logic.

[0175] Classification based on hierarchical decision rules: First priority (stable): CV < 0.15 and PeakRatio < 2.0. Where CV is the coefficient of variation (relative fluctuation of resource usage), 0.15 is the fluctuation threshold; PeakRatio is the peak ratio (ratio of extreme peak to typical level), and 2.0 is the peak deviation threshold.

[0176] Second priority (growth-oriented): β_normalized > 0.20. Where β_normalized is the slope of the normalization trend (the cumulative change in resource usage relative to the mean within the observation window), and 0.20 indicates that the cumulative growth exceeds 20% of the mean.

[0177] Third priority (periodic): ACF_max > 0.5. Here, ACF_max is the larger of the daily and weekly autocorrelation coefficients, and 0.5 is the threshold for moderate to strong correlation. All of these threshold parameters can be adjusted through system configuration.

[0178] IV. Resource Profiling Data Model.

[0179] The core fields of ResourceProfile include: service_id (unique service identifier), namespace, deployment, container, current_config (current resource configuration), usage_stats (percentile statistics), pattern (usage pattern classification results), oom_count_7d (number of OOM events), throttle_ratio (CPU throttling ratio), collected_at (collection time), and profile_version (version number).

[0180] The profile data is persistently stored in PostgreSQL, retaining at least 90 days of historical data, and supports version management and index-optimized queries.

[0181] Figure 7 The complete flowchart for anomaly detection and optimization suggestion generation includes four detection capabilities: waste score calculation (Waste_Score), risk score calculation (Risk_Score), pattern drift detection, and resource contention pattern recognition, as well as optimization suggestion generation logic such as differentiated safety margin strategy, namespace quota coordination, and risk level assessment.

[0182] The anomaly detection technology solution is as follows: The Anomaly Detector is the core analysis component of this invention, responsible for identifying two types of anomalies—resource waste and resource insufficiency—based on resource profile data, detecting resource usage pattern drift, and identifying namespace-level resource contention patterns. This component constructs a multi-dimensional, multi-level quantitative anomaly assessment system, using two composite indicators—Waste Score and Risk Score—to accurately quantify the resource status of services.

[0183] I. Waste Score Calculation Method: Waste scoring is used to quantify the deviation between the resource request configuration and the actual resource usage of a service. P95 is chosen as a representative value for actual usage, which eliminates the interference of extreme peaks and avoids the risk of underestimation caused by using the average.

[0184] The calculation formula is as follows: waste_cpu=max(0,(cpu_request-cpu_p95) / cpu_request×100); waste_mem=max(0,(mem_request-mem_p95) / mem_request×100); waste_score=0.5×waste_cpu+0.5×waste_mem; Wherein, waste_cpu is the percentage of wasted CPU resources; cpu_request is the current CPU resource request configuration value (in CPU cores); cpu_p95 is the 95th percentile of CPU usage (i.e., CPU usage does not exceed this value 95% of the time); waste_mem is the percentage of wasted memory resources; mem_request is the current memory resource request configuration value (in bytes); mem_p95 is the 95th percentile of memory usage; waste_score is the overall waste score; the max function takes the larger of the two parameters (ensuring that the percentage of wasted resources does not become negative); 0.5 is the equal weighting coefficient for both CPU and memory dimensions.

[0185] The value range is [0, 100]. The service is marked as wasted if and only if waste_score > 60.

[0186] II. Risk Score Calculation Method: Risk scoring is used to quantify the degree of operational risk faced by a service due to insufficient resource allocation, based on a three-factor weighted composite risk assessment model: Factor 1 (OOM Event Factor): oom_factor = min(oom_count_7d × 15, 40), where oom_factor is the OOM event risk factor score, oom_count_7d is the cumulative number of OOMMKilled (out-of-memory termination) events that occurred in the service within the past 7 days, 15 is the weight of each OOM event, and the min function takes the smaller of the two parameters. The maximum contribution is 40 points. OOMMKilled is the most severe resource shortage signal, therefore it is given the highest weight.

[0187] Factor 2 (CPU Throttling Factor): throttle_factor = min(throttle_ratio × 200, 30), where throttle_factor is the CPU throttle risk factor score, throttle_ratio is the CPU throttle ratio (i.e., the ratio of time throttled by the CFS scheduler to the total scheduling cycle time, ranging from 0.0 to 1.0), 200 is the amplification factor, and the min function takes the smaller of the two parameters. The maximum contribution is 30 points. A 200-fold amplification factor ensures that a throttle ratio of 15% achieves the full score.

[0188] Factor 3 (Insufficient Resource Margin Factor): headroom_factor = min(max(0,(p99 / limit-0.7))×100,30), where headroom_factor is the resource margin insufficient risk factor score, p99 is the 99th percentile of resource usage, limit is the current resource limit configuration value, and 0.7 is the margin safety threshold (i.e., scoring starts when P99 usage exceeds 70% of the limit value). The max function ensures that the score is not negative, and the min function limits the maximum score to 30 points. Calculate the CPU and memory dimensions separately, and take the larger value.

[0189] The overall risk score is calculated as risk_score = oom_factor + throttle_factor + headroom_factor, where risk_score is the overall risk score (the sum of the scores of the three factors) and its value ranges from [0, 100]. A high-priority alarm is generated if and only if risk_score > 70.

[0190] III. Mode drift detection method: A statistical detection method based on standard deviation (Z-Score method) is used: Step 1: Extract CPU P95 and memory P95 usage sequences from the historical image sequence.

[0191] Step 2: Calculate the historical mean μ, which is the arithmetic mean of resource usage in the historical profile sequence and the sample standard deviation σ, which is a measure of the dispersion of resource usage in the historical profile sequence.

[0192] Step 3: Calculate the Z-Score of the current value = |current-μ| / σ, where Z-Score is the standardized deviation value, which measures the degree to which the current value deviates from the historical mean, in standard deviation; current is the resource usage value in the latest profile; μ is the historical mean; σ is the standard deviation of the historical samples; || indicates taking the absolute value.

[0193] Step 4: When the Z-Score of either the CPU or memory dimension is greater than 2, it is determined that a mode drift has occurred.

[0194] Boundary condition handling: Skip detection when there are fewer than 3 historical images; set a minimum threshold σ_min=0.01×μ when the historical standard deviation is extremely small to avoid oversensitivity, where σ_min is the minimum protection threshold for the standard deviation and μ is the historical mean.

[0195] A drift alarm triggers a profile reconstruction process to ensure that subsequent analysis is based on the latest resource usage patterns.

[0196] IV. Namespace-level resource contention pattern identification: By analyzing the resource usage correlation of all services under the same namespace, service combinations with resource competition can be identified: Step 1: Construct a time series matrix of resource usage between services.

[0197] Step 2: Calculate the Pearson correlation coefficient between service pairs.

[0198] Step 3: When r_cpu > 0.7 or r_mem > 0.7, a resource contention is determined. Here, r_cpu is the Pearson correlation coefficient of the CPU usage time series between the two services (ranging from -1 to 1; the closer the value is to 1, the more consistent the CPU usage trends of the two services), and r_mem is the Pearson correlation coefficient of the memory usage time series between the two services.

[0199] Step 4: Assess the severity of competition using peak overlap rate and quota pressure index.

[0200] The proposed optimization solution is as follows: The Optimization Advisor is the core decision-making component of this invention. It is responsible for generating specific resource configuration optimization suggestions for each abnormal service based on resource profile data and anomaly detection results, coordinating multi-service optimization schemes under namespace resource quota constraints, estimating optimization cost-benefit, and assessing optimization risk level.

[0201] I. Requests / Limits Adjustment Algorithm Based on User Profile: This invention uses the P99 statistical value in the resource profile as a benchmark and applies differentiated safety margin coefficients based on the service's workload type. P99 is chosen instead of P95 or Max as the benchmark because P99 retains coverage of high-load scenarios while excluding extreme outliers.

[0202] Differentiated safety margin strategy: Stateless Service (Deployment): Safety margin coefficient 1.2, i.e., recommended_request ≥ P99 × 1.2. Where recommended_request is the optimized resource request value, and P99 is the 99th percentile of the service's resource usage. A 20% buffer is sufficient to cover the short transition period before the HPA extension takes effect.

[0203] StatefulSet: The safety margin coefficient is increased to 1.5, indicating that recommended_request ≥ P99 × 1.5. Here, recommended_request is the optimized resource request value, and P99 is the 99th percentile of the service's resource usage. A 50% buffer ensures that the stateful set still has sufficient resources under extreme loads, avoiding data security risks.

[0204] Resource limit calculation strategy: recommended_limit = recommended_request × limit_ratio, where recommended_limit is the optimized resource limit value, recommended_request is the optimized resource request value, and limit_ratio is the ratio coefficient between the resource limit and the request. For stateless services, CPU limit_ratio is 2.0 and memory limit_ratio is 1.5; for stateful services, CPU limit_ratio is 1.5 and memory limit_ratio is 1.2.

[0205] Lower bound protection mechanism: recommended_request = max(calculated_request, P99 × safety_factor), where recommended_request is the final output optimized resource request value, calculated_request is the initial recommended value calculated by the conventional algorithm, P99 is the 99th percentile of the service's resource usage, and safety_factor is the safety margin coefficient (1.2 for stateless services and 1.5 for stateful services). The max function takes the larger of the two parameters. This mechanism ensures that the recommended value is never lower than the safety lower bound.

[0206] II. Coordination Optimization Algorithm under Namespace Quota Constraints: When there are multiple services that need optimization under the same namespace, the total number of all suggested resource requests must not exceed the resource quota limit of the namespace.

[0207] Algorithm steps: Step 1: Generate initial optimization suggestions independently for each abnormal service.

[0208] Step 2: Calculate the sum of all suggested resource requests and the sum of current requests for unoptimized services.

[0209] Step 3: If the total exceeds the quota, prune suggestions from low to high priority. The priority scoring formula is priority_score = 0.5 × risk_score + 0.3 × waste_score + 0.2 × savings_score, where priority_score is the optimization priority score of the service, and the higher the value, the higher the optimization priority of the service. Suggestions for high-scoring services will be retained first during pruning. risk_score is the risk score of the service, measuring the severity of resource shortage risk. waste_score is the waste score of the service, measuring the severity of resource waste. savings_score is the estimated cost saving score of the service optimization suggestion, measuring the economic benefits of optimization. 0.5, 0.3, and 0.2 are the weight coefficients of the three scoring dimensions, respectively.

[0210] Step 4: During the trimming process, ensure that each suggestion still meets the lower safety limit constraint of P99×safety_factor.

[0211] III. Cost Savings Estimate: The estimated monthly cost savings for each optimization suggestion are calculated as follows: cpu_savings=(current_cpu_request-recommended_cpu_request)×cpu_cost_per_core_month; memory_savings=(current_mem_request-recommended_mem_request)×mem_cost_per_gb_month; total_savings=cpu_savings+memory_savings.

[0212] Among them, cpu_savings is the monthly cost savings in terms of CPU; current_cpu_request is the current CPU resource request configuration value (in terms of CPU cores); recommended_cpu_request is the recommended CPU resource request value (in terms of CPU cores); cpu_cost_per_core_month is the monthly cost per CPU core; memory_savings is the monthly cost savings in terms of memory; current_mem_request is the current memory resource request configuration value (in terms of GB); recommended_mem_request is the recommended memory resource request value (in terms of GB); mem_cost_per_gb_month is the monthly cost per GB of memory; and total_savings is the total monthly cost savings in terms of both CPU and memory.

[0213] IV. Risk Level Assessment: The comprehensive risk score (risk_composite) is calculated by multiplying four dimensions: Resource adjustment factor: Take the larger adjustment factor between CPU and memory.

[0214] Workload type factor: 1.0 for Deployment and 1.5 for StatefulSet.

[0215] Historical anomaly factor: 1.5 if there was an OOM or a throttling rate >10% in the past 7 days, otherwise 1.0.

[0216] Pattern stability factor: Stable 0.8, Cyclical 1.0, Growth 1.2, Burst 1.3.

[0217] Risk level assessment: risk_composite < 0.5 is low risk, 0.5 ≤ risk_composite < 1.0 is medium risk, and risk_composite ≥ 1.0 is high risk. For high-risk cases, it is recommended to automatically generate a rollback plan that includes rollback configuration, triggering conditions, and execution steps.

[0218] Figure 8 The complete flowchart for GitOps closed-loop optimization shows the end-to-end closed-loop process of YAML patch generation (including Round-Trip verification), risk-aware MR creation (three-level differentiated strategies: low / medium / high), CI inspection and audit, ArgoCD deployment monitoring, 24-hour effect verification, and automatic rollback.

[0219] The GitOps closed-loop optimization technical solution is as follows: The MR Generator is the core execution component of this invention. It is responsible for converting optimization suggestions into GitLab Merge Requests, adopting differentiated MR submission strategies based on risk levels, monitoring deployment progress via ArgoCD, verifying optimization effects, and automatically creating rollback MRs when service anomalies are detected. This component constructs a closed-loop GitOps optimization system that integrates precise generation via YAMLPatch, automated submission strategies with risk awareness, declarative deployment monitoring based on ArgoCD, quantitative effect verification, and intelligent automatic rollback.

[0220] I. YAMLPatch Generation Algorithm: The YAMLPatch generation algorithm precisely translates the recommended_config in the optimization suggestions into change patches for the resources.requests and resources.limits fields in the DeploymentYAML configuration file.

[0221] Generation process: Step 1: Locate the target Deployment YAML file in the GitOps repository based on the service_id.

[0222] Step 2: Use a YAML parser that preserves comments and formatting to read and parse the file structure.

[0223] Step 3: Locate the resources configuration node of the target container along the spec.template.spec.containers path.

[0224] Step 4: Convert the suggested resource configuration values ​​to the Kubernetes standard format (CPU in millicores, memory in Mi units).

[0225] Step 5: Write the changed values ​​to the resource configuration node.

[0226] Step 6: Serialize the output, preserving the original file's comments, blank lines, and indentation style.

[0227] Round-Trip correctness guarantee: After generation, the verification process from application to parsing to comparison is automatically executed to ensure that the resource configuration values ​​obtained after the YAML Patch is applied are exactly consistent with the recommended configuration values.

[0228] II. Risk Perception-Based MR Submission Strategy: Differentiated MR creation methods will be adopted based on the risk level recommended in the optimization: Low Risk (LOW): Automatically creates a MergeRequest in normal status. The MR description includes complete optimization basis, configuration change comparison, estimated savings, and risk assessment information. Medium Risk (MEDIUM): Creates a MergeRequest in Draft status, marked as requiring manual review, and automatically assigns a reviewer. High Risk (HIGH): Creates a MergeRequest in Draft status, with a complete rollback plan including rollback target configuration, rollback trigger conditions, rollback execution steps, and monitoring observation period. It requires approval from at least two reviewers before merging.

[0229] When a GitLabAPI call fails, it will be retried according to the exponential backoff strategy, with a maximum of 3 retries. The retry interval is base_interval×2^(n-1)+random_jitter.

[0230] III. Deployment Status Monitoring: After the MapReduce merge, the deployment progress of configuration changes is continuously monitored via ArgoCD's synchronization status API. Monitoring process: Step 1: Detect MR merging events.

[0231] Step 2: Query the synchronization status of the target application using the ArgoCDApplicationAPI.

[0232] Step 3: Wait for the synchronization status to change from OutOfSync to Synced, and record the synchronization time.

[0233] Step 4: Confirm the Pod's health status (Running and Ready).

[0234] IV. Optimization Effect Verification: During the 24-hour observation window after deployment, compare resource usage data and service performance metrics before and after deployment: change_percent=(after_value-before_value) / before_value×100; Here, change_percent is the percentage change, with positive values ​​indicating an increase in the metric and negative values ​​indicating a decrease in the metric. after_value is the metric value collected in the observation window after deployment, such as CPU usage, memory usage, error rate, or latency. before_value is the baseline value of the metric before deployment.

[0235] Generate an optimization effect verification report, which includes quantitative data in four dimensions: changes in CPU usage, changes in memory usage, changes in error rate, and changes in latency.

[0236] V. Automatic rollback mechanism: The optimization is deemed to have failed and a rollback is automatically triggered when any of the following abnormal conditions are met: (a) the error rate increases by more than 5% (error_rate_change_percent>5); (b) the latency increases by more than 20% (latency_change_percent>20).

[0237] Rollback execution process: Extract the original YAML configuration before optimization from the original optimized MR record; create a rollback branch in the GitOps repository and commit the original configuration; create a normal state rollback MR to ensure rapid merging; send rollback alert notifications to the operations team.

[0238] After rolling back the MR merge deployment, restart the 24-hour verification process to confirm whether the rollback has successfully restored the service to normal operation.

[0239] Figure 9 This is a complete flowchart of the capacity prediction algorithm, comprising five core stages. Stage one is time series decomposition, employing an additive model X(t) = P(t) + T(t) + R(t), where X(t) is the original resource usage observation at time point t, P(t) is the periodic component, reflecting the regular fluctuations in resource usage over daily or weekly periods, T(t) is the trend component, reflecting the long-term direction and rate of change in resource usage, R(t) is the residual component, the random fluctuations remaining after removing periodicity and trend, and t is the time index. This additive model assumes that the original time series can be decomposed into the arithmetic sum of these three independent components. The trend component is extracted using a 7-day central moving average, the periodic component is extracted using a periodic averaging method (using a weekly cycle for data ≥14 days, otherwise downgrading to a daily cycle), and the residual component is the original series minus the trend and periodic components. Phase Two involves multi-time-window forecasting, fitting the trend equation based on least-squares linear regression and extrapolating it to the future. Non-negativity constraints and a 3x growth rate cap are applied, combined with periodic modulo extrapolation, to generate forecasts for 30, 60, and 90-day windows. Phase Three calculates confidence intervals, using the residual standard deviation and prediction standard error to calculate 80% and 95% confidence intervals. Phase Four provides capacity warnings, generating an alert and recommending expansion plans when namespace-level forecast usage exceeds 80% of the quota. Phase Five involves model calibration and retraining, updating model parameters online using EWMA (Exponentially Weighted Moving Average), and triggering a full retraining when the MAPE (Mean Absolute Percentage Error) exceeds 25%.

[0240] The capacity prediction technical solution is as follows: The Capacity Predictor is the core forward-looking planning component of this invention. It is responsible for performing time series decomposition based on historical resource profile data, generating multi-time window resource demand forecasts, calculating forecast confidence intervals, checking capacity thresholds and generating early warnings, and continuously calibrating the forecast model.

[0241] I. Time Series Decomposition Methods: An additive decomposition model is adopted: X(t) = P(t) + T(t) + R(t), where X(t) is the observation value of the original resource usage time series at time t, P(t) is the periodic component (reflecting the regular fluctuations of daily and weekly cycles), T(t) is the trend component (reflecting the long-term direction of resource usage changes), R(t) is the residual component (reflecting the random fluctuations after removing periodicity and trend), and t is the time index (in units of sampling step size, i.e., the time corresponding to the t-th data point). This model decomposes the original time series into the sum of the above three components.

[0242] Trend component extraction: A central moving average method with a weekly window length of w=2016 (corresponding to the number of data points over 7 days with a 5-minute sampling step). The calculation formula is T(t)=(1 / w)×ΣX(t+i), where i ranges from -1008 to 1008. For boundary regions, an extended window method is used to calculate the average using available data points.

[0243] Periodic component extraction: Extracted from the detrended sequence D(t)=X(t)-T(t) using the periodic averaging method. A weekly cycle pattern (cycle length L=2016) is used when historical data covers at least 14 days; otherwise, a daily cycle pattern (cycle length L=288) is used. The average value of each time point across all cycles is calculated as the periodic component value for that point.

[0244] The residual components are: R(t) = X(t) - T(t) - P(t). The sum of the three components can reconstruct data that is approximately equivalent to the original sequence, and the reconstruction error is within the floating-point precision range.

[0245] (a) Overall architecture of capacity predictor.

[0246] The Capacity Predictor adopts a modular pipeline architecture design, consisting of five sub-modules: data preprocessing module, time series decomposition module, trend prediction module, confidence interval estimation module, and model management module. These sub-modules are executed sequentially in series to form a complete prediction pipeline.

[0247] The data preprocessing module is responsible for reading at least 30 days of historical resource profile sequences (list[ResourceProfile]) from the PostgreSQL database, extracting time-series data in two dimensions: CPUP95 and memory P95, and performing data quality checks (including missing value detection, outlier filtering, and timestamp alignment). When the historical data is less than 30 days, this module outputs a data insufficiency flag and terminates subsequent pipeline execution.

[0248] The time series decomposition module implements the additive decomposition model X(t) = P(t) + T(t) + R(t) described above, decomposing the preprocessed time series into three independent components: a trend component T(t), a periodic component P(t), and a residual component R(t). This module executes the decomposition process independently on both the CPU and memory sides, outputting two sets of decomposition results.

[0249] The trend prediction module takes the trend component T(t) obtained from the decomposition as input, fits the trend equation using a least squares linear regression model T(t) = α + β × t, and extrapolates the fitted parameters to generate trend prediction values ​​for three time windows: 30, 60, and 90 days. This module also applies non-negativity constraints ( ≥0) and growth rate upper limit constraint ( ≤3×T(N)), to prevent unreasonable extreme prediction values ​​from being generated by trend extrapolation.

[0250] The confidence interval estimation module calculates the prediction uncertainty based on the statistical properties of the residual component R(t). This module first calculates the residual standard deviation. Where σ_R is the sample standard deviation of the residual sequence, measuring the magnitude of random fluctuations in the time series after removing trend and periodic components; N is the total number of data points in the residual sequence; R(t) is the residual value at time point t, i.e., the random fluctuation portion after subtracting trend and periodic components from the original resource usage; and Σ is the summation operation over all time points. Then, the prediction standard error is calculated based on the prediction step size h. , where SE(h) is the standard error of prediction with a prediction step size of h, measuring the uncertainty of the predicted value, h is the prediction step size, i.e., the number of data points from the end of the training data to the prediction target time point, and N is the total number of training data points. The final output is confidence intervals at two levels: 80% and 95%.

[0251] The model management module is responsible for the persistent storage, version management, and self-calibration of prediction model parameters. This module stores the model parameters obtained from each training iteration (including linear regression coefficients α and β, residual standard deviation σ_R, periodic component template P(k), and the time range of the data used during training) in a structured format in the `prediction_models` table of the PostgreSQL database. Each service (service_id) maintains an independent record of model parameters. When new real-world data arrives, the model management module updates the model parameters online using the exponentially weighted moving average (EWMA) method, without needing to re-execute the entire training process.

[0252] The data flow relationship between the above five sub-modules is as follows: from the data preprocessing module to the time series decomposition module to the trend prediction module to the confidence interval estimation module. The model management module interacts bidirectionally with the trend prediction module and the confidence interval estimation module (reading historical model parameters and writing updated model parameters).

[0253] (ii) The training process of the capacity predictor.

[0254] The training process of the capacity predictor is divided into two modes: initial training and incremental update, which are applicable to the initial modeling and continuous operation stages, respectively.

[0255] Initial training process: Step 1 (Data Preparation): Extract historical resource profile sequences for the target service from PostgreSQL for at least 30 days (90 days recommended for a more stable model), and construct equal-interval time series for both CPUP95 and memory P95 dimensions. For missing data points, use linear interpolation to fill (missing segments < 1 hour) or mark them for exclusion (missing segments ≥ 1 hour).

[0256] Step 2 (Trend Component Fitting): Perform least-squares linear regression on the trend component T(t) extracted by the central moving average. Here, T(t) is the trend component value at time point t, the long-term trend value extracted from the original resource usage sequence using a 7-day central moving average, and t is the time index. Assume the trend component sequence contains M valid data points {(t_i, T(t_i))}, i = 1, 2, ..., M, where M is the total number of valid data points, t_i is the time index of the i-th data point, and T(t_i) is the trend component value corresponding to the i-th data point. The regression coefficients are solved by minimizing the sum of squared residuals Σ(T(t_i) - α - β × t_i)², where α is the trend intercept, i.e., the baseline value of resource usage at the origin, and β is the trend slope, i.e., the growth rate of resource usage per unit time step. The analytical solution to the normal equation is: β=(M×Σ(t_i×T(t_i))-Σt_i×ΣT(t_i)) / (M×Σt_i²-(Σt_i)²), α=(ΣT(t_i)-β×Σt_i) / M. Simultaneously, the regression goodness of fit R² is calculated as: R²=1-Σ(T(t_i)-α-β×t_i)² / Σ(T(t_i)- )², where R² is the arithmetic mean of the trend component series. The value of R² ranges from 0 to 1; a value closer to 1 indicates a better fit of the linear regression to the trend data. A warning log is logged when R² < 0.3, indicating that the trend linearity assumption may not be applicable to the service.

[0257] Step 3 (Construction of Periodic Component Template): Extract the periodic template from the detrended sequence D(t) = X(t) - T(t), where D(t) is the detrended value at time t, X(t) is the original resource usage at time t, and T(t) is the trend component value at time t. Taking a weekly cycle as an example (cycle length L = 2016, corresponding to 7 days × 288 sampling points / day), divide the detrended sequence into segments according to the cycle length, and calculate the arithmetic mean of each time position k (k = 0, 1, ..., L-1) over all complete cycles: P(k) = (1 / N_periods) × ΣD(j × L + k), j = 0, 1, ..., N_periods-1. Where P(k) is the value of the periodic template at time position k, representing the typical periodic offset of that time position relative to the trend line; N_periods is the number of complete periods contained in the historical data; j is the period number index; L is the period length (number of data points); and k is the time position index within the period. The generated periodic template {P(0),P(1),...,P(L-1)} is stored in the model parameters for periodic extrapolation during the prediction phase.

[0258] Step 4 (Calculation of Residual Statistical Properties): Calculate the sample standard deviation σ_R of the residual component R(t) = X(t) - T(t) - P(t), where R(t) is the residual value at time point t, i.e., the random fluctuation portion of the original data after removing trend and periodic components, X(t) is the original resource usage, T(t) is the trend component, P(t) is the periodic component, and σ_R is the sample standard deviation of the residual sequence, measuring the magnitude of random fluctuation and serving as the basic parameter for calculating the confidence interval. Simultaneously, perform a normality test (Shapiro-Wilk test) on the residual sequence. When the p-value < 0.05, record a log indicating that the residual distribution deviates from the normality assumption, and the coverage of the confidence interval may be biased.

[0259] Step 5 (Model Validation): Validate the trained model using backtesting. Use the last 7 days of historical data as the validation set. Train the model using the previous data and generate predictions for the validation set. Calculate the mean absolute percentage error (MAPE_validation) on the validation set: MAPE_validation = (1 / n) × Σ|predicted_i - actual_i| / actual_i × 100%. Where MAPE_validation is the mean absolute percentage error on the validation set, a metric for model prediction accuracy; a smaller value indicates more accurate predictions. n is the number of data points in the validation set; predicted_i is the model's predicted value for the i-th validation data point; and actual_i is the actual observed value for the i-th validation data point. When MAPE_validation > 25%, record a warning log and indicate insufficient model accuracy in the prediction results.

[0260] Step Six (Model Parameter Persistence): All trained model parameters, including α (trend intercept), β (trend slope), σ_R (residual standard deviation), R² (regression goodness of fit), P(k) (periodic template), training data time range, and MAPE_validation (validation set prediction error), are serialized in JSON format and stored in the PostgreSQL table `prediction_models`, with `service_id` as the primary key. The model version number (`model_version`, an auto-incrementing integer) and training timestamp are also recorded.

[0261] Incremental update process: When the system acquires new actual resource usage data during daily operation, the model management module updates the model parameters online using the exponentially weighted moving average (EWMA) method, avoiding the need to perform a complete retraining process every time.

[0262] Trend slope update: β_new=(1-λ)×β_old+λ×β_observed, where β_new is the calibrated global trend slope (the growth rate of resource usage per unit time step), β_old is the global trend slope before calibration, β_observed is the local trend slope calculated by linear regression based on the data of the most recent 7 days, and λ is the learning rate parameter with a value of 0.1.

[0263] Residual standard deviation update: Where σ_new is the standard deviation of the residuals after calibration (used to calculate the width of the prediction confidence interval), σ_old is the standard deviation of the residuals before calibration, error is the deviation between the most recent predicted value and the actual value, and λ is the learning rate parameter with a value of 0.1.

[0264] Periodic template update: P_new(k) = (1-λ) × P_old(k) + λ × D_observed(k), where P_new(k) is the value of the calibrated periodic template at time position k, P_old(k) is the value of the uncalibrated periodic template at time position k, D_observed(k) is the detrended observation at time position k in the most recent complete period (i.e., the residual value after subtracting the trend component from the actual resource usage), and λ is the learning rate parameter, with a value of 0.1.

[0265] The updated model parameters are written to PostgreSQL, and the model_version is incremented. When the cumulative number of incremental updates exceeds 30 (approximately 30 days) or the MAPE exceeds 25%, a complete retraining process is triggered to prevent parameter drift from accumulating.

[0266] (III) Setting key parameters for the capacity predictor.

[0267] The key parameters involved in the capacity predictor and the basis for their settings are as follows: 1. Data acquisition and preprocessing parameters.

[0268] Minimum training data length: 30 days. This parameter ensures that the training data covers at least four complete cycles, giving the estimation of periodic components statistical stability. When the data length reaches 90 days, the model can capture long-term patterns at the monthly level, further improving prediction accuracy.

[0269] Recommended training data length: 90 days. Covering approximately 13 complete cycles provides more robust trend estimation and periodic templates.

[0270] Sampling step size: 5 minutes (consistent with the default sampling interval of Prometheus), corresponding to 288 data points per day and 2016 data points per week.

[0271] Missing value interpolation threshold: 1 hour (12 consecutive data points). Missing segments shorter than this threshold are filled using linear interpolation, while missing segments longer than this threshold are marked as unusable and excluded from the calculation.

[0272] 2. Time series decomposition parameters.

[0273] Moving average window length w: 2016 (corresponding to 7 days × 288 points / day). Choosing a complete weekly cycle as the window length ensures that the moving average can completely smooth out periodic fluctuations and extract the pure trend component.

[0274] Period length L: Weekly period L=2016 is preferred (when data ≥ 14 days), and daily period L=288 is used as a fallback (when data < 14 days but ≥ 30 days, in which case the periodic template is built based on the daily period).

[0275] Minimum number of complete cycles required for periodic component calculation: 2 (at least 14 days of data are required for the weekly cycle pattern, and at least 2 days of data are required for the daily cycle pattern).

[0276] 3. Trend prediction parameters.

[0277] Linear regression model: T(t) = α + β × t, where T(t) is the trend prediction value at time point t (i.e., the long-term trend level of resource usage predicted by the model), α is the intercept term (i.e., the baseline value of resource usage at the origin of the trend line, with the unit consistent with resource usage, CPU cores and memory bytes), β is the trend slope (i.e., the growth rate of resource usage within a unit time step, with the unit being resource usage / time step), and t is the time index (a relative time number with the data collection start time as zero).

[0278] Nonnegativity constraint: (t_future)=max(0, (t_future)), where (t_future) represents the predicted trend value at the future time point t_future, and the max function takes the larger of the two parameters. This constraint ensures that the predicted resource usage does not become negative.

[0279] Growth rate ceiling constraint: (t_future)=min( (t_future),3×T(N)), where (t_future) represents the predicted trend value at a future time point, and T(N) represents the trend value at the last time point N in the training data, i.e., the current latest trend level. The min function takes the smaller of the two parameters. This constraint limits the predicted value to within 3 times the current trend value, preventing unrealistic extreme predictions from arising under long-term linear extrapolation. The choice of a 3-fold upper limit is based on the empirical judgment that service resource usage increasing more than 3 times within 90 days is an extremely rare occurrence in actual production environments.

[0280] Goodness-of-fit warning threshold R²: 0.3. R² represents the goodness-of-fit of the regression (ranging from 0 to 1, indicating the proportion of trend data variation explained by the linear regression model). When R² < 0.3, it indicates that the linear model can only explain less than 30% of the trend variation, and the reliability of trend prediction is low.

[0281] 4. Confidence interval parameters.

[0282] 80% confidence interval Z-value: 1.282 (corresponding to the 90th percentile of the standard normal distribution).

[0283] 95% confidence interval Z-value: 1.960 (corresponding to the 97.5th percentile of the standard normal distribution).

[0284] The Z value is the quantile of the standard normal distribution, which is used to convert the standard error of prediction into the half-width of the interval corresponding to the confidence level.

[0285] Formula for standard error of prediction: Where SE(h) is the standard error of prediction when the prediction step size is h, measuring the uncertainty of the predicted value; σ_R is the sample standard deviation of the residual components, measuring the magnitude of random fluctuations in historical data; h is the prediction step size, i.e., the number of data points from the end of the training data to the prediction target time point; and N is the total number of training data points. This formula reflects the characteristic that prediction uncertainty increases with the increase of the prediction step size: when h=0, SE=σ_R (equal to the standard deviation of the residuals), when h=N... Uncertainty increased by approximately 41%.

[0286] Non-negative lower bound constraint: ci_lower = max(0, ci_lower), where ci_lower is the lower bound of the confidence interval, and the max function takes the larger of the two parameters. This constraint ensures that the lower bound of the confidence interval does not have a negative value (because resource usage cannot be negative).

[0287] 5. Capacity warning parameters.

[0288] Warning trigger threshold: Namespace-level predicted resource usage reaches 80% of the current ResourceQuota quota. This threshold reserves 20% buffer space for the operations team to perform expansion operations.

[0289] The recommended quota for capacity expansion is calculated as: recommended_quota = predicted_usage / 0.70, where recommended_quota is the recommended new quota value, and predicted_usage is the future resource usage predicted by the model. This means it is recommended to set the quota to approximately 1.43 times the predicted usage, ensuring a 30% margin after expansion.

[0290] Early warning assessment time window: Prioritize assessing the forecast values ​​for the next 30 days, as this window has the highest forecast accuracy and best matches the capacity planning cycle of the operations and maintenance team.

[0291] 6. Model calibration and retraining parameters.

[0292] The EWMA learning rate λ is 0.1. This value ensures that model parameter updates incorporate the latest observations with 10% weight and retain historical parameters with 90% weight, striking a balance between model stability and the speed of response to new trends. Smaller λ values ​​(e.g., 0.05) make the model more stable but respond more slowly to changes, while larger λ values ​​(e.g., 0.2) make the model respond faster but may introduce more noise.

[0293] MAPE retraining trigger threshold: 25%. When the model's mean absolute percentage error exceeds this threshold, it indicates that the model's prediction accuracy has significantly decreased, requiring a complete retraining process based on the latest historical data. The 25% threshold is chosen based on the actual accuracy requirements of capacity planning scenarios: at this error level, the deviation between predicted and actual values ​​may lead to significant errors in judging the timing of capacity warnings.

[0294] Maximum number of incremental updates: 30. Exceeding this number will force a full retraining process to prevent the cumulative effect of parameter drift caused by long-term incremental updates.

[0295] Retraining and backtesting validation period: 7 days. The last 7 days of training data are used as the validation set to evaluate the prediction accuracy of the retrained model, ensuring that retraining does indeed improve model performance.

[0296] II. Multi-time window forecasting: Based on linear regression extrapolation of trend components and periodic extrapolation of periodic components, resource demand forecasts for the next 30 days, 60 days, and 90 days are generated, respectively.

[0297] Trend extrapolation: The least squares linear regression model T(t)=α+β×t is extended to the future, and non-negativity constraints and a 3x growth rate upper limit constraint are applied.

[0298] Periodic extrapolation: The periodic pattern is repeatedly extended using the modulo operation P(t_future) = P(t_futuremodL). Here, P(t_future) is the predicted value of the periodic component at the future time point t_future; t_future is the time index of the future time point; mod is the modulo operation (i.e., the remainder operation); and L is the period length (number of data points, L=2016 for a weekly period, L=288 for a daily period). This modulo operation maps future time points back to the corresponding positions in the periodic template, achieving the infinite repetition of the periodic pattern.

[0299] III. Calculation of Two-Level Confidence Intervals: Based on the standard deviation σ_R of the residual components (which measures the magnitude of random fluctuations in historical data) and the standard error of prediction Calculate the two-layer confidence interval, where SE(h) is the prediction standard error with a prediction step size of h, σ_R is the residual standard deviation, h is the prediction step size (number of data points), and N is the total number of training data points: 80% confidence interval: ±1.282×SE(h); 95% confidence interval: ±1.960×SE(h); in, The composite forecast (i.e., the sum of the trend forecast and the periodic forecast) is represented by 1.282 and 1.960, which are the Z-quantile values ​​corresponding to the 80% and 95% confidence levels of the standard normal distribution, respectively. ± indicates the symmetrical range of the forecast value. The 95% confidence interval includes the 80% confidence interval, and the 80% confidence interval includes the point forecast value.

[0300] IV. Capacity Warning: When the prediction results show that the resource usage of a certain namespace will exceed the current quota's preset percentage (default 80%) within a preset time in the future, a capacity warning will be automatically generated and an expansion plan will be recommended.

[0301] V. Model Self-calibration and Retraining: The prediction model is called the Capacity Predictor. The core model parameters of the Capacity Predictor include: trend linear regression coefficients (intercept α and slope β), residual standard deviation σ_R, and periodic component template P(k) (k=0,1,…,L-1). These parameters are estimated from historical data during the initial training phase using least squares regression and periodic averaging, and are persistently stored in the `prediction_models` table of the PostgreSQL database.

[0302] During continuous system operation, the resource usage characteristics of the service may gradually evolve with business development, leading to deviations between the model parameters obtained from initial training and the current actual data. To ensure that the prediction accuracy remains at an acceptable level over time, this invention designs a two-level model maintenance mechanism of online self-calibration and triggered retraining.

[0303] (a) Online self-calibration mechanism.

[0304] In each analysis cycle (once daily by default), after the capacity forecaster acquires new actual resource usage data, the model management module automatically executes the following online parameter calibration process: Step 1 (Calculate Prediction Bias): Compare the predicted value from the previous period with the actual value observed in the current period, and calculate the prediction error: error = actual - predicted. Here, error is the prediction error, i.e., the deviation between the actual and predicted values; a positive value indicates that the actual usage is higher than the predicted value, and a negative value indicates that it is lower than the predicted value; actual is the actual resource usage observed in the current period; and predicted is the predicted value output by the model in the previous period.

[0305] Step 2 (Trend Slope Calibration): Based on the actual data from the last 7 days, calculate the local trend slope β_observed using linear regression, and then update the global trend slope using the exponentially weighted moving average (EWMA) method. β_new=(1-λ)×β_old+λ×β_observed; Wherein, β_new is the calibrated global trend slope, i.e., the growth rate of resource usage per unit time step; β_old is the uncalibrated global trend slope; β_observed is the local trend slope calculated by linear regression based on the actual data of the last 7 days; λ is the learning rate parameter, with a value of 0.1, which controls the magnitude of the update of model parameters by new observation data. This update rule incorporates the latest observed local trend with a weight of 10% and retains the historically accumulated global trend with a weight of 90%, achieving a balance between the model's response speed to new trends and parameter stability.

[0306] Step 3 (Residual Standard Deviation Calibration): Update the residual standard deviation estimate using the latest prediction error: ; Where σ_new is the standard deviation of the residuals after calibration, used to calculate the width of the prediction confidence interval; σ_old is the standard deviation of the residuals before calibration; λ is the learning rate parameter, with a value of 0.1; and error is the prediction error calculated in step one. This update allows the width of the confidence interval to adaptively reflect the actual level of recent prediction error: when the recent prediction error increases, the value of σ increases, and the confidence interval widens accordingly, conveying a signal to operations personnel that prediction uncertainty has increased; and vice versa.

[0307] Step 4 (Periodic Template Calibration): When the detrended observation data D_observed(k) for the most recent complete period (7 days or 1 day, depending on the current periodic pattern used) is available, update the periodic component template: P_new(k)=(1-λ)×P_old(k)+λ×D_observed(k), k=0,1,…,L-1; Wherein, P_new(k) is the value of the calibrated periodic template at time position k, representing the periodic offset of this time position relative to the trend line; P_old(k) is the value of the uncalibrated periodic template at time position k; D_observed(k) is the detrended observation value at time position k in the most recent complete cycle, i.e., the residual value after subtracting the trend component from the actual resource usage; λ is the learning rate parameter, with a value of 0.1; L is the cycle length (weekly cycle L=2016 corresponds to 7 days × 288 sampling points / day, daily cycle L=288 corresponds to 1 day × 288 sampling points / day); k is the time position index within the cycle, with a value range from 0 to L-1.

[0308] This update allows periodic templates to gradually adapt to slow changes in the cyclical behavior of the service. For example, peak business hours may gradually shift from the morning to the afternoon.

[0309] Step 5 (Intercept Calibration): Based on the updated β_new and the most recent actual trend value T_observed(N), recalculate the intercept: α_new=T_observed(N)-β_new×t_N; Wherein, α_new is the calibrated trend line intercept, which is the baseline value of resource usage at the origin of the time; T_observed(N) is the actual trend component value at the most recent observation time point, which is the trend value obtained by performing a moving average on the latest resource usage data to remove periodic fluctuations; β_new is the trend slope after EWMA calibration, which is the growth rate of resource usage per unit time; t_N is the time index value of the most recent observation time point, which is the relative time number with the data collection start time as zero.

[0310] This calibration ensures that the trend line passes through the latest observation point, avoiding systematic prediction shifts caused by intercept bias.

[0311] Step 6 (Parameter Persistence): Write all updated model parameters to the PostgreSQL table `prediction_models`, increment `model_version` by 1, record the timestamp of this calibration and the parameter changes before and after calibration, and write them to the Loki audit log.

[0312] (ii) Prediction accuracy monitoring and retraining triggering.

[0313] After each calibration, the model management module automatically evaluates the prediction accuracy of the capacity predictor and triggers a full model retraining when the accuracy drops to an unacceptable level.

[0314] Accuracy assessment method: Calculate the average absolute percentage error of the most recent 7 predictions (corresponding to the most recent 7 days): MAPE=(1 / n)×Σ|predicted_i-actual_i| / actual_i×100%, i=1,2,…,n; In this calculation, MAPE is the Mean Absolute Percentage Error, a comprehensive indicator of model prediction accuracy; a smaller value indicates a more accurate prediction. n represents the logarithm of predicted versus actual values ​​used in the calculation, with a value of min(7, the logarithm of available historical predicted versus actual values). predicted_i is the model output value of the i-th prediction; actual_i is the actual observation value corresponding to the i-th prediction; Σ is the summation operator, summing all terms from 1 to n for i. MAPE is calculated separately for CPU and memory, and the larger value is taken as the overall MAPE.

[0315] Retraining trigger conditions: The complete retraining process of the capacity predictor is triggered when any of the following conditions are met: Condition 1: A comprehensive MAPE > 25% indicates that the prediction accuracy has decreased significantly.

[0316] Condition 2: The cumulative number of incremental updates since the last complete training exceeds 30 times (approximately 30 days) to prevent the cumulative effect of parameter drift caused by long-term incremental updates.

[0317] Retraining execution process: Step 1: Send a retraining notification to the operations and maintenance team, explaining the triggering reason (MAPE exceeding the limit or the number of incremental updates exceeding the limit) and the current MAPE value.

[0318] Step 2: Re-extract the historical resource profile sequence of the target service from PostgreSQL for the most recent 90 days (if less than 90 days, take all available data, but no less than 30 days).

[0319] Step 3: Following the initial training process, re-execute the complete six-step training process (data preparation, trend component fitting, periodic template construction, residual statistical property calculation, backtesting validation, and model parameter persistence).

[0320] Step 4: Perform backtesting validation on the retrained model, using the last 7 days of the training data as the validation set, and calculate MAPE_validation.

[0321] Step 5: If MAPE_validation ≤ 25% after retraining, then the retraining is successful. The new model parameters replace the old parameters, model_version is incremented, and the incremental update counter is reset to zero.

[0322] Step Six: If MAPE_validation remains >25% after retraining, generate an alert to notify the operations team, indicating that the resource usage pattern of the service may have undergone a fundamental change (e.g., significant changes in business logic, sudden changes in user scale, etc.), and recommend manual intervention to analyze the cause. At this time, the system still uses the retrained model (because it is based on the latest data and is usually superior to the old model), but a warning label indicating insufficient model accuracy is added to the prediction results. All calibration and retraining operations are recorded in structured audit logs written to Loki, containing complete information such as operation type (calibration or retrain), triggering reason, parameter changes before and after calibration, and MAPE changes, ensuring the traceability of the model maintenance process.

[0323] This invention is deployed within a Kubernetes cluster using a Python microservice architecture. The specific deployment is as follows: CronJob timer: The analysis cycle is triggered at 2:00 AM daily by default. The concurrencyPolicy:Forbid disables concurrent execution, and activeDeadlineSeconds:3600 limits the maximum execution time.

[0324] Microservice component deployment: The six core functional components are encapsulated in the same container image as Python modules, and are called by JobPod triggered by CronJob in a predefined process order.

[0325] Deploy a persistent validator service: Deployed as a Deployment, running as a single copy, scanning for tasks to be verified every 5 minutes.

[0326] Prometheus integration: Supports ServiceDNS resolution within the cluster and HTTP / HTTPS access outside the cluster via the query_range endpoint of the HTTP API.

[0327] Integration methods with existing technology stacks include: PostgreSQL integration: Connects via the psycopg2 driver; database connection parameters are managed through Kubernetes Secret. Includes storage resource profiling, optimization suggestions, prediction results, and validation reports.

[0328] Loki Integration: Structured audit logs are written via the HTTP API Push endpoint in JSON format, including operation timestamp, operation type, target service, operation parameters, and operation result. Log writing failures are cached locally and retried upon recovery.

[0329] GitLab Integration: Creates and manages MergeRequests via GitLabRESTAPIv4, supporting both PersonalAccessToken and OAuth2 authentication methods. API calls that fail are retried using an exponential backoff strategy.

[0330] ArgoCD Integration: Query application synchronization and health status via ArgoCDRESTAPI, and support BearerToken authentication.

[0331] Grafana integration: Automatically create dedicated dashboards for resource optimization using pre-configured DashboardJSON templates, displaying resource profiles, anomaly detection results, capacity alerts, and cost-saving trends.

[0332] System resource allocation includes: CronJob analytics task Pod resource configuration: CPU request 500MB / limit 2000MB, memory request 512MB / limit 2Gi. Estimated based on a medium-sized cluster managing approximately 500 services.

[0333] Deploy validator resource configuration: CPU request 100m, memory request 128Mi.

[0334] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores static and dynamic information data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0335] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0336] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0337] In addition, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0338] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0339] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A method for Kubernetes resource profiling and cost optimization, characterized in that, The method includes: Periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on preset query statements to obtain the raw indicator dataset. Based on the original indicator dataset, the data is aggregated according to preset dimensions to obtain aggregated indicator data. Based on the aggregated indicator data, the resource profiling engine is used to classify the resource usage patterns of each service and generate service resource profiles. Based on the service resource profile, multi-dimensional anomaly detection is performed using an anomaly detector to obtain a list of abnormal services and the corresponding anomaly detection results. Based on the list of abnormal services and service resource profiles, the optimization advisor generates adjustment suggestions for resource requests and resource limits for each abnormal service, resulting in a set of optimization suggestions. The MR generator is used to transform the set of optimization suggestions into change patches for the deployment configuration file, and a differentiated merge request submission strategy is adopted according to the risk level to output the merge request; Based on the merge request, compare resource usage data and service operation metrics before and after the merge, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, automatically roll back the merge request and send an alarm notification. The capacity predictor is used to predict resource demand based on the service resource profile and obtain the predicted value. When the predicted value exceeds the set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is calibrated based on the comparison between the actual value and the predicted value.

2. The Kubernetes resource profiling and cost optimization method according to claim 1, characterized in that, The process of aggregating the original indicator dataset according to preset dimensions to obtain aggregated indicator data, and then using a resource profiling engine to classify the resource usage patterns of each service and generate a service resource profile based on the aggregated indicator data, includes the following steps: After removing extreme outliers from the obtained raw metric dataset using the interquartile range method, the dataset is then aggregated hierarchically according to the three dimensions of namespace, deployment unit, and container to obtain the aggregated metric data for each service. Based on the aggregated metric data, calculate the four percentile statistics of each service in terms of CPU and memory dimensions: P50, P95, P99 and maximum value. The aggregated indicator data is input into the feature extraction layer of the resource profiling engine, where statistical features for pattern classification are extracted in both the CPU and memory dimensions. The feature normalization layer of the resource profiling engine is then used to fuse similar features from the CPU and memory dimensions to obtain fused feature data. The statistical features include the coefficient of variation, the maximum value of the autocorrelation coefficient, the slope of the normalization trend, and the peak-to-peak ratio. The fused feature data is input into the hierarchical decision layer of the resource profiling engine, and the resource usage patterns of each service are classified according to the preset judgment priority to obtain the corresponding resource usage pattern type. By combining aggregated metric data, percentile statistics, resource usage pattern types, number of container memory overflow termination events, and CPU throttling ratio, a service resource profile is constructed.

3. The Kubernetes resource profiling and cost optimization method according to claim 2, characterized in that, The process involves inputting the fused feature data into the hierarchical decision layer of the resource profiling engine, classifying the resource usage patterns of each service according to a preset decision priority, and obtaining the corresponding resource usage pattern types, including: Determine whether a service simultaneously satisfies the conditions that its coefficient of variation is below the first threshold and its peak value is below the second threshold. If so, classify the service as stable. If the stable condition is not met, then it is further determined whether the normalization trend slope is higher than the third threshold. If it is met, the service is classified as growth type. If the growth-type criteria are not met, then it is further determined whether the maximum value of the autocorrelation coefficient is higher than the fourth threshold. If it is met, then the service is classified as cyclical. If none of the three criteria are met, the service will be classified as a sudden occurrence.

4. The Kubernetes resource profiling and cost optimization method according to claim 1, characterized in that, The process of performing multi-dimensional anomaly detection based on service resource profiles and anomaly detectors to obtain a list of abnormal services and corresponding anomaly detection results includes the following steps: Based on service resource profiles, an anomaly detector is used to calculate the waste score for each service. When the waste score exceeds the first alarm threshold, the service is marked as a resource waste state and waste quantification data is recorded. Based on service resource profiles, an anomaly detector is used to calculate the risk score for each service; when the risk score exceeds the second alarm threshold, the service is marked as resource-insufficient and a high-priority alarm is generated. Based on the service resource profile, an anomaly detector is used to perform pattern drift detection on each service. When the current value of any resource dimension deviates from the historical mean by more than twice the standard deviation, it is determined that a pattern drift has occurred, a pattern drift alarm is generated, and the service resource profile is regenerated. Based on the service resource profiles of all services under the same namespace, the anomaly detector is used to calculate the resource usage correlation between service pairs. When the correlation coefficient in the CPU or memory dimension exceeds the preset correlation threshold, it is determined that there is a resource contention mode and the competing service combination is recorded. Services marked as resource waste, resource shortage, pattern drift, or resource contention are integrated to form a list of abnormal services and corresponding anomaly detection results.

5. The Kubernetes resource profiling and cost optimization method according to claim 4, characterized in that, The waste score is obtained by weighted averaging the percentage of waste in the CPU and memory dimensions by comparing the resource request value of the service with the actual usage of P95. The risk score is obtained by weighted summation of three risk factors: the number of OOM termination events, the CPU throttling ratio, and the insufficient resource margin factor.

6. The Kubernetes resource profiling and cost optimization method according to claim 1, characterized in that, The process of generating adjustment suggestions for resource requests and resource limits for each abnormal service based on the list of abnormal services and service resource profiles, and obtaining an optimization suggestion set, includes the following steps: Based on each abnormal service in the abnormal service list, and combined with the corresponding service resource profile, the workload type of each service is determined, resulting in stateless services and stateful services. Based on the P99 resource usage in the service resource profile, differentiated safety margin coefficients are applied for stateless and stateful services to calculate the resource request recommendation value for each abnormal service; and based on the resource request recommendation value and the proportion coefficient of the corresponding service type, the resource limit recommendation value is calculated. In the case of multiple abnormal services under the same namespace, the total resource request suggestion value of all abnormal services is calculated in combination with the resource quota constraint of the namespace. If the total resource request suggestion value exceeds the resource quota limit, the optimization suggestions are trimmed and optimized in order from low to high according to the preset priority score, and the safety lower limit constraint of each service is preserved in the trimming process to obtain the final adjustment suggestion. Estimate the monthly cost savings for each recommendation in the final adjustment recommendations, and assess the risk level of each recommendation based on the scope of resource adjustments, workload type, historical anomalies, and stability of resource usage patterns; Integrate all final adjustment recommendations, cost saving estimates, and risk levels to form an optimization recommendation set.

7. The Kubernetes resource profiling and cost optimization method according to claim 1, characterized in that, The differentiated merge request submission strategy includes: For low-risk optimization suggestions, automatically create a merge request in normal state, and improve the optimization basis, configuration change comparison, estimated cost savings and risk assessment information in the request description; For medium-risk optimization suggestions, create a merge request in draft status, mark it as requiring manual review, and automatically assign a reviewer; For high-risk optimization suggestions, create a merge request in draft form, attach a complete rollback plan, and merge after approval by the reviewer.

8. The Kubernetes resource profiling and cost optimization method according to claim 1, characterized in that, The capacity predictor is used to predict resource demand based on the service resource profile to obtain predicted values. When the predicted value exceeds a set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is calibrated based on the comparison between the actual value and the predicted value, including the following steps: Based on at least 30 days of historical service resource profile data, the capacity predictor is used to perform time series decomposition on the resource usage time series in the CPU and memory dimensions respectively, decomposing the original series into trend components, periodic components and residual components, and obtaining the data of each component after decomposition. Based on linear regression extrapolation of trend components and periodic extrapolation of periodic components, resource demand forecasts for three time windows of 30 days, 60 days and 90 days are generated. Confidence intervals at two levels, 80% and 95%, are calculated based on the standard deviation of the residual components to obtain the forecast values ​​and corresponding confidence intervals. When the predicted value shows that the resource usage of a namespace will exceed the preset ratio of the current resource quota limit of the namespace in the next 30 days, a capacity warning message is generated and an expansion plan is recommended. After acquiring new actual resource usage data, the predicted values ​​are compared with the actual values, the prediction error is calculated, and the capacity predictor is iteratively updated using the prediction error.

9. The Kubernetes resource profiling and cost optimization method according to claim 8, characterized in that, The process of comparing the predicted value with the actual value after acquiring new actual resource usage data, calculating the prediction error, and iteratively updating the capacity predictor using the prediction error includes the following steps: The capacity predictor model parameters are updated online using an exponentially weighted moving average method to obtain calibrated capacity predictor model parameters; wherein, the calibrated capacity predictor model parameters include trend slope, residual standard deviation, periodic component template, and intercept. Based on the calibrated capacity predictor model parameters, the prediction accuracy of the capacity predictor is evaluated, and the mean absolute percentage error is calculated. When the mean absolute percentage error exceeds a preset accuracy threshold, or the cumulative number of incremental updates since the last complete training exceeds a preset upper limit, the capacity predictor is automatically retrained to retrain the model parameters and complete the iterative update of the capacity predictor.

10. A Kubernetes resource profiling and cost optimization system, characterized in that, The system includes: The data acquisition module is used to periodically trigger the analysis cycle and obtain the raw data of multi-dimensional resource usage indicators of containers in the cluster based on preset query statements to obtain the raw indicator dataset. The profile building module is used to aggregate the original indicator dataset according to preset dimensions to obtain aggregated indicator data; based on the aggregated indicator data, the resource profile engine is used to classify the resource usage patterns of each service and generate service resource profiles. The anomaly detection module is used to perform multi-dimensional anomaly detection based on the service resource profile and the anomaly detector, and obtain a list of abnormal services and the corresponding anomaly detection results. The suggestion generation module is used to generate adjustment suggestions for resource requests and resource limits for each abnormal service based on the list of abnormal services and service resource profiles, and to obtain an optimization suggestion set. The change submission module is used to convert the set of optimization suggestions into change patches for the deployment configuration file using the MR generator, and to output the merge request by adopting a differentiated merge request submission strategy based on the risk level. The effect verification module is used to compare resource usage data and service operation metrics before and after the merge request, and generate an optimization effect verification report using the deployment validator; when a service anomaly is detected, the merge request is automatically rolled back and an alarm notification is sent. The capacity prediction module is used to predict resource demand based on the service resource profile using a capacity predictor and obtain predicted values. When the predicted value exceeds a set threshold, a capacity warning is generated and an expansion plan is recommended. The capacity predictor is also calibrated based on the comparison between the actual value and the predicted value.

Images