K8S-based satellite image recognition resource dynamic elastic scheduling system and method

Abstract

The invention provides a K8S-based satellite image recognition resource dynamic elastic scheduling system. The system comprises a task perception module, a resource evaluation module, an elastic scheduling module, a fault tolerance module and a learning optimization module. The task sensing module collects satellite image recognition task metadata and transfers the metadata to a priority label library; the resource evaluation module monitors node resources, quantifies the health degree and screens healthy nodes into a candidate pool; the elastic scheduling module executes Pod dynamic capacity expansion and contraction and other decisions according to tasks and resources; the fault-tolerant module identifies the fault Pod, reconstructs and distributes a new Pod according to an anti-affinity rule; the learning optimization module optimizes the system parameters according to the historical data. The invention also provides a dynamic elastic scheduling method. Therefore, the resource utilization rate and the system stability of the satellite image recognition task are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of satellite image processing technology, and in particular to a dynamic and elastic scheduling system and method for satellite image recognition resources based on K8S. Background Technology

[0002] Current satellite image recognition tasks typically rely on servers with fixed resource configurations or static virtualization clusters, which have significant drawbacks: 1) Low resource utilization: Traditional static allocation cannot adapt to the fluctuating load of image processing tasks, resulting in insufficient resources during peak periods and wasted resources during idle periods; 2) High response latency: Sudden tasks (such as disaster emergency image analysis) require manual intervention to expand capacity, which can take up to several hours; 3) Poor compatibility with heterogeneous environments: Satellite image processing involves a mixture of CPU-intensive (preprocessing) and GPU-intensive (model inference) loads, and existing scheduling strategies are difficult to optimize the allocation of heterogeneous resources.

[0003] Currently available industry solutions include: 1) Amazon AWS's Auto Scaling Group, which supports automatic scaling of virtual machines, but the startup latency is typically 3-5 minutes, failing to meet the timeliness requirements of real-time satellite image processing; 2) Google's Kubernetes Engine default scheduler, which primarily triggers scaling based on CPU and memory usage, lacking optimization support for GPU resources and specific AI task types. Although some research attempts to introduce cloud computing elastic scaling technology, the startup latency of ordinary virtual machines (VMs) and the default Kubernetes scheduling algorithm cannot meet the stringent timeliness and accuracy requirements of satellite image processing.

[0004] Therefore, there is an urgent need for an intelligent scheduling solution that combines load prediction, priority allocation, and elastic scaling. Summary of the Invention

[0005] To address the issues of wasted computing power, task priority conflicts, and service interruptions caused by hardware failures in satellite image recognition tasks within Kubernetes clusters due to rigid resource scheduling, this invention provides a dynamic elastic scheduling system and method for satellite image recognition resources based on Kubernetes. By dynamically sensing task characteristics and node health status, combined with elastic scaling strategies and intelligent fault tolerance mechanisms, it aims to achieve precise matching between computing resources and task requirements.

[0006] To achieve the aforementioned technical effects, on the one hand, this invention provides a dynamic and elastic scheduling system for satellite image recognition resources based on Kubernetes (K8S), comprising a task awareness module, a resource evaluation module, an elastic scheduling module, a fault-tolerant module, and a learning and optimization module; wherein:

[0007] The task awareness module is used to collect metadata of satellite image recognition tasks in real time and convert task features into priority tags and store them in the database; the metadata includes task type, data volume and processing timeliness requirements;

[0008] The resource assessment module is used to monitor and assess the resource status of cluster nodes, quantify the node resource health through a weighted scoring model, and select healthy nodes to be added to the scheduling candidate pool based on the node resource health.

[0009] The elastic scheduling module is used to make dynamic scaling decisions for Pods based on task requirements and resource status; the dynamic scaling decisions for Pods include horizontal scaling, vertical resource optimization, dynamic preemption and resource reclamation, and AI model resource adaptation.

[0010] The fault tolerance module is used to identify faulty Pods through a heartbeat detection mechanism, rebuild Pod instances through a Pod drift mechanism, and allocate new Pods to healthy nodes based on anti-affinity rules;

[0011] The learning optimization module is used to optimize the system configuration parameters of the resource evaluation module and the elastic scheduling module based on historical task execution data.

[0012] Optionally, the weighted scoring model is:

[0013] S i =

[0014] α*GpuScore+β*MemScore+γ*(1-NetworkLatencyNormlized)*100+δ*CpuScore;

[0015] Among them, S i Let GpuScore represent the overall score of node i, GpuScore represent the GPU utilization score, MemScore represent the memory availability score, NetworkLatencyNormlized represent the normalized network latency, CpuScore represent the CPU utilization score, and α, β, γ, and δ represent the weight coefficients that can be dynamically adjusted by the learning optimization module and satisfy α+β+γ+δ=1.0.

[0016] The step of selecting healthy nodes to add to the scheduling candidate pool based on the node resource health includes:

[0017] Nodes whose comprehensive scores exceed a preset score threshold are selected and added to the scheduling candidate pool.

[0018] Optionally, the horizontal scaling of the elastic scheduling module includes:

[0019] Load prediction for a specified future time period based on the ARIMA time series model, wherein the ARIMA time series model is:

