Off-line and on-line mixed task self-adaptive scheduling method and device

Abstract

The invention provides an off-line and on-line mixed task adaptive scheduling method and device, and the method comprises the steps: determining a predicted resource demand based on the monitoring data of each calculation node in a container cluster in a historical time period; determining a current scheduling strategy mode according to the real-time service load index, the overall utilization level of cluster resources and a preset strategy factor index; determining an online task resource quota and an offline task resource quota of each computing node according to the predicted resource demand quantity, the resource residual quantity and the scheduling strategy mode; calculating a scheduling priority score of each to-be-scheduled task; and generating a resource scheduling decision based on the online task resource quota and the offline task resource quota of each computing node and the scheduling priority score of each to-be-scheduled task, and according to the scheme, the overall resource utilization rate and the scheduling intelligence level of the hybrid deployment container cluster are improved while the online business service quality is guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an adaptive scheduling method and apparatus for hybrid online and offline tasks. Background Technology

[0002] With the widespread adoption of cloud computing and containerization technologies, enterprises commonly use container orchestration platforms such as Kubernetes to manage their applications. To improve data center resource utilization and reduce operating costs, deploying latency-sensitive online services and computationally intensive but time-sensitive offline tasks in the same container cluster has become a significant technological trend. However, online services and offline tasks differ fundamentally in their resource requirements, service quality requirements, and scheduling objectives, posing a significant challenge to achieving efficient resource scheduling and isolation in hybrid deployment environments.

[0003] Currently, mixed deployment is mainly achieved through extended schedulers on container orchestration platforms. A typical approach is to set high priority and fixed resource guarantees for online tasks, and low priority and elastic resource limits for offline tasks. When resources are scarce, offline tasks are suppressed or evicted to ensure the performance of online services. Some solutions also use resource overselling strategies to improve utilization.

[0004] However, the above solutions have the following drawbacks: First, the scheduling lacks foresight, relying solely on current resource snapshots for decisions, making it impossible to predict future demand and proactively address load peaks, which can easily lead to sudden performance drops. Second, the strategy patterns are rigid, relying on static configurations and unable to dynamically switch between online priority, balanced, or energy-saving scheduling modes based on real-time load, cluster utilization, and external policy factors. Third, resource allocation and task scheduling are disconnected; the fine-grained resource quotas calculated based on predictions and policies are not coordinated with task priorities that comprehensively consider service quality, weight, and waiting time, making it difficult to achieve efficient and accurate matching of resources and tasks. Summary of the Invention

[0005] This application provides an adaptive scheduling method and apparatus for hybrid online and offline tasks, which improves the overall resource utilization and scheduling intelligence level of hybrid deployment container clusters while ensuring the quality of online business services through predictive resource planning, dynamic multi-mode strategy scheduling and intelligent collaborative matching of tasks and resources.

[0006] In a first aspect, embodiments of this application provide an adaptive scheduling method for hybrid online and offline tasks, applied to a container cluster where online services and offline tasks are deployed in a hybrid manner. The method includes:

[0007] For each compute node in the container cluster, based on the monitoring data of the compute node in the historical time period, the predicted resource demand of the compute node in the future preset scheduling period is determined; wherein, the monitoring data includes CPU utilization, memory usage, and input / output throughput.

[0008] Based on real-time business load indicators, overall cluster resource utilization levels, and preset strategic factor indicators, the current scheduling strategy mode is determined; wherein, the scheduling strategy mode includes online priority mode, balanced mode, and energy-saving mode.

[0009] Based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode, calculate the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node.

[0010] Based on the service quality level, task weight, and task waiting time of each task to be scheduled, calculate the scheduling priority score for each task to be scheduled.

[0011] Based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, resource allocation is performed for the task to be scheduled, and a resource scheduling decision is generated.

[0012] Secondly, embodiments of this application also provide an adaptive scheduling device for hybrid online and offline tasks, applied in a container cluster where online services and offline tasks are deployed in a hybrid manner. The device includes:

[0013] The resource demand prediction module is used to determine the predicted resource demand of each computing node in the container cluster within a future preset scheduling period based on the monitoring data of the computing nodes in the historical time period; wherein, the monitoring data includes CPU utilization, memory usage, and input / output throughput.

[0014] The strategy mode determination module is used to determine the current scheduling strategy mode based on real-time business load indicators, overall cluster resource utilization level, and preset strategic factor indicators; wherein, the scheduling strategy mode includes online priority mode, balanced mode, and energy-saving mode.

[0015] The resource quota determination unit is used to calculate, based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode, the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node.

[0016] The task priority determination module is used to calculate the scheduling priority score of each task to be scheduled based on the service quality level, task weight and task waiting time of each task to be scheduled.

[0017] The scheduling decision determination module is used to allocate resources to the task to be scheduled based on the first resource quota, the second resource quota of each computing node and the scheduling priority score of each task to be scheduled, and generate a resource scheduling decision.

[0018] Thirdly, embodiments of this application also provide an electronic device, which includes:

[0019] One or more processors;

[0020] Storage device for storing one or more programs.

[0021] When one or more programs are executed by one or more processors, the one or more processors implement an adaptive scheduling method for hybrid online and offline tasks as described in any of the embodiments of this application.

[0022] Fourthly, embodiments of this application also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the online / offline hybrid task adaptive scheduling methods described in any of the embodiments of this application.

[0023] This application provides an adaptive scheduling method for hybrid online and offline tasks, applied to a container cluster where online services and offline tasks are deployed in a hybrid manner. The method includes: for each computing node in the container cluster, determining the predicted resource demand of the computing node within a future preset scheduling period based on monitoring data of the computing node over a historical time period, wherein the monitoring data includes CPU utilization, memory usage, and input / output throughput; determining the current scheduling strategy mode based on real-time service load indicators, the overall utilization level of cluster resources, and preset strategic factor indicators, wherein the scheduling strategy mode includes an online priority mode, a balanced mode, and an energy-saving mode; further, calculating a first resource quota that can be allocated to online tasks and a second resource quota that can be allocated to offline tasks for each computing node based on the predicted resource demand, remaining resources, and scheduling strategy mode; calculating a scheduling priority score for each task to be scheduled based on the service quality level, task weight, and task waiting time; and thus, allocating resources for the tasks to be scheduled based on the first resource quota, the second resource quota, and the scheduling priority score of each task, generating a resource scheduling decision. The technical solution of this application predicts future resource demand based on historical data, enabling forward-looking resource planning and allowing idle resources to be planned and utilized in advance, thus reducing resource idleness. Secondly, by comprehensively considering real-time load, cluster utilization, and policy factors, it dynamically switches between online priority, balanced, and energy-saving scheduling modes to ensure that resources can be allocated efficiently on demand in different scenarios. Finally, it coordinates and matches node-level fine-grained resource quotas generated based on prediction and policies with task priorities based on comprehensive service quality, weight, and waiting time, achieving precise matching between resource supply and task demand, avoiding resource fragmentation and mismatch, thereby maximizing the resource fill rate of offline tasks and the overall cluster utilization rate while ensuring the performance of online services. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the exemplary embodiments of this application, the accompanying drawings used in describing the embodiments are briefly introduced below. Obviously, the accompanying drawings described are only a portion of the embodiments to be described in this application, and not all of them. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0025] Figure 1 A flowchart illustrating an adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment;

[0026] Figure 2 A flowchart illustrating another adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment;

[0027] Figure 3A flowchart illustrating another adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment;

[0028] Figure 4 This is a schematic diagram of an adaptive scheduling device for hybrid online and offline tasks provided in an embodiment of this application. Detailed Implementation

[0029] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present application, not the entire structure.

[0030] Before introducing the technical solutions provided in the embodiments of this application, the application scenarios of the solutions can be described first. This embodiment is applicable to various scenarios in container clusters where online services and offline tasks are deployed in a mixed manner, requiring adaptive and intelligent task scheduling. Currently, although extended schedulers based on container orchestration platforms are widely used in mixed task scheduling, traditional methods have obvious limitations. In practical applications, due to the latency sensitivity of online services, the computational intensity of offline tasks, and the dynamic changes in cluster load and intense resource competition, traditional scheduling methods rely on static priorities and real-time resource snapshots, making it difficult to achieve forward-looking planning and dynamic strategy adjustment, which easily leads to problems such as low resource utilization, fluctuating service performance, and delayed scheduling response. Therefore, there is an urgent need for a method that can coordinate real-time load, predict future needs, and adaptively select scheduling strategies by integrating multiple factors to improve the overall optimization effect and resource utilization efficiency of mixed task scheduling. This embodiment is based on predicted resource demand. Under the collaborative mechanism of dynamically determining the scheduling strategy mode, finely dividing the node resource quota, and calculating the scheduling priority based on the task service quality and waiting time, a global resource scheduling decision is generated. This ensures that the scheduling scheme is comprehensively optimized in terms of adaptability, foresight, and fairness, and effectively improves the resource utilization and task execution performance of the container cluster.

[0031] Example 1

