Satellite-borne software scheduling management system

Abstract

According to the satellite-borne software scheduling management system provided by the invention, the cloud native component, the plurality of software operation boards and the scheduling management board are used for respectively providing a hardware foundation and a software environment required by the operation of the satellite-borne software, a tight coupling relationship between software and hardware on a traditional satellite is unlocked, and computer resource support can be provided for deployment and execution of various tasks. Meanwhile, by means of the native characteristics of the cloud, the functions of dynamic upgrading, fault management, resource scheduling and the like of satellite-borne software can be achieved.

Description

Technical Field

[0001] The present invention mainly relates to the field of satellite service technology, and in particular to a satellite-borne software scheduling and management system. Background Art

[0002] Satellite onboard computers are usually configured in dual or multi-machine mode. When a single machine has a hardware failure, it switches to another single machine for operation. However, each single machine can only run its own exclusive functions at the same time. When the processing capacity of a single machine is limited and the tasks of the satellite increase, it is impossible to fully utilize the performance of the redundant computer to achieve task expansion. Summary of the invention

[0003] The purpose of this application is to provide a satellite-borne software scheduling and management system to unlock the tight coupling relationship between software and hardware on traditional satellites and provide computer resource support for the deployment and execution of various tasks. At the same time, with the help of cloud-native features, it can realize the functions of dynamic upgrade of satellite-borne software, fault management, resource scheduling, etc.

[0004] To achieve the above-mentioned purpose, the present application provides a satellite-borne software scheduling and management system, including a Kubernetes cluster, which exchanges data with external devices through a bus; wherein: the scheduling management board serves as the master node of the Kubernetes cluster, and is used to run the resource management process of the Kubernetes cluster, and dynamically schedules the resources required for the satellite-borne software based on the resource management process; each software running board serves as a working node of the Kubernetes cluster, and is used to run a Pod associated with the satellite-borne software, wherein the Pod is created according to a function configured by the satellite-borne software, and is used to implement the corresponding function; the cloud-native components are deployed in the master node and each working node respectively, and are used to provide a proxy service between the master node and each working node, and provide a deployment basis for the scheduling management, image management, fault management and data management functions of the Kubernetes cluster.

[0005] In some embodiments, the cloud native component includes Etcd, which is used to save and manage the cluster state of the Kubernetes cluster and the shared storage data of the onboard software.

[0006] In some embodiments, the cloud native components also include an API Server, a Controller Manager, and a Scheduler; wherein: the API Server is used to communicate with Etcd in real time to obtain the latest cluster status information; the Controller Manager is used to monitor cluster status changes and respond; the Scheduler is used to allocate the Pod to be scheduled to the corresponding working node according to a predetermined scheduling strategy, wherein the scheduling strategy includes scheduling according to priority and scheduling according to resource requirements.

[0007] In some embodiments, when there are multiple master nodes, the cloud native component also includes a load balancer for managing load balancing between the multiple master nodes and the multiple worker nodes.

[0008] In some embodiments, the cloud native components also include any one or a combination of the following: Kube-proxy, used to monitor service and endpoint changes, and update network rules and routing tables on working nodes; Custom Resource Definitions, used to provide user-defined Kubernetes resources; Operators, used to manage complex applications; Webhooks, used to implement custom Webhooks; Event listeners, used to respond to corresponding cluster events; CLI, used to query the latest cluster status information on the API Server.

[0009] In some embodiments, the resource management process includes: kube-apiserver, kube-controller-manager and kube-scheduler, which are used to implement resource management, Pod scheduling, elastic scaling, security control, system monitoring and error correction functions of the Kubernetes cluster.

[0010] In some embodiments, each working node is equipped with a Node Problem Detector for monitoring and reporting the health status of the corresponding working node; and / or, each working node is equipped with a Node Controller for managing the life cycle of the corresponding working node.

[0011] In some embodiments, the master node is deployed with an image repository, which is used to store and manage large batches of data and / or images of various versions of each onboard software.

[0012] In some embodiments, each working node is also equipped with a Kubelet service, which is used to create a container according to the Pod creation instruction, download the corresponding image from the image library, and start the container.

[0013] In some embodiments, the Kubelet service is also used to perform health checks on the containers, wherein when a container fails, the corresponding Pod running in the working node is canceled, and the API Server is informed to create a new Pod.

