Cyclic resource scheduling method, system and device based on Kubernetes and medium

Abstract

The invention discloses a cyclic resource scheduling method, system and device based on Kubernetes and a medium, and the method specifically comprises the steps: collecting resource use data of Pod and nodes in a Kubernetes cluster in real time, and predicting a load trend; dividing the resources into a hot resource pool, a cold resource pool and an idle resource pool based on the prediction results of the resource use data and the load trend; according to the electricity price and carbon emission data of each region, dynamically adjusting task distribution, and preferentially scheduling the task of the thermal resource pool to a region with a high renewable energy source proportion; for the cold resource pool and the idle resource pool, executing a progressive dormancy process by monitoring the power consumption change in real time; and training a reinforcement learning scheduling strategy by taking the queue length of the hot resource pool, the recovery time of the cold resource pool and the calling frequency of the idle resource pool as input. According to the invention, intelligent cyclic scheduling of Kubernetes cluster resources is realized, the resource utilization rate is improved, the energy consumption cost is reduced, the service continuity is guaranteed, and the intelligent level of scheduling decision is improved.

Description

Technical Field

[0001] This invention relates to the field of Kubernetes cluster technology, and in particular to a Kubernetes-based cyclic resource scheduling method, system, device, and medium. Background Technology

[0002] In today's digital age, Kubernetes (K8s), as an open-source container orchestration platform, has been widely adopted in the management and scheduling of containerized applications due to its powerful features. It provides efficient and flexible solutions for the deployment, operation, and maintenance of containerized applications, greatly promoting the development of cloud computing and container technology.

[0003] Currently, Kubernetes resource scheduling primarily relies on technologies such as Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), and Cluster Autoscaler to achieve dynamic scaling of resources. HPA automatically adjusts the number of Pod replicas based on metrics such as CPU utilization to cope with changes in business load; VPA focuses on adjusting the resource requests and limits of individual Pods to optimize resource allocation; and Cluster Autoscaler is responsible for dynamically adjusting the number of nodes based on the overall resource needs of the cluster to ensure that the cluster has sufficient computing power. In addition, serverless technologies (such as Knative and AWS Lambda) are suitable for on-demand computing of stateless tasks, and can automatically allocate and release resources based on actual requests.

[0004] However, these existing solutions have revealed many limitations in practical applications, specifically in the following aspects: 1. Low resource utilization: Existing scaling strategies mainly focus on basic metrics such as CPU and memory, lacking a deep understanding of business load. In actual business scenarios, different businesses have vastly different resource requirements. Adjusting resources based solely on limited metrics often fails to accurately match business needs, resulting in a large amount of resources being idle or underutilized, leading to low overall resource utilization and increased operating costs for enterprises.

[0005] 2. Inflexible Task Migration: Existing technologies struggle to enable dynamic and flexible task migration between different states. When faced with rapid changes in workload or unexpected situations, tasks cannot be promptly migrated from high-load areas to low-load areas, or rationally allocated based on resource availability and cost factors. This results in inflexible resource scheduling, failing to fully leverage the cluster's resource potential.

[0006] 3. The cold start problem is prominent: When a task recovers from a cold state to a hot state, it takes a long time to complete a series of operations such as resource allocation and initialization. During this period, the business will be unable to respond to requests normally, which will seriously affect business continuity and user experience. The cold start problem is particularly prominent in business scenarios with high real-time requirements, and may lead to serious consequences such as business interruption or even data loss.

[0007] 4. Insufficient resource recycling: For tasks that have been idle for a long time, existing technologies lack an effective resource recycling mechanism, failing to release these idle resources for other tasks in a timely manner, resulting in serious resource waste. As the scale of business continues to expand and the number of tasks in the cluster increases, this resource waste problem will become increasingly prominent, further reducing the cluster's resource utilization efficiency. Summary of the Invention

[0008] The purpose of this invention is to provide a cyclic resource scheduling method, system, device, and medium based on Kubernetes, which realizes intelligent cyclic scheduling of Kubernetes cluster resources, improves resource utilization, reduces energy consumption costs, ensures business continuity, and enhances the intelligence level of scheduling decisions, thereby solving at least one of the aforementioned problems in the prior art.

[0009] In a first aspect, the present invention provides a Kubernetes-based round-robin resource scheduling method, the method specifically comprising: Real-time collection of resource usage data for Pods and nodes in a Kubernetes cluster, combined with time series forecasting algorithms to predict load trends; Based on resource usage data and load trend prediction results, resources are divided into hot resource pools, cold resource pools and idle resource pools, and a migration cost model is constructed according to business priority. The migration cost model is used to avoid frequent interruptions of high-priority tasks. Based on electricity price and carbon emission data in each region, the task distribution will be dynamically adjusted, and priority will be given to scheduling tasks for the thermal resource pool to regions with a high proportion of renewable energy. For cold resource pools and idle resource pools, a gradual sleep process is executed by monitoring power consumption changes in real time. The queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool are used as inputs to train a reinforcement learning scheduling strategy based on the Ray RLlib framework.

[0010] Secondly, the present invention provides a Kubernetes-based circular resource scheduling system, the system specifically comprising: The first scheduling module is used to collect resource usage data of Pods and nodes in the Kubernetes cluster in real time, and combine it with time series prediction algorithms to predict load trends. The second scheduling module is used to divide resources into hot resource pools, cold resource pools and idle resource pools based on resource usage data and load trend prediction results, and to construct a migration cost model according to business priority. The migration cost model is used to avoid frequent interruptions of high-priority tasks. The third scheduling module is used to dynamically adjust the task distribution based on electricity price and carbon emission data in each region, and prioritize scheduling tasks from the thermal resource pool to regions with a high proportion of renewable energy. The fourth scheduling module is used to execute a gradual sleep process for the cold resource pool and the idle resource pool by monitoring power consumption changes in real time. The fifth scheduling module is used to train a reinforcement learning scheduling strategy based on the Ray RLlib framework, taking the queue length of the hot resource pool, the recovery time of the cold resource pool, and the calling frequency of the idle resource pool as input.

[0011] Thirdly, the present invention provides a computer device, including: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the Kubernetes-based round-robin resource scheduling method as described in any of the above methods.

[0012] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the Kubernetes-based round-robin resource scheduling method as described in any of the above methods.

[0013] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention realizes intelligent cyclic scheduling of Kubernetes cluster resources, which improves resource utilization, reduces energy consumption costs, ensures business continuity, and enhances the intelligence level of scheduling decisions.

[0014] 2. This invention accurately grasps the dynamics of resource usage and predicts load changes in advance, providing a basis for the rational allocation of resources and avoiding over-allocation or under-allocation of resources.

[0015] 3. This invention quantifies the cost of Pod migration and selects the optimal node during scheduling, effectively avoiding frequent interruptions of high-priority tasks and ensuring the stable operation of critical businesses.

[0016] 4. This invention incorporates green energy factors for task scheduling, reducing electricity costs and carbon emissions, thus achieving both economic and environmental benefits.

[0017] 5. This invention monitors power consumption in real time and allows nodes to hibernate appropriately, reducing energy consumption of idle resources and improving energy utilization efficiency.

[0018] 6. This invention utilizes reinforcement learning agents to make optimization decisions based on real-time status, achieving adaptive resource scheduling and improving the overall performance of the cluster.

[0019] 7. This invention provides detailed billing and auditing information, helping users to clearly understand resource consumption and achieving refined cost management. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating a Kubernetes-based round-robin resource scheduling method according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a Kubernetes-based round-robin resource scheduling system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0022] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0028] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a Kubernetes-based round-robin resource scheduling method according to an embodiment of the present invention is shown below in detail: S101 collects resource usage data of Pods and nodes in the Kubernetes cluster in real time and combines it with time series forecasting algorithms to predict load trends.

[0029] In this embodiment, a dedicated daemon set for data collection is deployed in the Kubernetes cluster. This daemon set runs a data collection container instance on each node in the cluster, ensuring comprehensive coverage of resource usage across all nodes. Simultaneously, a lightweight sidecar container is deployed for each Pod to specifically collect resource usage data for that Pod. During data collection module initialization, connection parameters to the Kubernetes API server need to be configured to ensure the successful acquisition of relevant information about Pods and nodes in the cluster, such as the Pod's name, namespace, and parent node, as well as the node's name and identifier. Furthermore, the data collection frequency needs to be set, for example, collecting data every 5 seconds, to ensure data real-time performance and accuracy.

[0030] After the sidecar container starts, it interacts with the container runtime (such as Docker or containerd) within its Pod to obtain resource usage data for each container in that Pod. Specific resource metrics collected include CPU utilization, memory usage, disk I / O read / write speeds, and network bandwidth usage. After collecting this data, the sidecar container performs preliminary processing and formatting, aggregating the resource usage data of all containers within the same Pod to generate a data packet containing the overall resource usage of that Pod. Then, the sidecar container sends this data packet to the data collection container on its node.

[0031] In addition to receiving Pod resource usage data from sidecar containers, the data acquisition container on each node also interacts directly with the node's operating system to collect node-level resource usage data. This data includes the node's total CPU utilization, total memory usage, remaining disk space, network traffic, etc. The data acquisition container integrates the received Pod resource usage data and the collected node resource usage data, storing them in chronological order to form a time-series dataset containing the resource usage of all Pods and nodes in the cluster. A timestamp is added to each data record during storage for subsequent time-series analysis and prediction.

