An OTA upgrading method and system for a satellite on-board computing cluster and a computer storage medium

Abstract

The application discloses an OTA upgrading method for a satellite on-board computing cluster, which comprises the following steps: obtaining a current on-orbit mirror image Digest, Chart version and node label from each satellite backhaul state to form an auditable satellite cluster cloud native version matrix; calculating a multi-satellite differentiated distribution plan according to the windows, links, resources and task priorities of the satellites; performing differentiated satellite-ground uploading; each satellite locally checks received data and performs differential restoration; pushing a new restored target image to a satellite on-board cluster public Registry; dividing satellite nodes into one or more upgrading batches; and the satellite nodes in the upgrading batches access the satellite on-board public Registry through an inter-satellite link or a cluster network to pull a complete target image which has completed differential restoration and checking. The application further provides an OTA upgrading system for a satellite on-board computing cluster and a computer storage medium.

Description

Technical Field

[0001] This invention relates to the field of on-orbit software maintenance in commercial aerospace, and in particular to a method, system, and computer storage medium for OTA upgrades of multi-satellite cloud-native onboard computing clusters. Background Technology

[0003] As commercial spaceflight rapidly evolves towards distributed intelligent constellations, low-Earth orbit (LEO) satellite constellations have evolved from traditional single-satellite independent operation to space edge computing clusters. Multiple satellites collaborate to perform complex tasks such as real-time payload data processing, inter-satellite routing and forwarding, multi-satellite joint mission management, and on-orbit intelligent inference. These clusters typically employ a Kubernetes cloud-native containerized architecture, deployed uniformly as microservices. However, in the core aspect of cluster service iteration—OTA (Over-The-Air) upgrades—existing technologies cannot adapt to the unique constraints of the on-board environment, becoming a key bottleneck limiting the large-scale iterative development of constellation services. Existing OTA solutions mostly target individual satellites for upgrades, with the ground transmitting upgrade packages to each satellite separately. Ground-based cloud-native cluster upgrade solutions, on the other hand, assume that each node can directly pull images from a remote data center registry. During the upgrade, Helm pulls all dependencies from the remote registry in real time according to version. Therefore, there are the following prominent problems: scenarios such as short windows of satellite-to-ground links and changes in the availability of inter-satellite links are not considered; different satellites may be in different orbital positions, with different task loads and different network reachability states, making it impossible to accurately determine which image each satellite should receive, when to upgrade, whether the dependencies are satisfied, and which version to roll back to in case of failure; each satellite independently receives each image or complete HelmChart package from the ground, resulting in duplicate occupation of satellite-to-ground links.

[0004] In summary, there is currently no efficient OTA (Over-The-Air) method for iterating cloud-native on-board computing services for multi-satellite cloud-native on-board computing clusters. Summary of the Invention

[0005] The following description illustrates the contributions made by this invention.

[0006] To address the aforementioned issues, this invention provides an OTA upgrade method for a satellite-borne computing cluster. This method enables different satellites to receive different microservice images or image fragments within their respective visibility windows. After completing reception, verification, and differential restoration, the complete image is pushed to the onboard public Registry. Subsequently, the cluster control plane completes the upgrade by satellite, by service, and by batch.

[0007] An OTA upgrade method for a satellite-borne computing cluster includes the following steps: The current on-orbit image Digest, Chart version, and node label are obtained from the status returned by each satellite to form an auditable cloud-native version matrix of the satellite cluster. Calculate a multi-satellite differentiated distribution plan based on the satellite's window, link, resources, and mission priority, and allocate microservice images, image layers, or differential fragments and chart packets to be received for each satellite to avoid all satellites receiving the same data repeatedly. Perform differentiated satellite-to-ground injection, injecting the corresponding fragment data in the visible windows of different satellites respectively. Each fragment carries at least the following information: service identifier, image digest, layer digest or object digest, fragment number, offset length, hash value and signature reference. Each satellite verifies the received data and performs differential restoration locally. For microservice image differential packets, the satellite restores the target image based on the local original on-orbit image. For image layers or fragments, the satellite first completes the data required for the same target image, and then generates a complete target OCI image layout locally or at a designated restoration node. After the restoration is completed, the target image Digest is verified again. Push the newly restored target image to the onboard cluster's public registry; Based on the mission status, orbital phase, link reachability, and service dependencies of each satellite, satellite nodes are divided into one or more upgrade batches; Upgrade satellite nodes within the batch to access the onboard public Registry via inter-satellite links or cluster networks to pull the complete target image that has undergone differential restoration and verification.

