A method for containerized application automated deployment and elasticity

Abstract

The application discloses a kind of container application automatic deployment and elastic scaling method.Responding to deployment request, obtain and parse engineering build file and / or engineering configuration file, extract engineering features, automatically generate image construction description information and deployment arrangement configuration for target environment, build application image and create running instance in container arrangement platform.Resource indicators and application side runtime indicators are collected during running, and associated time series are formed according to instance identification and time stamp, cross-domain indicator mutual correlation peak value, correlation strength and time lag change are calculated in sliding window, abnormal score / label is output according to correlation decay and lag mutation and is classified as resource saturation or load growth, respectively, resource specification dynamic calibration or replica elastic scaling is performed, and minimum interval / hysteresis is set to suppress oscillation.Adjustment uses rolling update, readiness detection failure rollback and stability monitoring rollback after adjustment.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and container technology, and in particular to a method for automated deployment and elastic scaling of containerized applications. Background Technology

[0002] With the development of cloud computing, application deployment has evolved from physical servers / virtual machines to containerization. Traditional monolithic application deployments typically rely on physical servers or virtual machines, which suffer from problems such as complex environment configuration, redundant resource allocation, and poor scalability. Container technologies (such as Docker) improve application portability and delivery efficiency through lightweight virtualization, but in large-scale distributed and microservice scenarios, they still face challenges in deployment engineering, cross-environment consistency, runtime elasticity, and operational collaboration.

[0003] In existing technologies, container orchestration platforms such as Kubernetes provide basic capabilities such as application orchestration, service discovery, and rolling updates. However, their general capabilities are often not deeply integrated with the engineering characteristics of microservice frameworks (such as Spring Boot), which can easily lead to a disconnect between development and operation processes. In actual implementation, microservice applications often require manually building container images, writing or maintaining deployment orchestration configurations (such as YAML files), and configuring network, storage, and other resource objects one by one. This results in a time-consuming deployment process with insufficient repeatability. At the same time, differences in configuration items, dependency versions, and resource parameters between development, testing, and production environments can easily be scattered and managed in an unstructured manner, leading to inconsistencies in configuration, environment drift, and operational differences, increasing deployment risks and regression costs.

[0004] Furthermore, existing resource allocation and elastic scaling strategies still rely on manual experience and post-deployment adjustments in many scenarios. On the one hand, container resource requests and limit parameters are usually statically set before deployment, lacking a unified mechanism for continuous dynamic calibration based on runtime status. This can easily lead to low resource utilization, idle and wasted resources, or insufficient resources causing performance fluctuations when the load changes. On the other hand, existing automatic scaling solutions are mostly triggered based on platform-side resource indicator thresholds such as CPU and memory, or based on single business indicators. This may result in lag in scaling decisions when facing sudden traffic surges or complex workloads. Moreover, relying solely on single indicator thresholds makes it difficult to depict the transmission relationship between "resource changes and application performance changes," and it is difficult to distinguish between different abnormal mechanisms such as resource saturation and load growth. This leads to inaccurate scaling actions, or even false triggers, over-scaling, or ineffective adjustments.

[0005] At the same time, fault recovery and operation and maintenance monitoring may also suffer from decentralization and fragmentation in existing practices: platform-side resource metrics and application-side runtime metrics (such as request response latency, error rate, JVM performance metrics, etc.) are often collected and displayed by different systems, lacking a unified identification association and time alignment mechanism at the granularity of running instances. This makes it difficult to form a unified view of cross-domain metrics that can be used for decision-making, and increases the time consumption for problem localization and root cause analysis. In the case of container anomalies or performance degradation, it may still be necessary to manually compare multi-dimensional metrics and select handling strategies, resulting in insufficient automation and closed-loop.

[0006] Therefore, it is necessary to provide an automated deployment and elastic scaling method for containerized applications. This method can improve the automation of image building and orchestration deployment, ensure consistency of configuration across multiple environments, and perform instance-level correlation and time alignment between platform-side resource metrics and application-side runtime metrics during runtime. It can also perform more timely and interpretable detection and classification of anomalies based on cross-domain correlation characteristics. This will guide the selection and execution of dynamic calibration of resource specifications and elastic scaling of the number of instances, thereby improving deployment efficiency, optimizing resource utilization, and enhancing operational stability and maintenance efficiency. Summary of the Invention

[0007] The purpose of this invention is to provide a method for automated deployment and elastic scaling of containerized applications, addressing the problems of existing technologies where image building and deployment orchestration configuration rely on manual writing and maintenance, lack of reusability, and inconsistencies arising from multi-environment configurations. It also solves the problems of scattered collection of platform-side resource metrics and application-side runtime metrics, lack of unified correlation analysis leading to delayed anomaly detection, inaccurate handling strategy selection, and frequent false triggering and adjustment switching. By achieving unified correlation and time consistency analysis between platform-side resource status and application-side runtime performance at the runtime instance granularity, an indicator system is formed that can characterize the correlation between changes in resource status and changes in application performance. This system improves the timeliness and interpretability of anomaly identification when the correlation characteristics weaken or change abnormally, and further supports the differentiation of anomaly causes. This guides more targeted choices between dynamic calibration of resource specifications and elastic scaling of instance numbers, reducing ineffective adjustments and frequent switching, improving the accuracy and stability of elastic adjustments, optimizing resource utilization efficiency, and improving system performance, availability, and operational stability, while also enhancing deployment delivery efficiency and the level of operational automation.

