A method and system for autonomous container orchestration on a satellite with layered self-healing capability, a terminal device and a storage medium

Abstract

The application discloses a layered self-recovery-capable on-satellite autonomous container arrangement method and system, terminal equipment and a storage medium, and relates to the technical field of on-satellite container arrangement. The method comprises the following steps: receiving a high-order application description file, analyzing a deployment intention, making a scheduling decision, and deploying a container to a target working node; monitoring the running state of the container and the working node in real time; triggering cluster-level elastic scaling when a global load is abnormal, triggering container-level fault recovery when a single container process is abnormal, and triggering node-level fault migration when a working node is out of connection or fails. Through the three-layered self-recovery mechanism, the application realizes autonomous arrangement and differentiated and rapid recovery of faults of on-satellite containers, does not need to rely on real-time ground instructions, solves the problem of container arrangement failure when a satellite-ground link is interrupted, and improves the resource utilization rate and task reliability of a low-orbit satellite constellation.

Description

Technical Field

[0001] This invention relates to the field of on-board container orchestration technology, and in particular to an on-board autonomous container orchestration method, system, terminal device and storage medium with layered self-healing capability. Background Technology

[0002] As the complexity of low-Earth orbit satellite constellation services increases, the traditional static deployment of onboard software and centralized ground management model faces enormous challenges.

[0003] The main drawbacks of existing technologies are: application deployment, scaling up and down, and fault recovery heavily rely on real-time commands from ground stations; communication interruptions of the satellite-to-ground link lasting several hours will directly lead to the loss of service capabilities; on-board computing and storage resources are fixedly allocated and cannot be dynamically scheduled according to the load, resulting in low resource utilization; on-board systems are mostly single-point or cold backup architectures, lacking seamless fault migration capabilities.

[0004] While Kubernetes and other container orchestration platforms for terrestrial cloud computing can solve the problem of elastic scaling, they rely on stable networks and ground infrastructure. Direct deployment on satellites faces technical bottlenecks such as orchestration failure when the satellite-to-ground link is interrupted, failure to consider special satellite factors such as satellite orbit and energy, and extremely high operational complexity.

[0005] Most existing onboard container orchestration solutions only achieve simple deployment and lack layered self-healing capabilities, failing to balance fault recovery speed and system stability. Therefore, there is an urgent need for an onboard autonomous container orchestration method with layered self-healing capabilities to fill the gaps in existing technologies. Summary of the Invention

[0006] The technical problem this invention aims to solve is that, in the field of low-Earth orbit satellite constellation container orchestration, existing technologies heavily rely on real-time ground commands for container scheduling and fault recovery. When the satellite-to-ground link is interrupted, system service capabilities are lost. Furthermore, these technologies fail to consider unique onboard factors such as satellite orbital position, energy status, and inter-satellite link quality, resulting in insufficient onboard autonomy, low resource utilization, and delayed fault recovery. Therefore, an effective solution is urgently needed to achieve autonomous onboard container orchestration and hierarchical differentiated self-healing without relying on real-time ground commands, thereby resolving the aforementioned technical problems.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides an on-board autonomous container orchestration method with layered self-healing capabilities, applicable to a low-Earth orbit satellite constellation composed of multiple satellite nodes, the method comprising: Receive high-level application description files, parse application deployment intent, and obtain real-time status information of each satellite node in the constellation; Based on the application deployment intent and the real-time status information, a scheduling decision is made to deploy the container to the target worker node; Real-time monitoring of container running status and worker node running status on each worker node; When an abnormal global load is detected, the first-level cluster-level elastic scaling is triggered to adjust the number of container replicas. When an anomaly is detected in a single container process, a second-level container-level fault recovery is triggered to rebuild the abnormal container; When a worker node is detected to be disconnected or malfunctioning, a third-level node-level fault migration is triggered to migrate the containers on the faulty worker node to other healthy worker nodes. The scheduling decisions and the triggering of self-healing at each layer are all executed autonomously on the satellite.

[0008] In one implementation, the real-time status information includes at least one of the following: the orbital position of the satellite node, its energy status, its load status, and the quality of the inter-satellite link.

[0009] In one implementation, triggering first-layer cluster-level elastic scaling to adjust the number of container replicas when an abnormal global load is detected includes: When the load on a worker node exceeds the preset expansion threshold, increase the number of container replicas. When the load on a worker node is detected to be lower than the preset scaling-down threshold, the number of container replicas is reduced. During scaling up or down, containers are prioritized for scheduling to working nodes whose orbital positions and / or inter-satellite link quality meet preset conditions.

[0010] In one implementation, the step of triggering a second-level container-level fault recovery and rebuilding the abnormal container when an anomaly is detected in a single container process includes: For stateful containers, the stateful container persists its state data to a persistent volume during operation; When an anomaly is detected in the process of the stateful container, the original container is destroyed and a new container is rebuilt, and the rebuilt container is mounted to the persistent volume. The consistency of the state data in the persistent volume is checked, and the container's running state is restored based on the state data that passes the check.

[0011] In one implementation, the step of triggering a second-level container-level fault recovery and rebuilding the abnormal container when an anomaly is detected in a single container process includes: For stateless containers, when an anomaly is detected in the stateless container process, the stateless container is destroyed and a new container is created.

[0012] In one implementation, when a worker node is detected to be disconnected or malfunctioning, triggering a third-layer node-level fault migration to migrate containers on the faulty worker node to other healthy worker nodes includes: Determine the target healthy worker node to take over the container on the failed worker node; The target healthy working node obtains the image data corresponding to the container from the image cache of other satellite nodes in the low-Earth orbit satellite constellation through the inter-satellite point-to-point network; The container is rebuilt on the target healthy worker node based on the acquired image data.

[0013] In one implementation, the method further includes: Detect the storage capacity of the persistent volume; When the storage capacity of the persistent volume reaches a preset cleanup threshold, long-term inaccessible data that meets preset conditions is filtered out. Perform a deletion operation on the filtered data that has not been accessed for a long time.

[0014] Secondly, embodiments of the present invention also provide an on-board autonomous container orchestration system with hierarchical self-healing capabilities, applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes. The multiple satellite nodes include at least one control node and multiple working nodes. Each working node deploys a container runtime and a point-to-point image cache agent. The point-to-point image cache agents of each working node constitute an inter-satellite point-to-point image distribution network. The system includes: The deployment intent and status acquisition module is used to receive high-level application description files, parse application deployment intent, and obtain real-time status information of each satellite node in the constellation. The container deployment module is used to make scheduling decisions based on the application deployment intent and the real-time status information, and to deploy the container to the target worker node. The runtime status monitoring module is used to monitor the container runtime status and the runtime status of each worker node in real time. The elastic scaling module is used to trigger the first-level cluster-level elastic scaling when an abnormal global load is detected, and adjust the number of container replicas. The container recovery module is used to trigger a second-level container-level fault recovery and rebuild the abnormal container when an anomaly is detected in a single container process. The node migration module is used to trigger a third-level node-level fault migration when a worker node is detected to be disconnected or malfunctioning, and to migrate the containers on the malfunctioning worker node to other healthy worker nodes. The scheduling decisions and the triggering of self-healing at each layer are all executed autonomously on the satellite.

[0015] Thirdly, embodiments of the present invention also provide a terminal device, the terminal device including a memory, a processor, and an on-board autonomous container orchestration program with layered self-healing capability stored in the memory and executable on the processor. When the processor executes the on-board autonomous container orchestration program with layered self-healing capability, it implements the steps of the on-board autonomous container orchestration method with layered self-healing capability as described in any of the above schemes.

[0016] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing an on-board autonomous container orchestration program with hierarchical self-healing capabilities. When the on-board autonomous container orchestration program with hierarchical self-healing capabilities is executed by a processor, it implements the steps of the on-board autonomous container orchestration method with hierarchical self-healing capabilities as described in any of the above schemes.

[0017] Beneficial Effects: This invention discloses an on-board autonomous container orchestration method, system, terminal device, and storage medium with layered self-healing capabilities, relating to the field of on-board container orchestration technology. The method is applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes. First, it receives a high-order application description file, parses the application deployment intent, and obtains the real-time status information of each satellite node in the constellation. Then, based on the application deployment intent and the real-time status information, it makes scheduling decisions to deploy containers to target worker nodes. Next, it monitors the container running status and worker node running status of each worker node in real time. When a global load anomaly is detected, it triggers the first layer of cluster-level elastic scaling, adjusting the number of container replicas; when a single container process anomaly is detected, it triggers the second layer of container-level fault recovery, rebuilding the abnormal container; when a worker node is detected to be disconnected or faulty, it triggers the third layer of node-level fault migration, migrating containers on the faulty worker node to other healthy worker nodes. The scheduling decisions and the triggering of each layer of self-healing are all executed autonomously on-board.

[0018] This invention employs a three-tiered self-healing mechanism—cluster-level elastic scaling, container-level fault recovery, and node-level fault migration—to classify and handle faults according to their severity, achieving differentiated and rapid self-healing ranging from second-level in-situ container recovery to minute-level cross-node migration. Simultaneously, all scheduling decisions and self-healing triggers are executed autonomously on-board, without relying on real-time ground commands. This effectively overcomes the container orchestration failure problem caused by intermittent satellite-to-ground links, significantly improving the mission reliability and resource utilization of low-Earth orbit satellite constellations and reducing the operational complexity of large-scale constellations. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a specific implementation of the on-board autonomous container orchestration method with layered self-healing capabilities provided in this embodiment of the invention.