[0032] Figure 1 This is a flowchart illustrating an adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment. This embodiment is applicable to container clusters where online services and offline tasks are deployed in a hybrid manner, requiring adaptive and intelligent task scheduling. This method can be executed by an adaptive scheduling device for hybrid online and offline tasks. This device can be implemented in the form of software and / or hardware. The hardware can be a controller, such as a mobile terminal, a PC, or a server.

[0033] The adaptive scheduling method for hybrid online and offline tasks provided in this embodiment is applied to a container cluster where online services and offline tasks are deployed in a hybrid manner. This can be understood as running in a cluster environment that simultaneously supports real-time online services and deferred offline computations, with all workloads deployed in containerized form on a unified resource pool. When making decisions, this method must simultaneously perceive and handle the demand for immediate resource guarantees from online services and the elastic demand for resource consumption from offline tasks. By dynamically distinguishing the task attributes carried by the containers, it coordinates the coexistence and contention of two very different types of loads on the same set of physical nodes, enabling the cluster to maximize offline task availability while ensuring the quality of online service delivery, thereby improving overall resource utilization.

[0034] like Figure 1 As shown, the adaptive scheduling method for hybrid online and offline tasks provided in this embodiment of the invention includes the following steps:

[0035] S110. For each compute node in the container cluster, based on the monitoring data of the compute node in the historical time period, determine the predicted resource demand of the compute node in the future preset scheduling period.

[0036] In this context, a compute node refers to a physical or virtual server unit that constitutes the container cluster and can independently provide computing power. It is the basic hardware resource entity that carries and runs containerized online services and offline tasks, and is the direct object and target of monitoring data collection, resource prediction, quota allocation, and task scheduling.

[0037] Monitoring data refers to a set of quantitative indicators that are periodically collected and uploaded from each compute node in the container cluster according to a preset fixed monitoring period, reflecting its runtime resource consumption and status. Specifically, monitoring data may include CPU utilization, memory usage, and I / O throughput. CPU utilization refers to the percentage of time during which the CPU resources on a compute node are effectively utilized, reflecting its computational workload. Memory usage refers to the ratio of the amount of memory allocated to running tasks on a compute node to its total physical memory capacity, reflecting the level of memory resource consumption. I / O throughput refers to the total amount of data read and written by a compute node through its storage devices (such as disks) per unit time, reflecting the data transfer capacity of the storage subsystem.

[0038] The future preset scheduling period refers to a future time interval pre-set by the system after the current decision-making time. This period is the target output period of the load forecasting model, and its duration is a pre-configured fixed value. The predicted resource demand refers to the estimated quantity or proportion of various computing resources (such as CPUs, memory, etc.) that a certain computing node may need within the future preset scheduling period to maintain business operations or cope with expected load growth.

[0039] Specifically, each compute node in the container cluster can be used as an independent analysis unit. By acquiring and analyzing the monitoring data sequence recorded by each node in a continuous historical period, and using specific load prediction methods, the specific quantity or proportion of various resources that the node may need to meet its expected business load in the future scheduling period preset by the system can be estimated.

[0040] For example, in a container cluster consisting of multiple servers, the scheduling system retrieves monitoring data for a specific compute node (such as a server named Node-A), including CPU utilization, memory usage, and disk I / O throughput, recorded every 5 seconds (a fixed monitoring period) over the past hour (historical time period). The system then inputs this time-sorted data into a pre-trained predictive model. By analyzing the patterns in these historical data, the model predicts the approximate number of CPU cores, memory capacity, and disk bandwidth that Node-A might need in the next ten minutes (a future preset scheduling period). This predicted value is the node's predicted resource requirements.

[0041] In this embodiment, optionally, the specific steps for determining the predicted resource requirements of computing nodes within a future preset scheduling period may include:

[0042] S1. Each computing node collects corresponding real-time monitoring data based on a fixed monitoring cycle.

[0043] Among them, the fixed monitoring cycle refers to the data collection time interval that is set in advance and kept constant.

[0044] In practical applications, each compute node in a container cluster is configured to automatically collect real-time resource usage information generated during its operation at pre-set, equal-length, and continuously cyclical time intervals. This information includes CPU utilization, memory usage, and input / output throughput. The collection action is periodically triggered in the background by the node's local or associated monitoring agent, ensuring that the data acquired each time corresponds synchronously with the actual consumption status of the current physical or virtual resources. This provides continuous, equidistant, node-level raw real-time input for the subsequent formation of historical monitoring data sequences, extraction of time-series sample data, and input into load prediction models.

[0045] S2. At each prediction trigger time, obtain the historical monitoring data sequence formed by each computing node in the most recent continuous monitoring period from the collected real-time monitoring data.

[0046] The predicted trigger time refers to the point in time automatically determined based on preset rules or specific events to initiate a new round of resource demand prediction. The historical monitoring data sequence refers to a set of monitoring data continuously collected from a specific computing node according to a fixed monitoring cycle and arranged in chronological order. This sequence records the continuous observations of the node's core resource indicators (such as CPU utilization, memory usage, and I / O throughput) over a past period.

[0047] In this embodiment, when the prediction trigger time driven by the system clock or event arrives, the system can extract all continuous data points from the real-time monitoring data pool that has been continuously written to each computing node according to a fixed monitoring cycle. This data can be traced back at least one complete monitoring cycle from the current moment to each node. These data points are then arranged in chronological order to form a complete historical monitoring data sequence. This sequence covers the changes in CPU utilization, memory usage, and input / output throughput with the monitoring cycle, providing a structured, continuous, and node-specific historical input source for subsequent sliding time window extraction of time-series sample data and input into the load prediction model.

[0048] S3. Based on a preset sliding time window, extract time-series sample data within the corresponding time window from the historical monitoring data sequence.

[0049] Time-series sample data refers to a continuous monitoring data segment with a chronological order extracted from the historical monitoring data sequence of computing nodes according to a preset sliding time window. This data segment contains the change trajectory of indicators such as CPU utilization, memory usage, and input / output throughput within a specific time interval, and is organized into a standardized input format that can be directly processed by the load prediction model.

[0050] In this embodiment, a subset of data containing CPU utilization, memory usage, and input / output throughput, arranged in the order of the monitoring cycle, can be extracted within the range of a pre-configured continuous time length boundary that can slide back and forth on the historical monitoring data sequence. This subset forms time-series sample data. The sliding action moves backward synchronously as the prediction trigger time advances, ensuring that each extracted sample data always reflects a historical time series that is closest to the present and of a fixed length. This provides standardized, traceable, and real-time updated input for the load prediction model.

[0051] S4. Input the time series sample data into the pre-trained load prediction model and output the predicted resource demand of each computing node in the future preset scheduling period.

[0052] Specifically, time-series sample data, consisting of CPU utilization, memory usage, and input / output throughput extracted by a sliding time window and arranged in chronological order, can be used as input to a load prediction model that has been trained offline. Based on the learned historical resource change patterns, the model performs inference operations internally and directly provides the predicted resource demand that the corresponding computing node will reach in the next preset scheduling cycle. This output value is used for subsequent quota allocation and scheduling decisions.

[0053] S120. Determine the current scheduling strategy mode based on real-time business load indicators, overall cluster resource utilization level, and preset strategic factor indicators.

[0054] Real-time service load metrics refer to a series of dynamic quantitative data that directly reflect the operational pressure and performance of online services in the container cluster; for example, these include CPU utilization, service request latency, system throughput, and application load pressure trends. Overall cluster resource utilization level refers to the comprehensive quantitative representation of the current resource usage of the entire container cluster from a macro-level perspective, as assessed by the scheduling system. It reflects the overall situation, such as the average resource load of all computing nodes within the cluster, the evenness of resource distribution, and the proportion of idle computing nodes. Strategic factor metrics refer to a series of non-real-time, non-resource-related external constraints or guiding parameters used to influence scheduling decisions; for example, these include preset scheduling time windows, established operation and maintenance management strategies, and event instructions from upper-layer business systems.

[0055] The scheduling strategy mode refers to a resource allocation guideline that the scheduling system dynamically selects and applies based on real-time business load indicators, overall cluster resource utilization levels, and strategic factors. Scheduling strategy modes include online priority mode, balanced mode, and energy-saving mode. Online priority mode prioritizes the performance and stability of online tasks during resource allocation, allocating most idle resources to online tasks. Balanced mode allocates resources in a relatively balanced manner between online and offline tasks according to a preset fixed ratio, taking into account the needs of both types of tasks. Energy-saving mode aims to reduce overall energy consumption by consolidating the load onto a few nodes and shutting down idle nodes.

[0056] In this embodiment, at the moment of the current decision, real-time business load indicators reflecting the instantaneous pressure of online business and the backlog of offline tasks are read synchronously, and the overall utilization level of cluster resources is obtained by summarizing the resource consumption ratios of CPU memory input and output of each computing node. Then, combined with the preset strategic factor indicators injected by the administrator or upper-level policies, the three scheduling strategy modes of online priority mode, balanced mode and energy-saving mode are dynamically compared and selected. Once the comprehensive evaluation result meets the triggering conditions of a certain mode, the mode is established as the current scheduling strategy mode followed by subsequent resource quota allocation and task sorting, and is re-evaluated in the next decision cycle to achieve adaptive switching to meet multiple objectives of business needs, resource efficiency and operating costs.