[0008] This invention also provides an OTA upgrade system for a satellite-borne computing cluster, suitable for executing the OTA upgrade method described in any of the above. The system includes a cloud-native ground OTA management platform, multiple satellite-to-ground links, and a satellite-borne computing cluster. The ground OTA management platform includes a ground packet production and scheduling module. The satellite-borne computing cluster includes multiple satellite nodes, a satellite-borne cluster public Registry, a cluster Helm control plane, and inter-satellite links. The multiple satellite nodes include microservice Pods on each satellite.

[0009] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the above descriptions.

[0010] The OTA upgrade method and system for satellite-borne computing clusters of this invention are based on the unified management and control of multi-satellite cluster images and HelmChart version matrix. Through three core mechanisms, namely multi-satellite differentiated image distribution, satellite-borne public Registry320 aggregation storage, and cluster batch controllable upgrade, an efficient collaborative upgrade system is constructed. This effectively reduces the data transmission overhead of satellite-to-ground links 200, significantly improves the efficiency, operational stability, and cluster version consistency of satellite-borne cluster OTA upgrades, and solves many technical defects of traditional K8s architecture and conventional OTA upgrade solutions in multi-satellite cluster on-orbit upgrade scenarios.

[0011] Other features and advantages of the invention will become more apparent from the following more detailed description, taken in conjunction with the accompanying drawings, which illustrate the advantages of the invention by way of example. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the OTA upgrade system of a satellite-borne computing cluster in one embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of the satellite-borne computing cluster in one embodiment of the present invention; and Figure 3 This is a schematic diagram illustrating the timing of multi-satellite differentiated reception and onboard public Registry publication in one embodiment of the present invention. Detailed Implementation

[0013] The accompanying drawings illustrate the invention. Various embodiments are disclosed herein. Numerous specific details are set forth in the following description to provide a more thorough understanding of the invention. However, those skilled in the art will recognize that the technical content described herein can be practiced without one or more specific details, or other methods, components, materials, etc. In other examples, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring specific content.

[0014] Please refer to Figure 1In one embodiment, the OTA upgrade system for the satellite-borne computing cluster of the present invention includes a cloud-native ground OTA management platform 100, a multi-satellite-to-ground link 200, and a satellite-borne computing cluster 300. The ground OTA management platform 100 includes a ground packet production and scheduling module 110. The satellite-borne computing cluster 300 includes multiple satellite nodes 310, a satellite-borne cluster public Registry 320, a cluster Helm control plane 330, and inter-satellite links. The multiple satellite nodes 310 include microservice Pods on each satellite. The core technical architecture of the present invention is a three-in-one collaborative innovation system of multi-satellite collaborative distribution, satellite-borne public Registry aggregation, and cluster batch upgrade. Each link is deeply linked and constrained at each level, forming a complete technical closed loop with optimized links, unified versions, controllable risks, and traceable results, comprehensively improving the overall efficiency of multi-satellite cluster upgrades.

[0015] The cloud-native OTA management platform maintains a satellite cluster version matrix. Each record in the matrix includes at least the satellite identifier, node role, microservice name, current image digest, target image digest, current HelmChart version, target HelmChart version, configuration version, dependent services, upgrade batch, rollback version, and health check policy. This matrix supports the same microservice being on different versions on different satellites, and also supports the same HelmChart rendering different parameters based on satellite node labels.

[0016] The ground packet scheduling module 110 generates a distribution plan based on the version matrix. For the service set {svc1, svc2, ..., svcn}, the module can allocate the mirror differential packets of svc1 to satellite A, the mirror differential packets of svc2 to satellite B, and the mirror layers or fragments of svc3 to satellite C. The allocation is based on factors including the satellite-to-ground window length, the expected probability of transmission completion, on-board storage capacity, restoration computation cost, inter-satellite link reachability, and the current mission load of the satellite.

[0017] The onboard cluster public Registry320 enables localized unified storage and management of onboard service images. After each satellite 310 completes differential data reception, integrity verification, and differential restoration, it pushes the complete standardized image to the onboard public Registry320 via inter-satellite links. The public Registry320 then uses the image Digest verification mechanism to complete image deduplication, compliance verification, and unified version release.

