Kubernetes-based task scheduling method, controller, node and cluster system

Abstract

The invention provides a task scheduling method and device based on Kubernetes, the method is applied to a controller, and the method comprises the following steps: receiving a task submission request; calling a user-defined task segmentation program interface, and splitting the received task into a plurality of subtasks through a task segmentation program; selecting a plurality of target nodes matched with the task from the nodes based on the obtained resource state of each node of the Kubernetes; scheduling the plurality of sub-tasks to the corresponding target nodes, so that each target node processes the received sub-tasks through a task processing program by calling a task processing program interface; and calling a user-defined result merging program interface, obtaining processing results of the subtasks by the target nodes through a result merging program, and merging the processing results to obtain a final processing result. According to the task scheduling method based on Kubernetes, the node resource state can be dynamically sensed, fine-grained segmentation and combination of tasks can be achieved, and the task processing efficiency can be improved.

Description

Technical Field

[0001] The present application relates to a technical field related to cloud computing, and in particular to a task scheduling method, controller, node, and cluster system based on Kubernetes. Background Art

[0002] With the rapid development of cloud computing and containerization technologies, enterprises are increasingly demanding efficient and flexible task scheduling systems. While existing task scheduling systems have made progress in resource management and task allocation, they still face numerous challenges when handling resource-intensive tasks such as video processing and machine learning inference. These issues include uneven resource allocation, inefficient task processing, and a lack of fine-grained control, which severely impact overall system performance and user experience.

[0003] In existing technologies, task scheduling is mainly performed through traditional distributed task scheduling frameworks (such as YARN and Mesos) and the Kubernetes native scheduler. These technologies have certain advantages in task scheduling and resource management, but due to issues such as framework and resource settings, existing methods have the following disadvantages:

[0004] On the one hand, neither traditional distributed task scheduling frameworks nor the native Kubernetes scheduler can perceive changes in node resource status in real time, resulting in uneven resource allocation. This is particularly true for data-intensive, computationally heterogeneous, and resource-volatile tasks like video inference. Dynamic weight adjustment based on node historical performance is impossible, fine-grained control is lacking, and task segmentation at the video frame level is impossible. A single Pod still needs to process the entire video clip, resulting in insufficient resources on a single device to handle the task. This leads to excessive processing time for each task and waste of idle node resources.

[0005] On the other hand, due to the lack of fine-grained control, the existing task splitting and merging processing technology adopts a preset sharding ratio and cannot realize dynamic splitting and merging of tasks, resulting in excessively long single task processing time and affecting the overall performance of the system.

[0006] On the other hand, the task splitting logic of traditional distributed task scheduling frameworks (such as YARN and Mesos) is strongly coupled with the scheduler, requiring pre-defined node resource pools. It is unable to perceive network bandwidth fluctuations and GPU utilization changes in real time, lacks flexibility, and is difficult to adapt to different types of task requirements.

[0007] Therefore, in this context, how to provide a Kubernetes-based task scheduling method that can dynamically perceive the node resource status, realize fine-grained task segmentation and merging, and improve task processing efficiency is a technical problem that needs to be solved. Summary of the Invention

[0008] In view of the above problems in the prior art, the present application provides a task scheduling method, controller, node and cluster system based on Kubernetes, which can provide a system that can dynamically perceive the node resource status, realize fine-grained splitting and merging of tasks, and improve task processing efficiency.

[0009] To achieve the above objectives, the first aspect of the present application provides a Kubernetes-based task scheduling method, which is applied to a controller. The method includes:

[0010] Receive task submission requests;

[0011] Call the user-defined task splitting program interface and split the received task into several subtasks through the task splitting program;

[0012] Selecting several target nodes that match the task based on the resource status of each Kubernetes node;

[0013] Dispatching the plurality of subtasks to the corresponding target nodes, so that each target node processes the received subtasks through a task processing program by calling a task processing program interface;

[0014] Call the user-defined result merging program interface, obtain the processing results of each target node on the subtask through the result merging program, and merge them to obtain the final processing result.

[0015] As described above, the controller receives task requests, calls a user-defined task splitting program interface to split the task into subtasks, and intelligently selects execution nodes based on node resource status. The task handler processes the received subtasks by calling a customized task processing interface. After the subtasks are completed, the result merging program interface is called to aggregate the results, ensuring efficient task processing and resource utilization. This approach solves the problems of uneven resource allocation, inefficient task processing, and lack of fine-grained control in existing technologies, significantly improving the flexibility and performance of task scheduling.

[0016] As a possible implementation of the first aspect, selecting several target nodes matching the task based on the resource status of each node in Kubernetes includes:

[0017] Calculate a comprehensive score for each node based on its resource status, and select a required number of target nodes based on the ranking of the comprehensive scores; wherein the resource status of each node is regularly collected by a node resource collection component, including hardware resource status, network status, and historical task processing results;

