Container resource allocation method, system, equipment, medium and product

Abstract

The invention provides a container resource allocation method, system and device, a medium and a product, and belongs to the technical field of computers, and the method comprises the following steps: collecting a multi-dimensional operation index of a first container; predicting a first quota recommendation value of at least one target resource of the first container based on the multi-dimensional operation index; after the first container meets the dynamic adjustment condition and it is monitored that a target event of a container group where the first container is located is triggered, performing hot modification on the target resources based on first quota recommendation values of the target resources of all second containers in the container group; the dynamic adjustment condition is that the difference value between the first quota recommendation value of the target resource and the current quota value of the target resource is greater than a preset threshold value. According to the method, the adjustment opportunity of the resource quota is combined with the natural life cycle of the container, and the resource is automatically adjusted according to the predicted resource quota only in the normal reconstruction scene of the container group, so that service interruption is avoided, and the running continuity of the application is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a container resource configuration method, system, device, medium and product. Background Technology

[0002] With the rapid development of cloud computing technology, containerized deployment, with its lightweight, efficient, and portable characteristics, has become the mainstream method for application deployment in microservice architectures. Kubernetes, as the most popular container cluster, is responsible for scheduling, resource allocation, and lifecycle management of container clusters. Among them, the resource quota configuration of containers, such as central processing unit (CPU) and memory, directly affects the application's running stability and the utilization efficiency of cluster resources.

[0003] In practical applications, configuring container resource quotas faces two major challenges: First, if the resource quota is configured too low, containers may experience Out Of Memory (OOM) errors or CPU throttling due to insufficient resources, leading to application lag, crashes, and other failures. Second, if the resource quota is configured too high, it will waste cluster resources and reduce the overall resource utilization of the cluster. Traditional resource quota configuration methods mainly rely on the experience of operations personnel for static settings. This approach cannot adapt to dynamic changes in application load and is no longer sufficient to meet the management needs of large-scale, highly dynamic container clusters.

[0004] To address the limitations of static configuration, the Kubernetes community introduced Vertical Pod Autoscaler (VPA). Its core function is to dynamically adjust the CPU and memory quotas of containers based on their historical resource usage data. However, VPA's dynamic adjustment mechanism still has significant drawbacks in practical applications. It requires restarting containers when adjusting resource quotas, which can lead to application service interruptions. For stateless applications, brief service interruptions may be mitigated by the retry mechanism of a load balancer. However, for stateful applications, especially core business systems with extremely high service availability requirements such as finance and e-commerce, service interruptions can lead to data write failures, connection drops, and even serious problems such as data inconsistencies and transaction failures, severely impacting application availability. This significantly limits the application of VPA in critical business scenarios. Summary of the Invention

[0005] This application provides a container resource configuration method, system, device, media, and product, aimed at addressing the issue of VPA's dynamic adjustment mechanism requiring container restarts, which leads to service interruptions.

[0006] Firstly, this application provides a container resource configuration method, including: Collect multi-dimensional operational metrics for the first container; Based on multi-dimensional operational metrics, predict the recommended first quota value for at least one target resource in the first container; After the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group. The dynamic adjustment condition is that the difference between the first recommended quota value of the target resource and the current quota value of the target resource is greater than a preset threshold.

[0007] In one embodiment, after the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group, specifically including: When a target event of a container group is detected, the first quota recommendation value of all target resources of all second containers within the container group is extracted based on the unique identifier of the container group. During the target event, the current quota value of the target resource is modified based on the first quota recommendation value of the target resource in the second container; The recommended value of the first quota is validated based on resource constraint rules; If the verification is successful, the recommended first quota value will be retained.

[0008] In one embodiment, it further includes: If the verification fails, the target resource will be modified according to the default quota of the target resource in the second container.

[0009] In one embodiment, predicting a first quota recommendation value for at least one target resource of the first container based on multi-dimensional operational metrics specifically includes: Extracting the time dimension features of multi-dimensional operational metrics; Extract the correlation features between different indicators in multi-dimensional operational metrics; Predict a second quota recommendation value for at least one target resource in the first container based on time dimension features and correlation features; The first quota recommendation value is determined based on the second quota recommendation value.

[0010] In one embodiment, determining the first quota recommendation value based on the second quota recommendation value specifically includes: The second quota recommendation value is modified by combining the resource constraint rules and the business rules corresponding to the application type encapsulated in the first container, to obtain the first quota recommendation value.

[0011] In one embodiment, the target events include workload update events for the container group and fault self-healing events for the container group.