[0018] The cluster Helm control plane 330 limits upgrade targets based on node labels, affinity, taint tolerance, or partition parameters, enabling the same chart to be applied to different satellites 310 in batches. Satellite nodes are divided into one or more upgrade batches according to their mission status, orbital phase, link reachability, and service dependencies. Nodes carrying high-priority payloads can have their upgrades postponed; nodes performing common Registry 320 or control plane functions can be upgraded after a primary / backup switchover.

[0019] In the multi-satellite collaborative distribution phase, this invention breaks through the traditional upgrade mode of acquiring the full upgrade package for a single satellite. The ground control terminal comprehensively considers the transit control window of each satellite 310, the quality of the satellite-to-ground link 200, local storage capacity, real-time computing load, on-board thermal control status, and on-orbit mission priority to intelligently generate a multi-satellite differentiated image distribution strategy. It distributes matching microservice images, independent image layers, or image fragments to different satellites 310 as needed, enabling parallel data reception from multiple satellites and multiple windows, laying the foundation for subsequent data aggregation and streamlined transmission.

[0020] Specifically, in the aggregation stage of the onboard public Registry320, this invention constructs a unified logical cluster from the onboard computing nodes of multiple satellites 310 based on the Kubernetes architecture. Within this cluster, one or more onboard public Registries320 and a dedicated HelmChart repository are deployed to achieve localized unified storage and management of onboard version images. After each satellite completes differential data reception, integrity verification, and differential restoration, it pushes the complete standardized image to the onboard public Registry320. The public Registry320 completes image deduplication, compliance verification, and unified version release through the image Digest verification mechanism, completely avoiding the problem of massive duplicate transmissions caused by a single satellite independently acquiring all images in traditional solutions. Combined with inter-satellite link data completion and aggregation capabilities, this significantly improves the satellite-to-ground data reuse rate, forming a highly efficient closed-loop link utilization system.

[0021] In the cluster batch upgrade process, this invention achieves refined upgrade management with controllable versions and risks. The cluster controller sets up a pre-verification mechanism, ensuring that the Helm batch upgrade execution plan is generated only after the target image digest within the public Registry320 is complete and compliant. This prevents version inconsistencies caused by incomplete image aggregation and establishes a closed loop for version consistency. Simultaneously, this method establishes a multi-dimensional batch control mechanism, using the single-batch node readiness ratio, Pod target digest consistency rate, service probe running status, and business telemetry data as core criteria for batch start / stop. If an upgrade anomaly occurs, subsequent upgrade batches are immediately frozen, and the faulty node is precisely rolled back, effectively curbing the spread of the fault within the cluster and forming a comprehensive risk control closed loop.

[0022] This invention innovatively transforms the traditional satellite OTA server, upgrading it into an integrated OTA management platform for cloud-native satellite computing clusters (300 units). It covers core information such as cluster version matrix, unified management of satellite nodes, microservices, container image tags, image digests, HelmChart versions, configuration versions, service dependencies, and rollback baselines. This provides a unique and standardized execution basis for multi-satellite upgrade scheduling, collaborative image distribution, chart rendering, cluster health checks, and differentiated version rollbacks. Building upon this, the invention establishes a three-way comparison and verification mechanism using ground version profiles, Registry indexes, and Kubernetes runtime environments. It abandons the traditional single standard of "success upon completion of the upgrade command," using complete consistency among the target version list, Registry storage content, and Pod runtime digests as the core criterion for successful upgrades. This constructs a traceable and verifiable closed-loop effect guarantee, significantly enhancing the cluster version consistency management effect.

[0023] In summary, the core technological breakthroughs of this invention include at least the following: overcoming the technical shortcomings of traditional OTA servers, such as their inability to adapt to multi-satellite K8s cluster scenarios and their inability to manage cloud-native images and HelmChart versions; achieving distributed multi-satellite resource integration based on K8s to build a cloud-native node cluster that can be uniformly scheduled and finely managed in batches; establishing a satellite-based public Registry320 and a dedicated HelmChart repository to achieve localized and intensive management of satellite-based version resources; adopting a multi-satellite differential reception and unified aggregation mode to fundamentally solve the problem of duplicate transmission of 200 satellite-to-ground links; relying on the cluster version matrix to achieve fine-grained Helm upgrade and rollback operations by satellite, service, and batch; and effectively reducing the storage resource consumption of satellite-based equipment through image layer deduplication and dual-version retention strategies.

