Task scheduling method and device based on idle time resources of content delivery network

Abstract

The invention relates to a task scheduling method and device based on idle time resources of a content distribution network. The method comprises the steps of receiving a task creation request submitted by a user, wherein the task creation request comprises a container mirror image, Pod template parameters, resource specifications and the number of copies; based on edge Kubernetes cluster node resource data periodically acquired by a monitoring system, idle time nodes with loads lower than a threshold value are identified, and a resource pool is constructed; screening target nodes according to task resource requirements and resource pool states; generating a Kubernetes Job and configuring a node affinity rule of a Pod template, so that a task is scheduled to a target node to run; and when the monitoring system detects that the load of the target node exceeds an alarm threshold value, receiving a node overload alarm event and executing task scheduling operation. By adopting the method, idle resources of the CDN can be intelligently and safely utilized, and the idle resources are converted into effective computing power on the premise of ensuring CDN service quality.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network resource scheduling, and in particular to a task scheduling method and device based on idle time resources of a content distribution network, a computer device, a computer readable storage medium, and a computer program product. BACKGROUND

[0002] A content distribution network (CDN) is a technology that improves content access speed and availability by deploying edge servers in multiple geographic locations and storing content closer to users. With the popularization of cloud-native concepts, the method of building and running applications has begun to fully leverage the advantages of cloud computing to achieve rapid deployment, elastic expansion, and high reliability.

[0003] However, due to the significant volatility of Internet traffic, the resource occupancy varies greatly at different times. For example, during the night or during a specific business low-peak period, user access demand decreases significantly, resulting in low load or idle state of computing, storage, and bandwidth resources on a large number of edge nodes of the CDN. The CDN system has a large number of edge nodes, and how to fully improve the utilization rate of these resources has become a key challenge to reduce the overall operating cost of the CDN.

[0004] In traditional technologies, although cloud-native technology stacks (such as Kubernetes) provide powerful task scheduling and management capabilities, there is a lack of fine-grained scheduling solutions specifically for the special scenario of CDN idle time resources. Directly applying conventional task scheduling strategies to CDN nodes cannot accurately identify the true idle time window, and cannot ensure that idle time tasks will not cause performance interference and quality impact on core CDN services during traffic bursts. Therefore, there is an urgent need for a method that can intelligently and safely utilize CDN idle time resources, and convert idle resources into effective computing power under the premise of ensuring CDN service quality. SUMMARY

[0005] Therefore, it is necessary to provide a task scheduling method based on idle time resources of a content distribution network, which can intelligently and safely utilize CDN idle time resources, and convert idle resources into effective computing power under the premise of ensuring CDN service quality.

[0006] In a first aspect, the present application provides a task scheduling method based on idle time resources of a content distribution network, applied to a container platform, the method comprising:

[0007] receiving a task creation request submitted by a user, the task creation request including task execution logic based on a container image definition, task running parameters specified in a Pod template form, resource specification information required by the task, and a number of task replicas;

[0008] based on real-time resource utilization data of each node in a plurality of edge Kubernetes clusters periodically acquired by a monitoring system, identifying idle nodes with a current load level lower than a preset threshold, and constructing an idle resource pool;

[0009] According to the resource specification information and the number of replicas in the task creation request, and in combination with the total amount of resources and real-time usage of the nodes in the idle resource pool, target nodes that meet the scheduling conditions are screened out;

[0010] Generating a Kubernetes Job resource object corresponding to the task creation request, and configuring node affinity rules in the Pod template associated with the KubernetesJob resource object, so that the Pods created by the Pod template are scheduled to run on the target nodes selected out;

[0011] receiving a node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds a preset alarm threshold;

[0012] In response to the node overload alarm event, performing a task scheduling operation.

[0013] In one embodiment, the real-time resource utilization data of each node in a plurality of edge Kubernetes clusters periodically acquired by the monitoring system includes:

[0014] acquiring from the monitoring system host resource usage data and container resource usage data collected by the cAdvisor component deployed on each edge node;

[0015] The Prometheus server in the monitoring system periodically pulls the resource usage data exposed by the cAdvisor component from each edge node.

[0016] In one embodiment, the idle resource pool is constructed, including:

[0017] Maintaining resource information tags for each node in the idle resource pool, the resource information tags including at least one of the node's IP address, operator information, and geographic location information;

[0018] Caching the total amount of resources of each node and real-time resource usage data provided by the monitoring system.

[0019] In one of the embodiments, the group of target nodes meeting the scheduling condition comprises:

[0020] Analyzing the task creation request to determine the task type;

[0021] In the case where the task type is determined as a data collaboration type task, preferentially selecting a node with sufficient idle bandwidth resources as a candidate node;

[0022] In the case where the task type is determined as a compute-intensive task, preferentially selecting a node with sufficient idle CPU and memory resources as a candidate node;

[0023] Based on the resource specification information and the number of replicas, determining a final target node set from the candidate nodes.

[0024] In one of the embodiments, the node affinity rule in the Pod template associated with the Kubernetes Job resource object comprises:

[0025] Based on the resource information label of the selected target node, setting the nodeAffinity field in the Pod template specification; the configuration of the nodeAffinity field is used to instruct the Kubernetes scheduler to schedule Pod instances only to target nodes with matching resource information labels.

[0026] In one of the embodiments, the task scheduling operation performed in response to the node overload alarm event comprises:

[0027] In response to the node overload alarm event, determining the Kubernetes Job resource object corresponding to the idle task running on the overloaded node;

[0028] Deleting the determined Kubernetes Job resource object to evict the associated Pod;

[0029] Re-selecting a replacement node meeting the original task resource specification requirements from the current idle resource pool;

[0030] Recreating and issuing the Kubernetes Job resource object on the replacement node.

[0031] In one of the embodiments, after re-selecting a replacement node meeting the original task resource specification requirements from the current idle resource pool, further comprising:

[0032] In the case where there is a currently available node meeting the requirements, immediately re-issuing the task on the available node;

[0033] In the case that no available node meeting the requirements exists at present, the step of selecting a replacement node meeting the requirements of the original task resource specification from the current idle time resource pool is performed again after waiting for a preset time interval.

[0034] In a second aspect, the present application further provides a task scheduling device based on content distribution network idle time resources, comprising:

[0035] The receiving module is configured to receive a task creation request submitted by a user, the task creation request comprising task execution logic defined based on a container image, task running parameters specified in the form of a Pod template, resource specification information required by the task, and a number of task replicas.

[0036] The constructing module is configured to identify idle time nodes with a current load level lower than a preset threshold based on real-time resource utilization data of nodes in a plurality of edge Kubernetes clusters periodically acquired by a monitoring system, and construct an idle time resource pool.