[0057] S130. Based on the predicted resource demand, remaining resources, and scheduling strategy, calculate the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node.

[0058] The remaining resource amount refers to the difference between the total physical resource capacity of a specific computing node in a container cluster and the amount of resources actually occupied by all running tasks (including online and offline tasks).

[0059] The first resource quota and the second resource quota are the resource allocation amounts specifically allocated to two different types of tasks, calculated for each compute node in the container cluster based on predicted resource demand, remaining resources, and the current scheduling strategy. The first resource quota specifically refers to the amount of resources reserved or allocated on that node for online tasks, and the second resource quota specifically refers to the amount of resources reserved or allocated on that node for offline tasks.

[0060] Specifically, on each computing node, the predicted resource demand is first used as the upper limit benchmark, and then the currently used portion is deducted to obtain the remaining resource amount. Subsequently, based on the differentiated allocation tendency defined by the online priority mode, the balanced mode, or the energy-saving mode, the remaining resource amount is divided into online and offline tasks. The online priority mode allocates more available resources to online tasks, the energy-saving mode prioritizes compressing the available resources for offline tasks, and the balanced mode compromises according to a predetermined ratio. Finally, each node is given a first resource quota for running online tasks and a second resource quota for running offline tasks, which are used for subsequent task selection and binding.

[0061] S140. Calculate the scheduling priority score for each task to be scheduled based on its service quality level, task weight, and task waiting time.

[0062] Here, "tasks awaiting scheduling" refers to containerized work units that have been submitted to the scheduling system but have not yet been allocated resources and are waiting in the queue for execution. Service Quality Level (SQL) is a priority classification pre-defined for each task based on business importance, used to differentiate their service assurance levels. Task Weight is a quantitative coefficient defined based on business policies, used to further differentiate the relative importance of tasks within the same SQL. Task Waiting Time refers to the length of time a task has been waiting for scheduling from the time it enters the scheduling queue until the current moment. The scheduling priority score is a comprehensive value calculated by the system based on the aforementioned SQL, task weight, and task waiting time (which may include penalty factors). This score determines the order in which tasks awaiting scheduling are selected in the queue and allocated resources.

[0063] Specifically, for each submitted task that has not yet received resources, the guarantee requirements corresponding to its service quality level, the relative importance reflected by the task weight, and the queuing time accumulated by the task waiting time are comprehensively calculated according to a preset weighting rule. Tasks with higher service quality levels, greater task weights, and longer waiting times will receive higher scheduling priority scores. These scores are used to rank all tasks to be scheduled within the same resource pool, ensuring that critical and scarce tasks are given priority in subsequent resource allocation.

[0064] S150: Based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, allocate resources for the tasks to be scheduled and generate resource scheduling decisions.

[0065] Resource scheduling decision refers to the complete and executable instruction plan that the scheduling system ultimately forms after completing a series of calculations and judgments, including resource prediction for computing nodes, strategy mode selection, task priority ranking, and specific resource quota matching. This decision specifies in detail which scheduled task (container) should be assigned to which specific computing node, and the specific amount of resources it is granted on that node, either the first resource quota (for online tasks) or the second resource quota (for offline tasks). It is the core solution that is ultimately output by the entire scheduling process and guides the container orchestration system in its actual deployment.

[0066] Specifically, the hard upper limit can be set based on the first resource quota available for online tasks and the second resource quota available for offline tasks allocated to each computing node. Then, the tasks to be scheduled are sorted from high to low according to their scheduling priority scores. The task attributes are checked in turn to see if they match the remaining quota. Online tasks can only consume the first resource quota, and offline tasks can only consume the second resource quota. If the remaining quota of a node is insufficient to meet the task requirements, the task will be postponed to the next node until all the tasks that can be met find a suitable place. Finally, a resource scheduling decision is formed that includes the correspondence between tasks and nodes, the specific resource usage, and the execution order. This decision is used to guide the container orchestration interface to complete the actual binding and startup.

[0067] This application provides an adaptive scheduling method for hybrid online and offline tasks, applied to a container cluster where online services and offline tasks are deployed in a hybrid manner. The method includes: for each computing node in the container cluster, determining the predicted resource demand of the computing node within a future preset scheduling period based on monitoring data of the computing node over a historical time period, wherein the monitoring data includes CPU utilization, memory usage, and input / output throughput; determining the current scheduling strategy mode based on real-time service load indicators, the overall utilization level of cluster resources, and preset strategic factor indicators, wherein the scheduling strategy mode includes an online priority mode, a balanced mode, and an energy-saving mode; further, calculating a first resource quota that can be allocated to online tasks and a second resource quota that can be allocated to offline tasks for each computing node based on the predicted resource demand, remaining resources, and scheduling strategy mode; calculating a scheduling priority score for each task to be scheduled based on the service quality level, task weight, and task waiting time; and thus, allocating resources for the tasks to be scheduled based on the first resource quota, the second resource quota, and the scheduling priority score of each task, generating a resource scheduling decision. The technical solution of this application predicts future resource demand based on historical data, enabling forward-looking resource planning and allowing idle resources to be planned and utilized in advance, thus reducing resource idleness. Secondly, by comprehensively considering real-time load, cluster utilization, and policy factors, it dynamically switches between online priority, balanced, and energy-saving scheduling modes to ensure that resources can be allocated efficiently on demand in different scenarios. Finally, it coordinates and matches node-level fine-grained resource quotas generated based on prediction and policies with task priorities based on comprehensive service quality, weight, and waiting time, achieving precise matching between resource supply and task demand, avoiding resource fragmentation and mismatch, thereby maximizing the resource fill rate of offline tasks and the overall cluster utilization rate while ensuring the performance of online services.

[0068] Based on the above embodiments, optionally, the remote backup management method provided in this embodiment further includes the following steps:

[0069] (1) Determine whether the peak period of business load is about to begin based on the predicted resource demand.

[0070] The peak business load period refers to an upcoming time period during which the entire container cluster or its main business modules are expected to experience significantly higher service request pressure and processing load than usual, thereby simultaneously reaching or exceeding the preset high threshold for the demand for various computing resources.

[0071] In this embodiment, the predicted resource demand output by the load prediction model is compared with a preset peak discrimination threshold in real time during each decision cycle. When the predicted resource demand is continuously higher than the threshold and shows an upward trend, it is determined that the business load peak period is about to begin, thereby triggering subsequent replica expansion and resource preemption strategies to ensure the service quality of online services.

[0072] (2) If it is determined that the peak period of business load is about to begin, the replica expansion operation of critical online tasks will be triggered through the container orchestration interface according to the resource scheduling decision.

[0073] Container orchestration interfaces refer to the standard, procedural interfaces for communication and command exchange between the scheduling system and the underlying container orchestration platform (such as Kubernetes). These interfaces translate resource scheduling decisions into specific container management operations. Critical online tasks refer to online services with the highest or higher quality-of-service (QoS) level, stringent requirements for business continuity and response latency, and whose operational stability is given the highest priority. Replica scaling refers to the process of increasing the number of container instances (replicas) for a critical online task through the container orchestration interface, aiming to address anticipated or sudden increases in business load by enhancing parallel processing capabilities.

[0074] In this embodiment, if it is confirmed that a peak period of business load is about to begin based on the predicted resource demand, the container orchestration interface can be called to issue an expansion command to the container cluster according to the critical online tasks and their required number of replicas listed in the generated resource scheduling decision. This will automatically increase the number of container replicas of the critical online tasks in the cluster, thereby dispersing the upcoming business pressure in advance and ensuring service quality.

[0075] (3) If it is determined that the business load is about to enter a low period, the resource quota compression operation of the offline task is triggered through the container orchestration interface according to the resource scheduling decision.

[0076] Among them, the resource quota compression operation refers to the instruction action actively issued through the container orchestration interface after predicting or detecting that the business load has entered a low period, which aims to reduce the maximum limit of various computing resources (such as central processing unit and memory) currently allowed to be used by offline tasks.

[0077] In this embodiment, if it is confirmed that the business load is about to enter a low-peak period based on the predicted resource demand, a scaling-down instruction can be issued to the container cluster through the container orchestration interface according to the compression range and target nodes listed for offline tasks in the resource scheduling decision. This dynamically reduces the upper limit of the second resource quota for offline tasks on resources such as central processing unit, memory, and input / output, so that offline tasks can give up excess resources for critical online tasks to reserve or for nodes to save energy. At the same time, it ensures that offline tasks can still proceed slowly under the limited quota, thereby realizing resource recovery and energy consumption optimization during the low-peak period.

[0078] This configuration combines forward-looking resource forecasting with dynamic resource adjustment mechanisms to achieve intelligent prediction and proactive response to business load fluctuations. Specifically, when a business load peak is predicted, the system can proactively and automatically expand the replicas of critical online tasks, thereby enhancing service processing capacity and elasticity in advance. This effectively avoids performance bottlenecks or service degradation caused by insufficient resources, ensuring high availability of online services and a smooth user experience. Conversely, when a business load is predicted to enter a low-peak period, the system can automatically trigger resource quota compression for offline tasks, proactively reclaiming and releasing idle resources. This not only optimizes the overall resource utilization of the cluster and reduces unnecessary resource holding costs, but also reserves sufficient resource margin for potential subsequent load peaks, forming an intelligent resource management closed loop of peak shaving and on-demand supply.

