A method and device for dynamic real-time load isolation based on cloud-native schedulers

Abstract

This application provides a method and apparatus for dynamic isolation of hard real-time load based on a cloud-native scheduler. The method includes: deploying a latency monitoring process on each computing node in the cluster to monitor node latency data and aggregate node timing status; the cloud-native scheduler receiving node timing data sent by each node and obtaining node context data of each node; identifying nodes with excessive latency based on the timing data and the node real-time context data; generating scheduling decisions for nodes with excessive latency; receiving the scheduling decisions by a node agent process deployed on the nodes with excessive latency; isolating CPU cores and migrating hard real-time tasks for the nodes with excessive latency; and constructing a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby achieving dynamic load isolation of hard real-time tasks. This application can improve the stability of hard real-time tasks running in latency-sensitive environments.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for dynamic isolation of hard real-time load based on a cloud-native scheduler. Background Technology

[0002] With the rapid development and widespread application of cloud-native technologies, more and more real-time control systems are transforming towards containerization and adopting advanced container orchestration platforms such as Kubernetes for management. Cloud-native technologies, with their high scalability, elasticity, and automated operation and maintenance capabilities, have brought unprecedented convenience to distributed computing environments. However, in the process of migrating real-time control systems to cloud-native environments, a key technical challenge emerges: how to ensure that the deterministic latency requirements of hard real-time workloads are met in mixed workload scenarios.

[0003] Current Kubernetes schedulers are primarily designed for throughput-first or resource-balanced scenarios, with the core goal of maximizing cluster resource utilization and task throughput. This design approach performs well when handling general batch processing jobs or web services, but it falls short when facing hard real-time loads. Hard real-time loads place extremely stringent demands on system response time; even the slightest delay can lead to system instability or performance degradation, which is unacceptable in critical fields such as industrial control, smart manufacturing, automotive control, and aerospace.

[0004] In mixed workload scenarios, non-real-time tasks can interfere with real-time tasks in various ways, including but not limited to cache contention, memory bandwidth contention, and frequent interruptions. These interfering factors can cause hard real-time tasks to experience unpredictable latency, thereby compromising their deterministic latency requirements and causing hard real-time control tasks to fail. Existing scheduling strategies and isolation technologies cannot effectively address these challenges because they lack dynamic awareness and online isolation capabilities, and cannot form a closed-loop guarantee mechanism.

[0005] Based on the above factors, there is an urgent need for a dynamic isolation method for hard real-time load based on cloud-native schedulers, which aims to solve the problems existing in the current technology and improve the stability of hard real-time tasks running in latency-sensitive environments. Summary of the Invention

[0006] To address the problems in the prior art, this application provides a method and apparatus for dynamic isolation of hard real-time load based on a cloud-native scheduler, which can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0007] To solve at least one of the above problems, this application provides the following technical solution:

[0008] Firstly, this application provides a method for dynamic real-time load isolation based on a cloud-native scheduler, including:

[0009] Deploy a latency monitoring process on each compute node in the cluster to periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data, and system jitter data. Preprocess and aggregate the raw latency data to determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler.

[0010] The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node. It constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data. If the real-time performance indicators are higher than a threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node. The scheduling decision includes isolation decision and migration decision.

[0011] The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolated core, exclusively binds the existing hard real-time deployment units on the CPU core to the dedicated isolated core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, adjusts interrupt affinity to avoid interference with the isolated core, and constructs a resource allocator based on topology information. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolated core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolated core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0012] Further, the step of calculating the node's real-time performance metrics based on the node's time-series data and the node's real-time context data includes:

[0013] Configurable weighting coefficients are assigned to the scheduling delay, interruption delay, and system jitter indicators in the node time series data, respectively.

[0014] The number of CPUs and the node topological locality state can be used as adjustment factors to introduce the node data into the node real-time context data after weight allocation. The comprehensive real-time performance score of the node is calculated by linear weighted summation to determine the corresponding node real-time performance index.

[0015] Further, if the real-time performance metric exceeds a threshold, the node corresponding to the real-time performance metric exceeding the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, including:

[0016] The real-time performance indicators of each node are dynamically evaluated based on a preset latency threshold. If the real-time performance indicator of a node is higher than the preset threshold, the node is determined to be a node with excessive latency.

[0017] An isolation decision is generated for the node whose latency exceeds the limit, which is used to add the node to the real-time scheduling isolation list and prevent any new tasks with hard real-time identifiers from being scheduled to the node;

[0018] A migration decision is generated for the node whose latency exceeds the limit. This decision is used to query all hard real-time tasks currently running on the node whose latency exceeds the limit, and to generate a migration event for each hard real-time task.

[0019] Further, the node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolated core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolated core, simultaneously migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolated core, including:

[0020] The node agent process deployed on the node with excessive latency receives the scheduling decision and generates a locally executable sequence of operation instructions, wherein the scheduling decision includes the instruction type, the target CPU core identifier, and the expected isolation state;

[0021] According to the sequence of operation instructions, the CPU core of the node with excessive latency is removed from the general scheduling domain and added to the dedicated isolation core;

[0022] Identify deployment units with hard real-time tags running on the CPU cores of the node with excessive latency, and exclusively bind their processes to the dedicated isolated core; identify and obtain all non-real-time task processes currently running on the CPU cores of the node with excessive latency, migrate the non-real-time tasks to a preset system maintenance core, and adjust the affinity of all device interrupt requests processed by the CPU cores of the node with excessive latency.

[0023] Furthermore, the construction of a resource allocator based on topology information, wherein the resource allocator allocates CPU and memory resources to hard real-time tasks in the dedicated isolated core according to the topology information of the nodes with excessive latency, and limits the cache usage of non-real-time tasks on the dedicated isolated core according to a resource limiting algorithm, includes:

[0024] A resource allocator based on topology information is constructed to allocate CPU computing resources and memory resources located in the same node to hard real-time tasks on the dedicated isolated core according to the node topology information, so as to minimize memory access latency. The resource allocator is used to read the node topology information and real-time resource status of the node with excessive latency.

[0025] The resource allocator dynamically configures and applies cache space constraints based on a preset resource limitation algorithm, limiting the access and capacity of non-real-time tasks to the final-level cache occupied by the dedicated isolated core.

[0026] Further, the preprocessing and data aggregation of the original delayed data to determine the corresponding node time-series data includes:

[0027] The raw delay data is cleaned to remove outliers caused by instantaneous system overload or measurement noise. The cleaned delay data is then standardized and formatted to unify the data units and timestamp sequences, and the corresponding preprocessed data is determined.

[0028] The preprocessed data is aggregated using a sliding window method within a fixed time window to generate the node time series data. The node time series data includes the average delay, maximum delay, and standard deviation of delay within each time window.

[0029] Further, after limiting the cache usage of non-real-time tasks on the dedicated isolated core according to the resource limiting algorithm, the following is included:

[0030] Continuously monitor the real-time performance metrics of the nodes;

[0031] When the real-time performance metrics of a node recover to within the threshold, isolated resources are gradually released to achieve adaptive resource optimization.

[0032] Secondly, this application provides a hard real-time load dynamic isolation device based on a cloud-native scheduler, comprising:

[0033] The node timing data determination module is used to deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node timing data, and send the node timing data to the cloud-native scheduler.