[0037] The screening module is configured to screen target nodes meeting scheduling conditions according to the resource specification information and the number of replicas in the task creation request, and in combination with resource total amount and real-time usage of nodes in the idle time resource pool.

[0038] The configuring module is configured to generate a Kubernetes Job resource object corresponding to the task creation request, and configure node affinity rules in a Pod template associated with the Kubernetes Job resource object, so that a Pod created by the Pod template is scheduled to run on the screened target nodes.

[0039] The receiving module is further configured to receive a node overload alarm event sent by the monitoring system when detecting that real-time load of any target node exceeds a preset alarm threshold.

[0040] The executing module is configured to perform a task scheduling operation in response to the node overload alarm event.

[0041] In a third aspect, the present application further provides a computer device comprising a memory and a processor, the memory storing a computer program, and the processor realizing the following steps when executing the computer program:

[0042] The receiving module is configured to receive a task creation request submitted by a user, the task creation request comprising task execution logic defined based on a container image, task running parameters specified in the form of a Pod template, resource specification information required by the task, and a number of task replicas.

[0043] Based on the real-time resource utilization data of each node in the multiple edge Kubernetes clusters periodically acquired by the monitoring system, idle nodes with a current load level lower than a preset threshold are identified, and an idle resource pool is constructed;

[0044] According to the resource specification information and the number of replicas in the task creation request, and in combination with the total amount of resources and the real-time usage of the nodes in the idle resource pool, target nodes meeting the scheduling conditions are screened out;

[0045] A Kubernetes Job resource object corresponding to the task creation request is generated, and node affinity rules in a Pod template associated with the KubernetesJob resource object are configured, so that the Pods created by the Pod template are scheduled to run on the screened-out target nodes;

[0046] A node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds a preset alarm threshold is received;

[0047] In response to the node overload alarm event, a task scheduling operation is performed.

[0048] In a fourth aspect, the present application also provides a computer readable storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the following steps:

[0049] A task creation request submitted by a user is received, the task creation request including task execution logic defined based on a container image, task running parameters specified in the form of a Pod template, resource specification information required by the task, and the number of task replicas;

[0050] Based on the real-time resource utilization data of each node in the multiple edge Kubernetes clusters periodically acquired by the monitoring system, idle nodes with a current load level lower than a preset threshold are identified, and an idle resource pool is constructed;

[0051] According to the resource specification information and the number of replicas in the task creation request, and in combination with the total amount of resources and the real-time usage of the nodes in the idle resource pool, target nodes meeting the scheduling conditions are screened out;

[0052] A Kubernetes Job resource object corresponding to the task creation request is generated, and node affinity rules in a Pod template associated with the KubernetesJob resource object are configured, so that the Pods created by the Pod template are scheduled to run on the screened-out target nodes;

[0053] A node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds a preset alarm threshold is received;

[0054] perform a task scheduling operation in response to the node overload alarm event.

[0055] In a fifth aspect, the present application also provides a computer program product comprising a computer program which, when executed by a processor, implements the following steps:

[0056] receiving a task creation request submitted by a user, the task creation request comprising task execution logic defined based on a container image, task running parameters specified in a Pod template form, resource specification information required by the task, and a number of task replicas;

[0057] identifying idle nodes with a current load level lower than a preset threshold based on real-time resource utilization data of nodes in a plurality of edge Kubernetes clusters periodically obtained by a monitoring system, and constructing an idle resource pool;

[0058] screening target nodes meeting scheduling conditions according to the resource specification information and the number of replicas in the task creation request, and in combination with a total amount of resources and real-time usage of nodes in the idle resource pool;

[0059] generating a Kubernetes Job resource object corresponding to the task creation request, and configuring node affinity rules in a Pod template associated with the Kubernetes Job resource object, so that Pods created by the Pod template are scheduled to run on the screened target nodes;

[0060] receiving a node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds a preset alarm threshold;

[0061] performing a task scheduling operation in response to the node overload alarm event.

[0062] The task scheduling method, device, computer equipment, computer readable storage medium and computer program product based on idle resources of a content distribution network, receive a task request defined by a container image and a Pod template through a container platform, dynamically identify idle nodes with a load lower than a threshold value and construct a resource pool based on real-time monitoring data of an edge Kubernetes cluster node by a monitoring system, accurately filter suitable target nodes from the resource pool according to resource specifications and a number of replicas required by the task, and schedule the task to the target nodes for running by configuring a node affinity rule of a Kubernetes Job and a Pod template, so that idle computing, storage and bandwidth resources of CDN nodes are fully utilized, resource utilization is significantly improved, and operating costs are reduced. Meanwhile, when the monitoring system detects that the load of any target node exceeds an alarm threshold value, the container platform can immediately receive an alarm and perform a task scheduling operation, and ensure that core CDN services are not affected by expelling or migrating idle tasks, thereby improving resource utilization efficiency while ensuring the quality and stability of business services. BRIEF DESCRIPTION OF DRAWINGS

[0063] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the description of the embodiments of the present application or the related art will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0064] Figure 1 A flowchart of a task scheduling method based on idle resources of a content distribution network in an embodiment;

[0065] Figure 2 A flowchart of a task scheduling method based on idle resources of a content distribution network in another embodiment;

[0066] Figure 3 A core architecture diagram of a task scheduling method based on idle resources of a content distribution network in the most detailed embodiment;

[0067] Figure 4 A task scheduling flowchart in the most detailed embodiment;

[0068] Figure 5 A security protection flowchart in the most detailed embodiment;

[0069] Figure 6 A structural block diagram of a task scheduling device based on idle resources of a content distribution network in an embodiment;

[0070] Figure 7 An internal structure diagram of a computer equipment in an embodiment. DETAILED DESCRIPTION

[0071] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application.

[0072] It should be noted that the terms "first", "second" and the like used herein can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "include" and "have" and any variations thereof used herein are intended to cover non-exclusive inclusion. The term "multiple" used herein refers to two or more. The term "and / or" used herein refers to one of the options or any combination of multiple options.

[0073] In an exemplary embodiment, as shown in Figure 1 A task scheduling method based on content distribution network idle resources is provided. The method is applied to a container platform and includes the following steps S102 to S112. Wherein:

[0074] Step S102, receiving a task creation request submitted by a user, the task creation request including task execution logic defined based on a container image, task running parameters specified in the form of a Pod template, resource specification information required by the task, and the number of task replicas.

[0075] Specifically, the user first packs and builds the task program to be executed and its running environment into a container image. The image, as an independent and portable software unit, encapsulates all dependencies required for task execution, such as language runtime of a specific version, system library files, and user-compiled business programs. By defining based on the container image, the consistency of the task running environment on different edge computing nodes is ensured, and task execution failure caused by environment differences is avoided.