[0008] To achieve the above objectives, the present invention provides a method for automated deployment and elastic scaling of containerized applications, the method comprising:

[0009] In response to a deployment request issued for a target application, at least one project file is obtained, the project file including at least one of a project build file and a project configuration file; the project file is parsed to extract project features, and build description information and deployment orchestration configuration for building a container image are generated based on the project features;

[0010] The application image of the target application is constructed based on the construction description information; and the deployment orchestration configuration is distributed to the container orchestration platform to create a running instance of the target application in the container orchestration platform.

[0011] During the operation of the running instance, operational metric data is collected, which includes at least platform-side resource metrics and application-side runtime metrics.

[0012] Based on the runtime instance identifier, the platform-side resource metrics and the application-side runtime metrics are aligned and then aligned by timestamp to generate a time series of associated runtime metrics.

[0013] Based on the associated time series of operational metrics, an adjustment operation is determined for the operational instance, and the adjustment operation includes at least one of dynamic calibration of resource specifications and elastic scaling of the number of instances.

[0014] The adjustment operation is performed on the running instance through the container orchestration platform, and the execution result is output.

[0015] Furthermore, generating the deployment orchestration configuration includes:

[0016] Obtain the environment identifier of the target deployment environment; generate basic configuration information based on the engineering characteristics and load the environment-differentiated configuration parameters corresponding to the environment identifier; merge the basic configuration information and the environment-differentiated configuration parameters to generate the deployment orchestration configuration suitable for the target deployment environment.

[0017] Furthermore, the identifier alignment includes:

[0018] The runtime metrics on the application side are attached with the runtime instance identifier or an associated tag that can be mapped to the runtime instance identifier; and the runtime metrics on the application side are time-series mapped to the resource metrics on the platform side based on the runtime instance identifier or the associated tag.

[0019] Furthermore, performing cross-domain association modeling based on the associated operational indicator time series includes:

[0020] Within the sliding time window, calculate the cross-correlation function and determine the peak value and its corresponding time lag for at least the following two types of cross-domain indicator pairs:

[0021] (1) Processor utilization and / or memory working set usage in platform-side resource metrics, and request response latency in application-side runtime metrics;

[0022] (2) Processor utilization and / or memory working set usage in platform-side resource metrics, and request error rate in application-side runtime metrics;

[0023] The correlation strength corresponding to the peak value of the cross-correlation function and the change in time lag between adjacent sliding time windows are calculated.

[0024] Furthermore, performing anomaly detection includes:

[0025] When the correlation strength decreases by more than a first threshold between adjacent sliding time windows and the change in time lag exceeds a second threshold, the correlation anomaly score and / or correlation anomaly label are output.

[0026] The correlation anomaly score is obtained by weighting the decrease in correlation strength with the change in time lag; and the correlation anomaly score and / or correlation anomaly label are used as one of the conditions for triggering the adjustment operation.

[0027] Furthermore, the adjustment operation is determined to include:

[0028] The anomaly types are classified based on the associated anomaly labels and the direction and / or magnitude of the time lag change, and the anomaly types include at least resource saturation anomalies and load growth anomalies.

[0029] When the classification result is a resource saturation anomaly, dynamic calibration of resource specifications should be performed first.

[0030] When the classification result is a load growth anomaly, prioritize performing elastic scaling of the number of instances;

[0031] A minimum interval or hysteresis range is set for the selection to suppress the frequent switching of the adjustment operation between dynamic calibration of resource specifications and elastic scaling of the number of instances.

[0032] Furthermore, the dynamic calibration of resource specifications includes:

[0033] Within a preset time window, calculate the statistical characteristic value of resource usage in the associated operation indicator time series; calculate the deviation rate between the statistical characteristic value and at least one of the currently configured resource request value and resource limit value; when the deviation rate exceeds a preset adjustment threshold, generate new resource specification parameters based on the statistical characteristic value and update the resource configuration of the running instance.

[0034] Furthermore, the elastic scaling of the number of instances includes:

[0035] Monitor the rate of change of the application-side runtime metrics; when the rate of change exceeds a preset burst threshold, calculate the load estimate for the next moment based on the rate of change; and increase the number of replicas of the running instance in advance before the platform-side resource metrics reach the expansion threshold.

