Container engine of computing node and container arrangement method

Abstract

The embodiment of the invention provides a container engine of a computing node and a container arrangement method, and the container engine is realized based on C language operation, and comprises a CRI interface which is used for providing a CR I standard interface for the container engine to an external container management node; the mirror image management unit is used for carrying out mirror image management on each container on the computing node based on an OC I mirror image standard; during container operation, the container operation module is used for providing container operation time based on an OCI mirror image standard for each container; when the ubiquitous system runs, the system is used for providing running environments with mutually isolated resources for the containers through the ubiquitous system, and when the containers run according to the running environments, the ubiquitous system comprises a thread-based operating system, a process-based operating system, a partition operating system and a virtual machine operating system. According to the technical scheme, the container engine is achieved through the C language, standard container arrangement is supported, and various embedded real-time container scenes such as tasks, processes, partitions and virtual machines are supported.

Description

Technical Field

[0001] The present application relates to the field of operating system technology, and in particular to a container engine and a container orchestration method for a computing node. Background Art

[0002] Container technology is a lightweight virtualization technology that provides a lightweight isolated environment for software development, deployment, and operation. The application of container technology makes the development, testing, and deployment environments highly consistent. Application software can package its related dependencies and software configurations into container images. Even if multiple different versions of application software are deployed and run at the same time, there will be no package dependency conflicts.

[0003] Container technology for real-time systems has gradually attracted attention, but the container engines supported by most real-time systems are customized and do not comply with the CRI standard protocol. The current mainstream container engines such as docker, containerd, and cri-o are all written in GO language.

[0004] With the continuous rise of embedded device scenarios such as edge computing and the Internet of Things, the demand for business containerization is becoming increasingly urgent in resource-constrained environments. Container engines written in high-level languages ​​cannot be used in resource-constrained embedded systems, and real-time systems are of various types, including multi-tasking systems, time-sharing and partitioning systems, and multi-process systems. Therefore, a container engine is needed to support multiple operating scenarios such as tasks, processes, partitions, and virtual machines. Due to the standardization of the external interface of the container engine, it can be connected to the cloud platform for unified collaborative scheduling. Summary of the invention

[0005] In view of this, an embodiment of the present application provides a container engine and a container orchestration method for a computing node. The container engine implements the container engine through C language, so that it no longer needs to rely on customized fuzzy tools and workflows. The entire process and method are exactly the same as Linux. It not only supports the CRI standard interface of the cloud platform's container management system, realizes image management and container runtime based on the OCI image standard, but also can run in tasks, processes, partitions, virtual machines and other embedded running scenarios to realize real-time container orchestration.

[0006] In a first aspect, an embodiment of the present application provides a container engine for a computing node, which is implemented based on a C language runtime and includes: a CRI interface, which is used to provide a CRI standard interface for the container engine to an external container management node, and each container includes a real-time container; an image management unit, which is used to perform image management on each container on the computing node based on the OCI image standard; a container runtime, which is used to provide a container runtime based on the OCI image standard for each container and manage each container; a ubiquitous system runtime, which is used to provide an operating environment with resources isolated from each other for each container through the ubiquitous system, and implement the container runtime accordingly, and the ubiquitous system includes a thread-based operating system, a process-based operating system, a partition operating system, and a virtual machine operating system.

[0007] As mentioned above, the container engine is implemented through C language, so that it no longer needs to rely on customized fuzzy tools and workflows. The whole process and method are exactly the same as Linux. It not only supports the CRI standard interface of the cloud platform's container management system, realizes image management and container runtime based on the OCI image standard, but also can run in tasks, processes, partitions, virtual machines and other embedded scenarios to realize real-time container orchestration.

[0008] In a possible implementation manner of the first aspect, the CRI interface is connected to the container management node through a TSN network.

[0009] As shown above, the TSN network is a time-deterministic network that supports mixed transmission of strong real-time, soft real-time and non-real-time data, ensuring the determinism of time-critical tasks; the CRI interface connects the container management node through the TSN network, improving the determinism of communication between the two and further improving the real-time performance of the container engine.

[0010] In a possible implementation of the first aspect, the container engine is based on domain-driven hierarchical design.