[0020]

[0021] Where X(t) is the predicted load at time t. For model parameters, The value range is -1.0 to 1.0; ε(t) is white noise, and p and q are the memory lengths of the signal and noise terms, respectively;

[0022] If the predicted load output based on the ARIMA time series model exceeds the preset expansion threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas.

[0023] If the resource utilization rate falls below the preset scaling-down threshold within a specified period, then the Pod replicas will be reduced and idle nodes will be reclaimed.

[0024] The learning optimization module is used for:

[0025] Analyze historical load data and periodically train the model parameters of the ARIMA time series model.

[0026] Optionally, the vertical resource optimization of the elastic scheduling module includes:

[0027] Guaranteed QoS resources are allocated to Pods that perform high-priority tasks, which are determined based on the priority label.

[0028] Optionally, the dynamic preemption and resource reclamation of the elastic scheduling module includes:

[0029] When cluster resources are insufficient, the PreemptionPolicy mechanism of Kubernetes automatically evicts Pods of low-priority tasks to free up resources for high-priority tasks.

[0030] The evicted Pod saves its intermediate task state to CephFS distributed storage through a checkpointing mechanism, so that it can resume execution when resources are sufficient.

[0031] The eviction and resource reclamation targets are Pods that have been idle for more than 5 minutes, and the amount of reclaimable resources is calculated based on the following formula:

[0032]

[0033] Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and i is the Pod identifier.

[0034] Optionally, the AI ​​model resource adaptation of the elastic scheduling module includes:

[0035] Configure the corresponding resource request parameters according to the image recognition task type;

[0036] The learning optimization module is used for:

[0037] Based on the resource consumption patterns of different types of tasks, a mapping relationship between AI task types and resource requirements is established, so as to optimize the resource request parameter generation strategy based on the mapping relationship.

[0038] Optionally, the fault-tolerant module is specifically used for:

[0039] Periodically send HTTP requests to the Pod via Liveness Prob. If three consecutive requests fail, the Pod is identified as faulty.

[0040] The faulty Pod is automatically rebuilt using the Kubernetes deployment controller, and the rebuilt Pod is assigned to a healthy node using anti-affinity rules.

[0041] Intermediate task states are periodically persisted to distributed storage so that the most recent checkpoint data can be loaded during fault recovery.

[0042] The fault-tolerant module is also configured with a fault domain isolation strategy, which is as follows:

[0043] Based on the Kubernetes topologyKey parameter, Pods of the same service are forced to be deployed to different physical nodes or availability zones.

[0044] Optionally, the learning optimization module is used for:

[0045] Collect comparative data between the scoring results of the resource evaluation module and the actual task execution effect, and optimize the weight coefficients in the weighted scoring model based on the comparative data using the gradient descent algorithm.

[0046] On the other hand, the present invention also provides a dynamic elastic scheduling method based on the above system, comprising the following steps:

[0047] S101. Extract the metadata of the newly created Pod, including resource request parameters and priority tags;

[0048] S102. Calculate the node health score through a weighted scoring model, and select nodes whose node health scores meet the preset requirements to be added to the scheduling candidate pool. If the scheduling candidate pool is empty, trigger the Cluster Autoscaler to apply for a new node.

[0049] S103. Execute scaling up / down decisions based on load forecast results, including:

[0050] If the predicted load exceeds the preset expansion threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas.

[0051] If the resource utilization rate falls below the preset scaling-down threshold within a specified period, then the Pod replicas will be reduced and idle nodes will be reclaimed.

[0052] S104. Identify faulty Pods through a heartbeat detection mechanism, rebuild Pod instances through a Pod drift mechanism, and allocate the new Pods to healthy nodes based on anti-affinity rules;

[0053] S105. Regularly analyze historical task execution data, and optimize and adjust resource evaluation weights, ARIMA model parameters, and resource request strategies based on the analysis results.

[0054] Optionally, step S103 further includes a resource recycling strategy, the resource recycling strategy including:

[0055] Pods that have been idle for more than 5 minutes are marked as recyclable resources;

[0056] The recyclable resources are automatically cleaned up after a configured time using the TTL Controller;

[0057] The formula for calculating the amount of recyclable resources is as follows:

[0058]

[0059] Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and i is the Pod identifier.

[0060] The scenario adaptation mechanism of the method includes:

[0061] Deployed to edge nodes via the K3s lightweight container orchestration system to support local task processing during network outages; or

[0062] By using the Federation API cross-cluster scheduling interface, image processing tasks from different satellites can be incorporated into a unified resource pool for management, in order to support load balancing and data exchange between clusters.

[0063] Compared with the prior art, the present invention has the following beneficial effects:

[0064] (1) Improved resource utilization: Based on the strategy of multi-dimensional feature perception and dynamic weighted evaluation, it can accurately match task requirements and node load status, and improve resource utilization from the average of 40% in traditional solutions to more than 80%, reducing resource idleness by about 60%.

[0065] (2) Reduced task response time: Through a priority-driven elastic scaling mechanism, high-time-sensitivity tasks are guaranteed to receive computing resources first. The average response latency of critical tasks is reduced from minutes (180-300 seconds) to seconds (<10 seconds), meeting the needs of high-time-sensitivity scenarios such as real-time disaster monitoring.