[0076] The user further configures the specific running way of the task in the Kubernetes cluster in the form of a Pod template. The Pod is the smallest deployable and manageable unit in Kubernetes, and the Pod template defines the running specification of the Pod. This includes but is not limited to: container startup command and its input parameters, environment variable settings, data volume mounting point configuration, etc. For example, for a data backup task, the user can specify the authentication information (delivered through environment variables) for connecting a remote storage server and the specific command line instructions for performing backup operations in the Pod template.

[0077] To ensure that the idle-time task does not compete with the normal CDN services running on the node for resources, the user must explicitly declare in the request the system resource specifications that the task needs to pre-empt. This usually includes the number of CPU cores and the size of memory required by the task container (such as a 2-core CPU and 4GB of memory), and, in particular for data collaboration type tasks, the upper limit of the network bandwidth that it is expected to occupy (such as a maximum of 100Mbps of occupied bandwidth). This explicit resource declaration is the basis for subsequent accurate resource matching and isolation.

[0078] The user also needs to specify the number of copies of the task, that is, how many nodes the task needs to be executed in parallel. For example, the user may wish to start 3 concurrent copies of the data preprocessing task to speed up the processing flow. The setting of the number of copies enables the system to filter out multiple qualified nodes from the resource pool at one time according to the scale of the user's demand, and to schedule them uniformly.

[0079] In step S104, based on the real-time resource utilization data of each node in the multiple edge Kubernetes clusters periodically obtained by the monitoring system, idle-time nodes with a current load level lower than a preset threshold are identified, and an idle-time resource pool is constructed.

[0080] Specifically, the monitoring system (typically, such as Prometheus) is configured to actively pull real-time resource utilization data from all nodes of each edge Kubernetes cluster periodically (for example, at intervals of 30 seconds). These data cover key performance indicators, including but not limited to CPU usage, memory occupancy, network bandwidth usage, and disk I / O load. The data source is an agent component (such as cAdvisor integrated in the edgecore process of KubeEdge architecture) deployed on each edge node, which is responsible for collecting fine-grained resource consumption of the node itself and all containers on the node. Through this centralized monitoring data collection, the system obtains a global, near real-time resource view.

[0081] The container platform analyzes and processes the gathered resource data. It sets corresponding load thresholds for various resource indicators (for example, CPU usage below 10% for 5 minutes is considered low load). The system compares the real-time data of each node with the preset threshold and comprehensively judges its overall load state. When multiple core resource indicators (such as CPU, memory, and bandwidth) of a node are continuously and stably below their respective thresholds, the node is identified as an available idle-time node. This comprehensive judgment based on multi-dimensional indicators and continuous time effectively avoids false positives caused by transient traffic fluctuations, and accurately captures the real resource idle window.

[0082] All identified idle nodes will be aggregated, logically forming a unified idle resource pool. The container platform will maintain a metadata archive for each node in the pool, which contains not only the real-time resource usage provided by the monitoring system and dynamically updated, but also the static attribute tags of the node (such as IP address, operator, geographic location, etc.) and the total resource capacity of the node. The resource pool itself is highly dynamic: when the node load rises above the threshold, the system will automatically remove it from the pool; when the load falls below the threshold, it will be re-included. In this way, the idle resource pool always maintains an accurate mapping of the current CDN network resource availability, becoming a reliable and elastic task carrying substrate.

[0083] Step S106, according to the resource specification information and the number of copies in the task creation request, and combining the total resource amount and real-time usage of the nodes in the idle resource pool, the target nodes that meet the scheduling conditions are selected.

[0084] Specifically, the container platform first parses the received task creation request and extracts the key scheduling constraint conditions. This includes the resource specification information required by the task (for example, 4-core CPU, 8GB memory, and 100Mbps guaranteed bandwidth) and the number of task copies (for example, it needs to run on 5 nodes at the same time). In addition, the system will intelligently identify or directly determine the task type based on the task image attributes or user-specified tags, such as classifying it as a compute-intensive task (such as video transcoding) or a data collaborative task (such as cross-node data synchronization).

[0085] After the task requirements are clear, the system will query the idle resource pool that has been built. The screening process is a multi-condition matching operation: the system will subtract the real-time usage of each node in the idle resource pool (the latest data provided by the monitoring system) from the total resource amount of the node (the upper limit of the physical resources of the node), to calculate the current available resources of the node. Then, the available resources of each node are compared with the resource specification information of the task request. For example, a request requires 2-core CPU and 4GB memory, so only the nodes with current available CPU ≥ 2-core and available memory ≥ 4GB will be included in the candidate range. This matching process ensures that the selected nodes have enough remaining resources to carry new tasks without affecting the existing basic services on the nodes.

[0086] On the basis of the preliminary matching, the system will further optimize node selection according to the task type. For the identified compute-intensive tasks, the system will preferentially select the node with the most abundant available CPU and memory resources among all the nodes that meet the basic resource conditions, to ensure efficient execution of the computing task. Correspondingly, for data collaborative tasks, the node with the highest available network bandwidth resource and the lowest network delay is preferentially selected. Finally, the system determines the final number of target nodes (for example, selects the optimal 5 nodes from 10 candidate nodes) from the batch of optimized candidate nodes according to the number of task replicas specified by the user, to complete the accurate mapping from resource requirements to specific node targets.

[0087] Step S108, a Kubernetes Job resource object corresponding to the task creation request is generated, and node affinity rules in the Pod template associated with the Kubernetes Job resource object are configured, so that the Pod created by the Pod template is scheduled to run on the target node screened out.

[0088] Specifically, the container platform generates a specific Kubernetes Job resource object based on the parsed task creation request. The Job object is a Kubernetes native abstraction for one-time tasks or batch processing tasks. When creating the Job, the system completely embeds the Pod template provided by the user in its specification (Spec). This means that all the content defined by the user in the request through the Pod template, including the container image used, the startup command, the environment variable, the data volume mounting, and the crucial resource requirement (such as the CPU and memory amount defined in resources.requests), are preserved as they are, ensuring that the task execution environment is completely consistent with the user's expectations.

[0089] To achieve the goal of scheduling the Pod to the target node pre-selected by the system, the container platform dynamically modifies or configures the node affinity (nodeAffinity) rule in the Pod template associated with the Job object. Specifically, the system adds the corresponding node selector requirement (nodeSelectorTerms) in the.spec.affinity.nodeAffinity field of the Pod template based on the attributes of the target node selected (for example, unique labels such as node-id: edge-node-xyz or zone: north-china applied to the node during node registration or resource pool maintenance). For example, a rule can be configured to require that the Pod can only be scheduled to a node with the label node-id: edge-node-xyz. In this way, the scheduling decision of the system (i.e., which specific nodes should run) is fixed in a declarative and Kubernetes-understandable manner.