[0012] In one embodiment, the triggering conditions for the target event include listening to a target event of a container group triggered by the controller of the container cluster, or listening to a target event of a container group with a target tag.

[0013] In one embodiment, if the same target event is detected multiple times within a preset time interval, only the first instance is determined to satisfy the triggering condition of the target event.

[0014] In one embodiment, determining the dynamic adjustment conditions of the first container specifically includes: The dynamic adjustment conditions are determined based on the type of application encapsulated in the first container and / or the application's business cycle.

[0015] Secondly, this application also provides a container resource configuration system, including: The multi-dimensional data acquisition module is used to collect multi-dimensional operational metrics of the first container. The resource demand forecasting module is used to predict the first quota recommendation value of at least one target resource in the first container based on multi-dimensional operation indicators. The configuration module is used to hot modify the target resources based on the first quota recommendation value of the target resources of all second containers in the container group after the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered. The dynamic adjustment condition is that the difference between the first recommended quota value of the target resource and the current quota value of the target resource is greater than a preset threshold.

[0016] In one embodiment, the container resource configuration system is integrated into the target platform; Target platforms include cloud-native operations and maintenance management platforms, containerized application delivery tools, or hybrid cloud container management systems; Among them, containerized application delivery tools include continuous integration and continuous delivery deployment toolchain components for development teams.

[0017] In one embodiment, the access control module registers with the target platform based on an access control mechanism.

[0018] In one embodiment, the multi-dimensional data acquisition module adopts a plug-in architecture and interfaces with at least one of the following: Monitoring components for container clusters; ELK stack; Cloud-native monitoring platform; Presentation layer state transition application programming interface.

[0019] Thirdly, this application also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-described container resource configuration methods.

[0020] Fourthly, this application also provides a non-transitory computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements any of the above-described container resource configuration methods.

[0021] Fifthly, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements any of the above-described container resource configuration methods. Attached Figure Description

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

[0023] Figure 1 This is one of the flowcharts illustrating the container resource configuration method provided in this application; Figure 2 This is one of the flowcharts provided in this application for predicting the first quota recommendation value of at least one target resource of the first container based on multi-dimensional operational indicators; Figure 3 This is one of the flowcharts provided in this application for hot modification of target resources based on the first quota recommendation value of target resources in all second containers within a container group; Figure 4 One of the structural diagrams of the container resource configuration system provided in this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0026] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects have an "or" relationship.

[0027] As mentioned above, the core goal of VPA is to "dynamically adjust resources to match the load," ignoring the negative impact of service interruptions caused by restarting containers during dynamic adjustments. Therefore, how to achieve accurate and dynamic configuration of container resource quotas while avoiding container restarts and ensuring application service continuity has become a key technical problem that urgently needs to be solved in the current Kubernetes container cluster management field.

[0028] Based on these considerations, this application provides a container resource configuration method, system, device, medium, and product. It should be noted that this application is applicable to the dynamic configuration of container resources for both stateless and stateful applications.

[0029] The following is combined with Figures 1 to 5 This application describes the container resource configuration methods, systems, devices, media, and products provided.

[0030] It should be noted that the container resource configuration method provided in this application embodiment is implemented based on the container resource configuration system. The container resource configuration method breaks through the traditional VPA active restart mode through the core process of "multi-dimensional data collection - resource demand prediction - timing configuration". It binds the adjustment of resource quota with the natural reconstruction of container group Pods (such as workload update and fault self-healing), fundamentally avoiding service interruption and ensuring the continuity of application services.

[0031] This application uses a container resource configuration system as the execution subject to describe the container resource configuration method.

[0032] Figure 1 This is one of the flowcharts illustrating the container resource configuration method provided in this application.

[0033] like Figure 1 As shown, the container resource configuration method provided in this application includes: S110: Collect multi-dimensional operational metrics of the first container.

[0034] VPA only recommends resources based on two basic metrics: CPU utilization and memory utilization. It does not consider multi-dimensional factors such as application business characteristics and load type, which limits the accuracy of resource prediction. For example, for I / O intensive applications such as file servers, excessive disk I / O load may lead to application performance degradation, but VPA cannot detect such metrics. The resource quota recommended by VPA may not match the actual load demand. As another example, the load of an application during peak business periods (such as e-commerce "Double Eleven") differs greatly from the daily load. VPA's prediction based solely on historical average data is insufficient to cope with sudden high load scenarios, which can easily lead to insufficient or excessive resource allocation.