[0036] Furthermore, when performing the adjustment operation, a rolling update strategy is adopted to gradually replace, rebuild, and / or add the running instances; and the readiness status of the newly started running instances is monitored. If no readiness signal is detected within a preset time, the system automatically rolls back to the state before the adjustment.

[0037] Furthermore, the running status is continuously monitored for a preset duration after the adjustment operation is performed;

[0038] When it is detected that the application-side runtime metrics and / or the platform-side resource metrics no longer meet the preset stability conditions, a rollback operation is performed to undo the adjustment operation and / or restore the resource configuration and copy status before the adjustment.

[0039] The stability conditions include at least one of the following: error rate threshold condition, response latency threshold condition, availability threshold condition, and restart count threshold condition.

[0040] The present invention, by adopting the above technical solution, has at least the following beneficial effects:

[0041] By extracting engineering features from engineering files and automatically generating image build description information and deployment orchestration configurations, the workload of manual writing and maintenance is reduced, the probability of errors caused by manual configuration is lowered, deployment efficiency and delivery consistency are improved, and the reusability between different applications and projects is enhanced.

[0042] By introducing environment identifiers and structuring the merging of basic configuration information with environment-differentiated configuration parameters, the deployment configurations of different environments such as development, testing, and production become controllable and traceable, reducing inconsistencies and environment drift caused by scattered configurations, thereby reducing deployment risks and regression costs.

[0043] By uniformly associating platform-side resource metrics and application-side runtime metrics at the runtime instance granularity and ensuring time consistency, resource status and application performance can be compared and analyzed under the same view, reducing cross-system comparison costs and improving the efficiency of fault location and root cause analysis.

[0044] By detecting and quantifying anomalies based on cross-domain correlation features, the system can identify and provide anomaly indications that can be used for decision-making earlier when performance degradation or anomaly symptoms appear, reducing false negatives and false positives caused by a single threshold strategy, and improving the reliability and interpretability of anomaly identification.

[0045] By categorizing anomalies, the system can select more suitable adjustment directions based on different causes, achieving a more reasonable strategy choice between dynamic calibration of resource specifications and elastic scaling of instance numbers, reducing blind expansion, excessive expansion, or ineffective adjustments, and improving adjustment effectiveness and resource utilization efficiency.

[0046] By setting minimum intervals or hysteresis ranges, the probability of frequent switching between different strategies in adjustment operations is reduced, thereby mitigating the risk of system jitter and oscillation under load fluctuations and improving overall operational stability and service continuity.

[0047] By employing rolling updates during adjustment operations and supporting automatic rollback in abnormal situations, as well as performing stability monitoring after adjustments and executing rollbacks when stability conditions are not met, the risk of introducing new faults through adjustments is reduced, thereby improving the success rate of changes and system availability.

[0048] By achieving automated deployment, unified monitoring and correlation, anomaly detection and classification, and closed-loop adjustment, it can reduce manual operation and maintenance intervention and post-event remediation, improve resource utilization efficiency and elastic response capabilities, and thus improve system performance, availability and overall operation and maintenance efficiency. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a flowchart of the containerized application automated deployment and elastic scaling method of the present invention. Detailed Implementation

[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0052] like Figure 1 As shown in the figure, this embodiment provides a method for automated deployment and elastic scaling of containerized applications, the method including:

[0053] In response to a deployment request issued for a target application, at least one project file is obtained, the project file including at least one of a project build file and a project configuration file; the project file is parsed to extract project features, and build description information and deployment orchestration configuration for building a container image are generated based on the project features; wherein, by uniformly parsing the project build file and the project configuration file, project features such as dependencies, versions, ports, runtime parameters, environment variables, resource recommendation values ​​and service exposure methods can be extracted without changing the application source code organization method, thereby reducing the workload of manually writing build scripts and orchestration files and reducing configuration errors, improving the consistency and repeatability of the deployment chain.

[0054] The application image of the target application is constructed based on the build description information; and the deployment orchestration configuration is distributed to the container orchestration platform to create a running instance of the target application in the container orchestration platform; wherein, by generating and distributing the build description information and the deployment orchestration configuration in a linked manner, the image build parameters and the runtime orchestration parameters can be kept consistent, avoiding deployment failures caused by mismatches in image runtime entry, configuration mounting or port declaration, thereby improving the success rate of the first deployment and delivery efficiency.

[0055] During the operation of the instance, operational metrics data are collected. These metrics include at least platform-side resource metrics and application-side runtime metrics. The platform-side resource metrics characterize the computing and memory resources consumed by the instance, while the application-side runtime metrics characterize the performance and reliability of the services provided by the instance. This provides complementary information sources for subsequent correlation analysis and adjustment decisions, thereby improving the comprehensiveness of anomaly detection.

[0056] Based on the runtime instance identifier, the platform-side resource indicators and the application-side runtime indicators are aligned and then aligned by timestamp to generate a time series of associated runtime indicators. By implementing unified identifier association and time consistency processing at the instance granularity, indicators scattered across different collection systems can be aggregated onto the same instance object, reducing the cost of cross-system comparison and manual investigation, and improving the interpretability of anomaly location and decision-making.