[0032] As time series datasets continue to grow, preprocessing is necessary to improve the accuracy and efficiency of subsequent prediction algorithms. Preprocessing mainly includes two steps: data cleaning and data normalization. Data cleaning aims to remove outliers and noisy data from the dataset. For example, if CPU utilization suddenly spikes to an unreasonable value (far exceeding the number of physical CPU cores of a node) at a certain time point, this data is considered an outlier and needs to be corrected or deleted. Data normalization unifies resource usage indicators of different dimensions to the same numerical range. For example, CPU utilization and memory usage are normalized to the [0,1] interval. This avoids the adverse effects on prediction results caused by excessive differences in the dimensions of different indicators.

[0033] After data preprocessing, a suitable time series forecasting algorithm is selected to predict load trends. This embodiment uses a machine learning-based time series forecasting model, such as the Long Short-Term Memory (LSTM) model. LSTM models have the advantage of processing long-sequence data, capturing long-term dependencies, and are suitable for predicting resource usage load trends in Kubernetes clusters. When training the LSTM model, the preprocessed time series dataset is divided into training and test sets. The training set is used for model parameter learning and optimization, while the test set is used to evaluate the model's predictive performance. By continuously adjusting the model's hyperparameters, such as the number of hidden layer neurons and the learning rate, the prediction error on the test set is minimized, resulting in a well-trained time series forecasting model with high accuracy.

[0034] Once new resource usage data is collected and preprocessed, it is fed into a pre-trained time series forecasting model. The model then predicts future resource usage load trends based on patterns and regularities in historical data. The predictions include forecasts of key resource metrics such as CPU utilization and memory usage for each Pod and node over a future period (e.g., the next 10 minutes or 30 minutes). These forecasts provide crucial information for subsequent resource scheduling decisions, such as adjusting resource allocation in advance based on predicted load trends to avoid resource shortages or waste.

[0035] The load trend prediction results output by the time series forecasting model are fed back to the Kubernetes cluster's resource scheduler. The resource scheduler can then use these predictions, combined with other resource scheduling strategies (such as migration cost models based on business priorities, electricity price and carbon emission data), to formulate a more reasonable resource scheduling plan. Meanwhile, as time progresses, new resource usage data is constantly generated, requiring regular updates and optimizations to the time series forecasting model. For example, the model can be retrained every certain period (e.g., daily) using the latest collected data to adapt to changes in cluster resource usage patterns and ensure the accuracy and reliability of the prediction results.

[0036] In this embodiment, the function of real-time collection of resource usage data of Pods and nodes in Kubernetes clusters and prediction of load trends by combining time series forecasting algorithm is realized, which provides strong data support and decision basis for Kubernetes-based cyclic resource scheduling method.

[0037] S102, based on resource usage data and load trend prediction results, resources are divided into hot resource pool, cold resource pool and idle resource pool, and a migration cost model is constructed according to business priority. The migration cost model is used to avoid frequent interruptions of high priority tasks.

[0038] In this embodiment, after completing the real-time collection of resource usage data for Pods and nodes in the Kubernetes cluster and the prediction of load trends, these two types of data are first integrated. Resource usage data includes detailed metrics such as CPU utilization, memory usage, disk I / O, and network bandwidth for each Pod and node at different times, while the load trend prediction results provide the expected changes in these resource metrics over a future period. By associating resource usage data at the same point in time with the corresponding load trend prediction values, a comprehensive resource status dataset is formed. This dataset comprehensively reflects the current actual usage of cluster resources and future trends, providing an accurate basis for subsequent resource pool partitioning.

[0039] Based on the integrated and analyzed resource status dataset, the criteria for dividing the hot resource pool are determined. The hot resource pool is primarily used to handle tasks with currently high loads that are expected to remain high or continue to increase in the near future. Specifically, dual thresholds are set for CPU utilization and memory usage. For example, if a Pod's CPU utilization exceeds 80% for multiple consecutive time points, and its memory usage exceeds 70% of its requested resources, and load trend predictions indicate that the Pod's CPU and memory usage are not expected to decrease significantly within the next 10 minutes, then the Pod and its associated node resources are allocated to the hot resource pool. For nodes, if the proportion of Pods in the above-mentioned states on a node exceeds a certain percentage (e.g., 60%), then the entire node is allocated to the hot resource pool. Resources in the hot resource pool must be able to respond to business requests promptly; therefore, sufficient computing and storage resources are prioritized to meet the needs of high-load tasks.

[0040] The cold resource pool is used to store task resources that are currently under low load but are predicted to see increased business requests in the future based on load trends. When creating a cold resource pool, focus on Pods and nodes with low CPU utilization (e.g., below 30% for multiple consecutive time points) and relatively low memory usage (below 40% of their requested resource amount), but whose load trend predictions indicate a significant upward trend in the next 30 minutes. For example, the resource usage of certain scheduled tasks during their idle phase before execution meets the criteria for a cold resource pool. These resources are placed in the cold resource pool and appropriately reserved to ensure a quick recovery to a hot state when business requests arrive, reducing cold start time. Simultaneously, the resources in the cold resource pool are monitored regularly, and the pool's scope is adjusted promptly based on changes in load trends.

[0041] The idle resource pool contains resources that are currently idle and, based on load trends, are predicted to have no significant business requests for an extended period (e.g., more than one hour). Specifically, this is characterized by extremely low CPU and memory usage (close to zero) for Pods, with most resources on the node remaining unused. By analyzing the resource status dataset, Pods and nodes meeting these criteria are assigned to the idle resource pool. Resources in the idle resource pool can be more flexibly scheduled and optimized; for example, they can be used to execute low-priority background tasks, or consolidated and released to improve the overall resource utilization efficiency of the cluster.

[0042] To construct a migration cost model, it is necessary to prioritize and quantify the services within the cluster. Based on the importance of the services and their real-time requirements, services are categorized into different priority levels, such as high, medium, and low priority. High-priority services, such as financial transaction systems and online medical diagnostic systems, have extremely high requirements for continuity and real-time performance; any interruption could lead to severe economic losses or security risks. Medium-priority services, such as internal office systems and general e-commerce websites, have some real-time requirements but can tolerate short delays within a certain timeframe. Low-priority services, such as background tasks like data backup and log analysis, have lower real-time requirements and can be processed when system resources are idle. Each service is assigned a priority value based on its priority level, for example, 3 for high priority, 2 for medium priority, and 1 for low priority, for use in subsequent migration cost calculations.

[0043] When constructing a migration cost model, several factors affecting task migration need to be considered. First is task downtime, i.e., the length of time a task cannot provide normal service during the migration process. For high-priority tasks, excessive downtime can severely impact business operations; therefore, downtime is a crucial factor in migration cost. Second is resource reallocation cost, including the time and computing resources consumed in initializing and configuring resources on the new node, as well as integrating them with the existing system. Different priority tasks have different tolerances for resource reallocation; high-priority tasks require faster and more stable resource reallocation. Furthermore, data migration cost must be considered. If task migration involves the transfer of large amounts of data, such as database migration, the time and security of the data migration will have a significant impact on business operations, especially for high-priority businesses.

[0044] A migration cost model is constructed based on business priorities and defined migration cost factors. The core idea of ​​this model is to calculate a comprehensive migration cost value based on task priorities and various cost factors involved in the migration process. High-priority tasks are given higher weight in the migration cost calculation due to their importance. For example, when calculating the impact of task downtime on migration cost, the increase in migration cost for a high-priority task is greater for every 1 second increase in downtime. Similarly, when considering resource reallocation costs and data migration costs, corresponding weight adjustments are made based on business priorities. This approach ensures that high-priority tasks are not frequently interrupted during resource scheduling and task migration, prioritizing their stable operation.

[0045] In this embodiment, prediction results based on resource usage data and load trends are implemented, resources are divided into hot resource pools, cold resource pools and idle resource pools, and a migration cost model is constructed according to business priorities. This effectively avoids frequent interruptions of high-priority tasks and improves the rationality and stability of Kubernetes cluster resource scheduling.

[0046] S103 dynamically adjusts the task distribution based on electricity price and carbon emission data in each region, prioritizing the scheduling of tasks from the thermal resource pool to regions with a high proportion of renewable energy.

[0047] In this embodiment, dedicated data collection components are deployed in different regions involved in the Kubernetes cluster. These components are responsible for interfacing with local power supply departments, energy monitoring agencies, and relevant environmental data platforms. For electricity price data, real-time electricity price information for each region is obtained at set time intervals (e.g., every 15 minutes) through the interface with the power supply department, including peak and off-peak prices for different time periods. Simultaneously, historical electricity price data over a past period (e.g., one week) is collected to analyze price fluctuation patterns. For carbon emission data, interaction with energy monitoring agencies and environmental data platforms is used to obtain carbon emission intensity data during the power production process in each region, reflecting the carbon emissions generated per unit of electricity. Furthermore, the proportion of renewable energy in each region needs to be collected. This can be obtained through reports published by energy statistics departments or data from relevant energy monitoring platforms to understand the proportion of renewable energy sources such as wind, solar, and hydropower in the local power supply. The collected electricity price data, carbon emission data, and renewable energy proportion data are integrated to form a regional energy dataset containing multi-dimensional information, providing a comprehensive basis for subsequent task scheduling decisions.

[0048] Detailed feature extraction is performed on each task in the hot resource pool. These features include task type (e.g., compute-intensive, data storage-intensive, network communication-intensive), resource requirements (CPU core count, memory size, disk space, etc.), business priority, and historical runtime data, such as peak resource usage and average load at different times. For example, an online video processing task is a compute-intensive task with high CPU and GPU resource requirements. Its business priority is determined based on its importance, and its historical runtime data is analyzed to understand its resource usage patterns at different times of the day. By comprehensively extracting task features, the adaptability and scheduling requirements of tasks to different regional environments can be more accurately assessed.