[0018] The comprehensive score is obtained by scoring and weighted calculation based on the hardware resource status, network status and historical task processing results.

[0019] As shown above, through a comprehensive scoring mechanism, the controller can intelligently select the most suitable target node to execute subtasks, ensuring that each subtask runs on a node with the most appropriate resources. This not only improves task processing efficiency but also significantly increases the overall resource utilization of the cluster.

[0020] A second aspect of the present application provides a Kubernetes-based task scheduling method, which is applied to a Kubernetes node. The method includes:

[0021] Uploading resource status to a controller so that the controller can select a node for processing a subtask, where the subtask is formed by splitting a received task into two subtasks;

[0022] Receive a subtask scheduled by the controller;

[0023] Calling a task processing program interface, and downloading the subtask data from a specified location through the task processing program to perform subtask processing;

[0024] The processing results of the subtasks are sent to the controller for task processing merging.

[0025] As described above, by receiving the subtasks dispatched by the controller and processing them through the task handler, the burden of centralized processing of tasks with large computational load is reduced, the overall task processing efficiency is improved, and the cluster resource utilization is improved.

[0026] As a possible implementation of the second aspect, each Kubernetes node has a node resource collection component, which periodically reports node resources to the controller through the node resource collection component. The node resources include hardware resources, network status, and historical task processing results.

[0027] From the above, by deploying the node resource collection component on each node, plug-in expansion, customizable data sources and rapid adaptation to various types of heterogeneous hardware can be met; the node status is perceived and scored by collecting hardware resources, network status and historical task processing results.

[0028] As a possible implementation manner of the second aspect, the method further includes: in the process of processing the subtask, reporting the processing progress of the subtask to the controller.

[0029] As described above, by reporting subtask progress to the controller during processing, real-time feedback on task processing is provided. This allows users to monitor task execution status in real time and promptly identify and address potential issues. Furthermore, progress reporting provides the controller with more accurate scheduling information, further optimizing task scheduling efficiency and resource utilization.

[0030] A third aspect of the present application provides a Kubernetes-based task scheduling method, including a controller and several Kubernetes nodes in a Kubernetes cluster; the method includes:

[0031] The controller receives a task submission request, calls a task splitting program interface, and splits the received task into several subtasks through the task splitting program;

[0032] The controller selects a plurality of target nodes based on the resource status of each Kubernetes node obtained, and schedules the plurality of subtasks to the corresponding target nodes;

[0033] The target node calls the task processing program interface, processes the subtask scheduled to the node through the task processing program, obtains the processing result of the subtask, and sends it to the controller;

[0034] The controller calls the result merging program interface, and merges the received processing results of each target node on each subtask through the result merging program to obtain the final processing result.

[0035] As mentioned above, by pre-defining custom resources for coordination nodes and target nodes to call interfaces and run programs, users can flexibly configure and update these resources according to different task requirements. This improves the flexibility of the system and can adapt to different types of tasks and business needs.

[0036] A fourth aspect of the present application provides a Kubernetes controller, including:

[0037] Task receiving module, used to receive task submission requests;

[0038] The splitting processing module is used to call the user-defined task splitting program interface to split the received task into several subtasks through the task splitting program; select several target nodes matching the task based on the resource status of each Kubernetes node; and schedule the several subtasks to the corresponding target nodes, so that each target node processes the received subtasks through the task processing program by calling the task processing program interface;

[0039] The result merging module calls the user-defined result merging program interface, obtains the processing results of each target node on the subtask through the result merging program, and merges them to obtain the final processing result.

[0040] A fifth aspect of the present application provides a Kubernetes node, including:

[0041] A subtask receiving module, configured to receive a subtask scheduled by the controller;

[0042] The task processing module is used to call the task processing program interface and download the subtask data from the specified location through the task processing program to perform subtask processing;

[0043] The result uploading module is used to send the processing results of the subtasks to the controller for task processing merging.

[0044] A sixth aspect of the present application provides a Kubernetes cluster system, wherein custom resources are registered in the Kubernetes cluster system, and the custom resources include a task processing image, a task segmentation image, and a result merging image;

[0045] The Kubernetes cluster system includes the controller described in the fourth aspect and several Kubernetes nodes described in the fifth aspect.

[0046] In a seventh aspect, the present application provides a computing device, comprising: a processor, and a memory on which program instructions are stored. When the program instructions are executed by the processor, the processor executes the Kubernetes-based task scheduling method described in any one of the first aspects, or the Kubernetes-based task scheduling method described in the second and third aspects.

[0047] In an eighth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon. When the program instructions are executed by a computer, the computer executes the Kubernetes-based task scheduling method described in any one of the first aspects, or the Kubernetes-based task scheduling method described in the second and third aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a flowchart of the Kubernetes-based task scheduling method provided in the first embodiment of the present application;

[0049] Figure 2a This is a flowchart of the Kubernetes-based task scheduling method provided in the second embodiment of the present application;