[0011] As mentioned above, the container engine is based on domain-driven layered design, which decomposes the container engine business from interfaces, businesses, components, and infrastructure. Each layer is implemented deterministically in C language, so that the container engine no longer needs to rely on customized fuzzy tools and workflows, and each layer has time determinism.

[0012] In a possible implementation manner of the first aspect, the container engine further includes: an interface adaptation unit, configured to implement information interaction between the container management node and the container engine based on a CRI standard interface based on a gPRC framework.

[0013] As mentioned above, the interface adapter unit provides the definition of the CRI standard interface, implements the CRI standard interface request between the container management node and the container engine based on the gPRC framework, and realizes the information interaction between the two.

[0014] In a possible implementation of the first aspect, the container engine also includes: a CLI interface, used to provide an external CLI standard interface for the container engine; the interface adaptation unit is also used to implement information interaction between the outside and the container engine based on the CLI standard interface based on the REST architecture.

[0015] As mentioned above, the client performs command-line-based container image management and container management through the CLI interface. The interface adaptation unit also provides the definition of the CLI standard interface, and implements the CLI standard interface requests between the client and the container engine based on the REST framework processing to achieve information interaction between the two.

[0016] In a possible implementation manner of the first aspect, the container management node is a Master node of Kubernetes.

[0017] From the above, the container engine can work in the Kubernetes cluster and perform container orchestration through the Kubernetes Master node.

[0018] In a possible implementation of the first aspect, the layering based on domain-driven design includes: an infrastructure layer, which provides various tool functions based on the ubiquitous system as other layers; a domain logic layer, including various domain components of the container engine, each component executes the logical function of the container engine in the business domain, and the business at least includes the image management and the business corresponding to the container runtime; a business application layer, which is used to call the interface of the domain logic layer to implement the business, and each business is implemented by several of the domain components; a user interface layer, which is used to provide the container management node with the CRI standard interface of the container engine to the outside world.

[0019] As mentioned above, the container engine business is decomposed from interfaces, businesses, components, and infrastructure through the above layered structure, and the certainty and security between the various layers of the container engine are realized based on the C language. It is no longer necessary to rely on customized fuzzy tools and workflows to meet the real-time requirements of the container engine.

[0020] In a possible implementation of the first aspect, the infrastructure layer includes a function for implementing a TSN protocol stack.

[0021] From the above, the infrastructure layer includes functions for implementing the TSN protocol stack, which can realize the communication between the container engine and the container management node from a domain-driven perspective and improve the real-time performance of the system.

[0022] In a possible implementation manner of the first aspect, the layering further includes: a user interface layer, which is used for the container engine to provide an external CLI standard interface.

[0023] From the above, through the user interface layer, the external client uses the command line to interact with the real-time container based on the REST protocol to achieve container image management and container business management.

[0024] In a second aspect, an embodiment of the present application provides a container orchestration method for a computing node, implementing container orchestration through the container engine described in any implementation mode of the first aspect, including: receiving a container orchestration instruction based on a CRI standard interface from the outside through the CRI interface of the container engine; when the instruction is an image management instruction, performing image management on the corresponding container on the computing node based on the OCI image standard through the image management unit of the container engine; when the instruction is a container management instruction, managing the corresponding container on the computing node through the container runtime of the container engine using the ubiquitous system runtime of the container engine.

[0025] As mentioned above, container orchestration is performed through the container engine implemented in C language, so that it no longer needs to rely on customized fuzzy tools and workflows. It not only supports the CRI standard interface to implement image management and container runtime based on the OCI image standard, but also can run in tasks, processes, partitions, virtual machines and other embedded scenarios to realize real-time container orchestration.

[0026] In a possible implementation manner of the second aspect, the CRI interface interacts with the container management node through a TSN network.

[0027] As mentioned above, the TSN network is a time-deterministic network that supports mixed transmission of strong real-time, soft real-time and non-real-time data, ensuring the determinism of time-critical tasks; the CRI interface interacts with the container management node through the TSN network, improving the determinism of communication between the two and further improving the real-time performance of the container engine.

