A micro-service based container management method and system

Abstract

The application provides a micro-service-based container management method and system. The application uses micro-service management as a whole system framework, and a micro-service management module in an upper layer communicates with a management module in each client to complete management and control of a non-real-time container platform and a real-time container platform, and solves the problem of joint scheduling and management of real-time containers and non-real-time containers. Meanwhile, the application supports cross-platform distributed service management, service migration based on threshold control and exception processing, and service scheduling of various scheduling indexes.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and more specifically to a container management method and system based on microservices. Background Technology

[0002] Microservices architecture is a way of developing a single application using a series of small-scale services, each running in its own process and communicating with each other in a lightweight manner (usually via HTTP API). These services are deployed independently based on business logic and scope through automated deployment mechanisms, and centralized management of services should be minimal, meaning that each service can be written in a different programming language and use different data storage technologies.

[0003] Real-time containers refer to the application of container technology in the Linux embedded operating system. Non-real-time containers refer to the application of container technology in simple operating systems.

[0004] Chinese patent CN112579253A provides a method for managing real-time and non-real-time containers based on shadow containers. Control of containers on different platforms is achieved through the interaction between shadow containers and containers on different platforms. Summary of the Invention

[0005] The purpose of this invention is to solve the problem that non-real-time containers and real-time containers cannot be managed simultaneously.

[0006] The technical solution of this invention provides a microservice-based container management method for managing real-time and non-real-time containers located on worker nodes, comprising the following steps:

[0007] The data gateway in the microservice management module, located on the master node, receives requests from user terminals. The gateway mapping processing module in the data gateway matches the corresponding route based on the target URL in the request and sends the request to the web processing module in the data gateway. The web processing module uses a filter chain to transmit the request to the real-time container management module and the non-real-time container management module. These modules then forward the request to the proxy service of the real-time or non-real-time container located on the worker node, execute the business logic stored in the request, and return the response result to the user terminal. After the user terminal receives the response result, the configuration information server in the configuration management module retrieves the configuration file from the user terminal. The configuration information client pulls the configuration information server's configuration file and configures the real-time and non-real-time containers according to the configuration file. After the real-time and non-real-time containers obtain the configuration file, the access proxy modules in the real-time and non-real-time container management modules send the microservice application status information running in the configuration file to the service providers in the real-time and non-real-time containers. The service providers upload the microservice application status information to the service registry in the real-time and non-real-time container management modules. The service consumers in the real-time and non-real-time container management modules register with the service registry and obtain a list of available services. The service consumers remotely call the services in the list of available services.

[0008] Preferably, the microservice-based container management method further includes a load balancer located in the real-time container and the non-real-time container, which is used to select and distribute the services in the available service list according to the load balancing algorithm after obtaining the list of available services from the service registry.

[0009] Preferably, the filter chain can intercept and modify the request before it is forwarded to the proxy service. The modifications include parameter verification, permission verification, traffic monitoring, log output, and protocol conversion.

[0010] Preferably, the filter chain can intercept and reprocess the response result before it is returned to the user terminal. The processing includes modifying the response content or response header, logging output, and traffic monitoring.

[0011] Preferably, the list of available services includes service information registered with the service registry.

[0012] Preferably, the data gateway is used to interact with the real-time container management module and the non-real-time container management module; the configuration information server connects to the user terminal and provides the configuration information client with access interfaces for configuration information, encrypted information and decrypted information; the configuration information client obtains and loads configuration information through the configuration information server.

[0013] Preferably, the service consumer remotely invokes the services provided by the service provider via HTTP or a message queue (DDS).

[0014] Preferably, the working node is responsible for running a real-time operating system and a non-real-time operating system, and installing corresponding container modules in the real-time operating system and the non-real-time operating system to form a real-time container and a non-real-time container, thereby enabling the startup of microservice applications.

[0015] Preferably, the master control node is the management node responsible for the overall system operation, and is equipped with a data gateway, a configuration management module, a service registration center, a real-time container management module, and a non-real-time container management module.

[0016] This invention also proposes a microservice-based container management system, employing the aforementioned microservice-based container management method, comprising:

[0017] A microservice management module with a data gateway at the upper layer is used to receive user requests through the data gateway, manage configuration information, discover and register services, and remotely call services and load balance, thereby realizing the management of application scheduling strategies; a real-time container and a non-real-time container with a proxy service at the lower layer are used for container data storage, automatic container service migration, and container lifecycle management; information communication is carried out between the data gateway and the proxy service to realize the management of applications between real-time containers and non-real-time containers.

[0018] This invention uses microservice management as the overall system framework. The upper-layer microservice management module communicates with the management modules in each client to manage and control both real-time and non-real-time container platforms, solving the problem of joint scheduling and management of real-time and non-real-time containers. It also supports cross-platform distributed service governance, service migration based on threshold control and exception handling, and service scheduling with various scheduling metrics. Attached Figure Description

[0019] Figure 1 This is a system software architecture diagram;

[0020] Figure 2 For microservice management modules;

[0021] Figure 3 For data gateway workflow;

[0022] Figure 4 To configure information workflow;

[0023] Figure 5 To discover the registration principle for services;

[0024] Figure 6 Based on the principle of client-side load balancing;

[0025] Figure 7 This is a non-real-time container management module;

[0026] Figure 8 This is a real-time container management module. Detailed Implementation

[0027] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined by the appended claims.

[0028] The relevant terms and concepts used in this invention are as follows:

[0029] Docker: An open-source application container engine.

[0030] Kubelet: A proxy component on Kubernetes worker nodes, running on each node.

[0031] Pod: A logically related set of containers running on a client node.

[0032] In this embodiment, as Figure 1 As shown, the microservice-based container management system uses a microservice architecture and is mainly divided into three functional modules: the upper-layer microservice management module and the lower-layer real-time container management module and non-real-time container management module.

[0033] The microservice management module is primarily responsible for receiving user requests and managing application scheduling strategies through functions such as data gateway, configuration information management, service discovery and registration, remote service invocation, and load balancing. The real-time and non-real-time container management modules are mainly responsible for container data storage on worker nodes, automatic container service migration, and container lifecycle management. The system communicates with the proxy service in the worker nodes through the data gateway of the microservice management module to manage applications across different containers. The main functional components and servers of the microservice management, real-time, and non-real-time container management modules are deployed on the master node, while the worker nodes mainly deploy the functional components of container and service-related clients.

[0034] like Figure 2 As shown, the microservice management module mainly includes a data gateway, service registry, rate limiting and circuit breaker monitoring, configuration management, service scheduling, logging, and container management interface.

[0035] like Figure 3As shown, a data gateway is a service built between user terminals and microservices, primarily responsible for handling non-business logic such as authentication, monitoring, caching, and request routing. The data gateway is the sole external interface for the microservice management module. User terminals first send requests to the data gateway, which then forwards the requests to the microservice instances based on their identifiers. Currently, data gateways are mainly used to address issues such as maintaining a large number of service addresses for clients when dealing with a large number of services, cross-domain service requests, and microservice authentication.

[0036] The data gateway workflow is as follows: The user terminal sends a request to the data gateway. The data gateway, through its gateway mapping processing module, finds a matching route based on the target URL of the request and sends the request information to the web processing module. The web processing module reads the request information sent by the user terminal, uses a specified filter chain, and forwards the request to the actual worker node proxy service to execute business logic and return a response. Filters may execute business logic before (pre) or after (post) the request is forwarded. Filters can intercept and modify requests before they are forwarded to the worker node service proxy, including parameter validation, permission validation, traffic monitoring, log output, and protocol conversion. Filters can also intercept and reprocess responses before they are returned to the user terminal, including modifying response content or headers, logging, and monitoring traffic. The response is then returned to the user terminal via the original path.

[0037] like Figure 4 As shown, for microservice systems, the operation of all services relies on configuration files. While these files are typically managed by each service itself, this can lead to problems such as management difficulty, low security, and poor timeliness. To address these issues, a dedicated configuration management module is needed to manage all configurations uniformly. Configuration files are generated after the data gateway completes communication. The configuration management module mainly consists of two parts: a configuration information server and a configuration information client. The configuration information server is a distributed configuration center, running as an independent microservice application. It connects to user terminals and provides clients with access interfaces for obtaining, encrypting, and decrypting configuration information, running on the master node. The configuration information client is deployed on each microservice in the microservice architecture, obtaining and loading configuration information through the server, running on real-time container worker nodes and non-real-time container worker nodes.