[0034] The scheduling decision determination module is used by the cloud-native scheduler to receive node timing data sent by each node, and to obtain the real-time resource list, CPU set status and node topology information of each node, construct node real-time context data, calculate node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than a threshold, then the node corresponding to the real-time performance indicators higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0035] The node load isolation module is used to receive the scheduling decision on the node agent process deployed on the node with excessive latency, remove the CPU core of the node with excessive latency from the general scheduling domain, construct a dedicated isolation core, exclusively bind the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrate the existing non-real-time tasks on the CPU core to other CPU cores, adjust interrupt affinity to avoid their interference with the isolation core, and construct a resource allocator based on topology information. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the node with excessive latency, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0036] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the hard real-time load dynamic isolation method based on a cloud-native scheduler.

[0037] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the described hard real-time load dynamic isolation method based on a cloud-native scheduler.

[0038] Fifthly, this application provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the described hard real-time load dynamic isolation method based on a cloud-native scheduler.

[0039] As can be seen from the above technical solution, this application provides a method and apparatus for dynamic isolation of hard real-time load based on a cloud-native scheduler. By deploying a latency monitoring process on each computing node in the cluster to monitor node latency data and aggregate node timing status, the cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. By using the timing data and the node real-time context data, nodes with excessive latency are identified, and scheduling decisions are generated for these nodes. The node agent process deployed on the nodes with excessive latency receives the scheduling decisions, performs CPU core isolation and hard real-time task migration on the nodes with excessive latency, and constructs a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby achieving dynamic isolation of the hard real-time task load. This can improve the stability of hard real-time tasks running in latency-sensitive environments. Attached Figure Description

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

[0041] Figure 1 This is one of the flowcharts illustrating the hard real-time load dynamic isolation method based on a cloud-native scheduler in this application embodiment;

[0042] Figure 2 This is a structural diagram of the hard real-time load dynamic isolation device based on a cloud-native scheduler in the embodiments of this application;

[0043] Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0044] Figure label:

[0045] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

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

[0047] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0048] Considering that current Kubernetes scheduler designs are primarily geared towards throughput-first or resource-balanced scenarios, they fall short when facing hard real-time loads. Hard real-time loads have extremely strict requirements on system response time, and non-real-time tasks can interfere with real-time tasks in various ways. This application provides a method and apparatus for dynamic isolation of hard real-time loads based on a cloud-native scheduler. By deploying a latency monitoring process on each compute node in the cluster to monitor node latency data and aggregate node timing status, the cloud-native scheduler receives node timing data sent by each node and obtains node context data for each node. Based on the timing data and the node's real-time context data, nodes with excessive latency are identified. A scheduling decision is generated for these nodes, and a node agent process deployed on the nodes with excessive latency receives the scheduling decision. The scheduler then isolates CPU cores and migrates hard real-time tasks to these nodes, and constructs a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks. This achieves dynamic isolation of hard real-time task loads, thereby improving the stability of hard real-time tasks running in latency-sensitive environments.

[0049] To improve the stability of hard real-time tasks running in latency-sensitive environments, this application provides an embodiment of a dynamic isolation method for hard real-time loads based on a cloud-native scheduler. See [link to embodiment]. Figure 1 The hard real-time load dynamic isolation method based on cloud-native scheduler specifically includes the following:

[0050] Step S101: Deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler.

[0051] Optionally, in this embodiment, this step first deploys a dedicated latency monitoring process (Daemon) on each computing node. This process runs as a kernel module or system service, directly utilizing high-precision timers provided by real-time kernel extensions such as Xenomai Cobalt or Linux PREEMPT_RT to periodically perform latency measurements with microsecond-level precision. The collected raw latency data includes scheduling latency (i.e., the time difference between task readiness and actual execution start), interrupt latency (the time elapsed from the issuance of an interrupt signal to the start of the corresponding interrupt service routine), and system jitter (the deviation in the execution time of periodic tasks).

[0052] The next stage is preprocessing. This stage begins with data cleaning, using threshold filtering and sliding window statistics to identify and remove outliers caused by instantaneous system overload, external interference, or measurement noise, ensuring data validity. Subsequently, the valid data undergoes standardization, including timestamp alignment, data unit unification, and format conversion, providing a consistent and standardized data foundation for subsequent aggregation.

[0053] The preprocessed data is then aggregated and calculated according to a preset time window. The system uses a sliding window mechanism to statistically summarize latency indicators within a continuous time interval, generating node time-series data. This time-series data mainly includes the average latency (reflecting the overall latency level), the maximum latency (capturing worst-case performance), and the standard deviation of latency (measuring jitter) within each time window, thus comprehensively characterizing the real-time performance status of the nodes.

[0054] Finally, the aggregated time-series data is reported in real time to the cloud-native scheduler in the cluster via efficient and lightweight gRPC remote calls or the Kubernetes Custom Resource (CRD) mechanism. This step provides the scheduler with continuous, reliable, and fine-grained real-time performance profiles of nodes, enabling it to make scheduling decisions based on actual runtime data rather than static configurations. This lays a solid data foundation for the subsequent implementation of dynamic isolation and resource guarantees for hard real-time tasks.

[0055] Step S102: The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node, constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than the threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0056] Optionally, in this embodiment, this step is executed by the real-time awareness plugin inside the cloud-native scheduler. Based on the real-time data collected from each node of the cluster, a comprehensive decision is made to ensure that hard real-time tasks are always scheduled to meet performance standards.

[0057] Optionally, in this embodiment, the cloud-native scheduler continuously receives node time-series data proactively reported by each node in the cluster through an efficient communication mechanism. The core content includes:

[0058] Scheduling latency: The time elapsed from when a task is ready until it actually begins execution on the CPU.

[0059] Interrupt latency: The time elapsed from when an interrupt signal arrives at the CPU to when its corresponding interrupt handler begins execution.

[0060] System jitter: The range of fluctuations in the aforementioned latency is a key indicator for measuring system determinism.

[0061] At the same time, the scheduler actively obtains and maintains the real-time resource list (such as the current allocated and idle amount of CPU / memory), CPU set status (such as which CPU cores have been isolated and which are in a shared state) and detailed node topology information (mainly NUMA node distribution, CPU and memory affinity relationship, LLC cache topology) of each node by querying the Kubernetes API Server and other methods.

[0062] The scheduler fuses, correlates, and formats the received dynamic timing data with static and quasi-static resource information obtained from the system to construct real-time context data for each node, creating a panoramic view of its current performance and resource status. This view is no longer an isolated data point but forms a data model for in-depth analysis. For example, a high interrupt latency can be correlated with a high soft interrupt load on a specific NUMA node or with improper interrupt affinity configuration on a CPU core.

[0063] Next, based on the constructed real-time context data of the nodes, the scheduler uses its built-in algorithm model to calculate the real-time performance metrics of the nodes:

[0064] First, the input data is based on time-series data, and is combined with resource lists (such as the remaining resources of isolated cores) and topology information (such as the potential overhead of cross-NUMA access) for auxiliary judgment.

[0065] Second, the algorithm assigns different weights to different metrics (for example, in extreme real-time scenarios, the weight of interruption latency may be higher than that of scheduling latency), and incorporates trend analysis within a time window (such as whether latency continues to deteriorate). Finally, it outputs one or more quantifiable real-time performance metric scores or grades for each node.

[0066] Third, the calculated real-time performance metrics are compared with preset thresholds. These thresholds are predefined based on the stringent requirements of hard real-time tasks (e.g., requiring latency of 99.9% of quantiles to be below 50 microseconds).

