Device and method for providing container services and hot upgrade method of the device

Abstract

Disclosed are a device and method for providing container services, as well as a hot upgrade method for the device. Container instances are maintained in a user-state module. The kernel-state module includes an interface driver module and a logic driver module. The interface driver module is used to create and maintain device nodes, and connect the device nodes to corresponding container instances in the user-state module. The logic driver module is used to drive physical devices and perform logic control functions. The logic driver module communicates with the corresponding container instance in the user-state module through the device nodes maintained by the interface driver module. Functional modules that need to be hot-upgraded are configured in the logic driver module. During hot upgrades, the interface driver module is not hot-upgraded, but the interface driver module performs the upgrade process for the logic driver module. Thus, a new container architecture is provided, which can achieve hot upgrades of container services without the customer's perception.

Description

Technical Field

[0001] The present disclosure relates to a container service in the Internet field, and more particularly to a device and method for providing a container service, and a hot upgrade method for the device. Background Art

[0002] Container technology packages software into standardized units for development, delivery, and deployment. It ensures a consistent application runtime environment and enables faster startup. Container technology offers advantages such as isolation, scalability, ease of migration, and sustainable delivery and deployment. These features have led to its widespread adoption in cloud services.

[0003] For example, a lightweight GPU (Graphics Processing Unit) virtualization solution can be implemented based on container technology. Figure 1 A GPU container architecture that can be used in this solution is schematically shown.

[0004] In this GPU container architecture, a kernel-mode device driver (also called a "device driver" or a "device driver module") is used to implement communication between kernel-mode modules and containers, and between kernel-mode modules and physical devices.

[0005] like Figure 1 As shown, the user-mode module creates and maintains multiple container instances, such as container 1, container 2, ..., container N. These container instances can be initialized separately based on the GPU container runtime library.

[0006] The GPU container driver of the kernel-mode module includes a task scheduler, a resource allocator, and a GPU device driver.

[0007] The task scheduler is used to schedule tasks from various container instances.

[0008] Resource allocator, used to allocate resources of physical devices.

[0009] In addition to communicating with physical devices (such as GPUs) at the hardware layer, the GPU device driver also implements multiple device nodes, such as device node 1, device node 2, ... device node N, and links these device nodes to the corresponding container instances.

[0010] In this way, a physical device can be shared by multiple container instances, while ensuring resource isolation and task isolation between container instances.

[0011] This GPU container solution does not require modifications to the user-mode container runtime. Compared to device sharding virtualization solutions, this solution is easier to implement and offers theoretical performance advantages. Compared to hardware-based SR-IOV (Single Root I / O Virtualization) solutions, this solution is also flexible and configurable.

[0012] In this GPU container solution, software upgrades are often required for purposes such as software repair and new features.

[0013] In traditional upgrade solutions, you need to stop all container services, then upgrade the underlying container software, and then restart the container services. However, this upgrade solution will affect the services within the container.

[0014] For example, for Figure 1 In the architecture shown, the standard hot upgrade solution is to upgrade the entire GPU container driver as a whole. However, because the GPU container driver needs to provide multiple device nodes for the corresponding container instance, the upgrade process will inevitably affect the services within the container instance.

[0015] Therefore, there is still a need for a new container service solution that can realize hot upgrades of container services without customer perception, and will not affect the services within the container instance during the hot upgrade process. Summary of the Invention

[0016] A technical problem to be solved by the present disclosure is to provide a device and method for providing container services, as well as a hot upgrade method for the device, which can achieve hot upgrade of container services without customer perception.

[0017] According to a first aspect of the present disclosure, a device for providing container services is provided, including a user-mode module and a kernel-mode module. The kernel-mode module includes: an interface driver module for creating and maintaining device nodes and connecting the device nodes to corresponding container instances in the user-mode module; and a logic driver module for driving physical devices and performing logic control functions, wherein the logic driver module communicates with the corresponding container instances in the user-mode module via the device nodes maintained by the interface driver module.

[0018] Optionally, the logic driver module is configured to include a functional module that needs to be hot-upgraded and is capable of hot-upgrading.