[0090] When the Job resource configured with the specific node affinity rule is submitted to the target edge Kubernetes cluster, the Kubernetes scheduler (kube-scheduler) in the cluster listens to the new Pod scheduling requirement created. The scheduler will be forced to follow the preset node affinity rule in the Pod template when selecting nodes for it. Since the rule is precisely defined on the target node pre-selected by the system, the scheduler will eventually bind the Pod to the corresponding target node, and then the kubelet service on the node will actually create and start the task container.

[0091] Step S110, receiving the node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds the preset alarm threshold.

[0092] Specifically, the monitoring system (such as the combination of Prometheus and Alertmanager) is pre-configured with alarm rule thresholds for various resource metrics. These thresholds are carefully set to issue a warning before the CDN node load reaches a critical point that may affect the quality of its core business services, such as CPU usage exceeding 75% for 30 seconds or network bandwidth occupancy exceeding 80%. The monitoring system actively grabs real-time performance data of all target nodes (i.e., nodes currently running idle tasks) at a fixed period (such as 15 seconds). Once it detects that any monitoring metric of any target node has continuously broken through its preset alarm threshold, the monitoring system will immediately generate a structured node overload alarm event. The event payload usually contains key context information, such as the node identifier (node name or IP) that triggered the alarm, the specific over-standard metric, the current monitoring value, and the timestamp.

[0093] The delivery of the alarm event is not based on passive polling of the scheduling platform, but is actively initiated through the monitoring system configured webhook callback URL. When the alarm is triggered, the monitoring system will immediately initiate an HTTP POST request to the API endpoint pre-registered on the container platform, pushing the formatted alarm event data package to the container platform. This callback-based push mode, compared to the pull mode, can notify the abnormal state of node overload to the scheduling decision center with the lowest delay, which saves valuable time for subsequent rapid intervention.

[0094] A dedicated event listener is provided in the container platform, which is responsible for continuously listening to webhook requests from the monitoring system. When receiving the alarm event, the platform will immediately parse the event payload, verify its validity, and extract the core information, most importantly, determine which node is overloaded. This parsed alarm event immediately becomes an explicit trigger signal, activating the pre-set fault handling or resource recycling process in the container platform, thereby starting the subsequent task eviction and rescheduling operations to ensure the stability and quality of service of the core CDN service on the node.

[0095] Step S112, in response to the node overload alarm event, a task scheduling operation is performed.

[0096] Specifically, after parsing the received node overload alarm event, the container platform first extracts the target node identifier (such as node name) from the event payload that has exceeded the resource limit. Subsequently, the platform immediately queries the edge Kubernetes cluster it manages to accurately retrieve all Pod instances currently running on the overloaded node. By comparing the Kubernetes controller (Controller) to which the Pod belongs, the system can further filter and determine which Pods are controlled by the Kubernetes Job resource object created by the platform to execute idle-time tasks. This step ensures the accuracy of the intervention and avoids misoperation of non-idle-time task workloads.

[0097] After identifying the idle-time task Job that needs to be intervened, the container platform will immediately perform a Delete operation on the Job resource. According to the control loop mechanism of Kubernetes, deleting a Job object will trigger the automatic deletion of all Pod instances created by it. This process is called Eviction. When the Pod is deleted, the computing (CPU, memory) and network resources it occupies on the overloaded node will be immediately released. This is equivalent to actively removing a potential factor that causes node load to rise, freeing up necessary resources for the core CDN service processes running on the node, thereby quickly relieving the overload pressure on the node and ensuring the quality and stability of user access to content.

[0098] To ensure the final completion of the idle-time task itself, the scheduling operation does not simply terminate the task. At the same time or after expelling the original Job, the container platform starts a Rescheduling process. The platform queries the current idle-time resource pool state again to find a suitable replacement node that meets the original resource specification requirements of the task and is in a healthy load. Once a suitable node is found, the platform re-creates a Kubernetes Job resource object on the new node that is exactly the same as the original Job configuration. This new Job will go through the standard scheduling process and, as its node affinity rules are directed to the new replacement node, it will start a new Pod on the idle node and continue to execute the task. If there is no suitable node temporarily, the system will enter a waiting retry loop. This mechanism realizes the seamless migration of tasks from overloaded nodes to healthy nodes, ensuring the core business is not affected, and ultimately ensuring the computing results of idle-time tasks.

[0099] In the above task scheduling method based on content distribution network idle-time resources, the container platform receives the task request defined by the user in the form of a container image and a Pod template, dynamically identifies idle-time nodes with a load below a threshold value and builds a resource pool based on real-time monitoring data of edge Kubernetes cluster nodes by a monitoring system, and accurately filters suitable target nodes from the resource pool according to the resource specification and replica number required by the task. By configuring the node affinity rules of the Kubernetes Job and its Pod template, the task is scheduled to run on the target node, thereby fully utilizing the idle-time computing, storage, and bandwidth resources of CDN nodes, significantly improving resource utilization and reducing operating costs. At the same time, when the monitoring system detects that the load of any target node exceeds the alarm threshold, the container platform can immediately receive the alarm and perform a task scheduling operation to ensure that the core CDN service is not affected by expelling or migrating idle-time tasks, thereby improving resource utilization efficiency while ensuring the quality and stability of business services.

[0100] In one embodiment, the real-time resource utilization data of each node in the plurality of edge Kubernetes clusters periodically obtained by the monitoring system includes:

[0101] The host resource usage data and container resource usage data collected by the cAdvisor component deployed on each edge node are obtained from the monitoring system.

[0102] Among them, the Prometheus server in the monitoring system periodically pulls the resource usage data exposed by the cAdvisor component from each edge node.

[0103] Specifically, a container monitoring agent cAdvisor is deployed on each node of each edge Kubernetes cluster. This component serves as the terminal of data collection and is integrated directly in the edgecore process of the KubeEdge architecture without additional deployment. cAdvisor can automatically discover all container instances running on the node and continuously collect two types of key data with extremely fine granularity: one is host-level resource usage data, including the overall CPU usage, memory occupation, disk I / O throughput, and network bandwidth utilization of the node; the other is container-level resource usage data, which is accurate to the real-time consumption of CPU, memory, network, and storage resources of each independent container instance. These collected index data are exposed to the outside in a standard format through the built-in HTTP interface of cAdvisor, providing a unified endpoint for upper-layer data collection.

[0104] The Prometheus server in the monitoring system serves as a central data aggregation point, which periodically (e.g., every 30 seconds) accesses the HTTP index interface exposed by cAdvisor on each edge node through its unique pull (Pull) mode to actively obtain the latest resource usage data. This centralized pull mode can effectively cope with the architecture characteristics of a large number of edge nodes and dispersed geographical locations, avoiding the complexity of deploying a push agent on a large number of nodes. The Prometheus server stores the compressed time series data in the local time series database and performs preliminary aggregation processing to provide high-performance support for query analysis.