[0066] (3) Enhanced system reliability: The fault-tolerant design effectively reduces the impact of single point failures on the system through fault domain isolation and automated reconstruction mechanisms. The system availability is increased from 99.9% to 99.99%, and the annual downtime is reduced from 8.76 hours to 52.6 minutes.

[0067] (4) Reduced operation and maintenance costs: Intelligent resource management throughout the entire process reduces the need for manual intervention, reducing operation and maintenance manpower costs by about 40%, while supporting the efficient processing of larger-scale concurrent tasks.

[0068] (5) Adaptability and scalability: Through the self-evolution capability of the learning and optimization module, the system can continuously adapt to changes in workload, and the accuracy of scheduling decisions steadily improves. Edge computing and multi-satellite collaboration functions expand the application scenarios of the system and support integrated resource scheduling from the cloud to the edge. Attached Figure Description

[0069] Figure 1 A schematic block diagram of a dynamic and elastic scheduling system for satellite image recognition resources based on K8S provided in an embodiment of the present invention;

[0070] Figure 2 A flowchart illustrating the steps of the dynamic elastic scheduling method provided in an embodiment of the present invention;

[0071] Figure 3 A flowchart of a resource dynamic elastic scheduling method related to a K8S-based satellite image recognition resource dynamic elastic scheduling system provided in an embodiment of the present invention;

[0072] Figure 4 The diagram below illustrates a fault-tolerant mechanism state transition of a dynamic elastic scheduling system for satellite image recognition resources based on K8S, provided as an embodiment of the present invention. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0074] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0075] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function. The terms "comprising" and "including" used throughout the specification and subsequent claims are open-ended and should be interpreted as "including but not limited to." Additionally, the term "connection" here includes any direct and indirect electrical connection means. Indirect electrical connection means include connections made through other means.

[0076] Before describing the embodiments of this application in detail, the technical concept of this application is briefly described first: The Kubernetes-based dynamic elastic scheduling system for satellite image recognition resources provided in this application achieves efficient and reliable task processing through the collaborative efforts of five modules. First, the task awareness module collects task metadata and converts it into priority tags; the resource evaluation module quantifies node health and filters the candidate pool; the elastic scheduling module dynamically scales up and down Pods based on load prediction; the fault tolerance module ensures high availability through heartbeat detection and anti-affinity rules; and the learning optimization module continuously optimizes system parameters based on historical data. The whole system forms a closed-loop mechanism of "perception-evaluation-scheduling-fault tolerance-optimization," achieving accurate resource matching, rapid fault recovery, and adaptive system evolution, significantly improving the efficiency and resource utilization of satellite image recognition.

[0077] The specific principles of the K8S-based dynamic elastic scheduling system for satellite image recognition resources of this application will be described below with reference to specific embodiments.

[0078] Figure 1This invention illustrates a Kubernetes-based dynamic elastic scheduling system 100 for satellite image recognition resources, comprising a task awareness module 10, a resource evaluation module 20, an elastic scheduling module 30, a fault-tolerant module 40, and a learning optimization module 50; wherein:

[0079] The task awareness module 10 is used to collect metadata of satellite image recognition tasks in real time and convert task features into priority tags and store them in the database. The metadata includes task type, data volume, and processing timeliness requirements. The resource evaluation module 20 is used to monitor and evaluate the resource status of cluster nodes, quantify the node resource health through a weighted scoring model, and select healthy nodes to be added to the scheduling candidate pool based on the node resource health. The elastic scheduling module 30 is used to execute dynamic scaling decisions for Pods according to task requirements and resource status. The dynamic scaling decisions for Pods include horizontal scaling, vertical resource optimization, dynamic preemption of resource reclamation, and AI model resource adaptation. The fault tolerance module 40 is used to identify faulty Pods through a heartbeat detection mechanism, rebuild Pod instances through a Pod drift mechanism, and allocate new Pods to healthy nodes based on anti-affinity rules. The learning optimization module 50 is used to optimize the system configuration parameters of the resource evaluation module 20 and the elastic scheduling module 30 based on historical task execution data.

[0080] Kubernetes (K8S) is an open-source container orchestration platform from Google used for automating the deployment, scaling, and management of containerized applications. This embodiment specifically relates to a dynamic and elastic resource scheduling system based on the Kubernetes (K8S) container orchestration platform, particularly suitable for scenarios requiring real-time processing of massive amounts of satellite remote sensing images, such as environmental monitoring, mission reconnaissance, and emergency disaster relief. All functional components mentioned below originate from Kubernetes; a Pod is the smallest deployment unit in K8S, which can be understood as a "logical host that wraps one or more closely related containers." In this embodiment, the carrier for satellite image recognition tasks is a Pod, meaning that each satellite image recognition task (such as disaster monitoring or crop analysis) runs as a Pod.

[0081] This embodiment achieves precise matching of resources and tasks through the collaboration of five major modules.