[0019] Optionally, the interface driver module is configured to include a functional module that does not require hot upgrade.

[0020] Optionally, in response to the hot upgrade instruction, the interface driver module performs an upgrade process on the logic driver module.

[0021] Optionally, before performing the upgrade processing of the logic driver module, the interface driver module calls the state save function of the old logic driver module to save the state in the logic driver module; and after performing the upgrade processing of the logic driver module, the interface driver module calls the state recovery function of the new logic driver module to pass the saved state to the new logic driver module.

[0022] Optionally, before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function.

[0023] Optionally, in response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

[0024] Optionally, the interface driver module receives a hot upgrade instruction from a hot upgrade management program in the user mode module.

[0025] Optionally, the logic driver module includes: a task scheduler for scheduling tasks from each container instance; and / or a resource allocator for allocating resources of a physical device; and / or a device driver for driving a physical device.

[0026] Optionally, the user-mode module maintains the container instance, and the kernel-mode module enables the container instance to share physical devices.

[0027] Optionally, the device provides a GPU container service, and the physical device is a GPU.

[0028] Optionally, the device also includes the above-mentioned physical device.

[0029] According to a second aspect of the present disclosure, a device for providing container services is provided, including a user-state module and a kernel-state module. The kernel-state module includes: a first driver module, configured to create and maintain a device node, and connect the device node to a corresponding container instance in the user-state module; and a second driver module, configured to communicate with the corresponding container instance in the user-state module through the device node maintained by the first driver module.

[0030] Optionally, the first driver module includes functional modules in the kernel state module that do not need to be hot-upgraded, and the second driver module includes functional modules in the kernel state module that need to be hot-upgraded.

[0031] Optionally, the kernel mode module includes multiple second driver modules, and in response to a hot upgrade instruction for one or more second driver modules among the multiple second driver modules, the first driver module performs upgrade processing on the one or more second driver modules.

[0032] According to a third aspect of the present disclosure, a method for providing a container service is provided, comprising: maintaining a container instance in user mode; providing an interface driver module in kernel mode for creating and maintaining a device node and connecting the device node to a corresponding container instance in the user mode module; and providing a logic driver module in kernel mode for driving a physical device and performing a logic control function, wherein the logic driver module communicates with the corresponding container instance in the user mode module via the device node maintained by the interface driver module.

[0033] Optionally, the logic driver module is configured to include a functional module that needs to be hot-upgraded and is capable of hot-upgrading.

[0034] Optionally, the interface driver module is configured to include a functional module that does not require hot upgrade.

[0035] 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.

[0036] Optionally, the method may also include: before performing the upgrade processing of the logic driver module, the interface driver module calls the state save function of the old logic driver module to save the state in the logic driver module; and after performing the upgrade processing of the logic driver module, the interface driver module calls the state recovery function of the new logic driver module to pass the saved state to the new logic driver module.

[0037] Optionally, the method may further include: before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function.

[0038] Optionally, the method may further include: in response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

[0039] Optionally, the method may further include: the interface driver module receiving a hot upgrade instruction from a hot upgrade management program in the user mode module.

[0040] Optionally, the logic driver module maintains at least one of the following: a task scheduler for scheduling tasks from each container instance; and / or a resource allocator for allocating resources of a physical device; and / or a device driver for driving a physical device.

[0041] According to a fourth aspect of the present disclosure, a method for hot upgrading the device according to the first aspect of the present disclosure is provided, comprising: in response to a hot upgrade instruction, an interface driver module performs upgrade processing on a logic driver module.

[0042] Optionally, the method may also include: before performing the upgrade processing of the logic driver module, the interface driver module calls the state save function of the old logic driver module to save the state in the logic driver module; and after performing the upgrade processing of the logic driver module, the interface driver module calls the state recovery function of the new logic driver module to pass the saved state to the new logic driver module.

[0043] Optionally, the method may further include: before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function.

[0044] Optionally, the method may further include: in response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

[0045] Optionally, the method may further include: the interface driver module receiving a hot upgrade instruction from a hot upgrade management program in the user mode module.