[0020] Figure 2A schematic diagram of a low-Earth orbit satellite constellation architecture for the application of the on-board autonomous container orchestration method with layered self-healing capability provided in an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram of the multi-layer self-healing process of the on-board autonomous container orchestration method with layered self-healing capability provided in an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram illustrating the elastic scaling process of an on-board autonomous container orchestration method with layered self-healing capabilities, provided in an embodiment of the present invention.

[0023] Figure 5 This is a schematic diagram of the stateful container recovery process of the on-board autonomous container orchestration method with hierarchical self-healing capability provided in an embodiment of the present invention.

[0024] Figure 6 This is a schematic diagram illustrating the node migration process of the on-board autonomous container orchestration method with hierarchical self-healing capability provided in an embodiment of the present invention.

[0025] Figure 7 This is a schematic diagram of the technical closed-loop process of the on-board autonomous container orchestration method with layered self-healing capability provided in an embodiment of the present invention.

[0026] Figure 8 This is a schematic diagram of the on-board autonomous container orchestration device with layered self-healing capability provided in an embodiment of the present invention.

[0027] Figure 9 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, 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 of the invention and are not intended to limit the invention.

[0029] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0030] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0031] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0032] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0033] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0034] With the rapid development of low-Earth orbit satellite constellation technology, the services carried by satellites are becoming increasingly complex. The traditional on-board mission deployment and management model, which usually adopts on-board software static deployment and ground centralized management, is facing huge challenges and can no longer meet the needs of large-scale, highly reliable, and highly flexible services.

[0035] The existing technologies mainly have the following problems: (1) Severe dependence on ground: Application deployment, updates, scaling up and down and fault recovery heavily depend on ground station contact. When the satellite in orbit cannot communicate with the ground for several hours, the system service capability is interrupted or degraded; (2) Low resource utilization: On-board computing and storage resources are fixedly allocated and cannot be dynamically scheduled according to the task load, resulting in idle or overloaded resources; (3) Insufficient availability and elasticity: Most existing on-board systems are single-point or cold backup architectures, which cannot achieve seamless fault migration and recovery of services. The overall reliability of the system is constrained by single-point failures; (4) High operation and maintenance complexity: The software life cycle management (deployment, monitoring, and upgrade) of large-scale constellations is carried out one by one through ground commands, which is inefficient and prone to errors.

[0036] While container orchestration platforms such as Kubernetes (K8S) used in terrestrial cloud computing have solved the problems of elastic scaling and high availability, their design relies on stable networks and continuous ground infrastructure. Deploying terrestrial K8S directly on satellites faces numerous technical bottlenecks. First, terrestrial K8S depends on real-time ground command scheduling; interruptions in the satellite-to-ground link can cause container orchestration to fail, making autonomous operation and maintenance on satellite impossible. Second, terrestrial K8S does not consider special on-satellite factors such as satellite orbital position, energy status, and inter-satellite link quality, resulting in unreasonable resource scheduling and low overall constellation resource utilization. Third, the complexity of ground operation and maintenance for large-scale constellations is extremely high; ground personnel cannot effectively manage the container deployment and lifecycle of each satellite in real time, leading to a surge in operation and maintenance costs.

[0037] In existing technologies, there are few solutions for on-board container orchestration, and most of them fail to address the aforementioned core issues. Some solutions only achieve simple container deployment and lack self-healing capabilities, failing to guarantee autonomous recovery after container or node failures; some solutions rely on ground commands for scheduling and self-healing, resulting in insufficient on-board autonomy; and some solutions are not optimized for the characteristics of limited on-board resources and unstable links, leading to slow container startup, significant resource waste, and a lack of layered self-healing, failing to balance fault recovery speed and system stability.

[0038] Therefore, there is an urgent need for an on-board autonomous container orchestration system and method that is adapted to the characteristics of low-Earth orbit satellite constellations, has on-board autonomy and layered self-healing capabilities, and can optimize resource utilization and reduce operation and maintenance complexity, so as to solve the technical problem that ground container orchestration platforms cannot adapt to on-board scenarios.

[0039] This embodiment provides an on-board autonomous container orchestration method with layered self-healing capabilities, applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes. For example... Figure 2 As shown, this low-Earth orbit satellite constellation is logically divided into a control plane and a data plane. The control plane consists of at least one control node, responsible for global scheduling decisions, self-healing triggering, and cluster state maintenance. The data plane consists of multiple worker nodes, each deploying a container runtime and a point-to-point image caching agent, and configured with persistent volumes for persistent storage of stateful container state data. The point-to-point image caching agents of each worker node collectively form an inter-satellite point-to-point image distribution network, enabling distributed distribution of container images within the constellation and eliminating real-time dependence on ground-based image repositories. Based on this architecture, all scheduling decisions and self-healing triggering at each layer are executed autonomously on-board, without relying on real-time ground commands.

[0040] Furthermore, the low-Earth orbit satellite constellation can consist of N satellite nodes, where N is a positive integer. These N satellite nodes are logically divided into two categories: control nodes and worker nodes. The control nodes constitute the control plane, and the worker nodes constitute the data plane. Together, they achieve onboard autonomous container orchestration and hierarchical self-healing. The following, in conjunction with… Figure 2 Each part is explained in detail.

[0041] The control plane consists of M control nodes, also known as master nodes, where M ≥ 3 and is an odd number. All control nodes deploy container runtimes and high-availability consensus protocols. The container runtimes on the control nodes are used only to host the control plane's own cluster management components, not user-facing business containers. Specifically, control nodes use node taint policies to prevent ordinary business containers from being scheduled to run on them, ensuring the stability and security of the control plane. The high-availability consensus protocol can specifically adopt the Raft protocol, which has strong consistency and fault tolerance, enabling the control plane to tolerate (M-1) / 2 node failures. All control nodes deploy self-healing coordination procedures via Deployment, which are responsible for triggering container-level fault recovery, predictive rescheduling for node-level faults, and cluster-level elastic scaling decisions. The functions of the control plane include: receiving high-level application description files submitted by ground stations or other satellite nodes and parsing application deployment intentions; and collecting and maintaining in real-time the running status, container running status, and resource usage status of all satellite nodes (including control nodes and data plane nodes) across the entire constellation, serving as the basis for global scheduling and management. All scheduling, deployment, scaling, and self-healing decisions are triggered autonomously by the onboard control plane, without relying on real-time ground commands. The control plane only receives high-level commands from the ground station when the system malfunctions or requires global policy adjustments. These high-level commands are policy-level intent expressions rather than real-time scheduling commands.

[0042] The data plane consists of K worker nodes, where K = NM and K is a non-negative integer. Each worker node deploys a container runtime, persistent volumes, and a point-to-point image caching proxy. The container runtime is the underlying execution engine for containers, responsible for container lifecycle management, including container startup, shutdown, runtime status monitoring, image download and decompression, resource isolation and limiting, and bearing the actual operation of business containers. Persistent volumes are used to persistently store state data generated by stateful containers during runtime, making application data independent of container computing resources, achieving decoupling of computation and storage, and ensuring that data is not lost, state is traceable, and services can be quickly recovered when containers are destroyed, scheduled for migration, or rebuilt after failure. The point-to-point image caching proxy is used to cache container images locally on worker nodes and participate in inter-node image distribution, enabling each worker node to obtain images while also providing image data to other nodes, transforming the traditional one-to-many centralized image distribution model into a many-to-many distributed model.

[0043] It's important to note that the point-to-point image caching agent and the inter-satellite point-to-point distributed image repository are two components with different functional roles but that work together. The point-to-point image caching agent is deployed on each worker node, acting as an accelerator for image distribution. Specifically, it utilizes cached copies from nearby satellites to accelerate the speed of pulling images from the image source, reducing satellite-to-ground bandwidth consumption. It focuses on temporary data storage and high-speed distribution, addressing the real-time issue of slow image retrieval. The inter-satellite point-to-point distributed image repository, on the other hand, is a logical whole integrated from the point-to-point image caching agents on all worker nodes across the entire constellation. Its role is to serve as an alternative source to the ground image repository. Specifically, in situations where the satellite-to-ground link is interrupted and connection to the ground image repository is unavailable, it provides the ability for autonomous onboard acquisition of image data, addressing single points of failure and the survivability issue of image availability. Together, they constitute a complete onboard image distribution system.

[0044] The peer-to-peer image cache proxies of each worker node collectively constitute the inter-satellite peer-to-peer image distribution network. This network integrates the local image cache resources of all worker nodes across the entire constellation, forming a distributed image storage and distribution capability covering the entire constellation. When a worker node needs to pull a container image, it follows a priority order of local image cache first, followed by inter-satellite image cache. First, it checks whether the required image already exists in the local image cache of its node. If it does, it uses it directly. If it does not exist locally and the ground image repository is unreachable, it prioritizes obtaining the required image data from the image cache of a neighboring worker node through the inter-satellite peer-to-peer network, avoiding container deployment or migration failures due to satellite-to-ground link interruptions.

