A lightweight container base construction method, system, terminal and medium for a satellite computing node

Abstract

The application discloses a lightweight container base construction method, system, terminal and medium for a satellite-borne computing node, and the method comprises the following steps: removing a virtual machine layer, adopting a bare metal container deployment mode, installing a host operating system on the physical hardware of the satellite-borne computing node, deploying a Kubernetes node component on the host operating system, and obtaining a basic framework; according to the running requirements of the basic framework, retaining necessary components in the Kubernetes node component, trimming unnecessary components, and completing lightweight construction verification to obtain a lightweight architecture; and performing constraint configuration on the running parameters of the lightweight architecture to obtain a lightweight base suitable for the satellite-borne computing node. The application adopts the bare metal container deployment by removing the virtual machine layer and builds the Kubernetes basic framework based on the satellite-borne hardware, forms a special lightweight base through component trimming, lightweight verification and running parameter constraint configuration, and effectively reduces the satellite-borne computing resource overhead, reduces system redundancy loss, and improves the deployment running real-time performance and resource utilization.

Description

Technical Field

[0001] This invention relates to the field of spaceborne computing technology, and in particular to a method, system, terminal, and medium for constructing a lightweight container base for spaceborne computing nodes. Background Technology

[0002] Against the backdrop of real-time processing of onboard payload data and the large-scale deployment of onboard cloud-native applications, building an operational platform that combines low resource overhead with general-purpose container virtualization management capabilities has become a key direction for overcoming the resource constraints of onboard computing nodes and supporting the iterative upgrade of space-based intelligent services. It is also a current research focus in the fields of onboard computing architecture optimization and space-based cloud-native technologies. Onboard computing nodes have limited total CPU, memory, and disk hardware resources. They must meet the needs of isolated operation, modular deployment, and refined resource scheduling and management for various payload services and onboard data processing programs, while strictly controlling the resource consumption ratio of the virtualization underlying layer itself and reserving sufficient hardware resources to support actual onboard services. Therefore, a balanced design of lightweight and universal virtualization operating environments is increasingly crucial. However, in practical onboard engineering implementation, existing virtualization architectures using different approaches all have significant compatibility shortcomings, making it difficult to simultaneously achieve low overhead and general-purpose cloud-native operating capabilities. Traditional cloud-native architectures in terrestrial data centers typically employ a three-tier deployment model of physical machines, virtual machines, and containers, coupled with a complete Kubernetes component system. While relying on the virtual machine layer to achieve strong isolation and multi-tenant scheduling, the virtual machine monitoring program and guest operating systems generate enormous resource consumption. Furthermore, numerous terrestrial-specific resident components within the complete cluster system, such as traffic management, load balancing, and cluster monitoring, continuously consume node computing power and storage, directly leading to excessive overhead in the virtualization infrastructure itself, making it unsuitable for resource-scarce spaceborne hardware environments. While traditional spaceborne dedicated operating systems and embedded real-time systems possess advantages such as small size and strong deterministic operation, they are also suitable for… While meeting the operational requirements of fixed-mode on-board missions, the overall architecture leans towards mission-customized design, lacking core cloud-native capabilities such as container encapsulation, environment isolation, and flexible deployment of general applications. This makes it unsuitable as a general-purpose virtualization platform adaptable to various types of on-board applications. Existing lightweight Kubernetes solutions for ground-based edge scenarios, while simplifying some redundant modules and reducing system overhead to a certain extent, still rely on ground-based edge nodes for component selection and default operating parameters. They lack in-depth customized pruning and parameter constraint optimization for onboard hardware resource thresholds, resulting in resource waste due to redundant pre-installed plugins, unlimited Pod scheduling, and disordered log image scaling. In summary, the three existing mainstream technologies suffer from inherent defects: excessive virtualization overhead, lack of general-purpose virtualization capabilities, and insufficient depth of adaptation to onboard scenarios. They struggle to simultaneously achieve extremely low base resource consumption and standardized container scheduling and application isolation deployment on onboard computing nodes, making the construction of a lightweight cloud-native virtualization operating system adapted to onboard resource constraints a significant technical barrier.

[0003] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a lightweight container base construction method, system, terminal and medium for spaceborne computing nodes, addressing the above-mentioned deficiencies of the prior art. This invention aims to solve the problems of excessive overhead of existing traditional cloud-native architectures on the ground, lack of cloud-native general virtualization capabilities in traditional spaceborne embedded systems, and insufficient adaptation depth of edge lightweight Kubernetes solutions to spaceborne scenarios. These issues prevent the invention from simultaneously achieving extremely low resource overhead of virtualization bases and container isolation, standardized scheduling and flexible deployment of general applications on spaceborne hardware with limited resources.

[0005] 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 a method for constructing a lightweight container base for spaceborne computing nodes, wherein the method includes: By removing the virtual machine layer and adopting a bare metal container deployment method, the host operating system is installed on the physical hardware of the onboard computing node, and Kubernetes node components are deployed on the host operating system to obtain the infrastructure. Based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are removed, and lightweight build verification is completed to obtain a lightweight architecture. By constraining and configuring the operating parameters of the lightweight architecture, a lightweight base suitable for onboard computing nodes is obtained.

[0006] In one implementation, based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are removed, and lightweight build verification is completed to obtain a lightweight architecture, including: Based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, and unnecessary components are removed to obtain a streamlined component; The simplified components were built and verified to achieve a lightweight architecture.

[0007] In one implementation, the necessary components include: a container runtime, a node management component, a service proxy component, a cross-node network plugin, and a cluster domain name resolution component.