[0028] In a possible implementation of the second aspect, the container engine implements container image management and container runtime business in layers from a domain-driven perspective, and the layers include: an infrastructure layer, which provides various tool functions based on the ubiquitous system as other layers; a domain logic layer, which includes various domain components of the container engine, each component executes the logical function of the container engine in the business domain, and the business includes at least the image management and the business corresponding to the container runtime; a business application layer, which is used to call the interface of the domain logic layer to implement the business, and each business is implemented by several of the domain components; a user interface layer, which is used to provide the container management node with the CRI standard interface of the container engine to the outside world.

[0029] As mentioned above, the container engine is based on domain-driven layered design, which decomposes the container engine business from interfaces, businesses, components, and infrastructure. Each layer is implemented deterministically in C language, so that the container engine no longer needs to rely on customized fuzzy tools and workflows, and each layer has time determinism.

[0030] In a possible implementation of the second aspect, the container engine further includes: an interface adaptation unit; and information interaction based on a CRI standard interface is implemented between the container engine and the container management node through the interface adaptation unit based on a gPRC framework.

[0031] As mentioned above, the interface adapter unit provides the definition of the CRI standard interface, implements the CRI standard interface request between the container management node and the container engine based on the gPRC framework, and realizes the information interaction between the two.

[0032] In a possible implementation of the second aspect, the container engine also includes: a CLI interface; the container engine also communicates with the client through the CLI interface to receive container orchestration instructions based on the CLI standard interface; the container engine also implements information interaction between the outside and the container engine based on the CLI standard interface based on the REST architecture through the interface adaptation unit.

[0033] As mentioned above, the client performs command-line-based container image management and container management through the CLI interface. The interface adaptation unit also provides the definition of the CLI standard interface, and implements the CLI standard interface requests between the client and the container engine based on the REST framework processing to achieve information interaction between the two.

[0034] In a possible implementation of the second aspect, the container management node is a Master node of Kubernetes.

[0035] From the above, the container engine can work in the Kubernetes cluster and perform container orchestration through the Kubernetes Master node.

[0036] In a third aspect, an embodiment of the present application provides a computing device, including:

[0037] bus;

[0038] A communication interface connected to the bus;

[0039] at least one processor connected to the bus; and

[0040] At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes any implementation method of the first aspect of the present application.

[0041] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer executes any implementation method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a structural diagram of a container engine embodiment 1 of a computing node of the present application;

[0043] Figure 2 This is a structural diagram of a second embodiment of a container engine for a computing node of the present application;

[0044] Figure 3 This is a structural diagram of a container engine based on a gRPC framework in a container engine of a computing node embodiment 2 of the present application;

[0045] Figure 4 A schematic diagram of the location of a container engine in a Kubernetes cluster according to Embodiment 2 of a container engine for a computing node of the present application;

[0046] Figure 5 A schematic diagram of a domain-driven hierarchical structure of a container engine embodiment 2 of a computing node of the present application;

[0047] Figure 6 A schematic diagram of the software and hardware architecture of the TSN protocol of the container engine of the second embodiment of the container engine of a computing node of the present application;

[0048] Figure 7 A schematic diagram of a flow chart of an embodiment of a container orchestration method for a computing node of the present application;

[0049] Figure 8 A schematic diagram of the process of creating a container in a container orchestration method for a computing node of the present application;

[0050] Fig. 9 A schematic diagram of the structure of a computing device according to various embodiments of the present application. DETAILED DESCRIPTION

[0051] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0052] In the following description, the terms "first\second\third, etc." or module A, module B, module C, etc. are only used to distinguish similar objects, or to distinguish different embodiments, and do not represent a specific ordering of the objects. It can be understood that the specific order or sequence can be interchanged where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0053] In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.

[0054] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0055] The embodiment of the present application provides a container engine and a container orchestration method for a computing node, wherein the container engine is implemented based on a C language runtime, and includes: a CRI interface, which is used to provide a CRI standard interface for the container engine to an external container management node; an image management unit, which is used to perform image management on each container on the computing node based on the OCI image standard, wherein each container includes a real-time container; a container runtime, which is used to provide each container with a container runtime based on the OCI image standard; a ubiquitous system runtime, which is used to provide each container with an operating environment in which resources are isolated from each other through the ubiquitous system, and thereby implement the container runtime, wherein the ubiquitous system includes a thread-based operating system, a process-based operating system, a partition operating system, and a virtual machine operating system.