[0105] The container platform obtains the real-time resource utilization data processed by aggregation by calling the dedicated data query interface (such as HTTP API) provided by Prometheus on demand. The platform can execute complex query statements, such as obtaining the average CPU usage of all nodes of a specific cluster in the past 5 minutes, thereby providing accurate and complete decision-making basis for subsequent idle node identification and resource pool construction. This level completes the transformation from raw monitoring data to business usable information, enabling the container platform to make precise scheduling decisions based on data-driven methods.

[0106] In this embodiment, through the three-layer architecture of terminal collection, centralized pulling, and interface query, the comprehensiveness, real-time performance, and reliability of resource data are ensured, providing data perception capabilities for the entire task scheduling system.

[0107] In one of the embodiments, the idle resource pool is constructed, including:

[0108] Resource information tags are maintained for each node in the idle resource pool, including at least one of the IP address, operator information, and geographical location information of the node;

[0109] Cache the total resource information of each node and the real-time resource usage data provided by the monitoring system.

[0110] Specifically, the container platform maintains a set of structured resource information tags for each node in the idle resource pool. These tags are essentially key-value pairs that describe the inherent properties of the node. Specifically, they include: 1) network location identification, such as the IP address of the node, for precise network addressing and communication; 2) operator attributes, identifying the network operator to which the node belongs (e.g., "China Mobile", "China Telecom"), for example, to ensure low latency by scheduling tasks to the same operator network as the user; 3) geographic metadata, recording the specific geographic location information of the node deployment (e.g., "region: north-china, zone: beijing-a"), which enables the system to implement geographic-based scheduling strategies to meet data compliance or local computing needs. These static tags constitute the identity profile of the node, enabling the scheduling system to make intelligent decisions based on a rich set of dimensions rather than just resource availability.

[0111] The container platform synchronously maintains a dynamic resource state snapshot for each node. This includes two key data: 1) the total resource information of the node, i.e., the upper limit of the node's physical resources (such as total CPU cores, total memory capacity, total disk space, and network bandwidth limit), which is recorded when the node is registered; 2) real-time resource usage data obtained by querying the monitoring system interface, including current CPU usage, memory occupancy ratio, available disk space, and network bandwidth instantaneous usage rate, etc. The platform actively refreshes these real-time data at configurable time intervals (e.g., every 30 seconds) and caches them in local memory or high-performance storage.

[0112] In this embodiment, through the combination of static tags and dynamic data, each idle node in the resource pool is fully characterized as a comprehensive resource entity containing inherent attributes, resource capacity, and real-time load status. The caching mechanism avoids the delay caused by frequent queries to the monitoring system at each scheduling decision, enabling resource screening operations to be completed within milliseconds, greatly improving scheduling efficiency.

[0113] In one embodiment, a set of target nodes that meet the scheduling conditions are selected, including:

[0114] Parsing the task creation request to determine the task type;

[0115] In the case where the task type is determined to be a data collaboration task, preferentially selecting nodes with sufficient idle bandwidth resources as candidate nodes;

[0116] In the case where the task type is determined to be a compute-intensive task, the node with sufficient idle CPU and memory resources is preferentially selected as a candidate node;

[0117] Based on the resource specification information and the number of replicas, the final target node set is determined from the candidate nodes.

[0118] Specifically, the container platform deeply parses the received task creation request to determine the nature type of the task. This determination can be based on multiple information sources: one is explicit declaration, that is, the user directly indicates the task type through a specific label or field when submitting the request; the other is implicit inference, the system intelligently identifies by analyzing the resource proportion requested by the task (such as high bandwidth demand but moderate CPU / memory demand) or the container image attributes used (such as the image name or repository tag contains "data-sync", "transcode" and other keywords). Finally, the task is classified into a predefined type, such as a data collaboration type task (such as cross-node data synchronization, backup, distribution) or a compute-intensive task (such as video transcoding, big data analysis, machine learning inference).

[0119] On the basis of preliminary resource matching, the system performs differentiated optimization filtering strategies according to the task type:

[0120] For data collaboration type tasks, the performance bottleneck is usually in the network transmission capability. The system will preferentially select the node with the most sufficient bandwidth resources in idle time as a candidate among all nodes that meet the basic resource specifications. Specifically, the system will compare the real-time available bandwidth of each node (i.e. the total bandwidth minus the current usage), and tend to select the node with the highest percentage of available bandwidth or the largest absolute value to ensure that a large amount of data can flow quickly.

[0121] For compute-intensive tasks, the execution efficiency mainly depends on the computing speed of the processor and the available memory capacity. The system will therefore preferentially select the node with the highest comprehensive score of idle CPU and memory resources. This can be calculated by a weighted formula (for example, score = available CPU core number x weight 1 + available memory GB number x weight 2), and the node candidate set with the highest score is selected to ensure that the computing task obtains sufficient processing resources and shortens the task completion time.

[0122] After obtaining the candidate node list optimized by type, the system determines the final target node set from the candidate list according to the number of replicas specified in the task creation request. For example, if the user requests 3 replicas, the system selects the top 3 nodes from the optimized candidate node list.

[0123] In this embodiment, an idle resource pool is constructed by dynamically monitoring the resource load of edge nodes, and a differentiated scheduling strategy is implemented based on the type of task: high-bandwidth nodes are preferentially allocated to data collaboration tasks, and high-computing nodes are preferentially allocated to computing tasks. Precise scheduling is achieved through Kubernetes node affinity rules, and a task migration mechanism is automatically triggered when the node is overloaded, thereby fully improving the utilization rate of idle resources of the CDN while ensuring the quality and stability of core CDN services, effectively solving the balance problem between resource utilization and service guarantee.

[0124] In one of the embodiments, the node affinity rules in the Pod template associated with the Kubernetes Job resource object are configured, including:

[0125] Based on the resource information tags of the selected target nodes, the nodeAffinity field in the Pod template specification is set. The configuration of the nodeAffinity field is used to instruct the Kubernetes scheduler to schedule Pod instances only to target nodes with matching resource information tags.

[0126] Specifically, the container platform first converts the set of target nodes intelligently selected in the early stage into a set of node selection criteria that can be recognized by the Kubernetes scheduler. The platform reads the pre-set resource information tags on these target nodes (such as node-id: edge-node-01 to identify a specific node, or zone: north-china to identify a node group), which have been recorded and managed when the nodes are registered to the resource pool.