[0008] In one implementation, the trimming of unnecessary components includes: Unnecessary components are disabled during startup and are trimmed during source code building and packaging.

[0009] In one implementation, the lightweight construction verification of the simplified components to obtain a lightweight architecture includes: The simplified components are recompiled and packaged to obtain lightweight components; Based on lightweight components, the basic capabilities of the current architecture are verified. If the verification passes, a lightweight architecture is obtained.

[0010] In one implementation, the constraint configuration of the lightweight architecture operating parameters includes: constraint configuration of the number of Pods, log space, image storage, and resource reclamation.

[0011] In one implementation, after obtaining the lightweight base suitable for onboard computing nodes, the method further includes: In an idle state, the CPU, memory, and disk resource usage of the components in the lightweight architecture are statistically analyzed to obtain the basic overhead of the lightweight base itself.

[0012] Secondly, embodiments of the present invention also provide a lightweight container base construction system for spaceborne computing nodes, wherein the system includes: The infrastructure acquisition module is used to remove the virtual machine layer, adopt a bare metal container deployment method, install the host operating system on the physical hardware of the on-board computing node, and deploy Kubernetes node components on the host operating system to obtain the infrastructure. The lightweight architecture acquisition module is used to retain the necessary components in the Kubernetes node components, trim the unnecessary components, and complete the lightweight build verification based on the operational requirements of the infrastructure to obtain a lightweight architecture. The lightweight base acquisition module is used to constrain and configure the operating parameters of the lightweight architecture to obtain a lightweight base suitable for onboard computing nodes.

[0013] Thirdly, embodiments of the present invention also provide a terminal, wherein the terminal includes a memory, a processor, and a lightweight container docking station construction program for spaceborne computing nodes stored in the memory and executable on the processor. When the processor executes the lightweight container docking station construction program for spaceborne computing nodes, it implements the steps of the lightweight container docking station construction method for spaceborne computing nodes as described in any of the above schemes.

[0014] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a lightweight container docking station construction program for spaceborne computing nodes, and when the lightweight container docking station construction program for spaceborne computing nodes is executed by a processor, it implements the steps of the lightweight container docking station construction method for spaceborne computing nodes as described in any of the above schemes.

[0015] Beneficial Effects: This invention provides a lightweight container platform construction method for spaceborne computing nodes. Compared with existing technologies, this invention first removes the virtual machine layer and adopts a bare-metal container deployment method. A host operating system is installed on the physical hardware of the spaceborne computing node, and Kubernetes node components are deployed on the host operating system to obtain the infrastructure. This effectively avoids the performance loss, high resource consumption, and large scheduling latency problems caused by the virtual machine layer, fully releasing the native computing performance of the spaceborne hardware, and conforming to the basic operating scenario of limited hardware resources and high real-time requirements of spaceborne equipment. Next, based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are trimmed, and lightweight construction verification is completed to obtain a lightweight architecture. This significantly reduces the resource overhead of the architecture, reduces program runtime memory consumption and startup time, making the overall architecture more streamlined and efficient, and adapting to the special operating conditions of limited resources and complex working conditions in the spaceborne environment. Finally, the operating parameters of the lightweight architecture are constrained and configured to obtain a lightweight platform suitable for spaceborne computing nodes, effectively preventing the virtualization system from consuming too many resources during long-term operation due to excessive Pod count, continuous log growth, image cache accumulation, or temporary file accumulation. Overall, this invention, through a progressive design of layer-by-layer architecture simplification, component optimization, and parameter adaptation, overcomes the shortcomings of traditional container virtualization architectures, such as bloat, inefficiency, resource waste, and poor adaptability when adapting to spaceborne scenarios. While maximizing the computing power of spaceborne physical hardware and reducing system power consumption and resource consumption, it effectively improves the operational stability, real-time performance, and environmental adaptability of the spaceborne computing platform. It can better meet the core business needs of complex on-orbit computing, dynamic task scheduling, and long-term stable operation of satellites, providing solid underlying technical support for the efficient and reliable implementation of spaceborne computing tasks. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a specific implementation method for constructing a lightweight container base for onboard computing nodes, as provided in an embodiment of the present invention.

[0017] Figure 2 This is a comparison diagram of the traditional three-layer virtualization architecture and the bare metal virtualization architecture in the lightweight container base construction method for onboard computing nodes provided in the embodiments of the present invention.

[0018] Figure 3 This is a schematic diagram of a lightweight container base construction system for spaceborne computing nodes provided in an embodiment of the present invention.

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

[0020] 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.