[0057] Based on the associated time series of operating indicators, adjustment operations are performed on the operating instances. The adjustment operations include at least one of dynamic calibration of resource specifications and elastic scaling of the number of instances. By selecting between dynamic calibration of resource specifications and elastic scaling of the number of instances, differentiated handling paths can be adopted for different causes of anomalies, avoiding over-expansion, ineffective adjustment or resource waste caused by a single scaling strategy, and improving the targeting of adjustments and resource utilization efficiency.

[0058] The adjustment operation is performed on the running instance through the container orchestration platform, and the execution results are output. These results can be used to record changes in key metrics and adjustment types before and after the adjustment, facilitating audit tracking, effect evaluation, and subsequent strategy optimization, thereby improving operational closed-loop capabilities.

[0059] As one implementation method, generating the deployment orchestration configuration in this embodiment includes:

[0060] The process involves: obtaining the environment identifier of the target deployment environment; generating basic configuration information based on the project characteristics and loading environment-differentiated configuration parameters corresponding to the environment identifier; merging the basic configuration information and the environment-differentiated configuration parameters to generate the deployment orchestration configuration suitable for the target deployment environment. The environment identifier indicates the target environment, such as development, testing, pre-release, or production. The environment-differentiated configuration parameters carry environment-related differences such as external dependency addresses, credential references, rate limiting thresholds, log levels, and resource baselines, enabling centralized management of these differences in a structured manner. This reduces the risk of environment drift and improves cross-environment migration efficiency.

[0061] As one implementation method, the identifier alignment in this embodiment includes:

[0062] The runtime metrics on the application side are appended with the runtime instance identifier or an associated tag that can be mapped to the runtime instance identifier; and the runtime metrics on the application side are time-series mapped to the resource metrics on the platform side based on the runtime instance identifier or the associated tag. The associated tag can be a set of mappable identifiers consisting of at least one of instance name, namespace, workload identifier, Pod identifier, container identifier, and version identifier, to adapt to inconsistencies in instance identifier fields across different metric collection paths, thereby improving the success rate of metric association and ensuring that the resource status and business performance of the same instance can be analyzed consistently.

[0063] As one implementation method, cross-domain association modeling based on the associated operational indicator time series in this embodiment includes:

[0064] Within the sliding time window, calculate the cross-correlation function and determine the peak value and its corresponding time lag for at least the following two types of cross-domain indicator pairs:

[0065] (1) Processor utilization and / or memory working set usage in platform-side resource metrics, and request response latency in application-side runtime metrics;

[0066] (2) Processor utilization and / or memory working set usage in platform-side resource metrics, and request error rate in application-side runtime metrics;

[0067] The correlation strength corresponding to the peak value of the cross-correlation function and the change in time lag between adjacent sliding time windows are calculated.

[0068] The sliding time window has a window length and a sliding step size. The window length can be 30 seconds, 60 seconds, 120 seconds or 300 seconds, and the sliding step size can be 1 second, 5 seconds, 10 seconds or 30 seconds. By setting the window length and sliding step size, the cross-domain association modeling can reflect changes under short-term jitter and avoid statistical instability caused by an excessively short window, thereby improving the stability of the association features.

[0069] Before calculating the cross-correlation function, the processor utilization, memory working set usage, request response latency, and request error rate can be preprocessed. This preprocessing includes at least one of the following: standardizing the sampling interval, imputing or removing missing values, suppressing abnormal spikes, detrending, smoothing filtering, and standardization or normalization. By standardizing the units and sampling frequency and reducing noise impact, indicators from different sources are made comparable within the same window, thereby improving the reliability of cross-correlation peak identification. Furthermore, the preprocessing also includes resampling platform-side resource indicators and application-side runtime indicators to the same time grid and aligning them to a unified sampling period. This ensures that the cross-correlation calculation input sequence corresponds point-by-point on the same time axis, thus avoiding irreproducible results or lag sign meaning shifts caused by differences in implicit interpolation strategies.

[0070] The cross-correlation function can be calculated within a preset lag search range, and the lag search range can be limited to... ,in The time interval can be 5 seconds, 10 seconds, 30 seconds, or 60 seconds; by limiting the lag search range, the calculation is focused on the time scale that the business link can interpret, avoiding spurious correlations caused by accidental synchronization or long-cycle drift.

[0071] The cross-correlation function can adopt the following lag convention: Let the platform-side resource index sequence be denoted as... Application-side runtime indicator sequence Cross-correlation is defined as Under this convention, τ>0 indicates that changes in resource metrics precede changes in application metrics, and τ<0 indicates that changes in resource metrics lag behind changes in application metrics. This fixes the positive and negative semantics of time lag and ensures the consistency of subsequent anomaly classification rules across different implementation libraries.