[0079] Based on the above embodiments, optionally, the remote backup management method provided in this embodiment further includes the following steps:

[0080] (1) Continuously monitor the real-time performance indicators of each computing node; among which, the real-time performance indicators include the periodic fluctuation of the CPU utilization, the response latency of container services, and the degree of network transmission congestion.

[0081] Among these, real-time performance metrics refer to the dynamic data set continuously collected by the scheduling system to reflect the health status of compute nodes and the containers running on them in real time. The periodic fluctuation amplitude of CPU utilization specifically refers to the degree of volatility and regularity of changes in a node's CPU utilization around its average level within a continuous fixed sampling period. Container service response latency refers to the length of time from when a user request is sent to a service running within a container and a valid response is received. Network congestion refers to the situation where, during data transmission, insufficient bandwidth or queue accumulation occurs at the node's network interface, resulting in decreased packet transmission efficiency or increased latency. These metrics collectively constitute the core basis for judging whether a node exhibits abnormal performance fluctuations and whether intervention is necessary.

[0082] In this embodiment, high-frequency data can be collected from each computing node in the container cluster in an uninterrupted manner, instantly capturing the periodic fluctuations in CPU utilization around its average value, the changes in request processing latency reflected by container service response delay, and the data channel blockage level reflected by network transmission congestion. These real-time performance indicators are summarized in real time and used for subsequent interference judgment condition detection, providing a quantitative basis for dynamic callback operations.

[0083] (2) Based on the preset interference judgment conditions, determine whether there is a performance fluctuation that needs to be intervened.

[0084] The interference judgment conditions include at least one of the following: the fluctuation of the CPU utilization rate of the computing node exceeds a first threshold in multiple consecutive sampling periods; the container service response latency exceeds a preset multiple of the historical average; and the network transmission congestion level exceeds a second threshold.

[0085] In this scheme, interference judgment conditions refer to a set of logical judgment rules preset by the scheduling system to identify whether there are abnormal performance fluctuations in computing nodes that require intervention. These conditions specifically include: whether the CPU utilization jitter of the computing node exceeds a first threshold within multiple consecutive sampling periods, used to identify continuous and unstable CPU load fluctuations; whether the container service response latency exceeds a preset multiple of its historical average, used to determine whether service performance has significantly deteriorated; and whether the network transmission congestion level exceeds a second threshold, used to detect whether there are serious bottlenecks in the network link. When any one of the conditions is met, the system determines that there is a performance fluctuation that requires intervention.

[0086] (3) When it is determined that there is a performance fluctuation that requires intervention, a dynamic callback operation is executed.

[0087] The dynamic callback operation includes at least one of the following: migrating offline tasks from nodes with fluctuating performance to nodes with low load; dynamically reducing the CPU usage limit for low-priority tasks; and temporarily increasing the scheduling weight of critical online tasks.

[0088] In this embodiment, when it is confirmed that there is a performance fluctuation that requires intervention based on the preset interference judgment conditions, a fast reverse adjustment mechanism can be initiated in the container cluster. The offline tasks are preferentially moved out of the performance fluctuation node and rebound to the node with a lighter load. At the same time, the CPU usage limit of low-priority tasks on the node is immediately reduced, and the critical online tasks are given a higher scheduling weight, so that the critical online tasks can obtain priority allocation in the next round of resource competition, thereby eliminating performance jitter, restoring service quality and maintaining the stable operation of online services in the shortest possible time.

[0089] This configuration approach achieves rapid detection and proactive dynamic compensation for runtime performance interference through refined real-time monitoring of compute node performance metrics and intelligent judgment of preset thresholds. Specifically, it can promptly detect performance fluctuations such as CPU jitter, service latency spikes, or network congestion caused by resource contention, hardware anomalies, or network problems. Through dynamic callback operations, it provides precise intervention, effectively isolating performance interference sources, alleviating node pressure, ensuring the responsiveness and resource supply of critical online services, guaranteeing the achievement of service level targets in hybrid deployment environments, and improving the overall operational resilience and intelligent resource utilization of the cluster.

[0090] Based on the above embodiments, optionally, the remote backup management method provided in this embodiment further includes the following steps:

[0091] (1) Continuously monitor the status signals of each compute node in the container cluster and the running status of the container.

[0092] Status signals refer to communication messages periodically sent by each compute node in the container cluster or by the cluster management system to characterize its own survival and basic operational status, such as heartbeat signals. Container running status specifically refers to the current lifecycle stage and health status of each container instance (Pod) running on the compute node, such as whether it is running, whether it is in a crash loop due to repeated startup failures, or whether it is in an unknown state due to being undetectable.

[0093] In this embodiment, the heartbeat signal, resource availability, health probe return results, and start / stop, restart, and abnormal exit events of all containers running on each compute node in the container cluster can be captured in real time in an uninterrupted and comprehensive manner. The state changes of the node layer and the container layer are aggregated into a unified monitoring stream in real time, providing a continuous and consistent state data source for subsequent identification of node failures, triggering task migration, and replica restart based on preset fault judgment rules.

[0094] (2) Identify the computing nodes that have malfunctioned based on the preset fault judgment rules.

[0095] The preset fault judgment rules include at least one of the following: detecting that the heartbeat signal of the computing node is continuously lost for more than a preset first time threshold; detecting that the container running on the computing node repeatedly fails to restart within a preset number of times; detecting that the health probe of the computing node continuously returns a failure status.

[0096] Specifically, by continuously monitoring the status signals of each compute node in the container cluster and the running status of the containers, the duration of missing node heartbeat signals, the number of container restarts, and the results returned by health probes can be used as the basis for fault diagnosis. Once any indicator reaches the corresponding preset threshold, a fault determination is triggered, and the compute node can be marked as a faulty node and the subsequent task migration and recovery process can be started. This ensures that critical online and offline tasks can be quickly taken over and resources reallocated according to the priority order defined by the resource scheduling decision when a node-level failure occurs.

[0097] (3) When a node failure is detected, the affected critical online tasks are scheduled to be migrated to pre-marked redundant standby nodes based on the task priority defined in the resource scheduling decision.

[0098] Redundant standby nodes refer to pre-marked and reserved standby computing nodes in a container cluster, intended to take over critical tasks when the primary computing node fails. These nodes are typically idle or under low load and are assigned special identifiers (such as specific tags). Their core function is to provide immediate and available computing resources and runtime environments for affected critical online tasks in the event of a failure.

[0099] In this embodiment, when a computing node is confirmed to have failed according to the preset fault judgment rules, the container instances affected by the fault and whose priority meets the criteria for critical online tasks can be rescheduled to the idle resources of the redundant standby nodes in advance, based on the task priorities already assigned to each task in the resource scheduling decision. The target node change and task binding are completed through the container orchestration interface, ensuring that high-priority online services obtain continuously available computing resources and maintain service accessibility at the moment of failure.

[0100] (4) Automatically restart the container replicas of critical online tasks on redundant standby nodes and synchronously update the access routes for related services.

[0101] Specifically, once the faulty node isolation and task priority determination are completed, the container replicas corresponding to the critical online tasks can be launched on pre-marked and resource-sufficient redundant standby nodes through the container orchestration interface. This ensures that the application process and its dependent environment are restored to operation as before. At the same time, the access target address in the service registry, load balancer, or domain name resolution system is switched to the node where the new replica is located in real time. This allows external and internal traffic to be mapped to the restarted container instance without being aware of it, ensuring that critical online services remain available and the service entry point remains consistent during fault migration.

[0102] (5) Based on the remaining resource status of the container cluster, perform delayed recovery for the affected offline tasks.

[0103] In this embodiment, after the fault migration of critical online tasks is completed, the total amount of remaining CPU, memory and I / O resources of each node in the container cluster can be assessed. Based on the assessment results, offline tasks interrupted due to node failures are put back into the scheduling queue. Only when the remaining resource status allows and does not affect the service quality level of online tasks, the reduced second resource quota is gradually allocated to offline tasks in the order determined by the resource scheduling decision, so that they can restart and run with lower resource consumption after a delay period of time, thereby achieving elastic recovery of offline tasks while ensuring the priority of online services.

[0104] This configuration approach, through proactive monitoring and intelligent fault diagnosis, enables rapid and automated detection and self-healing of compute node and container operational anomalies, significantly improving the availability and business continuity of the container cluster. Specifically, the system can promptly and accurately identify faulty nodes based on multi-dimensional fault diagnosis rules, and automatically and quickly migrate affected critical online tasks to pre-configured redundant backup nodes according to preset task priority strategies. Subsequently, it automatically restarts services and updates routes, minimizing business interruption time. Simultaneously, the system can intelligently schedule delayed recovery of offline tasks based on the remaining cluster resources, prioritizing the core needs of online services. Ultimately, this constructs a highly elastic and reliable hybrid task scheduling and fault recovery closed loop.

[0105] Example 2

[0106] Figure 2 This is a schematic diagram of an adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment. Based on the foregoing embodiments, this embodiment provides a more detailed description of steps S120-S130, and the specific implementation can be found in the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0107] like Figure 2 As shown, the method specifically includes the following steps:

[0108] S210. For each compute node in the container cluster, based on the monitoring data of the compute node in the historical time period, determine the predicted resource demand of the compute node in the future preset scheduling period.

[0109] The monitoring data includes CPU utilization, memory usage, and input / output throughput.

[0110] S220. Determine the current scheduling strategy mode based on real-time business load indicators, overall cluster resource utilization level, and preset strategic factor indicators.

[0111] The scheduling strategy modes include online priority mode, balanced mode and energy-saving mode.

[0112] Optionally, the specific implementation steps for determining the current scheduling strategy mode may include:

[0113] S1. Based on the currently collected data on central processing unit utilization, service request latency, input / output throughput, and application load pressure trends, determine real-time business load indicators.

[0114] Among them, the application load pressure trend refers to the qualitative or semi-quantitative judgment on whether the load pressure that business applications may face in the near future tends to increase, remain stable, or decrease.

[0115] In this embodiment, at each sampling instant, the three types of real-time data just collected—CPU utilization, service request latency, and input / output throughput—are fused with the rising or falling trends reflected by the application load pressure. A comprehensive quantitative result is generated through weighted or threshold comparison, which is the real-time business load index. This index is used in subsequent steps, together with the overall utilization level of cluster resources and preset strategic factor indicators, to determine the switching of the current scheduling strategy mode, ensuring that online services and offline tasks receive matching resource allocation strategies under different load intensities.

[0116] S2. Determine the overall resource utilization level based on the load distribution status of each computing node in the container cluster and the proportion of idle nodes.

[0117] Specifically, by aggregating the real-time CPU utilization, memory usage, and input / output throughput of each computing node, the distribution of nodes under high load, balanced, or idle conditions is comprehensively evaluated. The proportion of nodes marked as idle to the total number of nodes in the cluster is also counted. After weighted fusion of the load distribution status and the proportion of idle nodes, a quantitative result representing the overall resource consumption of the cluster is generated. This result is the overall resource utilization level, which, together with real-time business load indicators and preset strategic factor indicators, determines the switching selection of the current scheduling strategy mode between online priority, balanced, or energy saving.

[0118] S3. Based on the pre-configured scheduling time window, operation and maintenance policy rules, and external business event information, determine strategic factor indicators.

[0119] Specifically, it can read the scheduling time window length and start and end times preset by the administrator, the description of the peak-valley and flat-peak resource tilt ratio and task guarantee level in the operation and maintenance strategy rules, and subscribe to the promotion, release or fault notification signals carried by external business event information. It can integrate and calculate these time boundaries, strategy constraints and event triggering conditions to generate strategic factor indicators for intervening in scheduling decision weights, so as to determine the priority ranking and resource allocation tendency of online priority mode, balanced mode or energy saving mode in the current cycle.

[0120] S4. Based on real-time business load indicators, overall resource utilization level, and strategic factor indicators, calculate the corresponding mode fitness attributes for online priority mode, balanced mode, and energy-saving mode, respectively.

[0121] The mode fitness attribute refers to a comprehensive evaluation value calculated through quantitative analysis for each of the three candidate scheduling strategy modes—online priority mode, balanced mode, and energy-saving mode—representing their applicability under the current cluster operating conditions. This attribute score is calculated based on multi-dimensional inputs such as real-time business load indicators, overall resource utilization levels, and strategic factor indicators. A higher score indicates that the mode is more adaptable to the needs and constraints of the current scenario, serving as a key decision-making basis for adaptive selection of scheduling strategies.

[0122] In this embodiment, within each decision cycle, the current business pressure reflected by the real-time business load index, the cluster resource consumption level represented by the overall resource utilization level, and the time window and operation and maintenance event policy requirements carried by the strategic factor index are all input into the fitness evaluation functions configured for online priority mode, balanced mode, and energy-saving mode respectively. The applicable scores of the three modes in the current scenario are quantified by weighting or rule mapping. This score is the mode fitness attribute, which is used to directly compare and select the optimal scheduling strategy mode to guide the subsequent allocation of the first resource quota and the second resource quota and task sorting.

[0123] S5. Based on the mode fitness attribute, select the scheduling strategy mode with the highest attribute score as the currently executed scheduling strategy mode.

[0124] Specifically, after calculating the fitness attributes of each of the three modes—online priority mode, balanced mode, and energy-saving mode—the three scores can be compared, and the scheduling strategy mode corresponding to the one with the largest score can be established as the currently effective scheduling strategy mode. Subsequent resource quota allocation, task sorting, and expansion / contraction operations will all be executed according to the tilt rules of this mode until the next decision cycle is recalculated and may switch to other modes.

[0125] S230. Calculate the current remaining resources for each computing node; where the remaining resources are the difference between the total resources of the computing node and the currently used resources.

[0126] In this embodiment, at each scheduling decision moment, the configuration limit of the total amount of central processing unit, memory and input / output resources of each computing node is read. At the same time, the corresponding resource components currently actually occupied by all container processes in the node are collected. The real-time difference obtained by subtracting the used resources from the total resources is used as the current remaining resources. This is used to measure the remaining capacity of the node to carry new online or offline tasks, and serves as the direct basis for the subsequent division of the first resource quota and the second resource quota.

[0127] S240. Compare the predicted resource demand with the current remaining resource, and take the smaller value as the available resource quantity for the computing node.

[0128] The amount of resources that can be allocated refers to the maximum amount of resources that can be allocated to new tasks or used to flexibly expand existing tasks.

[0129] In this embodiment, within each scheduling cycle, the predicted resource demand given by the load prediction model is compared one-to-one with the current remaining resource quantity obtained by the node in real time. If the predicted value is higher than the remaining quantity, the remaining quantity is used as the upper limit; if the predicted value is lower than the remaining quantity, the predicted value is used as the upper limit. The smaller value selected is the amount of resources that the computing node can allocate. This is used to ensure that the resources allocated to the first and second resource quotas are neither crowded out by the predicted peak demand nor exceed the actual idle capacity of the node, thereby avoiding overload or waste.

[0130] S250. Based on the current execution scheduling strategy mode, allocate the amount of scalable resources between online and offline tasks to determine the first and second resource quotas for each computing node.

[0131] In this embodiment, the available resources of a computing node can be divided into online and offline tasks according to the tilt ratio and priority rules specified by the selected online priority mode, balanced mode, or energy-saving mode: the online priority mode tilts more available resources to the first resource quota side, the energy-saving mode prioritizes compressing the available resources on the second resource quota side, and the balanced mode compromises according to a preset ratio, ultimately forming a first resource quota for online tasks and a second resource quota for offline tasks for each computing node, which are used for subsequent task screening and binding.

[0132] Based on the above embodiments, optionally, the specific implementation steps for determining the first resource quota and the second resource quota for each computing node may include:

[0133] (1) When the current scheduling strategy mode is online priority mode, the preset high proportion of the available resources is determined as the first resource quota for online tasks, and the remaining part is determined as the second resource quota for offline tasks; wherein, the preset high proportion can be 70%-90%.

[0134] In this embodiment, when it is determined that the currently effective scheduling strategy mode is the online priority mode, at least 70% and no more than 90% of the available resources are directly allocated to online tasks according to a preset tilt ratio, forming the first resource quota. The remaining small amount of resources after deducting this high proportion are all allocated to offline tasks, forming the second resource quota. This ensures that online services receive absolute priority in resource competition, while still leaving minimum operating space for offline tasks.

[0135] (2) When the current scheduling strategy mode is balanced mode, the amount of available resources is determined as the first resource quota for online tasks according to the preset first ratio, and as the second resource quota for offline tasks according to the preset second ratio.

[0136] Specifically, when the current effective scheduling strategy is determined to be the balanced mode, it no longer favors any type of task. Instead, it directly splits the available resources into two parts according to a pre-set first and second ratio. The first part is allocated to online tasks to form the first resource quota, and the second part is allocated to offline tasks to form the second resource quota. Both types of quotas exist simultaneously within the same node and the ratio is fixed, so that online services and offline computing maintain a relative balance in resource usage. This can meet the online service needs during normal periods and make full use of the remaining computing power to advance offline tasks.

[0137] (3) When the current scheduling strategy mode is energy saving mode, identify computing nodes whose load level is lower than the preset threshold, release the resource requirements corresponding to the task to be migrated from the first resource quota and the second resource quota, and re-plan the released resources to the quota of the target integration node.

[0138] In this embodiment, when the currently effective scheduling strategy mode is determined to be the energy-saving mode, the real-time load level of each computing node can be scanned, and nodes with loads below a preset threshold can be marked as source nodes to be integrated. Then, the resource requirements corresponding to all online and offline tasks on these nodes are deducted from their respective first and second resource quotas and released to form a recyclable resource pool. The total amount of released resources is then reallocated to the first and second resource quotas of the target integration node, so that low-load nodes can be freed up and taken offline. After the target integration node obtains the new quota, it can concentrate on carrying tasks, thereby reducing energy consumption and improving resource utilization.

[0139] S260. Calculate the scheduling priority score for each task to be scheduled based on its service quality level, task weight, and task waiting time.