[0021] Against the backdrop of real-time processing of onboard payload data and the large-scale deployment of onboard cloud-native applications, building an operational platform that combines low resource overhead with general-purpose container virtualization management capabilities has become a key direction for overcoming the resource constraints of onboard computing nodes and supporting the iterative upgrade of space-based intelligent services. It is also a current research focus in the fields of onboard computing architecture optimization and space-based cloud-native technologies. Onboard computing nodes have limited total CPU, memory, and disk hardware resources. They must meet the needs of isolated operation, modular deployment, and refined resource scheduling and management for various payload services and onboard data processing programs, while strictly controlling the resource consumption ratio of the virtualization underlying layer itself and reserving sufficient hardware resources to support actual onboard services. Therefore, a balanced design of lightweight and universal virtualization operating environments is increasingly crucial. However, in practical onboard engineering implementation, existing virtualization architectures using different approaches all have significant compatibility shortcomings, making it difficult to simultaneously achieve low overhead and general-purpose cloud-native operating capabilities. Traditional cloud-native architectures in terrestrial data centers typically employ a three-tier deployment model of physical machines, virtual machines, and containers, coupled with a complete Kubernetes component system. While relying on the virtual machine layer to achieve strong isolation and multi-tenant scheduling, the virtual machine monitoring program and guest operating systems generate enormous resource consumption. Furthermore, numerous terrestrial-specific resident components within the complete cluster system, such as traffic management, load balancing, and cluster monitoring, continuously consume node computing power and storage, directly leading to excessive overhead in the virtualization infrastructure itself, making it unsuitable for resource-scarce spaceborne hardware environments. While traditional spaceborne dedicated operating systems and embedded real-time systems possess advantages such as small size and strong deterministic operation, they are also suitable for… While meeting the operational requirements of fixed-mode on-board missions, the overall architecture leans towards mission-customized design, lacking core cloud-native capabilities such as container encapsulation, environment isolation, and flexible deployment of general applications. This makes it unsuitable as a general-purpose virtualization platform adaptable to various types of on-board applications. Existing lightweight Kubernetes solutions for ground-based edge scenarios, while simplifying some redundant modules and reducing system overhead to a certain extent, still rely on ground-based edge nodes for component selection and default operating parameters. They lack in-depth customized pruning and parameter constraint optimization for onboard hardware resource thresholds, resulting in resource waste due to redundant pre-installed plugins, unlimited Pod scheduling, and disordered log image scaling. In summary, the three existing mainstream technologies suffer from inherent defects: excessive virtualization overhead, lack of general-purpose virtualization capabilities, and insufficient depth of adaptation to onboard scenarios. They struggle to simultaneously achieve extremely low base resource consumption and standardized container scheduling and application isolation deployment on onboard computing nodes, making the construction of a lightweight cloud-native virtualization operating system adapted to onboard resource constraints a significant technical barrier.

[0022] To address the aforementioned issues, this embodiment provides a method for constructing a lightweight container platform for onboard computing nodes. Specifically, this embodiment first removes the virtual machine layer and employs a bare-metal container deployment approach. A host operating system is installed on the physical hardware of the onboard computing node, and Kubernetes node components are deployed on the host operating system to obtain the infrastructure. This effectively avoids the performance degradation, high resource consumption, and large scheduling latency issues caused by the virtual machine layer, fully releasing the native computing performance of the onboard hardware and catering to the basic operational scenarios of limited hardware resources and high real-time requirements of onboard equipment. Next, based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are trimmed, and lightweight construction verification is completed to obtain a lightweight architecture. This significantly reduces the architecture's resource overhead, decreases program runtime memory consumption and startup time, making the overall architecture more streamlined and efficient, and adaptable to the special operating conditions of the onboard environment with limited resources and complex operating conditions. Finally, the operating parameters of the lightweight architecture are constrained and configured to obtain a lightweight platform suitable for onboard computing nodes, effectively preventing the virtualization system from consuming excessive resources during long-term operation due to an excessive number of Pods, continuous log growth, image cache accumulation, or temporary file accumulation. Overall, this invention, through a progressive design of layer-by-layer architecture simplification, component optimization, and parameter adaptation, overcomes the shortcomings of traditional container virtualization architectures, such as bloat, inefficiency, resource waste, and poor adaptability when adapting to spaceborne scenarios. While maximizing the computing power of spaceborne physical hardware and reducing system power consumption and resource consumption, it effectively improves the operational stability, real-time performance, and environmental adaptability of the spaceborne computing platform. It can better meet the core business needs of complex on-orbit computing, dynamic task scheduling, and long-term stable operation of satellites, providing solid underlying technical support for the efficient and reliable implementation of spaceborne computing tasks.

[0023] The lightweight container base construction method for spaceborne computing nodes provided in this embodiment can be applied to smart terminals, such as... Figure 1 As shown, the specific steps include the following: Step S100: Remove the virtual machine layer and adopt a bare metal container deployment method. Install the host operating system on the physical hardware of the onboard computing node, and deploy Kubernetes node components on the host operating system to obtain the infrastructure.

[0024] In this embodiment, as Figure 2As shown, the traditional three-tier virtualization deployment architecture of "physical machine-virtual machine-container" is abandoned. Instead, a bare metal container deployment structure is adopted to build the infrastructure of the onboard computing node. First, the host operating system is installed and deployed on the physical hardware of the onboard computing node to complete the initialization of the underlying system environment. Then, the corresponding Kubernetes node components, containerd container runtime, and lightweight virtualization components are directly deployed inside the host operating system. Relying on Kubernetes, a PaaS management platform is formed to complete the overall scheduling and management of the container cluster. Relying on the containerd container runtime, the underlying execution capabilities of container lifecycle management, image pulling, and container start and stop are provided. Subsequently, business containers can run directly in the container environment built by the host operating system based on the container runtime. This deployment method completely eliminates the QEMU+KVM virtual machine monitor, virtual machine instances, and corresponding customer virtual machine operating system layers in the traditional three-tier architecture. At the same time, it no longer deploys an OpenStack-type IaaS management platform for virtual machine management. Considering that the total amount of hardware resources per node on the satellite computing node is limited, the margin available for virtual machine resource partitioning, scheduling, and reuse is already small. During the operation of the virtual machine layer, it will continuously generate resident resource consumption in terms of CPU, memory, and disk. After removing the entire set of virtual machine-related layers, the fixed resource overhead generated by the virtualization base itself can be effectively reduced, and the resource consumption of the virtualization system itself can be compressed. Containers no longer need to be forwarded and scheduled through the virtual machine intermediate layer, and the operation chain is more streamlined. Under the condition of limited satellite hardware resources, more hardware resources can be allocated to upper-layer business containers, improving the overall resource utilization efficiency of the satellite computing node.