[0072] Determining the peak includes: selecting the lag corresponding to the maximum absolute value of the cross-correlation function within the lag search range as the time lag corresponding to the peak, and using the maximum absolute value as the correlation strength; when there are multiple candidate peaks, the peak that satisfies the stability constraint can be selected first, the stability constraint includes the continuity constraint of the peak within the adjacent window or the peak width constraint, thereby reducing the probability of jump in the case of multiple peaks and improving the availability of the time lag sequence.

[0073] While using the maximum absolute value of the cross-correlation function as the correlation strength, the sign of the cross-correlation at the peak is also recorded as the correlation direction feature (positive or negative correlation). The correlation direction feature is written into the correlation anomaly label to avoid the absolute value operation from obscuring the correlation direction and affecting the explanation of the "resource change - performance change" transmission mechanism.

[0074] When multiple cross-domain indicator pairs exist, including processor utilization, response latency, memory working set, and error rate, the corresponding correlation strength and time lag can be obtained respectively. One of the following aggregation strategies can be used to form a representative value for subsequent detection: select the indicator pair with the highest correlation strength as the representative indicator pair and use its time lag; or take the maximum value of the correlation anomaly score of each indicator pair as the final score; or sum the scores of each indicator pair according to their weights. By clarifying the aggregation strategy, the input of subsequent anomaly detection and classification can be consistent and achievable.

[0075] The change in time lag between adjacent sliding time windows can be expressed as: When using absolute changes, it can be expressed as By measuring hysteresis changes, the system can capture signs of changes in the transmission path between resources and performance, thus providing additional criteria for anomaly detection.

[0076] Furthermore, validity criteria can be introduced for the correlation strength. These criteria include: the number of valid samples within the window is not less than a third threshold, the significance of the cross-correlation peak is not less than a fourth threshold, or the dominance of the cross-correlation peak relative to the second peak is not less than a fifth threshold. When the validity criteria are not met, the window can be marked as an undeterminable window and the abnormal trigger can be skipped, thereby reducing misjudgments caused by sparse sampling or insufficient data quality.

[0077] As one implementation method, the anomaly detection performed in this embodiment includes:

[0078] When the correlation strength decreases by more than a first threshold between adjacent sliding time windows and the change in time lag exceeds a second threshold, the correlation anomaly score and / or correlation anomaly label are output.

[0079] The correlation anomaly score is obtained by weighting the decrease in correlation strength with the change in time lag; and the correlation anomaly score and / or correlation anomaly label are used as one of the conditions for triggering the adjustment operation.

[0080] The decrease in correlation strength can be expressed as: ,in Let be the correlation strength of the k-th sliding time window; when A value greater than 0 indicates a weakening of the correlation; by quantifying the weakening of the correlation, the abnormal triggering is transformed from a qualitative judgment to a quantitative judgment of an adjustable parameter.

[0081] The first and second thresholds can be fixed thresholds or adaptive thresholds. When an adaptive threshold is used, the threshold range can be determined based on statistics from the historical window, including the mean, standard deviation, quantiles, or absolute deviation of the median. By introducing an adaptive threshold, anomaly detection can be adapted to the baseline differences of different services at different time periods, reducing the cost of manual threshold setting.

[0082] The associated anomaly score can be determined as follows: For and After normalization, the results are obtained by linear weighted summation. The weighting coefficients can be set according to the business's sensitivity to performance, indicator noise level, or historical false alarm rate. By outputting continuous scores, alarm classification and action intensity selection can be supported based on the score value, thereby improving the precision of the handling.

[0083] The associated anomaly label may include at least one of the following: indicator pair identifier, window time range, peak corresponding time lag, correlation strength, correlation direction feature, anomaly type candidate and confidence information; by carrying key correlation features in the label, traceable evidence can be retained in alarm and handling records, which is convenient for subsequent review and strategy iteration.

[0084] By simultaneously constraining the decrease in correlation strength and the abrupt change in time lag, the probability of false alarms caused by short-term noise, sampling jitter, or instantaneous spikes can be reduced, making anomaly triggering more stable. Furthermore, by outputting the correlation anomaly score, the severity of anomalies can be quantified, which can be integrated or ranked with other triggering conditions, thereby improving the reliability of adjustment decisions.

[0085] As one implementation method, determining the adjustment operation in this embodiment includes: classifying the anomaly type based on the associated anomaly label and the direction and / or magnitude of the time lag change, wherein the anomaly type includes at least resource saturation anomaly and load growth anomaly;

[0086] When the classification result is a resource saturation anomaly, dynamic calibration of resource specifications should be performed first.

[0087] When the classification result is a load growth anomaly, prioritize performing elastic scaling of the number of instances;

[0088] A minimum interval or hysteresis range is set for the selection to suppress the frequent switching of the adjustment operation between dynamic calibration of resource specifications and elastic scaling of the number of instances.