[0049] To comprehensively consider the impact of factors such as electricity prices, carbon emissions, and the proportion of renewable energy on task scheduling, a regional comprehensive evaluation index is constructed. First, weights are assigned to electricity prices, carbon emissions, and the proportion of renewable energy based on the companies' operational strategies and environmental goals. For example, if a company prioritizes reducing operating costs, the weight of electricity prices can be set higher; if a company emphasizes environmental protection and sustainable development, the weight of carbon emissions can be appropriately increased. Then, the data on electricity prices, carbon emissions, and the proportion of renewable energy in each region are standardized, converting them to a unified dimension. For example, electricity price data is mapped to the 0-1 range according to certain rules, and carbon emission data undergoes a similar standardization transformation. Finally, based on the set weights and the standardized data, the comprehensive evaluation score for each region is calculated. The calculation formula is: Comprehensive Evaluation Score = Electricity Price Weight × Standardized Electricity Price + Carbon Emission Weight × Standardized Carbon Emissions + Renewable Energy Proportion Weight × Standardized Renewable Energy Proportion. This comprehensive evaluation index quantifies the overall performance of each region in terms of cost, environmental protection, and energy sustainability.

[0050] Based on the characteristics of the thermal resource pool task and comprehensive regional evaluation indicators, suitable schedulable regions for task scheduling are selected. For computationally intensive tasks, regions with lower electricity prices and a higher proportion of renewable energy are preferred to reduce computing costs and dependence on traditional energy sources. For example, if a region has low electricity prices, a renewable energy share exceeding 50%, and low carbon emissions, then that region is an ideal schedulable region for computationally intensive tasks. For tasks with high real-time requirements, in addition to considering cost and energy factors, network latency must also be considered. Network latency data between each region and the main access nodes of the task can be obtained through network monitoring tools, using network latency as an additional filtering condition to ensure that the task maintains good performance after scheduling. Considering both task characteristics and multiple factors, 3-5 of the most suitable schedulable regions for task scheduling are selected from all regions.

[0051] Within the selected schedulable regions, they are sorted according to their comprehensive evaluation scores, with higher-scoring regions having higher priority. Tasks from the hot resource pool are prioritized for scheduling to the regions with the highest comprehensive evaluation scores, especially high-priority tasks, which are given priority in being scheduled to the optimal region. During scheduling, task dependencies and resource constraints are considered. For example, if a task depends on the output data of other tasks, it is necessary to ensure that these dependent tasks have been completed or can be completed within a reasonable time, and that the new scheduling region has sufficient resources to meet the task's operational requirements. Using Kubernetes' scheduling interface, tasks are migrated from their current region to the selected target region. During the task migration process, the task status and resource usage are monitored in real time to ensure a smooth migration process and avoid issues such as task interruption or data loss.

[0052] After task scheduling is completed, the scheduling effect is evaluated. Operational data of the task in the new region is collected, including indicators such as resource utilization efficiency, task completion time, and business response latency, and compared with the data before scheduling. Simultaneously, the impact of scheduling on regional electricity costs, carbon emissions, and renewable energy utilization is assessed. For example, the reduction in electricity costs, reduction in carbon emissions, and increase in renewable energy use in the region after task scheduling are calculated. Based on the evaluation results, the weights of the regional comprehensive evaluation indicators are adjusted and optimized. If it is found that the impact of a certain factor on task performance and cost in actual scheduling does not conform to expectations, its weight is adjusted accordingly to improve the accuracy and effectiveness of subsequent scheduling decisions. The evaluation results and adjusted weights are fed back to the data collection and integration stage, forming a closed-loop scheduling optimization system. This continuously improves the task scheduling strategy, achieving the goal of dynamically adjusting task distribution based on regional electricity price and carbon emission data, and prioritizing the scheduling of tasks from the thermal resource pool to regions with a high proportion of renewable energy.

[0053] S104 executes a gradual sleep process by monitoring power consumption changes in real time for cold resource pools and idle resource pools.

[0054] In this embodiment, a dedicated power monitoring component is deployed on each node of the Kubernetes cluster. This component has the ability to interact with the underlying hardware of the node, enabling it to acquire power consumption data from various hardware devices (such as CPU, memory, and disk) on the node in real time. After deployment, the power monitoring component is initialized and configured. The data collection interval is set, for example, collecting power consumption data every 5 seconds, to ensure that subtle changes in power consumption can be captured promptly. Simultaneously, the data storage method is configured to store the collected power consumption data in a distributed storage system within the cluster, such as Ceph or GlusterFS, for subsequent analysis and processing. Furthermore, a security authentication mechanism is set up for the power monitoring component to ensure that only authorized systems and services can access and obtain power consumption data, guaranteeing data security.

[0055] By leveraging Kubernetes' tagging and annotation mechanisms, Pods in the cluster are labeled to explicitly distinguish tasks belonging to the cold resource pool and the idle resource pool. Each task is associated with the power consumption information of its host node. By querying data stored in the power monitoring component, key metrics such as average and peak power consumption of the node where the task is running are obtained. For example, for a data backup task in the idle resource pool, the power consumption changes of its host node over a period of time are recorded to analyze the task's impact on node power consumption. In this way, a correlation is established between tasks in the cold and idle resource pools and node power consumption, providing a basis for subsequent gradual hibernation decisions.

[0056] Power consumption data associated with tasks in the cold and idle resource pools of the distributed storage system is read and analyzed in time series. A sliding window approach is used to divide the power consumption data within a certain time range into multiple windows, such as one-minute windows, to analyze the power consumption trend within each window. Statistical indicators such as the average power consumption and standard deviation within each window are calculated. By comparing the statistical indicators of different windows, the power consumption variation is determined. If the average power consumption within several consecutive windows shows a gradually decreasing trend and the standard deviation is small, it indicates that the task's resource usage is gradually decreasing, and it is likely to enter a hibernation state. Simultaneously, considering the task's business characteristics, such as the task's execution cycle and data processing volume, the power consumption variation is further evaluated to determine if it is consistent with the task's normal business fluctuations. If the power consumption decrease is due to the task completing a phase of work and entering an idle state, rather than an abnormal situation, then the task is determined to be suitable for entering a gradual hibernation process.

[0057] Based on the task type and power consumption changes, a personalized, gradual hibernation strategy should be developed. For computationally intensive tasks, which consume significant CPU resources, the CPU usage frequency needs to be gradually reduced when entering hibernation. For example, initially limit the CPU usage to 50%, run for a period of time (e.g., 30 seconds), and observe the task's running status and power consumption changes. If the task runs normally and power consumption continues to decrease, then limit the CPU usage to 25%, and so on, until the CPU usage is reduced to the minimum level sufficient to maintain the task's basic state. For data storage tasks, focus on disk read / write operations. During hibernation, first stop new data write operations and synchronize data in the cache to the disk to ensure data integrity and consistency. Then, gradually reduce the disk read / write frequency, for example, increasing the disk I / O operation interval from once per second to once every 5 seconds, eventually bringing the disk into a low-power hibernation state. Simultaneously, set a timeout for each hibernation stage. If the task fails to reach the expected hibernation state within the specified time or encounters an abnormal situation, terminate the hibernation process and resume normal task operation.

[0058] After the task completes each stage of the progressive sleep process, the power consumption data of the node is collected again by the power monitoring component to confirm whether the task has entered a stable sleep state. If the node's power consumption drops below the pre-set sleep power consumption threshold and remains below it for a period of time (e.g., 1 minute), the task is considered to have successfully entered a sleep state. The task's sleep state information is recorded in the Kubernetes metadata store, including the sleep start time, sleep stage, and estimated recovery time. Simultaneously, the cluster's resource usage view is updated, marking the resources occupied by the sleeping task as available for release so that other tasks can use these resources.

[0059] Setting wake-up conditions for dormant tasks includes timed wake-up, business request wake-up, and resource demand wake-up. Timed wake-up wakes up dormant tasks at specific times based on the task's business cycle or a preset schedule. For example, a task in an idle resource pool that performs data backups every morning enters a dormant state after completing the backup and automatically wakes up the next morning to continue the backup task. Business request wake-up listens for business request messages related to the task; when a new business request arrives, the dormant task is awakened to handle the request. For example, an online customer service task in a cold resource pool enters a dormant state when idle; when a user initiates an inquiry, the system detects the request message and immediately awakens the task. Resource demand wake-up is based on the overall resource usage of the cluster. When cluster resources are scarce and resources need to be released by the dormant task to meet the runtime needs of other high-priority tasks, the dormant task is awakened and its resource allocation is adjusted. When waking up a task, the resource usage of the task is gradually restored in reverse order of gradual dormancy, ensuring that the task can smoothly return to normal operation and avoiding system performance fluctuations caused by a sudden restoration of a large amount of resources.

[0060] Establish a monitoring mechanism for the entire gradual hibernation process, tracking key indicators such as task hibernation and wake-up states, power consumption changes, and process execution time in real time. A visual monitoring interface allows operations personnel to intuitively understand the process's operation. Regularly evaluate and optimize the gradual hibernation process, analyzing monitoring data to identify problems and bottlenecks. For example, if frequent abnormal interruptions are found during hibernation, analyze the causes and adjust relevant parameters in the hibernation strategy; if the execution time of a certain hibernation phase is too long, optimize the operation process of that phase to improve process efficiency. Through continuous monitoring and optimization, ensure the stable and efficient operation of the gradual hibernation process, improving the resource utilization efficiency of the cold resource pool and idle resource pool.

[0061] S105 takes the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool as inputs, and trains a reinforcement learning scheduling strategy based on the Ray RLlib framework.