[0025] Step S200: Based on the operational requirements of the infrastructure, retain the necessary components in the Kubernetes node components, trim the unnecessary components, and complete the lightweight build verification to obtain a lightweight architecture.

[0026] In this embodiment, the actual operational needs of the infrastructure are used as the core basis for a comprehensive review and identification of Kubernetes node components. The core, essential components that ensure normal cluster scheduling, node operation, and business load balancing are precisely selected. Retaining these fundamental components maximizes the preservation of the cluster's core operational capabilities, ensuring that core functions such as basic cluster services, resource scheduling, and node management are not missing or malfunctioning during the lightweight transformation process, thus guaranteeing the stability and continuity of business operations. Based on this, redundant, idle, and non-core unnecessary components in the nodes are systematically pruned. Eliminating useless components not only effectively reduces the resource consumption of Kubernetes nodes and minimizes the ineffective consumption of memory, computing power, and storage resources, but also simplifies the node operation chain, reduces redundant interactions and conflicts between components, and lowers the risk of cluster failures and operational complexity. Subsequently, lightweight construction verification is carried out to confirm that the pruned component architecture can run stably, with normal core function adaptation, accurate resource scheduling, and reliable node operation. This timely avoidance of adaptation problems and operational risks caused by the pruning operation ensures the feasibility and effectiveness of the lightweight transformation solution. Through a complete process of component identification and retention, redundant component pruning, and architecture construction and verification, the lightweight iterative optimization of the Kubernetes architecture was completed. While fully meeting the basic requirements for infrastructure operation, the overall cluster architecture was simplified, node resource utilization was improved, cluster deployment and operation costs were reduced, and cluster operation performance and operation efficiency were optimized. Ultimately, a streamlined, efficient, stable, and low-power lightweight Kubernetes architecture was built, which is better adapted to lightweight deployment scenarios and the high-efficiency operation requirements of the infrastructure.

[0027] Specifically, step S200 includes the following steps: Step S201: Based on the operational requirements of the infrastructure, retain the necessary components in the Kubernetes node components and trim the unnecessary components to obtain a streamlined set of components; Step S202: Perform lightweight construction verification on the simplified components to obtain a lightweight architecture.

[0028] In one implementation, firstly, based on the actual operational requirements of the onboard computing node infrastructure, Kubernetes node components are layered and filtered, precisely retaining the essential components indispensable for containerized business operations, while selectively cutting out various unnecessary components to streamline the virtualization component system. Specifically, the retained essential components include the container runtime containerd, the node management component kubelet, the service proxy component kube-proxy, the cross-node network plugin flannel, and the cluster domain name resolution component CoreDNS. Each component undertakes core basic capabilities: containerd provides complete container runtime capabilities, implementing container image management and basic operations such as container creation, startup, and shutdown; kubelet handles node-level container management, receiving cluster scheduling commands, managing the entire Pod lifecycle, and reporting node running status in real time; kube-proxy provides basic service forwarding capabilities, ensuring normal service access between containers; flannel builds the basic container network environment, ensuring normal cross-node communication between Pods; and CoreDNS provides basic service discovery and domain name resolution capabilities. This is achieved by retaining the entire set of essential components. The entire architecture fully supports core functions such as container operation, Pod management, container network communication, service forwarding, and service discovery, fully meeting the basic requirements for containerized deployment and operation of onboard business applications. On this basis, this solution abandons the extensive optimization approach of completely removing cloud-native components, and only removes redundant capabilities in the limited operation scenarios of onboard computing nodes. It accurately identifies unnecessary additional components such as Traefik, ServiceLB, metrics-server, local-storage, helm-controller, and network-policy as the objects to be trimmed. These components can respectively implement functions such as ingress traffic management, service load balancing, resource monitoring, local default storage, Helm application management, and network policy control in ground data centers and complex edge clusters. However, onboard computing nodes have the characteristics of limited node scale, single business type, and fixed service form. The above-mentioned complex governance, multi-tenancy, and large-scale cluster adaptation functions are not essential conditions for the operation of containerized business. Fully retaining these components will increase the number of resident processes, background control logic, software dependencies, and installation package size, significantly increasing the resource consumption of the virtualization base. To address this issue, this solution involves two phases to eliminate and optimize unnecessary components. In the first phase, all unnecessary components are disabled by configuring component startup parameters. During the deployment of lightweight virtualization components, startup parameters are adjusted to prevent redundant components such as Traefik and ServiceLB from starting and loading, thereby directly reducing the resource consumption of the system during runtime.The second phase involves deep pruning during source code building and packaging. This involves completely removing redundant component startup points, default configuration files, code dependencies, and packaging-related content. These unnecessary components are no longer involved in the compilation, packaging, and installation process of the virtualization system, further reducing runtime costs and minimizing system memory and disk storage usage. After component simplification and deep pruning, the optimized components are recompiled and packaged to generate lightweight components adapted for onboard scenarios. A lightweight architecture prototype is then built based on these lightweight components, and comprehensive verification of the architecture's fundamental capabilities is conducted. The focus is on verifying the availability of core capabilities such as container startup, Pod creation and deletion, container network connectivity, service discovery, and basic service forwarding. Only when all fundamental capabilities meet the onboard business operation standards is a stable and usable lightweight Kubernetes architecture finally formed. The entire optimization approach is based on the dedicated operating scenario of onboard computing nodes. While ensuring the core operating capabilities of containerized services to 100%, it simplifies redundant functions and components adapted to ground clusters, effectively reduces resident processes and redundant control logic, and significantly reduces CPU, memory, and disk resource consumption during architecture operation, thereby achieving a lightweight and efficient upgrade of cloud-native virtualization architecture in onboard scenarios.