[0014] Compared with the prior art, the present invention has the following advantages:

[0015] This application provides a satellite-borne software scheduling and management system, which provides the hardware foundation and software environment required for the operation of satellite-borne software through cloud-native components, multiple software running boards and scheduling management boards, unlocks the tight coupling relationship between software and hardware on traditional satellites, and can provide computer resource support for the deployment and execution of various tasks. At the same time, with the help of cloud-native features, it can realize functions such as dynamic upgrade of satellite-borne software, fault management, and resource scheduling. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings are included to provide a further understanding of the present application. They are included and constitute a part of the present application. The accompanying drawings illustrate embodiments of the present application and together with the present specification serve to explain the principles of the present application. In the accompanying drawings:

[0017] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0018] Figure 2 It is a schematic diagram of the architecture of a satellite-borne software scheduling and management system provided in an embodiment of the present application;

[0019] Figure 3 It is a schematic diagram of component interaction of a satellite-borne software scheduling and management system provided by the present application;

[0020] Figure 4 This is a flow chart of data interaction provided by this application. DETAILED DESCRIPTION

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for the description of the embodiments. Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. Unless it is obvious from the language environment or otherwise explained, the same reference numerals in the figures represent the same structure or operation.

[0022] As shown in this application and claims, unless the context clearly indicates an exception, the words "a", "an", "an" and / or "the" do not refer to the singular and may also include the plural. Generally speaking, the terms "include" and "comprise" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0023] In addition, it should be noted that the use of words such as "first" and "second" to define components is only for the convenience of distinguishing the corresponding components. If not otherwise stated, the above words have no special meaning and cannot be understood as limiting the scope of protection of this application. In addition, although the terms used in this application are selected from well-known and commonly used terms, some terms mentioned in the specification of this application may be selected by the applicant at his or her discretion, and their detailed meanings are explained in the relevant parts of the description of this article. In addition, it is required to understand this application not only by the actual terms used, but also by the meaning implied by each term.

[0024] refer to Figure 1 , is a schematic diagram of an application scenario applicable to this application. Figure 2 , is a schematic diagram of the architecture of a satellite-borne software scheduling and management system provided by this application. Figure 3 , which is a component interaction diagram of a satellite-based software scheduling and management system provided in this application.

[0025] like Figure 1 An application scenario applicable to the present application includes an external device 101, multiple software running boards 102, and a scheduling management board 103. Data is exchanged between the external device 101 and each software running board 102, and data is exchanged between each software running board 102 and the scheduling management board 103. The data exchange can be realized, for example, through a bus, wifi, etc., and there is no limitation on this.

[0026] In a specific implementation, the scheduling management board 103 can select a high-reliability computer board or an industrial-grade general-purpose computer board. For example, a computer board of aerospace grade with strong radiation resistance. The software running board 102 can select a general-purpose computer board, a high-performance computer board, and a high-real-time computer board. For example, a computer board that can provide powerful computing power or a computer board designed specifically for real-time systems.

[0027] like Figure 2 , the onboard software scheduling and management system includes a Kubernetes cluster. The Kubernetes cluster includes a master node and multiple worker nodes. Figure 1In the application scenario shown, the scheduling management board 103 can be used as the master node of the Kubernetes cluster to run the resource management process of the Kubernetes cluster, and dynamically schedule the resources required by the satellite software based on the resource management process. The resource types include but are not limited to CPU, memory, hard disk, bus (422, CAN, etc.), GPU, etc. Each software running board 102 is used as a working node of the Kubernetes cluster to run a Pod associated with the satellite software, wherein the Pod is created according to a function configured by the satellite software to implement the corresponding function. Cloud native components are deployed in the master node and each working node. The cloud native components are used to provide proxy services between the master node and each working node, and provide a deployment basis for the scheduling management, image management, fault management and data management functions of the Kubernetes cluster.

[0028] Cloud native components can be relevant native components provided by the Kubernetes cluster or user-defined components. The master node can be one or more, without restriction.

[0029] In some embodiments, Figure 3 As shown, the cloud native components include Etcd (distributed storage system), which is used to save and manage the cluster state of the Kubernetes cluster and the shared storage data of the onboard software.

[0030] In some embodiments, when there are multiple master nodes, the cloud native component also includes a load balancer for managing load balancing between the multiple master nodes and the multiple worker nodes.

