Container service management platform for embedded system
By designing a container service management platform for embedded systems, the problem of difficult to manage and schedule a container service cluster under embedded systems is solved, and efficient resource utilization and shortening of the software development life cycle is achieved.
Patent Information
- Application Number
- CN202411652244.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-19
- Publication Date
- 2025-02-18
AI Technical Summary
It is difficult to manage and schedule container service clusters under embedded systems, resulting in low resource utilization and long software development life cycle.
Design a container service management platform for embedded systems, adopting three-layer architectures of interface layer, function layer, and storage layer, providing automated management of containers and services, realizing functions such as automatic deployment, load balancing, service discovery, expansion and monitoring. .
Through unified scheduling and management of container service clusters, we can improve resource utilization, shorten the software development life cycle, reduce development and maintenance costs, and improve system stability and security.
Smart Images
Figure CN119484624A_ABST
Abstract
Description
Technical Field
[0001] The disclosed embodiments relate to the technical field of embedded systems, and in particular to a container service management platform for embedded systems. Background Art
[0002] Container technology is a virtualization technology that allows developers to package applications and their dependencies and run them in an isolated environment. This process is called containerization. The use of container technology can achieve cross-platform operation and rapid deployment of applications, ensure the consistency of the application operating environment, and allow developers to deploy in local workstations or actual operating environments without having to pay attention to differences in operating system configuration and underlying infrastructure. Applying container technology to the field of embedded systems can effectively solve the problem of inconsistency between embedded system development and operating environment, and improve the efficiency of embedded software development, deployment, and maintenance.
[0003] As an emerging software architecture technology, service-oriented has been widely studied and applied at home and abroad in recent years. As an architectural style, it is a method of developing a single application as a set of small services. Each service runs in its own process and uses a lightweight communication mechanism (usually HTTP-type API) for communication. These services are built around business capabilities and are often combined with container technology in terms of deployment. Each service runs as an independent unit in an independent container environment.
[0004] Container technology and service-oriented technology have improved the portability, scalability and flexibility of applications. However, as the number of containers and services continues to increase, it is becoming increasingly difficult to manage containerized and service-oriented applications. A container service management platform is needed to provide an automated way to manage containers and services, which can achieve functions such as automatic deployment, load balancing, service discovery, expansion and monitoring, thereby improving resource utilization and accelerating the software development life cycle.
[0005] Therefore, it is necessary to improve one or more problems existing in the above-mentioned related technical solutions.
[0006] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention
[0007] The purpose of the embodiments of the present disclosure is to provide a container service management platform for embedded systems, thereby overcoming one or more problems caused by limitations and defects of related technologies at least to a certain extent.
[0008] According to an embodiment of the present disclosure, a container service management platform for embedded systems is provided, including: The interface layer is used to provide external access interfaces and human-computer interaction interfaces; Functional layer, used for container management and service management; The storage layer is used to store container service images, business operation data, and system operation logs.
[0009] Furthermore, the interface layer includes: Web GUI module, API Client module and HTTP API module; among them, Web GUI module, which is used to provide a graphical human-computer interaction interface for scheduling and controlling container nodes and services; The API Client module is used to listen to and receive external requests, interact with containers in the cluster in a unified manner, route external requests, and forward them to the corresponding containers to achieve unified orchestration and management of each container; HTTP API module, used to provide HTTP interface.
[0010] Furthermore, the functional layer includes: The container management module is used to manage containers through load balancing, fault restart, container controller, and container scheduler components; The service management module is used to manage services through the registration center, remote call, quality control and link tracking components; The image management module is used to manage all image information in the image repository; the image information includes the image source, name, version, creation time and system architecture; The node management module is used to manage all computing nodes in a unified manner. It adds and configures the connection information of each computing node one by one through the IP address of the computing node, registers the computing node, and obtains the name, status, running time, number of container loads, creation time, CPU information, memory information, disk information, and network information of the computing node after registration. The status monitoring module is used to perform node status monitoring and container status monitoring. By collecting the status information of each computing node, it can realize real-time monitoring of the CPU, memory, and storage in the cluster, and collect the real-time running status information of each container application instance.
[0011] Furthermore, the container management module also includes: The load balancing component is used to perform load balancing scheduling according to the load of each computing node when scheduling and distributing containers and services, calculate the CPU and memory usage of each computing node, and select an optimal node to average the overall resources; The fault restart component is used to regularly detect and record the status of the container to the local database. When the container status is inconsistent with the expected status, it is determined whether the container operation status has failed. If a failure occurs, the container is restarted to restore the container to normal operation. The container controller is used to start, stop, pause, resume, restart, and destroy containers on the computing nodes. The container scheduler is used to read the list of containers to be scheduled and the list of available computing nodes, schedule containers using pre-defined scheduling algorithms and strategies, and select the optimal node to deploy the container to average the overall resources.
[0012] Furthermore, the service management module also includes: The registration center submodule is used to receive the registration information of each service, store the address information of the service provider, and attribute information related to service release. Service consumers obtain the address information of the service provider through active query and passive notification. The remote call submodule is used to encapsulate the calling process between services on different nodes into a unified interface through ID mapping, serialization and deserialization, and network transmission protocol; The quality control submodule is used to define the priority and other attributes for each data packet in the communication layer using the protocol stack IP DCSP for embedded application scenarios, and implement the data packet priority queue in the service transmission logic to cooperate with the service quality control management; The link tracking submodule is used to collect data, process and display service call data by tracking points in different modules, and generate call link diagrams and call topology diagrams.
[0013] Furthermore, the image management module is also used to provide buttons such as batch uploading container images, batch deleting container images, searching container images, and viewing container image details on the front-end interface to facilitate operations by users.
[0014] Furthermore, the status monitoring module is also used to summarize the real-time operation status information and display it comprehensively on the front-end interface.
[0015] Furthermore, the storage layer includes: Image storage, business data storage and log storage; among them, Image storage, used to store container service images; Business data storage, used to store business operation data; Log storage is used to store platform operation logs.
[0016] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects: In the embodiments of the present disclosure, through the above-mentioned container service management platform for embedded systems, on the one hand, including a three-layer architecture of an interface layer, a functional layer, and a storage layer, a method of automatically managing containers and services is provided, which can realize functions such as automatic deployment, load balancing, service discovery, expansion, and monitoring, and solve the problem that container service clusters under embedded systems are difficult to uniformly manage and schedule, thereby improving resource utilization and accelerating the software development life cycle. On the other hand, it is possible to uniformly schedule and manage container service clusters under embedded systems, provide convenience for the application of container technology and service technology in embedded systems, and facilitate developers to develop service-oriented programs and deploy and run containerized programs under embedded systems, thereby improving development efficiency and reducing development and maintenance costs. In addition, the service-oriented reconstruction and containerized deployment of programs through the container service management platform are conducive to improving system stability and security.
[0017] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.
[0019] Figure 1 A schematic diagram showing a framework of a container service management platform for embedded systems in an exemplary embodiment of the present disclosure; Figure 2 A schematic diagram showing an implementation of a container service management platform in an exemplary embodiment of the present disclosure; Figure 3 A schematic diagram showing an implementation of a container service management platform running on a computing node in an exemplary embodiment of the present disclosure; Figure 4 A schematic diagram showing the data flow of a container service management platform in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION
[0020] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the disclosure will be more comprehensive and complete and to fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0021] In addition, the accompanying drawings are only schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and thus their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.
[0022] This example implementation first provides a container service management platform for embedded systems. Figure 1 As shown in , the container service management platform for embedded systems may include: The interface layer is used to provide external access interfaces and human-computer interaction interfaces; Functional layer, used for container management and service management; The storage layer is used to store container service images, business operation data, and system operation logs.
[0023] Through the above-mentioned container service management platform for embedded systems, on the one hand, including the three-layer architecture of interface layer, function layer and storage layer, a way of automatically managing containers and services is provided, which can realize functions such as automatic deployment, load balancing, service discovery, expansion and monitoring, and solve the problem that container service clusters under embedded systems are difficult to manage and schedule in a unified manner, thereby improving resource utilization and accelerating the software development life cycle. On the other hand, it can uniformly schedule and manage container service clusters under embedded systems, facilitate the application of container technology and service technology in embedded systems, and facilitate developers to develop service-oriented programs and deploy and run containerized programs under embedded systems, improve development efficiency, and reduce development and maintenance costs. In addition, the service-oriented reconstruction and containerized deployment of programs through the container service management platform are conducive to improving system stability and security.
[0024] Next, we will refer to Figures 1 to 4 Each part of the above method in this example embodiment is described in more detail.
[0025] In one embodiment, the container service management platform (i.e., the container service management platform for embedded systems) includes a three-layer architecture of an interface layer, a function layer, and a storage layer.
[0026] The interface layer includes three modules: Web GUI, API Client, and HTTP API.
[0027] The Web GUI module provides a graphical human-computer interaction interface. Through a Web browser, you can access the container service management platform to perform operations such as viewing cluster status and deploying containers. It supports operations such as creating, running, deleting, querying, and pausing containers through a visual page.
[0028] The API Client module listens to and receives external requests, interacts with the container nodes in the cluster in a unified manner, routes external requests, and forwards them to the corresponding container worker nodes to achieve unified orchestration and management of containers on each node.
[0029] The HTTP API module encapsulates the core functions of the container service platform functional layer into HTTP interfaces.
[0030] In one embodiment, the functional layer includes a container management module, a service management module, an image management module, a node management module, and a status monitoring module.
[0031] The container management module includes load balancing, fault restart, container controller, and container scheduler components.
[0032] When scheduling and distributing containers and services, the load balancing component can perform load balancing scheduling based on the load conditions of each node, calculate the CPU and memory usage of each node, and select an optimal node to average the overall resources. The load balancing algorithms used include polling balancing, active-standby balancing, and minimum number of connections balancing.
[0033] The fault restart component regularly detects and records the status of the container to the local database. When the container status is inconsistent with the expected status, it is determined that the container operation status has failed, and the container is restarted to restore the container to normal operation.
[0034] The container controller starts, stops, pauses, resumes, restarts, and destroys containers on the node.
[0035] The container scheduler reads the list of containers to be scheduled and the list of available computing nodes, schedules the containers using predefined scheduling algorithms and policies, and balances the overall resources by selecting the optimal node to deploy the container.
[0036] The service management module includes registration center, remote call, quality control and link tracking components.
[0037] The registration center receives the registration information of each service, stores the address information of the service provider, and attribute information related to service release. Service consumers obtain the address information of the service provider through active query and passive notification.
[0038] Remote calls encapsulate the calling process between services that are not on the same node into a unified interface through ID mapping, serialization and deserialization, and network transmission protocols.
[0039] Quality control is aimed at embedded application scenarios. The protocol stack IP DCSP is used at the communication layer to define attributes such as priority for each data packet. At the same time, the data packet priority queue is implemented in the service transmission logic. The two work together to achieve service quality control management.
[0040] Link tracking collects data by embedding points in different modules, processes and displays service call data, and generates call link diagrams and call topology diagrams.
[0041] The image management module manages all image information in the image repository, including the image's source, name, version, creation time, system architecture, etc. In addition, buttons such as batch upload of container images, batch deletion of container images, search for container images, and viewing of container image details are provided on the front-end interface to facilitate operations by users.
[0042] The node management module manages all nodes in the platform in a unified manner, adds and configures the connection information of each node one by one through the node's IP address, and registers the node. After registration, the node's name, status, running time, number of container loads, creation time, and computing node CPU, memory, disk, network and other resource information are obtained.
[0043] Status monitoring includes node status monitoring and container status monitoring. On the one hand, by collecting the status information of each computing node, real-time monitoring of CPU, memory, storage and other resources in the cluster is achieved; on the other hand, real-time running status information of each container application instance is collected. After the running status information is summarized, it is comprehensively displayed on the front-end interface.
[0044] In one embodiment, the storage layer includes image storage, business data storage, and log storage, and three independent storage areas are constructed to store and record the container service images, business operation data, and platform operation logs in the platform respectively.
[0045] The container service management platform provided by this application can perform unified scheduling and management of container service clusters under embedded systems, facilitate the application of container technology and service technology in embedded systems, and help developers develop service-oriented programs and deploy and run containerized programs under embedded systems, thereby improving development efficiency and reducing development and maintenance costs. In addition, service-oriented reconstruction and containerized deployment of programs through the container service management platform are conducive to improving system stability and security.
[0046] In a specific embodiment, Figure 2This is an implementation method of the container service management platform of this application. The entire system includes three embedded computing nodes, one of which is used as a management node and the other two are used as computing nodes. The management node communicates data with the two computing nodes via an Ethernet data link (Ethernet can also be replaced by other data links). The container service management platform runs independently in the management node, and the node agent component runs on the computing node. The container service management platform sends and receives command status communications with the node agent component on the computing node to schedule and manage containers and services on computing node 1 and computing node 2.
[0047] Optionally, the system can be connected to multiple computing nodes for management, and multiple containers and services can run on each computing node.
[0048] Optionally, the container service management platform can also run directly on the computing node. In this case, no dedicated management node is required in the system. Figure 3 As shown, the container service management platform runs on computing node 1, directly communicates with the node agent component on computing node 1 through intra-board network, and communicates with the node agent component on computing node 2 through inter-board network, so as to implement the scheduling management of containers and services on the computing nodes.
[0049] The functional layer modules of the container service management platform include container management module, service management module, image management module, node management module and status monitoring module. The data flow of the container service management platform is as follows: Figure 4 As shown, the management node and the computing node interact with each other through the API interface exposed by the interface layer. The storage layer includes image storage, business data storage, and log storage. Three independent storage areas are built to store and record the container service images, business operation data, and platform operation logs in the platform.
[0050] Users can access the Web GUI interface provided by the container service management platform through a computer browser to perform scheduling and control operations on containers and services. After receiving the command sent by the user, the Web GUI interface parses the command and sends the parsed command to the API Client to call the corresponding interface function. The API Client selects the corresponding function module of the functional layer according to the command, and the interface of each function module is provided in the form of HTTP API.
[0051] Optionally, in addition to receiving commands from the Web GUI, the API Client can also directly parse pre-written program scripts without human operation. The execution operation after the API Client parses the program script is the same as above, that is, the HTTP API interface provided by the corresponding function module of the function layer is called according to the command selection.
[0052] The container management platform node agent program runs on the computing node, which acts as a communication agent to realize data communication between the management node and the computing node. Each module of the functional layer of the container service management platform sends the required control commands to the node agent component on the corresponding computing node. The node agent component performs corresponding scheduling operations on the containers and services on the computing node according to the control commands.
[0053] After the computing node completes the scheduling operation, it sends the execution result and computing node system status to the container service management platform. The container management platform stores and consolidates the data of each computing node, and stores the image information, business data information, log information, etc. in each storage module of the storage layer.
[0054] The external interfaces of each module in the functional layer are provided in the form of HTTP API, and different scheduling management operations are performed according to different commands received.
[0055] When a command to pull an image is received, the container scheduler in the container management module starts, parses the command parameters, generates information such as the identification, storage location, and pulling method of the image to be pulled, and sends it to the node agent in the computing node. After receiving the command, the node agent queries the corresponding image identification from the corresponding storage location in the image repository of the container service management platform through the API interface, and pulls the container image to the computing node according to the corresponding pulling method.
[0056] When a start image command is received, the container controller in the container management module starts, generates container image startup parameters according to the command, and sends them to the node agent component on the computing node. The node agent component starts the container image on the computing node according to the container image startup parameters.
[0057] The load balancing component in the container management module runs periodically after the container service management platform is started. According to the predetermined load balancing strategy, it generates a load balancing scheduling command and sends it to the node agent component on the corresponding computing node. The node agent component allocates the container load on the computing node according to the scheduling command.
[0058] The fault restart component in the container management module runs periodically after the container service management platform is started. When the container service management platform receives container fault information sent by the node agent, the fault restart component generates a container restart recovery strategy based on the fault information and sends it to the node agent component on the corresponding computing node. The node agent component schedules the container on the computing node to restart according to the container restart recovery strategy.
[0059] When a service registration command is received, the service management module is started, and the registration center receives the service information to be registered. After the service information is registered, it is solidified and stored in the storage layer.
[0060] When a service call request is received, the service management module queries the service list in the registration center and returns the service address through the remote call module. The service quality control component monitors the service call link and the data transmission volume of the service, and performs service quality control according to the service quality control strategy. The link tracking component records the service call chain information and sends it to the Web GUI for display through the HTTP API of the interface layer.
[0061] The node agent program on the computing node periodically collects the status data of the computing node and passes it to the status monitoring module of the container service management platform through the API interface. The status monitoring module sends the collected node status data to the Web GUI interface through the HTTP API interface for display, and stores and records the status information in the storage layer.
[0062] When receiving a node management command, the node management module parses the command, generates a node control instruction, sends it to the corresponding computing node, and executes the node management command operation.
[0063] When receiving an image management command, the image management module parses the command, generates an image control instruction, and executes the corresponding image management command operation on the stored image.
[0064] Optionally, the image storage module in the storage layer can be configured as a remote image repository, accessing the remote image repository through a pre-set IP address and pulling and uploading images.
[0065] This embodiment is only one of the preferred embodiments of the present application, and the implementation of the present application is not limited to this embodiment.
[0066] Through the above-mentioned container service management platform for embedded systems, on the one hand, including the three-layer architecture of interface layer, function layer and storage layer, a way of automatically managing containers and services is provided, which can realize functions such as automatic deployment, load balancing, service discovery, expansion and monitoring, and solve the problem that container service clusters under embedded systems are difficult to manage and schedule in a unified manner, thereby improving resource utilization and accelerating the software development life cycle. On the other hand, it can uniformly schedule and manage container service clusters under embedded systems, facilitate the application of container technology and service technology in embedded systems, and facilitate developers to develop service-oriented programs and deploy and run containerized programs under embedded systems, improve development efficiency, and reduce development and maintenance costs. In addition, the service-oriented reconstruction and containerized deployment of programs through the container service management platform are conducive to improving system stability and security.
[0067] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.
[0068] It should be noted that although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of a module or unit described above can be further divided into multiple modules or units for concretization. The components displayed as modules or units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. Those of ordinary skill in the art can understand and implement it without paying creative work.
[0069] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the appended claims.
Claims
1. A container service management platform for embedded systems, characterized in that: include: The interface layer is used to provide external access interfaces and human-computer interaction interfaces; Functional layer, used for container management and service management; The storage layer is used to store container service images, business operation data, and system operation logs.
2. According to claim 1, the container service management platform for embedded systems is characterized in that: The interface layer includes: Web GUI module, API Client module and HTTP API module; among them, Web GUI module, which is used to provide a graphical human-computer interaction interface for scheduling and controlling container nodes and services; The API Client module is used to listen to and receive external requests, interact with containers in the cluster in a unified manner, route external requests, and forward them to the corresponding containers to achieve unified orchestration and management of each container; HTTP API module, used to provide HTTP interface.
3. According to claim 2, the container service management platform for embedded systems is characterized in that: The functional layers include: The container management module is used to manage containers through load balancing, fault restart, container controller, and container scheduler components; The service management module is used to manage services through the registration center, remote call, quality control and link tracking components; The image management module is used to manage all image information in the image repository; the image information includes the image source, name, version, creation time and system architecture; The node management module is used to manage all computing nodes in a unified manner. It adds and configures the connection information of each computing node one by one through the IP address of the computing node, registers the computing node, and obtains the name, status, running time, number of container loads, creation time, CPU information, memory information, disk information, and network information of the computing node after registration. The status monitoring module is used to perform node status monitoring and container status monitoring. By collecting the status information of each computing node, it can realize real-time monitoring of the CPU, memory, and storage in the cluster, and collect the real-time running status information of each container application instance.
4. The container service management platform for embedded systems according to claim 3, characterized in that: The container management module also includes: The load balancing component is used to perform load balancing scheduling according to the load of each computing node when scheduling and distributing containers and services, calculate the CPU and memory usage of each computing node, and select an optimal node to average the overall resources; The fault restart component is used to regularly detect and record the status of the container to the local database. When the container status is inconsistent with the expected status, it is determined whether the container operation status has failed. If a failure occurs, the container is restarted to restore the container to normal operation. The container controller is used to start, stop, pause, resume, restart, and destroy containers on the computing nodes. The container scheduler is used to read the list of containers to be scheduled and the list of available computing nodes, schedule containers using pre-defined scheduling algorithms and strategies, and select the optimal node to deploy the container to average the overall resources.
5. The container service management platform for embedded systems according to claim 4, characterized in that: The service management module also includes: The registration center submodule is used to receive the registration information of each service, store the address information of the service provider, and attribute information related to service release. Service consumers obtain the address information of the service provider through active query and passive notification. The remote call submodule is used to encapsulate the calling process between services on different nodes into a unified interface through ID mapping, serialization and deserialization, and network transmission protocol; The quality control submodule is used to define the priority and other attributes for each data packet in the communication layer using the protocol stack IP DCSP for embedded application scenarios, and implement the data packet priority queue in the service transmission logic to cooperate with the service quality control management; The link tracking submodule is used to collect data, process and display service call data by tracking points in different modules, and generate call link diagrams and call topology diagrams.
6. The container service management platform for embedded systems according to claim 5, characterized in that: The image management module is also used to provide buttons such as batch uploading container images, batch deleting container images, searching container images, and viewing container image details on the front-end interface to facilitate operations by users.
7. The container service management platform for embedded systems according to claim 5, characterized in that: The status monitoring module is also used to summarize the real-time operation status information and display it comprehensively on the front-end interface.
8. The container service management platform for embedded systems according to claim 7, characterized in that: The storage layer includes: Image storage, business data storage and log storage; among them, Image storage, used to store container service images; Business data storage, used to store business operation data; Log storage is used to store platform operation logs.