[0029] Step S300: Configure the constraints on the lightweight architecture's operating parameters to obtain a lightweight base suitable for onboard computing nodes.

[0030] In this embodiment, considering the hardware resource characteristics of the onboard computing node and its long-term stable operation requirements in orbit, after trimming the virtualization system components, comprehensive constraints are configured on the lightweight architecture's operating parameters to optimize adaptation to the onboard scenario and build a resource-controllable lightweight foundation for the onboard computing node. The core of this configuration method is to specifically constrain various operating parameters of the virtualization system based on the CPU, memory, and disk capacity of the onboard computing node. This avoids excessive resource consumption and system instability caused by excessive Pod counts, continuous log growth, image cache accumulation, and temporary file accumulation during long-term on-orbit operation of the virtualization system. Specifically, parameter constraints are implemented from three dimensions: Pod count, log space, and image storage and resource reclamation. Resource reclamation and operational status detection mechanisms are also added to comprehensively ensure controllable and stable system resources. Regarding the maximum Pod count configuration, the maximum number of Pods a node can support is set based on the number of CPU cores and memory capacity of the onboard computing nodes, as well as the pre-planned scale of onboard services. This differs from the high default Pod count configuration of terrestrial Kubernetes and is adapted to the operational characteristics of pre-planned onboard services and fixed scenarios. Specifically, the following rule of thumb can be followed: Maximum Pod count = min(CPU core count × 4, memory capacity in GB × 2, maximum number of Pods planned for a single onboard service). This accurately matches hardware resources with business needs. It is recommended that the maximum number of Pods for onboard nodes with 2 CPU cores and 4GB of memory be controlled between 4 and 8, the maximum number of Pods for nodes with 4 CPU cores and 8GB of memory be controlled between 8 and 16, and the maximum number of Pods for nodes with 8 CPU cores and 16GB of memory be controlled between 16 and 32. Limiting this parameter can effectively avoid problems such as scheduling lag and excessive management overhead caused by an excessive number of containers. Regarding log space configuration, fine-grained space quota management is implemented for both system logs and container logs to prevent the problem of logs growing infinitely and filling up disk space. For system logs, parameters are configured through systemd-journald. The SystemMaxUse parameter is set to control the maximum space occupied by system logs to around 200MB, the SystemKeepFree parameter is set to ensure that the system reserves a minimum of 100MB of free space, the SystemMaxFileSize parameter is set to limit the maximum size of a single log file to around 50MB, and the SystemMaxFiles parameter is set to control the number of log files retained to around 5. At the same time, a regular log cleanup strategy is implemented to routinely clean up the overall log space to around 50MB. For container logs, constraints are imposed through kubelet or container runtime parameters to limit the size of a single container log file to 20-50MB and retain 3-5 historical log files, effectively avoiding the continuous consumption of disk resources caused by a single container continuously outputting logs for a long time.In terms of image storage and resource reclamation configuration, multiple parameters are used to constrain and control disk resource usage, clean up invalid and redundant data, and automatically clean up idle and invalid images when the image storage usage ratio exceeds the set value by setting an image garbage collection threshold. At the same time, the continuous expansion and growth of the container runtime cache directory is limited, and stopped containers, invalid snapshots and various temporary data are cleaned up in batches on a regular basis. The capacity status of container runtime data directories such as containerd is continuously monitored, and a disk reservation space threshold is set according to the node disk capacity to fundamentally prevent invalid images, cache files and residual runtime data from occupying disk space for a long time and prevent the virtualization system from exhausting disk resources. On this basis, a resource reclamation and runtime status detection mechanism is added. By periodically detecting the CPU, memory and disk resource usage of the virtualization system itself, automatic response and handling of resource anomalies are realized. When the virtualization system memory usage exceeds the set threshold, it automatically checks whether there are any unnecessary components that have started abnormally. When log resource usage exceeds the standard, log cleanup operations are automatically triggered. When image cache usage reaches the threshold, the image reclamation process is initiated. When the number of existing Pods is close to the maximum number of Pods on the node, the creation requests of low-priority containers are actively restricted. Overall, this solution comprehensively regulates the resource usage behavior of the virtualization system at the operational level through multi-dimensional and refined constraints on virtualization system operating parameters. It reduces system scheduling and management overhead by precisely matching hardware and business resources through Pod quota limits, curbs the disorderly growth of log resources through full-dimensional log space control, releases disk space through normalized image and redundant resource reclamation, and combines periodic resource detection and dynamic adjustment mechanisms to ensure that the onboard virtualization system maintains stable and controllable resource usage during long-term on-orbit operation, adapting to the high reliability and long-term steady-state operation requirements of onboard computing nodes.

[0031] In one implementation, after obtaining a lightweight base adapted to the onboard computing nodes, the lightweight effect can be verified using a dedicated resource overhead detection method. This method focuses on the virtualization base itself rather than the load of various business applications, accurately eliminating interference from business loads and providing a true reflection of the base's resource consumption level. The specific detection process must be conducted under no-load conditions. By statistically analyzing the CPU, memory, and disk resource usage of each virtualization component in the lightweight architecture, the basic overhead required for the lightweight base to operate is obtained. CPU and memory resource usage data can be collected directly by calling the resource statistics interface provided by the operating system kernel. Using conventional kernel tools such as cgroup mechanisms, process statistics interfaces, or kernel resource statistics files, the real-time CPU and memory usage of virtualization components can be accurately read. The native statistical capabilities of the operating system kernel ensure the accuracy and real-time nature of the data, intuitively reflecting the core operating overhead of the base. Disk resource usage is obtained by statistically analyzing the storage space usage of the installation directory, running directory, container runtime directory, log directory, and image directory of the virtualization components, comprehensively covering all disk resource scenarios required for base operation and providing a complete statistical analysis of the base's basic disk overhead. By employing the aforementioned comprehensive statistical methods for idle resource data, the basic resource overhead of the lightweight virtualization platform of this invention can be accurately calculated. Simultaneously, a horizontal comparison can be made between the resource overhead differences between traditional virtualization platform solutions and the solution of this invention under idle conditions. This allows for direct verification of whether the spaceborne lightweight platform designed in this invention achieves the low-overhead virtualization design goal, fully highlighting the core advantages of the solution—lightweight and low-load—and adapting to operating scenarios where spaceborne computing node resources are limited.