[0050] Figure 2bThis is a flowchart of the Kubernetes-based task scheduling method provided in the second embodiment of the present application;

[0051] Figure 2c This is a timing diagram of the Kubernetes-based task scheduling method provided in the second embodiment of the present application;

[0052] Figure 3 This is a flowchart of a Kubernetes-based task scheduling method provided in the third embodiment of the present application;

[0053] Figure 4 This is a flowchart of a Kubernetes-based task scheduling method provided in the fourth embodiment of the present application;

[0054] Figure 5 This is a schematic diagram of a Kubernetes controller provided in the fifth embodiment of the present application;

[0055] Figure 6 This is a schematic diagram of a Kubernetes node provided in the sixth embodiment of the present application;

[0056] Figure 7 This is a schematic diagram of a Kubernetes cluster system provided in the seventh embodiment of the present application;

[0057] Figure 8 It is a structural schematic diagram of a computing device provided in an embodiment of the present application.

[0058] It should be understood that the sizes and shapes of the blocks in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of the present invention. The relative positions and inclusion relationships between the blocks presented in the structural diagrams are merely schematic representations of the structural relationships between the blocks and do not limit the physical connection methods of the embodiments of the present invention. DETAILED DESCRIPTION

[0059] The technical solution provided by this application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of this application are mainly for illustrating possible implementation methods of the technical solution of this application and should not be interpreted as the sole limitation of the technical solution of this application. It is known to those skilled in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by this application is also applicable to similar technical problems.

[0060] It should be understood that the Kubernetes-based task scheduling solutions provided in the embodiments of this application include Kubernetes-based task scheduling methods, apparatuses, computing devices, and readable storage media. Because these technical solutions solve the same or similar problems, some repetitions may not be repeated in the following specific embodiments. However, these specific embodiments should be considered as having referenced each other and can be combined with each other.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. In the event of any inconsistency, the meanings described in this specification or the meanings derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application. In order to accurately describe the technical content in this application and to accurately understand the present invention, the following explanations or definitions are given for the terms used in this specification before describing the specific embodiments:

[0062] 1) Kubernetes (K8s): Kubernetes is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications. It ensures high availability and elastic scalability of applications by defining and managing the container lifecycle.

[0063] 2) CRD (Custom Resource Definition): CRD is a mechanism provided by Kubernetes that allows users to define their own resource types. Through CRD, users can extend the Kubernetes resource model to define and manage custom resources.

[0064] 3) Golang coroutines: Golang coroutines are lightweight threads used for concurrent programming in the Go language. A coroutine is started by prefixing a function call with the `go` keyword. Coroutines are inexpensive to create and switch between, making them suitable for high-concurrency scenarios.

[0065] 4) HTTP Request: An HTTP request is a network request based on the HTTP protocol, used for communication between a client and a server. An HTTP request typically includes a request method (such as GET or POST), a request header, and a request body.

[0066] 5) DaemonSet: DaemonSet is a controller in Kubernetes that ensures that each node in the cluster runs a specific Pod replica. DaemonSet is commonly used to deploy node-level services such as log collection, monitoring agents, and resource monitoring.

[0067] 5) GPU Utilization: GPU utilization refers to the usage of the GPU within a specific time, usually expressed as a percentage. It reflects how busy the GPU is at a given time.

[0068] The Kubernetes-based task scheduling solution provided by the embodiment of the present application receives task submission requests through a controller, calls a user-defined task splitting program interface, splits the original task into several subtasks through the task splitting program, selects the most suitable target node based on the resource status of the available nodes, calls the task processing program interface, and executes each subtask through the task processing program; after the subtask is completed, calls the user-defined result merging program interface, and aggregates the results of all subtasks through the result merging program to obtain the final processing result. This method can provide a Kubernetes-based task scheduling method that can dynamically perceive the node resource status, realize fine-grained splitting and merging of tasks, and improve task processing efficiency. The embodiment of the present application can be applied to cloud computing and cloud services in various fields such as video, data processing, model reasoning, and machine learning. The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0069] The first embodiment of the present application provides a task scheduling method based on Kubernetes, which is applied to the controller. Figure 1 , specifically describing the implementation of each step of the method, including steps S10-S50.

[0070] S10: Receive a task submission request.

[0071] In some embodiments, a deployment phase is also included: registering a custom resource (DynamicTask CRD) in the Kubernetes cluster, wherein the custom resource defines the task type, task processing image, task segmentation image, and result merge image; the custom resource is controlled by a controller; the controller is deployed in the Kubernetes cluster, and the controller listens for requests to operate the custom resource. Among them, the controller (CRD Operator) is provided by Kubernetes, and when the custom resource (DynamicTask CRD) is operated, the corresponding controller performs corresponding processing operations. For example, the controller listens for operation requests of the custom resource (DynamicTask CRD) based on the Kubernetes LIST-WATCH mechanism. When there is a create request, the controller initializes the corresponding storage and handler.