[0067] Based on the threshold comparison results, corresponding control actions are generated. If the real-time performance index is lower than (i.e., better than) the threshold, it indicates that the node is currently healthy and can meet the performance requirements of hard real-time tasks, and can continue to be selected as a scheduling target. If the real-time performance index is higher than (i.e., worse than) the threshold, the node is determined to be a latency-exceeding node, and the deterministic operation of hard real-time tasks can no longer be guaranteed. At this time, the scheduler will immediately generate a scheduling decision for this node:

[0068] Isolation Decision: This is a "defensive" or "remedial" decision. The decision aims to immediately alleviate latency issues on the target node. Instructions are sent to the Agent on the target node, requiring it to perform dynamic isolation operations, such as: further tightening CPU isolation (using tools like cset shield to move more non-real-time tasks away from real-time cores), adjusting IRQ interrupt affinity (binding interrupts to non-real-time cores), or limiting cache usage via resctrl. The goal is to quickly create a "clean" runtime environment for existing real-time tasks.

[0069] Migration Decision: This is a "avoidance" decision. The decision primarily involves triggering the eviction and rescheduling of hard real-time Pods currently running on the overloaded node. The scheduler will re-initiate the scheduling process for these Pods, using the same real-time evaluation mechanism to migrate them to healthy nodes where current real-time performance metrics meet the requirements.

[0070] This step represents a leap from "perception" to "decision-making." Through continuous monitoring and predictive evaluation, it can proactively avoid situations where node performance deteriorates to the point of impacting tasks, preventing hard real-time tasks from exceeding latency limits due to being scheduled to unsuitable nodes. Once node latency exceeds limits, it can automatically and instantly generate and execute a combined strategy that includes both on-site isolation and repair as well as task migration. Decisions are based on multi-dimensional contextual data (time-series data + resource status + topology), making the decision results more comprehensive and accurate.

[0071] Step S103: The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolation core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolation core. A resource allocator based on topology information is constructed. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0072] Optionally, in this embodiment, when a node's real-time performance metrics exceed a preset threshold due to system jitter, interruption accumulation, or resource contention, it is marked as a "latency exceeding the standard node." At this time, the node agent process deployed on that node will receive decision instructions from the upper-layer scheduler and initiate dynamic isolation operations. With real-time recovery as the core objective, strict protection for hard real-time tasks is achieved through resource reallocation and scheduling domain reconstruction.

[0073] Specifically, the node agent process first parses the received scheduling decision information.

[0074] The scheduling decision information includes the specific CPU core identifier to be isolated, the type of operation to be performed (such as core isolation, task migration, interrupt binding), and target status parameters.

[0075] The agent process, following instructions, invokes resource management interfaces provided by the underlying operating system (such as cpuset or cgroup file systems) to completely remove the specified CPU core from the general scheduling domain (i.e., the domain of the Linux kernel's Completely Fair Scheduler—CFS). This step removes the kernel scheduler's management control over the core at the system level, preventing it from participating in global task scheduling and load balancing, thus laying the foundation for building a dedicated runtime environment.

[0076] After the scheduling domain is stripped away, the CPU core is built as a "dedicated isolated core." Its core characteristic is that it is no longer subject to the scheduling policies of the conventional operating system, becoming a physical computing unit dedicated to executing highly deterministic tasks. Next, the node agent process scans all task entities currently running on this core. For deployment units identified as "hard real-time" (e.g., containers / pods with real-time priority or specific QoS levels), the agent process performs a CPU affinity binding operation, exclusively locking them onto this dedicated isolated core. This means that all subsequent threads and execution flows of these real-time tasks will be strictly constrained to execute within this core, ensuring that their runtime is not unexpectedly migrated or preempted, thus achieving extreme computational determinism.

[0077] Meanwhile, for non-real-time tasks (such as regular batch jobs and system background processes) also residing on the same core, the node agent process initiates a migration process. By calling the process migration API, these tasks are safely rescheduled to other non-isolated "Housekeeping Cores" dedicated to handling non-real-time loads. This operation aims to completely clear unnecessary loads from isolated cores, eliminating any sources of performance jitter that may arise from resource sharing (such as caching and memory bandwidth) or time-sharing execution by the scheduler, creating a "silent" and interference-free operating environment for hard real-time tasks.

[0078] To further solidify the isolation effect, the node agent process also performs interrupt affinity adjustments. By rewriting interface files such as ` / proc / irq / <interrupt number> / smp_affinity` in the Linux system, the processing flow of most device interrupt requests (especially those triggered by non-real-time tasks or general I / O operations) is redirected to the previously mentioned system maintenance kernel. This step is crucial because it prevents random interrupt events from disrupting the dedicated isolated kernel at the hardware interrupt level. Hard real-time tasks can thus execute continuously in a near-uninterruptible environment, with their worst-case interrupt latency (IRQ latency) significantly reduced and becoming predictable.

[0079] For hard real-time tasks, the direct benefit is a high degree of determinism in runtime, guaranteeing the worst-case execution time (WCET) and thus meeting microsecond-level or even more stringent latency requirements. For the entire system, this mechanism enables fine-grained resource management and graceful eviction of non-real-time loads, avoiding the long-term resource idleness issues that might result from static isolation. The system can adaptively adjust based on actual load and real-time status, ensuring the performance of critical business operations while also considering the overall resource utilization efficiency of the cluster, achieving a highly efficient balance between performance isolation and resource utilization.

[0080] Optionally, in this embodiment, after isolating the hard real-time task, computing resources are then allocated to it.

[0081] Specifically, the resource allocator continuously collects and parses the NUMA topology information of nodes with excessive latency, obtaining the physical relationships between CPU cores, memory nodes, and cache levels. Based on this topology information, when allocating computing resources for hard real-time tasks, it prioritizes CPUs and memory units located within the same NUMA node, ensuring that memory access during task execution is a local operation and minimizing the additional latency caused by cross-NUMA node access.

[0082] Subsequently, for the bound dedicated isolated kernels, the resource allocator implements cache capacity limits for non-real-time tasks through kernel-provided resource control mechanisms (such as the Linux resctrl interface). Specifically, it sets an upper limit on the available last-level cache (LLC) space for non-real-time task groups to prevent them from consuming excessive cache lines and causing cache pollution and a decrease in hit rate for real-time tasks. The resource limiting algorithm dynamically adjusts this upper limit based on the cache sensitivity of real-time tasks and the overall system load, ensuring low latency for real-time tasks while preventing a sharp performance drop in non-real-time tasks due to excessive restrictions.

[0083] During operation, the allocator continuously monitors cache usage and real-time task execution latency, providing dynamic feedback. If it detects that non-real-time tasks are still causing cache contention or that real-time task latency is increasing, it further tightens the cache quota and, if necessary, schedules the task to a logical processor far from the real-time core, achieving physical cache isolation.

[0084] By employing topology-aware resource allocation and dynamic caching constraints, cross-node communication overhead is reduced along the memory access path, while interference from non-real-time tasks to real-time tasks is prevented at the caching level. Ultimately, this allows hard real-time tasks to achieve near-physical isolation with low latency and high determinism in a shared environment, while maintaining the availability of non-real-time tasks and improving overall system resource utilization efficiency.

[0085] This example demonstrates how this embodiment achieves dynamic load isolation for hard real-time tasks by monitoring real-time node load status and generating isolation and migration decisions.

[0086] As described above, the hard real-time load dynamic isolation method based on a cloud-native scheduler provided in this application embodiment can monitor node latency data and aggregate node timing status by deploying a latency monitoring process on each computing node in the cluster. The cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. It determines the node with excessive latency by using the timing data and the node real-time context data, generates a scheduling decision for the node with excessive latency, and the node agent process deployed on the node with excessive latency receives the scheduling decision. It performs CPU core isolation and hard real-time task migration on the node with excessive latency, and builds a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby realizing dynamic load isolation of hard real-time tasks. This can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0087] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0088] Step S201: Assign configurable weight coefficients to the scheduling delay, interruption delay, and system jitter index in the node timing data respectively;