[0082] The task awareness module 10 is responsible for real-time acquisition of metadata for satellite image recognition tasks, including task type (e.g., object detection, semantic segmentation), data volume (single image resolution, batch size), and processing timeliness requirements (real-time, near real-time, offline). This module interfaces with the Prometheus monitoring component (an open-source monitoring system) through the Kubernetes Custom Metrics Adapter (a Kubernetes extension component used to convert metrics from external monitoring systems into custom metric formats recognizable by the Kubernetes API). It converts task characteristics into priority classes, such as marking disaster emergency tasks as "High" and offline annotation tasks as "Low," and stores these in the Etcd database (Kubernetes' default distributed key-value database) for subsequent scheduling decisions. Simultaneously, the task awareness module 10 dynamically parses Pod resource request parameters (e.g., requests.gpu, limits.memory). When a high-resolution image (e.g., resolution ≥ 2048*2048) is detected, it is automatically marked as a "computation-intensive task," providing input for the resource assessment module.

[0083] Specifically, the weighted scoring model is as follows:

[0084] S i =

[0085] α*GpuScore+β*MemScore+γ*(1-NetworkLatencyNormlized)*100+δ*CpuScore;

[0086] Among them, S i The overall score for node i is represented by a percentage system; GpuScore is the GPU utilization score (the highest score is achieved when the optimal utilization rate is 80% to 100%), MemScore is the memory availability score (the higher the available memory ratio, the higher the score); NetworkLatencyNormlized is the normalized network latency, with a value between 0 and 1, and the higher the latency, the higher the value; CpuScore is the CPU utilization score, with the highest score achieved when the optimal utilization rate is 80% to 100%; α, β, γ, and δ are weight coefficients that can be dynamically adjusted by the learning optimization module 50 and satisfy α+β+γ+δ=1.0; in this embodiment, the initial values ​​of the weight coefficients α, β, γ, and δ are set to 0.5, 0.3, 0.2, and 0.0, respectively. These initial weight values ​​are derived from the analysis of historical execution data of a large number of satellite image recognition tasks, reflecting the dominant role of GPU resources in image recognition and the importance of memory availability.

[0087] The step of selecting healthy nodes to add to the scheduling candidate pool based on the node resource health includes:

[0088] Nodes whose overall score exceeds a preset score threshold are selected and added to the scheduling candidate pool. For example, if the preset score threshold is 80 points, when the overall score S of a node i exceeds a preset score threshold... i Nodes scoring above 80 are marked as "healthy nodes" and added to the scheduling candidate pool. Further, when node i's score S... i If three consecutive cycles are all below 60 points, an alarm will be triggered and new task scheduling will be prohibited.

[0089] In this embodiment, the resource evaluation module 20 periodically (e.g., every 30 seconds) updates the node status to ensure that scheduling decisions are based on the latest resource data.

[0090] Furthermore, the learning optimization module 50 is used to: collect comparative data between the scoring results of the resource evaluation module 20 and the actual task execution effect, and optimize the weight coefficients in the weighted scoring model based on the comparative data using the gradient descent algorithm. That is, the learning optimization module optimizes the weight coefficients α, β, γ, and δ based on the collected comparative data.

[0091] In an optional implementation, the horizontal scaling of the elastic scheduling module 30 includes:

[0092] Load prediction for a specified future time period based on the ARIMA time series model, wherein the ARIMA time series model is: Where X(t) is the predicted load at time t. For model parameters, The value range is -1.0 to 1.0; ε(t) represents white noise, and p and q are the memory lengths of the signal and noise terms, respectively. If the predicted load output based on the ARIMA time series model exceeds the preset scaling threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas. If the resource utilization rate is lower than the preset scaling-down threshold for a specified period, the Pod replicas are reduced and idle nodes are reclaimed. For example, horizontal scaling is based on the ARIMA time series model to predict resource demand in the next 5 minutes. If the predicted value exceeds 120% of the current resource capacity (i.e., the preset scaling-up threshold is 120%), the HPA (Horizontal Pod Autoscaler) is triggered to expand the number of Pod replicas. If the resource utilization rate is lower than 40% for three consecutive periods (i.e., the preset scaling-down threshold is 40%), the Pods are scaled down and the Cluster Autoscaler (a type of Kubernetes cluster autoscaler) is notified to reclaim idle nodes. Figure 3 As shown.

[0093] Furthermore, the learning optimization module 50 is used to analyze historical load data and periodically train the model parameters of the ARIMA time series model. In specific implementation, the learning optimization module 50 analyzes historical load data and periodically (e.g., every 24 hours) retrains the ARIMA model parameters to improve the accuracy of load prediction.

[0094] In an optional implementation, the vertical resource optimization of the elastic scheduling module 30 includes:

[0095] Guaranteed QoS resources are allocated to Pods executing high-priority tasks, which are determined based on the priority tags. This embodiment optimizes the computation by allocating Guaranteed QoS resources (e.g., limits.cpu = requests.cpu = 4) to high-priority Pods, ensuring the computational stability of critical tasks. Resource quotas range from 1 to 32 CPU cores, 1 to 128 GB of memory, and 1 to 8 GPUs.

[0096] In an optional implementation, the dynamic preemption and resource reclamation of the elastic scheduling module 30 includes:

[0097] When cluster resources are insufficient (i.e., the available resources of all nodes in the cluster (such as CPU, GPU, memory, etc.) cannot meet the resource requirements of the current or newly submitted satellite image recognition task, resulting in the task being unable to be scheduled or run normally), based on Kubernetes' PreemptionPolicy mechanism, Pods of low-priority tasks (such as offline annotation) are automatically evicted to release resources for high-priority tasks (such as real-time disaster monitoring). The priority of a task is determined based on a priority value, which in this embodiment ranges from 0 to 10000. The evicted Pod saves the intermediate state of the task to CephFS (a distributed file system component of the Ceph storage system) through a checkpoint mechanism, so that it can resume execution when resources are sufficient. That is, when insufficient cluster resources are detected, the dynamic priority preemption policy evicts low-priority Pods (such as offline annotation tasks) based on PriorityClass (a resource object in Kubernetes used to define Pod priorities), releases resources for high-priority tasks, and saves the state of the evicted task to a persistent storage volume (PVC) through a checkpoint, so that it can be automatically restored when resources are sufficient.

[0098] The eviction and resource reclamation targets Pods that have been idle for more than 5 minutes, and the amount of reclaimable resources is calculated based on the following formula:

[0099]

[0100] Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and i is the Pod identifier.

[0101] In an optional implementation, the AI ​​model resource adaptation of the elastic scheduling module 30 includes:

[0102] Based on the image recognition task type, corresponding resource request parameters are configured. This embodiment's AI model resource adaptation strategy configures differentiated resource request parameters for different types of image recognition tasks. For example, object detection models (such as YOLO and Faster R-CNN) are prioritized for GPU resource allocation; image preprocessing processes are prioritized for CPU resource allocation; semantic segmentation models (such as U-Net) have higher memory requirements, so higher memory requests (a key parameter in Kubernetes used to declare memory resource requirements for Pods) values ​​will be set.

[0103] Furthermore, the learning optimization module 50 is used to: establish a mapping relationship between AI task types and resource requirements based on the resource consumption patterns of different types of tasks, so as to optimize the resource request parameter generation strategy based on the mapping relationship.

[0104] The fault-tolerant module 40 is specifically used for:

[0105] Periodically (e.g., every 30 seconds), HTTP requests are sent to the Pod via Liveness Prob. If three consecutive requests fail, the Pod is identified as faulty. The faulty Pod is automatically rebuilt by the Kubernetes deployment controller, and the rebuilt Pod is assigned to a healthy node through anti-affinity rules. The intermediate task status is periodically persisted to distributed storage so that the most recent checkpoint data is loaded when the fault is recovered.

[0106] Furthermore, the fault tolerance module 40 is also configured with a fault domain isolation strategy, which is: based on the Kubernetes topologyKey parameter, Pods of the same service are forced to be deployed to different physical nodes or availability zones.

[0107] See Figure 4In this embodiment, the fault-tolerant module 40 ensures high system availability through multi-level fault domain isolation and automated recovery mechanisms. The fault domain isolation strategy is based on Kubernetes topologyKey parameters (key parameters in Kubernetes affinity / anti-affinity rules and fault domain isolation strategies, such as kubernetes.io / hostname, kubernetes.io / zone), forcing Pods with the same service to be deployed across different physical nodes or availability zones, preventing single-point failures from causing service outages. Pod health status is checked every 30 seconds using the Liveness Probe (Kubernetes mechanism for detecting whether containers are running healthily). If three consecutive checks fail, the Pod is identified as faulty, triggering the DeploymentController (Kubernetes deployment controller) to automatically rebuild the instance. During rebuilding, the scheduler allocates new Pods to healthy nodes according to anti-affinity rules (podAntiAffinity), and simultaneously loads the most recent checkpoint data from distributed storage (such as CephFS or MinIO) to ensure rapid recovery after task interruption.

[0108] Preferably, the intermediate task state is persisted every 60 seconds. Combined with the cross-node drift mechanism, even if a rack-level failure occurs, the service can still be restored through nodes in other availability zones, keeping the service interruption time within 10 seconds.

[0109] The learning optimization module 50 continuously optimizes key system parameters by collecting and analyzing historical task execution data, thus achieving self-evolution; thereby adapting to constantly changing workload characteristics and continuously improving scheduling efficiency.

[0110] In practice, System 100 is deployed on the Kubernetes cluster control plane; the cluster nodes are divided into management nodes (Master) and worker nodes (Worker), and all modules interact with the Etcd database through the Kubernetes API Server; the interaction steps of each module are as follows:

[0111] 1. Deploy the Kubernetes cluster and initialize core components. Install the Prometheus monitoring system on the management node (Master), configure custom metric collection rules, including node GPU utilization (node_gpu_utilization), available memory percentage (node_memory_available), cross-node network latency (node_network_latency), with a time granularity set to 10 seconds, and CPU utilization (node_cpu_utilization).

[0112] 2. Integrate Task Awareness Module 10. Listen for Pod creation events through the Kubernetes API Server extension plugin and configure the Etcd database to store task metadata (such as task type, image resolution, and priority tags). For example, when a Pod tag containing `task-type:disaster-monitoring` is detected, it is automatically associated with `PriorityClass:High`.

[0113] III. Deploy Resource Assessment Module 20. Install the Scheduler Framework Plugin, register it with the Kubernetes scheduler chaining process, and configure the initial weight parameters (α = 0.5, β = 0.3, γ = 0.2) and scoring threshold (healthy node S) of the weighted scoring model. i ≥80, unhealthy node S i <60).