[0046] According to a fifth aspect of the present disclosure, a method for providing a container service is provided, including: maintaining a container instance in user mode; providing a first driver module in kernel mode, for creating and maintaining a device node, and connecting the device node to a corresponding container instance in the user mode module; and providing a second driver module in kernel mode, for communicating with the corresponding container instance in the user mode module through the device node maintained by the first driver module.

[0047] Optionally, the first driver module includes functional modules that do not need to be hot-upgraded in the kernel state, and the second driver module includes functional modules that need to be hot-upgraded in the kernel state.

[0048] Optionally, multiple second driver modules are provided in kernel mode, and the method may further include: in response to a hot upgrade instruction for one or more second driver modules among the multiple second driver modules, the first driver module performs upgrade processing on the one or more second driver modules.

[0049] According to a sixth aspect of the present disclosure, a computing device is provided, comprising: a processor; and a memory on which executable code is stored, and when the executable code is executed by the processor, the processor executes the method described in the third to fifth aspects above.

[0050] According to a seventh aspect of the present disclosure, a non-transitory machine-readable storage medium is provided, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor executes the methods described in the third to fifth aspects above.

[0051] Therefore, by decoupling the interface driver from the kernel driver, compared with the traditional overall hot upgrade solution, this solution can easily implement hot upgrades of container services without customer perception, greatly reducing the implementation difficulty and avoiding the risks that may be brought about by hot upgrades.

[0052] In a further embodiment, even if a hot upgrade fails, the interface driver module can promptly roll back the logic driver module to the old version. The entire process of upgrade failure and rollback can also be completely imperceptible to the customer. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure with reference to the accompanying drawings, wherein like reference numerals generally represent like components in the exemplary embodiments of the present disclosure.

[0054] Figure 1 A container architecture in the prior art is schematically shown.

[0055] Figure 2 The container architecture according to the present disclosure is schematically shown.

[0056] Figure 3 4 is a schematic flow chart of a container service hot upgrade method according to the present disclosure.

[0057] Figure 4 A schematic diagram of the structure of a computing device that can be used to implement the above-mentioned method for providing container services according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0058] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0059] In the container service provisioning solution disclosed herein, the existing GPU container kernel driver is split into a stable interface driver module that generally does not require hot upgrades, and a core logic module that can be hot upgraded. During a hot upgrade, the interface driver module does not need to be upgraded, only the core logic module needs to be upgraded.

[0060] Here, hot upgrade refers to upgrading without affecting services. Kernel refers to the kernel of the operating system, often used to refer to the kernel of the Linux operating system.

[0061] This innovative architecture enables hot upgrades without impacting container services for customers. Furthermore, compared to traditional, integrated hot upgrade solutions, it is much simpler to implement.

[0062] Figure 2 The container architecture according to the present disclosure is schematically shown, which can be used as an example of a device providing container services according to the present disclosure.

[0063] like Figure 2 As shown, the container architecture (device) may include a user-mode module and a kernel-mode module.

[0064] 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.

[0065] The physical device may include a GPU, for example. Accordingly, the container architecture (device) may be a container architecture (device) that provides a GPU container service, for example.