[0089] Step S202: After weighting the node data, the CPU set in the node real-time context data can be adjusted by the number of CPU cores and the node topological locality state. The comprehensive real-time performance score of the node is calculated by linear weighted summation to determine the corresponding node real-time performance index.

[0090] Optionally, in this embodiment, the primary task of this step is to assign a configurable weight coefficient to the three core indicators—scheduling latency, interruption latency, and system jitter—in the received node timing data. This is because not all indicators are equally important, and different application scenarios may have different sensitivities to various types of latency. Administrators can adjust this according to the specific needs of different application scenarios. For example:

[0091] In a control loop that is extremely sensitive to task response time (such as robot joint servo control), the weight of scheduling delay may be set to the highest.

[0092] In a system that needs to handle a large number of external hardware signal interrupts (such as a high-speed data acquisition card), the weight of interrupt latency may be set to the highest.

[0093] In a scenario where the stability requirements for periodic execution are extremely high and any fluctuations are averse (such as the perception fusion cycle of autonomous driving), the weight of system jitter may be set to the highest.

[0094] The simplified representation of weight allocation is as follows:

[0095] Weighted delay = W latency ×Standardization (scheduling delay) + W irq ×Standardization (interruption delay) + W jitter ×Standardization (System Jitter)

[0096] Optionally, in this embodiment, the delay data after weight allocation mainly reflects the current health status of the node. However, an ideal scheduling target node not only needs to be "healthy" but also "robust" and "efficient". Therefore, this step introduces the static and dynamic context information of the node, expanding the evaluation from simple "performance" to "performance + resource capabilities", forming a more comprehensive real-time health profile of the node.

[0097] CPU core availability: This refers to the number of CPU cores on the node that are not currently isolated and can be used to schedule new real-time tasks. This is a capacity factor. The more available cores, the stronger the node's ability to accept new tasks, and the score should be positively adjusted accordingly.

[0098] Node topology locality state: This is an efficiency factor. It evaluates the probability that a new task will achieve optimal NUMA locality if scheduled to this node. For example, does a NUMA node simultaneously have idle CPU cores and sufficient memory bandwidth? This can be determined by checking the NUMA affinity between the CPU and memory, as well as the remaining memory resources. Higher locality means shorter data access paths, lower potential latency, and a positively modulating score.

[0099] The weighted latency data is combined with these two adjustment factors using a linear weighted summation method. Each adjustment factor also has its own weight coefficient, reflecting the system's trade-offs between "performance," "capacity," and "efficiency."

[0100] The simplified formula for the overall real-time performance score is as follows:

[0101] Overall real-time performance = weighted latency metric + W cpu × Available core number adjustment function + numa× locality scoring function;

[0102] The final calculated overall real-time performance reflects not only the current real-time performance of a node (how good is it?) (how low is the latency), but also its ability to receive new tasks (whether it has spare resources) and suitability to receive new tasks (NUMA affinity). This overall real-time performance guides the scheduler to prioritize assigning tasks to "high-quality" nodes that have excellent real-time performance, sufficient resources, and a suitable topology, thus laying the foundation for optimal runtime performance before tasks even start. Furthermore, it prevents the scheduler from piling all tasks onto a node simply because it has temporarily the lowest latency, causing that node to quickly exhaust its resources and become a bottleneck, thereby achieving load balancing of cluster resources.

[0103] Through step S202, this embodiment successfully performs real-time dynamic performance evaluation of computing nodes, transforming the original multi-dimensional monitoring data into a quantifiable comprehensive score, providing an accurate basis for the scheduler's automated decision-making.

[0104] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0105] Step S301: Dynamically evaluate the real-time performance indicators of each node based on a preset latency threshold. If the real-time performance indicator of a node is higher than the preset threshold, the node is determined to be a node with excessive latency.

[0106] Step S302: Generate an isolation decision for the node whose latency exceeds the limit, which is used to add the node to the real-time scheduling isolation list and prevent any new tasks with hard real-time identifiers from being scheduled to the node;

[0107] Step S303: Generate a migration decision for the node with excessive latency, which is used to query all hard real-time tasks currently running on the node with excessive latency, and generate a migration event for each hard real-time task.

[0108] Optionally, in this embodiment, the system continuously receives real-time performance index data reported by each node in the cluster. The corresponding real-time performance index is calculated through the aforementioned step S202. If the comprehensive evaluation result of a node is determined to be "performance higher than a preset threshold" (i.e., performance not meeting the standard), then the node is marked as a "latency exceeding the standard node".

[0109] Once a node is determined to have excessive latency, the RealTimeIsolationPlugin in the scheduler will immediately generate an isolation decision, including:

[0110] Update the isolation list: Add the node's unique identifier (such as the node name) to an internal "real-time scheduling isolation list". This list is a dynamic data structure maintained in memory and may be persisted for sharing among multiple instances of the scheduler.

[0111] Implement scheduling interception: For any newly received Pod scheduling request with a hard real-time identifier (such as a node selector label with realtime: "true"), the scheduler will query this list during the pre-selection (Filter) phase. If the target node is in this list, it will be directly filtered out from the list of schedulable nodes, thereby preventing any new hard real-time tasks from being scheduled to the problematic node.

[0112] This ensures that new hard real-time tasks do not enter an unhealthy environment that is already experiencing high latency and high jitter, thus preventing new tasks from failing to meet real-time requirements due to node performance issues and preventing the situation from deteriorating further.

[0113] The isolation decision addresses future tasks, while this step handles existing tasks. For nodes marked as exceeding limits, the system also generates a migration decision. This decision drives the following operations:

[0114] Query real-time tasks: By querying the Kubernetes API Server, obtain a list of all Pods currently running on the "latency exceeding the limit node", and filter out the Pods with the hard real-time identifier;

[0115] A migration event is generated for each selected hard real-time Pod. This event is essentially a trigger signal. The specific process is as follows: directly call the Kubernetes API to evict these Pods, tag these Pods with the label that they need to be migrated, and have another controller listen for and execute a rescheduling operation to trigger a custom migration workflow, and perform some preprocessing (such as state saving) before migration.

[0116] Subsequently, Kubernetes' standard scheduling process takes over these evicted Pods, and they re-enter the scheduling queue. At this point, the scheduler with enhanced real-time awareness (RealTimeIsolationPlugin) will only bind them to nodes that are not on the isolation list and meet the real-time performance requirements.

[0117] This step enables remedial migration. It proactively and automatically migrates hard real-time tasks that are already in poor environments to healthy nodes, thereby quickly restoring the runtime performance of these tasks and ensuring that their latency requirements are continuously met.

[0118] Through step S303, this embodiment successfully generated a scheduling decision, laying the foundation for the subsequent isolation of hard real-time loads.

[0119] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0120] Step S401: The node agent process deployed on the node with excessive latency receives the scheduling decision and generates a locally executable sequence of operation instructions, wherein the scheduling decision includes instruction type, target CPU core identifier and expected isolation state;