[0035] Based on the above, the multi-dimensional operational metrics in this application include at least several dimensions such as resources, IO, network, and business. Resource-related metrics include CPU utilization (unit: cores), average CPU load (e.g., the average number of active processes over 1 minute, 5 minutes, or 15 minutes), memory utilization (unit: GB), and memory page miss rate. IO-related metrics include disk IOPS (Input / Output Per Second), disk throughput (read / write, unit: MB / s), and disk wait time (unit: ms). Network-related metrics include network bandwidth (input / output, unit: Mbps), number of network connections (TCP (Transmission Control Protocol) / UDP (User Datagram Protocol)), and network packet loss rate (unit: %). Business-related metrics include application request queries per second (QPS; unit: times / second), request response time (P95 / P99, unit: ms), number of concurrent users, and business transaction success rate.

[0036] Please combine Figure 4 The following uses a Kubernetes cluster as an example to illustrate the data collection method.

[0037] In one possible implementation, basic resource metrics such as CPU and memory are collected in real time via the KubernetesMetrics API, with a collection period of 10 seconds.

[0038] In one possible implementation, IO and network metrics are collected through the monitoring system Prometheus, combined with node-exporter (a node-level monitor) and cadvisor (a container-level monitor). The collection period can be set to 20 seconds.

[0039] In one possible implementation, for business metrics, users can report them through a custom metric API interface (such as Prometheus Adapter), and the collection period can be configured according to business needs (such as 15 seconds).

[0040] In one possible implementation, the collected multi-dimensional operational metrics data is stored in a historical database (such as InfluxDB), with a configurable retention period (such as 30 days), for subsequent trend analysis and prediction. Figure 4 As shown.

[0041] S120: Predict the first quota recommendation value for at least one target resource of the first container based on multi-dimensional operational metrics.

[0042] Specifically, a predictive model is used to predict the recommended value of the first quota. The input data of the predictive model consists of multi-dimensional operational metrics of the container, and the output data consists of the recommended value of the first quota for each target resource of the container. The predictive model is trained using a dataset composed of multi-dimensional historical operational metrics and historical quotas for each target resource.

[0043] In one possible implementation, the prediction model employs a Long Short-Term Memory (LSTM) network. The LSTM model processes multi-dimensional operational metric data to predict the average and peak CPU (target resource) and memory (target resource) demands of the container within a preset future timeframe, thereby determining recommended CPU and memory quotas. (See [link to relevant documentation]). Figure 4 .

[0044] To improve prediction accuracy, this application dynamically updates the prediction model to ensure that the prediction accuracy adapts to changes in load. Dynamic updates include two methods: timed retraining and incremental learning.

[0045] During scheduled retraining, the LSTM model is retrained based on the latest data from the past 7 days during the daily off-peak business hours (e.g., early morning) to update the model parameters and ensure that the model can adapt to long-term changes in application load, such as increased load due to business growth.

[0046] When a sudden change in application load is detected, such as a sudden increase in QPS of 200%, an incremental learning process is triggered. The model is fine-tuned using only the latest data from the change, avoiding the resource consumption and time delay of full retraining.

[0047] S130: After the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group.

[0048] In one possible implementation, the first container satisfies the dynamic adjustment condition when the difference between the first quota recommendation value and the current quota value of at least one target resource in the first container is greater than a preset threshold.

[0049] In one possible implementation, when the container resource configuration system of this application is integrated with a Kubernetes cluster, the target events of the container group Pod where the container resides are monitored through the Kubernetes API Server of the Kubernetes cluster. (See [link to relevant documentation]). Figure 4 When the Kubernetes API Server detects that a target event of a container group has been triggered, the target resources of the second container within the container group can be dynamically configured. See [link to documentation]. Figure 4 .

[0050] In this application, the dynamic configuration of the target resources in the container is only triggered when the container group Pod is rebuilt due to normal business needs or fault self-healing, so as to avoid application service interruption caused by actively restarting the container group Pod.

[0051] In one possible implementation, the target events include workload update events for the container group and fault self-healing events for the container group.

[0052] In one possible implementation, please combine Figure 4 When the image version of the workload controller Deployment / StatefulSet in the Kubernetes cluster needs to be updated or the configuration file needs to be modified, Kubernetes needs to delete the old container group Pod and create a new container group Pod. During this process, the quota of the target resource is dynamically modified to achieve dynamic configuration of the target resource.

[0053] In one possible implementation, if a health check of the container group Pod using the liveness probe and readiness probe fails, the container group Pod needs to be restarted. During the restart process, the quota of the target resource is dynamically modified, achieving dynamic configuration of the target resource. It should be noted that the container group Pod restart here is a self-healing event triggered by its own needs, rather than a proactive restart of the container group Pod to update the configuration of the target resource.