[0038] The configuration information workflow is as follows: User terminals submit configuration files to the configuration information server. The configuration information server (distributed configuration center) is responsible for receiving the configuration information sent by the client and exposing an interface for retrieving configurations to the configuration information client. The configuration information client uses the interface exposed by the configuration information server to pull the configurations from the configuration information server and performs different configurations for real-time containers and non-real-time containers to support service operation and function management.

[0039] Configuration information management uses Git by default to store configuration information, thus naturally supporting version control of microservice configurations. Git client tools provide convenient management and access to configuration content. Additionally, it supports storing configuration information using SVN, local file systems, etc. When configuration information changes, microservices do not need to restart; the configuration information server detects the changes and the configuration information client automatically retrieves and applies the latest configuration. Configuration information management allows for the management of multiple configuration environments used by applications and ensures that applications maintain complete configuration support for normal operation after migration to real-time and non-real-time container environments.

[0040] like Figure 5 As shown, after the real-time and non-real-time containers obtain their respective configuration files, the status information of the microservice applications running within those containers, based on the configuration files, is uploaded through the access proxy module. Service discovery and registration uses a client / server architecture, running two modules on the master node and the real-time and non-real-time container worker nodes. The module running on the master node is the service registry, primarily used for service registration. It maintains a list of available services, storing information on all available services registered to the master node. The real-time and non-real-time container worker nodes are deployed within the various microservice applications in the microservice system. They interact with the master node through the access proxy module and periodically send heartbeat messages to allow the master node to obtain the application running status of the real-time and non-real-time containers.

[0041] The specific service registration and discovery process is as follows: A service registry module is built using the master node. The data gateway provides the basic information for generating configuration files, which in turn provide the basic discoverable information for registration and discovery. When a service provider (worker node, real-time container, and non-real-time container) worker node starts, it registers its current node information with the master node via the access proxy module, using the service name. When a service consumer (real-time container microservice application and non-real-time container microservice application) starts, it registers with the service registry. The service consumer obtains a list of available services, which contains information about all services registered with the service registry (including service provider and its own information). After obtaining the list of available services, the service consumer remotely invokes the services provided by the service provider via HTTP or a message queue (DDS).

[0042] like Figure 6 As shown, load balancing distributes user application requests evenly across multiple worker nodes to expand bandwidth, enhance data processing capabilities, increase throughput, and improve network availability and flexibility. Common load balancing methods can be divided into server-side load balancing and client-side load balancing. The former requires a dedicated load balancing server, while the latter primarily uses client-side (worker nodes) load balancing algorithms to determine which real-time and non-real-time containers to connect to. Client-side load balancing is used here because it involves managing different worker nodes, and its implementation makes the system run more efficiently.

[0043] Client-side load balancing encapsulates the load balancing logic into code on worker nodes; that is, the load balancer resides on the worker nodes. Worker nodes obtain a list of available services provided by the master node from the service registry. With this service list, the load balancer selects a master node instance using a load balancing algorithm before sending a request, thus achieving load balancing. Furthermore, worker node load balancing requires a heartbeat mechanism to maintain the validity of the worker node list; this process needs to be completed in conjunction with the service registry.

[0044] The advantages of this load balancing method are as follows: The load balancer resides on the worker nodes, eliminating the need for a separate load balancing server. Load balancing occurs before the worker nodes send requests, thus the communication between worker nodes and the master node is point-to-point. Each worker node possesses a list of available services, obtained from a service registry, facilitating easy modification and maintenance. Various load balancing algorithms are available, such as round-robin, random, and least connections, allowing worker nodes to switch between algorithms to meet their specific needs.

[0045] like Figure 7As shown, the non-real-time container management module mainly consists of a master node and worker nodes, both running a general Linux operating system and using Docker as the container engine. The master node includes functions such as interface services, resource scheduling, cluster status maintenance, and cluster data storage; the worker nodes include runtime agent and access agent functions, the former being responsible for specific container lifecycle management, and the latter being responsible for distributing requests for a specific service to Pods on the worker nodes.

[0046] The main components of the non-real-time container management module are: data backend, interface service, resource controller, cluster scheduling, proxy service, and access proxy.