[0031] In some embodiments, the cloud native components include an API Server, a Controller Manager, and a Scheduler; wherein: the API Server is used to communicate with Etcd in real time to obtain the latest cluster status information; the Controller Manager is used to monitor cluster status changes and respond; the Scheduler is used to allocate the Pod to be scheduled to the corresponding working node according to a predetermined scheduling strategy, wherein the scheduling strategy includes scheduling according to priority and scheduling according to resource requirements.

[0032] In specific implementation, the Pod scheduling on the working node is the responsibility of the Scheduler provided by the Kubernetes cluster. The scheduler is a control plane component whose responsibility is to allocate the Pod to be scheduled to the appropriate working node according to the predetermined scheduling strategy and resource requirements. The process of Pod scheduling is as follows:

[0033] Node registration: The working node needs to register itself in the Kubernetes cluster first. After registration, the node controller will assign a CIDR address block to the node and ensure that the node is valid.

[0034] Pod creation: Users create Pods through the Kubernetes API. At this time, the Pods are in the Unscheduled (Pending) state.

[0035] Scheduling queue: The newly created Pod enters the scheduling queue and waits for processing by the scheduler.

[0036] Node selection: The scheduler selects a suitable node based on the Pod's specifications and resource requirements, as well as the current state of the cluster. The scheduling decision takes into account factors such as the node's resource capacity (such as CPU, memory), Pod's affinity and anti-affinity settings, node selectors and node labels, taints and tolerances, and Pod's specific requirements (such as storage and network policies).

[0037] Scheduling constraints: The scheduler can consider scheduling constraints for Pods, such as nodeSelector, which indicates that the Pod can only be scheduled to nodes with specific labels, or affinity and anti-affinity, which indicate Pod affinity rules that can specify the node types that the Pod should or should not be scheduled to.

[0038] Resource requests and limits: The scheduler checks the resource requests and limits of a node to ensure that the node has enough resources to meet the needs of the Pod.

[0039] Taints and Tolerances: The scheduler checks whether the node has taints and whether the Pod has corresponding tolerations to determine whether the Pod can be scheduled to the node.

[0040] Scheduling decision: The scheduler selects an optimal node to run the Pod based on the above factors and scheduling algorithms.

[0041] Bind Pod: The scheduler binds the Pod to the selected node, which is done through the Kubernetes API.

[0042] In some embodiments, each working node is also equipped with a Kubelet service, which is used to create a container according to the Pod creation instruction, download the corresponding image from the image library, and start the container. The Kubelet service can also be used to perform health checks on the container, where when a container fails, the corresponding Pod running in the working node is canceled, and the API Server is notified to create a new Pod.

[0043] For example, the Pod scheduling process may further include:

[0044] Kubelet receives instructions: After the Pod is bound to a node, the Kubelet service on the node receives instructions to create a Pod.

[0045] Container creation: Kubelet creates a container based on the Pod definition, downloads the required image, and starts the container.

[0046] Health Check: Once the container is started, Kubelet will perform health checks (Liveness and ReadinessProbes) to ensure that the container is running properly.

[0047] Status reporting: Kubelet periodically reports the status of Pods and containers to the Kubernetes API server, including running status, IP addresses, and events.

[0048] Elastic Scaling: If Pods are managed by controllers such as Deployment or ReplicaSet, they will scale elastically as needed.

[0049] In practice, the scheduler's decision-making process is automated and usually completed within seconds. Scheduling policies and priorities can be customized in a variety of ways to meet different business needs and workload characteristics.

[0050] The connection between the API server and Etcd can be established through automation and configuration drive. For example, the process of establishing a connection relationship includes:

[0051] Configure the API server: When the Kubernetes cluster is started, the API server component needs to specify the information of the etcd cluster through the configuration file or command line parameters. This usually includes the address, port, and authentication information of the etcd cluster.

[0052] Specify etcd cluster address: You need to specify one or more etcd node addresses in the apiserver configuration. If etcd runs as a cluster, all etcd node addresses will be listed here.

[0053] Security authentication: To ensure the security of data transmission, the communication between apiserver and etcd needs to be encrypted using Secure Sockets Layer (SSL) / Transport Layer Security (TLS). You need to configure the TLS certificate and key, as well as the trusted CA certificate.