[0066] The user-state module maintains multiple container instances in user state, such as container 1, container 2, ..., container N. These container instances can be initialized separately based on a container runtime (e.g., a 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 logic driver module 200.

[0067] The interface driver module 100 is used to create and maintain device nodes, such as device node 1, device node 2, ..., device node N, and connect these device nodes to corresponding container instances in the user state module, such as container 1, container 2, ..., container N.

[0068] Generally speaking, a container instance may not be able to directly see the device node. Therefore, you can use additional commands to bind or connect the device node to the container instance, so that the container instance can see the created and maintained device node, communicate with the kernel module through the device node, and then share the physical device allocated to it.

[0069] The logic driver module 200 is used to execute logic control functions, especially core logic functions (in this case, it can also be called a "core driver module"), such as task scheduling and resource allocation.

[0070] In the disclosed solution, an interface driver module 100 is introduced to maintain the interface, i.e., the device node, between the logic driver module 200 and the container instance in the user-mode module. In other words, functions that require communication with the user-mode module are implemented in the interface driver module 100. Therefore, the logical control functions performed by the logic driver module 200 can include those in kernel mode that do not require direct communication with the container instance in the user-mode module, thereby ensuring that hot upgrades do not affect the services of the user-mode container, such as task scheduling, resource allocation, and device drivers. The logic driver module 200 can also be used to drive physical devices, such as a GPU.

[0071] For example, the logic driver module 200 may include a task scheduler 210 , a resource allocator 220 , and a device driver 230 .

[0072] The task scheduler 210 is used to schedule tasks from each container instance.

[0073] The resource allocator 220 is configured to allocate resources of the physical device.

[0074] The device driver 230 is used to drive a physical device, such as a GPU. In the solution according to the present disclosure, the device driver 230 no longer creates and maintains a device node for communicating with a user-mode container instance, thereby being decoupled from the container instance.

[0075] The logic driver module 200 communicates with corresponding container instances in respective user-mode modules through the device nodes maintained by the interface driver module 100 .

[0076] The logic driver module 200 is configured to include functional modules that need to be hot-upgraded and can be hot-upgraded. In other words, various hot-upgradeable logic functions can be implemented in the logic driver module 200.

[0077] On the other hand, since the interface of the device node usually does not change, the interface driver module 100 does not need to be hot-upgraded.

[0078] In other words, functions that generally do not require hot upgrades can be implemented in the interface driver module 100, particularly maintenance functions for device nodes that communicate with user-mode container instances. That is, the interface driver module is configured to include a functional module that does not require hot upgrades. Once completed, this module can remain stable without the need for hot upgrades.

[0079] The interface driver module 100 may receive a hot upgrade instruction from the hot upgrade management program in the user mode module.

[0080] In response to the hot upgrade instruction, the interface driver module 100 can perform an upgrade process on the logic driver module 200. For example, the old logic driver module can be deleted (uninstalled) and the new logic driver module can be loaded and installed. Alternatively, the old logic driver module can be modified, such as deleting some old content (such as new function implementation) and / or adding some new content (such as new function implementation).

[0081] Therefore, the hot upgrade of the logic driver module 200 can be conveniently achieved.

[0082] At the same time, since the interface driver module 100 for maintaining the device node communicating with the user-mode container instance is not hot-upgraded, the user is not affected during the hot-upgrade process.

[0083] In addition, before performing the upgrade process on the logic driver module 200 , the interface driver module 100 may call the state saving function of the old logic driver module to save the state in the logic driver module 200 , such as the device node state.

[0084] Accordingly, after performing the upgrade process on the logic driver module 200, the interface driver module 100 calls the state recovery function of the new logic driver module and transfers the saved state, such as the device node state, to the new logic driver module.

[0085] In e.g. Figure 1 In the container architecture shown, the GPU container driver saves the status of multiple device nodes, which can easily cause race conditions in the software, resulting in device driver instability or even kernel crashes.

[0086] In the solution disclosed herein, the interface driver module 100 calls the state saving function of the old logic driver module to save the state, and calls the state restoring function of the new logic driver module to restore the state.

[0087] This allows for smooth recovery of state information, enabling smooth container services even before and after hot upgrades.

[0088] In addition, in order to avoid operation errors, before performing the hot upgrade, or further, before calling the state saving function, the interface driver module 100 can also instruct the old logic driver module 2 to suspend the execution of the core logic function.

[0089] In this way, after the state is saved, the state will no longer change due to the operation of the old logic driver module, which can further avoid the problem of state errors after the hot upgrade is completed.

[0090] In addition, in response to a rollback instruction issued by a user or the system, or in response to a hot upgrade error, the interface driver module 100 can also restore the old logic driver module 2.

[0091] In this way, even if the hot upgrade fails or you want to return to the previous version, you can easily restore the old logical driver module to continue providing container services.

[0092] Reference below Figure 3 The process of performing a hot upgrade in the container service provision solution according to the present disclosure is further described.

[0093] Figure 3 4 is a schematic flow chart of a container service hot upgrade method according to the present disclosure.

[0094] In step S1, when a hot upgrade is required, the hot upgrade management program in the user mode module triggers the hot upgrade process and notifies the interface driver module 100. The interface driver module 100 receives a hot upgrade instruction from the hot upgrade management program.

[0095] 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 from occurring during the hot upgrade process.

[0096] In step S3 , the interface driver module 100 calls the 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.

[0097] In step S4 , the interface driver module 100 performs an upgrade process on the logic driver module 200 .

[0098] For example, the old logic driver module may be uninstalled and a new logic driver module may be loaded. Alternatively, the old logic driver module may be modified, such as deleting some old content (such as new function implementation, etc.) and / or adding some new content (such as new function implementation, etc.).

[0099] In step S5 , the interface driver module 100 calls the state recovery function of the new logic driver module and transfers the state saved in step S3 , such as the device node state, to the new logic driver module (ie, the restored state).

[0100] In step S6 , the interface driver module 100 may continue to run the new logic driver module.

[0101] At this point, the entire hot upgrade process is completed.

[0102] As described above, in the solution for providing container services according to the present disclosure, the original single kernel-mode module is divided into two sub-modules.

[0103] A submodule provides an interface for the user-mode container instance and remains stable, thus avoiding the complex state of maintaining the user-mode interface during hot upgrades.

[0104] Another submodule executes the core logic of the container service, ensuring the core functions of the container service, such as the resource allocator and task scheduler. These functions can be hot-upgraded without affecting the user-mode container services.

[0105] More generally, the kernel mode module may include a first driver module and a second driver module.

[0106] The first driver module may include a functional module in the kernel state module that does not need to be hot-upgraded. For example, the first driver module may be, but is not limited to, Figure 2 The interface driver module 100 shown is used to create and maintain device nodes and connect the device nodes to the corresponding container instances in the user-mode module. In this way, the first driver module provides an interface for the user-mode container instance, that is, the functions that need to communicate with the user-mode module are implemented in the first driver module. It should be understood that the first driver module can also include other functional modules that do not need or do not often need to be hot-upgraded. For example, in Figure 2 If a module in the logic driver module 200 shown, such as the task scheduler 210 , the resource scheduler 220 , or the device driver 230 , does not need or does not frequently need to be hot-upgraded, it can also be configured in the first driver module.

[0107] The second driver module may include the functional modules that need to be hot-upgraded in the kernel mode module, or, in some embodiments, may only include the functional modules that often need to be hot-upgraded. For example, the second driver module may be, but is not limited to, Figure 2 The logic driver module 200 shown 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 need or often need to be hot-upgraded. Or, as mentioned above, in some cases, Figure 2 A module in the logic driver module 200 shown may also not belong to the second driver module but be configured in the first driver module.

[0108] In some embodiments, the logical functions performed by the second driver module may include those in the kernel state that do not need to communicate directly with the container instance in the user state module, so that the logical control functions of the user state container services will not be affected during hot upgrades, such as task scheduling, resource allocation, device drivers, etc.

[0109] In addition, one second driver module may be provided in the kernel mode module, or multiple second driver modules may be provided.

[0110] In the case of providing a plurality of second driving modules, the plurality of second driving modules may perform the same type of functions or different types of functions.

[0111] For example, one or more second driver modules may include a task scheduler for performing task scheduling functions. Another example may include a resource allocator for performing resource allocation functions. Another example may include a device driver for driving a physical device, such as a GPU.

[0112] In this way, one or more second driver modules can be hot-upgraded at a time. In other words, in response to a hot-upgrade instruction for one or more of the plurality of second driver modules, the first driver module can execute the upgrade process for those one or more second driver modules. However, the hot-upgrade process may not be executed for other second driver modules that have not received the hot-upgrade instruction.

[0113] After receiving the hot upgrade instruction sent by the hot upgrade management program in the user state, the first driver module can perform hot upgrade on the corresponding second driver module.

[0114] The process of hot upgrade can be referred to above Figure 3 The described processes are substantially the same, except that the interface driver module is replaced by the first driver module, and the logic driver module is replaced by the second driver module.

[0115] Specifically, the first driver module instructs the old second driver module, which requires a hot upgrade, to suspend its logic functions. The first driver module then calls the old second driver module's state save function to save the function. The first driver module then performs the hot upgrade of the second driver module. The first driver module then calls the new second driver module's state restore function to restore the state. The second driver module then resumes execution, completing the hot upgrade.

[0116] In some embodiments, the disclosed solutions can be implemented as heterogeneous computing solutions, i.e., system computing solutions composed of computing units using different types of instruction sets and architectures. Common types of computing units include CPUs (central processing units), GPUs (graphics processing units), and NPUs (neural network processing units).

[0117] For example, the container service software can be executed in the CPU, including user mode and kernel mode, while the underlying physical device of the container service can be a GPU.

[0118] Figure 4 A schematic diagram of the structure of a computing device that can be used to implement the above-mentioned method for providing container services according to an embodiment of the present invention is shown.

[0119] See also Figure 4, the computing device 400 includes a memory 410 and a processor 420 .

[0120] Processor 420 may be a multi-core processor or may include multiple processors. In some embodiments, processor 420 may include a general-purpose main processor and one or more specialized coprocessors, such as a graphics processing unit (GPU) or a digital signal processor (DSP). In some embodiments, processor 420 may be implemented using customized circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0121] Memory 410 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 420 or other modules of the computer. Permanent storage devices may be readable and writable storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, the permanent storage device uses a large-capacity storage device (such as a magnetic or optical disk, flash memory) as the permanent storage device. In other embodiments, the permanent storage device may be a removable storage device (such as a floppy disk, optical drive). System memory may be a readable and writable storage device or a volatile readable and writable storage device, such as dynamic random access memory. System memory may store some or all instructions and data required by the processor during operation. In addition, 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), and magnetic disks and / or optical disks may also be used. In some embodiments, the memory 410 may include a readable and / or writable removable storage device, 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, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0122] The memory 410 stores executable code. When the executable code is processed by the processor 420 , the processor 420 may execute the method for providing container services described above.