[0054] In one possible implementation, if a node in a container group Pod fails, the container group Pod needs to be rescheduled. During the rescheduling process, the quota of the target resource is dynamically modified to achieve dynamic configuration of the target resource.

[0055] This application combines the timing of resource quota adjustments with the natural lifecycle of containers. Resources are automatically adjusted based on the predicted resource quota only during normal rebuilding scenarios such as business updates or fault self-healing of container group Pods. This eliminates the need to actively trigger container group Pod restarts, fundamentally avoiding service interruptions caused by restarting container group Pods for resource adjustments and ensuring application continuity. Furthermore, this application adds monitoring data for multiple dimensions, including IO, network, and business metrics. By integrating multi-dimensional data, it provides a more comprehensive understanding of application load characteristics, generating resource quota recommendations that better meet actual needs and effectively avoiding configuration deviations.

[0056] In one possible implementation, such as Figure 2 As shown, in step S120, predicting the first quota recommendation value for at least one target resource in the first container based on multi-dimensional operational indicators specifically includes: S1210: The predictive model extracts the time dimension features of multi-dimensional operating indicators.

[0057] Specifically, the time dimension features of the data are extracted from the multi-dimensional operational indicator data. The time dimension can be features for preset time intervals (e.g., 0:00 to 23:00), features for working status (e.g., weekdays and / or weekends), features for business volume (e.g., business peak periods, such as the user-preset 9:00-21:00), etc.

[0058] S1220: The predictive model extracts the correlation features between different indicators in the multi-dimensional operational indicators.

[0059] In one possible implementation, the associated features include: The ratio of request QPS to CPU utilization is a correlation feature that reflects the application's CPU efficiency. The ratio of memory utilization to the number of concurrent users is a correlation feature that reflects the memory consumption of a single user.

[0060] S1230: The prediction model predicts a second quota recommendation value for at least one target resource in the first container based on time dimension features and correlation features.

[0061] S1240: The prediction model determines the first quota recommendation value based on the second quota recommendation value.

[0062] Understandably, prior to step S1210, data preprocessing is performed on the multi-dimensional operational metrics (see [link]). Figure 4 This allows the data to better reflect the container's operational status. Data preprocessing can include outlier handling, missing value imputation, and data smoothing.

[0063] In one possible implementation, the 3σ principle is used to remove extreme outlier data, such as a momentary CPU utilization of 1000% due to a container failure.

[0064] In one possible implementation, linear interpolation is used to fill in missing data for short periods of time (such as the loss of 1-2 collection points due to network fluctuations).

[0065] In one possible implementation, a moving average algorithm is used to smooth short-term fluctuating data, highlighting load trends. In another possible implementation, the window size is set to 5 minutes.

[0066] In one possible implementation, after step S1240, all feature values ​​are normalized to the [0,1] interval to avoid affecting the model prediction accuracy due to differences in the magnitude of the indicators.

[0067] This application embodiment improves the accuracy of the model's prediction results by extracting the correlation features between indicators to enable the model to learn the mutual influence between indicators and combining time dimension features to predict the quota recommendation value.

[0068] In one possible implementation, step S1240, determining the first quota recommendation value based on the second quota recommendation value, specifically includes: The second quota recommendation value is modified by combining the resource constraint rules and the business rules corresponding to the application type encapsulated in the first container, to obtain the first quota recommendation value.

[0069] Resource constraint rules are safeguards that ensure the normal operation of container group Pods. For example, if the predicted peak CPU demand exceeds 80% of the remaining CPU resources of the node scheduling the container group Pod, it will be reduced to 70% of the node's remaining CPU resources to avoid exhausting the node's resources.

[0070] Different application types have different characteristics and corresponding business rules. By adjusting the model prediction results according to the business rules, we can ensure that the recommended quota value is more in line with the actual needs of the container. For example, if the application is a database service, during adjustment, an additional 20% redundancy is added to the predicted recommended memory quota value to ensure data caching requirements.

[0071] This application combines model prediction results with rule-based correction operations to improve the accuracy of resource recommendations.

[0072] VPA's resource adjustment thresholds and cycles are fixed configurations and cannot be customized based on application importance, business cycles, etc. For example, for core business applications, operations personnel may want to adjust resources only when the configuration is severely unreasonable (e.g., the difference exceeds 50%) to reduce the frequency of adjustments; while for non-core applications, a lower adjustment threshold can be set to improve resource utilization, but VPA cannot meet such differentiated needs.