[0089] The anomaly type classification can be based on at least one of the following rules: when the peak value corresponds to a positive time lag and shows an increasing trend in adjacent windows, and the processor utilization and / or memory working set usage are in a high range, the anomaly is determined to be a resource saturation anomaly; when the peak value corresponds to a negative time lag or changes from positive to negative, and the request volume-related indicators or request error rate and request response latency deteriorate synchronously, the anomaly is determined to be a load growth anomaly; by introducing the discrimination rules for the direction and magnitude of the time lag, the time-series information of "whether resources change first or performance changes first" can be transformed into executable classification conditions, thereby improving the targeting of strategy selection.

[0090] The positive and negative judgment of the time lag follows the above cross-correlation lag convention; when the cross-correlation implementation adopts different lag definitions, the positive and negative interpretation and classification rules are adjusted synchronously to avoid misclassification of resource saturation anomalies and load growth anomalies due to inconsistent symbol semantics.

[0091] The anomaly type classification can output candidate classification results and candidate confidence scores for each indicator pair in the case of multiple indicator pairs, and obtain the final classification result based on the maximum confidence score or weighted voting; or it can perform classification only on representative indicator pairs. By clarifying the classification aggregation method of multiple indicator pairs, it can ensure that the classification output is consistent with the aforementioned cross-correlation aggregation strategy, thereby improving consistency and maintainability.

[0092] The resource saturation anomaly can be further subdivided into computing resource saturation and memory resource saturation: when the resource metric more strongly associated with request response latency or request error rate is processor utilization, it is preferentially determined to be computing resource saturation; when the resource metric more strongly associated with memory working set usage, it is preferentially determined to be memory resource saturation. By subdividing the saturation type, a clearer resource dimension can be provided for dynamic calibration of resource specifications, reducing unnecessary simultaneous increases in resources.

[0093] The load growth anomaly can be further confirmed by combining the rate of change of application-side runtime metrics: when the rate of change of request response latency and request error rate continues to rise within multiple consecutive windows, the confidence of the load growth anomaly is increased; by confirming the rate of change, misclassification caused by occasional external dependency jitter can be reduced.

[0094] The minimum interval time can be set to a first interval and a second interval for the same running instance. The first interval is used to limit the frequency of continuous execution of dynamic calibration of resource specifications, and the second interval is used to limit the frequency of continuous execution of elastic scaling of the number of instances. By setting the intervals separately, the characteristics of different effective times and costs of the two types of adjustment actions can be adapted, thereby reducing the instability caused by frequent changes.

[0095] The hysteresis interval may include score hysteresis and state hysteresis: when the associated abnormal score enters the first trigger interval, the trigger is allowed to be triggered, and when the associated abnormal score falls back to the second recovery interval, the trigger is allowed to be deactivated. There is a preset difference between the second recovery interval and the first trigger interval. By setting the hysteresis interval, repeated triggering and deactivation near the threshold can be avoided, thereby suppressing policy jitter.

[0096] By classifying anomaly types and setting minimum intervals or hysteresis ranges, different priority actions can be taken in two scenarios: insufficient resource supply and changes in business load. This avoids repeated triggering of the two types of adjustments in a short period of time, which would cause policy oscillations, thereby improving service continuity and reducing the additional overhead caused by adjustments.

[0097] As one implementation method, in this embodiment, determining the adjustment operation includes:

[0098] The anomaly types are classified based on the associated anomaly labels and the direction and / or magnitude of the time lag change, and the anomaly types include at least resource saturation anomalies and load growth anomalies.

[0099] When the classification result is a resource saturation anomaly, dynamic calibration of resource specifications should be performed first.

[0100] When the classification result is a load growth anomaly, prioritize performing elastic scaling of the number of instances;

[0101] A minimum interval or hysteresis range is set for the selection to suppress the frequent switching of the adjustment operation between dynamic calibration of resource specifications and elastic scaling of the number of instances.

[0102] The anomaly type classification can be based on at least one of the following rules: when the peak value corresponds to a positive time lag and shows an increasing trend in adjacent windows, and the processor utilization and / or memory working set usage are in a high range, the anomaly is determined to be a resource saturation anomaly; when the peak value corresponds to a negative time lag or changes from positive to negative, and the request volume-related indicators or request error rate and request response latency deteriorate synchronously, the anomaly is determined to be a load growth anomaly; by introducing the discrimination rules for the direction and magnitude of the time lag, the time-series information of "whether resources change first or performance changes first" can be transformed into executable classification conditions, thereby improving the targeting of strategy selection.

[0103] The positive and negative judgment of the time lag follows the above cross-correlation lag convention; when the cross-correlation implementation adopts different lag definitions, the positive and negative interpretation and classification rules are adjusted synchronously to avoid misclassification of resource saturation anomalies and load growth anomalies due to inconsistent symbol semantics.