[0062] In this embodiment, a dedicated data acquisition component is deployed in the Kubernetes cluster. This component has the ability to interact with various nodes and Pods within the cluster. For hot resource pools, the component interfaces with the task management module in the hot resource pool to obtain the queue length information of each hot resource pool in real time, i.e., the number of tasks currently waiting to be processed. For example, for a hot resource pool processing online transactions, the acquisition component records the number of transaction orders waiting to be processed in the queue every 10 seconds. For cold resource pools, when tasks in the cold resource pool execute a progressive sleep and wake-up process, the time required to wake up each task is recorded as the recovery time data for the cold resource pool. For example, the time taken for a data analysis task in a cold resource pool to wake up from a sleep state and be able to process data normally is recorded once after each wake-up operation. For idle resource pools, the number of times tasks in the idle resource pool are called within a specific time interval is counted by monitoring the task call interface to obtain call frequency data. For example, the number of times a log recording task in an idle resource pool is called per hour is counted.

[0063] A reinforcement learning training environment is constructed based on the Ray RLlib framework. First, the state space of the environment is defined, with the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool as features of the state space. For example, the state can be represented as a three-dimensional vector, where the first dimension is the average queue length of the hot resource pool, the second dimension is the average recovery time of the cold resource pool, and the third dimension is the average call frequency of the idle resource pool. These feature values ​​are normalized and mapped to the [0,1] interval to avoid the impact of excessively large differences in the magnitude of different feature values ​​on the training results.

[0064] Next, define the action space. In a resource scheduling scenario, actions can include migrating a task from a hot resource pool to a cold resource pool, waking up a task from a cold resource pool and assigning it to a hot resource pool, adjusting the resource allocation ratio of tasks in an idle resource pool, etc. For example, an action can be defined as several discrete options, such as 0 indicating no task migration or adjustment, 1 indicating migrating a task from a hot resource pool to a cold resource pool, 2 indicating waking up a task from a cold resource pool and assigning it to a hot resource pool, etc.

[0065] Next, a reward function is defined. The reward function is designed to guide the reinforcement learning model to learn the optimal resource scheduling strategy. The reward value is calculated by comprehensively considering multiple factors, such as resource utilization, task processing efficiency, and energy consumption. For example, a positive reward is given when scheduling actions improve cluster resource utilization; a negative reward is given when task processing time is prolonged due to unreasonable scheduling. Specifically, the reward value can be calculated based on the reduction in the hot resource pool queue length, the optimization of the cold resource pool recovery time, and the rationality of the idle resource pool call frequency. If the hot resource pool queue length is significantly reduced after scheduling, it indicates that scheduling effectively alleviates the pressure on the hot resource pool, and a larger positive reward is given; if the cold resource pool recovery time is too long and affects task processing efficiency, a corresponding negative reward is given.

[0066] Choose a suitable reinforcement learning algorithm model within the Ray RLlib framework, such as the Proximal Policy Optimization (PPO) algorithm. The PPO algorithm has stable training performance and good convergence, making it suitable for handling complex resource scheduling problems. Initialize the model parameters, including the weights and biases of the neural network. For the neural network structure, a multilayer perceptron (MLP) can be used. The number of nodes in the input layer is the same as the feature dimension of the state space, i.e., 3 nodes (corresponding to the hot resource pool queue length, cold resource pool recovery time, and idle resource pool call frequency). The hidden layers can be set to 2-3 layers according to the actual situation, with each layer having 64-128 nodes. The number of nodes in the output layer is the same as the number of options in the action space. Initialize the weights and biases of the neural network with random values ​​to ensure that the model has randomness at the beginning of training, in order to explore different scheduling strategies.

[0067] Preprocessed data is read from a distributed database and divided into training and test sets. The training set is used for updating the model's parameters, while the test set is used to evaluate the model's performance. During training, the state space data is input into the reinforcement learning model, and the model outputs an action based on the current state. This action is applied to a simulated Kubernetes resource scheduling environment to obtain a new state and corresponding reward value. Based on the new state and reward value, the model's parameters are adjusted using the PPO algorithm's update rules to maximize long-term rewards. For example, the PPO algorithm updates the policy parameters by calculating the probability ratio between the current policy and the old policy, combined with the reward value, allowing the model to gradually learn actions that yield higher rewards in different states.

[0068] In each training iteration, a batch of data is used to update the model. The batch size can be adjusted based on the cluster's computing resources and training results, typically set to 32-128 samples. During training, the model's performance is periodically evaluated using a test set. Evaluation metrics include resource utilization improvement rate, average task processing time, and energy consumption reduction rate. If the model's performance does not significantly improve in several consecutive iterations, hyperparameters such as the learning rate can be adjusted, or the amount of training data can be increased, and training can continue until the model reaches a satisfactory performance level.

[0069] Once the reinforcement learning model is trained, it is deployed to the Kubernetes cluster. During actual resource scheduling, real-time data on the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool are collected and fed into the deployed model. The model outputs corresponding actions based on the learned scheduling strategy, and the cluster scheduler executes actual resource scheduling operations, such as task migration and resource allocation adjustments, based on the actions output by the model.

[0070] Simultaneously, a feedback mechanism is established to continuously monitor the actual effectiveness of resource scheduling and feed the data back to the model. For example, after each scheduling, metrics such as cluster resource utilization and task processing time are recorded and compared with expected targets. If there is a significant deviation between the actual results and expectations, the reasons are analyzed, and the model is fine-tuned or retrained to ensure that the model can adapt to constantly changing business needs and cluster environments, achieving continuously optimized resource scheduling results.

[0071] In some embodiments, step S101 above, which involves real-time collection of resource usage data for Pods and nodes in the Kubernetes cluster and combining it with a time series forecasting algorithm to predict load trends, specifically includes: A monitoring agent deployed in a Kubernetes cluster collects resource usage data of Pods and nodes in real time. The resource usage data includes CPU utilization, memory usage, network I / O throughput, and disk I / O operation count. Resource usage data is preprocessed to form a model training dataset. Based on the training dataset, a time series forecasting algorithm is used to train the load forecasting model. The load forecasting model is used to perform rolling forecasts of resource load trends within a specified future time window, and the load forecasting results are output.

[0072] In this embodiment, a customized monitoring agent component is deployed on each node of the Kubernetes cluster. This monitoring agent has the ability to deeply interact with the node's operating system and the Pods running on the node. For CPU utilization collection, the monitoring agent communicates with the node kernel through an interface to obtain the CPU time slice usage of each Pod and the node as a whole, and calculates the real-time CPU utilization. For example, data is collected every 5 seconds, recording the percentage of CPU time used by a Pod or node out of the total available CPU time during that time interval.

[0073] Regarding memory usage collection, the monitoring agent utilizes the operating system's memory management interface to obtain the currently allocated physical memory size of Pods and nodes, as well as the memory size occupied by caches and buffers, and adds them together to obtain the total memory usage. It also records memory usage precisely at 5-second intervals.

[0074] Network I / O throughput is collected by a monitoring agent that listens to the network interface of a node and counts the number of incoming and outgoing data packets and bytes within a specific time interval. For example, the network input and output bytes of all Pods on that node are counted every 5 seconds to measure network I / O throughput.

[0075] Disk I / O operation counts are collected by monitoring the agent's interaction with the node's disk driver, recording the number of disk read and write operations performed by the Pod within the collection interval. For example, the number of disk reads and writes by each Pod is counted every 5 seconds to obtain relevant data on disk I / O operations. This collected resource usage data is stored in real-time in a distributed message queue within the cluster, such as Apache Kafka, to ensure high availability and ordering of the data.

[0076] Resource usage data collected from a distributed message queue is read, cleaned, and feature-engineered to form a dataset suitable for model training. First, data cleaning is performed to check for missing, outlier, and duplicate values. For missing values, if the missing percentage is small (e.g., less than 5%), the average of data from adjacent time points is used to fill in the gaps; if the missing percentage is large, data for that time period is recollected. For outliers, a reasonable threshold range is set for identification. For example, CPU utilization should normally be between 0% and 100%; values ​​exceeding 100% or less than 0% are considered outliers and replaced with normal values ​​from adjacent time points. Duplicate values ​​are removed to ensure data uniqueness.

[0077] Next, feature engineering is performed to smooth the collected time series data to reduce noise interference. A moving average method is used, with an appropriate window size (e.g., window size 3), to calculate the average value of the data within each window. This average value replaces the original data at the center of the window, resulting in the smoothed time series. Simultaneously, to ensure that data with different features have the same scale, features such as CPU utilization, memory usage, network I / O throughput, and disk I / O operations are normalized, mapping the value of each feature to the [0,1] interval. After data cleaning and feature engineering, the data is divided into a training set and a validation set. The training set is used to train the load prediction model, and the validation set is used to evaluate the model's performance.

[0078] Based on the preprocessed training dataset, a suitable time series forecasting algorithm is selected to train the load forecasting model. Here, the Long Short-Term Memory (LSTM) network algorithm is chosen, as it can effectively handle long-term dependencies in time series data. The LSTM model structure includes an input layer, hidden layers, and an output layer. The number of nodes in the input layer is the same as the number of preprocessed features, i.e., 4 nodes (corresponding to CPU utilization, memory usage, network I / O throughput, and disk I / O operations). The hidden layers can be set to 2-3 layers depending on the data complexity and training performance, with each layer containing 64-128 LSTM units. The output layer has 1 node and is used to predict the resource load value within a specified future time window.