[0045] Through the coordinated operation of the control plane, data plane, and inter-satellite point-to-point mirror distribution network, the entire low-Earth orbit satellite constellation forms a container orchestration system where ground-based intent submissions are made and onboard execution is autonomous. Compared to terrestrial Kubernetes clusters, the onboard orchestration system has the following differences: onboard resources are extremely limited, making it impossible to dynamically request sufficient CPU and memory resources like on the ground; inter-satellite and satellite-to-ground networks are characterized by high latency, low bandwidth, and intermittent connectivity; the onboard system needs a high degree of autonomy, capable of autonomously completing container orchestration and fault recovery even in extreme situations where ground stations are unreachable; onboard storage primarily consists of local storage and lightweight inter-satellite distributed storage, rather than the cloud disks or network-attached storage commonly used on the ground; onboard energy supply is tight, requiring scheduling decisions to incorporate energy-aware strategies, automatically reducing frequencies or migrating non-critical services when satellites enter Earth's shadow region to ensure the survival of core services; in terms of system size, the onboard orchestration platform needs extreme trimming and lightweighting to adapt to platforms with extremely limited resources, such as micro- and nano-satellites. The above architecture provides a complete architectural foundation for the implementation of the layered self-healing method.

[0046] This embodiment provides a method for orchestrating autonomous containers on a satellite with layered self-healing capabilities, such as... Figure 1 As shown, the specific steps include the following: Step S100: Receive the high-level application description file, parse the application deployment intent, and obtain the real-time status information of each satellite node in the constellation.

[0047] In this embodiment, the high-level application description file (HLP) is a declarative application deployment description. Ground operations personnel or the constellation management system use this file to express the desired state of the application deployment without submitting specific, line-by-line scheduling instructions. Specifically, the HLP can be a Kubernetes YAML configuration file, containing information such as the application's resource requirements (e.g., number of CPU cores and memory size), runtime parameters, self-healing strategies, and scaling thresholds. For example, a YAML file for a satellite communication service container might declare its resource requirements as specific CPU and memory quantities, its self-healing strategy as immediate recovery in case of container anomalies, and its scaling thresholds as triggering scaling up when CPU utilization reaches 70% and scaling down when it falls below 30%.

[0048] Application deployment intent refers to the target state of how the application is expected to be deployed and run, parsed from the high-level application description file. Specifically, it may include the expected number of container replicas, resource quotas for each replica, health check methods, fault recovery strategies, and scaling boundary conditions. The parsing process is completed by the master node running the self-healing coordination program in the control plane. The master node reads the fields from the description file, extracts the structured deployment intent data, and forms an internal representation that can be used for subsequent scheduling decisions.

[0049] Real-time status information refers to the operational status data of each satellite node in the constellation at the current moment or within the most recent acquisition cycle. This information is obtained through several methods: monitoring components such as the Metrics Server in the control plane periodically poll the satellite nodes to collect indicator data, and each node actively reports its own status snapshots via inter-satellite links. The collected status information specifically covers satellite node orbital positions such as current latitude, longitude, and altitude; energy status such as solar panel power generation and remaining battery power; load status such as CPU utilization and memory utilization, and the number of running containers; and inter-satellite link quality such as link bandwidth, latency, and packet loss rate. This information, aggregated in the control plane, forms a real-time status view of the entire constellation, providing a data foundation for scheduling decisions. By using the constellation's real-time status as scheduling input, the orchestration system can perceive dynamic changes in the onboard environment, avoiding the shortcomings of ground-based container orchestration platforms that rely solely on static resource requests for scheduling and cannot adapt to complex onboard conditions.

[0050] In one implementation, the real-time status information includes at least one of the following: the orbital position of the satellite node, its energy status, its load status, and the quality of the inter-satellite link.

[0051] In this embodiment, the real-time status information specifically includes at least one of the following: the orbital position of the satellite node, its energy status, its load status, and the quality of the inter-satellite link.

[0052] Specifically, in on-board container orchestration scenarios, orbital position information describes the satellite's spatial coordinates and trajectory at the current moment, including parameters such as latitude and longitude, orbital altitude, orbital inclination, and current orbital phase angle. Orbital position directly affects the satellite's Earth coverage area and inter-satellite visibility. In container orchestration scheduling decisions, incorporating orbital position information allows the control plane to predict when a satellite will enter or leave its service area, thus avoiding scheduling containers to satellite nodes about to leave the target coverage area, or pre-deploying containers on satellites about to enter the target area to achieve predictive service continuity.

[0053] Energy status information reflects a satellite's current power supply capacity and energy consumption trends. Specifically, it can include the real-time power output of solar panels, the state of charge of batteries, the current total power consumption, and whether it is about to enter the Earth's shadow (the region in shadow where the Earth blocks sunlight). Low-Earth orbit satellites spend a portion of their orbital period in the Earth's shadow, during which time they rely entirely on battery power. By incorporating energy status into scheduling decisions, the control plane can proactively relocate high-energy-consuming, non-critical containers to satellites in the sunlit area before the satellite enters the shadow, or automatically limit the CPU and memory quotas of non-core containers when entering the shadow, ensuring the continuous operation of core services.

[0054] Load profiles describe the utilization of computing and storage resources on satellite nodes, specifically including metrics such as CPU utilization, memory utilization, disk utilization, network bandwidth utilization, and the number of currently deployed containers. Load profiles are the most direct trigger for elastic scaling decisions. When the overall load of multiple satellite nodes in a region is high, it indicates a surge in business requests in that region, requiring scaling up. Conversely, when the load remains low, scaling down is triggered to release resources.

[0055] Inter-satellite link quality describes the transmission performance of communication channels between adjacent satellites, specifically including parameters such as link bandwidth, signal propagation delay, bit error rate, link connectivity, and predicted link duration. As the relative positions of satellites in a low-Earth orbit constellation continuously change, inter-satellite link quality fluctuates dynamically. During container migration and image distribution, paths with good link quality are prioritized for data transmission, significantly improving image retrieval speed, reducing migration latency, and ensuring node-level self-healing is completed within the specified timeframe. Furthermore, service containers requiring frequent inter-satellite communication should be prioritized for scheduling to satellite nodes with stable inter-satellite link quality to guarantee service quality.

[0056] Step S200: Based on the application deployment intent and the real-time status information, make a scheduling decision and deploy the container to the target worker node.

[0057] In this embodiment, scheduling decision refers to the process by which the control plane, based on the desired state expressed by the application deployment intent and combined with the real-time status information of all satellite nodes in the constellation, determines, through a preset scheduling algorithm, which specific worker nodes to deploy each application container to for execution. The entity responsible for scheduling decision is the master control node in the control plane. Multiple master control nodes reach a consensus on the scheduling result through a high-availability consensus protocol, ensuring that the scheduling decision remains reliable even if some control nodes fail.

[0058] The scheduling decision is based on two inputs: first, the application deployment intent parsed from the high-level application description file, which outlines hard constraints for container deployment, such as required resource quotas, and soft preferences, such as prioritizing nodes in well-lit areas and replica count requirements; second, real-time status information collected from the entire constellation, including the orbital position, energy status, load, and inter-satellite link quality of each worker node. The scheduling algorithm comprehensively analyzes these two types of inputs and evaluates the suitability of each candidate worker node for each container to be deployed.

[0059] Furthermore, the calculation logic for adaptability may include: prioritizing the exclusion of worker nodes whose load has exceeded a preset threshold to avoid overload; prioritizing the exclusion of worker nodes that are about to fly out of the target service area to avoid the need for migration in a short period of time after deployment; among the remaining candidate nodes, prioritizing worker nodes with sufficient energy, such as those located in sunny areas and with sufficient battery power, to ensure the energy supply for container operation; prioritizing worker nodes with good inter-satellite link quality to ensure possible subsequent image pulling and data synchronization; and at the same time, distributing multiple replicas of the same application across different worker nodes as much as possible to improve fault tolerance.

[0060] After confirming the scheduling results, the control plane issues container deployment instructions to each selected target worker node. These instructions include the image identifier, resource quotas, environment variables, mounted volume information, and health check configurations for the containers to be deployed. Upon receiving the instructions, the target worker node first checks if the required container image is cached locally. If the image is not present in the local cache and a connection to the ground image repository is unavailable, the worker node retrieves the image data from the image caches of other satellite nodes via the inter-satellite point-to-point network, completes the image retrieval, and then starts the container. After successful container startup, the worker node reports the container's running status to the control plane, which updates the deployment results to the global status database, completing a full scheduling and deployment cycle. By incorporating satellite-specific factors such as orbital position and energy status into the scheduling decision, intelligent scheduling with onboard environment awareness is achieved. Compared to the simple scheduling strategy of ground-based container orchestration platforms based solely on CPU and memory requests, this significantly improves the overall resource utilization of the constellation and the rationality of service deployment. Furthermore, containers are deployed on more reliable nodes from the outset, reducing the probability of subsequent failures.