[0032] Taking a single onboard computing node as an example, the lightweight virtualization method proposed in this invention will be explained. Using an onboard computing node configured with a 4-core CPU, 8GB of memory, and 100GB of disk capacity as the application object, this invention's lightweight virtualization method abandons the traditional virtual machine layer architecture and adopts a bare-metal container deployment method to achieve lightweight virtualization deployment. First, the basic architecture is built by installing a Linux host operating system on the physical hardware of the onboard computing node. Then, the containerd container runtime and basic Kubernetes node components are deployed on the host operating system, completing the basic runtime environment setup for the node and enabling the node to have basic container running capabilities, thus constructing the virtualization infrastructure of the onboard computing node. Based on this, and considering the operational characteristics of single-operation scenarios for onboard computing nodes, the absence of complex governance of ground-based cloud-native services, and multi-tenant cluster management, lightweight trimming and reconstruction were carried out on the deployed Kubernetes virtualization components. First, unnecessary redundant components such as the Traefik ingress traffic management component, ServiceLB service load balancing component, metrics-server resource monitoring component, local-storage local storage component, helm-controller application management component, and network-policy network policy component were identified and determined. Then, these components were deeply optimized at the source code level, removing the corresponding component startup entry and initialization logic, deleting related dependencies and functional modules, modifying the system build configuration to prevent redundant components from participating in compilation, and clearing related configuration items in the default configuration file. After completing the trimming and optimization, the virtualization components were recompiled and packaged to generate a lightweight virtualization component version. At the same time, runtime parameter constraints were used to prevent residual functions from being accidentally triggered, thus completing the construction of the lightweight architecture. To further manage system resource consumption and adapt to scenarios with limited onboard node resources, the optimized lightweight architecture was configured with refined operating parameters. For hardware specifications of 4-core CPU and 8GB memory, the maximum number of Pods per node was set to 8-16 to avoid scheduling pressure and resource redundancy caused by too many Pods. At the same time, log resource parameters were configured to limit the maximum system log space to approximately 200MB, ensure that the node has no less than 100MB of free space, set the maximum size of a single log file to approximately 50MB, and the size of a single container log file to 20-50MB. The system retains 3-5 historical log files. In addition, an image recycling threshold was set to regularly clean up invalid images, stop containers and various temporary data, and control the growth of the container runtime data directory, thus building a resource-controllable and low-overhead onboard lightweight virtualization operating platform.Finally, a comprehensive operational verification of the entire lightweight virtualization system was conducted. The operational status of core functions such as container start-up and shutdown, Pod creation and deletion, container network communication, and service discovery were tested in sequence. The system's CPU and memory usage data under idle conditions were collected through the operating system kernel resource statistics interface. The test results showed that the CPU usage of the lightweight virtualization system under idle conditions was approximately 18.8 mCPU, and the memory usage was approximately 190MB. The availability ratio of node CPU, memory, and disk resources all exceeded 90%, effectively achieving low-overhead and high-availability virtualization operation under the condition of limited on-board node resources.

[0033] At the experimental verification level, this invention uses a computing node configured with a 4-core CPU, 8GB of memory, and 100GB of disk capacity as a unified test object to specifically compare the resource consumption performance of traditional virtualization solutions and the lightweight solution of this invention. The traditional comparison solution employs a three-layer architecture of "physical machine-virtual machine-container" and deploys Kubernetes virtualization components. To ensure fairness in the comparison experiment, the virtual machine is set to a minimum overhead configuration, and the test is conducted by virtualizing the entire physical machine as a single virtual machine. In contrast, the solution of this invention uses a bare-metal container deployment mode, combined with a trimmed and optimized lightweight virtualization component to complete the test. This test collects CPU and memory usage data under idle conditions, without deploying any business containers throughout the process. Only the resource overhead generated by the virtualization system itself is statistically analyzed. All test data is obtained directly through the operating system kernel resource statistics interface to ensure that the data accurately reflects the basic resource consumption levels of the two virtualization platforms. The actual test results show that, in terms of CPU usage, the traditional solution's virtualization component averages 72.3 mCPU, while the solution of this invention only uses 18.8 mCPU, achieving a reduction of approximately 73.9% in CPU usage. In terms of memory usage, the traditional solution averages 1731.5 MB, while the solution of this invention uses only 190.3 MB, a reduction of approximately 89.0%. Regarding node available resources, for a test node with a total resource of 4000 mCPU, 8GB memory, and 100GB disk, after virtualization processing using the solution of this invention, the node's available resources reach 3976 mCPU, 7.44GB memory, and 94.5GB disk, respectively, corresponding to CPU, memory, and disk available resource percentages of 99.4%, 93.0%, and 94.5%. These test results fully demonstrate that this invention can significantly reduce the CPU, memory, and disk resource overhead of the virtualization system itself, and after the virtualization environment is deployed, it can still retain the vast majority of available node resources for business applications. In summary, this invention offers multiple technological advantages in terms of overall performance and architecture. It can reduce CPU usage of virtualization components by over 70%, significantly reducing CPU resource consumption in the virtualization system; it can control virtualization system memory usage to within 200MB, achieving extremely low memory overhead; it effectively improves the overall resource availability ratio of nodes, with CPU, memory, and disk availability all exceeding 90%; by streamlining the architecture and eliminating unnecessary components, it significantly reduces additional resource overhead, lowers the number of resident processes, and reduces overall operational complexity; it can effectively manage resource increments during long-term system operation, avoiding the problem of continuously increasing resource consumption caused by log, image, and cache accumulation; and it fully retains core virtualization capabilities while maintaining extreme lightweight design, stably supporting core functions such as container operation, network communication, and basic service discovery.Therefore, this invention can be adapted to the operating scenarios of resource-constrained on-board computing nodes, and can build a stable and reliable containerized operating environment with extremely low system overhead, effectively improving the service carrying capacity and operation guarantee capability of satellite platforms.