[0079] During training, the training dataset is sequentially input into the LSTM model in chronological order. The model calculates predicted values ​​based on the input historical resource usage data through forward propagation, compares these predicted values ​​with the actual resource load values, and calculates a loss function (e.g., mean squared error loss). Then, the backpropagation algorithm is used to update the weights and bias parameters of each layer in the model based on the gradient information of the loss function, in order to minimize the loss function. To improve the training efficiency and stability of the model, batch gradient descent is used for parameter updates, with appropriate batch sizes (e.g., 32 or 64) and learning rates (e.g., 0.001). During training, the model's performance is periodically evaluated using a validation set. Based on the loss function values ​​and accuracy on the validation set, the model's hyperparameters, such as the number of hidden layer nodes and the learning rate, are adjusted until the model's performance on the validation set reaches a satisfactory level, completing the training of the load prediction model.

[0080] The trained load forecasting model is used to perform rolling forecasts of resource load trends within a specified future time window. The size of the forecast time window is set, for example, to forecast resource load trends over the next 30 minutes. The time window is divided into multiple smaller forecast intervals, such as every 5 minutes. First, preprocessed resource usage data from the current moment and a previous period (e.g., the past hour) is input into the load forecasting model. The model then outputs the predicted resource load value for the first future forecast interval (i.e., the next 5 minutes).

[0081] As time progresses to the next moment, the new current moment's resource usage data, along with the resource usage data from the previous period (including newly collected data not used in the previous prediction), is recombined into the input data and fed back into the load prediction model to obtain the resource load prediction value for the next prediction interval (i.e., the next 5-10 minutes). This process continues, continuously using the latest resource usage data as input to achieve continuous prediction of resource load trends over the next 30 minutes. After each prediction is completed, the load prediction results are stored in the cluster's database and simultaneously displayed visually on the cluster management interface, allowing operations personnel to understand resource load changes in real time and providing a basis for subsequent resource scheduling and optimization decisions.

[0082] In some embodiments, step S102 above, which involves constructing a migration cost model based on business priorities, specifically includes: Based on pre-set business priority labels and node status, a migration cost model is constructed to quantify the cost of Pod migration. During the scheduling or rescheduling decision-making process, the business priority of the Pod, the data locality of the data that the Pod depends on, and the network status between nodes are calculated through the migration cost model to score or filter candidate nodes and obtain the scoring results. The node with the lowest migration cost is selected based on the scoring results to avoid frequent interruptions of high-priority tasks.

[0083] In this embodiment, within the Kubernetes cluster management system, business priority tags are pre-assigned to Pods corresponding to each service. These tags can be categorized based on factors such as the criticality of the service, real-time requirements, and the urgency of resource needs. For example, Pods corresponding to services with extremely high requirements for system stability and real-time performance, such as financial transaction processing and real-time monitoring and alarms, are assigned high priority; Pods corresponding to services that can tolerate a certain level of latency, such as routine data analysis and report generation, are assigned medium priority; and Pods corresponding to testing environments and non-critical auxiliary services are assigned low priority. Simultaneously, the status information of each node in the cluster is monitored in real time, including CPU utilization, remaining memory, disk space usage, and network bandwidth utilization, and this node status information is stored in the cluster's distributed storage system for later querying and use. Based on the pre-set business priority tags and node status information, a migration cost model for quantifying Pod migration costs is constructed.

[0084] When constructing a migration cost model, three key elements are identified: the business priority of the Pod, the data locality of the data the Pod depends on, and the network status between nodes. For the business priority of the Pod, it is quantified using pre-defined labels, for example, high priority is assigned a value of 3, medium priority a value of 2, and low priority a value of 1. The data locality of the data the Pod depends on refers to the storage location of the data required for the Pod's operation on the node. If the data the Pod depends on is already stored on the target node, then the data locality is good, and the migration cost is relatively low; if the data needs to be transferred from other nodes, then the data locality is poor, and the migration cost increases. A data distribution mapping table can be maintained in the cluster to record the storage location of the data each Pod depends on on each node, thereby assessing data locality. The network status between nodes includes network latency, bandwidth, etc. Lower network latency and higher bandwidth result in lower communication costs between nodes and better performance after Pod migration. Network performance tests can be performed regularly between cluster nodes, such as using the ping command to test network latency and the iperf tool to test network bandwidth, and the test results can be recorded as a basis for evaluating the network status between nodes.

[0085] Taking into account the three key factors mentioned above, a migration cost model is constructed. For each candidate node, the corresponding cost value is calculated based on the Pod's business priority, data locality, and inter-node network status. For example, for business priority cost, the value assigned to the Pod's business priority label is directly used as this part of the cost value; for data locality cost, if the data is on the target node, the data locality cost is 0; if the data is not on the target node, the time required for data transmission is estimated based on factors such as data transmission volume and network bandwidth, and this is used as the data locality cost; for inter-node network status cost, it is quantified using pre-defined rules based on network latency and bandwidth conditions, such as increasing the cost by 1 for every 10ms increase in network latency and increasing the cost by 1 for every 10Mbps decrease in network bandwidth. The cost values ​​of these three parts are added together to obtain the total Pod migration cost corresponding to the candidate node, thus constructing a complete migration cost model.

[0086] During scheduling or rescheduling decisions in a Kubernetes cluster, when a new node needs to be selected for a Pod, all candidate nodes are first identified. Then, for each candidate node, a pre-built migration cost model is used for calculation. The Pod's business priority information, data locality information obtained by querying the data distribution mapping table, and inter-node network state information obtained by querying network performance test results are substituted into the migration cost model to calculate the migration cost of the Pod to that candidate node, thus obtaining the candidate node's score. The same method is used to calculate the migration cost of a Pod to all candidate nodes, obtaining the scores for all candidate nodes.

[0087] Based on the calculated scores of all candidate nodes, the node with the lowest migration cost is selected as the target node for the Pod's migration. For example, if there are three candidate nodes A, B, and C, and the calculated cost of migrating a Pod to node A is 5, to node B is 3, and to node C is 7, then node B is selected as the target node for the Pod's migration. This approach avoids interruptions to high-priority tasks due to frequent node migrations, as Pods corresponding to high-priority tasks will prioritize migrating to nodes with lower migration costs, reducing potential problems during the migration process and ensuring the stable operation of high-priority tasks. Furthermore, this node selection method based on the migration cost model also considers factors such as data locality and inter-node network conditions, which helps improve the post-migration performance of Pods and the overall resource utilization of the cluster.

[0088] In some embodiments, step S103 above, which involves dynamically adjusting the task distribution based on regional electricity prices and carbon emission data, and prioritizing the scheduling of tasks from the thermal resource pool to regions with a high proportion of renewable energy, specifically includes: By calling an external carbon footprint API, real-time electricity price and carbon emission data for the region where the nodes of the Kubernetes cluster are located can be obtained periodically. Based on real-time electricity price and carbon emission data, calculate green dispatch scores for each region, and map the green dispatch scores to the labels or taints of nodes in the Kubernetes cluster; When a task needs to be scheduled into the hot resource pool, nodes are prioritized based on the green scheduling score, and tasks are scheduled to nodes with higher green scheduling scores first.

[0089] In this embodiment, a module specifically designed for calling external carbon footprint APIs is integrated into the Kubernetes cluster management system. This module automatically initiates requests to reliable external carbon footprint APIs at preset time intervals, such as every 15 minutes. These external APIs originate from authoritative energy data agencies or government departments and can provide accurate and real-time electricity price and carbon emission data. The request must include identification information of the region where the Kubernetes cluster nodes are located, such as region codes or geographic coordinates, so that the API can return accurate data for the corresponding region. The acquired data includes real-time electricity prices, expressed in yuan / kWh, reflecting the current electricity cost in the region; and carbon emission data, typically expressed as carbon dioxide emissions per kilogram of electricity, expressed in kilograms / kWh, reflecting the cleanliness of the electricity supply in the region. The acquired real-time electricity prices and carbon emission data for each region are stored in the cluster's distributed database, such as Cassandra or MongoDB, for subsequent querying and processing. Simultaneously, a data version control mechanism is established in the database to record the time and content of each data acquisition, ensuring data traceability and consistency.

[0090] Develop a scoring calculation module to read real-time electricity price and carbon emission data for each region from a distributed database. The green dispatch score calculation considers both electricity price and carbon emission factors. Weights are set for electricity price and carbon emission, for example, electricity price weight is 0.4 and carbon emission weight is 0.6. These weights can be adjusted according to actual business needs and energy strategies. For the electricity price factor, the lower the price, the higher the score. A linear mapping method is used to map the electricity price range to a score range of 0-40. For example, if the lowest electricity price in a region is 0.3 yuan / kWh and the highest is 1.0 yuan / kWh, the electricity price factor score is 40 points when the price is 0.3 yuan / kWh, and 0 points when the price is 1.0 yuan / kWh. For the carbon emission factor, the lower the carbon emissions, the higher the score. Similarly, a linear mapping method is used to map the carbon emission range to a score range of 0-60. For example, if a region's carbon emissions range from a minimum of 0.2 kg / kWh to a maximum of 0.8 kg / kWh, the carbon emission factor score is 60 points when emissions are 0.2 kg / kWh and 0 points when emissions are 0.8 kg / kWh. The green dispatch score for each region is obtained by adding the electricity price factor score and the carbon emission factor score, with a range of 0-100 points.

[0091] After calculating the green scheduling score for each region, the score is mapped to a label or taint on a Kubernetes cluster node. For label mapping, a label named "green-score" is added to the node, with the label value being the corresponding green scheduling score, such as "green-score=85". For taint mapping, different taints are set according to the score range. For example, when the score is greater than or equal to 80, the taint is set to "green-level=high"; when the score is between 60 and 79, the taint is set to "green-level=medium"; and when the score is less than 60, the taint is set to "green-level=low". Associating the green scheduling score with nodes through labels or taints facilitates subsequent task scheduling decisions.