[0123] The apparatus and method for providing container services according to the present invention have been described above in detail with reference to the accompanying drawings.

[0124] In addition, the method according to the present invention may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing the above steps defined in the above method of the present invention.

[0125] Alternatively, the present invention can also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) on which executable code (or computer program, or computer instruction code) is stored. When the executable code (or computer program, or computer instruction code) is executed by a processor of an electronic device (or computing device, server, etc.), the processor executes the various steps of the above-mentioned method according to the present invention.

[0126] Those skilled in the art will 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.

[0127] The flowcharts and block diagrams in the accompanying drawings show the possible implementation architecture, functions and operations of the systems and methods according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0128] While various embodiments of the present invention have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A device for providing container services, comprising a user-mode module and a kernel-mode module, wherein the kernel-mode module comprises: The interface driver module is used to create and maintain device nodes and connect the device nodes to the corresponding container instances in the user-mode module; as well as A logic driver module is used to drive the physical device and perform logic control functions, wherein the logic driver module communicates with the corresponding container instance in the user state module through the device node maintained by the interface driver module, wherein the logic driver module is configured to include a functional module that needs to be hot-upgraded and is capable of hot-upgrading.

2. The device according to claim 1, wherein The interface driver module is configured to include functional modules that do not require hot upgrade.