[0034] The core of this invention is to streamline redundant functions of the virtualization base, reduce system operating overhead, and optimize parameter configuration based on the resource constraints of onboard computing nodes, effectively improving the utilization rate of onboard computing resources. Without departing from this core technological concept, this invention can be improved and replaced through multiple dimensions of implementation methods to adapt to different application scenarios, further realizing low-overhead, high-resource-utilization containerized virtualization capabilities. This invention uses a lightweight Kubernetes system based on K3s as the container orchestration foundation, relying on this architecture to achieve basic container operation and overall management functions. In practical applications, it can also be replaced with other lightweight Kubernetes distributions such as K0s and micro K8s, or other container orchestration systems built on containerd. All alternative solutions can stably achieve the core capabilities of basic container operation and management, while adapting to lightweight deployment requirements. At the container runtime level, this invention selects containerd as the core container runtime, relying on it to achieve full container lifecycle management. It can also be replaced with any lightweight container runtime conforming to the OCI standard, such as CRI-O, continuously ensuring efficient management capabilities of the container lifecycle without changing the core virtualization mechanism of this invention. Regarding the removal of unnecessary virtualization components, this invention eliminates redundant components and reduces system overhead through a combination of startup parameter disabling and source code-level trimming. In addition, various other methods can be employed, such as compile-time conditional switches, binary-level module deletion and replacement, dynamically disabling components using configuration templates, and on-demand loading of runtime policies, all of which effectively remove or suppress unnecessary functional components of the virtualization platform, significantly reducing system overhead. In the core resource parameter optimization phase, this invention specifically optimizes key parameters such as the maximum number of Pods and log space usage for the CPU, memory, and disk core resources of the onboard computing nodes. This optimization method can be further expanded to employ diversified optimization strategies such as static resource threshold configuration, task-type resource hierarchical configuration, and runtime monitoring dynamic parameter adjustment. By establishing quantitative constraint relationships to adapt to different resource configuration scenarios, and relying on the function association pattern of maximum Pod count = f (CPU, Memory), log limit = g (disk capacity), and image cache = h (storage space), precise adaptation and dynamic optimization of computing and storage resource parameters can be achieved. In terms of overall deployment, this invention is based on bare metal container deployment as its basic architecture, and can be extended to various deployment modes such as lightweight virtualization and container hybrid deployment, multi-node distributed lightweight virtualization nodes, etc. All extended deployment modes adhere to the core idea of ​​removing the virtual machine layer and reducing the operating overhead of the virtualization base.Overall, all alternative and optimized implementation schemes do not deviate from the core technical concept of this invention. In the special operating environment with limited onboard resources, they can build a low-overhead containerized virtualization operating system through comprehensive virtualization component trimming, redundant function simplification, precise optimization of operating parameters, and lightweight architecture construction, which can significantly improve the overall computing resource utilization efficiency of onboard computing nodes.

[0035] In summary, this embodiment first removes the virtual machine layer and adopts a bare-metal container deployment method. A host operating system is installed on the physical hardware of the onboard computing node, and Kubernetes node components are deployed on the host operating system to obtain the infrastructure. This effectively avoids the performance loss, high resource consumption, and large scheduling latency problems caused by the virtual machine layer, fully releasing the native computing performance of the onboard hardware, and conforming to the basic operating scenario of limited hardware resources and high real-time requirements of onboard equipment. Next, based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are trimmed, and lightweight construction verification is completed to obtain a lightweight architecture. This significantly reduces the resource overhead of the architecture, reduces program runtime memory consumption and startup time, making the overall architecture more streamlined and efficient, and adapting to the special operating conditions of the onboard environment with limited resources and complex working conditions. Finally, the operating parameters of the lightweight architecture are constrained and configured to obtain a lightweight base suitable for onboard computing nodes, effectively preventing the virtualization system from consuming too many resources during long-term operation due to excessive Pod numbers, continuous log growth, image cache accumulation, or temporary file accumulation. Overall, this invention, through a progressive design of layer-by-layer architecture simplification, component optimization, and parameter adaptation, overcomes the shortcomings of traditional container virtualization architectures, such as bloat, inefficiency, resource waste, and poor adaptability when adapting to spaceborne scenarios. While maximizing the computing power of spaceborne physical hardware and reducing system power consumption and resource consumption, it effectively improves the operational stability, real-time performance, and environmental adaptability of the spaceborne computing platform. It can better meet the core business needs of complex on-orbit computing, dynamic task scheduling, and long-term stable operation of satellites, providing solid underlying technical support for the efficient and reliable implementation of spaceborne computing tasks.