[0114] IV. Configure the elastic scheduling module 30. Enable Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) in the Kubernetes cluster and bind them to the ARIMA prediction model parameter training service; predefine scaling up and down trigger conditions (scaling up when the load prediction value is >120% and scaling down when the utilization is <40%).

[0115] 5. Deploy the fault tolerance module 40. Configure the CephFS distributed storage cluster and set up a PVC template for checkpoint data persistence. Define anti-affinity rules in the Pod template, for example: topologyKey:kubernetes.io / hostname.

[0116] VI. Integrated Learning Optimization Module 50. The specific execution steps of Learning Optimization Module 50 are as follows:

[0117] Collect comparative data between the scoring results of the resource assessment module and the actual task execution effect, and optimize the weight coefficients (α, β, γ, δ) in the scoring formula through the gradient descent algorithm;

[0118] Analyze historical load data and retrain ARIMA model parameters periodically (every 24 hours by default) to improve load prediction accuracy;

[0119] Based on the resource consumption patterns of different types of tasks, a mapping relationship between AI task types and resource requirements is established, and the resource request parameter generation strategy is optimized.

[0120] Corresponding to the above embodiments, in another embodiment of the present invention, a dynamic elastic scheduling method based on the system 100 described in the above embodiments is also provided, such as... Figure 2 As shown, the steps include:

[0121] S101: Extract metadata from the newly created Pod, including resource request parameters and priority tags; the user submits a satellite image recognition task; declare resource requests (e.g., requests.gpu:1, limits.memory:8Gi) and priority tags (e.g., priorityClass:High) in the Pod template. The task awareness module 10 extracts task metadata (e.g., image resolution, batch size), and marks it as compute-intensive:"true" when the resolution is ≥2048*2048.

[0122] In practice,

[0123] By monitoring newly created Pods through the Kubernetes API Server, their resource requests (e.g., requests.gpu=1) and priority tags are extracted and written to a Redis cache for querying by the resource evaluation module. For example, the metadata JSON format of an object detection task Pod is as follows:

[0124] {

[0125] "task_id":"detect-001",

[0126] "priority":"High",

[0127] "gpu_required":1,

[0128] "deadline":"2025-04-09T17:00:00Z",

[0129] "image_resolution":"2048*2048",

[0130] "model_type":"object_detection"

[0131] }

[0132] S102: Calculate the node health score using a weighted scoring model, and select nodes whose health scores meet the preset requirements to add to the scheduling candidate pool. If the scheduling candidate pool is empty, trigger the Cluster Autoscaler to apply for a new node. The formula for the weighted scoring model is described in the above embodiment. When the node score calculated based on the formula of the weighted scoring model is ≥80, the corresponding node is added to the scheduling candidate pool. If the scheduling candidate pool is empty, trigger the Cluster Autoscaler to apply for a new node.

[0133] S103: Execute scaling up / down decisions based on load forecast results, including:

[0134] If the load forecast exceeds the preset expansion threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas; if the resource utilization is lower than the preset shrinkage threshold within a specified period, the number of Pod replicas is reduced and idle nodes are reclaimed.

[0135] Specifically, when the elastic scheduling module 30 executes scaling decisions, it calls the ARIMA model to predict the load for the next 5 minutes. The formula for the ARIMA model is as follows:

[0136]

[0137] Among them, parameters θ1 = 0.4 was obtained through training with historical data.

[0138] If the predicted value exceeds 120% of the current resources, HPA will be triggered to expand the number of Pod replicas (e.g., from 3 to 4); if the utilization rate is less than 40% for 3 consecutive cycles, the Pod will be scaled down and the node will be reclaimed.

[0139] Step S103 further includes a resource recycling strategy, which includes:

[0140] Pods that have been idle for more than 5 minutes are marked as reclaimable resources; these reclaimable resources are automatically cleaned up after a configured time (e.g., 10 minutes) via the TTL Controller;

[0141] The formula for calculating recyclable resources is:

[0142]

[0143] Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and i is the Pod identifier.

[0144] This involves using the elastic scheduling module 30 to perform dynamic priority preemption and resource reclamation. When resources are insufficient, low-priority Pods (such as priorityClass:Low) are evicted according to the PreemptionPolicy, releasing resources for high-priority tasks. The state of the evicted Pods is saved to CephFS through checkpoints, and the amount of reclaimable resources is recorded.

[0145] S104: A heartbeat detection mechanism identifies faulty Pods, and a Pod instance is rebuilt using a Pod drift mechanism. The new Pod is then assigned to a healthy node based on anti-affinity rules. Specifically, node failures are handled by fault tolerance module 40. When LivenessProbe fails three consecutive times (with a 30-second interval), the Pod is marked as faulty, triggering the Deployment Controller to rebuild the instance on a healthy node. The new Pod loads checkpoint data recovery tasks from CephFS, ensuring an interruption time of less than 10 seconds.

