Container engine device and method for realizing a container engine
By separating the container engine into management and worker node components and using a communication protocol, the resource consumption and deployment complexity issues of existing container engines are addressed, enabling efficient management in resource-constrained environments.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- ZTE CORP
- Filing Date
- 2022-10-18
- Publication Date
- 2026-04-15
AI Technical Summary
Current container engines deployed on worker nodes in cloud computing clusters excessively consume CPU and memory resources, particularly in resource-constrained environments like IoT clusters, and require significant development efforts for compatibility with container orchestration systems.
The container engine is split into a first device on the management node and a second device on the worker node, communicating via a communication protocol to manage container operations, reducing resource consumption and simplifying deployment by separating the container engine components.
This approach reduces resource consumption on worker nodes and simplifies deployment, making it suitable for resource-constrained environments while maintaining efficient container management.
Smart Images

Figure 0007846756000001 
Figure 0007846756000002 
Figure 0007846756000003
Abstract
Description
Technical Field
[0001] This disclosure was filed with the State Intellectual Property Office on October 18, 2021, with application number CN202111212628. 4 and and claims the priority of a Chinese patent application titled "Container Engine and Method for Realizing Container Engine, Electronic Device, Storage Medium", and all the contents of these applications are incorporated herein by reference.
[0002] Embodiments of this disclosure relate to the field of cloud computing container technology, but are not limited thereto. Specifically, they relate to container engines Device and methods for realizing container engines.
Background Art
[0003] As a cutting-edge technology in the field of cloud computing, container technology provides an independent execution environment for business programs. At the same time, the deployment, startup, and deletion of containers are fast, and the performance loss of the central processing unit (CPU), memory, and input / output (IO) is zero.
[0004] In the container field, container engines such as Docker, Containerd, and Container Runtime Interface Open (CRI-O) have emerged. These container engines provide external application programming interfaces (APIs) and command lines, and offer container image management and container cycle management functions via APIs and command lines. Currently, container engines such as Docker, Containerd, and CRI-O, which are widely used in the industry, are generally deployed on worker nodes along with the node agent of the container orchestration system, while the management node has only the API of the container orchestration system deployed. This deployment method has the problem that the container engine and the node agent of the container orchestration system on the worker nodes consume excessive CPU and memory resources of the worker nodes. [Overview of the Initiative] [Problems that the invention aims to solve]
[0005] Embodiments of the present disclosure are container engines Device And provides a method for realizing a container engine. [Means for solving the problem]
[0006] In a first aspect, embodiments of the present disclosure provide a method for implementing a container engine applied to a first device located on a management node, the method comprising: sending a container operation request to a second device using a communication protocol; and receiving a container operation response sent by the second device using the communication protocol.
[0007] In a second aspect, embodiments of the present disclosure provide a method for implementing a container engine applicable to a second device located on a management node or worker node, comprising the steps of: receiving a container operation request transmitted by the first device and performing a container operation using a communication protocol; and transmitting a container operation response to the first device using the communication protocol.
[0008] In a third aspect, the present disclosure provides an electronic device comprising at least one processor and a memory that stores at least one program, and when the at least one program is executed by the at least one processor, enables the implementation of any one of the container engines.
[0009] In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium in which a computer program is stored, wherein when the computer program is executed by a processor, the computer-readable storage medium enables the implementation of any one of the container engines.
[0010] In a fifth aspect, the present embodiment of the disclosure provides a container engine comprising a first device provided on a management node and a second device provided on a management node or a worker node, wherein the first device comprises a container engine core module having a container management submodule configured to transmit container operation requests to a master agent submodule and a master agent submodule configured to transmit container operation requests to a container operation submodule of the second device and to receive container operation responses transmitted by the container operation submodule of the second device, employing a communication protocol, and the second device comprises a container spacer module comprising a container operation submodule configured to receive container operation requests transmitted by the master agent submodule of the first device and to transmit the container operation requests to a container runtime module, employing the communication protocol, and a container runtime module configured to perform container operations and transmit container operation responses to the container operation submodule, wherein the container operation submodule further provides a container engine configured to transmit container operation responses to the master agent submodule of the first device, employing the communication protocol. [Brief explanation of the drawing]
[0011] [Figure 1] Figure 1 is a schematic diagram of the container engine configuration in related technologies. [Figure 2] Figure 2 is a block diagram of the configuration of a container engine provided by an embodiment of the present disclosure. [Figure 3] Figure 3 is a flowchart illustrating a method for implementing a container engine applied to a management node, as provided by one embodiment of the present disclosure. [Figure 4] Figure 4 is a flowchart illustrating a method for implementing a container engine applied to a worker node, as provided by another embodiment of the present disclosure. [Modes for carrying out the invention]
[0012] To enable those skilled in the art to better understand the technical proposals of this disclosure, the container engine and methods for realizing the container engine, electronic equipment, and computer-readable storage media provided herein are described in detail below, with the help of drawings.
[0013] Illustrative embodiments will be described in detail below with reference to the drawings, but these exemplary embodiments may be embodied in different forms and should not be construed as being limited to the embodiments described herein. Rather, the provision of these embodiments is intended to make this disclosure thorough and complete and to allow those skilled in the art to fully understand the scope of this disclosure.
[0014] The various embodiments and features of the present disclosure can be combined with each other, insofar as they do not conflict.
[0015] As used in this disclosure, the terms "and / or" include any or all combinations of at least one related enumeration item.
[0016] The terms used herein are for the purpose of describing specific embodiments and are not intended to limit this disclosure. The singular forms “one” and “the” used herein are also intended to include the plural unless otherwise clearly stated in the preceding or following text. When the terms “includes” and “consist of” are used herein, they specify the presence of such features, wholes, steps, operations, elements, and / or components, but it will be further understood that they do not exclude the presence or addition of at least one other feature, whole, step, operation, element, component, and / or group thereof.
[0017] All terms used herein (including technical and scientific terms) shall have the same meaning as those generally understood by those skilled in the art, unless otherwise specified. Furthermore, it will be understood that such terms, as defined in common dictionaries, shall have meanings consistent with their meanings in the context of the relevant art and this disclosure, and shall not be interpreted as having ideal or overly formal meanings unless explicitly defined herein.
[0018] In the container field, container engines such as Docker, Containerd, and CRI-O have emerged. These container engines provide external APIs and command lines, offering container image management and container five-cycle management functions via APIs and command lines. Currently, container engines widely used in the industry, such as Docker, Containerd, and CRI-O, can be broadly divided into three main components: a container engine core module, a container spacer module, and a container runtime module. As shown in Figure 1, the container engine core module specifically includes API submodules, client submodules, container management submodules, container image management submodules, node management submodules, and image storage submodules. The container spacer module specifically includes I / O transfer submodules, container resource reclamation submodules, and container operation submodules. The container runtime module specifically includes Open Container Initiative (OCI) runtime submodules or LXC (Linux® Container) submodules.
[0019] The functions of each submodule are described below.
[0020] The API submodule is responsible for providing container engine functionality and service software interface submodules to external systems (e.g., container orchestration systems).
[0021] The client sub-module is responsible for the command-line tools provided by the container engine for container and image operations.
[0022] The container management sub-module is responsible for managing the lifecycle states of containers, such as creation, execution, stop, and deletion.
[0023] The container image management sub-module is responsible for managing the image state and the relationships between images.
[0024] The node management sub-module is responsible for managing information such as management node resources and security states.
[0025] The image storage sub-module is responsible for managing the actual files or devices of images and reading and writing to the image content.
[0026] The input / output transfer sub-module is responsible for transferring external inputs into the container and transferring the outputs inside the container to the container engine.
[0027] The container resource recovery sub-module is responsible for recovering the system resources consumed by dead containers.
[0028] The container operation sub-module is responsible for directly initiating operations such as creating, executing, stopping, deleting, and viewing containers by calling the container runtime module.
[0029] The OCI runtime sub-module is a container runtime tool that meets the definition of the OCI specification and is responsible for performing specific operations such as creating, executing, stopping, deleting, and viewing containers on the operating system.
[0030] The LXC submodule is provided by the open-source Linux Containerer project and allows you to create, run, stop, delete, and view container tools or dynamic libraries on Linux.
[0031] The container engine provides API submodules or client submodules to the container orchestration system (e.g., K8S (Kubernetes), K3S, etc.), which instructs the container engine using the API submodules or client submodules to perform container management functions such as creating, deleting, querying, importing, exporting, pulling images from a repository, and pushing images to a repository, as well as creating, deleting, starting, stopping, pausing, resuming containers, and querying container status. In current container engine implementations, functions such as creating, deleting, starting, stopping, pausing, and resuming containers, which were previously achieved by calling the underlying operating system, are integrated into the OCI runtime submodule or LXC submodule. The container engine internally maintains state management of the container lifecycle, and container operations are performed by the container operations submodule calling the OCI runtime submodule or LXC submodule. Furthermore, each container engine is equipped with a container spacer module to handle resource reclamation when internal container processes terminate and to relay standard input, standard output, and standard error of internal container processes.
[0032] The emergence of major container orchestration systems such as K8S, K3S, and Docker Swarm has made deploying and upgrading containers in cluster environments more convenient. This has led to the formation of a set of cloud computing clusters where the container orchestration system acts as the management portal and the container engine acts as the working implementation unit. Business developers can use the container orchestration system to quickly deploy groups of business processes in container form to the internal nodes of the cluster. In such cloud computing clusters, individual physical devices (e.g., servers or singleboards) are divided into management nodes and worker nodes by the functional units installed on them. Management nodes are servers or singleboards with relatively sufficient CPU, memory, and storage resources, and the container orchestration system is often deployed on them. Worker nodes are typically servers or singleboard devices with relatively limited CPU, memory, and storage resources. The container orchestration agent and container engine are deployed on the worker nodes, and the containers run precisely on the container engine. Depending on the cluster design's reliability, response speed, and other metrics, one or more management nodes can be deployed to the cluster, and depending on the cluster's worker load metrics, one or more worker nodes can be deployed to the cluster. In extreme cases, the management node and worker nodes may be deployed on the same physical device.
[0033] In a typical cloud computing cluster node, the container orchestration system's API is deployed on the management node, while the node agent and container engine are deployed on the worker nodes. When a user needs to create a container, they simply send a command to the container orchestration system's API located on the management node, which then instructs the container engine, via the node agent, to complete the actual container creation, startup, and management tasks. However, the container engine and node agent on worker nodes have a problem: they excessively consume the worker node's CPU and memory resources. For example, the open-source Containerd engine requires 300 megabytes (M) of memory space to create and start 500 containers. This is unacceptable in resource-constrained clusters, particularly in IoT (Internet of Things) cluster spaces, where embedded devices are used as worker nodes. Furthermore, deploying only OCI runtime submodules or LXC submodules to worker nodes requires developing adapter modules that meet the requirements for the container orchestration system to invoke the container engine, which can lead to a heavy development burden and system instability.
[0034] Figure 2 is a block diagram of the container engine configuration provided by an embodiment of the present disclosure. As shown in Figure 2, the embodiment of the present disclosure modifies the deployment configuration of the container engine on a cluster, dividing the container engine into a first device 201 and at least one second device 202, the first device 201 and the second device 202 being completely independent of each other.
[0035] Here, the relationship between the first device 201 and the second device 202 is in master-slave mode, such as one master and one slave, or one master and multiple slaves. Specifically, the first device 201 is a master device installed in the management node, and the second device 202 is a slave device installed in the worker node. In some cases, the first device 201 and the second device 202 may be installed in the management node simultaneously, meaning the management node also functions as a work node.
[0036] A link between the first device 201 and the second device 202 may employ one of the following technologies: bus technology, wired network technology, or wireless network technology.
[0037] The first device 201 includes a container engine core module 2011, and the second device 202 includes a slave agent module 2021, a container spacer module 2022, and a container runtime module 2023.
[0038] The Container Engine Core Module 2011 includes the API submodule, client submodule, container management submodule, container image management submodule, and master agent submodule.
[0039] In some exemplary embodiments, the slave agent module 2021 includes a communication submodule, an image storage submodule, and a node management submodule. In further exemplary embodiments, the slave agent module 2021 includes a communication submodule and a node management submodule, and the image storage submodule is a separate module. In further exemplary embodiments, the slave agent module 2021 includes a communication submodule and an image storage submodule, and the node management submodule is a separate module. In further exemplary embodiments, the slave agent module 2021 includes a communication submodule, the image storage submodule is a separate module, and the node management submodule is also a separate module.
[0040] The Container Spacer Module 2022 includes an I / O transfer submodule, a container resource retrieval submodule, and a container operation submodule.
[0041] Container Runtime Module 2023 includes OCI Runtime submodules or LXC submodules.
[0042] In some exemplary embodiments, the first device 201 communicates with the second device 202 using the Remote Procedure Call Protocol (RPC), that is, it performs corresponding functions by calling the second device 202 using RPC. For example, the master agent submodule communicates with the slave agent module 2021 using RPC, that is, it performs corresponding functions by calling the slave agent module 2021 using RPC.
[0043] In some exemplary embodiments, when a first device 201 and a second device 202 are simultaneously installed on a management node, the first device 201 communicates with the second device 202 using Unix sockets (Sock) or inter-process communication (IPC). For example, a master-agent submodule communicates with a slave-agent module 2021 using Unix Sock or IPC.
[0044] In some exemplary embodiments, a client / service (C / S) model is employed for establishing communication between the first device 201 and the second device 202. For example, the first device 201 acts as the client and the second device 202 acts as the service. In this configuration, after startup, the second device 202 listens on its address and port, and after power-on, the first device 201 obtains the address and port of the second device 202, spontaneously establishes a link with the second device 202 according to its address and port, and registers with the second device 202.
[0045] In some exemplary embodiments, when the image storage submodule is a separate module, communication between the slave agent module 2021 and the image storage submodule is performed using IPC. When the image storage submodule is a submodule of the slave agent module 2021, the image storage submodule shares the same process as the slave agent module 2021, thereby reducing the occupation of process resources by the second device 202.
[0046] In some exemplary embodiments, when the image storage submodule is a single separate module, the master-agent submodule communicates indirectly with the image storage submodule by using RPC as a relay through the slave-agent module 2021. In some further exemplary embodiments, when the image storage submodule is a single separate module, the master-agent submodule communicates directly with the image storage submodule by using RPC.
[0047] In some exemplary embodiments, when the node management submodule is a separate module, communication between the slave agent module 2021 and the node management submodule is performed using IPC. When the node management submodule is a submodule of the slave agent module 2021, the node management submodule shares the same process as the slave agent module 2021, thereby reducing the occupation of process resources by the second device 202.
[0048] In some exemplary embodiments, when the node management submodule is a separate module, the master agent submodule communicates indirectly with the node management submodule via RPC through the slave agent module 2021. In some further exemplary embodiments, when the node management submodule is a separate module, the master agent submodule communicates directly with the node management submodule via RPC.
[0049] In some exemplary embodiments, the container spacer module 2022, the container runtime module 2023, and the slave agent module 2021 are each implemented using independent processes, the container spacer module 2022 communicates with the slave agent module 2021 using IPC, and the container runtime module 2023 communicates with the slave agent module 2021 using IPC.
[0050] In some exemplary embodiments, the master agent submodule employs ttrpc to communicate directly with the container spacer module 2022, thereby accelerating the speed of container operations. Here, trpc is the codename for an open-source software project, such as GRPC for low-memory environments.
[0051] In some exemplary embodiments, a master-agent submodule RPC is employed to communicate indirectly with the container spacer module 2022 via a slave agent module 2021.
[0052] In some exemplary embodiments, the container spacer module 2022 simplifies the slave agent module 2021 by calling the container runtime module 2023 to perform container operations.
[0053] The aforementioned changes to the container engine architecture have altered some aspects of the internal implementation of the container engine. The following describes the internal implementation of the container engine based on these changes. However, the following description does not represent the entire implementation process of the container engine, but rather a part of the implementation process that differs from the internal implementation of the container engine before the changes. The described implementation is not intended to limit the implementation process of the modified container engine.
[0054] Figure 3 is a flowchart illustrating a method for implementing a container engine applied to a management node, as provided by one embodiment of the present disclosure.
[0055] In a first aspect, referring to Figure 3, one embodiment of the present disclosure provides a method for realizing a container engine applied to a first device located in a management node, the method comprising steps 300 and 301.
[0056] Step 300: The second device adopts a communication protocol and sends a container operation request.
[0057] In some exemplary embodiments, the communication protocol includes one of RPC, sockets, or IPC. Specifically, if the first and second devices are simultaneously located on a management node, the communication protocol employed may be sockets or IPC, and if the first device is located on a management node and the second device is located on a worker node, the communication protocol employed may be RPC.
[0058] In some exemplary embodiments, when a container orchestration system receives an API request, it can use a communication protocol depending on the content requested in the API request to send a container operation request to a second device. If the API request requests a container operation, the container operation request can be sent to the second device directly using the communication protocol to perform the container operation, or, to perform a container image operation, the communication protocol can be used first to send a container image operation request to the second device, and then, to perform the container operation, the communication protocol can be used to send a container operation request to the second device. For example, when creating a container, it is necessary to first create a container image and then create the container. When it is necessary to create a container, it is possible to send an API request first to create the container image and then send another API request to create the container, or to send only one API request to create both the container image and the container.
[0059] In some exemplary embodiments, API requests can be listened to via a socket file or a specified network port in Unix.
[0060] In some exemplary embodiments, container operations include at least one of the following: container creation, container deletion, container execution, container stop, container pause, container restart, new process creation within a container, and container information queri.
[0061] In some exemplary embodiments, container image operations include at least one of the following: container image creation, container mirror deletion, container mirror information retrieval, format conversion, and container read / write layer creation.
[0062] Step 301: Employ a communication protocol to receive the container operation response transmitted by the second device.
[0063] In some exemplary embodiments, the method employs a communication protocol to transmit a container operation request to a second device, prior to this step, The steps include: using a communication protocol to send a node status inquiry request to a second device, and using the communication protocol to receive a node status inquiry response containing node status information sent by the second device; The steps include: using a communication protocol to send a first node resource request to a second device, and using a communication protocol to receive a first node resource request response sent by the second device; The steps include: using a communication protocol to send a second node resource request to a second device, and using a communication protocol to receive a second node resource request response sent by the second device; The method further includes at least one of the following steps: sending a container image manipulation request to a second device using a communication protocol; and receiving a container image manipulation response sent by the second device using a communication protocol.
[0064] In some exemplary embodiments, when a container orchestration system receives an API request, it can adopt a communication protocol according to the content requested in the API request and send a container image manipulation request to a second device. In some exemplary embodiments, the method is The steps include receiving a console type parameter that indicates the link type of standard input, standard error, and standard output, The process further includes the step of using a communication protocol to include console type parameters in a container creation request or process creation request and sending it to a second device.
[0065] In some exemplary embodiments, the link types for standard input, standard error, and standard output include linking standard input, standard error, and standard output to a specified console, linking standard input, standard error, and standard output to a specified file, and not linking them at all.
[0066] In some exemplary embodiments, console type parameters may be transmitted to the first device by a container orchestration system or other external system.
[0067] In some exemplary embodiments, if the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a specified console, the method is: The steps include: adopting a communication protocol and including the port of the first device in a container creation request or process creation request and sending it to the second device; The steps include: adopting a communication protocol to transmit the standard input of the container to the second device via a port on the first device, The further step includes listening on a port of the first device using a communication protocol to receive the standard output and standard error of a container transmitted by the second device, and outputting the standard output and standard error of the container to a designated console.
[0068] In some exemplary embodiments, if the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a specified file, the method is: The process further includes a step of using a communication protocol to include the filename of a specified file in a container creation request or process creation request and sending it to a second device.
[0069] In some exemplary embodiments, when a first device communicates with a second device using a C / S model, the first and second devices need to establish a link, and when the first device is a client, it needs to register with the second device. Specifically, this is implemented as follows: That is, before the step of sending a container operation request to the second device using a communication protocol, the method further includes the steps of sending a link establishment request to the second device using a communication protocol based on a pre-configured address and port of the second device, and receiving a link establishment response sent by the second device using a communication protocol, in order to complete the link establishment, and sending a registration command to the second device using a communication protocol, and receiving a registration response sent by the second device using a communication protocol, in order to complete the registration.
[0070] In some exemplary embodiments, the address and port of the second device may be pre-configured in a configuration file.
[0071] If there are two or more second devices, the deployment file will contain the address and port of each second device, and the first device will establish a link with each second device and register each second device separately.
[0072] In some exemplary embodiments, after the step of receiving a registration response transmitted by a second device using a communication protocol, the method further includes the step of periodically transmitting keep-alive information to the second device using a communication protocol in order to implement a health check mechanism.
[0073] In some exemplary embodiments, prior to the step of sending a first node resource request to a second device, the method: The process further includes the steps of using a communication protocol to send a container spacer module creation request to a second device, and using a communication protocol to receive a container spacer module creation response sent by the second device.
[0074] In some exemplary embodiments, the container spacer module creation response includes ports for the container spacer module.
[0075] Figure 4 is a flowchart illustrating a method for implementing a container engine applied to a worker node, as provided by another embodiment of the present disclosure.
[0076] In a second aspect, referring to Figure 4, another embodiment of the present disclosure provides a method for realizing a container engine applicable to a second device located in a management node or worker node, the method comprising steps 400 and 401.
[0077] Step 400: Employ a communication protocol to receive a container operation request transmitted by the first device and perform the container operation.
[0078] In some exemplary embodiments, the communication protocol includes one of RPC, sockets, or IPC. Specifically, if the first and second devices are simultaneously located on a management node, the communication protocol employed may be sockets or IPC, and if the first device is located on a management node and the second device is located on a worker node, the communication protocol employed may be RPC.
[0079] In some exemplary embodiments, container operations include at least one of the following: container creation, container deletion, container execution, container stop, container pause, container restart, new process creation within a container, and container information queri.
[0080] Step 401: A communication protocol is adopted to send the container operation response to the first device.
[0081] In some exemplary embodiments, the method employs a communication protocol to receive a container operation request transmitted by the first device, prior to that step, The steps include: receiving a node status inquiry request transmitted by the first device using a communication protocol, querying node status information, and transmitting a node status inquiry response containing node status information to the first device using a communication protocol; The steps include: adopting a communication protocol to receive a first node resource request transmitted by the first device, allocating a first node resource for the first device, and adopting a communication protocol to send a first node resource request response to the first device; The steps include: adopting a communication protocol to receive a second node resource request transmitted by the first device, allocating the second node resource for the first device, and adopting a communication protocol to send a second node resource request response to the first device; The process further includes at least one of the following steps: receiving a container image manipulation request transmitted by a first device using a communication protocol, performing a container image manipulation, and transmitting a container image manipulation response to the first device using a communication protocol.
[0082] In some exemplary embodiments, container image operations include at least one of the following: container image creation, container mirror deletion, container mirror information retrieval, format conversion, and container read / write layer creation.
[0083] In some exemplary embodiments, the method is The process further includes the step of receiving console type parameters transmitted by a first device, which indicate the link types of standard input, standard error, and standard output, by employing a communication protocol.
[0084] In some exemplary embodiments, if the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a specified console, the method is: The steps include: adopting a communication protocol to receive the port of the first device transmitted by the first device, The communication protocol is adopted, and the standard input of the container transmitted by the first device is received by the port of the first device, and the standard input of the container is input to the container, The further step includes receiving the standard output and standard error of a container, and, employing a communication protocol, transmitting the standard output and standard error of the container to the first device via a port of the first device.
[0085] In some exemplary embodiments, if the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a specified file, the method is: The steps include: adopting a communication protocol to receive the filename of the specified file transmitted by the first device, The process further includes creating a specified file with the filename of the received specified file as its filename, and writing the container's standard input and standard error to the specified file.
[0086] In some exemplary embodiments, when a C / S model is used to communicate between a first device and a second device, the first device and the second device must establish a link, and when the first device is the client, it must register with the second device. Specifically, this is implemented as follows: That is, before the step of receiving a container operation request sent by the first device using a communication protocol, the method further includes the steps of: to complete the establishment of the link, to receive a link establishment request sent by the first device using a communication protocol, to listen on a pre-configured address and port of the second device using a communication protocol, and to send a link establishment response to the first device using a communication protocol; and to complete the registration, to receive a registration command sent by the first device using a communication protocol, to execute the registration command, and to send a registration response to the first device using a communication protocol.
[0087] In some exemplary embodiments, the address and port of the second device may be pre-configured. The specific configuration method is not particularly limited and can be, for example, configured in a configuration file.
[0088] If there are two or more second devices, the deployment file will contain the address and port of each second device, and the first device will establish a link with each second device and register each second device separately.
[0089] In some exemplary embodiments, after the step of employing a communication protocol to send a registration response to a first device, the method further includes the step of employing a communication protocol to periodically receive keep-alive information transmitted by the first device in order to implement a health check mechanism.
[0090] In some exemplary embodiments, prior to the step of receiving a first node resource request transmitted by the first device, the method, The process further includes the steps of receiving a container spacer module creation request transmitted by a first device using a communication protocol, creating a container spacer module, and transmitting a container spacer module creation response to the first device using a communication protocol. In some exemplary embodiments, the container spacer module creation response includes ports for the container spacer module.
[0091] In a third aspect, another embodiment of the present disclosure provides an electronic device comprising at least one processor and a memory storing at least one program, which, when the at least one program is executed by the at least one processor, enables the implementation of any one of the container engines.
[0092] Here, a processor is a device that has data processing capabilities, and this includes, but is not limited to, a central processing unit (CPU). Memory is a device that has data storage capabilities, and this includes, but is not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH).
[0093] In some embodiments, the processor and memory are connected to each other via a bus, and further connected to other components of the computing device.
[0094] In a fourth aspect, another embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored, and which, when the computer program is executed by a processor, enables the implementation of any one of the above-described container engine implementation methods.
[0095] As shown in Figure 2, in a fifth aspect, another embodiment of the present disclosure provides a container engine including a first device 201 and a second device 202, wherein the first device is located on a management node and the second device is located on either a management node or a worker node.
[0096] Here, the first device comprises a container engine core module 2011 having a container management submodule configured to send container operation requests to a master agent submodule, and a master agent submodule configured to send container operation requests to a container operation submodule of the second device using a communication protocol, and to receive container operation responses sent by the container operation submodule of the second device using a communication protocol.
[0097] Here, the second device 202 includes a container spacer module 2022 which includes a container operation submodule that employs a communication protocol to receive a container operation request transmitted by the master agent submodule of the first device 201 and transmit the container operation request to the container runtime module 2023, and a container runtime module 2023 which performs a container operation and transmits a container operation response to the container operation submodule, the container operation submodule further employs a communication protocol and transmits a container operation response to the master agent submodule of the first device 201.
[0098] In some exemplary embodiments, the master agent submodule employs ttrpc to communicate directly with the container spacer module 2022, thereby accelerating the speed of container operations.
[0099] In a further exemplary embodiment, the master agent submodule communicates indirectly with the container spacer module 2022 via a slave agent module 2021 by employing RPC. In this case, the second device 202 further includes a slave agent module 2021, which includes a communication submodule that employs a communication protocol to enable communication with the master agent submodule.
[0100] In some exemplary embodiments, when a C / S model is used to communicate between a first device and a second device, the first device and the second device must establish a link, and when the first device is the client, it must register with the second device. Specifically, this is implemented as follows: The master agent submodule is configured to further use a communication protocol to send a link establishment request to the slave agent module 2021, according to the address and port of the pre-configured slave agent module 2021, to receive a link establishment response sent by the slave agent module 2021, thereby completing the link establishment, to send a registration command to the slave agent module 2021, and to receive a registration response sent by the slave agent module 2021, thereby completing the registration.
[0101] The second device 202 further includes a slave agent module 2021 configured to receive a link establishment request sent by a master agent submodule by listening to the address and port of a pre-configured slave agent module 2021 using a communication protocol, complete the establishment of the link by sending a link establishment response to the master agent submodule using a communication protocol, receive a registration command sent by the master agent submodule using a communication protocol, execute the registration command, and complete the registration by sending a registration response to the master agent submodule using a communication protocol.
[0102] In some exemplary embodiments, the address and port of the slave agent module 2021 may be pre-configured in the deployment file.
[0103] If there are two or more second devices, the deployment file will contain the address and port of each second device, and the first device will establish a link with each second device and register each second device separately.
[0104] In some exemplary embodiments, the master agent submodule is further configured to employ a communication protocol to periodically transmit keep-alive information to the slave agent module 2021 in order to implement a health check mechanism. The slave agent module 2021 is further configured to employ a communication protocol to periodically receive keep-alive information transmitted by the master agent submodule of the first device in order to implement a health check mechanism.
[0105] In some exemplary embodiments, the container engine core module 2011 of the first device 201 further includes an API submodule configured to receive API requests transmitted by a container orchestration system and to transmit container operation requests to a container management submodule or container image operation requests to a container image management submodule, depending on the content requested in the API request; and a container image management submodule configured to receive container image operation requests transmitted by the API submodule, to transmit container image operation requests to an image storage submodule of the second device using a communication protocol, and to receive container image operation responses transmitted by the image storage submodule of the second device using a communication protocol. The container management submodule further includes an API submodule configured to receive container operation requests transmitted by the API submodule, to transmit container operation requests to a container operation submodule of the second device using a communication protocol, and to receive container operation responses transmitted by the container operation submodule of the second device using a communication protocol.
[0106] The second device 202 further includes a slave agent module 2021, which includes an image storage submodule configured to receive container image operation requests transmitted by the container image management submodule of the first device using a communication protocol, perform container image operations, and transmit container image operation responses to the container image management submodule of the first device using a communication protocol. The container operation submodule is configured to receive container operation requests transmitted by the container management submodule of the first device using a communication protocol, perform container operations, and transmit container operation responses to the container management submodule of the first device using a communication protocol.
[0107] In some exemplary embodiments, the container management submodule is further configured to send node status inquiry requests to the master agent submodule. The master agent submodule is further configured to employ a communication protocol to send node status inquiry requests to the node management submodule of a second device, to employ a communication protocol to receive node status inquiry responses containing node status information sent by the node management submodule of the second device, and to send the node status inquiry responses to the container management submodule.
[0108] The second device 202 further includes a slave agent module 2021, which includes a node management submodule configured to receive node status inquiry requests sent by the master agent submodule of the first device, query node status information, and send a node status inquiry response containing the node status information to the master agent submodule of the first device, using a communication protocol.
[0109] In some exemplary embodiments, the container management submodule is further configured to send a first node resource request to the master agent submodule, the master agent submodule is further configured to use a communication protocol to send the first node resource request to the node management submodule of a second device, and to use a communication protocol to receive the first node resource request response sent by the node management submodule of the second device and send the first node resource request response to the container management submodule.
[0110] The second device 202 further includes a slave agent module 2021, which includes a node management submodule configured to receive a first node resource request sent by the master agent submodule of the first device, allocate a first node resource for the first device, and send a first node resource request response to the master agent submodule of the first device, using a communication protocol.
[0111] In some exemplary embodiments, the container management submodule is further configured to send a second node resource request request to the master agent submodule, the master agent submodule is further configured to use a communication protocol to send the second node resource request request to the node management submodule of the second device, use a communication protocol to receive the second node resource request response sent by the node management submodule of the second device, and send the second node resource request response to the container management submodule.
[0112] The second device 202 further includes a slave agent module 2021, which includes a node management submodule configured to receive a second node resource request sent by the master agent submodule of the first device, allocate the second node resource for the first device, and send a second node resource request response to the master agent submodule of the first device, using a communication protocol.
[0113] In some exemplary embodiments, the container engine core module 2011 further includes a client submodule configured to receive console type parameters indicating the link types of standard input, standard error, and standard output, and to transmit the console type parameters to a container management submodule. The container management submodule is further configured to transmit the console type parameters to a master agent submodule. The master agent submodule is further used to employ a communication protocol to include the console type parameters in a container creation request or process creation request and transmit them to an I / O transfer submodule of a second device.
[0114] The Container Spacer Module 2022 further includes an I / O Transfer submodule that is configured to receive console type parameters and send them to the Container Operations submodule.
[0115] In some exemplary embodiments, the container management submodule is further configured to send its port to the master agent submodule when the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a designated console. The master agent submodule is further configured to employ a communication protocol to include the port of the container management submodule in a container creation request or process creation request and send it to the I / O transfer submodule of the second device, employ a communication protocol to send the standard input of the container to the I / O transfer submodule of the second device via the port of the container management submodule, and to employ a communication protocol to listen on the port of the container management submodule to receive the standard output and standard error of the container sent by the I / O transfer submodule of the second device, and to send the standard output and standard error of the container to the container management submodule. The container management submodule is further configured to output the standard output and standard error of the container to a designated console.
[0116] The input / output transfer submodule is further configured to adopt a communication protocol to receive the port of the container management submodule transmitted by the master agent submodule of the first device, to receive the standard input of the container transmitted by the master agent submodule of the first device via the port of the container management submodule, to transmit the standard input of the container to the container operation submodule, and to transmit the standard output and standard error of the container to the container management submodule via the port of the container management submodule, if the console type parameter is used to indicate that standard input, standard error and standard output are linked to a specified console.
[0117] The container operations submodule is further configured to input the container's standard input into the container, receive the container's standard output and standard error, and send the container's standard output and standard error to the input / output transfer submodule.
[0118] In some exemplary embodiments, the container management submodule is further configured to send console type parameters to the master agent submodule when the console type parameters are used to indicate that standard input, standard error, and standard output are linked to a specified file. The master agent submodule is further configured to employ a communication protocol to include the filename of the specified file in the container creation request or process creation request and send it to the I / O transfer submodule of the second device.
[0119] The input / output transfer submodule is further configured to employ a communication protocol to receive the filename of the specified file sent by the first device, when the console type parameter is used to indicate that standard input, standard error, and standard output are linked to a specified file, to create the specified file using the received filename as the filename, and to send the filename of the specified file to the container operations submodule. The container operations submodule is further configured to write the container's standard input and standard error to the specified file.
[0120] The container engine provided by the embodiments of this disclosure is implemented by dividing the container engine into a first device and a second device, with the first device located at the management node and the second device located at either the management node or a worker node. Without changing the method of docking the container engine orchestration system to the container engine, the container engine core module is held in the first device, while the container spacer module and container runtime module are held in the second device. Because the resource consumption of the container spacer module and container runtime module is small and the resource consumption of the container engine core module is large, the embodiments of this disclosure save on worker node resource consumption while docking the container engine using the original container engine orchestration system.
[0121] In some exemplary embodiments, the master agent submodule is further configured to employ a communication protocol to send a container spacer module creation request to a communication submodule of a second device, and to employ a communication protocol to receive a container spacer module creation response sent by the communication submodule of the second device.
[0122] The slave agent module 2021 further includes a communication submodule configured to receive a container spacer module creation request sent by the first device, create a container spacer module, and send a container spacer module creation response to the first device, also using the communication protocol.
[0123] Those skilled in the art will understand that all or some of the functional modules / units among the steps, systems, and apparatus disclosed above may be performed as software, firmware, hardware, or appropriate combinations thereof. In hardware embodiments, the distinctions between functional modules / units mentioned above do not necessarily correspond to distinctions between physical components. For example, one physical component may have multiple functions, and one function or step may be performed by the cooperation of several physical components. Some or all physical components may be performed as software executed by a processor such as a central processing unit, digital signal processor, or microprocessor, as hardware, or as an integrated circuit such as an application-specific integrated circuit. Such software may be distributed on computer-readable media, which may include computer storage media (or non-temporary media) and communication media (or temporary media). As is well known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media executed by any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic memory, or any other media that can be used to store desired information and can be accessed by a computer. Furthermore, it is known to those skilled in the art that communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other carrier mechanisms, and may include any information distribution media.
[0124] While examples of embodiments and specific terminology have already been disclosed in this specification, they are used and should be interpreted as general descriptive only and are not intended to be limiting. In some examples, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in combination with certain embodiments may be used alone or in combination with features, characteristics, and / or elements described in other embodiments, unless otherwise explicitly noted. Accordingly, those skilled in the art will understand that various forms and details may be modified, as long as they do not deviate from the scope of this disclosure as revealed by the appended claims.
Claims
1. A method for realizing a container engine that is applicable to a first device installed in a management node and is executable by electronic equipment, The steps include: adopting a communication protocol to send a container operation request to a second device, A method for realizing a container engine, comprising the step of receiving a container operation response transmitted by the second device using the aforementioned communication protocol, wherein the method is A step of receiving a console type parameter that indicates the link type of standard input, standard error, and standard output, The steps include: using the aforementioned communication protocol, including the console type parameter in a container creation request or process creation request and sending it to the second device; A method for realizing a container engine, which further includes the following.
2. Prior to the step of sending a container operation request to a second device using a communication protocol, The steps include: sending a node status inquiry request to the second device using the aforementioned communication protocol, and receiving a node status inquiry response containing node status information sent by the second device using the aforementioned communication protocol; The steps include: using the aforementioned communication protocol to send a first node resource request to the second device, and using the aforementioned communication protocol to receive a first node resource request response sent by the second device; The steps include: using the aforementioned communication protocol to send a second node resource request to the second device, and using the aforementioned communication protocol to receive a second node resource request response sent by the second device; A method for realizing a container engine according to claim 1, comprising at least one of the following steps: sending a container image operation request to the second device using the communication protocol; and receiving a container image operation response sent by the second device using the communication protocol.
3. If the console type parameter is used to indicate that the standard input, standard error, and standard output are linked to the specified console, The steps include: using the aforementioned communication protocol, including the port of the first device in the container creation request or process creation request and sending it to the second device; The steps include: employing the aforementioned communication protocol and transmitting the standard input of the container to the second device via the port of the first device; A method for realizing a container engine according to claim 1, further comprising the steps of listening on a port of the first device by employing the communication protocol to receive the standard output and standard error of a container transmitted by the second device, and outputting the standard output and standard error of the container to the designated console.
4. If the console type parameter is used to indicate that the standard input, standard error, and standard output are linked to a specified file, A method for realizing a container engine according to claim 1, further comprising the step of using the aforementioned communication protocol to include the filename of the specified file in the container creation request or process creation request and send it to the second device.
5. Prior to the step of sending a container operation request to a second device using a communication protocol, The steps include: sending a link establishment request to the second device by adopting the communication protocol based on the address and port of the second device that have been preconfigured; and receiving a link establishment response sent by the second device by adopting the communication protocol. A method for realizing a container engine according to any one of claims 1 to 4, further comprising the steps of: sending a registration command to the second device using the communication protocol; and receiving a registration response sent by the second device using the communication protocol.
6. Before the step of sending the first node resource request to the second device, A method for realizing a container engine according to any one of claims 1 to 4, further comprising the steps of: using the communication protocol to send a container spacer module creation request to the second device; and using the communication protocol to receive a container spacer module creation response sent by the second device.
7. The method for realizing a container engine according to claim 6, wherein the container spacer module creation response includes ports of the container spacer module.
8. A method for implementing a container engine according to any one of claims 1 to 4, wherein the communication protocol includes one of the following: Remote Procedure Call Protocol (RPC), sockets, or Inter-Process Communication (IPC).
9. A method for realizing a container engine that is applicable to a second device installed on a management node or worker node and is executable by electronic equipment, The process involves adopting a communication protocol to receive a container operation request transmitted by the first device and performing a container operation. A method for realizing a container engine, comprising the step of employing the aforementioned communication protocol and transmitting a container operation response to the first device, wherein the method is A method for implementing a container engine, further comprising the step of receiving a console type parameter transmitted by the first device, which indicates the link type of standard input, standard error, and standard output, by employing a communication protocol.
10. Before the step of receiving a container operation request transmitted by the first device using a communication protocol, The steps include: receiving a node status inquiry request transmitted by the first device using the aforementioned communication protocol, querying node status information, and transmitting a node status inquiry response containing the node status information to the first device using the aforementioned communication protocol; The steps include: receiving a first node resource request transmitted by the first device using the aforementioned communication protocol, allocating a first node resource for the first device, and transmitting a first node resource request response to the first device using the aforementioned communication protocol; The steps include: receiving a second node resource request sent by the first device using the aforementioned communication protocol, allocating a second node resource for the first device, and sending a second node resource request response to the first device using the aforementioned communication protocol, or A method for realizing a container engine according to claim 9, further comprising at least one of the following steps: receiving a container image operation request transmitted by the first device using the communication protocol, performing a container image operation, and transmitting a container image operation response to the first device using the communication protocol.
11. If the console type parameter is used to indicate that the standard input, standard error, and standard output are linked to the specified console, The steps include: adopting the aforementioned communication protocol and receiving the port of the first device transmitted by the first device; The steps include: adopting the aforementioned communication protocol, receiving the standard input of a container transmitted by the first device via a port of the first device, and inputting the standard input of the container into the container; A method for realizing a container engine according to claim 9, further comprising the steps of receiving the standard output and standard error of a container, and transmitting the standard output and standard error of the container to the first device via a port of the first device using the communication protocol.
12. If the console type parameter is used to indicate that the standard input, standard error, and standard output are linked to a specified file, The steps include: adopting the aforementioned communication protocol and receiving the filename of the specified file transmitted by the first device; A method for implementing a container engine according to claim 9, further comprising the steps of creating the specified file with the filename of the received specified file as the filename, and writing the container's standard input and standard error to the specified file.
13. Before the step of receiving a container operation request transmitted by the first device using a communication protocol, The steps include: adopting the communication protocol to listen on the pre-configured address and port of the second device in order to receive a link establishment request transmitted by the first device, and adopting the communication protocol to send a link establishment response to the first device; A method for realizing a container engine according to any one of claims 9 to 12, further comprising the steps of receiving a registration command transmitted by the first device using the communication protocol, executing the registration command, and transmitting a registration response to the first device using the communication protocol.
14. Prior to the step of receiving the first node resource request transmitted by the first device, A method for realizing a container engine according to any one of claims 9 to 12, further comprising the steps of receiving a container spacer module creation request transmitted by the first device using the communication protocol, creating a container spacer module, and transmitting a container spacer module creation response to the first device using the communication protocol.
15. The method for realizing a container engine according to claim 14, wherein the container spacer module creation response includes ports of the container spacer module.
16. A method for implementing a container engine according to any one of claims 9 to 12, wherein the communication protocol includes one of the following: Remote Procedure Call Protocol (RPC), sockets, or Inter-Process Communication (IPC).
17. A container engine device comprising a first module installed on a management node and a second module installed on a management node or a worker node, The first module is, A container management submodule is configured to send container operation requests to the master agent submodule, A master agent submodule is configured to use a communication protocol to send container operation requests to the container operation submodule of the second module, and to use the same communication protocol to receive container operation responses sent by the container operation submodule of the second module. Equipped with a container engine core module having, The second module described above is A container spacer module including a container operation submodule that employs the aforementioned communication protocol to receive a container operation request transmitted by the master agent submodule of the first module and transmit the container operation request to the container runtime module, A container runtime module is configured to perform container operations and send container operation responses to the container operation submodule, Equipped with, The container operation submodule is further configured to employ the communication protocol and transmit container operation responses to the master agent submodule of the first module, and is further configured as a container engine device.
18. The container engine device according to claim 17, wherein a link is provided between the first module and the second module using one of the following technologies: bus technology, wired network technology, or wireless network technology.
Citation Information
Patent Citations
A physical security system with multiple server nodes
JP2015535970A
Information processing system, information processing method, and program
JP2019128617A