[0073] In one possible implementation, the dynamic adjustment conditions of the first container are determined, specifically including: The dynamic adjustment conditions are determined based on the type of application encapsulated in the first container and / or the application's business cycle.

[0074] In one possible implementation, for applications of higher importance, the preset threshold for triggering dynamic adjustments is increased; for applications of lower importance, the preset threshold for triggering dynamic adjustments is decreased. For example, for core applications, resource quota adjustments are only made when the difference between the recommended quota value and the current quota value of the target resource exceeds 50% (the preset threshold). For non-core applications, resource quota adjustments can be made when the difference between the recommended quota value and the current quota value of the target resource exceeds 20% (the preset threshold).

[0075] One possible implementation is to disable resource quota adjustments when the containerized application experiences high traffic. For example, during peak business hours (such as 9:00-21:00), quota adjustments for target resources are disabled to avoid impacting business operations.

[0076] The embodiments of this application flexibly adjust the triggering strategy for dynamic configuration of resource quotas according to application type and business cycle, meet differentiated management needs, and improve the flexibility and practicality of the system.

[0077] In one possible implementation, in step S130, the triggering conditions for the target event include listening to a target event of a container group triggered by the controller of the container cluster, or listening to a target event of a container group with a target label.

[0078] Specifically, to accurately identify when a "target event is triggered," embodiments of this application design multi-dimensional event filtering rules, including: Event-based filtering: The target event is considered triggered only when a container group Pod is rebuilt by a controller of the container cluster (such as a Kubernetes controller Deployment, StatefulSet, or DaemonSet), thus triggering dynamic configuration of the target resource. This mechanism excludes active operations such as manually deleting a container group Pod using the command `kubectl delete pod` or manually adjusting the number of replicas using the command `kubectl scale`.

[0079] Application-based tag filtering: Users can add target tags to container group Pods of core applications. Only container group Pods with the target tag can recognize that a target event has been triggered when listening for that event, thus initiating dynamic configuration of the target resource. Under this mechanism, non-core applications without the target tag are disabled from dynamic configuration of target resources.

[0080] The embodiments of this application filter target events from multiple dimensions based on actual needs, thereby improving system flexibility.

[0081] Based on the above, in one possible implementation, in step S130, if the same target event is detected multiple times within a preset time interval, only the first one is determined to meet the triggering condition of the target event.

[0082] This application's embodiments filter target events based on time intervals. For example, if a Pod in the same container group triggers multiple rebuild events within 5 minutes (e.g., due to a failure causing frequent restarts of the Pod), the target event is only considered to have been triggered during the first rebuild event, thus triggering dynamic configuration of the target resource. Subsequent Pod rebuild events reuse the target resource configuration from the first event, avoiding redundant calculations and resource fluctuations.

[0083] In one possible implementation, such as Figure 3 As shown, in step S130, after the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group. Specifically, this includes: S1310: When a target event of a container group is detected, extract the first quota recommendation value for all target resources of all second containers within the container group based on the unique identifier of the container group.

[0084] In one possible implementation, in step S120, after obtaining the first quota recommendation value of at least one target resource of the first container, the first quota recommendation values ​​of all target resources of the first container are stored in the recommendation value database.

[0085] When a target event of a container group is triggered, the system queries the recommended first quota values ​​for all target resources of all second containers within that container group Pod from the recommended value database, based on the unique identifier of the container group Pod (such as the container group name and namespace). If a recommended first quota value exists for at least one target resource (e.g., CPU or memory) of at least one second container, then that recommended first quota value is extracted. If no recommended first quota value exists, for example, if the container group Pod is being created for the first time and there is no historical data, then the user-preset default quota for the target resource is used to configure the target resource.

[0086] In one possible implementation, an admission control mechanism is used to automatically inject the recommended quota value of the target resource into the configuration of the container group Pod without manual intervention.

[0087] Taking a Kubernetes cluster as an example, when the Kubernetes API Server receives a rebuild request for a container group Pod, it forwards the request to the Kubernetes cluster's admission control module. The admission control module retrieves the corresponding recommended CPU and memory quotas from the recommendation database based on the unique identifier of the container group Pod.

[0088] S1320: During the execution of the target event, modify the current quota value of the target resource based on the first quota recommendation value of the target resource in the second container.

[0089] Specifically, the admission control module modifies the YAML configuration of the container group Pod to inject the recommended quota value of the target resource into the configuration of the container group Pod.

[0090] Here is an example: If an application's container group Pod has an original CPU quota of 1 core and a memory quota of 2GB, and the system predicts a recommended value of 1.5 CPU cores and 2.5GB memory, when the container group Pod is rebuilt due to a Deployment image update, the admission control module will automatically modify the CPU quota of the new container group Pod to 1.5 cores and the memory quota to 2.5GB.