[0036] like Figure 3As shown in the illustration, this embodiment also provides a lightweight container platform construction system for onboard computing nodes. This system includes: an infrastructure acquisition module 10, a lightweight architecture acquisition module 20, and a lightweight platform acquisition module 30. Specifically, the infrastructure acquisition module 10 is used to remove the virtual machine layer, adopt a bare-metal container deployment method, install a host operating system on the physical hardware of the onboard computing node, and deploy Kubernetes node components on the host operating system to obtain the infrastructure. The lightweight architecture acquisition module 20 is used to retain necessary components from the Kubernetes node components, trim unnecessary components, and complete lightweight construction verification according to the operational requirements of the infrastructure to obtain a lightweight architecture. The lightweight platform acquisition module 30 is used to configure constraints on the lightweight architecture's operating parameters to obtain a lightweight platform suitable for onboard computing nodes.

[0037] In one implementation, the lightweight architecture acquisition module 20 includes: The streamlined component acquisition unit is used to retain the necessary components in the Kubernetes node components and remove the unnecessary components according to the operational requirements of the infrastructure, so as to obtain streamlined components; The lightweight architecture acquisition unit is used to perform lightweight construction verification on simplified components to obtain a lightweight architecture.

[0038] The working principle of each module in the lightweight container base construction system for spaceborne computing nodes in this embodiment is the same as that of each step in the above method embodiment, and will not be repeated here.

[0039] Based on the above embodiments, the present invention also provides a terminal, the principle block diagram of which can be as follows: Figure 4 As shown. The terminal may include one or more processors 100 ( Figure 4 (Only one is shown in the image), memory 101, and computer program 102 stored in memory 101 and executable on one or more processors 100, such as a lightweight container docking station construction program for onboard computing nodes. When one or more processors 100 execute computer program 102, they can implement the various steps in the embodiments of the lightweight container docking station construction method for onboard computing nodes. Alternatively, when one or more processors 100 execute computer program 102, they can implement the functions of various modules / units in the embodiments of the lightweight container docking station construction method for onboard computing nodes, which is not limited here.

[0040] In one embodiment, the processor 100 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0041] In one embodiment, memory 101 may be an internal storage unit of an electronic device, such as a hard drive or RAM. Memory 101 may also be an external storage device of the electronic device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, memory 101 may include both internal and external storage units. Memory 101 is used to store computer programs and other programs and data required by the terminal. Memory 101 can also be used to temporarily store data that has been output or will be output.

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

[0043] 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, operational databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual operating 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.

[0044] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for constructing a lightweight container base for spaceborne computing nodes, characterized in that, The method includes: By removing the virtual machine layer and adopting a bare metal container deployment method, the host operating system is installed on the physical hardware of the onboard computing node, and Kubernetes node components are deployed on the host operating system to obtain the infrastructure. Based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are removed, and lightweight build verification is completed to obtain a lightweight architecture. By constraining and configuring the operating parameters of the lightweight architecture, a lightweight base suitable for onboard computing nodes is obtained.

2. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 1, characterized in that, Based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, unnecessary components are removed, and lightweight build verification is completed to obtain a lightweight architecture, including: Based on the operational requirements of the infrastructure, necessary components in the Kubernetes node components are retained, and unnecessary components are removed to obtain a streamlined component; The simplified components were built and verified to achieve a lightweight architecture.

3. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 2, characterized in that, The necessary components include: container runtime, node management component, service proxy component, cross-node network plugin, and cluster domain name resolution component.

4. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 2, characterized in that, The trimming of unnecessary components includes: Unnecessary components are disabled during startup and are trimmed during source code building and packaging.

5. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 2, characterized in that, The lightweight construction and verification of the simplified components to obtain a lightweight architecture includes: The simplified components are recompiled and packaged to obtain lightweight components; Based on lightweight components, the basic capabilities of the current architecture are verified. If the verification passes, a lightweight architecture is obtained.

6. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 1, characterized in that, The configuration of constraints on the lightweight architecture's operating parameters includes: configuring constraints on the number of Pods, log space, image storage, and resource reclamation.

7. The method for constructing a lightweight container base for spaceborne computing nodes according to claim 1, characterized in that, After obtaining the lightweight base suitable for spaceborne computing nodes, the system also includes: In an idle state, the CPU, memory, and disk resource usage of the components in the lightweight architecture are statistically analyzed to obtain the basic overhead of the lightweight base itself.

8. A lightweight container base construction system for spaceborne computing nodes, characterized in that, The system includes: The infrastructure acquisition module is used to remove the virtual machine layer, adopt a bare metal container deployment method, install the host operating system on the physical hardware of the on-board computing node, and deploy Kubernetes node components on the host operating system to obtain the infrastructure. The lightweight architecture acquisition module is used to retain the necessary components in the Kubernetes node components, trim the unnecessary components, and complete the lightweight build verification based on the operational requirements of the infrastructure to obtain a lightweight architecture. The lightweight base acquisition module is used to constrain and configure the operating parameters of the lightweight architecture to obtain a lightweight base suitable for onboard computing nodes.

9. A terminal, characterized in that, The terminal includes a memory, a processor, and a lightweight container docking station construction program for spaceborne computing nodes stored in the memory and executable on the processor. When the processor executes the lightweight container docking station construction program for spaceborne computing nodes, it implements the steps of the lightweight container docking station construction method for spaceborne computing nodes as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a lightweight container docking station construction program for spaceborne computing nodes. When the lightweight container docking station construction program for spaceborne computing nodes is executed by a processor, it implements the steps of the lightweight container docking station construction method for spaceborne computing nodes as described in any one of claims 1-7.

Images