[0140] S270. Based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, resource allocation is performed for the tasks to be scheduled, and resource scheduling decisions are generated.

[0141] The technical solution of this application, when determining the current scheduling strategy mode, determines real-time business load indicators based on currently collected data such as CPU utilization, service request latency, input / output throughput, and application load pressure trends; determines the overall resource utilization level based on the load distribution status of each computing node in the container cluster and the proportion of idle nodes; determines strategic factor indicators based on pre-configured scheduling time windows, operation and maintenance policy rules, and external business event information; and calculates corresponding mode fitness attributes for online priority mode, balanced mode, and energy-saving mode based on real-time business load indicators, overall resource utilization level, and strategic factor indicators, respectively. According to the mode fitness attributes, the scheduling strategy mode with the highest attribute score is selected as the currently executed scheduling strategy mode. The technical solution of this application can comprehensively consider real-time business load indicators reflecting current business pressure, overall resource utilization level characterizing the overall resource status of the cluster, and strategic factor indicators representing external constraints and business objectives, calculating a quantified mode fitness attribute value for each of the three candidate strategies: online priority mode, balanced mode, and energy-saving mode. By comparing these attribute values, the system can automatically and objectively select the optimal scheduling strategy that best suits the current multidimensional operating environment and business needs. This ensures that the resource allocation logic can match the fluctuations in business load, the abundance or scarcity of cluster resources, and the guidance of operation and maintenance strategies in real time and accurately, significantly improving the adaptability and overall efficiency of hybrid task scheduling in complex dynamic environments.

[0142] The technical solution of this application embodiment calculates the current remaining resource amount of each computing node when calculating the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks. The remaining resource amount is the difference between the total resource amount of the computing node and the currently used resource amount. The predicted resource demand is compared with the current remaining resource amount, and the smaller value is taken as the available resource amount of the computing node. Based on the currently executed scheduling strategy mode, the available resource amount is allocated between online tasks and offline tasks to determine the first resource quota and the second resource quota of each computing node. The technical solution of this application firstly clarifies the current actual available resource balance by calculating the remaining node resources; secondly, it takes the smaller value between the predicted resource demand and this balance as the amount of adjustable resources. This operation constructs a critical safety boundary—preventing the risk of resource over-allocation due to overly optimistic predictions while reserving necessary resources to cope with predicted future demands; finally, based on an adaptive scheduling strategy, this safe and adjustable resource amount is strategically divided between online and offline tasks, thereby ensuring that resource allocation strictly follows different business objectives, from high real-time performance assurance to energy saving, while always being based on the node's own robust supply capacity, achieving a unity of security, foresight, and strategy in resource supply.

[0143] Example 3

[0144] Figure 3 This is a schematic diagram of an adaptive scheduling method for hybrid online and offline tasks provided in this application embodiment. Based on the foregoing embodiments, this embodiment provides a more detailed description of steps S140-S150, and the specific implementation can be found in the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0145] like Figure 3 As shown, the method specifically includes the following steps:

[0146] S310. For each compute node in the container cluster, based on the monitoring data of the compute node in the historical time period, determine the predicted resource demand of the compute node in the future preset scheduling period.

[0147] The monitoring data includes CPU utilization, memory usage, and input / output throughput.

[0148] S320. Determine the current scheduling strategy mode based on real-time business load indicators, overall cluster resource utilization level, and preset strategic factor indicators.

[0149] S330. Based on the predicted resource demand, remaining resources, and scheduling strategy, calculate the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node.

[0150] S340. Based on the preset service quality level of each task to be scheduled, determine the corresponding level quantification value; based on the business importance definition of each task to be scheduled, determine the corresponding task weight coefficient; based on the cumulative waiting time of each task to be scheduled from the time it enters the scheduling queue to the current time, determine the normalized waiting time penalty value.

[0151] The grade quantification value refers to a numerical value that can be used in calculations, which maps the preset service quality level (such as critical, high, medium, low) of the task to be scheduled according to established rules. The task weight coefficient is a multiplier factor assigned based on the definition of task business importance, used to further adjust its relative priority within the same service quality level. The waiting time penalty value is a normalized value obtained by normalizing the cumulative waiting time of the task from when it entered the scheduling queue to the current time, used to quantify the scheduling urgency caused by waiting.

[0152] Specifically, the system can read the preset service quality level assigned to a task during creation and map this level to a quantified value that can be used in numerical calculations. The higher the level, the larger the quantified value, which is used to reflect the task's resource guarantee requirements in subsequent calculations. Based on the level declaration of the business carried by the task or the importance definition marked by the administrator, a task weight coefficient is assigned to the task. The higher the importance, the larger the coefficient, which is used to amplify the priority of resource acquisition in priority calculations. The system records the start time of the task entering the scheduling queue and subtracts the start time from the current time to obtain the accumulated waiting time. This time is then converted into a waiting time penalty value through a normalization method. The longer the wait, the larger the penalty value, which is used to improve the ranking position of long-waiting tasks in the priority score and avoid task starvation.

[0153] S350 calculates the scheduling priority score for each task to be scheduled based on the level quantification value, task weight coefficient, and normalized waiting time penalty value, combined with the preset penalty factor.

[0154] The penalty factor is a configured adjustment coefficient used to regulate the impact of task waiting time on the final scheduling priority score.

[0155] In this embodiment, the basic weight is obtained by multiplying the quantified value of the service quality requirement level with the task weight coefficient that reflects the importance of the business. Then, the normalized waiting time penalty value is multiplied with the preset penalty factor to obtain the waiting penalty amount. By subtracting the waiting penalty amount from the basic weight and superimposing an optional fine-tuning offset, a comprehensive scheduling priority score is generated. This score highlights the urgency of high-level, high-weight tasks while also taking into account the fairness of long-waiting tasks. It is used to determine the order in which tasks obtain resources in subsequent sorting.

[0156] S360. Sort all tasks to be scheduled in descending order based on scheduling priority scores to generate a sequence of tasks to be scheduled for execution.

[0157] The task execution sequence refers to a list of tasks with a clear order, formed by arranging all tasks in descending order of their calculated scheduling priority scores. This sequence determines the specific order in which each task is considered and allocated resources during subsequent resource matching, and is a crucial intermediate output connecting task priority calculation and final resource binding execution.

[0158] In this embodiment, after calculating the scheduling priority score of each task to be scheduled, all tasks can be arranged in descending order of scheduling priority score to form an ordered list. This list is the execution sequence of the tasks to be scheduled. During subsequent node matching and resource binding, the tasks are strictly processed in this sequence to ensure that tasks with high scheduling priority scores get available nodes and quotas first, while tasks with low scheduling priority scores are moved to the back in order until all tasks are allocated or resources are exhausted.

[0159] S370. According to the execution sequence of the tasks to be scheduled, match the computing nodes for each task to be scheduled in turn.

[0160] Specifically, following the pre-arranged sequence of tasks to be scheduled, starting with the task with the highest priority score, the online or offline attributes of each task are queried in turn. Combined with the corresponding first or second resource quota, a set of computing nodes with sufficient spare capacity is selected. Then, based on node affinity rules or anti-affinity rules, a unique target node is determined from the candidate nodes to complete resource reservation and binding, until all tasks in the sequence are deployed or cluster resources are exhausted. This ensures that high-priority tasks receive resources first and that the matching process is orderly and without omissions.

[0161] S380. During the matching process, for online tasks, the set of target nodes that can be deployed is determined based on the first resource quota, and node affinity rules pointing to high-performance node groups are set for critical online tasks.

[0162] Specifically, when selecting nodes for online tasks, the first upper limit is set by the first resource quota of each computing node. Nodes with insufficient remaining resources are eliminated to form a set of deployable target nodes. Then, for objects marked as critical online tasks, node affinity rules are added to force them to be scheduled only to the pre-divided high-performance node group. This ensures that critical online tasks obtain high-frequency, large-memory, and low-latency hardware resources, thereby guaranteeing service quality and user experience.

[0163] S390. During the matching process, for offline tasks, the set of target nodes that can be deployed is determined according to the second resource quota, and anti-affinity rules are set for offline tasks to avoid deployment to high-load computing nodes.

[0164] Specifically, when selecting nodes for offline tasks, the second resource quota of each computing node is used as the upper limit to eliminate nodes whose remaining resources are insufficient to meet the task requirements, forming a set of deployable target nodes. Then, an anti-affinity rule is applied to the high-load computing nodes in this set, so that offline tasks are preferentially scheduled to nodes with lower load and more abundant resources, thereby preventing offline computing from exacerbating the resource pressure on high-load nodes and ensuring the stability of online business operations.

[0165] The technical solution of this application, when calculating the scheduling priority score of each task to be scheduled, determines the corresponding level quantification value based on the preset service quality level of each task; determines the corresponding task weight coefficient based on the business importance definition of each task; determines the normalized waiting time penalty value based on the cumulative waiting time of each task from entering the scheduling queue to the current time; and calculates the scheduling priority score of each task based on the level quantification value, task weight coefficient, and normalized waiting time penalty value, combined with a preset penalty factor. This technical solution not only assigns static basic priorities to tasks based on preset service quality levels and business importance, ensuring that high-security-level and critical businesses can obtain resources first; but also, by introducing a normalized penalty value based on cumulative waiting time and dynamically adjusting it in conjunction with a penalty factor, the model effectively incorporates the fairness factor of waiting time into consideration. This automatically increases the scheduling urgency of tasks with long waiting times, thereby intelligently preventing low-priority tasks from falling into an indefinite waiting state due to continuous resource preemption by high-priority tasks. Ultimately, the scheduling priority score generated by this calculation method provides a scientific and quantitative basis for subsequent task sorting and resource matching that respects business preset rules while dynamically maintaining the long-term fairness of the system.