[0121] Step S402: According to the operation instruction sequence, remove the CPU core of the node with excessive latency from the general scheduling domain and add it to the dedicated isolation core;

[0122] Step S403: Identify the deployment unit with a hard real-time tag running on the CPU core of the node with excessive latency, and exclusively bind its process to the dedicated isolated core; identify and obtain all non-real-time task processes currently running on the CPU core of the node with excessive latency, migrate the non-real-time tasks to the preset system maintenance core, and adjust the affinity of all device interrupt requests processed by the CPU core of the node with excessive latency.

[0123] Optionally, in this embodiment, the Node Agent process deployed on the node with excessive latency serves as the core execution unit, receiving remote scheduling decisions from the central scheduler.

[0124] The decision is a structured data packet containing three key data fields: instruction type (e.g., “Execute dynamic isolation” or “Deisolate”), target CPU core identifier (which explicitly specifies which physical or logical cores on the node need to be operated), and expected isolation state (which describes the resource allocation and scheduling state that these CPU cores should eventually reach).

[0125] The node agent process's task is to deserialize the data packet, parse out the specific operation parameters, and "translate" them into a series of low-level operation instructions that can be directly executed at the local operating system kernel level. This includes: invoking specific system commands (such as cset), modifying specific kernel interface files (such as / sys / devices / system / cpu / cpuX / online or / proc / irq / N / smp_affinity), and executing process migration commands (such as taskset or migrate_pages). Generating this sequence is essentially transforming a policy intent into a series of atomic system operations.

[0126] Optionally, in this embodiment, the proxy process excludes the target CPU cores specified in the instruction sequence from the general scheduling domain to which they originally belonged (usually the set of all CPUs managed by the Linux Completely Fair Scheduler CFS) through the cgroup cpuset interface of the kernel. When the CFS scheduler assigns tasks in the future, it will no longer consider these removed CPU cores, thus avoiding non-real-time tasks from being accidentally assigned to them at the scheduling level.

[0127] Subsequently, these stripped CPU cores are added to a pre-created dedicated isolation cgroup or cpuset designed specifically for real-time tasks. This dedicated cpuset is configured to only allow processes of specific users or groups to run on the CPUs in this set. At this point, these CPU cores have been "appropriated" logically, forming a pure dedicated computing resource unit isolated from the general computing resource pool.

[0128] After the static partitioning of CPU resources is completed, step S403 is responsible for handling the currently running dynamic entity processes and interrupts to purify the runtime environment.

[0129] The node proxy process will first identify the container processes in the Pods marked as hard real-time that are currently running on the target CPU cores based on labels or cgroup membership. Subsequently, use a process binding tool (such as taskset) to bind these processes exclusively to the new dedicated isolation cores. Ensure that these critical processes will only execute on this dedicated core hereafter and will not be migrated to other cores by the scheduler, thus ensuring the continuous stability of their execution environment and cache affinity.

[0130] Immediately afterwards, the proxy process will identify and obtain all non-real-time task processes that are still running on the target core. Forcefully migrate these processes to the pre-specified system maintenance cores used to run the operating system background tasks and non-real-time workloads.

[0131] Based on the above, device interrupts are another major source of latency disturbances. Therefore, the proxy process will enumerate all the device interrupt requests (IRQs) currently processed by the target CPU core, and by modifying the / proc / irq / <IRQ number> / smp_affinity file corresponding to each IRQ, rebind the handling of these interrupts to the corresponding system maintenance cores and dedicated isolation cores. Ensure that subsequent non-real-time device interrupts will not be triggered on the real-time cores, thus avoiding the preemption and interference of the interrupt handler on the execution of real-time tasks.

[0132] Through step S403, this embodiment successfully intervenes in and reshapes the node state, migrates non-real-time tasks away, rebinds interrupts, and simplifies the load on the dedicated isolated core to only hard real-time tasks, whose execution paths become extremely predictable, thus providing a solid foundation for meeting the strict microsecond-level deterministic latency requirements.

[0133] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0134] Step S501: Construct a resource allocator based on topology information, and allocate CPU computing resources and memory resources located in the same node to the hard real-time tasks on the dedicated isolated core according to the node topology information, so as to minimize memory access latency. The resource allocator is used to read the node topology information and real-time resource status of the node with excessive latency.

[0135] Step S502: The resource allocator dynamically configures and applies cache space constraints according to a preset resource limitation algorithm, limiting the access and capacity of non-real-time tasks to the last-level cache occupied by the dedicated isolated core.

[0136] Optionally, in this embodiment, this step constructs a resource allocator based on topology information, which performs fine-grained resource allocation for hard real-time tasks on dedicated isolated cores according to the internal hardware topology of the node.

[0137] Specifically, the resource allocator first reads the node topology information of nodes with excessive latency, including NUMA node partitioning, physical layout of CPUs and memory, cache hierarchy, and current resource usage status. After obtaining this information, the allocator prioritizes allocating CPU cores and memory resources located within the same NUMA node for hard real-time tasks based on topological proximity. For example, if a hard real-time task is scheduled to a dedicated isolated core, the resource allocator ensures that the memory requested by that task is also allocated locally from the same NUMA node, thereby avoiding remote memory access across nodes.

[0138] For example, suppose we have a server whose hardware architecture is a typical 2-Socket NUMA system (i.e., it has two NUMA nodes):

[0139] NUMA Node 0:

[0140] CPU Cores: CPU0, CPU1, CPU2, CPU3

[0141] Local memory: Memory A, Memory B

[0142] NUMA Node 1:

[0143] CPU Cores: CPU4, CPU5, CPU6, CPU7

[0144] Local memory: Memory C, Memory D

[0145] If CPU0 (on Node 0) needs to access Memory A (also on Node 0), this is a local access with the shortest path and lowest latency. If CPU0 (on Node 0) needs to access Memory C (on Node 1), it must go through the interconnect bus between CPUs (such as Intel's QPI or AMD's Infinity Fabric), which is a remote access with a longer path and higher latency (typically increasing latency by 50% or more).

[0146] Suppose we want to schedule a hard real-time Pod, and the resource configuration request for this Pod is as follows:

[0147] yaml

[0148] resources:

[0149] requests:

[0150] cpu: "2"

[0151] memory: "4Gi"

[0152] Behavior of a regular scheduler without NUMA topology awareness:

[0153] It only cares whether "this node has 2 free CPUs and 4Gi of free memory". It might make allocations like this:

[0154] CPU: CPU0 is allocated from Node 0, and CPU4 is allocated from Node 1.

[0155] Memory: Allocate 4 Gi from Node 1 (assuming there is just enough contiguous space).

[0156] As a result, when CPU0 is running, if it needs to access the 4Gi of memory, it must make a remote access to Node 1 every time, introducing unpredictable and higher latency. This is fatal for hard real-time tasks.

[0157] In this application, the behavior of the NUMA topology-aware scheduler is as follows:

[0158] Upon receiving the Pod scheduling request, it not only checks the total resources of the nodes but also examines the detailed resource information for each NUMA node, and discovers:

[0159] Node 0 has available CPU and memory, but it may not be enough (e.g., only 1 idle CPU and 2Gi memory).

[0160] Node 1 has available CPU and memory (e.g., 2 idle CPUs and 6 Gi of memory).

[0161] The decision-making logic is: prioritize ensuring that the CPU and memory come from the same NUMA node.