[0072] In some embodiments, users submit tasks via HTTP requests. The tasks include at least one of the following: video processing, video stream processing, machine learning, model reasoning, and big data analysis. The HTTP task requests can be created using Golang coroutines.

[0073] In some embodiments, in a task submission request, a user can specify a priority for the task, and high-priority tasks are processed first.

[0074] In some embodiments, users are allowed to specify dependencies between tasks in a task submission request. When scheduling tasks, the controller considers these dependencies to ensure that tasks are executed in the correct order.

[0075] In some embodiments, the node resource status is obtained by a node resource collection component; the node resource collection component is deployed on each of the nodes through DaemonSet resources, and regularly collects and reports the node resource status to the controller, including hardware resource status, network status and historical task processing results; wherein, at least one of the following indicators: GPU utilization, CPU utilization, memory usage, network bandwidth and latency, network throughput, and node I / O throughput performance.

[0076] S20: calling a user-defined task splitting program interface, and splitting the received task into several subtasks through the task splitting program.

[0077] In some embodiments, the controller creates an instance of the DynamicTask CRD resource based on a user request and exposes a unified RESTful API.

[0078] In some embodiments, the task splitting image, task processing image, and result merging image are defined by custom resources. When the controller receives the task submission request, it starts the container and runs the task splitting program, task processing program, and result merging program. Each program has its own interface for the controller or coordination node to call. The interface is a corresponding RESTful API exposed according to the specification. For example, the task splitting program interface API is called to divide the task into multiple subtasks through the task splitting program.

[0079] In some embodiments, multiple task segmentation strategies are provided, allowing users to select the appropriate strategy based on the task type and data characteristics. For example, for video processing tasks, segmentation can be performed by frame; for big data tasks, segmentation can be performed by data block. The same applies to result merging.

[0080] S30: Selecting several target nodes matching the task based on the resource status of each node in Kubernetes.

[0081] In some embodiments, resource status of available nodes is evaluated first, and then subtasks are split, and target nodes of the subtasks are selected based on the ranking of node resource status.

[0082] In some embodiments, the method of selecting several target nodes that match the task based on the resource status of each node of Kubernetes includes: calculating a comprehensive score of each node through the resource status of each node, and selecting a required number of target nodes according to the ranking of the comprehensive score; wherein, the resource status of each node is regularly collected by a node resource collection component, including hardware resource status, network status and historical task processing results; wherein, the comprehensive score is obtained by scoring and weighted calculation based on the hardware resource status, network status and historical task processing results.

[0083] In some embodiments, the comprehensive scoring formula also includes other score items OtherScore, which are calculated based on CPU usage, memory, disk space, and network status. For example:

[0084] FinalScore=α·GPUScore+β·OtherScore+γ·HistoryScore

[0085] Among them, the FinalScore is a comprehensive score, the GPUScore is the current GPU utilization, the HistoryScore is the average of the GPU historical utilization in the past period of time, and the α, β, and γ are weight coefficients. For general tasks, α=0.4, β=0.4, and γ=0.2; for computing-intensive tasks, α=0.5, β=0.3, and γ=0.2.

[0086] In some embodiments, GPUScore is calculated by the GPU free memory, the memory size required by the current task, and the current GPU utilization, for example:

[0087]

[0088] Among them, Free_GPU_Mem is the free GPU memory, Req_GPU_Mem is the existing memory size required by the current task, which is obtained by obtaining the subtask description. effective is the current GPU utilization, w G is the weight coefficient, which can be 0.7.

[0089] In some embodiments, HistoryScore is the average score of task processing results, which is calculated by task success rate and efficiency score, for example:

[0090] HistoryScore=λ·SuccessRate+(1-λ)·EfficiencyScore

[0091] Among them, λ is the weight coefficient, SuccessRate is the task success rate, and EfficiencyScore is the efficiency score, which are calculated according to the following formulas:

[0092]

[0093] Among them, SuccessCount is the number of successful historical tasks, TotalCount is the number of all historical tasks, TimeoutCount is the number of timed tasks; AvgTaskTime cluster AvgTaskTime is the average processing time of the cluster as a whole. node The average processing time of tasks on this node.

[0094] OtherScore is calculated according to the following formula:

[0095] OtherScore=w c CPUScore+w m MemScore+w d DiskScore+w n NetScore

[0096] Among them, w c ,w m ,w d ,w n They are weight coefficients. CPUScore, MemScore, DiskScore, and NetScore are scores for CPU, memory, disk space, and network status respectively, which can be calculated according to the following formula:

[0097]

[0098] Among them, Free_CPU is the CPU resource currently available for the node (unit: number of cores or vCPU), Req_CPU is the CPU resource required for the task, k c is the sensitivity parameter and can be taken as 0.4.

[0099]

[0100] Among them, Free_Mem is the memory currently available for the node, Req_Mem is the memory required for the task, and k m is the sensitivity parameter and can be taken as 0.3.