[0054] Connection test: When the API server starts, it tries to connect to the configured Etcd cluster address and performs a connection test to ensure that it can successfully access Etcd.

[0055] Data encryption: When the API server starts, it tries to connect to the configured Etcd cluster address and performs a connection test to ensure that it can successfully access Etcd.

[0056] Use gRPC protocol: Api server usually uses gRPC protocol to communicate with Etcd. gRPC is a high-performance, open source and general RPC framework.

[0057] Service registration and discovery: In some deployments, the API server may use a service discovery mechanism to dynamically find the service address of the Etcd cluster, especially in a cloud environment or when using a service mesh.

[0058] Load balancing: If the Etcd cluster is deployed with multiple nodes, the Api server may use a built-in or external load balancer to balance requests to different Etcd nodes.

[0059] Failover and high availability: Configure the failover mechanism so that when the Etcd node is unavailable, the Api server can automatically switch to other healthy Etcd nodes.

[0060] Cluster status synchronization: Once the connection is established, the API server will start reading and writing cluster status information from Etcd to synchronize the status.

[0061] Monitoring and logging: Monitor the communication between the API server and Etcd, and log any connection issues or performance bottlenecks.

[0062] Version compatibility: Make sure the versions of Apiserver and Etcd are compatible to avoid potential communication issues.

[0063] Network Policy: Configure network policy to allow traffic between the API server and Etcd.