[0162] Therefore, it will choose to schedule the entire Pod to NUMA Node 1 and make the following allocation:

[0163] CPU: CPU4 and CPU5 (two CPUs on the same node) are allocated from Node 1.

[0164] Memory: Allocate 4 Gi from Memory C or Memory D on Node 1 (on the same node as the CPU).

[0165] As a result, when CPU4 and CPU5 are running, all their memory accesses are performed within their local NUMA Node 1, making them local accesses. This ensures the lowest and most stable memory access latency, meeting the deterministic requirements of hard real-time tasks.

[0166] In summary, in non-uniform memory access architectures, the latency of accessing memory across NUMA nodes is typically much higher than that of local access, sometimes by several times. This is unacceptable for hard real-time tasks with microsecond-level latency requirements. By forcing the CPU and memory to reside on the same node, the system effectively avoids the uncertain latency introduced by remote memory access, greatly improving the timing predictability of real-time task execution.

[0167] Furthermore, proactive management and isolation of cache resources are implemented. The resource allocator imposes constraints on the use of the last-level cache (LLC) based on a preset resource constraint algorithm (a dynamic allocation strategy for real-time task cache requirements and non-real-time task behavior models). In practice, the system uses kernel-provided resource control mechanisms (such as the Linux resctrl interface) to set a cache capacity limit for non-real-time task groups running on general-purpose kernels (e.g., by specifying an available cache bitmask or maximum available cache space), thereby strictly limiting the total amount of shared LLC they can occupy.

[0168] Crucially, the resource allocator continuously monitors cache usage metrics (such as cache miss rate and real-time task execution jitter) and dynamically adjusts the cache quota for non-real-time tasks based on system load changes and the actual needs of real-time tasks. For example, during periods when real-time tasks are highly sensitive to cache, the system can further tighten the available cache space for non-real-time tasks to ensure that critical data for real-time tasks remains stably in the cache; conversely, when the load on real-time tasks is light, the restrictions can be appropriately relaxed to improve overall resource utilization and effectively suppress cache interference.

[0169] In multi-core systems with shared caches, frequent data access by non-real-time tasks can evict cache lines needed by real-time tasks, leading to increased cache miss rates and unpredictable execution latency. By dynamically applying cache space constraints, the system isolates non-real-time loads from real-time tasks at the hardware resource level, ensuring low latency and determinism in cache access during real-time task execution. This not only stabilizes task execution time but also improves the overall real-time performance and reliability of the system.

[0170] Through step S502, this embodiment achieves multi-level resource isolation from memory to cache, providing end-to-end low-latency assurance for hard real-time tasks, while taking into account the reasonable resource requirements of non-real-time tasks and the overall resource utilization efficiency of the system.

[0171] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0172] Step S601: Clean the raw delay data, remove outliers caused by instantaneous system overload or measurement noise, and standardize and format the cleaned delay data to unify the data units and timestamp sequences, and determine the corresponding preprocessed data.

[0173] Step S602: Perform sliding window aggregation calculation on the preprocessed data according to a fixed time window to generate the node time series data. The node time series data includes the average delay, maximum delay, and standard deviation of delay within each time window.

[0174] Optionally, in this embodiment, the original delayed data is first cleaned to improve data quality and reliability.

[0175] Specifically, by setting reasonable thresholds or employing statistical methods (such as outlier detection based on interquartile range), outliers caused by instantaneous system overload, measurement jitter, or external interference are identified and removed. Subsequently, the cleaned data undergoes standardization formatting, unifying the unit of all delay values ​​to microseconds (µs) and aligning the timestamps of all data points to a unified clock source and sequence format. This step eliminates noise and inconsistencies in the original data, creating a clean, standardized, and time-consistent preprocessed data set, laying the foundation for subsequent accurate aggregation and analysis.

[0176] Optionally, in this embodiment, the preprocessed data after cleaning and standardization is then aggregated and calculated.

[0177] A fixed-length sliding window is used to perform statistical calculations on data points within the window sequentially, generating time-series metrics that characterize the real-time performance of nodes. Specifically, three core statistics are calculated within each time window: the average latency, reflecting the overall latency level during that period; the maximum latency, capturing the worst-case latency performance; and the standard deviation of latency, quantifying the degree of latency fluctuation and jitter. Through this aggregation method, the raw, low-level time-series data is transformed into high-level, intuitively interpretable, and statistically significant node performance metrics. The effect is that it extracts massive amounts of raw data into time-series characteristics that accurately and stably reflect the real-time performance status of nodes, providing direct and reliable quantitative evidence for the scheduler's real-time perception and dynamic decision-making.

[0178] Through step S602, this embodiment realizes the transformation from raw signals to decision support information, ensuring that subsequent scheduling strategies are based on high-quality, statistically significant time-series data.

[0179] In one embodiment of the hard real-time load dynamic isolation method based on cloud-native scheduler in this application, it may further include the following:

[0180] Step S701: Continuously monitor the real-time performance indicators of the nodes;

[0181] Step S702: When the real-time performance indicators of the node recover to within the threshold, gradually release the isolated resources to achieve adaptive resource optimization.

[0182] Optionally, in this embodiment, the system continuously collects key real-time performance indicators. When the system detects that the real-time performance indicators of a certain node are consistently stable within a preset safety threshold range, it indicates that the real-time load pressure on that node has eased and resource contention is at a low level. At this time, the system will initiate a resource reclamation process: the node agent gradually releases or shrinks the previously implemented isolation area according to a predetermined strategy. For example, some CPU cores that were originally isolated for real-time tasks are reintegrated into the general scheduling pool, allowing non-real-time tasks to be scheduled there; the cache allocation strategy (such as relaxing LLC restrictions) and interrupt affinity settings are adjusted accordingly. This process needs to adopt a gradual strategy to avoid performance fluctuations caused by sudden resource release.

[0183] Through this detection and adaptive optimization adjustment, elastic management and efficient utilization of cluster resources can be achieved. On the one hand, it can strictly guarantee the determinism of critical tasks when the real-time load increases; on the other hand, when the real-time load decreases, it automatically releases redundant isolated resources back to the shared pool for use by non-real-time tasks, thereby avoiding long-term idle resources.

[0184] Through step S702, this embodiment successfully achieves a dynamic balance between resource isolation strength and overall utilization, improving the system's economy and adaptability in mixed load scenarios.

[0185] To improve the stability of hard real-time tasks running in latency-sensitive environments, this application provides an embodiment of a cloud-native scheduler-based hard real-time load dynamic isolation device for implementing all or part of the aforementioned cloud-native scheduler-based hard real-time load dynamic isolation method. See [link to embodiment]. Figure 2 The hard real-time load dynamic isolation device based on the cloud-native scheduler specifically includes the following components:

[0186] The node timing data determination module 10 is used to deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node timing data, and send the node timing data to the cloud-native scheduler.

[0187] The scheduling decision determination module 20 is used by the cloud-native scheduler to receive node timing data sent by each node, and to obtain the real-time resource list, CPU set status and node topology information of each node, construct node real-time context data, calculate node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than a threshold, then the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0188] The node load isolation module 30 is used to receive the scheduling decision on the node agent process deployed on the node with excessive latency, remove the CPU core of the node with excessive latency from the general scheduling domain, construct a dedicated isolation core, exclusively bind the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrate the existing non-real-time tasks on the CPU core to other CPU cores, adjust interrupt affinity to avoid their interference with the isolation core, construct a resource allocator based on topology information, the resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the node with excessive latency, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, so as to achieve dynamic load isolation of hard real-time tasks.