[0092] In a Kubernetes cluster, when a task in a hot resource pool needs to be scheduled, the scheduler first queries the tags or taints of all available nodes. Based on the node's "green-score" tag or "green-level" taint, it obtains the green scheduling score for each node. Nodes are then prioritized according to their green scheduling scores, from highest to lowest, with higher-scoring nodes having higher scheduling priority. During scheduling, the scheduler prioritizes assigning tasks from the hot resource pool to nodes with higher green scheduling scores. For example, if there are three nodes A, B, and C, and node A has a green scheduling score of 90, node B has a score of 75, and node C has a score of 60, the scheduler will prioritize scheduling the task to node A. If node A's resources are insufficient, then node B and node C will be considered in that order.

[0093] Meanwhile, to ensure smooth task execution, node resource availability must also be considered during scheduling. The scheduler queries node resource usage in real time, such as CPU, memory, and disk utilization, to ensure that the assigned node has sufficient resources to run the task. If a high-scoring node lacks sufficient resources, the scheduler skips that node and selects the next high-scoring node with ample resources for task scheduling. In this way, task distribution is dynamically adjusted based on regional electricity prices and carbon emission data, prioritizing tasks from the hot resource pool to areas with a high proportion of renewable energy. This reduces both the electricity cost of task operation and carbon emissions, aligning with the green and energy-saving development concept.

[0094] In some embodiments, step S104 above, which involves performing a gradual sleep process for the cold resource pool and the idle resource pool by real-time monitoring of power consumption changes, specifically includes: The power consumption data of nodes in the cold resource pool and idle resource pool are collected in real time through power consumption monitoring tools. By comparing power consumption data with a preset idle time threshold, it is determined whether the node meets the conditions for triggering the sleep process. When the conditions are met, a gradual hibernation process is executed. The gradual hibernation process involves evicting non-core workloads from the node, marking the node as unschedulable, and performing operations to reduce the CPU frequency or power down the hardware of peripheral devices.

[0095] In this embodiment, a dedicated power monitoring tool is deployed within the Kubernetes cluster management system. This tool is implemented by combining a hardware-level power monitoring interface with a software-level data acquisition agent. At the hardware level, if the node server supports the Intelligent Platform Management Interface (IPMI), it communicates with the Baseboard Management Controller (BMC) via the IPMI protocol to directly obtain real-time power consumption data from the BMC. This method provides relatively accurate underlying hardware power consumption information. If the node does not support IPMI, an external power monitoring device is connected to the server's power module. This device transmits the collected power consumption data to the monitoring system via a serial port or network interface.

[0096] At the software level, a data acquisition agent is installed on each node in both the cold and idle resource pools. The agent sends data requests to the hardware power consumption monitoring module at preset time intervals, such as every 5 seconds, to obtain the real-time power consumption value of the current node, in watts (W). Simultaneously, the agent performs preliminary processing on the collected power consumption data, such as data verification and outlier filtering, to ensure data accuracy and reliability. The processed power consumption data is then encapsulated into a specific message format and transmitted over the network to the central monitoring server in the cluster. The central monitoring server is responsible for receiving, storing, and managing the power consumption data uploaded by all nodes, using a distributed database (such as HBase) for storage to ensure high availability and scalability.

[0097] On the central monitoring server, an idle time threshold judgment module is set up. This module continuously tracks the power consumption data changes of each node in the cold resource pool and idle resource pool, and combines this data with a preset idle time threshold to determine whether the node meets the conditions for triggering the hibernation process. The specific judgment process is as follows: First, a power consumption history queue is maintained for each node, storing the node's power consumption data over a period of time, such as the power consumption data of the past 30 minutes. The judgment module periodically (e.g., every minute) analyzes the power consumption data in the queue to calculate the node's average power consumption. If the node's average power consumption is consistently lower than a preset low power consumption threshold (e.g., 50W, which can be adjusted according to the node's hardware configuration and actual business conditions), the node is considered to be in an idle state. At the same time, the judgment module records the duration of the node's idle state. When the duration of the node's idle state exceeds the preset idle time threshold (e.g., 30 minutes), the node is determined to meet the conditions for triggering the hibernation process. At this time, the judgment module generates a hibernation trigger signal and sends this signal to the cluster's scheduling management module, notifying it to prepare to execute a gradual hibernation process on the node.

[0098] When the cluster's scheduling and management module receives a hibernation trigger signal, it immediately initiates a gradual hibernation process.

[0099] Specifically, the scheduling management module first queries the workload information running on the target node. By interacting with workload management components in the cluster (such as Kubernetes Deployment and StatefulSet controllers), it identifies non-core workloads. Non-core workloads can be predefined and marked based on factors such as business importance and priority. For example, workloads in test environments and non-critical data backup tasks can be defined as non-core workloads. The scheduling management module sends eviction commands to these non-core workloads. Upon receiving the command, the workload releases resources and stops its processes according to a pre-defined graceful termination policy, ensuring data integrity and consistency. After the workload has completely terminated, the scheduling management module updates the cluster's resource status information, marking these resources as available.

[0100] After evicting non-core workloads, the scheduling management module marks the target node as unschedulable using Kubernetes' node labeling or taint mechanism. For example, adding a label "schedulable=false" or setting a taint "no-schedule" to the node prevents the scheduler from allocating new workloads to that node during subsequent task scheduling, thus avoiding interruptions to the hibernation process caused by new tasks entering the node.

[0101] The scheduling and management module will select to perform either a CPU frequency reduction operation or a power-down operation to shut down the hardware components of peripheral devices, based on the node's hardware configuration and support capabilities. For CPUs supporting Dynamic Frequency Scaling (DVFS) technology, the scheduling and management module will interact with the operating system's power management interface to send instructions to reduce the CPU frequency, adjusting the CPU's operating frequency to a lower level to reduce power consumption. For example, reducing the CPU frequency from 3.0GHz to 1.5GHz.

[0102] If the node supports partial hardware power-down, the scheduling and management module will identify peripheral devices that can be shut down, such as idle hard drives and unused network cards. By communicating with the hardware device's management interface, it sends a command to shut down the device, achieving partial power-down and further reducing the node's power consumption. After executing the hardware-level energy-saving operation, the scheduling and management module continuously monitors the node's power consumption changes to ensure the energy-saving operation achieves the expected results, while also recording the entire hibernation process and its outcome.

[0103] In some embodiments, step S105 above, which involves using the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool as inputs to train a reinforcement learning scheduling policy based on the Ray RLlib framework, specifically includes: The queue length of the hot resource pool, the recovery time of the cold resource pool, and the function call frequency of the idle resource pool are obtained in real time to form a state space; A reward function is constructed based on resource utilization rate, SLA achievement rate, energy efficiency, and task migration cost. Based on the Ray RLlib framework, historical cluster data is used to train reinforcement learning agents; The trained reinforcement learning agent is integrated into the Kubernetes cluster as a scheduling component, and optimization decisions are made by combining the state space and reward function, outputting Pod placement decisions or resource pool management instructions.

[0104] In this embodiment, a data acquisition and monitoring system is deployed in the Kubernetes cluster. This system is responsible for acquiring key indicator data of the hot resource pool, cold resource pool and idle resource pool in real time to form a state space.

[0105] For hot resource pools, the data acquisition module interacts with the Kubernetes API server to periodically (e.g., every 5 seconds) query the length information of each queue in the hot resource pool. These queues store Pods waiting to be scheduled for execution, and the queue length directly reflects the current task backlog in the hot resource pool. The collected queue length data is tagged with a timestamp and the corresponding resource pool identifier, and then stored in a distributed time-series database (such as InfluxDB).

[0106] For cold resource pools, the monitoring system communicates with the cold resource pool management component to obtain the recovery time of resources in each pool. Resources in a cold resource pool may be in a dormant or low-power state; the recovery time refers to the time required to recover from the current state to a state capable of normally supporting task execution. The method for obtaining the recovery time depends on the specific implementation of the cold resource pool. For example, if the cold resource pool is implemented using hardware hibernation technology, the recovery time can be obtained by querying the hardware wake-up time parameter; if it is based on software virtualization, the recovery time can be estimated by simulating the resource startup process. The obtained recovery time data is also recorded in the time-series database and associated with the corresponding cold resource pool.

[0107] For the idle resource pool, the data acquisition module analyzes logs and monitoring metrics of services related to the idle resource pool in the Kubernetes cluster to calculate the function call frequency of the idle resource pool. Function call frequency reflects how frequently the idle resource pool is used by external requests and is an important indicator of its activity. The collected function call frequency data is aggregated according to a certain time granularity (e.g., per minute) and stored in a time-series database, while also being tagged with the identifier of the idle resource pool.

[0108] The state space construction module periodically (e.g., every 10 seconds) reads data from the time-series database, including the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool. It then integrates this data according to a predefined format to form a multi-dimensional state vector, which serves as the input state for the reinforcement learning model.

[0109] Taking into account multiple key factors such as resource utilization, SLA achievement rate, energy efficiency, and task migration cost, a comprehensive reward function is constructed to evaluate the performance of reinforcement learning agents under different scheduling decisions.

[0110] Resource utilization is a crucial metric for measuring the efficiency of cluster resource usage, including CPU utilization and memory utilization. Real-time resource utilization data for each node and resource pool is obtained through Kubernetes monitoring components (such as Prometheus). In the reward function, higher resource utilization is rewarded positively to encourage agents to fully utilize cluster resources; conversely, lower resource utilization is rewarded negatively to prompt agents to optimize scheduling strategies and improve resource utilization efficiency.

