CN113296821A - Apparatus and method for providing container service and hot upgrade method of the apparatus - Google Patents
Apparatus and method for providing container service and hot upgrade method of the apparatus Download PDFInfo
- Publication number
- CN113296821A CN113296821A CN202110137160.0A CN202110137160A CN113296821A CN 113296821 A CN113296821 A CN 113296821A CN 202110137160 A CN202110137160 A CN 202110137160A CN 113296821 A CN113296821 A CN 113296821A
- Authority
- CN
- China
- Prior art keywords
- module
- logic
- driving module
- driver
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
An apparatus and method for providing a container service and a hot upgrade method of the apparatus are disclosed. The container instance is maintained at the user mode module. The kernel mode module comprises an interface driving module and a logic driving module. The interface driver module is used for creating and maintaining the equipment node and connecting the equipment node to the corresponding container instance in the user mode module. The logic driving module is used for driving the physical equipment and executing logic control functions. And the logic driving module communicates with the corresponding container instance in the user mode module through the equipment node maintained by the interface driving module. The functional module needing hot upgrade is configured in the logic driving module. When the interface driver module is upgraded, the interface driver module does not upgrade the interface driver module, and the interface driver module executes the upgrading process of the logic driver module. Thus, a new container architecture is provided that enables client-unaware hot upgrade of container services.
Description
Technical Field
The present disclosure relates to a container service in the internet field, and more particularly, to an apparatus and method for providing a container service and a hot upgrade method for the apparatus.
Background
Container technology is a technology that packages software into standardized units for development, delivery, and deployment. The method ensures the consistency of the application running environment and can be started more quickly. The container technology has the characteristics of isolation, expandability, convenience in migration, sustainable delivery, deployment and the like. Based on the above characteristics, the container technology is widely applied in the field of cloud services.
Based on the container technology, for example, a light-weight GPU (Graphics Processing Unit) virtualization solution can be realized. Fig. 1 schematically illustrates one GPU container architecture that may be used in this scheme.
In the GPU container architecture, communication between the kernel mode module and the container and communication between the kernel mode module and the physical device are implemented based on a kernel mode device driver (or referred to as a "device driver" or a "device driver module").
As shown in FIG. 1, the user mode module creates and maintains multiple container instances, e.g., container 1, container 2, … …, container N. These container instances may be separately initialized based on the GPU container runtime.
The GPU container driver of the kernel mode module comprises a task scheduler, a resource allocator and a GPU device driver.
The task scheduler is used to schedule tasks from the container instances.
And the resource allocator is used for allocating the resources of the physical equipment.
In addition to communicating with the physical devices of the hardware layer (e.g., GPUs), the GPU device driver implements a plurality of device nodes, e.g., device node 1, device node 2, … … device node N, each of which is linked inside a respective container instance.
Therefore, one physical device can be shared by a plurality of container instances, and resource isolation and task isolation among the container instances can be guaranteed.
This GPU container approach does not require modification of the user-mode container runtime. Compared with a device fragment virtualization scheme, the method is easier to implement and has the theoretical performance advantage. Compared with a hardware SR-IOV (Single Root I/O Virtualization) scheme, the scheme is flexible and configurable.
In such a GPU container scheme, software upgrading is often required for the purposes of software repair, newly added functions, and the like.
In conventional upgrade schemes, all container services need to be stopped, then the underlying container software is upgraded, and then the container services are restarted. However, such an upgrade scheme may have an impact on the services within the container.
For example, for the architecture shown in fig. 1, a standard hot-upgrade scheme is to upgrade the entire GPU container driver as a whole. However, since the GPU container driver needs to provide a plurality of device nodes for the corresponding container instances to use, inevitably, the services in the container instances are affected during the upgrade process.
Therefore, there is still a need for a new container service solution that makes it possible to achieve a client-unaware hot upgrade of a container service without affecting the services within the container instance during the hot upgrade.
Disclosure of Invention
One technical problem to be solved by the present disclosure is to provide an apparatus and method for providing a container service and a method for hot upgrade of the apparatus, which can implement client-unaware hot upgrade of the container service.
According to a first aspect of the present disclosure, there is provided an apparatus for providing a container service, including a user mode module and a kernel mode module, the kernel mode module including: the interface driving module is used for creating and maintaining the equipment nodes and connecting the equipment nodes to the corresponding container instances in the user mode module; and the logic driving module is used for driving the physical equipment and executing a logic control function, wherein the logic driving module is communicated with the corresponding container instance in the user mode module through the equipment node maintained by the interface driving module.
Optionally, the logic driver module is configured to include a functional module that requires a hot upgrade and is capable of hot upgrade.
Optionally, the interface driver module is configured to include a functional module that does not require a hot upgrade.
Optionally, in response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
Optionally, before performing the upgrade processing on the logic driver module, the interface driver module calls a state saving function of the old logic driver module to save the state in the logic driver module; and after the upgrading processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module and transmits the stored state to the new logic driving module.
Optionally, the interface driver module also instructs the old logic driver module to suspend execution of the core logic function before the state save function is called.
Optionally, the interface driver module restores the old logic driver module in response to a rollback instruction or a hot upgrade error.
Optionally, the interface driver module receives a hot upgrade instruction from a hot upgrade management program in the user mode module.
Optionally, the logic driving module comprises: a task scheduler for scheduling tasks from each container instance; and/or a resource allocator for allocating resources of the physical device; and/or a device driver for driving the physical device.
Optionally, the user-mode module maintains the container instances, and the kernel-mode module causes the container instances to share the physical device.
Optionally, the device provides GPU container services, and the physical device is a GPU.
Optionally, the device further comprises the above physical device.
According to a second aspect of the present disclosure, there is provided an apparatus for providing container services, including a user mode module and a kernel mode module, the kernel mode module including: the first driving module is used for creating and maintaining the equipment node and connecting the equipment node to the corresponding container instance in the user mode module; and the second driving module is communicated with the corresponding container instance in the user mode module through the equipment node maintained by the first driving module.
Optionally, the first driver module includes a functional module that does not need to be thermally upgraded in the kernel mode module, and the second driver module includes a functional module that needs to be thermally upgraded in the kernel mode module.
Optionally, the kernel mode module includes a plurality of second driver modules, and in response to a hot upgrade instruction for one or more second driver modules of the plurality of second driver modules, the first driver module performs upgrade processing on the one or more second driver modules.
According to a third aspect of the present disclosure, there is provided a container service providing method including: maintaining the container instance in a user state; providing an interface driving module in a kernel mode, and being used for creating and maintaining the equipment node and connecting the equipment node to the corresponding container instance in the user mode module; and providing a logic driving module in the kernel mode, wherein the logic driving module is used for driving the physical equipment and executing a logic control function, and the logic driving module is communicated with the corresponding container instance in the user mode module through the equipment node maintained by the interface driving module.
Optionally, the logic driver module is configured to include a functional module that requires a hot upgrade and is capable of hot upgrade.
Optionally, the interface driver module is configured to include a functional module that does not require a hot upgrade.
Optionally, the method may further include: in response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
Optionally, the method may further include: before the upgrading processing of the logic driving module is executed, the interface driving module calls a state saving function of the old logic driving module to save the state in the logic driving module; and after the upgrading processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module and transmits the stored state to the new logic driving module.
Optionally, the method may further include: the interface driver module also instructs the old logic driver module to suspend execution of the core logic function before the state save function is called.
Optionally, the method may further include: in response to a rollback instruction or a hot upgrade error, the interface driver module recovers the old logic driver module.
Optionally, the method may further include: the interface driving module receives a hot upgrade instruction from a hot upgrade management program in the user mode module.
Optionally, the logic driver module maintains at least one of: a task scheduler for scheduling tasks from each container instance; and/or a resource allocator for allocating resources of the physical device; and/or a device driver for driving the physical device.
According to a fourth aspect of the present disclosure, there is provided a method of hot-upgrading a device according to the first aspect of the present disclosure, comprising: in response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
Optionally, the method may further include: before the upgrading processing of the logic driving module is executed, the interface driving module calls a state saving function of the old logic driving module to save the state in the logic driving module; and after the upgrading processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module and transmits the stored state to the new logic driving module.
Optionally, the method may further include: the interface driver module also instructs the old logic driver module to suspend execution of the core logic function before the state save function is called.
Optionally, the method may further include: in response to a rollback instruction or a hot upgrade error, the interface driver module recovers the old logic driver module.
Optionally, the method may further include: the interface driving module receives a hot upgrade instruction from a hot upgrade management program in the user mode module.
According to a fifth aspect of the present disclosure, there is provided a container service providing method including: maintaining the container instance in a user state; providing a first driving module in a kernel mode, wherein the first driving module is used for creating and maintaining equipment nodes and connecting the equipment nodes to corresponding container instances in a user mode module; and providing a second driver module in the kernel mode, and communicating with the corresponding container instance in the user mode module through the equipment node maintained by the first driver module.
Optionally, the first driver module includes a functional module that does not need to be subjected to a hot upgrade in a kernel mode, and the second driver module includes a functional module that needs to be subjected to a hot upgrade in a kernel mode.
Optionally, a plurality of second driving modules are provided in the kernel state, and the method may further include: in response to a hot upgrade instruction for one or more of the plurality of second driver modules, the first driver module performs an upgrade process for the one or more second driver modules.
According to a sixth aspect of the present disclosure, there is provided a computing device comprising: a processor; and a memory having executable code stored thereon, which when executed by the processor, causes the processor to perform the method as described in the third to fifth aspects above.
According to a seventh aspect of the present disclosure, there is provided a non-transitory machine-readable storage medium having stored thereon executable code which, when executed by a processor of an electronic device, causes the processor to perform the method of the third to fifth aspects as described above.
Therefore, by decoupling the interface driver and the kernel driver, compared with the traditional overall hot upgrading scheme, the scheme can conveniently realize the container service hot upgrading without perception of a client, greatly reduces the realization difficulty and avoids the risk possibly brought by the hot upgrading.
In a further embodiment, the interface driver module may also timely rollback the logic driver module to an old version even if a hot upgrade is in error. The whole process of upgrading the error and returning can also be completely imperceptible to the client.
Drawings
The above and other objects, features and advantages of the present disclosure will become more apparent by describing in greater detail exemplary embodiments thereof with reference to the attached drawings, in which like reference numerals generally represent like parts throughout.
Fig. 1 schematically shows a container architecture of the prior art.
Fig. 2 schematically illustrates a container architecture according to the present disclosure.
Fig. 3 is a schematic flow diagram of a container service hot upgrade method according to the present disclosure.
Fig. 4 is a schematic structural diagram of a computing device that can be used to implement the method for providing a container service according to an embodiment of the present invention.
Detailed Description
Preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
In the container service providing scheme according to the present disclosure, the kernel driver of the original GPU container is split into a stable interface driver module that generally does not need to be thermally upgraded and a core logic module that can be thermally upgraded. When the hot upgrade is carried out, the interface driving module does not need to be upgraded, and only the core logic module needs to be upgraded.
Here, the hot upgrade refers to upgrade without affecting the service. Kernel refers to the Kernel of an operating system, often used to refer to the Kernel of a Linux operating system.
With this innovative architecture, hot upgrades can be made without affecting the container service to the customer. And compared with the traditional integral hot upgrading scheme, the method is simple in implementation difficulty.
Fig. 2 schematically illustrates a container architecture according to the present disclosure, which may be an example of an apparatus for providing a container service according to the present disclosure.
As shown in fig. 2, the container architecture (device) may include a user-mode module and a kernel-mode module.
The container architecture (device) may also include a physical device. The kernel mode module drives the physical device and enables one or more container instances maintained by the user mode module to share the physical device.
The physical device may comprise, for example, a GPU. Accordingly, the container architecture (device) may be, for example, a container architecture (device) that provides GPU container services.
The user-mode module maintains multiple container instances, e.g., container 1, container 2, … …, container N, in user-mode. These container instances may be separately initialized based on a container runtime (e.g., GPU container runtime). The kernel-state module enables the container instances to share physical devices and may include an interface driver module 100 and a logical driver module 200.
Interface driver module 100 is used to create and maintain device nodes, e.g., device node 1, device node 2, … …, device node N, and to connect these device nodes to corresponding container instances in the user mode module, e.g., container 1, container 2, … …, container N, respectively.
In general, a container instance may not be able to directly see a device node. In this way, the device node can be bound or connected to the container instance through an additional command, so that the created and maintained device node can be seen inside the container instance, thereby communicating with the kernel mode module through the device node, and further sharing and utilizing the physical device allocated for the device node.
The logic driver module 200 is used to perform logic control functions, especially logic functions of the core (in this case, it may also be called "core driver module"), such as task scheduling and resource allocation.
In the solution of the present disclosure, the interface driver module 100 is introduced to maintain an interface, i.e. a device node, between the logic driver module 200 and the container instance in the user mode module, in other words, a function that needs to communicate with the user mode module is implemented in the interface driver module 100. Thus, the logic control functions performed by the logic driver module 200 may include those in kernel mode that do not require direct communication with the container instance in the user mode module, and thus do not affect the service of the user mode container during a hot upgrade, such as task scheduling, resource allocation, device drivers, etc. The logic driver module 200 may also be used to drive a physical device, such as a GPU.
For example, the logic driver module 200 may include a task scheduler 210, a resource allocator 220, and a device driver 230.
A task scheduler 210 for scheduling tasks from the container instances.
The resource allocator 220 is configured to allocate resources of the physical device.
A device driver 230 for driving a physical device, such as a GPU. In an aspect in accordance with the present disclosure, the device driver 230 no longer creates and maintains device nodes that communicate with the user-mode container instance, and thus is decoupled from the container instance.
The logic driver module 200 communicates with the corresponding container instance in the respective user mode module via each device node maintained by the interface driver module 100.
The logic driving module 200 is configured to include a functional module requiring a thermal upgrade and to be capable of a thermal upgrade. In other words, various logic functions and the like that can be upgraded thermally can be implemented in the logic driving module 200.
On the other hand, since the interfaces of the device nodes are not usually changed, the interface driver module 100 may not be upgraded thermally.
In other words, functions that do not generally require a hot upgrade, particularly maintenance functions for device nodes communicating with user-mode container instances, may be implemented in the interface driver module 100. That is, the interface driver module is configured to include a functional module that does not require a hot upgrade. This module, once completed, can remain stable without the need for a hot upgrade.
The interface driver module 100 may receive a hot upgrade instruction from a hot upgrade management program in the user mode module.
In response to the hot upgrade instruction, the interface driver module 100 may perform an upgrade process on the logic driver module 200. For example, the old logical driver module may be deleted (uninstalled) and the new logical driver module may be loaded and installed. Alternatively, the old logic driver module may be modified, for example, part of the old content (for example, the new function implementation) is deleted and/or part of the new content (for example, the new function implementation) is added.
Thus, the thermal upgrade of the logic driving module 200 can be conveniently realized.
Meanwhile, since the interface driving module 100 of the device node for maintaining communication with the user-mode container instance is not thermally upgraded, it is possible to realize no sense to the user in the thermal upgrade process.
In addition, before performing the upgrade process on the logic driver module 200, the interface driver module 100 may call a state saving function of the old logic driver module to save a state, such as a device node state, in the logic driver module 200.
Accordingly, after performing the upgrade process on the logic driver module 200, the interface driver module 100 calls the state restoration function of the new logic driver module, and passes the saved state, e.g., the device node state, to the new logic driver module.
In a container architecture such as that shown in fig. 1, the GPU container driver is used to save the states of a plurality of device nodes, which is prone to generate a race state in software, causing instability of the device driver and even kernel crash.
In the solution of the present disclosure, the interface driver module 100 calls the state save function of the old logic driver module to save the state, and calls the state restore function of the new logic driver module to restore the state.
Thus, smooth recovery of state information can be achieved, so that smooth container service can be provided even before and after hot upgrade.
In addition, to avoid running errors, interface driver module 100 may also instruct old logic driver module 2 to suspend execution of core logic functions before performing a hot upgrade, or further, before calling the state save function.
Therefore, after the state is saved, the state can not be changed due to the operation of the old logic driving module, and the problem of state error after the hot upgrade is finished can be further avoided.
In addition, the interface driver module 100 may also restore the old logical driver module 2 in response to a rollback instruction issued by a user or system, or in response to a hot upgrade error.
In this way, even if a hot upgrade makes a mistake, or desires to return to a previous version, the old logical drive module can be conveniently restored to continue providing container services.
The process of performing a hot upgrade in a container service provisioning scheme according to the present disclosure is further described below with reference to fig. 3.
Fig. 3 is a schematic flow diagram of a container service hot upgrade method according to the present disclosure.
In step S1, when a hot upgrade is needed, the hot upgrade management program in the user mode module triggers a hot upgrade process to notify the interface driver module 100. The interface driver module 100 receives a hot upgrade instruction from a hot upgrade management program.
In step S2, the interface driver module 100 instructs the old logic driver module 200 to suspend execution of core logic functions, such as task scheduler, resource allocator, etc., to prevent errors during the hot upgrade process.
In step S3, the interface driver module 100 calls a state saving function of the logic driver module 200 to save the state in the logic driver module 200, such as the device node state.
In step S4, the interface driver module 100 performs an upgrade process for the logic driver module 200.
For example, it may be that the old logical driver module is unloaded and the new logical driver module is loaded. Alternatively, the old logic driver module may be modified, for example, part of the old content (for example, the new function implementation) is deleted and/or part of the new content (for example, the new function implementation) is added.
In step S5, the interface driver module 100 calls the state restoration function of the new logical driver module to transfer the state saved in step S3, e.g., the device node state, to the new logical driver module (i.e., to restore the state).
In step S6, the interface driver module 100 may continue to run the new logical driver module.
So far, the whole hot upgrading process is completed.
As described above, in the scheme of providing container services according to the present disclosure, an original single kernel-mode module is divided into two sub-modules.
A sub-module provides an interface for a user-mode container instance and remains stable, thereby avoiding maintaining the complex state of the user-mode interface during a hot upgrade.
The other submodule executes the core logic of the container service, and ensures the core functions of the container service, such as a resource distributor, a task scheduler and the like. These functions can be upgraded thermally, and the service of the user mode container is not affected during the hot upgrade.
More generally, the kernel mode module may include a first driver module and a second driver module.
The first driver module may include a functional module of the kernel-mode module that does not require a hot upgrade. For example, the first driver module may be, but is not limited to, the interface driver module 100 shown in FIG. 2, for creating and maintaining the device node and connecting the device node to the corresponding container instance in the user mode module. In this way, the first driver module provides an interface for the user-mode container instance, i.e. the functionality that needs to communicate with the user-mode module is implemented in the first driver module. It should be understood that the first driver module may also include other functional modules that do not require or infrequently require a thermal upgrade. For example, when a module of the logic driver modules 200 shown in fig. 2, for example, one of the task scheduler 210, the resource scheduler 220, and the device driver 230, does not need or does not often need to be upgraded, it may be configured in the first driver module.
The second driver module may include a functional module that needs to be upgraded in a kernel mode module, or may include only a functional module that often needs to be upgraded in a hot mode in some embodiments. For example, the second driver module may be, but is not limited to, the logical driver module 200 shown in fig. 2, and communicates with the corresponding container instance in the user mode module through the device node maintained by the first driver module. It should be understood that the second driver module may also include other functional modules that require or frequently require a thermal upgrade. Alternatively, as described above, in some cases, a certain module in the logic driver module 200 shown in fig. 2 may be configured not to belong to the second driver module but to be configured in the first driver module.
In some embodiments, the logic functions performed by the second driver module may include those logic control functions in kernel mode that do not require direct communication with the container instance in the user mode module, and thus do not affect the service of the user mode container during a hot upgrade, such as task scheduling, resource allocation, device drivers, and the like.
In addition, one second driving module may be provided in the core state module, or a plurality of second driving modules may be provided.
In the case where a plurality of second driving modules are provided, the plurality of second driving modules may perform the same type of function, and may also perform different types of functions.
For example, there may be one or more second driver modules that include a task scheduler for performing task orchestration functions. Also for example, there may be one or more of the second driver modules including a resource allocator for performing resource allocation functions. For another example, there may be one or more second driver modules comprising a device driver for driving a physical device, such as a GPU.
In this way, one or more secondary drive modules may be thermally upgraded at a time. In other words, in response to a hot upgrade instruction for one or more of the plurality of second drive modules, the first drive module may perform an upgrade process for the one or more second drive modules. And for other second drive modules which do not receive the hot upgrade instruction, the hot upgrade processing is not required.
After receiving a hot upgrade instruction sent by a user-mode hot upgrade management program, the first driver module can perform hot upgrade on the corresponding second driver module.
The process of a hot upgrade may be substantially the same as the process described above with reference to fig. 3, except that the interface driver module is replaced with a first driver module and the logic driver module is replaced with a second driver module.
Specifically, the first driver module instructs the old second driver module that requires the hot upgrade to suspend performing its logic function. The first driver module calls the state save function of the old second driver module to save the function. The first driver module performs a hot upgrade of the second driver module. The first driver module calls the state recovery function of the new second driver module to recover the state. And then continuing to operate the second driving module, and finishing the hot upgrade.
In some embodiments, the disclosed solution may be implemented as a heterogeneous computing solution, i.e., a system computing solution consisting of computing units using different types of instruction sets and architectures. Common classes of computing units include CPUs (central processing units), GPUs (image processing units), NPUs (neural network processing units), and the like.
For example, container service software may be executed in the CPU, including user mode, kernel mode. The underlying physical device of the container service may then be a GPU.
Fig. 4 is a schematic structural diagram of a computing device that can be used to implement the method for providing a container service according to an embodiment of the present invention.
Referring to fig. 4, computing device 400 includes memory 410 and processor 420.
The processor 420 may be a multi-core processor or may include a plurality of processors. In some embodiments, processor 420 may include a general-purpose host processor and one or more special coprocessors such as a Graphics Processor (GPU), a Digital Signal Processor (DSP), or the like. In some embodiments, processor 420 may be implemented using custom circuits, such as an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA).
The memory 410 may include various types of storage units, such as system memory, Read Only Memory (ROM), and permanent storage. Wherein the ROM may store static data or instructions that are required by the processor 420 or other modules of the computer. The persistent storage device may be a read-write storage device. The persistent storage may be a non-volatile storage device that does not lose stored instructions and data even after the computer is powered off. In some embodiments, the persistent storage device employs a mass storage device (e.g., magnetic or optical disk, flash memory) as the persistent storage device. In other embodiments, the permanent storage may be a removable storage device (e.g., floppy disk, optical drive). The system memory may be a read-write memory device or a volatile read-write memory device, such as a dynamic random access memory. The system memory may store instructions and data that some or all of the processors require at runtime. Further, the memory 410 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), magnetic and/or optical disks, may also be employed. In some embodiments, memory 410 may include a removable storage device that is readable and/or writable, such as a Compact Disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, dual layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, min SD card, Micro-SD card, etc.), a magnetic floppy disc, or the like. Computer-readable storage media do not contain carrier waves or transitory electronic signals transmitted by wireless or wired means.
The memory 410 has stored thereon executable code that, when processed by the processor 420, causes the processor 420 to perform the above-mentioned method of providing container services.
The apparatus and method for providing a container service according to the present invention have been described above in detail with reference to the accompanying drawings.
Furthermore, the method according to the invention may also be implemented as a computer program or computer program product comprising computer program code instructions for carrying out the above-mentioned steps defined in the above-mentioned method of the invention.
Alternatively, the invention may also be embodied as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) having stored thereon executable code (or a computer program, or computer instruction code) which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the steps of the above-described method according to the invention.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (24)
1. An apparatus for providing container services, comprising a user-mode module and a kernel-mode module, the kernel-mode module comprising:
the interface driving module is used for creating and maintaining the equipment nodes and connecting the equipment nodes to the corresponding container instances in the user mode module; and
and the logic driving module is used for driving the physical equipment and executing a logic control function, wherein the logic driving module is communicated with the corresponding container instance in the user mode module through the equipment node maintained by the interface driving module.
2. The apparatus of claim 1, wherein,
the logic driving module is configured to comprise a functional module needing hot upgrading and can be hot upgraded; and/or
The interface driver module is configured to include functional modules that do not require a thermal upgrade.
3. The apparatus of claim 1, wherein,
the interface driving module receives a hot upgrade instruction from a hot upgrade management program in the user mode module; and/or
In response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
4. The apparatus of claim 3, wherein,
before the upgrading processing of the logic driving module is executed, the interface driving module calls a state saving function of the old logic driving module to save the state in the logic driving module; and is
After the upgrade processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module, and transmits the stored state to the new logic driving module.
5. The apparatus of claim 4, wherein,
before the state saving function is called, the interface driving module also instructs the old logic driving module to suspend the execution of the core logic function; and/or
In response to a rollback instruction or a hot upgrade error, the interface driver module recovers the old logic driver module.
6. The apparatus of claim 1, wherein the logic driver module comprises:
a task scheduler for scheduling tasks from each container instance; and/or
A resource allocator for allocating resources of the physical device; and/or
A device driver for driving the physical device.
7. The apparatus of any one of claims 1 to 6,
the user mode module maintains the container examples, and the kernel mode module enables the container examples to share the physical equipment; and/or
The device provides GPU container services, the physical device is a GPU; and/or
The device also includes the physical device.
8. An apparatus for providing container services, comprising a user-mode module and a kernel-mode module, the kernel-mode module comprising:
the first driving module is used for creating and maintaining the equipment node and connecting the equipment node to the corresponding container instance in the user mode module; and
and the second driving module is communicated with the corresponding container instance in the user mode module through the equipment node maintained by the first driving module.
9. The apparatus of claim 8, wherein,
the first driving module comprises a functional module which does not need to be subjected to thermal upgrade in the kernel mode module, and the second driving module comprises a functional module which needs to be subjected to thermal upgrade in the kernel mode module; and/or
The kernel mode module comprises a plurality of second driver modules, and the first driver module executes upgrading processing of one or more second driver modules in response to a hot upgrading instruction aiming at one or more second driver modules in the plurality of second driver modules.
10. A container service providing method, comprising:
maintaining the container instance in a user state;
providing an interface driving module in a kernel mode, and being used for creating and maintaining the equipment node and connecting the equipment node to the corresponding container instance in the user mode module; and
and providing a logic driving module in the kernel state, wherein the logic driving module is used for driving the physical equipment and executing a logic control function, and the logic driving module is communicated with the corresponding container instance in the user state module through the equipment node maintained by the interface driving module.
11. The method of claim 10, wherein,
the logic driving module is configured to comprise a functional module needing hot upgrading and can be hot upgraded; and/or
The interface driver module is configured to include functional modules that do not require a thermal upgrade.
12. The method of claim 10, further comprising:
the interface driving module receives a hot upgrade instruction from a hot upgrade management program in the user mode module; and/or
In response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
13. The method of claim 12, further comprising:
before the upgrading processing of the logic driving module is executed, the interface driving module calls a state saving function of the old logic driving module to save the state in the logic driving module; and
after the upgrade processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module, and transmits the stored state to the new logic driving module.
14. The method of claim 13, further comprising:
before the state saving function is called, the interface driving module also instructs the old logic driving module to suspend the execution of the core logic function; and/or
In response to a rollback instruction or a hot upgrade error, the interface driver module recovers the old logic driver module.
15. The method of claim 10, wherein the logical drive module maintains at least one of:
a task scheduler for scheduling tasks from each container instance; and/or
A resource allocator for allocating resources of the physical device; and/or
A device driver for driving the physical device.
16. The method of any one of claims 10 to 15,
the kernel mode enables the container instances to share the physical device; and/or
The container service is a GPU container service and the physical device is a GPU.
17. A method of thermally upgrading the apparatus of any of claims 1 to 7, comprising:
in response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.
18. The method of claim 17, further comprising:
before the upgrading processing of the logic driving module is executed, the interface driving module calls a state saving function of the old logic driving module to save the state in the logic driving module; and
after the upgrade processing of the logic driving module is executed, the interface driving module calls a state recovery function of the new logic driving module, and transmits the stored state to the new logic driving module.
19. The method of claim 18, further comprising:
before the state saving function is called, the interface driving module also instructs the old logic driving module to suspend the execution of the core logic function; and/or
In response to a rollback instruction or a hot upgrade error, the interface driver module recovers the old logic driver module.
20. The method of claim 17, further comprising:
the interface driving module receives a hot upgrade instruction from a hot upgrade management program in the user mode module.
21. A container service providing method, comprising:
maintaining the container instance in a user state;
providing a first driving module in a kernel mode, wherein the first driving module is used for creating and maintaining equipment nodes and connecting the equipment nodes to corresponding container instances in a user mode module; and
and providing a second driver module in the kernel mode, and communicating with the corresponding container instance in the user mode module through the equipment node maintained by the first driver module.
22. The method of claim 21, wherein,
the first driving module comprises a functional module which does not need to be subjected to hot upgrading in a kernel state, and the second driving module comprises a functional module which needs to be subjected to hot upgrading in the kernel state; and/or
Providing a plurality of second driver modules in the kernel state, the method further comprising: in response to a hot upgrade instruction for one or more of the plurality of second driver modules, the first driver module performs an upgrade process for the one or more second driver modules.
23. A computing device, comprising:
a processor; and
a memory having executable code stored thereon which, when executed by the processor, causes the processor to perform the method of any of claims 10 to 22.
24. A non-transitory machine-readable storage medium having stored thereon executable code, which when executed by a processor of an electronic device, causes the processor to perform the method of any of claims 10 to 22.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110137160.0A CN113296821A (en) | 2021-02-01 | 2021-02-01 | Apparatus and method for providing container service and hot upgrade method of the apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110137160.0A CN113296821A (en) | 2021-02-01 | 2021-02-01 | Apparatus and method for providing container service and hot upgrade method of the apparatus |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113296821A true CN113296821A (en) | 2021-08-24 |
Family
ID=77318890
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110137160.0A Pending CN113296821A (en) | 2021-02-01 | 2021-02-01 | Apparatus and method for providing container service and hot upgrade method of the apparatus |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113296821A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023165431A1 (en) * | 2022-03-03 | 2023-09-07 | 阿里巴巴（中国）有限公司 | Device access method and system for secure container |
-
2021
- 2021-02-01 CN CN202110137160.0A patent/CN113296821A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023165431A1 (en) * | 2022-03-03 | 2023-09-07 | 阿里巴巴（中国）有限公司 | Device access method and system for secure container |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9170835B2 (en) | Apparatus and method for expedited virtual machine (VM) launch in VM cluster environment | |
| US8875133B2 (en) | Migration of virtual machines | |
| US9760408B2 (en) | Distributed I/O operations performed in a continuous computing fabric environment | |
| US9384060B2 (en) | Dynamic allocation and assignment of virtual functions within fabric | |
| US7743372B2 (en) | Dynamic cluster code updating in logical partitions | |
| US10635499B2 (en) | Multifunction option virtualization for single root I/O virtualization | |
| US20060020940A1 (en) | Soft-partitioning systems and methods | |
| CN111290827B (en) | Data processing method, device and server | |
| US20140089652A1 (en) | Customizing program logic for booting a system | |
| US11334427B2 (en) | System and method to reduce address range scrub execution time in non-volatile dual inline memory modules | |
| US20120227050A1 (en) | Changing a scheduler in a virtual machine monitor | |
| US10705867B2 (en) | Hypervisor exchange with virtual machines in memory | |
| WO2023061172A1 (en) | Application upgrading method and apparatus, and computing device and chip system | |
| US8484616B1 (en) | Universal module model | |
| US9804877B2 (en) | Reset of single root PCI manager and physical functions within a fabric | |
| JP2002132741A (en) | Processor adding method, computer and recording medium | |
| US20160077847A1 (en) | Synchronization of physical functions and virtual functions within a fabric | |
| CN113296821A (en) | Apparatus and method for providing container service and hot upgrade method of the apparatus | |
| CN114816655A (en) | Device access method and system for secure container | |
| JP6859463B2 (en) | Methods, devices, devices and media for launching virtual machines | |
| US20120272239A1 (en) | Sharing class data | |
| US11221766B2 (en) | System and method for persistent memory rotation based on remaining write endurance | |
| US20200364040A1 (en) | System and Method for Restoring a Previously Functional Firmware Image on a Non-Volatile Dual Inline Memory Module | |
| US8612737B2 (en) | System and method for supporting multiple hardware platforms with a single disk image | |
| CN108304200B (en) | Method and device for upgrading driving program and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40057566 Country of ref document: HK |