[0189] As described above, the hard real-time load dynamic isolation device based on a cloud-native scheduler provided in this application embodiment can monitor node latency data and aggregate node timing status by deploying a latency monitoring process on each computing node in the cluster. The cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. It determines the node with excessive latency by using the timing data and the node real-time context data, generates a scheduling decision for the node with excessive latency, and the node agent process deployed on the node with excessive latency receives the scheduling decision. It performs CPU core isolation and hard real-time task migration on the node with excessive latency, and builds a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby realizing dynamic load isolation of hard real-time tasks. This can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0190] Optionally, the specific technical process of this solution is as follows:

[0191] 1. Delayed probes and real-time detection

[0192] Run a latency monitoring daemon on each node, using a high-precision timer from the Xenomai 4 / Cobalt or LinuxPREEMPT_RT kernel to periodically measure scheduling latency, IRQ latency, and system jitter.

[0193] Delayed data is reported to the scheduler plugin in real time via gRPC / CRD.

[0194] 2. Cloud-native scheduling plugin

[0195] Add the RealTimeIsolationPlugin plugin to the Kubernetes Scheduler to support adding latency metric weights to scheduling decisions.

[0196] For nodes with latency exceeding the threshold, hard real-time Pods are prohibited from being scheduled to them, and load migration is triggered.

[0197] 3. Dynamic isolation at runtime

[0198] When node latency approaches the threshold, the CPU isolation policy (such as csetshield, cpuset, IRQ affinity) is dynamically adjusted through the Node Agent to remove hard real-time cores from the CFS scheduling domain and migrate non-real-time tasks to the housekeeping core.

[0199] Supports hot migration of containers or rescheduling of real-time task Pods to maintain a low-latency environment.

[0200] 4. NUMA and Cache Layer Optimization

[0201] By combining NUMA topology awareness to prioritize the allocation of CPU and memory on the same node, cross-node access latency is reduced.

[0202] By using the resctrl technique, the LLC cache space occupied by non-real-time loads is limited to the real-time core, reducing cache interference.

[0203] 5. Closed-loop adaptive mechanism

[0204] Latency metrics are continuously fed back to the scheduling plugin to form a closed-loop optimization, supporting automatic recovery isolation strategies. When the load decreases, resources are released to improve resource utilization.

[0205] Optional, implementation steps of this solution (example):

[0206] Deploy a latency monitoring daemon (Xenomai Latency Test + custom collection script) on each node.

[0207] Deploy a Kubernetes scheduler image that includes the RealTimeIsolationPlugin.

[0208] Add scheduling tags and QoS configurations to the real-time task Pod, for example:

[0209] nodeSelector:

[0210] realtime: "true"

[0211] qosClass: guaranteed

[0212] The Node Agent adjusts CPU isolation and IRQ affinity in real time during runtime.

[0213] The scheduler performs task migration or updates isolation policies based on latency data.

[0214] Optionally, the scalability and industrial applications of this solution...

[0215] 1. It can be used in conjunction with real-time kernels such as Xenomai 4, PREEMPT_RT, and RTLinux.

[0216] 2. Adaptable to cloud-edge collaboration scenarios, it can be deployed on edge nodes, vehicle computing platforms, industrial control gateways and other devices.

[0217] 3. Works with resources such as SR-IOV / DPDK / GPU passthrough to achieve multi-dimensional real-time performance assurance.

[0218] From a hardware perspective, in order to improve the stability of hard real-time tasks running in latency-sensitive environments, this application provides an embodiment of an electronic device for implementing all or part of the aforementioned hard real-time load dynamic isolation method based on a cloud-native scheduler. The electronic device specifically includes the following components:

[0219] The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to implement information transmission between the cloud-native scheduler-based hard real-time load dynamic isolation method and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the cloud-native scheduler-based hard real-time load dynamic isolation method described in the previous embodiment, and the contents of these embodiments are incorporated herein, with repeated details not repeated.

[0220] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0221] In practical applications, the hard real-time load dynamic isolation method based on cloud-native schedulers can be partially executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0222] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0223] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0224] In one embodiment, the hardware real-time load dynamic isolation method based on a cloud-native scheduler can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0225] Step S101: Deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler.

[0226] Step S102: The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node, constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than the threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0227] Step S103: The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolation core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolation core. A resource allocator based on topology information is constructed. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0228] As described above, the electronic device provided in this application embodiment monitors node latency data and aggregates node timing status by deploying a latency monitoring process on each computing node in the cluster. The cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. It determines the node with excessive latency by using the point timing data and the node real-time context data, generates a scheduling decision for the node with excessive latency, and the node agent process deployed on the node with excessive latency receives the scheduling decision. It performs CPU core isolation and hard real-time task migration on the node with excessive latency, and builds a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby realizing dynamic load isolation of hard real-time tasks. This can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0229] In another implementation, the cloud-native scheduler-based hard real-time load dynamic isolation method can be configured separately from the central processing unit 9100. For example, the cloud-native scheduler-based hard real-time load dynamic isolation method can be configured as a chip connected to the central processing unit 9100, and the function of the cloud-native scheduler-based hard real-time load dynamic isolation method can be implemented through the control of the central processing unit.

[0230] like Figure 3As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technology.

[0231] like Figure 3 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0232] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0233] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0234] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0235] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0236] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0237] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor 9130 is also coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored sound via the speaker 9131.

[0238] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the cloud-native scheduler-based hard real-time load dynamic isolation method with the execution subject being a server or client in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the cloud-native scheduler-based hard real-time load dynamic isolation method with the execution subject being a server or client in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0239] Step S101: Deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler.

[0240] Step S102: The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node, constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than the threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0241] Step S103: The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolation core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolation core. A resource allocator based on topology information is constructed. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0242] As described above, the computer-readable storage medium provided in this application embodiment monitors node latency data and aggregates node timing status by deploying a latency monitoring process on each computing node in the cluster. The cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. It determines the node with excessive latency by using the point timing data and the node real-time context data, generates a scheduling decision for the node with excessive latency, and the node agent process deployed on the node with excessive latency receives the scheduling decision. It performs CPU core isolation and hard real-time task migration on the node with excessive latency, and builds a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby realizing dynamic load isolation of hard real-time tasks. This can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0243] Embodiments of this application also provide a computer program product capable of implementing all steps of the cloud-native scheduler-based hard real-time load dynamic isolation method, where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the cloud-native scheduler-based hard real-time load dynamic isolation method. For example, the computer program / instruction implements the following steps:

[0244] Step S101: Deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler.

[0245] Step S102: The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node, constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than the threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision;

[0246] Step S103: The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolation core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolation core. A resource allocator based on topology information is constructed. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

[0247] As described above, the computer program product provided in this application provides that, by deploying a latency monitoring process on each computing node in the cluster to monitor node latency data and aggregate node timing status, the cloud-native scheduler receives node timing data sent by each node and obtains node context data of each node. By using the point timing data and the node real-time context data, it determines the nodes with excessive latency, generates scheduling decisions for the nodes with excessive latency, and the node agent process deployed on the nodes with excessive latency receives the scheduling decisions. It performs CPU core isolation and hard real-time task migration on the nodes with excessive latency, and builds a resource allocator based on topology information to allocate CPU and memory resources to the migrated hard real-time tasks, thereby achieving dynamic load isolation of hard real-time tasks. This can improve the stability of hard real-time tasks running in latency-sensitive environments.