[0146] S105: Regularly analyze historical task execution data, and optimize and adjust resource evaluation weights, ARIMA model parameters, and resource request strategies based on the analysis results.

[0147] The method is also applicable to edge computing and multi-satellite collaboration scenarios:

[0148] Edge computing adaptation: Deployed to resource-constrained edge nodes through the K3s lightweight container orchestration system, using resource reservation strategies (such as kube-reserved) to ensure system stability and support local task processing in offline states.

[0149] Multi-satellite collaborative scenario: Through cross-cluster scheduling via the Federation API, image processing tasks from different satellites are uniformly incorporated into resource pool management, supporting load balancing and data exchange between clusters.

[0150] The method in this embodiment also supports adaptation to different container orchestration platforms, for example:

[0151] Docker Swarm Adaptation: Through the service discovery and transformation mechanism, the concepts of Kubernetes Deployment and Service are mapped to Swarm Stack and Service to achieve cross-platform resource scheduling;

[0152] OpenShift Adaptation: Utilizes OpenShift's DeploymentConfig and Route resources to replace the native K8S Deployment and Ingress, while maintaining consistency in core scheduling logic.

[0153] This invention further optimizes the long-term operational economy of infrastructure through adaptive load prediction and idle resource reclamation mechanisms, providing a highly available, low-latency, elastic computing solution for the satellite image processing field. As shown in Table 1 below, practical application tests demonstrate that compared to traditional static allocation schemes, this system can support more than three times the task concurrency while reducing the total cost of ownership of infrastructure by 25%.

[0154] Table 1:

[0155] Performance Comparison Traditional methods This embodiment Comparison of resource utilization rates 40％ 80％ Task response time comparison 180～300s <10s

[0156] In summary, the dynamic elastic scheduling system and method for satellite image recognition resources based on Kubernetes (K8S) provided by this invention aims to solve the problems of rigid resource allocation, high response latency, and low utilization of computing resources in traditional satellite image processing. This system integrates K8S container orchestration technology to achieve automated resource scheduling and elastic scaling for satellite image recognition tasks. The method includes: real-time monitoring of the resource requirements (such as CPU, GPU, and memory) and task queue status of satellite image recognition tasks; predicting future load trends based on time series prediction models (such as ARIMA); and evaluating current resource utilization and task priority using fuzzy logic algorithms to dynamically adjust the number of Pod replicas and node resource quotas in the K8S cluster. The core modules of this system include: 1) a task awareness module, which collects task type, data volume, and processing timeliness requirements; 2) a resource assessment module, which quantifies node resource health through a weighted scoring model; 3) an elastic scheduling module, which automatically triggers Horizontal Pod Autoscaler (HPA) or Cluster Autoscaler (CA) to achieve resource scaling based on policies; 4) a fault tolerance module, which ensures high availability through heartbeat detection and Pod drift mechanisms; and 5) a learning optimization module, which continuously optimizes system parameters through historical execution data. Therefore, this invention has the following beneficial effects: 1) It improves the processing efficiency of satellite image recognition tasks by more than 50% and increases resource utilization by approximately 40%; 2) It supports second-level response (<10 seconds) for sudden task loads; 3) It is compatible with heterogeneous computing environments (such as edge node and cloud collaboration), and is suitable for scenarios such as remote sensing monitoring and disaster early warning.

[0157] This invention can be implemented on a computer as a computer-based method, or in dedicated hardware, or a combination of both. Executable code or portions thereof for the method according to the invention can be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Optionally, the computer program product includes non-transitory program code components stored on a computer-readable medium so as to execute the method according to the invention when the program product is executed on a computer.

[0158] In an optional embodiment, the computer program includes computer program code components adapted to perform all the steps of the method according to the invention when the computer program is run on a computer. Optionally, the computer program is embodied on a computer-readable medium.

[0159] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0160] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A dynamic and elastic scheduling system for satellite image recognition resources based on Kubernetes, characterized in that, It includes a task awareness module, a resource assessment module, an elastic scheduling module, a fault tolerance module, and a learning optimization module; among which: The task awareness module is used to collect metadata of satellite image recognition tasks in real time and convert task features into priority tags and store them in the database; the metadata includes task type, data volume and processing timeliness requirements; The resource assessment module is used to monitor and assess the resource status of cluster nodes, quantify the node resource health through a weighted scoring model, and select healthy nodes to be added to the scheduling candidate pool based on the node resource health. The elastic scheduling module is used to make dynamic scaling decisions for Pods based on task requirements and resource status; the dynamic scaling decisions for Pods include horizontal scaling, vertical resource optimization, dynamic preemption and resource reclamation, and AI model resource adaptation. The fault tolerance module is used to identify faulty Pods through a heartbeat detection mechanism, rebuild Pod instances through a Pod drift mechanism, and allocate new Pods to healthy nodes based on anti-affinity rules; The learning optimization module is used to optimize the system configuration parameters of the resource evaluation module and the elastic scheduling module based on historical task execution data.