[0024] Please continue to refer to this. Figure 2 The OTA upgrade method for the satellite-borne computing cluster of the present invention includes the following steps: Step S1: Establish a satellite cluster version matrix. The ground terminal obtains the current image digest, chart version, and node tag from the status returned by each satellite 310, forming an auditable cloud-native version status of the satellite cluster. The version matrix includes at least: satellite identifier, node name, node role, node tag, node orbit / batch information, microservice name, current image tag and digest, target image tag and digest, current HelmChart version, target HelmChart version, configuration version, ConfigMap / Secret summary, dependent services, number of service deployment replicas, upgrade batch, rollback version, health check strategy, current Pod running digest, whether the target image is ready in the public Registry 320, data source satellite or restore node, upgrade status, and failure reason. The core function of the version matrix is ​​to unify "which satellite, which service, what is the current version, what is the target version, where to get the image, when to upgrade, and where to roll back to in case of failure" into an auditable data table, serving as the sole basis for differentiated distribution, Helm rendering, health checks, and rollback.

[0025] Step S2: Calculate the multi-satellite differentiated distribution plan. Based on the window, link, resources, and task priority of each satellite 310, the system allocates microservice images, image layers, differential fragments, or chart packets to be received by each satellite 310, avoiding duplicate data reception by all satellites 310. During allocation, the receptive capacity and upgrade risk of each satellite 310 can be calculated first: longer windows, higher link rates, lower bit error rates, larger storage margins, more sufficient CPU temperature or margin, and lower current task priority are more suitable for receiving large images, common layers, or computationally intensive differential packets; satellites 310 with short windows, poor links, or currently executing high-priority tasks are only allocated small fragments, metadata, or delayed reception.

[0026] For example, if satellite A has a 12-minute window, 8Mbps link, 8GB of storage, and idle mission during this transit, it will be allocated large differential packets and the common base layer of svc1. If satellite B has only a 5-minute window, 3Mbps link, but its CPU is idle, it will be allocated small differential packets of svc2. If satellite C has a longer window but is executing a high-priority payload mission, it will only receive chart packets, signature lists, or a small number of low-I / O fragments. After A and B complete reception and reconstruction, they will push the complete image to the common Registry 320 via the inter-satellite link. C will then pull the target image from the common Registry 320 without occupying the satellite-to-ground link 200.

[0027] Step S3: Perform differentiated satellite-to-ground data injection. The ground end injects the corresponding data within the visible windows of different satellites 310. Each fragment carries at least the following information: service identifier, image digest, layer digest / object digest, fragment number, offset length, hash value, and signature reference. The corresponding fragment data includes, but is not limited to: microservice image differential packages, complete image layers, image layer fragments, HelmChart packages, Chart differential patches, ConfigMap / Secret configuration changes, upgrade lists, and signature files. The specific data transmitted depends on the task assigned to satellite 310: it could be a differential package for an entire service, several fragments of a single image layer, or simply Chart and configuration changes.

[0028] Step S4: Perform receive verification and differential restoration. Each satellite 310 locally verifies the received data. For microservice image differential packets, satellite 310 restores the target image based on the local original on-orbit image v1; for image layers or fragments, satellite 310 first completes the data required for the same target image, then generates the complete target OCI image layout locally or at a designated restoration node, and verifies the target image Digest again after restoration is completed.

[0029] Step S5: Push the new image to the onboard cluster public Registry 320. Each satellite 310 or designated restore node pushes the complete target image, verified by Digest, to the onboard public Registry 320. The onboard public Registry 320 maintains a deduplication index for image layers; the same layer is saved only once when referenced by multiple services or multiple satellite 310s. The onboard public Registry 320 retains at least the current stable version and the target version for each microservice.

[0030] Step S6: Synchronize the HelmChart repository or Chart package. The cluster Helm control plane 330 obtains the target Chart version and uniformly changes the image repository address referenced in the Chart to the onboard public Registry 320 address, locking the image tag and digest to the target value in the matrix. This is the most accurate method considering the actual onboard Registry address and available ports. In another implementation, the image repository address can also be modified during registration on the ground OTA management platform.