[0101]

[0102] Among them, Free_Disk is the disk space currently available on the node, Req_DISK is the disk space required by the task, and k d is a sensitivity parameter and can be taken as 0.5.

[0103]

[0104] Among them, Avail_BW is the node's currently available network bandwidth, Max_BW is the node's maximum network bandwidth, Latency is the network delay time, Throughput is the node's network throughput per unit time, and k n ,k m is a sensitivity parameter, which can be 0.55 and 0.25.

[0105] In some embodiments, other node status indicators may also be monitored, such as system error logs, hardware failures, etc.

[0106] In some embodiments, based on the resource status of available nodes, the execution node of the subtask is selected, the subtask is dynamically created on each execution node, the task processing interface is called, and the subtask is executed through the task processing program.

[0107] S40: dispatching the plurality of subtasks to the corresponding target nodes, so that each target node processes the received subtasks through a task processing program by calling a task processing program interface.

[0108] In some embodiments, the input data is preprocessed before the task is processed, for example, denoising the video data, cleaning the big data, etc.

[0109] In some embodiments, on each target node, the task processing program interface is an API interface exposed by starting a container (instantiation) according to the task processing image and running the task processing program.

[0110] In some embodiments, during the task processing of the subtask, the processing progress of the subtask is reported to the controller, which may include the number of completed subtasks, the estimated completion time, etc.

[0111] In some embodiments, the controller dynamically adjusts the task scheduling strategy based on real-time progress feedback. For example, if a subtask takes too long to process, the remaining subtasks can be reallocated to other nodes.

[0112] S50: calling the user-defined result merging program interface, obtaining the processing results of each target node on the subtask through the result merging program, and merging them to obtain the final processing result.

[0113] In some embodiments, after all subtasks are completed, the result merging program interface API is called, and the results of the subtasks are aggregated into a final result through the result merging program.

[0114] In some embodiments, after the result merging is completed, the final result is formatted according to user requirements and saved to a specified location. For example, the video processing result is converted into a specific video format.

[0115] The second embodiment of the present application provides a task scheduling method based on Kubernetes. Figure 2a The method provided by the second embodiment includes the following steps S200-S240.

[0116] S200: Register and define custom resources.

[0117] In general scenarios of traditional task scheduling, the Kubernetes native scheduler uses a three-stage mechanism of "preselection-optimization-binding" to select the target node for task processing, namely:

[0118] 1. Pre-selection stage: Filter out unavailable nodes based on hard indicators such as node resource margin and taint tolerance. For example, exclude nodes with insufficient GPU memory or network bandwidth below the threshold.

[0119] 2. Optimization stage: Scoring is based on dynamic indicators such as node resource balance and image cache status.

[0120] 3. Binding phase: etcd persists scheduling decisions and supports preemptive scheduling to ensure high-priority tasks.

[0121] The native scheduler performs well in container (Pod)-level resource allocation, but it encounters problems in data-intensive, computationally heterogeneous, and resource-volatile task scenarios, such as video inference tasks. It cannot dynamically adjust weights based on the node's historical performance, lacks fine-grained control, and cannot achieve task segmentation at the video frame level. A single Pod still needs to process the entire video clip, resulting in a single device's resources being unable to meet task processing needs. This leads to excessively long single-task processing times and idle and wasted resources on other nodes.

[0122] Therefore, the embodiment of the present application proposes to use custom resources to define task processing procedures, task splitting procedures and result merging procedures, and perform task scheduling through the method implemented by the controller. Break through the Pod-level resource allocation limitations, realize video frame-level task splitting and cross-node dynamic scheduling, and eliminate the resource bottleneck of a single device. Through the DynamicTask CRD standardized task splitting / merging interface, the user business logic (video inference algorithm) is decoupled from the scheduling framework to achieve higher scalability. Users can freely implement task splitting algorithms and merging algorithms according to actual task scenarios.

[0123] Specifically, DynamicTaskCRD is designed based on Kubernetes' custom resource (DynamicTask CRD). Users register the CRD resource of dynamictasks.workflow.com in the Kubernetes cluster. Its simplified definition is as follows:

[0124]

[0125]

[0126] Among them, taskType supports multiple task types, such as video detection (video_detect), video reasoning, big data analysis (data_analysis), stream processing (stream_process), etc. Among them, processorImage, splitImage, and mergeImage are the images of the task processing program, task splitting program, and result merging program respectively.

[0127] The controller monitors DynamicTask CRD resource operation requests based on the Kubernetes LIST-WATCH mechanism. When a create request arrives, it initializes the corresponding storage and processing programs, creates an HTTP task processing service based on a Golang coroutine, and exposes a RESTful API (such as / v1 / task / submit) for user access.

[0128] For example, when the controller receives the task submission request, it makes a creation request for the DynamicTaskCRD resource. The controller starts the task splitting program and the result merging program by running the customized task splitting image and result merging image, and exposes the corresponding RESTful API interface for the controller (CRD Operator) to call.