2. The system according to claim 1, characterized in that, The weighted scoring model is as follows: S i ＝ α*GpuScore+β*MemScore+γ*(1-NetworkLatencyNormlized)*100+δ*CpuScore; Among them, S i Let GpuScore represent the overall score of node i, GpuScore represent the GPU utilization score, MemScore represent the memory availability score, NetworkLatencyNormlized represent the normalized network latency, CpuScore represent the CPU utilization score, and α, β, γ, and δ represent the weight coefficients that can be dynamically adjusted by the learning optimization module and satisfy α+β+γ+δ=1.

0. The step of selecting healthy nodes to add to the scheduling candidate pool based on the node resource health includes: Nodes whose comprehensive scores exceed a preset score threshold are selected and added to the scheduling candidate pool.

3. The system according to claim 1, characterized in that, The horizontal scaling of the elastic scheduling module includes: Load prediction for a specified future time period based on the ARIMA time series model, wherein the ARIMA time series model is: Where X(t) is the predicted load at time t. For model parameters, The value range is -1.0 to 1.0; ε(t) is white noise, and p and q are the memory lengths of the signal and noise terms, respectively; If the predicted load output based on the ARIMA time series model exceeds the preset expansion threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas. If the resource utilization rate falls below the preset scaling-down threshold within a specified period, then the Pod replicas will be reduced and idle nodes will be reclaimed. The learning optimization module is used for: Analyze historical load data and periodically train the model parameters of the ARIMA time series model.

4. The system according to claim 1, characterized in that, The vertical resource optimization of the elastic scheduling module includes: Guaranteed QoS resources are allocated to Pods that perform high-priority tasks, which are determined based on the priority label.

5. The system according to claim 1, characterized in that, The dynamic preemption and resource reclamation of the elastic scheduling module includes: When cluster resources are insufficient, the PreemptionPolicy mechanism of Kubernetes automatically evicts Pods of low-priority tasks to free up resources for high-priority tasks. The evicted Pod saves its intermediate task state to CephFS distributed storage through a checkpointing mechanism, so that it can resume execution when resources are sufficient. The eviction and resource reclamation targets are Pods that have been idle for more than 5 minutes, and the amount of reclaimable resources is calculated based on the following formula: Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and i is the Pod identifier.

6. The system according to claim 1, characterized in that, The AI ​​model resource adaptation of the elastic scheduling module includes: Configure the corresponding resource request parameters according to the image recognition task type; The learning optimization module is used for: Based on the resource consumption patterns of different types of tasks, a mapping relationship between AI task types and resource requirements is established, so as to optimize the resource request parameter generation strategy based on the mapping relationship.

7. The system according to claim 1, characterized in that, The fault-tolerant module is specifically used for: Periodically send HTTP requests to the Pod via Liveness Prob. If three consecutive requests fail, the Pod is identified as faulty. The faulty Pod is automatically rebuilt using the Kubernetes deployment controller, and the rebuilt Pod is assigned to a healthy node using anti-affinity rules. Intermediate task states are periodically persisted to distributed storage so that the most recent checkpoint data can be loaded during fault recovery. The fault-tolerant module is also configured with a fault domain isolation strategy, which is as follows: Based on the Kubernetes topologyKey parameter, Pods of the same service are forced to be deployed to different physical nodes or availability zones.

8. The system according to claim 1, characterized in that, The learning optimization module is used for: Collect comparative data between the scoring results of the resource evaluation module and the actual task execution effect, and optimize the weight coefficients in the weighted scoring model based on the comparative data using the gradient descent algorithm.

9. A dynamic elastic scheduling method based on the system described in any one of claims 1 to 8, characterized in that, Including the following steps: S101. Extract the metadata of the newly created Pod, including resource request parameters and priority tags; S102. Calculate the node health score through a weighted scoring model, and select nodes whose node health scores meet the preset requirements to be added to the scheduling candidate pool. If the scheduling candidate pool is empty, trigger the Cluster Autoscaler to apply for a new node. S103. Execute scaling up / down decisions based on load forecast results, including: If the predicted load exceeds the preset expansion threshold of the current resource capacity, the HPA mechanism is triggered to expand the number of Pod replicas. If the resource utilization rate falls below the preset scaling-down threshold within a specified period, then the Pod replicas will be reduced and idle nodes will be reclaimed. S104. Identify faulty Pods through a heartbeat detection mechanism, rebuild Pod instances through a Pod drift mechanism, and allocate the new Pods to healthy nodes based on anti-affinity rules; S105. Regularly analyze historical task execution data, and optimize and adjust resource evaluation weights, ARIMA model parameters, and resource request strategies based on the analysis results.

10. The method according to claim 9, characterized in that, Step S103 further includes a resource recycling strategy, which includes: Pods that have been idle for more than 5 minutes are marked as recyclable resources; The recyclable resources are automatically cleaned up after a configured time using the TTL Controller; The formula for calculating the amount of recyclable resources is as follows: Where I() is the indicator function, which is 1 when the condition is met and 0 otherwise; Idle_Minutes i >5 indicates that the device has been idle for more than 5 minutes, and 'i' is the Pod identifier; The scenario adaptation mechanism of the method includes: Deployed to edge nodes via the K3s lightweight container orchestration system to support local task processing during network outages; or By using the Federation API cross-cluster scheduling interface, image processing tasks from different satellites can be incorporated into a unified resource pool for management, in order to support load balancing and data exchange between clusters.

Images