[0091] S1330: Verify the recommended value of the first quota based on the resource constraint rules. If the verification is successful, proceed to step S1340; otherwise, proceed to step S1350.

[0092] After the recommended quota value is injected, the admission control module will verify the modified container group Pod configuration to ensure that the configuration complies with the resource constraint rules of the container cluster, such as whether it exceeds the remaining resources of the node, and whether the minimum resource Requests value required by the container is not greater than the maximum resource limits value that the container can use.

[0093] S1340: Verification successful. The recommended first quota value for the target resource is retained; that is, the target resource will be configured according to the recommended first quota value. Please refer to [link / reference]. Figure 4 .

[0094] S1350: Verification failed. Modify the target resource according to the default quota of the target resource in the second container.

[0095] A verification failure indicates that the recommended quota value does not meet the resource constraints of the container cluster, such as the recommended CPU quota exceeding the node's remaining CPU resources. In this case, it will automatically fall back to the user-preset default quota for the target resource, and a log will be logged. The log includes the reason for the failure, the recommended value, and the default value, facilitating troubleshooting by operations personnel. Please refer to the log. Figure 4 .

[0096] In this embodiment of the application, after injecting the recommended quota value of the target resource into the container group Pod, the configuration is also verified based on the resource constraint rules to ensure that the configuration of the container group Pod meets the operating requirements.

[0097] The following example, using the "product details page service" of an e-commerce platform, further illustrates the practical application effect of this application: Scenario Background: This service is a stateless application deployed in a Kubernetes cluster, managed by Deployments, with 3 replicas, an initial CPU quota of 1 core, and a memory quota of 2GB. During peak business hours (10:00-12:00 and 20:00-22:00 daily), the QPS can reach 5000, while the daily QPS is approximately 1000. Adjustments to traditional VPAs can cause brief service interruptions, impacting user experience.

[0098] Application process of this application: Data Acquisition: The system collects the following data in real time: CPU utilization (peak hours up to 80%, daily hours 30%), memory utilization (peak hours 75%, daily hours 40%), network bandwidth (peak hours 100Mbps, daily hours 20Mbps), QPS (5000 / 1000), and response time (peak hours P95 150ms, daily hours P95 50ms). Predictive Recommendation: The prediction model combines time characteristics (identifying peak periods) with business metrics, predicting that peak periods require 1.5 CPU cores and 2.8GB of memory, while daily periods require 0.8 CPU cores and 1.5GB of memory. Configuration activation: Every Monday at 2:00 AM (off-peak business period), when the log configuration of the service is updated via Deployment (triggering a Pod rebuild event), the system will automatically adjust the new CPU quota to 0.8 cores and 1.5GB of memory; when a promotional activity causes the Deployment image to be updated (triggering a Pod rebuild event), the system will automatically adjust the quota to 1.5 cores and 2.8GB. Application effect: The entire process was uninterrupted, with ample resources during peak periods (response time remained stable within 150ms), and the daily resource waste rate was reduced from 40% to 10%.

[0099] Based on the above, this application also provides a container resource configuration system. The container resource configuration system and the container resource configuration method described above can be referred to in correspondence.

[0100] As an example, such as Figure 4 As shown, the container resource configuration system provided in this application includes a multi-dimensional data acquisition module 410, a resource demand prediction module 420, and a configuration module 430.

[0101] The multi-dimensional data acquisition module 410 is used to collect multi-dimensional operational metrics of the first container from the container cluster and monitoring system, providing data support for resource prediction.

[0102] The resource demand prediction module 420 is used to predict the first quota recommendation value of at least one target resource of the first container based on multi-dimensional operation indicators, which may include the container's CPU quota recommendation value, memory quota recommendation value, etc.

[0103] The configuration module 430 includes a recommended value database, which stores the first recommended quota values ​​for the target resources of each container. When the first container meets the dynamic adjustment conditions, the configuration module 430 uses the container cluster to listen for target events in the container group to which the first container belongs. When a target event of the container group is triggered, the configuration module 430 triggers the dynamic configuration of the container group. Specifically, after the target event of the container group to which the first container belongs is triggered, the target resources are hot-modified based on the first recommended quota values ​​of the target resources of all second containers in the container group. When a Pod is rebuilt, the recommended resource quotas are injected into the configuration of the new Pod through the Kubernetes admission control mechanism.

[0104] The dynamic adjustment condition is that the difference between the first recommended quota value of the target resource and the current quota value of the target resource is greater than a preset threshold.