[0061] In practical deployments, the specific implementation of the on-board container orchestration platform can be flexibly selected based on the satellite's hardware resources. For medium and large satellite nodes with ample computing and storage resources, a fully functional Kubernetes can be used as the underlying orchestration platform, paired with containerd as the container runtime. For micro and nano satellite nodes with extremely limited resources, lightweight K3s can be used instead of Kubernetes, and the container runtime can be replaced with a lightweight version of CRI-O or a simplified version of KataContainers. By trimming redundant functions such as image building and log collection, the memory and CPU usage of the container runtime can be reduced, enabling the orchestration system to run stably even on micro satellites.

[0062] Furthermore, the lightweight container runtime has been specifically optimized for the characteristics of on-board links. Regarding image loading, it supports an image fragmentation loading mechanism, which splits container images into smaller data fragments. When a container starts, it only pulls the necessary fragments as needed, rather than waiting for the complete image to download before starting, thereby further reducing container cold start time and lowering the instantaneous transmission pressure on inter-satellite links. In terms of resource management, it supports dynamic container resource limiting, automatically adjusting the CPU and memory quota limits of containers based on the satellite's current energy status: when the satellite is in a sunlit area and solar power is sufficient, containers are allowed to use higher resource quotas to ensure service performance; when the satellite is about to enter or is already in the shadow area and relies entirely on battery power, the CPU frequency and memory quota of non-core containers are automatically reduced, limiting the execution of energy-intensive tasks and prioritizing the allocation of limited power to core service containers, ensuring the continuous operation of core functions of the satellite during periods of energy scarcity.

[0063] Step S300: Monitor the container running status and worker node running status of each worker node in real time.

[0064] In this embodiment, the container running status refers to the process-level health information of the application container instances deployed on each worker node. Specifically, it may include whether the container process is running normally or has crashed and exited, whether the actual CPU and memory usage is within the quota, the detection results of internal container health check probes such as HTTP probes or command probes, and whether abnormal error messages appear in the container logs. The monitoring of the container running status is the responsibility of the container runtime on each worker node. The container runtime continuously monitors the process status of all containers on its node. When it detects abnormal exit of a container process, such as program crash, kernel termination due to memory overflow, or process deadlock, it immediately marks the container's status as abnormal and reports the abnormal event to the control plane.

[0065] The operational status of a worker node refers to the overall operational health of the worker node itself and the satellite it resides in. Specifically, this includes whether the node's agent process maintains a heartbeat connection with the control plane, whether the node's total CPU and memory utilization are within safe limits, whether the node's storage devices are functioning properly, whether the satellite's power system is supplying power normally, and whether the satellite's orbital attitude is within the normal range. Monitoring the operational status of worker nodes is the responsibility of the control plane. The control plane determines the health of nodes by periodically receiving heartbeat signals and status snapshots reported by each worker node's agent. When the control plane does not receive a heartbeat signal from a worker node within a preset timeout period, it indicates that the worker node's agent has lost contact. Possible causes include satellite power outages due to depleted satellite power, communication interruptions due to abnormal satellite orbits, and network isolation due to inter-satellite link failures. In this case, the control plane marks the worker node as out of contact and further determines whether to trigger node-level fault migration based on the node's historical status data.

[0066] By continuously monitoring the operational status of the container level and the node level at both the working node and control plane levels, the hierarchical self-healing system can accurately and timely detect fault signals at different levels, providing a reliable criterion for triggering self-healing actions at the corresponding level based on the severity of the fault.

[0067] It should be noted that the monitoring scope of the operational status is not limited to the working nodes of the data plane. The control plane also monitors the operational status of each master node, including whether the proxy process of the master node is alive, whether the consensus protocol is running normally, and whether the energy and orbit of the satellite where the node is located are abnormal. When a failure of a master node is detected, the control plane, based on the fault tolerance mechanism of the high-availability consensus protocol, allows the remaining healthy control nodes to take over the cluster management responsibilities, ensuring that the control plane can still operate normally when some nodes fail, thus enabling the monitoring system to cover all nodes of both the control plane and the data plane.

[0068] Step S400: When an abnormal global load is detected, trigger the first-level cluster-level elastic scaling to adjust the number of container replicas.

[0069] In this embodiment, as Figure 3 As shown, the layered self-healing system comprises three layers according to the severity of the fault: cluster-level elastic scaling, container-level fault recovery, and node-level fault migration. The first layer, cluster-level elastic scaling, is a self-healing mechanism within the layered self-healing system, addressing load changes in the worker node clusters of the entire constellation or a specific region within the constellation.

[0070] Specifically, global load anomaly refers to a deviation of the overall load metric of multiple worker nodes across the entire constellation or within a specific geographical area from the preset normal operating range, manifesting as excessively high or low overall load. Global load monitoring data originates from monitoring components such as the Metrics Server in the control plane. These components collect real-time metrics such as CPU utilization, memory utilization, and service request volume from all satellite nodes across the constellation, while simultaneously combining this with satellite orbital position information to determine if there is regional load imbalance. As a cluster-level resource metric aggregator, the Metrics Server collects data equally from every node in the cluster, including both worker nodes in the data plane and control nodes in the control plane, thus providing a complete data view for global load assessment. For example, when service request volume surges within the coverage area of ​​multiple satellite nodes in a certain region, and the average CPU utilization of each worker node in that region consistently exceeds the preset expansion threshold, it is determined to be a global load anomaly; conversely, when the average CPU utilization consistently falls below the preset reduction threshold, it is determined to be a global load anomaly.

[0071] After triggering elastic scaling, the control plane autonomously decides and executes container scaling operations based on preset strategies. Preset strategies may include threshold strategies based on CPU and memory utilization, and time-based strategies. Taking the threshold strategy as an example, when the load exceeds the preset scaling threshold, the control plane autonomously increases the number of replicas of the target application container. The newly added container replicas will be scheduled to run on worker nodes within the region with sufficient resources, suitable orbital locations, and good inter-satellite link quality, to promptly handle new service requests. When the load falls below the preset scaling threshold, the control plane autonomously reduces the number of container replicas, gracefully terminating redundant containers and releasing occupied computing and storage resources, reducing the overall energy consumption of the constellation. The scaling step size, cooldown period, and upper and lower limits of the number of replicas can all be preset according to actual business needs.

[0072] During the scaling-up and scaling-down process, the control plane prioritizes scheduling new containers to working nodes with suitable orbital positions and inter-satellite link quality that meet preset conditions. For example, it prioritizes nodes located in illuminated areas, with current load below 50%, and link latency within preset ranges, avoiding deployment of containers to satellites about to fly out of the target service area. This on-board environment-aware scheduling preference makes elastic scaling not just a simple quantitative adjustment, but a qualitative and intelligent adjustment that maximizes the overall resource utilization of the constellation while ensuring the stable operation of services after scaling up or down.

[0073] In one implementation, when an abnormal global load is detected, triggering the first-layer cluster-level elastic scaling to adjust the number of container replicas specifically includes the following steps: Step S410: When the load of the worker node is detected to exceed the preset expansion threshold, increase the number of container replicas; Step S420: When the load of the worker node is detected to be lower than the preset scaling-down threshold, reduce the number of container replicas; During scaling up or down, containers are prioritized for scheduling to working nodes whose orbital positions and / or inter-satellite link quality meet preset conditions.

[0074] In this embodiment, elastic scaling specifically includes threshold triggering mechanisms in both expansion and contraction directions, as well as a scheduling preference strategy based on on-board environment awareness during the expansion and contraction process. Figure 4 As shown, the complete process of elastic scaling is as follows.

[0075] When the monitoring components of the control plane detect that the load of worker nodes in a certain area or the entire constellation exceeds the preset expansion threshold, the expansion decision process is initiated. The expansion threshold can be flexibly configured according to the actual business scenario. A typical setting is to set the CPU utilization expansion threshold to 70%, that is, when the average CPU utilization of worker nodes in the target area reaches 70% or more, it is determined that expansion is needed. Once the expansion decision is made, the control plane calculates the new expected number of replicas according to the preset expansion step size, such as adding two replicas each time, and ensures that this number does not exceed the preset maximum number of replicas. A typical configuration is to set the maximum number of replicas to 10. Subsequently, the control plane selects the optimal expansion target node from the candidate worker nodes according to the aforementioned on-board environment-aware scheduling strategy and issues container deployment instructions to it. After the expansion is completed, the newly started containers access business traffic through the load balancing mechanism, sharing the load pressure of the original replicas, so that the overall load falls back to the normal range.

[0076] Conversely, when the monitoring component detects that the workload of a worker node remains below a preset scaling-down threshold, it initiates a scaling-down decision process. The scaling-down threshold can also be configured based on requirements; a typical setting is to set the CPU utilization scaling-down threshold to 30%, meaning that scaling down is deemed necessary when the load remains below this level. The scaling-down decision must also ensure that the number of replicas after scaling down is not less than a preset minimum replica count, which is set to 2. The control plane selects redundant containers to be scaled down, prioritizing containers with the lowest load, those on nodes with limited resources, or those about to enter the shadow region. Before scaling down, the control plane gradually redirects new requests from the container to be scaled down to other containers, gracefully terminating the container after existing tasks are completed to avoid service interruption.