[0248] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0249] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0250] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0251] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0252] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for dynamic real-time load isolation based on a cloud-native scheduler, characterized in that, The method includes: Deploy a latency monitoring process on each compute node in the cluster to periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data, and system jitter data. Preprocess and aggregate the raw latency data to determine the corresponding node time series data, and send the node time series data to the cloud-native scheduler. The cloud-native scheduler receives node timing data sent by each node, and obtains the real-time resource list, CPU set status and node topology information of each node. It constructs node real-time context data, calculates node real-time performance indicators based on the node timing data and the node real-time context data. If the real-time performance indicators are higher than a threshold, the node corresponding to the real-time performance indicators that are higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node. The scheduling decision includes isolation decision and migration decision. The node agent process deployed on the latency-exceeding node receives the scheduling decision, removes the CPU core of the latency-exceeding node from the general scheduling domain, constructs a dedicated isolated core, exclusively binds the existing hard real-time deployment units on the CPU core to the dedicated isolated core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, adjusts interrupt affinity to avoid interference with the isolated core, and constructs a resource allocator based on topology information. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolated core according to the node topology information of the latency-exceeding node, and limits the cache occupation of non-real-time tasks on the dedicated isolated core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

2. The method for dynamic hard real-time load isolation based on a cloud-native scheduler according to claim 1, characterized in that, The step of calculating the node's real-time performance metrics based on the node's time-series data and the node's real-time context data includes: Configurable weighting coefficients are assigned to the scheduling delay, interruption delay, and system jitter indicators in the node time series data, respectively. The number of CPUs and the node topological locality state can be used as adjustment factors to introduce the node data into the node real-time context data after weight allocation. The comprehensive real-time performance score of the node is calculated by linear weighted summation to determine the corresponding node real-time performance index.

3. The hard real-time load dynamic isolation method based on cloud-native scheduler according to claim 1, characterized in that, If the real-time performance metric exceeds a threshold, the node corresponding to the real-time performance metric exceeding the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, including: The real-time performance indicators of each node are dynamically evaluated based on a preset latency threshold. If the real-time performance indicator of a node is higher than the preset threshold, the node is determined to be a node with excessive latency. An isolation decision is generated for the node whose latency exceeds the limit, which is used to add the node to the real-time scheduling isolation list and prevent any new tasks with hard real-time identifiers from being scheduled to the node; A migration decision is generated for the node whose latency exceeds the limit. This decision is used to query all hard real-time tasks currently running on the node whose latency exceeds the limit, and to generate a migration event for each hard real-time task.

4. The method for dynamic hard real-time load isolation based on a cloud-native scheduler according to claim 1, characterized in that, The node agent process deployed on the node with excessive latency receives the scheduling decision, removes the CPU core of the node with excessive latency from the general scheduling domain, constructs a dedicated isolated core, exclusively binds the existing hard real-time deployment unit on the CPU core to the dedicated isolated core, migrates the existing non-real-time tasks on the CPU core to other CPU cores, and adjusts interrupt affinity to avoid interference with the isolated core, including: The node agent process deployed on the node with excessive latency receives the scheduling decision and generates a locally executable sequence of operation instructions, wherein the scheduling decision includes the instruction type, the target CPU core identifier, and the expected isolation state; According to the sequence of operation instructions, the CPU core of the node with excessive latency is removed from the general scheduling domain and added to the dedicated isolation core; Identify deployment units with hard real-time tags running on the CPU cores of the node with excessive latency, and exclusively bind their processes to the dedicated isolated core; identify and obtain all non-real-time task processes currently running on the CPU cores of the node with excessive latency, migrate the non-real-time tasks to a preset system maintenance core, and adjust the affinity of all device interrupt requests processed by the CPU cores of the node with excessive latency.

5. The method for dynamic hard real-time load isolation based on a cloud-native scheduler according to claim 1, characterized in that, The construction of a topology-based resource allocator, which allocates CPU and memory resources to hard real-time tasks in the dedicated isolated core according to the topology information of the nodes with excessive latency, and limits the cache usage of non-real-time tasks on the dedicated isolated core according to a resource limiting algorithm, includes: A resource allocator based on topology information is constructed to allocate CPU computing resources and memory resources located in the same node to hard real-time tasks on the dedicated isolated core according to the node topology information, so as to minimize memory access latency. The resource allocator is used to read the node topology information and real-time resource status of the node with excessive latency. The resource allocator dynamically configures and applies cache space constraints based on a preset resource limitation algorithm, limiting the access and capacity of non-real-time tasks to the final-level cache occupied by the dedicated isolated core.

6. The method for dynamic hard real-time load isolation based on a cloud-native scheduler according to claim 1, characterized in that, The preprocessing and data aggregation of the original delayed data to determine the corresponding node time-series data includes: The raw delay data is cleaned to remove outliers caused by instantaneous system overload or measurement noise. The cleaned delay data is then standardized and formatted to unify the data units and timestamp sequences, and the corresponding preprocessed data is determined. The preprocessed data is aggregated using a sliding window method within a fixed time window to generate the node time series data. The node time series data includes the average delay, maximum delay, and standard deviation of delay within each time window.

7. The method for dynamic hard real-time load isolation based on a cloud-native scheduler according to claim 1, characterized in that, After limiting the cache usage of non-real-time tasks on the dedicated isolated core according to the resource limiting algorithm, the following is included: Continuously monitor the real-time performance metrics of the nodes; When the real-time performance metrics of a node recover to within the threshold, isolated resources are gradually released to achieve adaptive resource optimization.

8. A hard real-time load dynamic isolation device based on a cloud-native scheduler, characterized in that, The device includes: The node timing data determination module is used to deploy a latency monitoring process on each computing node in the cluster, periodically measure the raw latency data of each node, including scheduling latency data, interrupt latency data and system jitter data, preprocess and aggregate the raw latency data, determine the corresponding node timing data, and send the node timing data to the cloud-native scheduler. The scheduling decision determination module is used by the cloud-native scheduler to receive node timing data sent by each node, and to obtain the real-time resource list, CPU set status and node topology information of each node, construct node real-time context data, calculate node real-time performance indicators based on the node timing data and the node real-time context data, and if the real-time performance indicators are higher than a threshold, then the node corresponding to the real-time performance indicators higher than the threshold is determined as a latency-exceeding node, and a scheduling decision is generated for the latency-exceeding node, the scheduling decision including isolation decision and migration decision; The node load isolation module is used to receive the scheduling decision on the node agent process deployed on the node with excessive latency, remove the CPU core of the node with excessive latency from the general scheduling domain, construct a dedicated isolation core, exclusively bind the existing hard real-time deployment unit on the CPU core to the dedicated isolation core, migrate the existing non-real-time tasks on the CPU core to other CPU cores, adjust interrupt affinity to avoid their interference with the isolation core, and construct a resource allocator based on topology information. The resource allocator allocates CPU and memory resources to the hard real-time tasks in the dedicated isolation core according to the node topology information of the node with excessive latency, and limits the cache occupation of non-real-time tasks on the dedicated isolation core according to the resource limiting algorithm, thereby realizing dynamic load isolation of hard real-time tasks.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the hard real-time load dynamic isolation method based on cloud-native scheduler as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the hard real-time load dynamic isolation method based on a cloud-native scheduler as described in any one of claims 1 to 7.

Images