[0031] Step S7: Select Upgrade Batch. The system divides satellite node 310 into one or more upgrade batches based on satellite 310 mission status, orbital phase, link reachability, and service dependencies. Nodes carrying high-priority payload tasks can have their upgrades postponed; nodes undertaking common Registry 320 or control plane functions can be upgraded after a primary / backup switchover. High priority typically refers to tasks or nodes that affect satellite 310 safety, critical missions, or real-time service continuity, such as attitude and orbit control related support tasks, satellite management, telemetry, tracking and command communications, real-time payload imaging processing, inter-satellite routing and forwarding, emergency collision avoidance, and critical services in security patches.

[0032] Primary / standby switchover upgrade refers to upgrading nodes that undertake public Registry 320, Helm control plane 330, or critical services without directly shutting down the primary node. Instead, it first confirms that the standby node or replica has been synchronized and can take over the services, then switches the traffic or control responsibilities to the standby node, and then upgrades the original primary node.

[0033] Step S8: Perform a cluster Helm upgrade. The cluster Helm control plane 330 executes a Helm upgrade, limiting the upgrade targets by node labels, affinity, taint tolerance, or partition parameters, allowing the same Chart to be applied to different satellites 310 in batches. The batch application of the same Chart to different satellites 310 can be controlled through Kubernetes node labels, affinity, taint tolerance, partition parameters, or Chart values. Each satellite node 310 is pre-labeled, such as satellite=A, orbit=01, batch=canary, payload=idle. During the Helm upgrade, the Chart template renders the nodeSelector, nodeAffinity, tolerations, or partition parameters, allowing only the target batch of nodes to schedule the new version of Pods.

[0034] For example, if only satellite A is upgraded in the first batch: when performing a Helm upgrade, if batch=A or nodeSelectorsatellite=A is passed, the Chart will schedule the target version v2 Pods of service svc1 to satellite A, while satellites B / C will still maintain the v1 version Pods of svc1. After A passes the Pod status, probe, service telemetry, and Digest consistency checks, the second batch parameters are changed to satellite in [B,C] or batch=2, and the next Helm upgrade is executed.

[0035] In step S9, each satellite 310 pulls the image from the onboard public Registry 320. Satellite nodes 310 in the upgrade batch access the onboard public Registry 320 through efficient inter-satellite links or cluster networks to pull the complete target image that has undergone differential restoration and verification, without having to occupy the satellite-to-ground link 200 again.

[0036] Step S10: Perform a cluster health check. The system checks the Pod status, service topology, cross-satellite service calls, service probes, resource curves, and anomaly logs for each satellite 310. The health check results are written back to the cluster version matrix.

[0037] Step S11: Perform a differentiated rollback and record the failure results. If the upgrade of a satellite 310 or a microservice fails, the system only performs a Helm rollback on the failed node or service and pulls a stable version from the onboard public Registry 320; nodes that have passed the health check keep the target version running. The system records the failed satellite 310, the failed service, the reason for the failure, the rollback version, and the rollback result.

[0038] Service failures are typically identified at the service level, such as a Pod failing to pull the target image, a Pod failing to start, a CrashLoopBackOff, a discrepancy between the target Digest and the matrix, a failed readiness / liveness probe, a business interface timeout, critical exceptions appearing in logs, or resource curves exceeding thresholds. Any combination of these conditions can be considered a failed service.

[0039] Failure nodes are judged at the satellite node granularity of 310, which does not mean that the failure of any single service necessarily constitutes a failure node. If only a non-critical microservice fails, and the basic capabilities of other services and nodes are normal, only the failed service can be rolled back. If multiple critical services on the node fail, the node is NotReady, the kubelet is abnormal, the network is unreachable, the public Registry320 is inaccessible, resources are exhausted, or there is a node-level telemetry anomaly, any combination of these conditions is considered a failure node. In this case, the upgrade objects in this batch on the node will be rolled back and subsequent batches will be frozen.