[0077] Regarding scheduling preferences for scaling up and down, this embodiment incorporates the satellite's unique orbital position and inter-satellite link quality into the scheduling decision. Specifically, when evaluating the suitability of each candidate working node, the scheduling algorithm assigns higher weights to nodes with suitable orbital positions (i.e., currently within the target service coverage area and unlikely to leave in a short period), and to nodes with good inter-satellite link quality (i.e., sufficient link bandwidth and latency within a preset range). Simultaneously, it comprehensively considers the node's energy status and current load. This multi-dimensional scheduling preference ensures that scaling up and down not only responds to load changes but also fully adapts to the dynamic characteristics of the satellite environment.

[0078] By combining a two-way threshold mechanism with on-board scheduling preferences, the first layer of elastic scaling achieves macro-level dynamic optimization of constellation resources. From detecting load anomalies to completing scaling up or down operations, the response time for elastic scaling is controlled within 30 seconds. During high loads, timely scaling up ensures service capacity, while during low loads, timely scaling down releases resources and reduces energy consumption. Furthermore, each adjustment deploys containers on the most suitable satellite nodes, maximizing the overall resource utilization efficiency of the constellation. This mechanism addresses the fundamental shortcomings of traditional on-board systems, which have fixed resource allocation and cannot flexibly respond to load changes. In actual deployment, the preset scaling up / down thresholds and scheduling preference parameters can be customized according to the specific mission requirements of the constellation and the satellite hardware configuration, demonstrating good adaptability and scalability.

[0079] In practical deployments, elastic scaling strategies can be further adjusted according to the needs of business scenarios. One enhancement is to link business priorities with satellite orbital cycles to achieve more refined predictive scaling. Specifically, the various services carried on the satellite are first divided into high, medium, and low priorities based on their importance. Applications directly related to the core functions of the constellation, such as satellite communication services, are high priority; periodic tasks such as Earth observation data acquisition are medium priority; and non-real-time tasks such as log statistics and background analysis are low priority. Different priority services are preset with different scaling thresholds and response speeds, with high-priority services enjoying lower expansion trigger thresholds and faster expansion response speeds. At the same time, combined with the orbital cycle of low-Earth orbit satellites, which is approximately 90 minutes, the control plane can predict the time window for satellite coverage of a specific target area: about 30 minutes before the satellite enters the target area, expansion is initiated in advance for high-priority services, increasing the number of container replicas to the level that meets the peak demand of services in that area; after the satellite leaves the target area, low-priority services are automatically scaled down, releasing resources that are no longer needed. Taking a high-priority satellite communication service as an example, its coverage window for the target area is fifteen minutes. Thirty minutes before the satellite enters the target area, the control plane expands the number of Pod replicas for this service from five to ten to ensure sufficient service capacity within the coverage window. After the satellite leaves the target area, the number of replicas is reduced to three. This ensures the stability of the service within the coverage window and avoids long-term idle resources outside the coverage window, reducing the interruption rate of high-priority services to zero. This spatiotemporal prediction-based scaling strategy outperforms simple scaling methods that rely solely on current load thresholds in terms of both resource utilization and service continuity.

[0080] Step S500: When an abnormality is detected in a single container process, the second-level container-level fault recovery is triggered to rebuild the abnormal container.

[0081] In this embodiment, the second-level container-level fault recovery is aimed at process-level faults of a single container instance, and its recovery time limit is in the second range.

[0082] A single container process anomaly refers to the abnormal exit or unresponsiveness of a process of a container instance running on a worker node. Specifically, this could be due to the application itself crashing (e.g., a segmentation fault or uncaught exception causing process exit), the container process being forcibly terminated by the operating system's OOM Killer mechanism due to exceeding memory quotas, or the container process getting stuck in a deadlock or infinite loop, causing continuous failures of health check probes. When the container runtime on the worker node detects the above-mentioned anomalies, it immediately triggers a container-level self-healing process.

[0083] Container-level fault recovery is divided into two main categories based on whether the container stores business state data: recovery paths for stateful containers and recovery paths for stateless containers. For the recovery of stateless containers, since stateless application containers do not store business data, are not bound to specific nodes, and can be restarted and migrated at will, the recovery method is to destroy the original container instance and create a completely new container instance to replace it. Once the new container starts, it immediately connects to business traffic, and the entire process is typically completed within seconds.

[0084] Recovery of stateful containers relies on persistent volume mechanisms. Stateful applications, such as satellite orbital parameter services and observation data storage services, need to persistently store business state data to ensure that the business can continue operating from its pre-failure state after container reconstruction, rather than starting from scratch. By designing separate solutions for stateful and stateless containers, the second-layer container-level self-healing balances recovery speed and data security. Stateless containers recover faster, while stateful containers achieve rapid recovery while ensuring data integrity.

[0085] In one implementation, when an anomaly is detected in a single container process, triggering a second-level container-level fault recovery to rebuild the abnormal container specifically includes the following steps: Step S510: For stateful containers, the stateful container persists its state data to a persistent volume during operation; Step S520: When an abnormality is detected in the process of the stateful container, the original container is destroyed and a new container is rebuilt, and the rebuilt container is mounted to the persistent volume. Step S530: Perform consistency verification on the state data in the persistent volume, and restore the container running state based on the state data that passes the verification.

[0086] In this embodiment, a stateful container refers to a container application that needs to store and maintain business data. Typical stateful container application scenarios include satellite orbit parameter management services, Earth observation data storage and processing services, constellation operation and maintenance log recording services, and payload operation status monitoring services. These applications generate and accumulate critical operational status information during operation. If a container fails and this status data is lost, even if the container is rebuilt, the business cannot continue operating from the pre-failure state, potentially leading to task interruption or permanent data loss. Therefore, the recovery of stateful containers relies on persistent volume mechanisms to decouple application data from container computing resources.

[0087] A persistent volume (PV) is a cluster-level storage resource whose lifecycle is independent of any individual container or Pod (a Pod is the smallest unit of deployment and scheduling in Kubernetes, containing one or more containers sharing network and storage resources). Even if a container using a persistent volume is deleted, the data stored within it remains intact. The hierarchical relationship between persistent volumes, persistent volume claims (PVCs), Pods, and containers constitutes the basic architecture of Kubernetes persistent storage. At the underlying resource layer, a persistent volume is a real storage resource at the cluster level, independent of any specific business logic. Its lifecycle is unrelated to Pods; even if a Pod using a persistent volume is deleted, the data stored within it remains intact in the underlying storage. At the intermediate bridge layer, a Pod cannot directly occupy a persistent volume but must use a persistent volume claim as an intermediary. The persistent volume claim expresses the user's requirements for storage space size and read / write patterns, and Kubernetes automatically binds eligible idle persistent volumes to persistent volume claims one-to-one. At the mount reference layer, the Pod's definition file specifies which persistent volume declaration to use via the volume field, granting the Pod access to the actual storage. At the actual usage layer, the container runs inside the Pod. By setting volume mount parameters in the Pod configuration, the storage path mapped by the persistent volume declaration is mounted to a specific directory inside the container. The application's read and write operations on this directory are actually persisted to the underlying physical storage. In satellite scenarios, since satellites typically perform single-node specific tasks, the persistent volume access mode is usually configured as ReadWriteOnce (RWO), meaning a persistent volume can only be mounted by a single Pod for read and write operations at any given time. This meets the exclusivity requirements of satellite missions and simplifies concurrent access control.

[0088] Regarding the preparation and binding of persistent volumes, since the total amount of onboard storage resources is fixed and can be pre-planned, a static preparation method is typically used. During the deployment phase, the system administrator pre-defines each persistent volume object in Kubernetes, specifying the storage capacity, access mode (e.g., ReadWriteOnce), and storage path (e.g., / data / db) for each persistent volume. When a Pod starts, it expresses its storage needs through the persistent volume declarations in its definition file, such as requesting 1 Gi of storage space. When making scheduling decisions, the Kube-Scheduler component checks whether each candidate worker node has free persistent volume resources that meet the persistent volume declaration requirements and schedules the Pod to a worker node with sufficient persistent volume resources. After the Pod is scheduled to the target worker node, the kubelet component on that node performs the specific mounting operation, mounting the node's local persistent volume directory (e.g., / mnt / pv-db) to the specified path of the Pod's container (e.g., / var / lib / mysql), completing the storage binding and mapping.

[0089] like Figure 5 As shown, the complete recovery process of a stateful container includes four stages: persistent writing of state data, fault detection and container destruction, new container reconstruction and persistent volume mounting, data consistency verification and state recovery.

[0090] In on-board environments, due to the inability to use cloud disks or complex distributed storage systems commonly used in terrestrial cloud computing, and the limited bandwidth and high latency of inter-satellite communication, the underlying storage media for persistent volumes are primarily local solid-state drives (SSDs) or embedded multimedia storage cards (eMMCs) on satellite nodes. Depending on the importance of the data and redundancy requirements, persistent volumes can adopt two modes: Local persistent volume mode is suitable for ordinary business data, where data is stored only on the satellite's local disk. The disk's own multi-copy mechanism, such as storing two copies of critical hot data locally, prevents data loss due to single-point failures. Inter-satellite network persistent volume mode is suitable for critical status data such as satellite cluster metadata and mission configuration files. In addition to local storage, data blocks are synchronized to neighboring satellites via inter-satellite point-to-point protocols, forming cross-node data redundancy. Even if the entire satellite fails, critical data can be recovered from neighboring satellites.