[0127] When creating a Kubernetes Job resource object, the platform dynamically injects node affinity (nodeAffinity) configuration into the Pod template specification (PodTemplate Spec) associated with it. Specifically, under the.spec.affinity.nodeAffinity path, node selector requirements (nodeSelectorTerms) are configured. This configuration explicitly specifies the node label matching conditions that must be met when the Pod is scheduled. For example, a rule can be configured to require that the Pod can only be scheduled to nodes with the label node-id with the value edge-node-01, edge-node-02, or edge-node-03. These three node IDs correspond to the target nodes selected by the system earlier.

[0128] When this Job configured with the specific node affinity rule is submitted to the Kubernetes cluster, the scheduler (kube-scheduler) in the cluster will no longer perform the general scoring preference logic when selecting a node for its Pod, but strictly follow this mandatory affinity rule. The scheduler will traverse all the nodes in the cluster, and only include the target nodes whose node labels completely match the requirements of the rule into the schedulable range. If there are multiple target nodes, the scheduler may make a secondary selection based on this; if only a unique target node is specified in the rule, the scheduler will directly bind the Pod to that node.

[0129] In this embodiment, by configuring the Kubernetes Job with a node label-based affinity rule, the target nodes selected by the scheduling system are directly converted into mandatory scheduling constraints for the Pod, ensuring that the idle tasks are precisely deployed to the pre-set edge nodes, thereby guaranteeing the final landing effect of the resource scheduling strategy and system reliability in a complex distributed environment.

[0130] In one of the embodiments, in response to a node overload alarm event, a task scheduling operation is performed, including: Figure 2

[0131] Step S202, in response to the node overload alarm event, determining the Kubernetes Job resource object corresponding to the idle task running on the overloaded node;

[0132] Step S204, deleting the determined Kubernetes Job resource object to evict its associated Pod;

[0133] Step S206, reselecting a replacement node that meets the original task resource specification requirements from the current idle resource pool;

[0134] Step S208, recreating and issuing the Kubernetes Job resource object on the replacement node.

[0135] Specifically, after verifying the validity of the node overload alarm event, the container platform first accurately extracts the target node identifier (such as node name or IP address) that triggered the alarm from the event payload. Subsequently, the platform queries the API server of the corresponding edge Kubernetes cluster to obtain the list of all Pod instances running on the overloaded node. By comparing the ownerReferences field of the Pod, the system can accurately trace and determine which Pod instances are controlled by the specific Kubernetes Job resource object created by the platform for managing idle tasks. This tracing mechanism ensures the accuracy of the intervention operation and avoids affecting other system or core business Pods on the node.​

[0136] After identifying the Job object to be intervened, the platform immediately issues an instruction to the cluster to delete this Job resource. According to the garbage collection mechanism of Kubernetes, deleting the Job object will trigger a cascading deletion of all Pod instances created by it. This eviction process forcibly terminates the idle task container running on the overloaded node and immediately releases the key resources such as CPU, memory, and bandwidth occupied by it. This eliminates the resource competition between the idle task and the core CDN service, providing immediate resource guarantee for the node to resume normal operation.

[0137] To ensure the final completion of the idle task itself, the system starts the rescheduling process. The platform re-queries the current dynamically updated idle resource pool and selects one or more healthy replacement nodes according to the resource specification requirements (such as CPU, memory, and replica number) defined in the original task request. Subsequently, the system recreates a Kubernetes Job resource object on the selected replacement node that is identical to the original Job configuration. This new Job object will go through the standard scheduling and startup process and eventually continue to execute the task on a resource-abundant node, thereby ensuring the computational continuity of the idle task and its final completion while ensuring that the core service is not affected.

[0138] In this embodiment, by establishing a node overload real-time response mechanism, the task migration process is automatically triggered when the node resource is monitored to be over-limit: the idle task on the overloaded node is accurately located and evicted to quickly release resources, while the task is seamlessly migrated to a healthy node that meets the resource requirements for continuous execution. This mechanism not only effectively guarantees the resource supply and running stability of the core CDN service, but also maintains the execution continuity of the idle task through the task rescheduling mechanism, achieving a dynamic balance between service quality guarantee and resource utilization efficiency.

[0139] In one embodiment, after selecting a replacement node that meets the resource specification requirements of the original task from the current idle resource pool, it further includes:

[0140] In the case where there is a node that meets the requirements, the task is immediately reissued on the available node;

[0141] In the case where there is no node that meets the requirements, after waiting for a preset time interval, the step of selecting a replacement node that meets the resource specification requirements of the original task from the current idle resource pool is executed again.

[0142] Specifically, when the system completes the selection process of replacing the node, it first makes a real-time judgment on the current resource pool state. If there is a node in the resource pool that meets the resource specification requirements of the original task, the system will immediately perform a scheduling operation and reissue a Kubernetes Job resource object on the node that is completely the same as the original task configuration. This instant scheduling mechanism without delay can minimize the task interruption time, ensure the continuity of task execution, and improve the overall scheduling efficiency.

[0143] When the system detects that there is no available node that meets the requirements in the current resource pool (possibly due to global resource shortage or temporary load peak), the system will enter a controlled waiting state. After a preset time interval (such as 5 minutes), the system will automatically perform the complete replacement node selection process again. This cyclic detection mechanism takes into account the dynamic load characteristics of the CDN edge environment. The current unavailable resources may become available again due to a decrease in load in a short period of time. Through this periodic retry, the system can automatically resume task execution when the resource conditions are met without human intervention.

[0144] In this embodiment, the entire retry process constitutes a complete closed-loop control system. The system does not give up the task due to a single resource unavailability, but actively seeks opportunities for task execution through continuous detection-waiting-retry cycles. This not only avoids the system overhead caused by continuous queries when resources are absolutely scarce, but also ensures that tasks can be scheduled and executed in time once a suitable idle resource window appears, ultimately achieving the ultimate goal of improving idle resource utilization.

[0145] The most detailed embodiment of the present application is:

[0146] A task scheduling system and method based on CDN idle resources are provided, and the core architecture is as shown in Figure 3 The system mainly includes three components: a container platform, an edge Kubernetes cluster (managed by KubeEdge), and a monitoring system (based on Prometheus). The container platform serves as the control center of the system, responsible for managing multiple edge clusters, receiving user tasks, making scheduling decisions, and managing the task life cycle. The edge Kubernetes cluster carries the actual CDN business services and idle tasks, and its nodes are connected through the KubeEdge framework, with offline autonomy. The monitoring system is responsible for continuously collecting and storing resource data of edge nodes and actively alerting when the nodes are overloaded.

[0147] The embodiment describes in detail the task scheduling method based on the above-mentioned system, and the complete process includes two core closed loops of task scheduling and security protection.

[0148] 1. Task scheduling process, as shown in Figure 4As shown, the specific implementation steps of task scheduling are as follows:

[0149] Each node in the edge Kubernetes cluster runs an edgecore process that locally integrates a cAdvisor monitoring component. cAdvisor automatically collects host-level resource usage data (such as total CPU usage, total memory occupancy) and container-level resource usage data (such as CPU, memory consumption of each container instance) of the node it is located in, and exposes the data through an HTTP interface. Subsequently, the Prometheus server in the monitoring system actively pulls these resource usage data from the cAdvisor interface of all edge nodes periodically (e.g., every 30 seconds) and stores them, thereby providing a global, near real-time resource view for the container platform.

[0150] The container platform maintains a resource information file for each managed edge node, recording its static attributes by tagging the node, including IP address, operator information, and geographic location information, etc. At the same time, the container platform caches the total resource and real-time usage data of each node provided by the monitoring system. Based on these data, the container platform dynamically builds and updates the "idle resource pool": it continuously compares the real-time resource utilization (such as CPU, memory, bandwidth usage) of the node with the preset load threshold, identifies the node whose load is continuously below the threshold as an "idle node" and includes it in the resource pool; when the load of a node in the pool rises above the threshold, it is removed from the pool.

[0151] Users submit task creation requests by calling the interfaces provided by the container platform. In this request, users need to encapsulate single-execution programs such as data collaboration, backup, or calculation into Docker images, and specify the running parameters (such as environment variables, startup commands) of the task based on the form of Kubernetes Pod template. In addition, the request must explicitly specify the resource specification information that needs to be preoccupied for this task, such as the required CPU core number, memory size, bandwidth upper limit, and task replica number (i.e., how many nodes are needed to execute the task in parallel).

[0152] After receiving the user request, the container platform initiates a scheduling plan. First, it parses the request to determine the task type (e.g., is it a data collaboration task or a compute-intensive task). Then, the platform filters a set of target nodes that meet the conditions based on the resource specifications and replica number in the request, combined with the real-time resource conditions of the nodes in the idle resource pool. In this process, the platform implements optimization strategies: for data collaboration tasks, it prioritizes nodes with sufficient idle bandwidth resources; for compute-intensive tasks, it prioritizes nodes with sufficient idle CPU and memory resources. Then, the platform generates a KubernetesJob resource object and embeds the user-provided Pod template in it. Crucially, the platform modifies the nodeAffinity (node affinity) rules in this Pod template based on the node resource information labels maintained in step S202, limiting the scheduling target of the Pod to the specific target nodes that have been filtered. Finally, the platform issues this Job object to the corresponding edge Kubernetes cluster. The cluster's scheduler will strictly follow this affinity rule to schedule the task Pod to the specified target node for execution, thereby achieving precise utilization of idle resources.

[0153] 2. Security protection process, as shown in FIG. 2, to ensure that idle tasks do not affect core CDN services, the system implements the following security protection mechanisms: Figure 5

[0154] The monitoring system (Prometheus) continuously and periodically pulls resource data from edge nodes and makes judgments based on pre-set alarm rules (e.g., node CPU usage exceeds 75% for 1 minute continuously). Once it detects that the real-time load of a target node exceeds the alarm threshold, the monitoring system immediately sends a node overload alarm event to the container platform through the webhook callback mechanism.

[0155] After receiving the node overload alarm, the container platform immediately queries all Pods running on the overloaded node and locates the KubernetesJob resource object corresponding to the idle task created by the system. Then, the platform actively deletes the Job object. According to the Kubernetes mechanism, deleting the Job will cascade delete all Pods created by it, thereby expelling the idle task from the overloaded node and quickly releasing the occupied computing and network resources, ensuring that the core CDN services on the node return to normal.

[0156] ​After the original task is evicted, the container platform initiates a rescheduling process. It re-inquires the current idle resource pool to find a replacement node that meets the resource specification requirements of the original task. If a suitable node is found, the same KubernetesJob resource object is immediately recreated and delivered on the node, so that the task can continue to be executed. If there is no suitable node at present, the system will wait for a preset time interval (for example, 5 minutes), and then try to query and select a replacement node again until the task is successfully rescheduled. This mechanism ensures that the idle task can be completed eventually without affecting the business.

[0157] It should be understood that, although each step in the flowchart involved in each embodiment as described above is displayed in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, there is no strict order limitation for the execution of these steps, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in each embodiment as described above can include multiple steps or stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0158] Based on the same inventive concept, the embodiments of the present application also provide a content distribution network idle resource-based task scheduling device for implementing the above-mentioned content distribution network idle resource-based task scheduling method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more content distribution network idle resource-based task scheduling device embodiments provided below can refer to the limitations of the content distribution network idle resource-based task scheduling method in the above text, which will not be repeated here.

[0159] In one exemplary embodiment, as shown in Figure 6 a content distribution network idle resource-based task scheduling device is provided, comprising:

[0160] The receiving module 602 is configured to receive a task creation request submitted by a user, wherein the task creation request includes task execution logic defined based on a container image, task running parameters specified in the form of a Pod template, resource specification information required by the task, and the number of task replicas.

[0161] The building module 604 is configured to identify idle nodes with a current load level lower than a preset threshold based on real-time resource utilization data of each node in a plurality of edge Kubernetes clusters periodically acquired by a monitoring system, and build an idle resource pool.

[0162] The screening module 606 is configured to screen target nodes meeting scheduling conditions according to the resource specification information and the replica quantity in the task creation request, and in combination with the total resource quantity and real-time usage of the nodes in the idle resource pool.

[0163] The configuration module 608 is configured to generate a Kubernetes Job resource object corresponding to the task creation request, and configure a node affinity rule in a Pod template associated with the Kubernetes Job resource object, so that a Pod created by the Pod template is scheduled to run on the screened target nodes.

[0164] The receiving module 602 is further configured to receive a node overload alarm event sent by the monitoring system when detecting that the real-time load of any target node exceeds a preset alarm threshold.

[0165] The execution module 610 is configured to perform a task scheduling operation in response to the node overload alarm event.

[0166] In an exemplary embodiment, the construction module 604 is specifically configured to obtain, from the monitoring system, host resource usage data and container resource usage data collected by a cAdvisor component deployed on each edge node; wherein a Prometheus server in the monitoring system periodically pulls resource usage data exposed by the cAdvisor component from each edge node.

[0167] In an exemplary embodiment, the construction module 604 is specifically configured to maintain resource information tags for each node in the idle resource pool, the resource information tags including at least one of an IP address, operator information and geographical location information of the node; and cache total resource quantity information of each node and real-time resource usage data provided by the monitoring system.

[0168] In an exemplary embodiment, the screening module 606 is specifically configured to parse the task creation request to determine a task type; in a case where the task type is determined to be a data collaboration type task, preferentially select a node with sufficient idle bandwidth resources as a candidate node; in a case where the task type is determined to be a compute-intensive task, preferentially select a node with sufficient idle CPU and memory resources as a candidate node; and determine a final target node set from the candidate nodes based on the resource specification information and the replica quantity.