[0166] The technical solution of this application embodiment, when generating resource scheduling decisions, sorts all tasks to be scheduled in descending order based on scheduling priority scores to generate a task execution sequence; according to the task execution sequence, it matches computing nodes for each task to be scheduled in turn; during the matching process, for online tasks, it determines the set of deployable target nodes based on the first resource quota, and sets node affinity rules pointing to high-performance node groups for critical online tasks; during the matching process, for offline tasks, it determines the set of deployable target nodes based on the second resource quota, and sets anti-affinity rules for offline tasks to avoid deployment to high-load computing nodes. The technical solution of this application, firstly, generates a task execution sequence in descending order of scheduling priority scores, ensuring that high-priority tasks are processed first and guaranteeing the timeliness of critical business scheduling; secondly, when matching nodes for tasks, the system strictly selects the set of nodes that meet the conditions based on the pre-calculated first and second resource quotas, ensuring that resource allocation does not exceed the limits and conforms to the policy orientation; finally, by setting node affinity rules for critical online tasks, they are scheduled to high-performance node groups to ensure service quality, while setting anti-affinity rules for offline tasks, which actively avoid high-load nodes, effectively isolating the performance interference of offline tasks on online services, and ultimately achieving efficient and orderly allocation of resources and operational isolation between the two types of tasks in a hybrid deployment scenario.

[0167] Example 4

[0168] Figure 4 This application provides a schematic diagram of an adaptive scheduling device for hybrid online and offline tasks, applied in a container cluster where online services and offline tasks are deployed in a hybrid manner. The device includes:

[0169] The resource demand prediction module 410 is used to determine the predicted resource demand of each computing node in the container cluster within a future preset scheduling period based on the monitoring data of the computing nodes in the historical time period; wherein, the monitoring data includes CPU utilization, memory usage, and input / output throughput.

[0170] The strategy mode determination module 420 is used to determine the current scheduling strategy mode based on real-time business load indicators, overall cluster resource utilization level and preset strategic factor indicators; wherein, the scheduling strategy mode includes online priority mode, balanced mode and energy saving mode.

[0171] The resource quota determination unit 430 is used to calculate, based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode, a first resource quota that can be allocated to online tasks and a second resource quota that can be allocated to offline tasks for each computing node.

[0172] The task priority determination module 440 is used to calculate the scheduling priority score of each task to be scheduled based on the service quality level, task weight and task waiting time of each task to be scheduled.

[0173] The scheduling decision determination module 450 is used to allocate resources to the task to be scheduled based on the first resource quota, the second resource quota of each computing node and the scheduling priority score of each task to be scheduled, and generate a resource scheduling decision.

[0174] This application provides an adaptive scheduling device for hybrid online and offline tasks. When applied, this device determines the predicted resource demand of each computing node in a container cluster within a future preset scheduling period based on monitoring data of the computing nodes over a historical time period. The monitoring data includes CPU utilization, memory usage, and input / output throughput. Based on real-time business load indicators, the overall utilization level of cluster resources, and preset strategic factors, a current scheduling strategy mode is determined. This scheduling strategy mode includes online priority mode, balanced mode, and energy-saving mode. Further, based on the predicted resource demand, remaining resources, and scheduling strategy mode, a first resource quota that can be allocated to online tasks and a second resource quota that can be allocated to offline tasks are calculated for each computing node. Based on the service quality level, task weight, and task waiting time of each task to be scheduled, a scheduling priority score is calculated for each task. Therefore, based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, resource allocation is performed for the tasks to be scheduled, generating a resource scheduling decision. The technical solution of this application predicts future resource demand based on historical data, enabling forward-looking resource planning and allowing idle resources to be planned and utilized in advance, thus reducing resource idleness. Secondly, by comprehensively considering real-time load, cluster utilization, and policy factors, it dynamically switches between online priority, balanced, and energy-saving scheduling modes to ensure that resources can be allocated efficiently on demand in different scenarios. Finally, it coordinates and matches node-level fine-grained resource quotas generated based on prediction and policies with task priorities based on comprehensive service quality, weight, and waiting time, achieving precise matching between resource supply and task demand, avoiding resource fragmentation and mismatch, thereby maximizing the resource fill rate of offline tasks and the overall cluster utilization rate while ensuring the performance of online services.

[0175] Based on the above-mentioned device, optionally, a resource demand prediction module 410 is used for each computing node to collect corresponding real-time monitoring data based on a fixed monitoring period; at each prediction trigger time, to obtain the historical monitoring data sequence formed by each computing node in the most recent continuous monitoring period from the collected real-time monitoring data; to extract time-series sample data within the corresponding time window from the historical monitoring data sequence based on a preset sliding time window; to input the time-series sample data into a pre-trained load prediction model, and to output the predicted resource demand of each computing node in the future preset scheduling period.

[0176] Based on the aforementioned device, optionally, the strategy mode determination module 420 is specifically used to determine real-time service load indicators based on currently collected central processing unit utilization, service request latency, input / output throughput, and application load pressure trends; determine the overall resource utilization level based on the load distribution status of each computing node in the container cluster and the proportion of idle nodes; determine strategic factor indicators based on pre-configured scheduling time windows, operation and maintenance policy rules, and external business event information; calculate the corresponding mode fitness attributes for the online priority mode, the balanced mode, and the energy-saving mode based on the real-time service load indicators, the overall resource utilization level, and the strategic factor indicators; and select the scheduling strategy mode with the highest attribute score as the currently executed scheduling strategy mode according to the mode fitness attributes.

[0177] Based on the above-mentioned device, optionally, a resource quota determination unit 430 is used to calculate the current remaining resource amount of each computing node; wherein, the remaining resource amount is the difference between the total resource amount of the computing node and the currently used resource amount; the predicted resource demand is compared with the current remaining resource amount, and the smaller value between the two is taken as the available resource amount of the computing node; based on the currently executed scheduling strategy mode, the available resource amount is allocated between online tasks and offline tasks to determine the first resource quota and the second resource quota of each computing node.

[0178] Based on the above-mentioned device, optionally, the resource quota determination unit 430 is further configured to, when the current scheduling strategy mode is online priority mode, determine a preset high proportion of the available resources as the first resource quota for online tasks and the remaining portion as the second resource quota for offline tasks; wherein, the preset high proportion can be in the range of 70%-90%; when the current scheduling strategy mode is balanced mode, determine the available resources as the first resource quota for online tasks according to a preset first proportion and as the second resource quota for offline tasks according to a preset second proportion; when the current scheduling strategy mode is energy-saving mode, identify computing nodes with load levels below a preset threshold, release the resource requirements corresponding to the tasks to be migrated from the first and second resource quotas, and reallocate the released resources to the quota of the target integration node.

[0179] Based on the above-mentioned device, optionally, the task priority determination module 440 is used to determine the corresponding level quantification value based on the preset service quality level of each task to be scheduled; determine the corresponding task weight coefficient based on the business importance definition of each task to be scheduled; determine the normalized waiting time penalty value based on the cumulative waiting time of each task to be scheduled from the time it enters the scheduling queue to the current time; and calculate the scheduling priority score of each task to be scheduled based on the level quantification value, the task weight coefficient, and the normalized waiting time penalty value, combined with a preset penalty factor.

[0180] Based on the above-mentioned device, optionally, the scheduling decision determination module 450 is specifically used to sort all tasks to be scheduled in descending order based on the scheduling priority score to generate a task execution sequence; according to the task execution sequence, to match computing nodes for each task to be scheduled in turn; during the matching process, for online tasks, to determine the set of deployable target nodes based on the first resource quota, and to set node affinity rules pointing to high-performance node groups for critical online tasks; during the matching process, for offline tasks, to determine the set of deployable target nodes based on the second resource quota, and to set anti-affinity rules for offline tasks to avoid deployment to high-load computing nodes.

[0181] Optionally, based on the above-mentioned device, the device further includes: a peak period quota adjustment module, used to determine whether a peak business load period is about to begin based on the predicted resource demand; if it is determined that a peak business load period is about to begin, then according to the resource scheduling decision, trigger a replica expansion operation for critical online tasks through a container orchestration interface; if it is determined that a low business load period is about to begin, then according to the resource scheduling decision, trigger a resource quota compression operation for offline tasks through a container orchestration interface.