[0111] SLA achievement rate reflects the quality of service provided by the cluster to users. Based on a predefined SLA protocol, the requirements for various service metrics are clearly defined, such as task response time and task completion rate. The monitoring system collects task execution data in real time to calculate the actual SLA achievement rate. Positive rewards are given when the agent's scheduling decisions improve the SLA achievement rate; negative rewards are given if the SLA achievement rate decreases, ensuring that the cluster can meet users' service quality requirements.

[0112] Energy efficiency is a crucial indicator considering both cluster operating costs and environmental factors. Combining the energy-saving strategies of the cold and idle resource pools mentioned earlier, real-time power consumption data for each node and resource pool in the cluster is obtained through power monitoring tools to calculate the energy efficiency index. In the reward function, scheduling decisions that improve energy efficiency receive positive rewards, encouraging agents to adopt energy-saving scheduling strategies and reduce cluster energy consumption.

[0113] Task migration cost refers to the overhead incurred in migrating a task from one resource pool to another, including data transfer time and task interruption recovery time. The task migration cost is calculated by analyzing monitoring data during the migration process. In the reward function, scheduling decisions that minimize task migration costs receive positive rewards, avoiding unnecessary task migrations and improving the overall performance of the cluster.

[0114] The reward values ​​of the four factors mentioned above are weighted and summed to obtain a comprehensive reward function value. The weights can be adjusted according to actual business needs and cluster characteristics. For example, if service quality requirements are high, the weight of SLA achievement rate can be appropriately increased; if energy conservation is emphasized, the weight of energy efficiency can be increased.

[0115] A reinforcement learning training environment was built based on the Ray RLlib framework, using historical cluster data to train the reinforcement learning agent. First, the historical cluster data was preprocessed, including data cleaning, feature extraction, and labeling. Data cleaning primarily removes noisy data and outliers to ensure data quality and accuracy. Feature extraction extracts features relevant to scheduling decisions from the raw data, such as task type, resource requirements, and resource pool status. Labeling assigns an optimal scheduling decision label to each data sample based on historical scheduling results and actual performance metrics, serving as the agent's learning target. Within the Ray RLlib framework, a suitable reinforcement learning algorithm (such as the PPO algorithm) was selected, and relevant parameters such as learning rate, discount factor, and number of iterations were configured. The reinforcement learning agent was initialized, and the preprocessed historical data was divided into training and validation sets. During training, the agent generates scheduling decisions based on the current state space input using the reinforcement learning algorithm. The generated scheduling decisions were applied to the historical cluster data simulation environment, and the reward value of each decision was calculated according to the reward function. The agent updates its policy parameters based on the reward value to maximize long-term cumulative rewards. Through continuous iterative training, the agent gradually learns the optimal scheduling strategy under different states. During training, the agent's performance is periodically evaluated using a validation set to monitor convergence and performance improvement trends. If the agent's performance on the validation set stops improving or overfitting occurs, the algorithm parameters are adjusted or training is stopped, and the best-performing agent model is saved.

[0116] The trained reinforcement learning agent is integrated into the Kubernetes cluster as a scheduling component. It combines the real-time acquired state space and the constructed reward function to make optimization decisions and output Pod placement decisions or resource pool management instructions.

[0117] Develop a custom scheduler extension in the Kubernetes cluster, which is responsible for interacting with the reinforcement learning agent. The custom scheduler uses the data acquisition and monitoring system mentioned earlier to obtain the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool in real time, and constructs the current state space vector.

[0118] The state space vector is input into the reinforcement learning agent, which generates a scheduling decision based on the learned scheduling policy. The decision includes Pod placement decision (which node or resource pool to place the Pod) or resource pool management instructions (such as activating resources in the cold resource pool, adjusting the calling policy of the idle resource pool, etc.).

[0119] A custom scheduler applies scheduling decisions generated by the agent to the Kubernetes cluster, interacting with the Kubernetes API server to execute corresponding scheduling operations. For example, for Pod placement decisions, the scheduler binds the Pod to a specified node; for resource pool management commands, the scheduler calls the corresponding resource pool management interface to dynamically adjust the resource pool.

[0120] After a scheduling decision is executed, the monitoring system continuously tracks the task's execution status and cluster performance metrics, calculating the actual reward value for the decision based on the reward function. This actual reward value is then fed back to the reinforcement learning agent to further optimize the agent's scheduling strategy, forming a closed-loop optimization system that continuously improves the scheduling performance and resource utilization efficiency of the Kubernetes cluster.

[0121] In some embodiments, the method further includes the following steps in steps S101-S105: The peak resource usage of the hot resource pool, the storage occupancy time of the cold resource pool, and the number of function calls of the idle resource pool are collected to form core billing dimension data. Based on the pre-set differentiated billing model, the core billing dimension data is processed and calculated to obtain the billing results; By injecting unique tracking identifiers into workloads within a Kubernetes cluster and recording their entire lifecycle events, a resource consumption audit trail is built, which associates all resource consumption events with specific users and projects to obtain audit data. Link billing results and audit data to generate visualized resource billing analysis reports.

[0122] In this embodiment, a data acquisition and monitoring system is deployed in the Kubernetes cluster. This system is responsible for collecting the peak resource usage of the hot resource pool, the storage occupancy time of the cold resource pool, and the number of function calls of the idle resource pool in real time, thereby forming core billing dimension data.

[0123] For hot resource pools, the monitoring system interacts with Kubernetes' metrics interface (such as Metrics Server) to periodically (e.g., every minute) obtain real-time resource usage data for each node, including CPU, memory, and storage. Simultaneously, a sliding window algorithm is used to dynamically analyze resource usage data over a period (e.g., the past 10 minutes) to identify peak usage for each resource dimension. For example, for CPU resources, the CPU utilization is continuously compared at each time point within the sliding window, and the highest value is recorded as the peak CPU usage of the hot resource pool during that time period. The peak usage data for each resource dimension is then associated with corresponding timestamps, hot resource pool identifiers, and other information, and stored in a distributed database (such as Cassandra).

[0124] For cold resource pools, the data acquisition module communicates with the cold resource pool management component to obtain the storage resource occupancy status of each cold resource pool. Resources in the cold resource pool may exist in the form of object storage, block storage, etc. The management component records information such as the creation time, access time, and deletion time of each storage object. By analyzing this time information, the storage occupancy time of each storage object in the cold resource pool is calculated. For the entire cold resource pool, the storage occupancy time of all storage objects is summarized and statistically analyzed to obtain the total storage occupancy time of the cold resource pool, which is then associated with the cold resource pool identifier and the statistical time and stored in the database.

[0125] For the idle resource pool, the monitoring system analyzes the logs and monitoring metrics of related services to count the number of function calls to the idle resource pool. Functions in the idle resource pool may be microservice functions used to handle specific tasks. The service logs record the call request information for each function, including call time and parameters. The data acquisition module periodically (e.g., every 5 minutes) scans and analyzes the service logs, counts the number of calls to each function within a specified time period, and associates the function call count data with information such as the idle resource pool identifier and function name, storing the data in the database.

[0126] Based on a pre-defined differentiated billing model, the collected core billing dimension data is processed and calculated to obtain the billing results. The differentiated billing model is designed based on different resource types, usage scenarios, and user needs, aiming to achieve fair and reasonable resource billing.

[0127] For hot resource pools, the billing model sets different unit prices based on different resource types (such as CPU, memory, and storage). For example, the unit price for CPU resources may be calculated per core per hour, the unit price for memory resources may be calculated per GB per hour, and the unit price for storage resources may be calculated per GB per hour. Based on the peak usage and corresponding unit price of each resource dimension collected in the hot resource pool, the cost for each resource dimension is calculated, and then the costs of each resource dimension are added together to obtain the total cost of the hot resource pool.

[0128] For cold resource pools, the billing model primarily considers storage duration and storage capacity. A base storage price is set, calculated per hour per GB, while different discount strategies are applied based on the duration of storage usage. For example, a discount is offered after storage usage exceeds a certain number of days. The storage cost for the cold resource pool is calculated based on the total storage duration and total storage capacity collected, combined with the base storage price and discount strategies.

[0129] For the idle resource pool, the billing model is based on the number of function calls and the function type. Different types of functions may have different complexities and resource consumption, thus requiring different unit prices. For example, the unit price of a computationally intensive function may be higher than that of a simple data processing function. Based on the collected call counts and corresponding unit prices of each function in the idle resource pool, the cost of each function is calculated, and then the costs of all functions are summed to obtain the total cost of the idle resource pool.

[0130] The costs of the hot resource pool, cold resource pool, and idle resource pool are aggregated to obtain the total resource usage cost of the entire Kubernetes cluster. This cost is then stored in the database as the billing result, along with relevant data such as billing time and user information.

[0131] By injecting unique tracking identifiers into workloads within a Kubernetes cluster and recording their entire lifecycle events, a resource consumption audit trail is built, which associates all resource consumption events with specific users and projects to obtain audit data.

[0132] When a workload is created, the Kubernetes cluster's scheduling system generates a unique trace identifier for each workload (such as a Pod or Deployment). This identifier is generated using a Globally Unique Identifier (UUID) algorithm to ensure its uniqueness throughout the entire cluster. The generated trace identifier is then injected into the workload's metadata as a unique identifier for the workload.

[0133] Throughout the workload's lifecycle, the monitoring system interacts with the Kubernetes API server and kubelets on each node to record various workload events in real time, including creation, scheduling, startup, running, scaling up, scaling down, and stopping. Each event record includes the event type, the time the event occurred, the workload's trace identifier, relevant resource information (such as the nodes used and resource usage), and the user information of the operator.