[0091] During normal operation, stateful containers periodically or in real-time write the state data generated during their operation to a persistent volume. The specific content of this state data may include intermediate calculation results, task configuration parameters, business database records, track parameters, payload operation status snapshots, and operation and maintenance logs. The writing method can be either through the application inside the container directly calling the file write interface, or through inter-process communication mechanisms such as message queues or shared memory to pass the state data to a dedicated data persistence sidecar container, which is then responsible for uniformly writing the data to the persistent volume. This design allows the container's main business process to be free from concern for the underlying storage details of the data, achieving separation of concerns.

[0092] When the container runtime detects an abnormal exit of a stateful container's process, the second-layer container-level self-healing process is initiated. First, the container runtime reports the abnormal event to the control plane. After the control plane confirms the abnormality, the Kubernetes StatefulSet controller is responsible for the recovery orchestration of the stateful container. The StatefulSet controller first destroys the failed container instance and its associated Pod, but retains the persistent volume declaration bound to the Pod. The one-to-one binding between the persistent volume declaration and the persistent volume is not severed by the deletion of the Pod. Subsequently, the StatefulSet controller recreates a new Pod with the same name on the original worker node. When the new Pod starts, it remounts the persistent volume to the original persistent volume through the persistent volume declaration, enabling the newly created container to access all state data from before the failure. The path for mounting the persistent volume is specified by the volume mount configuration in the Pod definition. For example, mounting the persistent volume to a data directory inside the container allows applications within the container to directly manipulate the data in the persistent volume by reading and writing to that directory.

[0093] Upon startup of a new container, a data consistency verification mechanism is triggered. Specifically, the verification process compares the data snapshot stored in the persistent volume with the last recorded normal state data before the application failure to determine if there was any data write interruption or inconsistency caused by the failure. If the verification finds data inconsistency, the system automatically initiates a repair process, restoring the correct data from local redundant copies or inter-satellite synchronized copies based on a preset backup strategy. For example, if the persistent volume uses a local dual-copy mechanism, correct data can be read from another intact copy to overwrite the corrupted data blocks; if an inter-satellite network persistent volume mode is used and synchronized to nearby satellites, correct data fragments can be pulled from nearby satellites for repair. After the data verification passes, the application reads the complete state data from the persistent volume before the failure and restores its running state, including reloading business configurations, restoring database connections, and replaying unfinished computation tasks. Subsequently, the system performs a health check on the recovered container using the readinessProbe. The readinessProbe is a probe mechanism in Kubernetes used to determine whether a container is ready to receive business traffic. Only after the probe detection passes will Kubernetes register the container's IP address to the service's backend endpoint list, allowing it to access system traffic. This mechanism effectively avoids the problem of request failure caused by assigning business requests before the container state has been fully restored, ensuring the smoothness and reliability of the stateful container recovery process. After the detection passes, the container is connected to system traffic, and the recovery of the stateful container application is complete.

[0094] After the container is successfully launched, capacity management of the persistent volume is still required. The data lifecycle management component detects the current storage capacity usage of the persistent volume. If the capacity reaches a preset cleanup threshold, such as 90%, it further filters out data that has not been accessed for a long time for cleanup. The cleanup strategy is divided into two levels: for data marked for deletion and whose last access time exceeds a preset period, such as 180 days, physical deletion is performed directly; for non-core data that is not marked for deletion but whose last access time exceeds another preset period, such as 90 days, a secondary confirmation mechanism is triggered. If it is detected that the application has not made any access requests to the data within a certain period of time, physical deletion is performed automatically. After the cleanup is completed, a cleanup log is recorded, including information such as the data type cleaned, the amount cleaned, and the remaining capacity of the persistent volume, to ensure that the capacity of the persistent volume is restored to below the safe level and to avoid new data being unable to be written due to the persistent volume being full.

[0095] Through persistent volume mechanisms, stateful containers achieve second-level response times for fault recovery, while fully preserving the business state. Users are virtually unaware of the fault occurring, achieving seamless fault recovery. In actual operational testing, fault recovery for stateful containers can be completed within 0.8 seconds, with recovery time controlled within 1 second.

[0096] In one implementation, when an anomaly is detected in a single container process, triggering a second-level container-level fault recovery to rebuild the abnormal container specifically includes the following steps: Step S540: For stateless containers, when an abnormality is detected in the stateless container process, the stateless container is destroyed and a new container is created.

[0097] In this embodiment, a stateless container refers to a container application that does not store business data, is not bound to a specific node, and can be restarted arbitrarily and migrated between nodes. Typical application scenarios for stateless containers include satellite communication protocol processing services, request routing and load balancing services, real-time data forwarding services, and simple telemetry data acquisition and reporting services. The characteristics of these applications are that the service itself does not store data that needs to be persisted across requests, and the processing result of each request does not depend on the previous request history. Therefore, any replica instance can equivalently handle any request.

[0098] When a stateless container process exits abnormally during container runtime, a fault recovery process is initiated. Unlike stateful containers, stateless containers do not require consideration of data retention and migration, making their recovery process simple and efficient. First, the control plane confirms the container's abnormal event, and the Deployment controller is responsible for the recovery orchestration of the stateless container. The Deployment controller directly destroys the failed container instance and its associated Pod, including releasing the CPU and memory resources occupied by the container and cleaning up the temporary file system. Subsequently, the Deployment controller creates a completely new Pod and container instance on the original worker node or another available worker node, based on the expected number of replicas defined in the application deployment intent. The new container uses the exact same image and configuration parameters as the failed container. After startup, its health status is checked via a readiness probe. If the check passes, system business traffic is restored. The recovery process typically completes within seconds or even sub-seconds.

[0099] Stateless containers are managed using Deployment controllers instead of StatefulSet controllers because Deployment provides Pods with random naming and eliminates the need to maintain network identifiers. Multiple replicas are completely peer-to-peer, and the failure of one replica will not affect the normal service of other replicas. With the default restartPolicy set to Always, even if the container crashes repeatedly, the system will continuously attempt to rebuild, ensuring service availability. For stateless applications that need to maintain a certain service capacity, Deployment also supports configuring a minimum number of ready replicas. During the short time window between the destruction of an old container and the readiness of a new one, other ready replicas continue to handle business traffic, avoiding a temporary drop in service capacity.

[0100] Step S600: When a worker node is detected to be disconnected or malfunctioning, a third-level node-level fault migration is triggered to migrate the containers on the malfunctioning worker node to other healthy worker nodes.

[0101] In this embodiment, the third-level node-level fault migration is aimed at severe faults in the entire satellite's working nodes, with a recovery time of minutes.

[0102] A worker node losing connection or malfunctioning refers to the control plane not receiving a heartbeat signal from a worker node's agent within a preset timeout period, or receiving an unrecoverable severe fault report from that node. Specific triggering scenarios include satellite power depletion leading to a complete power outage, abnormal satellite orbit causing deviation from the predetermined orbit and loss of communication with the constellation, hardware failure of inter-satellite link equipment leading to complete node loss of connection, and node load continuously exceeding a safety threshold with ineffective node-level repair attempts. The control plane comprehensively judges the node's outage duration, the last reported status data, and monitoring information from neighboring nodes. After confirming a node failure, it marks the node as unavailable and immediately initiates a node-level fault migration process.

[0103] The goal of node-level failover is to migrate all container instances running on a failed worker node to other healthy worker nodes in the constellation to resume operation and restore affected business services. The migration process begins with the control plane selecting a suitable backup worker node as the migration target based on the real-time status of all nodes in the constellation.

[0104] The selection criteria specifically include that the standby node has a low enough current load to receive new containers, is in a stable orbital position and will not fly out of the target service area in a short time, has sufficient energy supply, and has a high degree of overlap with the failed node's image data so as to quickly pull the required image.

[0105] After the target node is identified, the migration enters the image acquisition and container reconstruction phase. Specifically, the target node obtains the image data corresponding to the container from the image cache of other satellite nodes in the constellation that have cached the required image through the inter-satellite point-to-point network, without relying on the ground image repository. This allows the node-level migration to be completed autonomously even when it is difficult to transfer ground image data to the satellite.

[0106] After the target node obtains the image data, the container runtime starts the container instance and restores it to its pre-failure running state as much as possible, completing service reconstruction. The entire node-level migration process is completed within minutes. Before recovery, the failed node is continuously marked as unavailable, the control plane updates the global node state, and no new containers will be scheduled to that node subsequently; if the failed node resumes normal operation after a period of time and re-establishes a heartbeat connection with the control plane, it is automatically reinstated into cluster management.

[0107] In one implementation, when a worker node is detected to be disconnected or malfunctioning, a third-layer node-level fault migration is triggered to migrate the containers on the faulty worker node to other healthy worker nodes. This specifically includes the following steps: Step S610: Determine the target healthy worker node to take over the container on the failed worker node; Step S620: The target healthy working node obtains the image data corresponding to the container from the image cache of other satellite nodes in the low-Earth orbit satellite constellation through the inter-satellite point-to-point network; Step S630: Rebuild the container on the target healthy working node based on the acquired image data.