[0104] The anomaly type classification can output candidate classification results and candidate confidence scores for each indicator pair in the case of multiple indicator pairs, and obtain the final classification result based on the maximum confidence score or weighted voting; or it can perform classification only on representative indicator pairs. By clarifying the classification aggregation method of multiple indicator pairs, it can ensure that the classification output is consistent with the aforementioned cross-correlation aggregation strategy, thereby improving consistency and maintainability.

[0105] The resource saturation anomaly can be further subdivided into computing resource saturation and memory resource saturation: when the resource metric more strongly associated with request response latency or request error rate is processor utilization, it is preferentially determined to be computing resource saturation; when the resource metric more strongly associated with memory working set usage, it is preferentially determined to be memory resource saturation. By subdividing the saturation type, a clearer resource dimension can be provided for dynamic calibration of resource specifications, reducing unnecessary simultaneous increases in resources.

[0106] The load growth anomaly can be further confirmed by combining the rate of change of application-side runtime metrics: when the rate of change of request response latency and request error rate continues to rise within multiple consecutive windows, the confidence of the load growth anomaly is increased; by confirming the rate of change, misclassification caused by occasional external dependency jitter can be reduced.

[0107] The minimum interval time can be set to a first interval and a second interval for the same running instance. The first interval is used to limit the frequency of continuous execution of dynamic calibration of resource specifications, and the second interval is used to limit the frequency of continuous execution of elastic scaling of the number of instances. By setting the intervals separately, the characteristics of different effective times and costs of the two types of adjustment actions can be adapted, thereby reducing the instability caused by frequent changes.

[0108] The hysteresis interval may include score hysteresis and state hysteresis: when the associated abnormal score enters the first trigger interval, the trigger is allowed to be triggered, and when the associated abnormal score falls back to the second recovery interval, the trigger is allowed to be deactivated. There is a preset difference between the second recovery interval and the first trigger interval. By setting the hysteresis interval, repeated triggering and deactivation near the threshold can be avoided, thereby suppressing policy jitter.

[0109] By classifying anomaly types and setting minimum intervals or hysteresis ranges, different priority actions can be taken in two scenarios: insufficient resource supply and changes in business load. This avoids repeated triggering of the two types of adjustments in a short period of time, which would cause policy oscillations, thereby improving service continuity and reducing the additional overhead caused by adjustments.

[0110] As one implementation method, the dynamic calibration of resource specifications in this embodiment includes:

[0111] Within a preset time window, the statistical characteristic value of resource usage in the associated operational indicator time series is calculated; the deviation rate between the statistical characteristic value and at least one of the currently configured resource request value and resource limit value is calculated; when the deviation rate exceeds a preset adjustment threshold, new resource specification parameters are generated based on the statistical characteristic value, and the resource configuration of the running instance is updated. By dynamically calibrating the resource configuration based on the statistical characteristic value, resource idleness or contention caused by unreasonable resource request and limit value settings can be reduced while ensuring stable service operation, thereby improving cluster resource utilization and reducing performance fluctuations caused by insufficient resources.

[0112] As one implementation method, the elastic scaling of the number of instances in this embodiment includes:

[0113] The system monitors the rate of change of the application-side runtime metrics; when the rate of change exceeds a preset burst threshold, it calculates the load estimate for the next moment based on the rate of change; and before the platform-side resource metrics reach the expansion threshold, it increases the number of replicas of the running instance in advance. By using the rate of change of the application-side runtime metrics for proactive judgment, expansion can be carried out in advance before the platform-side resource metrics increase significantly, thereby reducing the risk of increased response latency or error rate caused by expansion lag, and thus improving service availability and user experience in burst traffic scenarios.

[0114] As one implementation method, this embodiment employs a rolling update strategy to gradually replace, rebuild, and / or add running instances during the adjustment operation; and monitors the readiness status of newly started running instances. If no readiness signal is detected within a preset time, the system automatically rolls back to the state before the adjustment. Using rolling updates can control the scope of the changes and maintain continuous service provision. Combined with readiness status detection and automatic rollback, it reduces the risk of failures caused by misconfigurations or incompatible changes, improving the security and success rate of the adjustment operation.

[0115] As one implementation method, in this embodiment, the running status is continuously monitored for a preset time after the adjustment operation is performed;

[0116] When it is detected that the application-side runtime metrics and / or the platform-side resource metrics no longer meet the preset stability conditions, a rollback operation is performed to undo the adjustment operation and / or restore the resource configuration and copy status before the adjustment.

[0117] The stability conditions include at least one of the following: error rate threshold, response latency threshold, availability threshold, and restart count threshold. By setting a stability observation period after adjustment and performing rollback based on the stability conditions, it is possible to avoid the adjustment actions causing hidden degradation in the short term and affecting business in the long term. This forms a mechanism for verifying the effect of the adjustment and mitigating risks, thereby improving the system's operational stability and closed-loop maintenance capabilities.