[0134] Simultaneously, workloads are associated with specific users and projects. When a user creates a workload, they are required to specify the project to which they belong, and this project information is recorded in the workload's metadata. Through integration with the cluster's user authentication and authorization system, the identity information of the operating user is obtained, and this user information is associated with the workload's tracking identifier.

[0135] All recorded resource consumption events are stored in a distributed log system (such as ELKStack) in chronological order to form a complete resource consumption audit trail. By querying and analyzing the audit logs, it is possible to clearly understand the resource usage of each workload at different time periods, as well as the correlation between resource consumption and specific users and projects.

[0136] By linking billing results and audit data, a visualized resource billing analysis report is generated, providing users with intuitive and clear information on resource usage and costs.

[0137] Develop a data analysis and visualization platform that connects to a database storing billing and audit data, periodically (e.g., monthly) retrieving the latest billing and audit data. During the data analysis phase, the platform performs correlation analysis on the billing and audit data. For example, based on workload tracking identifiers and user project information in the audit data, the platform categorizes and statistically analyzes the billing results by user and project, calculating indicators such as the cost percentage and resource usage trends for each user and project across different resource types. It also analyzes peak and off-peak periods of resource usage, providing users with resource optimization suggestions. In the visualization phase, the platform presents the analysis results to users using various formats such as charts and reports. For example, it uses bar charts to compare resource usage costs for different users or projects, line charts to show resource usage trends over time, and pie charts to display the cost percentage for different resource types. Detailed reports are also provided, including resource usage and cost details for each workload, facilitating in-depth analysis and querying by users.

[0138] The generated visual resource billing analysis report is pushed to users via email, web pages, etc., so that users can understand their resource usage and cost information in a timely manner, providing strong support for resource management and cost control.

[0139] Reference Figure 2 An embodiment of the present invention provides a Kubernetes-based circular resource scheduling system 2, wherein system 2 specifically includes: The first scheduling module 201 is used to collect resource usage data of Pods and nodes in the Kubernetes cluster in real time, and combine it with time series prediction algorithms to predict load trends. The second scheduling module 202 is used to divide resources into hot resource pools, cold resource pools and idle resource pools based on resource usage data and load trend prediction results, and to construct a migration cost model according to business priority. The migration cost model is used to avoid frequent interruptions of high-priority tasks. The third scheduling module 203 is used to dynamically adjust the task distribution based on the electricity price and carbon emission data of each region, and prioritize the scheduling of tasks from the thermal resource pool to regions with a high proportion of renewable energy. The fourth scheduling module 204 is used to execute a gradual sleep process for the cold resource pool and the idle resource pool by monitoring power consumption changes in real time. The fifth scheduling module 205 is used to train a reinforcement learning scheduling strategy based on the Ray RLlib framework, taking the queue length of the hot resource pool, the recovery time of the cold resource pool, and the calling frequency of the idle resource pool as input.

[0140] It is understandable that, such as Figure 1 The content of the Kubernetes-based round-robin resource scheduling method embodiments shown herein is applicable to this Kubernetes-based round-robin resource scheduling system embodiment. The specific functions implemented in this Kubernetes-based round-robin resource scheduling system embodiment are the same as those shown below. Figure 1 The illustrated Kubernetes-based round-robin resource scheduling method is the same as the one described above, and achieves the same beneficial effects. Figure 1 The beneficial effects achieved by the Kubernetes-based round-robin resource scheduling method embodiment shown are also the same.

[0141] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0142] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0143] Reference Figure 3 The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the Kubernetes-based round-robin resource scheduling method as described in any of the above methods.

[0144] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0145] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0146] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0147] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the Kubernetes-based round-robin resource scheduling method as described in any of the above methods.

[0148] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0149] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0151] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0152] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A Kubernetes-based round-robin resource scheduling method, characterized in that, The method specifically includes: Real-time collection of resource usage data for Pods and nodes in a Kubernetes cluster, combined with time series forecasting algorithms to predict load trends; Based on resource usage data and load trend prediction results, resources are divided into hot resource pools, cold resource pools and idle resource pools, and a migration cost model is constructed according to business priority. The migration cost model is used to avoid frequent interruptions of high-priority tasks. Based on electricity price and carbon emission data in each region, the task distribution will be dynamically adjusted, and priority will be given to scheduling tasks for the thermal resource pool to regions with a high proportion of renewable energy. For cold resource pools and idle resource pools, a gradual sleep process is executed by monitoring power consumption changes in real time. The queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool are used as inputs to train a reinforcement learning scheduling strategy based on the Ray RLlib framework.

2. The method according to claim 1, characterized in that, The real-time collection of resource usage data for Pods and nodes in the Kubernetes cluster, combined with time-series forecasting algorithms to predict load trends, specifically includes: A monitoring agent deployed in a Kubernetes cluster collects resource usage data of Pods and nodes in real time. The resource usage data includes CPU utilization, memory usage, network I / O throughput, and disk I / O operation count. Resource usage data is preprocessed to form a model training dataset. Based on the training dataset, a time series forecasting algorithm is used to train the load forecasting model. The load forecasting model is used to perform rolling forecasts of resource load trends within a specified future time window, and the load forecasting results are output.

3. The method according to claim 1, characterized in that, The construction of the migration cost model based on business priorities specifically includes: Based on pre-set business priority labels and node status, a migration cost model is constructed to quantify the cost of Pod migration. During the scheduling or rescheduling decision-making process, the business priority of the Pod, the data locality of the data that the Pod depends on, and the network status between nodes are calculated through the migration cost model to score or filter candidate nodes and obtain the scoring results. The node with the lowest migration cost is selected based on the scoring results to avoid frequent interruptions of high-priority tasks.

4. The method according to claim 1, characterized in that, The method of dynamically adjusting task distribution based on regional electricity price and carbon emission data, prioritizing the allocation of tasks from the thermal resource pool to regions with a high proportion of renewable energy, specifically includes: By calling an external carbon footprint API, real-time electricity price and carbon emission data for the region where the nodes of the Kubernetes cluster are located can be obtained periodically. Based on real-time electricity price and carbon emission data, calculate green dispatch scores for each region, and map the green dispatch scores to the labels or taints of nodes in the Kubernetes cluster; When a task needs to be scheduled into the hot resource pool, nodes are prioritized based on the green scheduling score, and tasks are scheduled to nodes with higher green scheduling scores first.

5. The method according to claim 1, characterized in that, The aforementioned gradual sleep process for the cold resource pool and idle resource pool involves real-time monitoring of power consumption changes and execution of the following specific steps: The power consumption data of nodes in the cold resource pool and idle resource pool are collected in real time through power consumption monitoring tools. By comparing power consumption data with a preset idle time threshold, it is determined whether the node meets the conditions for triggering the sleep process. When the conditions are met, a gradual hibernation process is executed. The gradual hibernation process involves evicting non-core workloads from the node, marking the node as unschedulable, and performing operations to reduce the CPU frequency or power down the hardware of peripheral devices.

6. The method according to claim 1, characterized in that, The process of training a reinforcement learning scheduling strategy based on the Ray RLlib framework, using the queue length of the hot resource pool, the recovery time of the cold resource pool, and the call frequency of the idle resource pool as inputs, specifically includes: The queue length of the hot resource pool, the recovery time of the cold resource pool, and the function call frequency of the idle resource pool are obtained in real time to form a state space; A reward function is constructed based on resource utilization, SLA achievement rate, energy efficiency, and task migration cost. Based on the Ray RLlib framework, historical cluster data is used to train reinforcement learning agents; The trained reinforcement learning agent is integrated into the Kubernetes cluster as a scheduling component, and optimization decisions are made by combining the state space and reward function, outputting Pod placement decisions or resource pool management instructions.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The peak resource usage of the hot resource pool, the storage occupancy time of the cold resource pool, and the number of function calls of the idle resource pool are collected to form core billing dimension data. Based on the pre-set differentiated billing model, the core billing dimension data is processed and calculated to obtain the billing results; By injecting unique tracking identifiers into workloads within a Kubernetes cluster and recording their entire lifecycle events, a resource consumption audit trail is built, which associates all resource consumption events with specific users and projects to obtain audit data. Link billing results and audit data to generate visualized resource billing analysis reports.

8. A Kubernetes-based round-robin resource scheduling system, characterized in that, The system specifically includes: The first scheduling module is used to collect resource usage data of Pods and nodes in the Kubernetes cluster in real time, and combine it with time series prediction algorithms to predict load trends. The second scheduling module is used to divide resources into hot resource pools, cold resource pools and idle resource pools based on resource usage data and load trend prediction results, and to construct a migration cost model according to business priority. The migration cost model is used to avoid frequent interruptions of high-priority tasks. The third scheduling module is used to dynamically adjust the task distribution based on electricity price and carbon emission data in each region, and prioritize scheduling tasks from the thermal resource pool to regions with a high proportion of renewable energy. The fourth scheduling module is used to execute a gradual sleep process for the cold resource pool and the idle resource pool by monitoring power consumption changes in real time. The fifth scheduling module is used to train a reinforcement learning scheduling strategy based on the Ray RLlib framework, taking the queue length of the hot resource pool, the recovery time of the cold resource pool, and the calling frequency of the idle resource pool as input.

9. A computer device, characterized in that, include: A memory and a processor, and a computer program stored in the memory, which, when executed on the processor, implements the Kubernetes-based round-robin resource scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the Kubernetes-based round-robin resource scheduling method as described in any one of claims 1 to 7.

Images