3. The device according to claim 1, wherein The interface driver module receives a hot upgrade instruction from the 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 device according to claim 3, wherein Before executing the upgrade process of the logic driver module, the interface driver module calls the state saving function of the old logic driver module to save the state in the logic driver module; and After performing the upgrade process on the logic driver module, the interface driver module calls the state recovery function of the new logic driver module and transfers the saved state to the new logic driver module.

5. The device according to claim 4, wherein Before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function; and / or In response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

6. The apparatus according to claim 1, wherein The logic driver module includes: A task scheduler to schedule tasks from each container instance; and / or a resource allocator for allocating resources to physical devices; and / or Device drivers are used to drive physical devices.

7. The apparatus according to any one of claims 1 to 6, wherein: The user-mode module maintains the container instances, and the kernel-mode module enables the container instances to share physical devices; and / or The device provides a GPU container service, and the physical device is a GPU; and / or The device also includes the physical device.

8. A device for providing container services, comprising a user-mode module and a kernel-mode module, wherein the kernel-mode module comprises: The first driver module is used to create and maintain device nodes and connect the device nodes to corresponding container instances in the user-mode module; as well as The second driver module communicates with the corresponding container instance in the user state module through the device node maintained by the first driver module, wherein the second driver module includes a functional module that needs to be hot-upgraded in the kernel state module.