[0129] S210: The controller receives the task submission request and scores and sorts the tasks according to the resource status of the available nodes.

[0130] like Figure 2c As shown, when the controller receives a task request, it obtains the status data of the node resources through the node monitoring component (node ​​resource collection component) and reports it to the controller through a lightweight communication mechanism (such as gRPC or HTTP).

[0131] The node evaluation algorithm is executed based on the received data. Specifically, the comprehensive score of each available node is calculated according to the following formula:

[0132] FinalScore=α·GPUScore+β·OtherScore+γ·HistoryScore

[0133] The FinalScore is a comprehensive score, the GPUScore is the current GPU utilization, the OtherScore is a score that combines CPU, memory, disk space, and network status factors, and the HistoryScore is the average score of task processing results over the past period of time. α, β, and γ are weight coefficients that are dynamically selected based on the task type. For general tasks such as taskType video detection (video_detect) and video inference, α = 0.4, β = 0.4, and γ = 0.2; for compute-intensive tasks such as taskType big data analysis (data_analysis) and stream processing (stream_process), α = 0.5, β = 0.3, and γ = 0.2.

[0134] GPUScore is calculated by the GPU's free memory, the memory required by the current task, and the current GPU utilization:

[0135]

[0136] Among them, Free_GPU_Mem is the free GPU memory, Req_GPU_Mem is the existing memory size required by the current task, which is obtained by obtaining the subtask description. effective is the current GPU utilization, w G is the weight coefficient, which can be 0.7.

[0137] OtherScore is calculated according to the following formula:

[0138] OtherScore=w c CPUScore+w m MemScore+w d DiskScore+w n NetScore

[0139] Among them, w c ,wm ,w d ,w n They are weight coefficients. CPUScore, MemScore, DiskScore, and NetScore are scores for CPU, memory, disk space, and network status respectively, which can be calculated according to the following formula:

[0140]

[0141] Among them, Free_CPU is the CPU resource currently available for the node (unit: number of cores or vCPU), Req_CPU is the CPU resource required for the task, k c is the sensitivity parameter and can be taken as 0.4.

[0142]

[0143] Among them, Free_Mem is the memory currently available for the node, Req_Mem is the memory required for the task, and k m is the sensitivity parameter and can be taken as 0.3.

[0144]

[0145] Among them, Free_Disk is the disk space currently available on the node, Req_DISK is the disk space required by the task, and k d is a sensitivity parameter and can be taken as 0.5.

[0146]

[0147] Among them, Avail_BW is the node's currently available network bandwidth, Max_BW is the node's maximum network bandwidth, Latency is the network delay time, Throughput is the node's network throughput per unit time, and k n ,k m is a sensitivity parameter, which can be 0.55 and 0.25.

[0148] HistoryScore is the historical task success rate, which is calculated by task success rate and efficiency score:

[0149] HistoryScore=λ·SuccessRate+(1-λ)·EfficiencyScore

[0150] Among them, SuccessRate is the task success rate, and EfficiencyScore is the efficiency score, which are calculated according to the following formulas:

[0151]

[0152]

[0153] Among them, SuccessCount is the number of successful historical tasks, TotalCount is the number of all historical tasks, TimeoutCount is the number of timed tasks; AvgTaskTime cluster AvgTaskTime is the average processing time of the cluster as a whole. node The average processing time of tasks on this node.

[0154] After calculating the comprehensive score of each available node, they are sorted from high to low for selection by subsequent subtasks.

[0155] The embodiment of the present application integrates real-time node indicators (CPU / GPU utilization, network bandwidth) and historical success rates through a dynamic scoring algorithm to improve the accuracy of scheduling decisions.

[0156] S220: The controller calls the task splitting program interface, splits the original task into several subtasks through the task splitting program, and selects a suitable target node to send the subtasks.

[0157] Call the RESTful API interface of the splitImage task splitting program, split the original task data into multiple subtasks through the task splitting program, and select a suitable target node for each subtask based on the ranking of the comprehensive scores of the available nodes.

[0158] S230: Calling a task processing program interface at each target node to process the subtask.

[0159] For each subtask, create a subtask on the target node in the Kubernetes cluster in the form of a KubernetesJob, such as Figure 2b 、 2c As shown in the figure, the target node starts a container (Pod) based on the task processing image, runs the task processing program, begins task processing, and returns a startup completion notification.

[0160] During the task execution process, the controller obtains the task execution progress by querying the RESTful API interface of the task handler.

[0161] S240: After the subtasks of each target node are completed, the controller calls the result merging program interface and aggregates the results of all subtasks through the result merging program to obtain the final processing result.

[0162] When all subtasks are completed, the controller calls the RESTful API interface of the result merging program, and the result merging program summarizes (Merge) the processing results of all subtasks to complete the result aggregation, and the user obtains the final processing result of the task.