[0047] Etcd: Data backend, is a key-value database that combines consistency and high availability, used to store all cluster data in the background.

[0048] Interface Service: This is the external interface of the entire system, providing a set of RESTful APIs for clients and other components to call. It provides the entry point for adding, deleting, modifying, and querying all resources, and offers mechanisms for authentication, authorization, access control, API registration and discovery, as well as cluster management and resource quota control.

[0049] Resource Controller: A component that runs on the master node as a control manager (its functions mainly include lifecycle management and API business logic). It serves as the automated control center for all resource objects and is responsible for maintaining the cluster's state.

[0050] Cluster scheduling: Responsible for resource scheduling, scheduling Pods (newly created Pods without a specified running node) to the appropriate node according to the corresponding scheduling policy.

[0051] Proxy service: A proxy running on each node. It ensures that containers run within Pods. It is responsible for Pod creation, startup, monitoring, restarting, and destruction, as well as volume and network management. The kubelet receives data from the master node and handles the specific container lifecycle management.

[0052] Access Proxy: This is a network access proxy on a node that is responsible for distributing requests to a service to specific Pods on worker nodes.

[0053] A typical process for associating Pods with services is as follows: Pods are created by the Pod controller and accessed internally and externally by specific services. The Pod controller defines Pod resource objects using YAML files, which tag Pod objects for identification. Services can associate Pod resource objects with the same tag type. Pod creation process: Users initiate an API request to create a Pod via the REST API. The interface service writes this request to etcd. The cluster scheduler detects an unbound Pod, begins scheduling, and updates the Pod's node bindings. The proxy service detects a new Pod being scheduled and runs it using Docker. The proxy service obtains the Pod's status and updates it in the interface service.

[0054] The master node is the central hub of the cluster, primarily responsible for exposing API interfaces, monitoring the health status of other servers, and orchestrating communication with them. To address single points of failure, a master-slave configuration is typically used in actual deployments to improve reliability. Within the master node, the cluster scheduler is responsible for resource scheduling, allocating Pods to appropriate machines according to predefined scheduling policies. Factors considered in scheduling decisions include the resource requirements of individual Pods and Pod sets, latency, load balancing, resource limitations, hardware / software / policy constraints, affinity and anti-affinity rules, data location, interference between workloads, and deadlines.

[0055] The default scheduling process involves two steps: First, a pre-selection scheduling process is conducted, which involves traversing all target nodes and filtering out all candidate nodes that meet the requirements (there are multiple candidate strategies). Then, the optimal node is determined. Based on the above, an optimal selection strategy is adopted to calculate the score of each candidate node, and the node with the higher score wins.

[0056] like Figure 8 As shown, the real-time container management module also includes a master node and worker nodes. The master node uses a general-purpose Linux operating system, while the worker nodes use a VxWorks embedded operating system. The master node includes functions such as interface services, resource scheduling, and cluster status maintenance; the worker nodes include runtime agent and access agent functions. The former is responsible for the specific container lifecycle management, while the latter is responsible for distributing requests for a specific service to the Pods on the worker nodes.

[0057] The main components of the real-time container management module are: data backend, interface service, resource controller, cluster scheduling, proxy service, and access proxy.

[0058] Data backend: This is a key-value database that combines consistency and high availability, used to store all cluster data in the backend database.

[0059] Interface Services: The system's external interfaces provide a complete set of RESTful APIs for clients and other components to call. It provides entry points for operations on all resources, including mechanisms for authentication, authorization, access control, service registration and discovery, cluster management, and resource quota control.

[0060] Resource Controller: The control manager component runs on the master node and is responsible for maintaining the cluster state. It is the automated control center for resource objects.

[0061] Cluster scheduling: A resource scheduling component that runs on the master node and is responsible for scheduling Pods to the corresponding worker nodes to run according to the configured scheduling policy.

[0062] Proxy Service: The proxy component runs on each worker node and ensures the operation of containers within Pods. It is responsible for tasks including Pod creation, startup, monitoring, restart, destruction, and management of data volumes and networks. It interacts with the master node through an interface service, receives data from the master node, and performs lifecycle management on the corresponding containers.

[0063] Access Proxy: The node network access proxy component also performs load balancing. It is responsible for distributing requests to a specific service to the Pods on the worker nodes.