[0040] Step S12: Upgrade results are transmitted back and the version matrix is ​​solidified. After each upgrade batch is completed, regardless of success or failure, the onboard control plane transmits the upgrade results, health check results, failure reasons, rollback results, upgrade times for each satellite (310), data sources, restore nodes, and verification results back to the ground-based OTA management platform 100. After all target batches pass the health check, the cloud-native OTA management platform 100 solidifies the target image Digest and target Chart versions as a new cluster stability baseline; if any batches fail, the ground-based OTA management platform 100 retains the failure records and regenerates subsequent compensation upgrade plans.

[0041] Compensatory upgrades refer to the process where, after an upgrade of a batch or a node fails, the entire cluster is not fully upgraded again. Instead, a new plan is generated based on the failure records to re-upgrade, restore, redeploy, or downgrade the failed components. The compensation targets can be failed services, failed satellite node 310, failed chart configurations, or versions that do not meet dependencies.

[0042] For example, if satellites A and B successfully upgrade svc2 to version v2, but satellite C fails to upgrade svc2 due to a mismatch between its Chart configuration parameters and C's node labels, the compensation plan is to regenerate Chartvalues ​​or ConfigMap patches adapted to C's node labels, sign them, and then only perform the compensation upgrade on that service on C. After compensation is complete, the compensation time, data source, verification results, and final version will be written back to the version matrix.

[0043] like Figure 3 As shown, in one embodiment, satellite A receives service A image differential packets, satellite B receives service B image differential packets, and satellite C receives service C image differential packets. After the three satellites 310 complete reception, verification, and differential restoration, they push the complete target image of the corresponding service to the onboard public Registry 320. The onboard public Registry 320 performs deduplication and digest verification on the image layer and publishes a unified image source. Subsequently, the cluster Helm control plane 330 performs rolling upgrades on satellites A, B, and C based on the target Chart version matrix. This embodiment enables the transit windows of multiple satellites 310 to be used in parallel for upgrade data reception, significantly reducing the link and storage pressure on specific satellites 310.

[0044] Through the above implementation methods, this invention achieves unified version management, differentiated satellite-to-ground distribution, differential restoration of each satellite's 310 layer, aggregation and release of the onboard public Registry 320, batch upgrades of the Kubernetes cluster, differentiated rollback, and feedback of upgrade success or failure results for multi-satellite Kubernetes clusters. It is suitable for on-orbit maintenance of commercial satellite 310 constellations with low bandwidth, short window, and inter-satellite collaboration. Compared to ground-based Kubernetes architectures and conventional OTA upgrade solutions, this invention achieves substantial and quantifiable technical improvements in satellite-to-ground link utilization, cluster upgrade efficiency, version consistency, and upgrade security, adapting to the complex operating conditions of multi-satellite constellation on-orbit upgrades. In terms of link optimization, in scenarios where multi-satellite mirrors can be reused, through multi-satellite complementary reception and a public Registry deduplication mechanism, the amount of duplicate data transmitted via the satellite-to-ground link is reduced by 50% to 90% compared to the traditional satellite-by-satellite full-transmission mode. The optimization range is determined by the proportion of the public mirror layer, the version difference ratio, and the inter-satellite link capacity. In terms of efficiency improvement, for constellation scenarios with staggered telemetry and control windows, the traditional serial full-download upgrade preparation mode is optimized into a multi-window parallel reception and inter-satellite collaborative patching and aggregation mode, which can significantly shorten the overall cluster upgrade preparation time. Regarding consistency assurance, relying on the public Registry's Digest index, reference counting, and version marking mechanism, the cluster image pull source is unified, avoiding version risks of heterogeneous images with the same name; combined with batch health gating and Digest consistency verification, it effectively ensures that the running version of cluster Pods after the upgrade is highly consistent with the ground target version list. In terms of security management, by limiting the maximum number of unavailable nodes in a single batch, the ready ratio threshold, and multi-dimensional telemetry judgment conditions, the impact of upgrade failures is constrained within the current batch, completely avoiding the cluster-wide paralysis problem caused by traditional full-upgrades. All technical gains of this invention can be verified statistically through quantitative indicators such as the number of bytes transmitted, image deduplication rate, batch upgrade time, ready node ratio, and Digest consistency rate.