[0064] Based on the above steps, the Kubernetes API server can establish a stable and secure connection with the Etcd cluster (such as Figure 2 As shown in the figure), ensure the persistence and high availability of the cluster state. In practice, these steps are usually automated by cluster installation and configuration tools (such as kubeadm, Minikube, or cloud service provider's Kubernetes service).

[0065] When the information in Etcd changes, multiple other components in the Kubernetes cluster, such as user-defined components, can be quickly notified.

[0066] In some embodiments, in addition to the API Server, Controller Manager, Scheduler and Kubelet mentioned above, cloud native components may include any one or a combination of the following: Kube-proxy, used to monitor service and endpoint changes, and update network rules and routing tables on working nodes; Custom Resource Definitions (CRDs), providing user-defined Kubernetes resources; Operators, used to manage complex applications; Webhooks, used to implement customized Webhooks; Event listeners, used to respond to corresponding cluster events; CLI, used to query the latest cluster status information on the API Server.

[0067] These cloud-native components can respond to changes in etcd in the following ways:

[0068] Listening to CRDs: Users can create custom controllers to listen to changes in their own CRDs.

[0069] Using client libraries: User programs can use Kubernetes client libraries, such as client-go, to monitor resource changes.

[0070] Set up Webhooks: trigger custom callbacks or logic when resources change.

[0071] Subscribe to Kubernetes events: Get events that occur in the cluster through the Kubernetes event system.

[0072] In some embodiments, the resource management process includes: kube-apiserver, kube-controller-manager, and kube-scheduler. These processes are run on the master node (i.e., master) to implement the functions of resource management, Pod scheduling, elastic scaling, security control, system monitoring, and error correction of the Kubernetes cluster.

[0073] In some embodiments, each working node is equipped with a Node Problem Detector for monitoring and reporting the health status of the corresponding working node; and / or, each working node is equipped with a Node Controller for managing the life cycle of the corresponding working node.

[0074] In specific implementation, Node Problem Detector can run on each node in the form of DaemonSet, collect problems from system logs, and report them to the API server in the form of node Condition and Event. NodeController can allocate CIDR address blocks to nodes, check whether the virtual machine corresponding to the node object is available through the cloud provider interface, and monitor the health of the node. When a node becomes unreachable, the node controller will update the node status and evict all Pods on the node after a certain period of time.

[0075] The Kubernetes cluster regularly checks the health status of the container through Liveness Probe and Readiness Probe. If the container crashes, Kubernetes automatically restarts the container, which helps maintain the stability of the application and the log records generated by various components can help identify and debug problems.

[0076] When a working node fails, the status information on the working node can be sent to the master node through the cloud native components deployed on it, so that the master node can modify or migrate the pod of the corresponding onboard software to other working nodes. For example, the working node can also migrate or restart the interrupted pod through the process maintenance function of the cloud native component, or send the alarm information to Prometheus. The onboard software receives the alarm information and performs autonomous operations on the satellite (mode switching, restarting, status setting, etc.) or ground control according to the set alarm level.

[0077] Furthermore, in some embodiments, the master node is deployed with an image repository, which is used to store and manage large quantities of data and / or images of each version of each satellite-borne software. The ground can upload the image of the updated software version to the satellite through satellite-to-ground transmission, and the satellite updates the image to the image library, rolling update the running pod, and realizes seamless update. When a bug is found in a certain version of a satellite-borne software, the update can be suspended or the current version can be directly rolled back to other versions stored in the image library, which is convenient for updating and using the satellite-borne software.

[0078] The satellite-borne software scheduling and management system provided by the present application can exchange data with the ground station, so as to conveniently and quickly expand the satellite functions or modify the original satellite software. Figure 4 As shown, the process of adding or refactoring onboard software may include:

[0079] S401, the ground station initiates an application for uploading data and uploads the reconstructed mirror data;

[0080] S402, the onboard software scheduling and management system receives the mirror data that has been uploaded and verifies all the data. If there is a problem with the verification, the ground station is notified to fill in frames or re-upload data according to real-time telemetry;

[0081] S403, the ground station sends a corresponding instruction to instruct the onboard software scheduling and management system to update the image warehouse; or, the onboard software scheduling and management system updates the image registered by the ground station to the image warehouse, which can be used for subsequent backup rollback, etc.;

[0082] S404, the ground station sends a corresponding instruction to apply for software update. If it is the onboard software required by the Kubernetes cluster, the instruction content includes the specifications, resources and other information required to run the software, and step S405 is executed; if it is the software required by the external device, the instruction content includes the information of the corresponding device, and step S406 is executed;

[0083] S405, the onboard software scheduling management system creates a pod according to the scheduling strategy of the cloud platform, and the ground station can dynamically monitor or interrupt it through real-time telemetry;

[0084] S406, the onboard software scheduling and management system forwards the data to the external device via the bus.

[0085] In summary, this application provides a satellite-borne software scheduling and management system, which provides the hardware foundation and software environment required for the operation of satellite-borne software through cloud-native components, multiple software running boards and scheduling management boards, unlocks the tight coupling relationship between software and hardware on traditional satellites, and can provide computer resource support for the deployment and execution of various tasks. At the same time, with the help of cloud-native features, it can realize functions such as dynamic upgrade of satellite-borne software, fault management, and resource scheduling.

[0086] The basic concepts have been described above. Obviously, for those skilled in the art, the above invention disclosure is only used as an example and does not constitute a limitation of the present application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements and amendments to the present application. Such modifications, improvements and amendments are suggested in the present application, so such modifications, improvements and amendments still belong to the spirit and scope of the exemplary embodiments of the present application.

[0087] At the same time, the present application uses specific words to describe the embodiments of the present application. For example, "one embodiment", "an embodiment", and / or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of the present application. Therefore, it should be emphasized and noted that "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more in different positions in this specification does not necessarily refer to the same embodiment. In addition, some features, structures or characteristics in one or more embodiments of the present application can be appropriately combined.

[0088] Some aspects of the present application may be performed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". The processor may be one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or combinations thereof. In addition, various aspects of the present application may be expressed as computer products located in one or more computer-readable media, which include computer-readable program codes. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, tapes ...), optical disks (e.g., compact disks CDs, digital versatile disks DVDs ...), smart cards, and flash memory devices (e.g., cards, sticks, key drives ...).

[0089] A computer-readable medium may include a propagated data signal containing computer program code, such as in baseband or as part of a carrier wave. The propagated signal may have a variety of manifestations, including electromagnetic, optical, etc., or a suitable combination. A computer-readable medium may be any computer-readable medium other than a computer-readable storage medium, which may be connected to an instruction execution system, device or apparatus to communicate, propagate or transmit a program for use. The program code on the computer-readable medium may be propagated via any suitable medium, including radio, cable, fiber optic cable, radio frequency signal, or similar medium, or any combination of the above mediums.

[0090] Similarly, it should be noted that in order to simplify the description of the disclosure of this application and thus help understand one or more embodiments of the invention, in the above description of the embodiments of this application, multiple features are sometimes combined into one embodiment, figure or description thereof. However, this disclosure method does not mean that the features required by the object of this application are more than the features mentioned in the claims. In fact, the features of the embodiments are less than all the features of the single embodiment disclosed above.

[0091] In some embodiments, numbers describing the number of components and attributes are used. It should be understood that such numbers used in the description of the embodiments are modified by the modifiers "about", "approximately" or "substantially" in some examples. Unless otherwise specified, "about", "approximately" or "substantially" indicate that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may change according to the required features of individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and adopt the general method of retaining digits. Although the numerical domains and parameters used to confirm the breadth of their range in some embodiments of the present application are approximate values, in specific embodiments, the setting of such numerical values ​​is as accurate as possible within the feasible range.

[0092] Although the present application has been described with reference to the current specific embodiments, ordinary technicians in this technical field should recognize that the above embodiments are only used to illustrate the present application, and various equivalent changes or substitutions may be made without departing from the spirit of the present application. Therefore, as long as the changes and modifications to the above embodiments are within the essential spirit of the present application, they will fall within the scope of the claims of the present application.

Claims

1. A satellite-borne software scheduling and management system, characterized in that: It includes a Kubernetes cluster, which exchanges data with external devices through a bus; the Kubernetes cluster consists of cloud native components, multiple software running boards and a scheduling management board; wherein: The scheduling management board serves as the master node of the Kubernetes cluster, and is used to run the resource management process of the Kubernetes cluster, and dynamically schedule the resources required by the onboard software based on the resource management process; Each software running board serves as a working node of the Kubernetes cluster, and is used to run a Pod associated with the onboard software, wherein the Pod is created according to a function configured by the onboard software, and is used to implement the corresponding function; The cloud native components are deployed in the master node and each working node respectively to provide proxy services between the master node and each working node, and provide a deployment basis for the scheduling management, image management, fault management and data management functions of the Kubernetes cluster.

2. The onboard software scheduling and management system according to claim 1, characterized in that: The cloud native component also includes Etcd, which is used to save and manage the cluster state of the Kubernetes cluster and the shared storage data of the onboard software.

3. The onboard software scheduling and management system according to claim 2, characterized in that: The cloud native components also include API Server, Controller Manager and Scheduler; among them: API Server, used to communicate with Etcd in real time to obtain the latest cluster status information; Controller Manager, which monitors cluster status changes and responds to them; Scheduler is used to allocate the Pods to be scheduled to the corresponding working nodes according to a predetermined scheduling strategy, where the scheduling strategy includes scheduling according to priority and scheduling according to resource requirements.

4. The onboard software scheduling and management system according to claim 1, characterized in that: When there are multiple master nodes, the cloud native component also includes a load balancer for managing load balancing between the multiple master nodes and the multiple working nodes.

5. The onboard software scheduling and management system according to claim 1, characterized in that: The cloud native components also include any one or a combination of the following: Kube-proxy, which monitors service and endpoint changes and updates network rules and routing tables on worker nodes; Custom Resource Definitions, which are used to provide user-defined Kubernetes resources; Operators, for managing complex applications; Webhooks, used to implement custom Webhooks; Event listeners, used to respond to corresponding cluster events; CLI, used to query the latest cluster status information on the API Server.

6. The onboard software scheduling and management system according to claim 1, characterized in that: The resource management process includes: kube-apiserver, kube-controller-manager and kube-scheduler, which are used to implement the resource management, Pod scheduling, elastic scaling, security control, system monitoring and error correction functions of the Kubernetes cluster.

7. The onboard software scheduling and management system according to claim 1, characterized in that: Each working node is equipped with a NodeProblem Detector for monitoring and reporting the health status of the corresponding working node; and / or each working node is equipped with a Node Controller for managing the life cycle of the corresponding working node.

8. The onboard software scheduling and management system according to claim 1, characterized in that: The master node is deployed with an image warehouse, which is used to store and manage large batches of data and / or images of various versions of each onboard software.

9. The onboard software scheduling and management system according to claim 8, characterized in that: Each working node is also equipped with a Kubelet service, which is used to create a container according to the Pod creation instruction, download the corresponding image from the image library, and start the container.

10. The onboard software scheduling and management system according to claim 9, characterized in that: The Kubelet service is also used to perform a health check on the container, wherein when the container fails, the corresponding Pod running in the working node is canceled, and the API Server is informed to create a new Pod.

Images