[0056] The technical solution of the embodiment of the present application implements the container engine through C language, which no longer needs to rely on customized fuzzy tools and workflows. The entire process and method are exactly the same as Linux. It not only supports the CRI standard interface of the cloud platform's container management system, realizes image management and container runtime based on the OCI image standard, but also can run in tasks, processes, partitions, virtual machines and other embedded scenarios to realize real-time container orchestration.

[0057] The following describes various embodiments of the present application in conjunction with the accompanying drawings. Figure 1 The present application introduces a first embodiment of a container engine for a computing node.

[0058] Figure 1 The structure of a first embodiment of a container engine for a computing node is shown, including: a CRI interface 110, an image management unit 120, a container runtime 130 and a ubiquitous system runtime 140.

[0059] The container engine of this embodiment is implemented in C language, and the container engine runs in the C language runtime. C language consumes little system consumption and can better support real-time scheduling, completely avoiding the problems of high-level languages ​​such as GO language and poor real-time performance, and improving the real-time performance of the container engine. With the help of open standards, known workflows, existing tools and infrastructure, real-time, secure, and certifiable RTOS software can be developed to deploy, run, manage, and update real-time containers, thereby reducing costs and risks, making its entire process and method exactly the same as Linux.

[0060] The CRI interface 110 is used to provide a CRI standard interface for the container engine to an external container management node, thereby achieving compatibility with the external container management node.

[0061] In some embodiments, the container management node is a Master node of Kubernetes.

[0062] Among them, the CRI standard interface (Container Runtime Interface) is a standard container CRI interface based on gRPC. The container engine defined by Kubernetes needs to provide an interface for container and image services to Kubernetes for access by the container engine.

[0063] In some embodiments, the container engine also includes a CLI interface, which is used for the container engine to provide an external CLI standard interface (command line interface), that is, the client manages container images and containers through the command line interface.

[0064] In some embodiments, the CRI interface 110 is connected to the container management node through the TSN network, which improves the determinism between the CRI interface 110 and the container management node, thereby improving the real-time performance of the container engine.

[0065] The image management unit 120 is used to manage the images of the containers on the computing nodes based on the OCI image standard.

[0066] Among them, each container includes a real-time container. OCI (Open Container Initiative) is an open source standard organization that promotes the interoperability and compatibility of container technology by defining container images and runtime specifications.

[0067] Among them, the image management unit 120 can connect to the instructions of the CRI standard interface received through the CRI interface 110, and perform image management (Image Service) based on the OCI image standard according to the instructions, including transmitting and managing container images, decompressing container images, and passing them to the container runtime to run the container, and performing determined management based on the C language runtime, with good determinism.

[0068] The container runtime 130 is used to provide a container runtime (RuntimeService) based on the OCI image standard for each container, and manage each container, including container management throughout the entire life cycle, including container creation, container operation, container suspension, container monitoring, and container deletion. The container management is determined based on the C language runtime and has good determinism.

[0069] The ubiquitous system runtime 140 is a real-time runtime, which is used to provide a real-time operating environment with isolated resources for each container through the ubiquitous system, and implement the container runtime 130 accordingly, so that the container runtime 130 no longer depends on the basic environment of the ubiquitous system, making the container runtime 130 a lightweight runtime.

[0070] The ubiquitous system includes: a thread-based operating system, a process-based operating system, a partition operating system, and a virtual machine operating system. The ubiquitous system runtime 140 includes: a thread runtime, a process runtime, a partition runtime, and a virtual machine runtime, which correspond to the thread-based operating system, the process-based operating system, the partition operating system, and the virtual machine operating system, respectively, so that the real-time container can run in a variety of embedded scenarios such as tasks, processes, partitions, and virtual machines, and realize the orchestration of real-time containers.

[0071] Among them, thread-based operating systems do not support processes, and resources are directly isolated in threads; process-based operating systems support processes, and resources are isolated in processes, and multiple thread programs can be run in processes; partition operating systems allocate independent hardware resources to each partition; virtual machine operating systems allocate hardware resources to each virtual machine through hardware virtualization, and some virtual machines obtain independent resources through time partitioning. The ubiquitous system runtime 140 cannot be implemented in high-level languages ​​such as GO language, but is implemented through C language by calling the kernel / microkernel of the operating system, isolating independent resources for real-time containers to achieve its real-time performance.