[0182] Optionally, based on the above-described device, the device further includes: a dynamic callback module, used to continuously monitor the real-time performance indicators of each computing node; wherein the real-time performance indicators include the periodic fluctuation amplitude of CPU utilization, container service response latency, and network transmission congestion level; based on preset interference judgment conditions, determining whether there is a performance fluctuation that requires intervention; wherein the interference judgment conditions include at least one of the following: the fluctuation amplitude of CPU utilization of the computing node exceeds a first threshold within multiple consecutive sampling periods; the container service response latency exceeds a preset multiple of the historical average; the network transmission congestion level exceeds a second threshold; when it is determined that there is a performance fluctuation that requires intervention, a dynamic callback operation is executed; wherein the dynamic callback operation includes at least one of the following: migrating offline tasks from performance fluctuation nodes to low-load nodes; dynamically reducing the CPU utilization limit of low-priority tasks; temporarily increasing the scheduling weight of critical online tasks.

[0183] Optionally, based on the above-described device, the device further includes: a node fault handling module, used to continuously monitor the status signals of each compute node in the container cluster and the running status of the containers; to identify the compute node that has failed based on preset fault judgment rules; wherein the preset fault judgment rules include at least one of the following: detecting that the heartbeat signal of the compute node is continuously lost for more than a preset first time threshold; detecting that the container running on the compute node repeatedly fails to restart within a preset number of times; detecting that the health probe of the compute node continuously returns a failure status; when a node fault is identified, based on the task priority defined in the resource scheduling decision, the affected critical online tasks are scheduled and migrated to pre-marked redundant standby nodes; the container replicas of the critical online tasks are automatically restarted on the redundant standby nodes, and the relevant service access routes are updated synchronously; and the affected offline tasks are delayed in recovery based on the remaining resource status of the container cluster.

[0184] The online / offline hybrid task adaptive scheduling device provided in this application can execute the online / offline hybrid task adaptive scheduling method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method.

[0185] It is worth noting that the various units and modules included in the above system are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the protection scope of the embodiments of this application.

[0186] Note that the above description is merely a preferred embodiment and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments. Many other equivalent embodiments may be included without departing from the concept of this application, and the scope of this application is determined by the scope of the appended claims.

Claims

1. An adaptive scheduling method for hybrid online and offline tasks, applied to a container cluster where online services and offline tasks are deployed in a hybrid manner, characterized in that, The method includes: For each compute node in the container cluster, based on the monitoring data of the compute node in the historical time period, the predicted resource demand of the compute node in the future preset scheduling period is determined; wherein, the monitoring data includes CPU utilization, memory usage, and input / output throughput. Based on real-time business load indicators, overall cluster resource utilization levels, and preset strategic factor indicators, the current scheduling strategy mode is determined; wherein, the scheduling strategy mode includes online priority mode, balanced mode, and energy-saving mode. Based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode, calculate the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node. Based on the service quality level, task weight, and task waiting time of each task to be scheduled, calculate the scheduling priority score for each task to be scheduled. Based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, resource allocation is performed for the task to be scheduled, and a resource scheduling decision is generated.

2. The method according to claim 1, characterized in that, The process of determining the predicted resource requirements of the computing nodes within a future preset scheduling period based on monitoring data of the computing nodes over a historical time period includes: Each computing node collects corresponding real-time monitoring data based on a fixed monitoring cycle; At each prediction trigger time, the historical monitoring data sequence formed by each computing node in the most recent continuous monitoring period is obtained from the collected real-time monitoring data. Based on a preset sliding time window, time-series sample data within the corresponding time window is extracted from the historical monitoring data sequence; The time-series sample data is input into a pre-trained load prediction model, which outputs the predicted resource demand of each computing node within the future preset scheduling period.

3. The method according to claim 1, characterized in that, The process of determining the current scheduling strategy mode based on real-time service load indicators, overall cluster resource utilization levels, and preset strategic factor indicators includes: Based on the current collected data on CPU utilization, service request latency, input / output throughput, and application load pressure trends, determine real-time business load indicators. Based on the load distribution status of each computing node in the container cluster and the proportion of idle nodes, the overall resource utilization level is determined. Based on pre-configured scheduling time windows, operation and maintenance policy rules, and external business event information, strategic factor indicators are determined. Based on the real-time business load index, the overall resource utilization level, and the strategic factor index, calculate the corresponding mode fitness attributes for the online priority mode, the balanced mode, and the energy-saving mode, respectively. Based on the pattern fitness attribute, the scheduling strategy pattern with the highest attribute score is selected as the currently executed scheduling strategy pattern.

4. The method according to claim 1, characterized in that, The step of calculating the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode includes: Calculate the current remaining resources for each computing node; wherein the remaining resources are the difference between the total resources of the computing node and the currently used resources. The predicted resource demand is compared with the current remaining resource amount, and the smaller value between the two is taken as the amount of resources that can be allocated to the computing node. Based on the currently executing scheduling strategy mode, the available resources are allocated between online and offline tasks to determine the first resource quota and the second resource quota for each computing node.

5. The method according to claim 4, characterized in that, The step of calculating the first resource quota that can be allocated to online tasks and the second resource quota that can be allocated to offline tasks for each computing node based on the predicted resource demand, the remaining resource quantity, and the scheduling strategy mode includes: When the current scheduling strategy mode is online priority mode, a preset high percentage of the available resources is determined as the first resource quota for online tasks, and the remaining portion is determined as the second resource quota for offline tasks; wherein, the preset high percentage can be in the range of 70%-90%; When the current scheduling strategy mode is balanced mode, the amount of available resources is determined as the first resource quota for online tasks according to a preset first ratio, and as the second resource quota for offline tasks according to a preset second ratio. When the current scheduling strategy mode is energy-saving mode, the computing nodes with load levels below a preset threshold are identified, the resource requirements corresponding to the tasks to be migrated are released from the first resource quota and the second resource quota, and the released resources are reallocated to the quota of the target integration node.

6. The method according to claim 1, characterized in that, The calculation of the scheduling priority score for each task to be scheduled, based on its service quality level, task weight, and task waiting time, includes: Based on the preset service quality level of each task to be scheduled, determine the corresponding level quantification value; Based on the business importance definition of each task to be scheduled, determine the corresponding task weight coefficient; Based on the cumulative waiting time of each task to be scheduled from the time it enters the scheduling queue to the current time, a normalized waiting time penalty value is determined. Based on the quantified level value, the task weight coefficient, and the normalized waiting time penalty value, combined with a preset penalty factor, the scheduling priority score of each task to be scheduled is calculated.

7. The method according to claim 1, characterized in that, The resource allocation for the tasks to be scheduled, based on the first resource quota, the second resource quota of each computing node, and the scheduling priority score of each task to be scheduled, and generating resource scheduling decisions, includes: Based on the scheduling priority score, all tasks to be scheduled are sorted in descending order to generate an execution sequence of tasks to be scheduled. According to the execution sequence of the tasks to be scheduled, a computing node is matched for each task to be scheduled in turn; During the matching process, for online tasks, the set of target nodes that can be deployed is determined based on the first resource quota, and node affinity rules pointing to high-performance node groups are set for critical online tasks. During the matching process, for offline tasks, the set of target nodes that can be deployed is determined based on the second resource quota, and anti-affinity rules are set for offline tasks to avoid deployment to high-load computing nodes.

8. The method according to claim 1, characterized in that, After generating the resource scheduling decision, the method further includes: Based on the predicted resource demand, determine whether the peak business load period is about to begin; If it is determined that a peak period of business load is about to begin, then based on the resource scheduling decision, the replica expansion operation of critical online tasks is triggered through the container orchestration interface; If it is determined that a period of low business load is about to begin, then based on the resource scheduling decision, the resource quota compression operation of offline tasks is triggered through the container orchestration interface.

9. The method according to claim 1, characterized in that, After generating the resource scheduling decision, the method further includes: Continuously monitor the real-time performance metrics of each computing node; wherein, the real-time performance metrics include the periodic fluctuation of CPU utilization, container service response latency, and network transmission congestion level; Based on preset interference judgment conditions, determine whether there is a performance fluctuation that requires intervention; wherein, the interference judgment conditions include at least one of the following: the central processing unit utilization of the computing node fluctuates by more than a first threshold within multiple consecutive sampling periods; the container service response latency exceeds a preset multiple of the historical average; the network transmission congestion level exceeds a second threshold. When a performance fluctuation requiring intervention is determined, a dynamic callback operation is executed; wherein, the dynamic callback operation includes at least one of the following: migrating offline tasks from the performance fluctuation node to a low-load node; dynamically reducing the CPU usage limit of low-priority tasks; and temporarily increasing the scheduling weight of critical online tasks.

10. The method according to claim 1, characterized in that, After generating the resource scheduling decision, the method further includes: Continuously monitor the status signals of each compute node in the container cluster and the running status of the containers; Based on preset fault judgment rules, the faulty computing nodes are identified; wherein, the preset fault judgment rules include at least one of the following: detecting that the heartbeat signal of the computing node is continuously lost for more than a preset first time threshold; detecting that the container running on the computing node repeatedly fails to restart within a preset number of times; detecting that the health probe of the computing node continuously returns a failure status; When a node failure is detected, the affected critical online tasks are relocated to pre-marked redundant backup nodes based on the task priorities defined in the resource scheduling decision. The container replicas of the critical online tasks are automatically restarted on the redundant standby node, and the relevant service access routes are updated synchronously. Based on the remaining resource status of the container cluster, delayed recovery is performed on the affected offline tasks.

Images