9. The apparatus according to claim 8, wherein The first driver module includes a functional module in the kernel mode module that does not need to be hot-upgraded; and / or The kernel mode module includes a plurality of second driver modules. In response to a hot upgrade instruction for one or more second driver modules among the plurality of second driver modules, the first driver module executes an upgrade process for the one or more second driver modules.

10. A method for providing a container service, comprising: Maintain container instances in user mode; Providing an interface driver module in kernel mode for creating and maintaining device nodes and connecting the device nodes to corresponding container instances in user mode modules; and A logic driver module is provided in the kernel state for driving the physical device and performing logic control functions, wherein the logic driver module communicates with the corresponding container instance in the user state module through the device node maintained by the interface driver module, wherein the logic driver module is configured to include a functional module that needs to be hot-upgraded and is capable of hot-upgrading.

11. The method according to claim 10, wherein: The interface driver module is configured to include functional modules that do not require hot upgrade.

12. The method according to claim 10, further comprising: The interface driver module receives a hot upgrade instruction from the 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 according to claim 12, further comprising: Before executing the upgrade process of the logic driver module, the interface driver module calls the state saving function of the old logic driver module to save the state in the logic driver module; as well as After performing the upgrade process on the logic driver module, the interface driver module calls the state recovery function of the new logic driver module and transfers the saved state to the new logic driver module.

14. The method according to claim 13, further comprising: Before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function; and / or In response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

15. The method according to claim 10, wherein The logic driver module maintains at least one of the following: A task scheduler to schedule tasks from each container instance; and / or a resource allocator for allocating resources to physical devices; and / or Device drivers are used to drive physical devices.

16. The method according to any one of claims 10 to 15, wherein: Kernel mode enables container instances to share physical devices; and / or The container service is a GPU container service, and the physical device is a GPU.

17. A method for thermally upgrading the device according to any one 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 according to claim 17, further comprising: Before executing the upgrade process of the logic driver module, the interface driver module calls the state saving function of the old logic driver module to save the state in the logic driver module; as well as After performing the upgrade process on the logic driver module, the interface driver module calls the state recovery function of the new logic driver module and transfers the saved state to the new logic driver module.

19. The method according to claim 18, further comprising: Before calling the state saving function, the interface driver module further instructs the old logic driver module to suspend execution of the core logic function; and / or In response to a rollback instruction or a hot upgrade error, the interface driver module restores the old logic driver module.

20. The method of claim 17, further comprising: The interface driver module receives a hot upgrade instruction from the hot upgrade management program in the user mode module.

21. A method for providing a container service, comprising: Maintain container instances in user mode; Providing a first driver module in kernel mode for creating and maintaining a device node and connecting the device node to a corresponding container instance in a user mode module; and A second driver module is provided in the kernel state, and communicates with the corresponding container instance in the user state module through the device node maintained by the first driver module, wherein the second driver module includes a functional module that needs to be hot-upgraded in the kernel state.

22. The method according to claim 21, wherein The first driver module includes a functional module in the kernel state that does not need to be hot-upgraded; and / or A plurality of second driver modules are provided in kernel mode. The method further includes: in response to a hot upgrade instruction for one or more second driver modules among the plurality of second driver modules, the first driver module executes an upgrade process for the one or more second driver modules.

23. A computing device comprising: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to perform the method according to any one of claims 10 to 22.

24. A non-transitory machine-readable storage medium having executable codes stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method according to any one of claims 10 to 22.

Images