[0072] In some embodiments, the container engine further includes an interface adapter unit for implementing information interaction of a CRI standard interface between a container management node and a container engine based on a gPRC framework, wherein the interface adapter unit is a client based on a gPRC framework, and the image management unit 120 and the container runtime 130 are servers based on a gPRC framework.

[0073] In some embodiments, when the container engine further includes a CLI interface, the interface adapter unit is further used to implement information interaction of the CLI standard interface between the external and the container engine based on the REST architecture. The interface adapter unit is a client based on the REST framework, and the image management unit 120 and the container runtime 130 are servers based on the REST framework.

[0074] In some embodiments, the container engine is based on a domain-driven layered design, which decomposes the container engine business from interfaces, businesses, components, and infrastructure. Each layer is implemented deterministically in C language, so that the container engine no longer needs to rely on customized fuzzy tools and workflows.

[0075] In some embodiments, from a domain perspective, the layering of the container engine includes: an infrastructure layer, which provides various ubiquitous system-based tool functions as other layers and serves as a support library for other layers; a domain logic layer, which includes various domain components of the container engine and is the core of the container engine software. Each component executes the logical function of the container engine in the business domain, decomposes the components, and implements them through the infrastructure layer. The business here at least includes the business corresponding to the image management unit 120 and the container runtime 130; a business application layer, which is used to call the interface of the domain logic layer to implement the business of the container engine, and each business is implemented through several domain components; a user interface layer, which is used to provide the container management node with the CRI standard interface of the container engine to the outside world, and supports the interface of two services during image management and period runtime. Through the above-mentioned hierarchical structure, the container engine business is decomposed from the interface, business, component, and infrastructure, and combined with the C language implementation, the container engine has certainty and security between the layers, and no longer needs to rely on customized fuzzy tools and workflows.

[0076] In some embodiments, the infrastructure layer includes functions for implementing the TSN protocol stack, thereby achieving certain communication between the container engine and the container management node from a domain-driven perspective and improving the real-time performance of the system.

[0077] In some embodiments, the domain-driven layering also includes: a user interface layer, which is used for the container engine to provide an external CLI standard interface, so that the outside can interact with the real-time container through the command line based on the REST protocol.

[0078] In summary, a container engine implementation example 1 of a computing node implements the container engine through C language. The container engine runs in the C language runtime, so that it no longer needs to rely on customized fuzzy tools and workflows. The entire process and method are exactly the same as Linux. It not only supports the CRI standard interface of the cloud platform's container management system, realizes image management and container runtime based on the OCI image standard, but also can run in tasks, processes, partitions, virtual machines and other embedded running scenarios to realize real-time container orchestration.

[0079] Combine the following Figures 2 to 6 A second embodiment of a container engine for a computing node is introduced.

[0080] A second embodiment of a container engine for a computing node inherits all structures of the first embodiment of a container engine for a computing node, is a detailed implementation method of the first embodiment of a container engine for a computing node, and has all the advantages of the first embodiment of a container engine for a computing node.

[0081] Figure 2 The structure of a second embodiment of a container engine for a computing node is shown. Compared with the first embodiment of a container engine for a computing node, a CLI interface 115 and an interface adapter unit 118 are added, and other modules are exactly the same as those of the first embodiment of a container engine for a computing node, which will not be described in detail here.

[0082] The CLI interface 115 is used for the container engine to provide an external CLI standard interface, so that the client can manage container images and containers through the command line standard interface.

[0083] The interface adapter unit 118 is used to implement information interaction between the container management node and the container engine based on the CRI standard interface based on the gPRC framework. Among them, the interface adapter unit is a client based on the gPRC framework, and the container engine (essentially the image management unit 120 and the container runtime 130) is a server based on the gPRC framework.

[0084] Figure 3 The structure based on the gRPC framework in the container engine of this embodiment is shown. The interface adapter unit 118 in the container engine is similar to the kubelet of Kubernetes. The container engine (essentially the image management unit 120 and the container runtime 130) is a server based on the gRPC framework, providing image management (image service) and container runtime (runtime service).

[0085] The interface adapter unit 118 is also used to implement information interaction between the external and the container engine based on the CLI standard interface based on the REST architecture. Among them, the interface adapter unit is a client based on the REST framework, and the container engine (essentially the image management unit 120 and the container runtime 130) is a server based on the REST framework.