[0045] Throughout this specification, references to "an embodiment," "an example," or "an example" mean that a particular feature, structure, or characteristic described in connection with that embodiment or example is included in at least one embodiment. Or, an example of the invention. Therefore, phrases such as "in one embodiment" or "in one example" appearing throughout this specification do not necessarily refer to the same embodiment or example. Furthermore, a particular feature, structure, or characteristic may be combined in any suitable manner in one or more embodiments or examples. Directional terms such as "top," "down," "above," and "below" are used to indicate the direction of reference to the described drawings. Furthermore, unless otherwise specifically stated, the terms "having," "comprising," "containing," and similar terms are defined as meaning "including." A particular feature, structure, or characteristic may be included in an integrated circuit, electronic circuit, combinational logic circuit, or other suitable component that provides the described functionality. Additionally, it should be understood that the drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0046] The above description of the illustrated examples of the invention (including those described in the abstract) is not intended to be exhaustive or limited to the precise forms disclosed. While specific embodiments and examples of the invention have been described herein for illustrative purposes, various equivalent modifications may be made without departing from the broader spirit and scope of the invention. Indeed, it should be understood that specific example structures and materials are provided for illustrative purposes, and other structures and materials may be used in other embodiments and examples based on the teachings of the invention. These modifications can be made to embodiments of the invention based on the above detailed description. The terminology used in the following claims should not be construed as limiting the invention to the specific embodiments disclosed in the specification and claims. Rather, the scope is determined entirely by the following claims, which should be interpreted according to the established principles of their interpretation.

Claims

1. An OTA upgrade method for a satellite-borne computing cluster, characterized in that, Includes the following steps: The current on-orbit image Digest, Chart version, and node label are obtained from the status returned by each satellite to form an auditable cloud-native version matrix of the satellite cluster. Calculate a multi-satellite differentiated distribution plan based on the satellite's window, link, resources, and mission priority, and allocate microservice images, image layers, or differential fragments and chart packets to be received for each satellite to avoid all satellites receiving the same data repeatedly. Perform differentiated satellite-to-ground injection, injecting the corresponding fragment data in the visible windows of different satellites respectively. Each fragment carries at least the following information: service identifier, image digest, layer digest or object digest, fragment number, offset length, hash value and signature reference. Each satellite verifies the received data and performs differential restoration locally. For microservice image differential packets, the satellite restores the target image based on the local original on-orbit image. For image layers or fragments, the satellite first completes the data required for the same target image, and then generates a complete target OCI image layout locally or at a designated restoration node. After the restoration is completed, the target image Digest is verified again. Push the newly restored target image to the onboard cluster's public registry; Based on the mission status, orbital phase, link reachability, and service dependencies of each satellite, satellite nodes are divided into one or more upgrade batches; Upgrade satellite nodes within the batch to access the onboard public Registry via inter-satellite links or cluster networks to pull the complete target image that has undergone differential restoration and verification.

2. The method as described in claim 1, characterized in that, The satellite cluster cloud-native version matrix includes at least: satellite identifier, node name, node role, node tag, node orbit or batch information, microservice name, current on-orbit image tag and digest, target image tag and digest, current HelmChart version, target HelmChart version, configuration version, ConfigMap or Secret summary, dependent services, number of service deployment replicas, upgrade batch, rollback version, health check policy, current Pod running digest, whether the target image is ready in the public Registry, data source satellite or restore node, upgrade status and failure reason.

3. The method as described in claim 1, characterized in that, The multi-satellite differentiated distribution plan first calculates the receptive capabilities and upgrade risks of each satellite when allocating resources: satellites with long windows, high link rates, low bit error rates, large storage margins, sufficient CPU temperature or margin, and low current task priority will receive large images, common layers, or differential packets with high computational load; satellites with short windows, poor links, or those performing high-priority tasks will only be allocated small fragments, metadata, or delayed reception.

4. The method as described in claim 1, characterized in that, The corresponding sharded data includes, but is not limited to: microservice image differential packages, full image layers, image layer shards, HelmChart packages, Chart differential patches, ConfigMap or Secret configuration changes, upgrade lists, signature files, etc.

5. The method as described in claim 1, characterized in that, When selecting upgrade batches, nodes carrying high-priority payload tasks are upgraded later; and / or, nodes undertaking common Registry or control plane functions are upgraded after primary / backup switchover; wherein, the high priority refers to tasks or nodes that affect satellite safety, critical missions, or real-time service continuity, including attitude and orbit control related support tasks, satellite management, telemetry and control communication, real-time payload imaging processing, inter-satellite routing and forwarding, emergency collision avoidance, critical services in security patches, etc.; the primary / backup switchover upgrade means that for nodes undertaking common Registry, Helm control plane, or critical services, the upgrade is not performed directly on the primary node, but rather the backup node or replica is first confirmed to be synchronized and capable of taking over services, then the traffic or control responsibilities are switched to the backup node, and then the original primary node is upgraded.