[0118] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for automated deployment and elastic scaling of containerized applications, characterized in that: The method includes: In response to a deployment request issued for a target application, at least one project file is obtained, the project file including at least one of a project build file and a project configuration file; the project file is parsed to extract project features, and build description information and deployment orchestration configuration for building a container image are generated based on the project features; The application image of the target application is constructed based on the construction description information; and the deployment orchestration configuration is distributed to the container orchestration platform to create a running instance of the target application in the container orchestration platform. During the operation of the running instance, operational metric data is collected, which includes at least platform-side resource metrics and application-side runtime metrics. Based on the runtime instance identifier, the platform-side resource metrics and the application-side runtime metrics are aligned and then aligned by timestamp to generate a time series of associated runtime metrics. Based on the associated time series of operational metrics, an adjustment operation is determined for the operational instance, and the adjustment operation includes at least one of dynamic calibration of resource specifications and elastic scaling of the number of instances. The adjustment operation is performed on the running instance through the container orchestration platform, and the execution result is output. Cross-domain association modeling based on the time series of the associated operational metrics includes: Within the sliding time window, calculate the cross-correlation function and determine the peak value and its corresponding time lag for at least the following two types of cross-domain indicator pairs: (1) Processor utilization and / or memory working set usage in platform-side resource metrics, and request response latency in application-side runtime metrics; (2) Processor utilization and / or memory working set usage in platform-side resource metrics, and request error rate in application-side runtime metrics; And calculate the correlation strength corresponding to the peak value of the cross-correlation function and the change in time lag between adjacent sliding time windows; Performing anomaly detection includes: When the correlation strength decreases by more than a first threshold between adjacent sliding time windows and the change in time lag exceeds a second threshold, the correlation anomaly score and / or correlation anomaly label are output. The correlation anomaly score is obtained by weighting the decrease in correlation strength with the change in time lag; and the correlation anomaly score and / or correlation anomaly label are used as one of the conditions for triggering the adjustment operation. The adjustment operation is determined to include: The anomaly types are classified based on the associated anomaly labels and the direction and / or magnitude of the time lag change, and the anomaly types include at least resource saturation anomalies and load growth anomalies. When the classification result is a resource saturation anomaly, dynamic calibration of resource specifications should be performed first. When the classification result is a load growth anomaly, prioritize performing elastic scaling of the number of instances; A minimum interval or hysteresis range is set for the selection to suppress frequent switching between dynamic calibration of resource specifications and elastic scaling of instance quantity in the adjustment operation; The hysteresis interval may include score hysteresis and status hysteresis: when the associated abnormal score enters the first trigger interval... Triggering adjustments is allowed, but the trigger can only be lifted when the associated abnormal score falls back to the second recovery zone. There is a preset difference between the threshold and the first trigger interval; by setting a hysteresis interval, repeated triggering near the threshold can be avoided. This releases the policy jitter, thereby suppressing it.

2. The method according to claim 1, characterized in that: Generating the deployment orchestration configuration includes: Obtain the environment identifier of the target deployment environment; generate basic configuration information based on the engineering characteristics and load the environment-differentiated configuration parameters corresponding to the environment identifier; merge the basic configuration information and the environment-differentiated configuration parameters to generate the deployment orchestration configuration suitable for the target deployment environment.

3. The method according to claim 1, characterized in that: The identifier alignment includes: The runtime metrics on the application side are attached with the runtime instance identifier or an associated tag that can be mapped to the runtime instance identifier; and the runtime metrics on the application side are time-series mapped to the resource metrics on the platform side based on the runtime instance identifier or the associated tag.

4. The method according to claim 1, characterized in that: The dynamic calibration of resource specifications includes: Within a preset time window, calculate the statistical characteristic value of resource usage in the associated operation indicator time series; calculate the deviation rate between the statistical characteristic value and at least one of the currently configured resource request value and resource limit value; when the deviation rate exceeds a preset adjustment threshold, generate new resource specification parameters based on the statistical characteristic value and update the resource configuration of the running instance.

5. The method according to claim 1, characterized in that: The elastic scaling of the number of instances includes: Monitor the rate of change of the application-side runtime metrics; when the rate of change exceeds a preset burst threshold, calculate the load estimate for the next moment based on the rate of change; and increase the number of replicas of the running instance in advance before the platform-side resource metrics reach the expansion threshold.

6. The method according to claim 1, characterized in that: When performing the adjustment operation, a rolling update strategy is used to gradually replace, rebuild and / or add the running instances; and the readiness status of the newly started running instances is monitored. If no readiness signal is detected within a preset time, the system will automatically roll back to the state before the adjustment.

7. The method according to claim 1, characterized in that: After performing the adjustment operation, the running status is continuously monitored for a preset duration; When it is detected that the application-side runtime metrics and / or the platform-side resource metrics no longer meet the preset stability conditions, a rollback operation is performed to undo the adjustment operation and / or restore the resource configuration and copy status before the adjustment. The stability conditions include at least one of the following: error rate threshold condition, response latency threshold condition, availability threshold condition, and restart count threshold condition.

Images