[0086] The container management node in this embodiment is a Kubernetes management node. Figure 4The figure shows the location of the container engine of this embodiment in the Kubernetes cluster. The container engine communicates with Kubernetes (abbreviated as k8s in the figure) based on the CRI standard interface and is parallel to other node components of Kubernetes to realize the orchestration of real-time containers in the Kubernetes cluster.

[0087] The container engine of this embodiment is based on domain-driven layered design, which decomposes the container engine business from interfaces, businesses, components, and infrastructure. Each layer is implemented deterministically in C language, so that the container engine no longer needs to rely on customized fuzzy tools and workflows.

[0088] Figure 5 The domain-driven layering of this embodiment is shown, including: an infrastructure layer 510 , a domain logic layer 520 , a business application layer 530 , a user interface layer 540 , and a user interface layer 550 .

[0089] The infrastructure layer 510 provides various tool functions as other layers and serves as a support library for other layers, including: functions based on the ubiquitous system, such as basic hardware management functions such as memory management functions, to achieve hardware isolation; basic function functions, such as compression algorithms, encryption algorithms (SHA256 algorithms) and TSN protocol stack functions, to abstract the functions of the ubiquitous system, and the external interface is independent of the type of ubiquitous system. In some embodiments, the tool functions provided by the infrastructure layer 510 implement the ubiquitous runtime.

[0090] The domain logic layer 520 includes various domain components of the container engine and is the core of the container engine software. Each component executes the logical function of the container engine in the business domain and includes at least one of the following components: image management, container module, event module, service module, plug-in management, log module and container runtime module.

[0091] The business application layer 530 is used to call the interface of the domain logic layer to implement the business of the container engine. Each business is implemented through several domain components, including a container business module and a mirror business module.

[0092] The user interface layer 540 is used to provide the definition of the CLI standard interface and the CRI standard interface to process the CLI standard interface request of the user interface layer 550 and the CRI standard interface request of the management node of Kubernetes.

[0093] The user interface layer 550 is used for the container engine to provide an external CLI standard interface, so that the outside can interact with the real-time container through the command line based on the REST protocol.

[0094] In order to meet the determinism of container scheduling and control, this embodiment uses the TSN network to connect with the management node of Kubernetes. The TSN network is a time-deterministic network and a key infrastructure for information communication in deterministic control. It supports the mixed transmission of strong real-time, soft real-time and non-real-time data to ensure the determinism of time-critical tasks. TSN defines the deterministic communication service capabilities in the TSN network, enabling the network to transmit data at a beat synchronized with the business, and provide bounded business assurance capabilities, including transmission delay, jitter, packet loss rate, reliability and other indicators, thereby providing deterministic service guarantees for industrial production.

[0095] Figure 6 The software and hardware architecture of the TSN protocol of the container engine of this embodiment is shown.

[0096] Among them, the hardware part includes message timestamp processing, clock system, IEEE 802.1Qbu, IEEE 802.1Qbv and hardware B code synchronization processing module, as well as CPU chips and TSN network card chips with enhanced I / O, which can provide reliable support for various software functions.

[0097] Among them, the software part includes subsystems such as cloud-native operation and maintenance management, software platform acceleration, TSN protocol stack functions, synchronous signal transmission processing, and TSN network management.

[0098] The TSN protocol stack functions of the infrastructure layer 510 provide the following functional support:

[0099] Network topology discovery, used to discover and exchange system and configuration information among networks;

[0100] IEEE 802.1AS / IEEE 1588 protocol stack synchronization, including: PTP protocol encapsulation, PTP protocol parsing, system clock and B code synchronization functions;

[0101] IEEE 802.1Qbv protocol gating shaping: including hardware-based GCL and IEEE 802.1Qbv protocol stack;

[0102] IEEE 802.1Qbu provides a priority-based frame preemption mechanism.

[0103] In summary, a second embodiment of a container engine for a computing node combines TSN deterministic networks, real-time systems and container technology to provide an efficient, reliable and flexible operating environment for real-time applications. Through container orchestration and management, resource scheduling and isolation, real-time monitoring and fault recovery, etc., it is possible to realize the automated deployment, management and expansion of real-time applications, and improve the performance and reliability of real-time systems. The container engine is designed based on domain-driven C language, providing a true embedded container engine on a ubiquitous system, so that it no longer needs to rely on customized fuzzy tools and workflows, thereby reducing costs and risks, making its entire process and method exactly the same as Linux.