6. The method as described in claim 1, characterized in that, Pushing to the onboard public Registry includes: each satellite or designated restore node pushes the complete target image that has passed Digest verification to the onboard public Registry. The onboard public Registry maintains a deduplication index for the image layer. When the same layer is referenced by multiple services or multiple satellites, it is saved only once. The onboard public Registry retains at least the current stable version and the target version for each microservice.

7. The method as described in claim 1, characterized in that, It also includes the following steps: synchronizing the HelmChart repository or Chart package, where the cluster Helm control plane obtains the target Chart version, and uniformly changes the image repository address referenced in the Chart to the onboard public Registry address, and locks the image tag and Digest to the target value in the matrix.

8. The method as described in claim 1, characterized in that, It also includes the following steps: performing cluster Helm upgrades. When the cluster Helm control plane performs a helm upgrade, it limits the upgrade targets by node labels, affinity, taint tolerance, or partition parameters, so that the same chart can be applied to different satellites in batches.

9. The method as described in claim 8, characterized in that, By using Kubernetes node labels, affinity, taint tolerance, partition parameters, or chart values, the same chart can be applied to different satellites in batches. Each satellite node is pre-labeled. When Helm upgrades, the chart template renders nodeSelector, nodeAffinity, tolerations, or partition parameters, allowing only the target batch of nodes to schedule the new version of Pods.

10. The method as described in claim 1, characterized in that, It also includes the following steps: performing cluster health checks, checking the Pod status, service topology, cross-satellite service calls, business probes, resource curves and anomaly logs of each satellite, and writing the health check results back to the cluster version matrix.

11. The method as described in claim 10, characterized in that, It also includes the following steps: performing differentiated rollback and recording failure results. If a satellite or microservice upgrade fails, the system only performs helmrollback on the failed node or service and pulls a stable version from the onboard public Registry. Nodes that have passed the health check keep the target version running, and the system records the failed satellite, failed service, failure reason, rollback version, and rollback result.

12. The method as described in claim 111, characterized in that, Failed services are judged at the service granularity, including Pods failing to pull the target image, Pods failing to start, CrashLoopBackOff, target Digest not matching the matrix, readiness or liveness probe failure, business interface timeout, and / or logs showing critical exceptions or resource curves exceeding thresholds. Any combination of these conditions is considered a failed service. Failed nodes are judged at the satellite node granularity. If only a few non-critical microservices fail, and the basic capabilities of other services and nodes are normal, only the failed service is rolled back. If multiple critical services on a node fail, the node is NotReady, the kubelet is abnormal, the network is unreachable, the public registry is inaccessible, resources are exhausted, or there is a node-level telemetry anomaly, any combination of these conditions will result in the satellite node being deemed a failed node. In this case, the upgrade objects in this batch on that node will be rolled back and subsequent batches will be frozen.

13. The method as described in claim 12, characterized in that, The process also includes the following steps: transmitting upgrade results and solidifying the version matrix. After each upgrade batch is completed, the onboard control plane transmits the upgrade results, health check results, failure reasons, rollback results, upgrade time of each satellite, data source, restore node, and verification results back to the ground OTA management platform. After all target batches pass the health check, the cloud-native ground OTA management platform solidifies the target image Digest and target Chart versions into a new cluster stability baseline. When there are failed batches, the ground OTA management platform retains the failure records and regenerates the subsequent compensation upgrade plan.

14. An OTA upgrade system for a satellite-borne computing cluster, suitable for executing the OTA upgrade method as described in any one of claims 1-13, characterized in that, The system includes a cloud-native ground OTA management platform, multiple satellite-to-ground links, and a satellite-borne computing cluster. The ground OTA management platform includes a ground packet production and scheduling module. The satellite-borne computing cluster includes multiple satellite nodes, a satellite-borne cluster public Registry, a cluster Helm control plane, and inter-satellite links. The multiple satellite nodes include microservice Pods on each satellite.

15. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 13.

Images