[0105] This application combines the timing of resource quota adjustments with the natural lifecycle of containers. Resources are automatically adjusted based on the predicted resource quota only during normal rebuilding scenarios such as business updates or fault self-healing of container group Pods. This eliminates the need to actively trigger container group Pod restarts, fundamentally avoiding service interruptions caused by restarting container group Pods for resource adjustments and ensuring application continuity. Furthermore, this application adds monitoring data for multiple dimensions, including IO, network, and business metrics. By integrating multi-dimensional data, it provides a more comprehensive understanding of application load characteristics, generating resource quota recommendations that better meet actual needs and effectively avoiding configuration deviations.

[0106] In one possible implementation, the container resource configuration system is integrated into the target platform.

[0107] The target platforms include cloud-native operations and maintenance management platforms, containerized application delivery tools, or hybrid cloud container management systems.

[0108] The cloud-native operations and maintenance management platform is a Kubernetes cluster lifecycle management platform for medium and large enterprises, providing one-stop capabilities for cluster deployment, monitoring, resource optimization, and troubleshooting. The container resource configuration system in this application, serving as the "intelligent resource optimization module" of the cloud-native operations and maintenance management platform, automatically configures reasonable CPU and memory quotas for users' containers, reducing operational costs and improving cluster resource utilization.

[0109] Containerized application delivery tools are toolchain components for continuous integration (CI) / continuous delivery (CD) deployment for development teams, supporting end-to-end automation from code compilation and image building to Kubernetes deployment. The container resource configuration system in this application automatically predicts and recommends container resource quotas during application deployment (such as before executing `kubectl apply` in GitLab CI or Jenkins Pipeline), preventing developers from configuring unreasonable resource parameters due to lack of experience.

[0110] Hybrid cloud container management systems are container platforms that support unified management of public clouds (such as Alibaba Cloud / Huawei Cloud / AWS), private clouds, and edge nodes, suitable for enterprises deploying across clouds. The container resource configuration system in this application provides a unified resource recommendation strategy for container applications in different environments based on multi-dimensional monitoring data across clusters, solving the problem of inconsistent resource configuration standards in cross-cloud environments.

[0111] This application's embodiments are compatible with the native Kubernetes ecosystem and are developed based on native Kubernetes APIs (such as Metrics API and CustomResourceDefinition). They do not require modification of the Kubernetes kernel or core components and can be directly integrated into existing Kubernetes clusters. They also support compatibility with mainstream monitoring tools such as Prometheus and Grafana, reducing deployment and migration costs for users.

[0112] In one possible implementation, the configuration module 430 performs hot modification of the target resource through the access control module, which registers with the target platform based on the access control mechanism.

[0113] In one possible implementation, the admission control module of the container resource configuration system of this application is registered to the Kubernetes API Server in the form of MutatingAdmissionWebhook, and the triggering rule is configured to "only apply to Pod creation requests" to ensure that the resource quota injection operation is only performed when the Pod is rebuilt, without affecting the creation process of other Kubernetes resources.

[0114] This application embodiment interfaces with the native container cluster through an admission control module and reduces the impact on the creation process of other resources by limiting the trigger conditions.

[0115] In one possible implementation, to adapt to the monitoring systems of different users, this application supports multi-source data access. The multi-dimensional data acquisition module 410 adopts a plug-in architecture. In addition to interfacing with the default container cluster monitoring component Prometheus / Metrics API, it also interfaces with the ELK stack, cloud-native monitoring platform, and Representational State Transfer Application Programming Interface (REST API).

[0116] The ELK stack is used to collect business metrics from application logs, such as order volume and payment success rate. Cloud-native monitoring platforms, including Datadog and New Relic, are used to obtain container runtime data across clusters. REST APIs are used to custom-report private business metrics, such as real-time data transmission volume from IoT devices.

[0117] This application supports multi-source data access from Prometheus, ELK, third-party monitoring platforms, etc., adapting to the monitoring systems of different users and improving the system's compatibility and scalability.

[0118] Figure 5 This is a schematic diagram of the structure of the electronic device provided in this application, such as... Figure 5 As shown, the electronic device may include: a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communications interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute a container resource configuration method, which includes: Collect multi-dimensional operational metrics for the first container; Based on multi-dimensional operational metrics, predict the recommended first quota value for at least one target resource in the first container; Once the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group.

[0119] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] On the other hand, this application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the container resource configuration method provided in the above embodiments. The method includes: Collect multi-dimensional operational metrics for the first container; Based on multi-dimensional operational metrics, predict the recommended first quota value for at least one target resource in the first container; Once the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group.