[0163] The third embodiment of the present application provides a task scheduling method based on Kubernetes, such as Figure 3 As shown, it is applied to Kubernetes nodes, including S300-S320:

[0164] S300: Receive a subtask scheduled by a controller.

[0165] S310: calling a task processing program interface, and downloading the subtask data from a specified location through the task processing program to perform subtask processing.

[0166] In some embodiments, each of the Kubernetes nodes has a node resource collection component, which periodically reports node resources to the controller through the node resource collection component. The node resources include hardware resources, network status, and historical task processing results.

[0167] In some embodiments, the method further includes: during the processing of the subtask, reporting the processing progress of the subtask to the controller.

[0168] S320: Send the processing results of the subtasks to the controller for task processing merging.

[0169] The fourth embodiment of the present application provides a task scheduling method based on Kubernetes, such as Figure 4 As shown, the Kubernetes cluster includes a controller and several Kubernetes nodes; including steps S400-S430:

[0170] S400: The controller receives a task submission request, calls a task splitting program interface, and splits the received task into several subtasks through the task splitting program.

[0171] S410: The controller selects several target nodes based on the obtained resource status of each Kubernetes node, and schedules the several subtasks to the corresponding target nodes.

[0172] S420: The target node calls the task processing program interface, processes the subtask scheduled to the node through the task processing program, obtains the processing result of the subtask, and sends it to the controller.

[0173] S430: The controller calls the result merging program interface, and merges the received processing results of each target node on each subtask through the result merging program to obtain a final processing result.

[0174] The fifth embodiment of the present application provides a Kubernetes controller, which can be used to implement the Kubernetes-based task scheduling method in the above embodiment, such as Figure 5 As shown, the Kubernetes controller includes:

[0175] The task receiving module is used to receive a task submission request; specifically, the task receiving module can be used to implement step S10 in the first embodiment and its optional embodiments.

[0176] A splitting processing module is used to call a user-defined task splitting program interface to split the received task into several subtasks; based on the resource status of each node in Kubernetes, several target nodes matching the task are selected; the several subtasks are scheduled to the corresponding target nodes, so that each target node processes the received subtasks through the task processing program by calling the task processing program interface; specifically, the splitting processing module can be used to implement steps S20-S40 in the first embodiment and its optional embodiments.

[0177] The result merging module calls the user-defined result merging program interface, obtains the processing results of each target node on the subtask through the result merging program, and merges them to obtain the final processing result. Specifically, the result merging module can be used to implement step S50 in the first embodiment and its optional embodiments.

[0178] The sixth embodiment of the present application provides a Kubernetes node, which can be used to implement the Kubernetes-based task scheduling method in the above embodiment, such as Figure 6 As shown, the Kubernetes nodes include:

[0179] The subtask receiving module is used to receive a subtask scheduled by the controller; specifically, the subtask receiving module can be used to implement step S300 in the third embodiment and its optional embodiments.

[0180] The task processing module is used to call the task processing program interface and download the subtask data from the specified location through the task processing program to perform subtask processing; specifically, the task processing module can be used to implement step S310 in the third embodiment and its optional embodiments.

[0181] The result uploading module is used to send the processing results of the subtasks to the controller for task processing and merging. Specifically, the result uploading module can be used to implement step S330 in the third embodiment and its optional embodiments.

[0182] The seventh embodiment of the present application provides a Kubernetes cluster system, such as Figure 7 As shown, custom resources are registered in the Kubernetes cluster system, and the custom resources include task processing images, task segmentation images, and result merging images;

[0183] The Kubernetes cluster system includes the controller described in the fifth embodiment and several Kubernetes nodes described in the sixth embodiment.

[0184] Figure 8 900 is a schematic structural diagram of a computing device provided in an embodiment of the present application. The computing device can execute each optional embodiment of the above method. The computing device can be a terminal, or a chip or chip system inside the terminal. Figure 8 As shown, the computing device 900 includes: a processor 910 , a memory 920 , and a communication interface 930 .

[0185] It should be understood that Figure 8 The communication interface 930 in the computing device 900 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0186] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit within the processor 910, an external storage unit independent of the processor 910, or a component including both a storage unit within the processor 910 and an external storage unit independent of the processor 910.

[0187] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via a bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0188] It should be understood that in the embodiment of the present application, the processor 910 can adopt a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 910 adopts one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0189] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a non-volatile random access memory. For example, the processor 910 may also store information about the device type.

[0190] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform any operation step of the above method and any optional embodiment thereof.

[0191] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subject in executing the method according to each embodiment of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

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