[0104] Combine the following Figure 7 and Figure 8 An embodiment of a container orchestration method for computing nodes is introduced.

[0105] An embodiment of a container orchestration method for a computing node runs on a container engine described in Embodiment 1 of a computing node or Embodiment 2 of a container engine for a computing node to implement real-time orchestration of real-time containers.

[0106] Figure 7 The flowchart of an embodiment of a method for orchestrating containers of a computing node is shown, including steps S710 to S730.

[0107] S710: The CRI interface of the container engine receives a container orchestration instruction based on the CRI standard interface from the outside.

[0108] Among them, container orchestration instructions based on the CRI standard interface are received from the Kubernetes management node through the TSN network.

[0109] S720: When the container orchestration instruction is an image management instruction, the image management unit of the container engine performs image management on the corresponding container on the computing node based on the OCI image standard.

[0110] S730: When the container orchestration instruction is a container management instruction, the container runtime of the container engine utilizes the ubiquitous system runtime of the container engine to manage the corresponding container on the computing node.

[0111] Among them, the ubiquitous system runtime provides isolation resources for each container on the computing node, and the container runtime realizes the management of real-time containers.

[0112] The following describes the real-time container creation process of this embodiment. Figure 8 The flowchart of a container creation process in a container orchestration method for a computing node is shown, including steps S810 to S860.

[0113] Real-time container creation runs in the container runtime through the container creation function KD_ContainerCreate, which is used to create a container. The function creates a container with a unique ID from the specified OCI image package. The OCI image package is a standard format that contains all the files required for the container to run, including but not limited to binary files, configuration files, and other file system elements.

[0114] S810: Check the parameters and process the relative path, and construct a JSON message created by the container.

[0115] This step includes the following steps:

[0116] (1) Check whether the parameter container ID and OCI image path are null pointers. If they are null pointers, the EINVAL error code is returned and the creation is stopped.

[0117] Among them, containerId: a pointer to a string, which represents the unique identifier of the newly created container, imagePath: a pointer to a string, which represents the location of the OCI image package stored on the disk, which contains all the files required for the container to run.

[0118] (2) Perform relative path processing on the imagePath path. If it is a relative path, construct a full path object.

[0119] (3) Use the parameter container ID and the processed OCI image path to construct a JSON message for creating a container, and send the message to the container management service thread (the container module in the domain logic layer 520).

[0120] S820: Enter the container management service and check the JSON message.

[0121] Among them, this step includes the following steps:

[0122] (1) After receiving the message, the container management service calls the container message processing kdContainerMessageProcess to process the message, enters the container creation logic processing flow according to the container creation CONTAINER_CREATE command type, and calls kdContainerCreate to actually create the container.

[0123] (2) Check whether the container name and container image path are valid, and check whether the container already exists. If the container name or container image path is invalid, or the container exists, an EEXIST error is returned.

[0124] S830: Allocate and set the container object structure.

[0125] Among them, when the container name and container image path are valid and the container does not exist, calloc is called to allocate the container object structure and the following settings are performed:

[0126] Set the container state to CONTAINER_STATE_CREATING;

[0127] Set the container image path of the container object structure;

[0128] Set the container image ID of the container object structure.

[0129] S840: Initialize the runtime of the created container according to the OCI image.

[0130] Among them, the OCI runtime specification defines the configuration file format required for container runtime, which contains all the information required to start the container, such as container execution parameters, environment variables, mount points, network configuration, user and permission settings, etc.

[0131] The resources that the runtime depends on are provided by the corresponding ubiquitous system runtime 140 .

[0132] S850: Set the container status to the creation completion status and mount the root file system.

[0133] Among them, this step includes the following steps:

[0134] (1) Set the container state to CONTAINER_STATE_CREATED to indicate that the container has been created.

[0135] (2) Call kdContainerMount to mount the root file system of the container.

[0136] Among them, according to the container's config.json configuration file, the root file system and other mount points will be mounted to the container's root directory