[0064] Worker Nodes: Responsible for running both real-time and non-real-time operating systems, and installing container modules within their respective operating systems to form real-time and non-real-time containers, enabling the startup of microservice applications; they also act as proxy service modules to facilitate data interaction between worker nodes and the master node. Master Node: The management node responsible for the overall system operation, equipped with a data gateway module, configuration management module, service discovery and registration module, and real-time and non-real-time container management module. Through data processing and interaction between these modules, it achieves centralized management and scheduling of real-time and non-real-time containers.

[0065] This embodiment, through a microservice architecture, can satisfy dual-container management while also ensuring the developability and customizability of management services due to the open-source, modular, and loosely coupled characteristics of microservice architecture. Given the increasing use of real-time operating systems and the growing necessity of real-time containers, the emergence of a microservice management system effectively compensates for the shortcomings of the current environment and provides assurance for production.

Claims

1. A container management method based on microservices, characterized in that, The method for managing real-time and non-real-time containers located on worker nodes includes the following steps: The data gateway in the microservice management module is located on the master node and receives requests from user terminals. The data gateway is used to interact with the real-time container management module and the non-real-time container management module. The gateway mapping processing module in the data gateway matches the corresponding route based on the target URL in the request and sends the request to the web processing module in the data gateway. The web processing module uses a filter chain to transmit requests to the real-time container management module and the non-real-time container management module. These modules then forward the requests to the proxy service located in the real-time or non-real-time container on the worker node. There, the business logic stored in the request is executed, and a response is returned to the user terminal. The filter chain can intercept and modify requests before they are forwarded to the proxy service, including parameter validation, permission validation, traffic monitoring, log output, and protocol conversion. Furthermore, the filter chain can intercept and reprocess the response before it is returned to the user terminal, including modifying the response content or headers, logging, and monitoring traffic. After the user terminal receives the response, the configuration information server in the configuration management module obtains the configuration file from the user terminal; the configuration information server connects to the user terminal and provides the configuration information client with access interfaces for configuration information, encrypted information and decrypted information; The configuration information client in the configuration management module pulls configuration files from the configuration information server and configures real-time and non-real-time containers according to the configuration files; the configuration information client obtains and loads configuration information through the configuration information server. After the real-time container and the non-real-time container obtain the configuration file, the access proxy module in the real-time container management module and the non-real-time container management module send the status information of the microservice application running in the configuration file to the service provider in the real-time container and the non-real-time container. Service providers upload microservice application status information to the service registry in both the real-time container management module and the non-real-time container management module; Service consumers in both the real-time and non-real-time container management modules register with the service registry and obtain a list of available services. Service consumers remotely invoke services from the list of available services.

2. The microservice-based container management method as described in claim 1, characterized in that, It also includes load balancers located in real-time and non-real-time containers, which, after obtaining the list of available services from the service registry, select services in the list for load balancing according to the load balancing algorithm.

3. The microservice-based container management method as described in claim 1, characterized in that, The list of available services includes service information registered with the service registry.

4. The microservice-based container management method as described in claim 1, characterized in that, The service consumer remotely invokes the services provided by the service provider via HTTP or a message queue (DDS).

5. The microservice-based container management method as described in claim 1, characterized in that, The working node is responsible for running a real-time operating system and a non-real-time operating system, and installing corresponding container modules in the real-time operating system and the non-real-time operating system to form a real-time container and a non-real-time container, thereby enabling the startup of microservice applications.

6. The microservice-based container management method as described in claim 1, characterized in that, The master control node is the management node responsible for the overall system operation, and it is equipped with a data gateway, configuration management module, service registration center, real-time container management module, and non-real-time container management module.

7. A microservice-based container management system, characterized in that, The container management method based on microservices as described in any one of claims 1-6 includes: A microservice management module with a data gateway located at the upper layer is used to receive user requests through the data gateway, manage configuration information, discover and register services, and remotely call services and load balance, thereby realizing the management of application scheduling strategies. Real-time and non-real-time containers with proxy services located at the underlying layer are used for container data storage, automatic container service migration, and container lifecycle management. By communicating with the agent service through the data gateway, the management of applications between real-time containers and non-real-time containers can be achieved.

Images