[0121] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the container resource configuration method provided in the above embodiments, the method comprising: Collect multi-dimensional operational metrics for the first container; Based on multi-dimensional operational metrics, predict the recommended first quota value for at least one target resource in the first container; Once the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resource of all second containers in the container group.

[0122] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0123] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A container resource configuration method, characterized in that, include: Collect multi-dimensional operational metrics for the first container; Based on the multi-dimensional operational metrics, predict the first quota recommendation value for at least one target resource of the first container; After the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resources of all second containers in the container group. The dynamic adjustment condition is that the difference between the first recommended quota value of the target resource and the current quota value of the target resource is greater than a preset threshold.

2. The container resource configuration method according to claim 1, characterized in that, After the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered, the target resource is hot-modified based on the first quota recommendation value of the target resources of all second containers in the container group, specifically including: When the target event of the container group is triggered, the first quota recommendation value of all target resources of all second containers in the container group is extracted based on the unique identifier of the container group. During the execution of the target event, the current quota value of the target resource is modified based on the first quota recommendation value of the target resource in the second container; The recommended value of the first quota is verified based on resource constraint rules; If the verification is successful, the first quota recommendation value will be retained; If the verification fails, the target resource is modified according to the default quota of the target resource in the second container.

3. The container resource configuration method according to claim 1, characterized in that, The step of predicting the first quota recommendation value for at least one target resource of the first container based on the multi-dimensional operational metrics specifically includes: Extract the time dimension features of the multi-dimensional operational indicators; Extract the correlation features between different indicators in the multi-dimensional operational indicators; Based on the time dimension features and the correlation features, predict the second quota recommendation value for at least one target resource of the first container; The first quota recommendation value is determined based on the second quota recommendation value.

4. The container resource configuration method according to claim 3, characterized in that, The step of determining the first quota recommendation value based on the second quota recommendation value specifically includes: The second quota recommendation value is modified by combining the resource constraint rules and the business rules corresponding to the application type encapsulated in the first container, so as to obtain the first quota recommendation value.

5. The container resource configuration method according to claim 1, characterized in that, The target events include the workload update event of the container group and the fault self-healing event of the container group.

6. The container resource configuration method according to claim 1, characterized in that, The triggering conditions for the target event include listening to the target event of the container group triggered by the controller of the container cluster, or listening to the target event of the container group with a target tag.

7. The container resource configuration method according to claim 6, characterized in that, If the same target event is detected multiple times within a preset time interval, only the first detection will be considered as meeting the triggering condition of the target event.

8. The container resource configuration method according to claim 1, characterized in that, Determining the dynamic adjustment conditions for the first container specifically includes: The dynamic adjustment conditions are determined based on the type of application encapsulated in the first container and / or the business cycle of the application.

9. A container resource allocation system, characterized in that, include: The multi-dimensional data acquisition module is used to collect multi-dimensional operational metrics of the first container. The resource demand prediction module is used to predict the first quota recommendation value of at least one target resource of the first container based on the multi-dimensional operation indicators. The configuration module is used to perform hot modification of the target resource based on the first quota recommendation value of the target resources of all second containers in the container group after the first container meets the dynamic adjustment conditions and the target event of the container group to which the first container belongs is triggered. The dynamic adjustment condition is that the difference between the first recommended quota value of the target resource and the current quota value of the target resource is greater than a preset threshold.

10. The container resource allocation system according to claim 9, characterized in that, The container resource configuration system is integrated into the target platform; The target platform includes a cloud-native operation and maintenance management platform, a containerized application delivery tool, or a hybrid cloud container management system. The containerized application delivery tools include continuous integration and continuous delivery deployment toolchain components for development teams.

11. The container resource allocation system according to claim 9, characterized in that, The configuration module performs hot modification of the target resource through the access control module, and the access control module registers with the target platform based on the access control mechanism.

12. The container resource allocation system according to claim 9, characterized in that, The multi-dimensional data acquisition module adopts a plug-in architecture and interfaces with at least one of the following: Monitoring components for container clusters; ELK stack; Cloud-native monitoring platform; Presentation layer state transition application programming interface.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the container resource configuration method as described in any one of claims 1 to 8.

14. A non-transitory computer-readable storage medium, wherein a computer program is stored on the non-transitory computer-readable storage medium, characterized in that, When the computer program is executed by a processor, it implements the container resource configuration method as described in any one of claims 1 to 8.

15. A computer program product, the computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the container resource configuration method as described in any one of claims 1 to 8.

Images