[0169] In an example embodiment, the configuration module 608 is specifically configured to set a nodeAffinity field in the Pod template specification based on the resource information label of the target node screened out; and the configuration of the nodeAffinity field is used to instruct the Kubernetes scheduler to schedule the Pod instance only to the target node with a matching resource information label.

[0170] In an example embodiment, the execution module 610 is specifically configured to, in response to a node overload alarm event, determine a Kubernetes Job resource object corresponding to the idle-time task running on the overloaded node; delete the determined Kubernetes Job resource object to evict the associated Pod; reselect a replacement node meeting the original task resource specification requirement from the current idle-time resource pool; and re-create and issue the Kubernetes Job resource object on the replacement node.

[0171] In an example embodiment, the execution module 610 is further configured to, in the case where a node meeting the requirement is currently available, immediately re-issue the task on the available node; and in the case where no node meeting the requirement is currently available, wait for a preset time interval, and then perform the step of reselecting a replacement node meeting the original task resource specification requirement from the current idle-time resource pool again.

[0172] The above various modules in the task scheduling apparatus based on the idle-time resources of the content distribution network can be all or partially implemented by software, hardware, and combinations thereof. The above various modules can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in the computer device in software form, so as to be called and executed by a processor to perform the operations corresponding to the above various modules.

[0173] In an example embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in Figure 7As shown in the figure. The computer device includes a processor, a memory, an input / output interface (I / O for short) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the real-time resource utilization data of each node in the plurality of edge Kubernetes clusters. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with the terminal outside through network connection. The computer program is executed by the processor to implement a task scheduling method based on content distribution network idle time resource.

[0174] Those skilled in the art can understand that, Figure 7 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0175] In one exemplary embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above method.

[0176] In one embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by the processor to implement the steps of the above method.

[0177] In one embodiment, a computer program product is provided, including a computer program, and the computer program is executed by the processor to implement the steps of the above method.

[0178] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0179] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0180] The technical features of the above embodiments can be combined in any manner. To make the description concise, all possible combinations of the technical features in the above embodiments are not described, but as long as the combinations of the technical features do not exist contradictions, they should be considered as the scope of the present application.

[0181] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is relatively specific and detailed, but should not be understood as a limitation on the scope of the patent. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A task scheduling method based on idle resources of a content delivery network, characterized in that, Applied to a container platform, the method includes: Receive a task creation request submitted by a user. The task creation request includes the task execution logic defined based on the container image, the task running parameters specified in the form of a Pod template, the resource specification information required by the task, and the number of task replicas. Based on the real-time resource utilization data of each node in multiple edge Kubernetes clusters periodically obtained by the monitoring system, idle nodes with current load levels below a preset threshold are identified, and an idle resource pool is constructed. Based on the resource specification information and number of replicas in the task creation request, and combined with the total resource amount and real-time usage of the nodes in the idle resource pool, target nodes that meet the scheduling conditions are selected. Generate a Kubernetes Job resource object corresponding to the task creation request, and configure the node affinity rules in the Pod template associated with the Kubernetes Job resource object so that the Pod created by the Pod template is scheduled to run on the selected target node; Receive a node overload alarm event sent by the monitoring system when it detects that the real-time load of any target node exceeds a preset alarm threshold; In response to the node overload alarm event, a task scheduling operation is performed.

2. The method according to claim 1, characterized in that, The real-time resource utilization data of each node in multiple edge Kubernetes clusters, which are periodically acquired by the monitoring system, includes: The system acquires host resource usage data and container resource usage data collected by the cAdvisor component deployed on each edge node. In this monitoring system, the Prometheus server periodically pulls the resource usage data exposed by the cAdvisor component from each edge node.

3. The method according to claim 1, characterized in that, The construction of the idle resource pool includes: Maintain a resource information tag for each node in the idle resource pool. The resource information tag includes at least one of the node's IP address, its operator information, and its geographical location information. The cache stores information on the total resources of each node, as well as real-time resource usage data provided by the monitoring system.

4. The method according to claim 1, characterized in that, The selection of a set of target nodes that meet the scheduling conditions includes: Analyze the task creation request to determine the task type; When the task type is determined to be a data collaboration task, nodes with sufficient idle bandwidth resources are given priority as candidate nodes. When the task type is determined to be a computationally intensive task, nodes with sufficient idle CPU and memory resources are preferentially selected as candidate nodes. Based on the resource specification information and the number of replicas, the final target node set is determined from the candidate nodes.

5. The method according to claim 3, characterized in that, The node affinity rules in the Pod template associated with the configured Kubernetes Job resource object include: Based on the resource information tags of the selected target nodes, set the nodeAffinity field in the Pod template specification; the configuration of the nodeAffinity field is used to instruct the Kubernetes scheduler to schedule Pod instances only to target nodes with matching resource information tags.

6. The method according to claim 1, characterized in that, The task scheduling operation performed in response to the node overload alarm event includes: In response to the node overload alarm event, determine the Kubernetes Job resource object corresponding to the idle task running on the overloaded node; Delete the identified Kubernetes Job resource object to evict its associated Pod; Select a replacement node from the current idle resource pool that meets the original task resource specifications. The Kubernetes Job resource object is recreated and deployed on the replacement node.

7. The method according to claim 6, characterized in that, After selecting a replacement node from the current idle resource pool that meets the original task resource specifications, the process also includes: If a suitable available node exists, immediately redeploy the task to that node. If no suitable available node is currently available, after a preset time interval, the step of selecting a replacement node that meets the original task resource specifications from the current idle resource pool will be executed again.

8. A task scheduling device based on idle resources of a content delivery network, characterized in that, The device includes: The receiving module is used to receive a task creation request submitted by the user. The task creation request includes the task execution logic defined based on the container image, the task running parameters specified in the form of a Pod template, the resource specification information required by the task, and the number of task replicas. The module is used to identify idle nodes whose current load level is below a preset threshold based on real-time resource utilization data of each node in multiple edge Kubernetes clusters periodically obtained by the monitoring system, and to build an idle resource pool. The filtering module is used to filter out target nodes that meet the scheduling conditions based on the resource specification information and number of replicas in the task creation request, combined with the total resource amount and real-time usage of the nodes in the idle resource pool. The configuration module is used to generate a Kubernetes Job resource object corresponding to the task creation request, and configure the node affinity rules in the Pod template associated with the Kubernetes Job resource object so that the Pod created by the Pod template is scheduled to run on the selected target node; The receiving module is also used to receive a node overload alarm event sent by the monitoring system when it detects that the real-time load of any target node exceeds a preset alarm threshold. The execution module is used to perform task scheduling operations in response to the node overload alarm event.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to 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 a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images