[0137] S860: Record the newly created container into the management container list to facilitate subsequent starting, stopping, and deleting.

[0138] Among them, kdContainerAdd is called to record the newly created container into the management container list.

[0139] The present application embodiment also provides a computing device, Fig. 9 Detailed introduction.

[0140] The computing device 900 includes a processor 910 , a memory 920 , a communication interface 930 , and a bus 940 .

[0141] It should be understood that the communication interface 930 in the computing device 900 shown in this figure can be used to communicate with other devices.

[0142] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit inside the processor 910, or an external storage unit independent of the processor 910, or a component including a storage unit inside the processor 910 and an external storage unit independent of the processor 910.

[0143] Optionally, the computing device 900 may further include a bus 940. The memory 920 and the communication interface 930 may be connected to the processor 910 via the bus 940. The bus 940 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 940 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the figure is represented by only one line, but it does not mean that there is only one bus or one type of bus.

[0144] It should be understood that in the embodiment of the present application, the processor 910 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 910 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

[0145] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a nonvolatile random access memory. For example, the processor 910 may also store information on the device type.

[0146] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform the operation steps of each method embodiment.

[0147] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subjects in the methods according to the embodiments of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0148] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0149] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0150] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0151] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0152] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0153] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0154] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute the operating steps of each method embodiment.

[0155] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above.More specific examples (non-exhaustive lists) of computer-readable storage media include, electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

[0156] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, which carry computer-readable program code. Such transmitted data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, transmit, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0157] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0158] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0159] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims

1. A container engine for a computing node, characterized in that: Based on C language runtime implementation, including: CRI interface, used to provide the container engine with a CRI standard interface to an external container management node; The image management unit is used to manage the images of each container on the computing node based on the OCI image standard; A container runtime is used to provide a container runtime based on the OCI image standard for each container and to manage each container; When the ubiquitous system is running, it is used to provide an operating environment with resources isolated from each other for each container through the ubiquitous system, and thereby implement the container runtime. The ubiquitous system includes a thread-based operating system, a process-based operating system, a partition operating system, and a virtual machine operating system.

2. The container engine according to claim 1, characterized in that: The CRI interface is connected to the container management node through the TSN network.

3. The container engine according to claim 1, characterized in that: Also includes: The interface adaptation unit is used to implement information interaction of the CRI standard interface between the container management node and the container engine based on the gPRC framework.

4. The container engine according to claim 3, characterized in that: Also includes: CLI interface, used to provide an external CLI standard interface for the container engine; The interface adaptation unit is also used to implement information interaction of the CLI standard interface between the outside and the container engine based on the REST architecture.

5. The container engine according to claim 1, characterized in that: The container management node is the Master node of Kubernetes.

6. The container engine according to claim 1, characterized in that: The container engine is based on a domain-driven layered design, and the layering includes: The infrastructure layer, as other layers, provides various tool functions based on the ubiquitous system; The domain logic layer includes domain components of the container engine, each of which performs the logical function of the container engine in the business domain, and the business at least includes the image management and the business corresponding to the container runtime; The business application layer is used to call the interface of the domain logic layer to implement the business. Each business is implemented by several domain components. The user interface layer is used to provide the container management node with the CRI standard interface of the container engine.

7. The container engine according to claim 6, characterized in that: The infrastructure layer includes functions for implementing the TSN protocol stack; and / or The layering also includes: a user interface layer, which is used for the container engine to provide an external CLI standard interface.

8. A container orchestration method for computing nodes, characterized in that: Implementing container orchestration by using the container engine described in any one of claims 1 to 7 includes: Receiving a container orchestration instruction based on a CRI standard interface from the outside through the CRI interface of the container engine; When the instruction is an image management instruction, the image management unit of the container engine performs image management on the corresponding container on the computing node based on the OCI image standard; When the instruction is a container management instruction, the container runtime of the container engine uses the ubiquitous system runtime of the container engine to manage the corresponding container on the computing node.

9. A computing device, characterized in that include, bus; A communication interface connected to the bus; at least one processor connected to the bus; as well as At least one memory is connected to the bus and stores program instructions, and when the program instructions are executed by the at least one processor, the at least one processor executes the method of claim 8.

10. A computer-readable storage medium, characterized in that: Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method of claim 8.

Images