[0193] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0194] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0195] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0196] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0197] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0198] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the program is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0199] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connection with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0200] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0201] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0202] The computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0203] In addition, the words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0204] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0205] The term "comprising" as used in the specification and claims should not be construed as limiting to what is listed thereafter; it does not exclude other elements or steps. Thus, it should be interpreted as specifying the presence of the features, integers, steps, or components mentioned, but not excluding the presence or addition of one or more other features, integers, steps, or components, or groups thereof. Thus, the expression "a device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0206] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0207] Note that the above are only preferred embodiments of the present application and the technical principles employed. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments and may include many other equivalent embodiments without departing from the scope of protection of the present application, all of which fall within the scope of protection of the present application.

Claims

1. A task scheduling method based on Kubernetes, characterized in that: Applied to a controller, the method includes: Receive task submission requests; Call the user-defined task splitting program interface and split the received task into several subtasks through the task splitting program; Selecting several target nodes that match the task based on the resource status of each Kubernetes node; Dispatching the plurality of subtasks to the corresponding target nodes, so that each target node processes the received subtasks through a task processing program by calling a task processing program interface; Call the user-defined result merging program interface, obtain the processing results of each target node on the subtask through the result merging program, and merge them to obtain the final processing result.

2. The method according to claim 1, characterized in that The step of selecting a plurality of target nodes matching the task based on the resource status of each node of Kubernetes includes: Calculate a comprehensive score for each node based on its resource status, and select a required number of target nodes based on the ranking of the comprehensive scores; wherein the resource status of each node is regularly collected by a node resource collection component, including hardware resource status, network status, and historical task processing results; The comprehensive score is obtained by scoring and weighted calculation based on the hardware resource status, network status and historical task processing results.

3. A task scheduling method based on Kubernetes, characterized in that: Applied to a Kubernetes node, the method includes: Receive a subtask scheduled by the controller; Calling a task processing program interface, and downloading the subtask data from a specified location through the task processing program to perform subtask processing; The processing results of the subtasks are sent to the controller for task processing merging.

4. The method according to claim 3, characterized in that Each Kubernetes node has a node resource collection component, which regularly reports node resources to the controller through the node resource collection component. The node resources include hardware resources, network status and historical task processing results.

5. The method according to claim 3, characterized in that The method further includes: in the process of processing the subtask, reporting the processing progress of the subtask to the controller.

6. A task scheduling method based on Kubernetes, characterized in that: A Kubernetes cluster includes a controller and several Kubernetes nodes; the method includes: The controller receives a task submission request, calls a task splitting program interface, and splits the received task into several subtasks through the task splitting program; The controller selects a plurality of target nodes based on the resource status of each Kubernetes node obtained, and schedules the plurality of subtasks to the corresponding target nodes; The target node calls the task processing program interface, processes the subtask scheduled to the node through the task processing program, obtains the processing result of the subtask, and sends it to the controller; The controller calls the result merging program interface, and merges the received processing results of each target node on each subtask through the result merging program to obtain the final processing result.

7. The method according to claim 6, characterized in that Custom resources are registered in the Kubernetes cluster, including task processing images, task segmentation images, and result merging images. When the controller receives the task submission request, it starts the task splitting program and the result merging program by running the customized task splitting image and result merging image, and exposes the corresponding task splitting interface and result merging interface for the controller to call; The target node starts the task processing program by running the customized task processing image, and exposes the corresponding task processing interface for the target node to call.

8. A Kubernetes controller, characterized in that: include: Task receiving module, used to receive task submission requests; The splitting processing module is used to call the user-defined task splitting program interface to split the received task into several subtasks through the task splitting program; select several target nodes matching the task based on the resource status of each Kubernetes node; and schedule the several subtasks to the corresponding target nodes, so that each target node processes the received subtasks through the task processing program by calling the task processing program interface; The result merging module calls the user-defined result merging program interface, obtains the processing results of each target node on the subtask through the result merging program, and merges them to obtain the final processing result.

9. A Kubernetes node, characterized in that: include: A subtask receiving module, configured to receive a subtask scheduled by the controller; The task processing module is used to call the task processing program interface and download the subtask data from the specified location through the task processing program to perform subtask processing; The result uploading module is used to send the processing results of the subtasks to the controller for task processing merging.

10. A Kubernetes cluster system, characterized in that: The Kubernetes cluster system has custom resources registered therein, including a task processing image, a task segmentation image, and a result merging image. The Kubernetes cluster system includes the controller described in claim 8 and several Kubernetes nodes described in claim 9.

11. A computing device, characterized in that include: processor, and A memory having program instructions stored thereon, wherein the program instructions, when executed by the processor, cause the processor to execute the Kubernetes-based task scheduling method described in any one of claims 1 to 2, or the Kubernetes-based task scheduling method described in any one of claims 3 to 5, or the Kubernetes-based task scheduling method described in any one of claims 6 to 7.

12. A computer-readable storage medium, characterized in that Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer executes the task scheduling method based on Kubernetes described in any one of claims 1 to 2, or the task scheduling method based on Kubernetes described in any one of claims 3-5, or the task scheduling method based on Kubernetes described in any one of claims 6-7.

Images