[0108] In this embodiment, the specific execution process of the third-layer node-level fault migration includes determining the target node for migration, obtaining mirror data through the inter-satellite point-to-point network, and rebuilding the container on the target node. For example... Figure 6 As shown, the complete process is explained in detail below.

[0109] First, upon confirming an unrecoverable failure of a working node, the control plane immediately selects a suitable target healthy working node for each container on that failed node across the entire constellation. The selection of the target node comprehensively considers the following dimensions: the node's current load should be within a preset safety range to ensure it can accommodate new containers without causing overload; the node's orbital position should match or be close to the service area originally covered by the failed node to ensure that migrated containers can continue to provide services to the original service area; the node's energy status should be sufficient, with priority given to satellite nodes located in well-lit areas and with sufficient battery power; and the inter-satellite link quality should be good to ensure efficient transmission of subsequent mirror data. This multi-dimensional selection criterion reflects the predictive rescheduling concept of onboard environment awareness, avoiding the problem of ground-based container orchestration platforms scheduling solely based on resource reserves while ignoring specific onboard constraints.

[0110] Once the target node is determined, the image data acquisition phase begins. Due to the limited bandwidth, high latency, and intermittent nature of the communication link between the satellite and the ground, it is impossible to wait for the image to be re-downloaded from the ground image repository in an emergency scenario involving node-level fault migration. In this case, an inter-satellite point-to-point image distribution network is required.

[0111] At the storage level of mirror data, the inter-satellite point-to-point mirror distribution network adopts a fragmented storage model. Each layer of the image is split into fixed-size data blocks, with each block size set to, for example, 4MB. Each fragment is uniquely identified by the hash value of its content. The same image layer or fragment from different container images is stored only once across the entire constellation, and this deduplication mechanism greatly saves the already limited onboard storage space. To ensure data recoverability in the event of partial node failure, the system dynamically calculates the number of copies of each fragment based on the storage capacity and orbital position of each satellite, achieving a balance between storage efficiency and data reliability. Specifically, redundancy coding techniques such as Reed-Solomon erasure coding can be used to reduce additional storage overhead while ensuring data recoverability.

[0112] In the specific process of image acquisition, when a target worker node needs to pull a container image, the entire process is divided into three stages: request parsing, peer-to-peer download, and local assembly. In the request parsing stage, the container creation request triggers the image pull process. The target node first queries the distributed metadata service to obtain the complete shard hash list corresponding to the image. The hash list describes all the data shards that make up the image and their corresponding hash identifiers. In the peer-to-peer download stage, based on the obtained hash list, the target node initiates a shard download request to the nearest satellite node with the best inter-satellite link status. Through a neighbor node priority strategy, the image shard pull latency can be controlled within 100 milliseconds. If a neighbor node is missing a required shard, multi-hop forwarding is performed using peer-to-peer network routing protocols such as distributed hash tables, routing hop-by-hop to other satellite nodes that store the shard to obtain it, ensuring that any node within the constellation can obtain any shard through a multi-hop path. During the local assembly phase, after the target node has downloaded all the shards, it verifies the hash value of each shard locally to ensure that the data has not been tampered with or damaged during transmission. Then, all the verified shards are assembled into a complete container image file according to the image layer organization structure, and finally loaded into the container runtime for container startup.

[0113] Regarding image cache management, given the extremely limited storage resources of satellites, the system implements a hierarchical priority strategy for cached images. The first level consists of mission-critical images, including images that ensure core satellite services such as attitude control and communication relay services. These are pre-pushed to all relevant satellite nodes via ground stations for permanent caching. The second level consists of commonly used basic images, such as Alpine and Busybox, which are small in size and heavily relied upon by many applications. These are cached as common resources on most working nodes in the constellation. The third level consists of regionalized or mission-specific images, cached on demand based on the satellite's orbital position and current mission plan. Specifically, satellite constellations responsible for observation missions in the same area can pre-cache the same processing model images, and satellites in the same orbital plane can share common service images. When local cache space is insufficient, the system cleans up non-critical fragment caches based on the Least Recently Used (LRU) strategy. However, during the cleanup process, it must ensure that the minimum number of copies of each fragment agreed upon by the system is not violated to prevent the loss of irrecoverable unique copies of certain fragments within the constellation due to excessive cleanup.

[0114] Regarding image data consistency maintenance, the inter-satellite point-to-point image distribution network employs a lightweight distributed consensus algorithm to ensure that the mapping relationship between images and shards remains consistent across the entire constellation. Considering the high latency characteristics of inter-satellite links, this consensus algorithm is optimized for high-latency environments, for example, by using a latency-tuned variant of the Raft algorithm. The metadata service is responsible for maintaining the mapping between each image identifier and its corresponding shard hash list. When an image is updated, added, or deleted, the change information is synchronized to the metadata replicas of all nodes in the constellation via the consensus algorithm.

[0115] Once the image and state data are ready, the container runtime on the target node starts a new container instance. For stateless containers, a brand new container is started directly based on the image; for stateful containers, after starting the container, a synchronized persistent volume is mounted, and data consistency checks are performed. In cross-node migration scenarios involving persistent volume data, the system implements a data following mechanism through an inter-satellite point-to-point storage layer: the target node pulls data shards of the persistent volume from other satellite nodes where the data replica of the failed node resides via inter-satellite links, completes data assembly locally, and then the Pod starts on the target node and mounts the locally synchronized persistent volume. Throughout the migration process, distributed locks or version number mechanisms ensure data consistency and prevent data inconsistencies caused by concurrent or partial writes during data synchronization.

[0116] In practical deployments, node-level migration strategies can be differentiated and optimized based on the severity of the fault. For scenarios involving severe satellite failures, such as complete satellite downtime or complete energy depletion, the aforementioned full migration strategy is executed, migrating all containers on the faulty node to other healthy nodes. For scenarios with partial node failures, such as only some containers being abnormal, excessive load without node downtime, or unstable inter-satellite links, a hybrid self-healing approach combining differentiated migration and node repair is adopted. Specifically, the control plane first determines the specific type and severity of the fault. If it is determined to be a repairable partial fault, only the faulty containers or high-priority containers are migrated to the backup node, while low-priority containers remain on the original node to continue running. Simultaneously, the control plane triggers the node repair process, attempting to repair the fault of the original node through remote commands. Repair methods may include restarting container runtime to restore its normal function, releasing memory and CPU resources occupied by redundant processes, and reinitializing link connections to restore inter-satellite communication. After the original node is successfully repaired, the control plane automatically migrates the previously migrated low-priority containers back to the original node to continue running. The differentiated hybrid self-healing approach significantly reduces inter-satellite data transmission volume and migration overhead while ensuring business continuity, thus improving overall self-healing efficiency. For example, if a worker node experiences a CPU utilization spike to 85% but does not crash and the link remains normal, the control plane only migrates the two high-priority containers on that node to a backup node, while the low-priority containers remain running. Simultaneously, node repair is triggered, releasing redundant resources. One minute later, the node's CPU utilization drops back to 50%, and the control plane then migrates the high-priority containers back to their original node. Compared to a full migration solution, this significantly reduces link transmission volume and noticeably improves self-healing efficiency.

[0117] In one implementation, the on-board autonomous container orchestration method with hierarchical self-healing capabilities further includes the following steps: Step S710: Detect the storage capacity of the persistent volume; Step S720: When the storage capacity of the persistent volume reaches a preset cleanup threshold, filter long-term inaccessible data that meets preset conditions; Step S730: Delete the filtered data that has not been accessed for a long time.

[0118] In this embodiment, the persistent volume serves as the persistent storage medium for the state data of the stateful container, continuously accumulating written data during long-term operation. Due to the extremely limited storage resources on the satellite, the storage capacity of a single persistent volume configured on a worker node is far lower than that of a terrestrial data center. Therefore, an automated persistent volume capacity management mechanism is needed to periodically monitor storage usage and perform deep cleanup when capacity is critical, preventing the persistent volume from becoming full and thus hindering the normal operation and data persistence of the stateful container.

[0119] The persistent volume capacity management process consists of three steps. First, the data lifecycle management component periodically checks the storage capacity utilization of each persistent volume. When the used capacity percentage of a persistent volume reaches a preset cleanup threshold, a deep cleanup process is triggered. The preset cleanup threshold can be flexibly configured based on the total capacity of the persistent volume and the growth rate of business data. A typical setting is 90%, meaning that cleanup begins when the persistent volume utilization reaches 90%, reserving sufficient buffer space for subsequent writes.

[0120] Secondly, the access frequency and timestamp analysis of the data stored in the persistent volume are used to filter out long-term inaccessible data that meets preset conditions as cleanup candidates. The filtering strategy is divided into two levels: The first level is for data that has been explicitly marked as deleted, such as expired calculation results actively marked as recyclable by the application, temporary configuration files of completed tasks, etc. If its last access time exceeds a preset first time threshold, it is directly included in the cleanup list; The second level is for non-core data that has not been marked as deleted but has not been accessed for a long time, such as historical operation and maintenance logs, outdated track parameter snapshots, etc. If its last access time exceeds a preset second time threshold, a secondary confirmation mechanism is triggered. The data lifecycle management component sends a data access status query request to the corresponding application container. If the application returns confirmation that there is no access requirement within the specified time, the data is included in the cleanup list.

[0121] Finally, physical deletion is performed on the selected long-term inaccessible data, which involves erasing the data from the underlying storage medium and reclaiming the corresponding storage blocks. After cleanup, the data lifecycle management component records a detailed log of the cleanup, including information such as the type of cleaned data, the total amount of cleaned data, the amount of storage space released, and the remaining available capacity of the persistent volume after cleanup. If the persistent volume utilization rate does not fall below the safe level after a single cleanup, the cleanup threshold parameter is automatically lowered, and a more aggressive second round of cleanup is performed until the capacity returns to normal. Through the above automated persistent volume capacity detection and deep cleanup mechanism, the on-board orchestration system can autonomously maintain the health of storage resources without human intervention, ensuring the long-term stable operation of stateful containers without the threat of storage space exhaustion.

[0122] In summary, as Figure 7As shown, the entire method forms a complete technical closed loop from state awareness and scheduling deployment to layered self-healing and resource optimization. Through the coordinated operation of the above three-layered self-healing mechanism and the on-board autonomous orchestration method, the entire low-Earth orbit satellite constellation can operate autonomously for more than 72 hours without ground intervention. During this period, the scheduling deployment, fault recovery, and elastic scaling of all containers are completed autonomously by the on-board system. Compared with the prior art, this embodiment improves the overall resource utilization of the constellation by more than 30%, reduces the operation and maintenance complexity by 80%, and has advantages such as layered self-healing capability, high fault recovery efficiency, strong on-board autonomy, reduced ground dependence, adaptability to special on-board scenarios, high resource utilization, low operation and maintenance complexity, strong scalability, strong data consistency, seamless fault recovery, and separation of storage and computing.

[0123] like Figure 8 As shown in the figure, this embodiment of the invention provides an on-board autonomous container orchestration system with layered self-healing capabilities, applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes. The multiple satellite nodes include at least one control node and multiple working nodes. Each working node deploys a container runtime and a point-to-point image cache agent. The point-to-point image cache agents of each working node constitute an inter-satellite point-to-point image distribution network. The system includes: a deployment intent and status acquisition module 10, a container deployment module 20, a runtime status monitoring module 30, an elastic scaling module 40, a container recovery module 50, and a node migration module 60.

[0124] Specifically, the deployment intent and status acquisition module 10 is used to receive a high-level application description file, parse the application deployment intent, and obtain the real-time status information of each satellite node in the constellation; the container deployment module 20 is used to make scheduling decisions based on the application deployment intent and the real-time status information, and deploy containers to target worker nodes; the operation status monitoring module 30 is used to monitor the container operation status and worker node operation status of each worker node in real time; the elastic scaling module 40 is used to trigger the first-layer cluster-level elastic scaling and adjust the number of container replicas when an abnormal global load is detected; the container recovery module 50 is used to trigger the second-layer container-level fault recovery and rebuild the abnormal container when an abnormal single container process is detected; the node migration module 60 is used to trigger the third-layer node-level fault migration and migrate the containers on the faulty worker node to other healthy worker nodes when a worker node is detected to be disconnected or faulty; wherein, the scheduling decisions and the triggering of each layer of self-healing are all executed autonomously on the satellite.

[0125] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 9As shown, the terminal device includes a processor, memory, network interface, display screen, and temperature sensor connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a hierarchical self-healing on-board autonomous container orchestration method. The display screen can be an LCD screen or an e-ink screen. The temperature sensor is pre-installed inside the terminal device to detect the operating temperature of internal components.

[0126] Those skilled in the art will understand that Figure 9 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0127] In one embodiment, a terminal device is provided, including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs including instructions for performing operations as described in the embodiments of the methods above.

[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0129] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0130] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for orchestrating on-board autonomous containers with layered self-healing capabilities, applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes, characterized in that... The method includes: Receive high-level application description files, parse application deployment intent, and obtain real-time status information of each satellite node in the constellation; Based on the application deployment intent and the real-time status information, a scheduling decision is made to deploy the container to the target worker node; Real-time monitoring of container running status and worker node running status on each worker node; When an abnormal global load is detected, the first-level cluster-level elastic scaling is triggered to adjust the number of container replicas. When an anomaly is detected in a single container process, a second-level container-level fault recovery is triggered to rebuild the abnormal container; When a worker node is detected to be disconnected or malfunctioning, a third-level node-level fault migration is triggered to migrate the containers on the faulty worker node to other healthy worker nodes. The scheduling decisions and the triggering of self-healing at each layer are all executed autonomously on the satellite.

2. The on-board autonomous container orchestration method with layered self-healing capability according to claim 1, characterized in that, The real-time status information includes at least one of the following: the orbital position of the satellite node, its energy status, its load status, and the quality of the inter-satellite link.

3. The on-board autonomous container orchestration method with layered self-healing capability according to claim 1, characterized in that, When an abnormal global load is detected, the first-level cluster-level elastic scaling is triggered to adjust the number of container replicas, including: When the load on a worker node exceeds the preset expansion threshold, increase the number of container replicas. When the load on a worker node is detected to be lower than the preset scaling-down threshold, the number of container replicas is reduced. During scaling up or down, containers are prioritized for scheduling to working nodes whose orbital positions and / or inter-satellite link quality meet preset conditions.

4. The on-board autonomous container orchestration method with layered self-healing capability according to claim 1, characterized in that, When an anomaly is detected in a single container process, the second-level container-level fault recovery is triggered to rebuild the abnormal container, including: For stateful containers, the stateful container persists its state data to a persistent volume during operation; When an anomaly is detected in the process of the stateful container, the original container is destroyed and a new container is rebuilt, and the rebuilt container is mounted to the persistent volume. The consistency of the state data in the persistent volume is checked, and the container's running state is restored based on the state data that passes the check.

5. The on-board autonomous container orchestration method with layered self-healing capability according to claim 1 or 4, characterized in that, When an anomaly is detected in a single container process, the second-level container-level fault recovery is triggered to rebuild the abnormal container, including: For stateless containers, when an anomaly is detected in the stateless container process, the stateless container is destroyed and a new container is created.

6. The on-board autonomous container orchestration method with layered self-healing capability according to claim 1, characterized in that, When a worker node is detected to be offline or malfunctioning, a third-level node-level fault migration is triggered to migrate containers on the malfunctioning worker node to other healthy worker nodes, including: Determine the target healthy worker node to take over the container on the failed worker node; The target healthy working node obtains the image data corresponding to the container from the image cache of other satellite nodes in the low-Earth orbit satellite constellation through the inter-satellite point-to-point network; The container is rebuilt on the target healthy worker node based on the acquired image data.

7. The on-board autonomous container orchestration method with layered self-healing capability according to claim 4, characterized in that, The method further includes: Detect the storage capacity of the persistent volume; When the storage capacity of the persistent volume reaches a preset cleanup threshold, long-term inaccessible data that meets preset conditions is filtered out. Perform a deletion operation on the filtered data that has not been accessed for a long time.

8. An on-board autonomous container orchestration system with hierarchical self-healing capabilities, applied to a low-Earth orbit satellite constellation composed of multiple satellite nodes, wherein the multiple satellite nodes include at least one control node and multiple working nodes, each working node deploying a container runtime and a point-to-point image cache agent, and the point-to-point image cache agents of each working node forming an inter-satellite point-to-point image distribution network, characterized in that, The system includes: The deployment intent and status acquisition module is used to receive high-level application description files, parse application deployment intent, and obtain real-time status information of each satellite node in the constellation. The container deployment module is used to make scheduling decisions based on the application deployment intent and the real-time status information, and to deploy the container to the target worker node. The runtime status monitoring module is used to monitor the container runtime status and the runtime status of each worker node in real time. The elastic scaling module is used to trigger the first-level cluster-level elastic scaling when an abnormal global load is detected, and adjust the number of container replicas. The container recovery module is used to trigger a second-level container-level fault recovery and rebuild the abnormal container when an anomaly is detected in a single container process. The node migration module is used to trigger a third-level node-level fault migration when a worker node is detected to be disconnected or malfunctioning, and to migrate the containers on the malfunctioning worker node to other healthy worker nodes. The scheduling decisions and the triggering of self-healing at each layer are all executed autonomously on the satellite.

9. A terminal device, characterized in that, The terminal device includes a memory, a processor, and an on-board autonomous container orchestration program with hierarchical self-healing capability stored in the memory and executable on the processor. When the processor executes the on-board autonomous container orchestration program with hierarchical self-healing capability, it implements the steps of the on-board autonomous container orchestration method with hierarchical self-healing capability as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an on-board autonomous container orchestration program with hierarchical self-healing capability. When the on-board autonomous container orchestration program with hierarchical self-healing capability is executed by a processor, it implements the steps of the on-board autonomous container orchestration method with hierarchical self-healing capability as described in any one of claims 1-7.

Images