Container kernel upgrade method and device based on programmable container kernel

Abstract

Embodiments of the present specification provide a container kernel upgrading method and device based on a programmable container kernel. In the method, in response to receiving a container kernel upgrading request, an application container in which a first container kernel to be upgraded is located is frozen; current container state data of the application container is saved, the current container state data including first container kernel state data of the first container kernel and application program state data of all container application programs running in the application container; the application container is restarted using a second container kernel for container kernel upgrading, the container state data of the restarted application container including second container kernel state data of the second container kernel at the time of restarting the application container; corresponding data fields in a data structure of the restarted container state data are updated using the saved current container state data; and in response to completion of the container state data updating, the container application programs in the frozen application container are resumed to run in the restarted application container.

Description

Technical Field

[0001] The embodiments in this specification generally relate to the field of operating systems, and more particularly to container kernel upgrade methods and apparatus based on programmable container kernels. Background Technology

[0002] Application containers (also known as secure containers) are a runtime technology. In application container technology, each application is provided with an independent application container kernel. This kernel is a lightweight operating system that provides an operating system execution environment for the container applications within the application container, but isolates the execution of the container applications from the host operating system. This prevents container applications from directly accessing host resources, thus providing isolation protection between application containers and the host, or between application containers themselves. When the application container kernel provides system services to container applications, if operating system vulnerabilities are discovered or new features are added, an application container kernel upgrade is required. Summary of the Invention

[0003] In view of the above, embodiments of this specification provide a container kernel upgrade method and apparatus based on a programmable container kernel. Using this container kernel upgrade method and apparatus, a programmable container kernel can be used to upgrade the container kernel, thereby enabling customized modifications to the container kernel during the upgrade process.

[0004] According to one aspect of the embodiments of this specification, a container kernel upgrade method based on a programmable container kernel is provided, comprising: in response to receiving a container kernel upgrade request, freezing an application container containing a first container kernel to be upgraded; saving current container state data of the application container, the current container state data including first container kernel state data corresponding to the first container kernel and application state data of all applications running in the application container, and having a first data structure defined by the first container kernel; restarting the application container using a second container kernel for container kernel upgrade, the restarted application container's restarted container state data including second container kernel state data corresponding to the second container kernel at the time the application container restarts, and having a second data structure defined by the second container kernel; updating corresponding data fields in the data structure of the restarted container state data using the saved current container state data; and in response to the container state data update being completed, resuming the running of container applications in the frozen application container in the restarted application container.

[0005] Optionally, in one example of the above aspects, saving the current container state data of the application container may include: saving the current container state data in the form of a container snapshot in a data file, the container snapshot being generated by serializing the current container state data; updating the restarted container state data using the saved current container state data includes: deserializing the container snapshot in the data file to restore the saved current container state data; and updating the corresponding data field in the data structure of the restarted container state data using the restored current container state data.

[0006] Optionally, in one example of the above aspects, the current container state data and the restarted container state data are organized as a data tree. Updating the corresponding data field in the data structure of the restarted container state data using the recovered current container state data may include: starting from the root data node of the data tree of the restarted container state data, performing the following update process node by node from top to bottom: determining whether the current data node has a corresponding data node in the data tree of the current container state data; in response to the absence of a corresponding data node in the data tree of the current container state data, not updating the data field portion of the current data node; in response to the presence of a corresponding data node in the data tree of the current container state data, determining whether the current data node has undergone a data field change relative to the corresponding data node; in response to the absence of a data field change relative to the corresponding data node, directly updating the data field information of the current data node using the data field information of the corresponding data node; in response to a data field change relative to the corresponding data node, using the data field information of the corresponding data node to update the data field information of the current data node according to a specified strategy.

[0007] Alternatively, in one example of the above aspects, the data file includes a memory file or a disk file.

[0008] Optionally, in one example of the above aspects, before saving the current container state data of the application container, the container kernel upgrade method may further include: stopping the message receiving function of the application container's driver cache, and handing over the messages in the driver cache to the first container kernel.

[0009] Optionally, in one example of the above aspects, the container kernel upgrade method may further include discarding all cached data of the application container before saving the current container state data of the application container.

[0010] Optionally, in one example of the above aspects, before saving the current container state data of the application container, the container kernel upgrade method may further include: performing anomaly detection on the container state data corresponding to each container component in the current container state data of the application container; and / or recording the system startup time and current real-time time of the application container.

[0011] Optionally, in one example of the above aspects, after updating the restart container state data using the saved current container state data, the container kernel upgrade method may further include: reopening the host file that is set to open in the current container state data.

[0012] Optionally, in one example of the above aspects, after updating the restart container state data using the saved current container state data, the container kernel upgrade method may further include: determining the system startup time of the application container; and / or starting the hardware transceiver function of the application container.

[0013] According to another aspect of the embodiments of this specification, a container kernel upgrade apparatus based on a programmable container kernel is provided, comprising: a container freezing unit, which, in response to receiving a container kernel upgrade request, freezes an application container containing a first container kernel to be upgraded; a container state data saving unit, which saves current container state data of the application container, the current container state data including first container kernel state data corresponding to the first container kernel and application state data of all applications running in the application container, and having a first data structure defined by the first container kernel; a container restart unit, which restarts the application container using a second container kernel for container kernel upgrade, the restarted application container's restarted container state data including second container kernel state data corresponding to the second container kernel at the time of restarting the application container, and having a second data structure defined by the second container kernel; a container state data updating unit, which updates the corresponding data field in the data structure of the restarted container state data using the saved current container state data; and an application running recovery unit, which, in response to the completion of the container state data update, resumes the running of the container applications in the frozen application container in the restarted application container.

[0014] Optionally, in one example of the above aspects, the container state data storage unit saves the current container state data in a data file as a container snapshot, the container snapshot being generated by serializing the current container state data. The container state data update unit may include: a container state data recovery module, which performs data deserialization on the container snapshot in the data file to recover the current container state data; and a container state data update module, which uses the current container state data to update the corresponding data fields in the data structure of the restarted container state data.

[0015] Optionally, in one example of the above aspects, the current container state data and the restarted container state data are organized as a data tree. The container state data update module is configured to: starting from the root data node of the data tree of the restarted container state data, perform the following update process node by node from top to bottom: determine whether the current data node has a corresponding data node in the data tree of the current container state data; in response to the absence of a corresponding data node in the data tree of the current container state data, not update the data field portion of the current data node; in response to the presence of a corresponding data node in the data tree of the current container state data, determine whether the current data node has undergone a data field change relative to the corresponding data node; in response to the absence of a data field change relative to the corresponding data node, directly update the data field information of the current data node using the data field information of the corresponding data node; in response to a data field change relative to the corresponding data node, use the data field information of the corresponding data node to update the data field information of the current data node according to a specified strategy.

[0016] Optionally, in one example of the above aspects, the container kernel upgrade apparatus may further include: a global preprocessing unit, which, before saving the current container state data of the application container, stops the message receiving function of the driver cache of the application container and hands over the messages in the driver cache to the first container kernel.

[0017] Optionally, in one example of the above aspects, the container kernel upgrade apparatus may further include a post-processing unit that, after updating the restart container state data using the saved current container state data, reopens the host file that is set to be open in the current container state data.

[0018] According to another aspect of the embodiments of this specification, a container kernel upgrade apparatus based on a programmable container kernel is provided, comprising: at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory, wherein the at least one processor executes the computer program to implement the container kernel upgrade method based on a programmable container kernel as described above.

[0019] According to another aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores executable instructions, which, when executed, cause a processor to perform the container kernel upgrade method based on a programmable container kernel as described above.

[0020] According to another aspect of the embodiments of this specification, a computer program product is provided, including a computer program that is executed by a processor to implement the container kernel upgrade method based on a programmable container kernel as described above. Attached Figure Description

[0021] A further understanding of the nature and advantages of this specification can be achieved by referring to the following figures. In the figures, similar components or features may have the same reference numerals.

[0022] Figure 1 An example schematic diagram of a computer system architecture according to an embodiment of this specification is shown.

[0023] Figure 2 An example flowchart of a container kernel upgrade method based on a programmable container kernel according to an embodiment of this specification is shown.

[0024] Figure 3 An example schematic diagram of the data structure for container state data according to an embodiment of this specification is shown.

[0025] Figure 4 An example flowchart of a container state data update process according to an embodiment of this specification is shown.

[0026] Figure 5 An example flowchart of a container kernel upgrade method based on a programmable container kernel, according to another embodiment of this specification, is shown.

[0027] Figure 6 A schematic diagram illustrating an example of a container snapshot generation process for the current container state data of a first container kernel to be upgraded, according to an embodiment of this specification.

[0028] Figure 7 A schematic diagram illustrating an example of a container state data update process for a second container kernel used for container kernel upgrades according to an embodiment of this specification is shown.

[0029] Figure 8 An example block diagram of a container kernel upgrade apparatus based on a programmable container kernel according to an embodiment of this specification is shown.

[0030] Figure 9 An example block diagram of a container kernel upgrade apparatus based on a programmable container kernel according to another embodiment of this specification is shown.

[0031] Figure 10 An example schematic diagram of a container kernel upgrade apparatus based on a computer system according to an embodiment of this specification is shown. Detailed Implementation

[0032] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the various examples. For example, the described methods may be performed in a different order than described, and steps may be added, omitted, or combined. Furthermore, features described in some examples may be combined in other examples.

[0033] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0034] One approach to upgrading an application container kernel is to install a new version of the kernel (i.e., the operating system) and then restart the kernel to switch to the new version. This approach requires shutting down or migrating the running container application, reloading the kernel (including initializing hardware resources), and then restarting the application. This results in a prolonged interruption of the container application's operation, especially in application scenarios where container initialization and startup are time-consuming.

[0035] To address the aforementioned issues, an application container kernel supporting CRIU (Checkpoint / Restore In Userspace) technology is proposed. This kernel can leverage CRIU to support cross-version container kernel upgrades. CRIU allows pausing a group of applications (at the application container level), saving all state data of this group of applications to a disk file, and then restoring the running state of the group of applications from the disk file when needed, allowing the applications to continue running. This achieves requirements such as application container migration and application state snapshots.

[0036] However, in CRIU, the saving / restoration of state data relies entirely on the application container kernel's API / SystemCall (system call). This only allows for the restoration of the container application running within the application container, without affecting the kernel itself, thus preventing the restoration and upgrading of customized application container kernels. In this specification, the term "customized application container kernel" is also referred to as "programmable application container kernel." A programmable container kernel refers to a kernel whose functions and data structures are customized and updated using programming techniques.

[0037] In view of the above, embodiments of this specification provide a container kernel upgrade method based on a programmable container kernel. In this container kernel upgrade scheme, the current container state data of the first container kernel to be upgraded is saved. The saved current container state data includes the first container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container, and is organized into a first data structure defined by the container kernel version of the first container kernel. After restarting the application container using a second container kernel obtained through the code logic of the programmable container kernel, the restarted application container's restarted container state data can have a second data structure defined by the container kernel version of the second container kernel. Then, the corresponding data fields in the second data structure of the restarted container state data are updated using the saved current container state data, and in response to the completion of the container state data update, the frozen container application is re-run in the restarted application container, thereby completing the recovery and upgrade of the customized application container kernel.

[0038] The following describes, with reference to the accompanying drawings, a container kernel upgrade method and apparatus based on a programmable container kernel according to embodiments of this specification.

[0039] Figure 1 An example schematic diagram of a computer system architecture 100 according to an embodiment of this specification is shown.

[0040] like Figure 1As shown, the computer system 100 includes underlying hardware 110, host kernel 120, and application container 130.

[0041] The underlying hardware 110 provides the hardware environment required for the application to run. The underlying hardware 110 may include, for example, a processor and storage devices. In some embodiments, examples of processors may include, but are not limited to, one or more combinations of: a central processing unit (CPU), an application-specific integrated circuit (ASIC), a special-purpose instruction set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a microcontroller unit, a reduced instruction set computer (RISC), a microprocessor, etc. In some embodiments, storage devices may include, but are not limited to: mass storage, removable storage, volatile read-write memory, read-only memory (ROM), etc., or any combination thereof. Exemplary mass storage may include a hard disk, an optical disk, a solid-state drive, etc. Exemplary removable storage may include a flash drive, a floppy disk, an optical disk, a memory card, a compact disk, a magnetic tape, etc. Exemplary volatile read-only memory may include random access memory (RAM). Exemplary RAMs may include Dynamic RAM (DRAM), Double Data Rate Synchronous Dynamic RAM (DDRSDRAM), Static RAM (SRAM), Thyristor RAM (T-RAM), and Zero Capacitor RAM (Z-RAM), etc. Exemplary ROMs may include Mask ROM (MROM), Programmable ROM (PROM), Erasable Programmable ROM (PEROM), Electronically Erasable Programmable ROM (EEPROM), Optical Disc ROM (CD-ROM), and Digital Universal Disk ROM, etc. In some embodiments, the storage device 140 may be implemented on a cloud platform. By way of example only, the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-layer cloud, etc., or any combination thereof.

[0042] The host kernel 120 is the operating system kernel that runs on the underlying hardware 110. The host kernel 120 is a first-layer software extension based on the underlying hardware 110, responsible for managing the computer system's processes, memory, device drivers, file systems, and network systems, thus determining the computer system's performance and stability. Examples of host kernels 120 may include, but are not limited to, the Windows kernel and the Linux kernel.

[0043] Application container 130 runs on top of host kernel 120. Each application container 130 has an independent container kernel 131. Container kernel 131 can provide an isolated operating system execution environment for one or more container applications 133 running in application container 130, thereby isolating the execution of container applications 133 from host kernel 120, thus preventing container applications from directly accessing host resources, thereby providing isolation protection between application container 130 and host kernel 120 or between another application container 130. In some embodiments, examples of container kernel 131 may include, but are not limited to, operating system kernels such as Windows kernel, Linux kernel, etc. More preferably, container kernel 131 may include an operating system kernel that supports kernel state saving / restoration through serialization / deserialization.

[0044] The host kernel 120 has a hypervisor 121. The processor in the hardware architecture operates in root mode and non-root mode. Non-root mode is used to run virtual machines, and configuration, creation, and entry are handled by the root mode. The application container 130 is treated as a process (container process) by the host kernel 120. The container process can enter non-root mode through the hypervisor. In non-root mode, the container kernel 133 provides OS functionality and then provides a standard application runtime environment compatible with the host operating system (e.g., Linux), allowing container applications within the application container to run in an OS environment similar to the host operating system. Furthermore, the computer system 100 may also include other processes that the host kernel 120 can support running, such as file agent processes. These other processes can run, for example, in root mode or non-root mode.

[0045] Figure 2 An example flowchart of a container kernel upgrade method 200 based on a programmable container kernel according to an embodiment of this specification is shown.

[0046] like Figure 2 As shown in step 210, in response to receiving a container kernel upgrade request, the application container containing the first container kernel to be upgraded is frozen. After the application container is frozen, the runtime environment of the application container is stopped, for example, the running of processes, message sending and receiving, and file reading and writing within the application container are stopped. Furthermore, the container application within the frozen application container no longer runs and no longer consumes OS resources provided by the container kernel.

[0047] At step 220, the current container state data of the application container (hereinafter referred to as the first container state data) is saved. The saved first container state data includes the container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container. The first container state data has a first data structure defined by the container kernel version (e.g., code logic) of the first container kernel. The container kernel mentioned in the embodiments of this specification is a programmable container kernel. Each container kernel can be programmed to have the data structures defined by the current container kernel version, thereby organizing the container state data saved by the container kernel according to the defined data structures. For example, when an application runs within the application container where the container kernel resides, the container kernel saves process management data structures, memory management data structures, file management data structures, and the application's own data (such as the application's memory and code) for each application. In addition, the container kernel also saves some global data structures shared by multiple applications, such as control groups and shared memory. The above-mentioned data saved by the container kernel is called container state data, and the saved container state data is organized into the data structures defined by the corresponding container kernel version.

[0048] The container state data of an application container may include, but is not limited to: global configuration information, kernel state information, file system, memory management, namespace, shared memory, control groups (cgroups), network connection information, cached packet process state (context), process memory, etc.

[0049] Figure 3 An example schematic diagram of the data structure for container state data according to an embodiment of this specification is shown.

[0050] like Figure 3As shown, all container state data of an application container is organized into a tree. The root data node (also called the root data member) is the container kernel. First-level downstream data nodes include tasks, file systems, namespaces, shared memory, and networks. Second-level downstream data nodes are further subdivisions of the first-level data nodes. For example, second-level data nodes for tasks include memory, files, and running status. Second-level data nodes for file systems include memory file systems, pipe file systems, and disk file systems. Second-level data nodes for namespaces include User namespace, PID namespace, Mount namespace, and Net namespace. Second-level data nodes for shared memory include Unix System V shared memory and POSIX (The Portable Operating System Interface) shared memory. Second-level data nodes for networks include network devices, routing configurations, protocol stack configurations, and protocol stack packets. Furthermore, each second-level data node also has corresponding downstream data nodes. There are mutual references between the branches of the data tree; for example, processes may open files.

[0051] In some embodiments, when saving the state of the data tree of the first container state data, a container snapshot is generated by serializing the first container state data. Subsequently, the generated container snapshot is written to a data file, thereby saving the first container state data in the data file as a container snapshot. In some embodiments, the container snapshot can be written to a disk file. In some embodiments, the container snapshot can be written to a memory file. Since the write / read speed of memory files is much higher than that of disk files, the read / write time of the container snapshot can be shortened, thereby shortening the container kernel upgrade time. The data serialization process for container state data can be implemented using any suitable data serialization scheme in the art.

[0052] Back Figure 2In section 230, the frozen application container is restarted using a second container kernel used for container kernel upgrades. It should be noted that "application container restart" here only includes restarting the application container's runtime environment and does not restore the running of any frozen applications within the application container. The second container kernel can be obtained, for example, by programmatically updating the container kernel, thereby adding new kernel features (e.g., adding a new system) or implementing other modifications to the container kernel. In the updated container kernel version of the second container kernel, the data structure corresponding to the container kernel (i.e., the data structure when the container state data is saved) is redefined, for example, by modifying the data nodes, the data type of the data nodes, and / or the data field values, thereby changing the data structure of the container state data from the first data structure to the second data structure, or redefining a new second data structure. In this specification, both the "first container kernel" and the "second container kernel" are programmable container kernels. The second container kernel can read and modify the first container state data for use in the second container kernel, thereby achieving the programming effect of the container kernel's runtime logic. For example, by comparing the data structure types in the first container state data and the data structure types in the second container state data, the addition and deletion of members of the corresponding data structure type in the second container state data are identified, and the corresponding data fields in the second container state data are automatically restored to the data field values ​​stored in the first container state data. After restarting the frozen application container using the second container kernel, the restarted application container restores its runtime environment. Since all applications in the application container are not started after the application container restarts, the restarted container state data obtained after restarting the application container does not contain any application state data, and the restarted container state data has a second data structure that is different from the first data structure defined by the container kernel version to be upgraded. For example, the data nodes in the data trees of the first container state data and the second container state data are different, the data fields defined by the data structure types of the data nodes are different, and / or the data field values ​​are different, etc.

[0053] At 240, the corresponding data field in the data structure of the restarted application container's restarted container state data (hereinafter referred to as the second container state data) is updated using the saved first container state data.

[0054] In some embodiments, the container snapshot in the data file is deserialized to recover the saved first container state data. Then, the corresponding data fields in the data structure (second data structure) of the second container state data are updated using the recovered first container state data.

[0055] Figure 4 An example flowchart of a container state data update process 400 according to an embodiment of this specification is shown. Figure 4In the example, the state data of the first container and the state data of the second container are organized into a data tree.

[0056] exist Figure 4 In the example flow, starting from the root data node of the data tree of the second container state data, the following update process is executed cyclically from top to bottom, node by node.

[0057] During each cycle update, at 420, it is determined whether the current data node in the data tree of the second container state data has a corresponding data node in the data tree of the first container state data.

[0058] In response to the absence of a corresponding data node in the data tree of the first container state data, at 430, the data fields of the current data node are not updated, and then proceed to 470.

[0059] In response to the existence of a corresponding data node in the data tree of the first container state data, at 440, it is determined whether the data fields of the current data node have changed relative to the corresponding data node. For example, the data structure type of the data node is stored in both the first and second container state data; by comparing the data structure types of the data nodes, it can be identified whether new data fields have been added or old data fields have been deleted. In response to the absence of data field changes for the current data node relative to the corresponding data node, at 450, the data field information of the current data node is directly updated using the data field information of the corresponding data node in the data tree of the first container state data, and then proceeds to 470.

[0060] In response to a change in data fields of the current data node relative to its corresponding data node, at step 460, the data field information of the current data node is updated according to a specified strategy using the data field information of the corresponding data node in the data tree of the first container state data. For example, suppose the data field information of a data node has been modified (data fields added or deleted), such as having the same name but different types. In this case, customized recovery can be supported. For example, the data field information of the corresponding data node in the data tree of the first container state data is first restored to a temporary variable. Then, the data field information of the current data node in the data tree of the second container state data is reconstructed based on the temporary variable. Subsequently, the process proceeds to step 470.

[0061] At step 470, it is determined whether the update of data nodes in the data tree for the second container state data is complete, i.e., whether the above update process has been completed for all data nodes. If there are any unupdated data nodes, then at step 480, the next data node is selected from the data tree of the second container state data. For example, a traversal method can be used to determine the next data node. Then, the processing steps 420 to 470 above are repeated for the selected next data node. If there are no unupdated data nodes, then at step 490, the container state data update is complete.

[0062] Back Figure 2 In response to the completion of container state data updates, at 250, the container application in the frozen application container is re-run in the restarted application container, thereby realizing the programmable container kernel upgrade process.

[0063] Using the above-described container kernel upgrade scheme based on a programmable container kernel, the current container state data of the first container kernel to be upgraded is saved. The saved current container state data has a first data structure defined by the container kernel version of the first container kernel, and includes the first container kernel state data corresponding to the first container kernel and the application state data of all applications running in the application container. After restarting the application container using the second container kernel obtained by programming the container kernel code version (e.g., code logic), the corresponding data field in the second data structure of the restarted container state data is updated using the saved current container state data. This allows the upgraded second container kernel to restore the state information of the container applications running in the first container kernel before the upgrade and to have the new features of the programmed second container kernel, thereby completing the recovery and upgrade of the customized container kernel.

[0064] Furthermore, the aforementioned container kernel upgrade scheme enables rapid upgrades to the container kernel logic while quickly restoring container applications previously running within the container kernel. During this upgrade process, there is no need to stop, migrate, or start the container application, thus achieving container kernel upgrades with virtually no interruption (seconds).

[0065] Figure 5 An example flowchart of a container kernel upgrade method 500 based on a programmable container kernel according to an embodiment of this specification is shown. Figure 5 The embodiment shown is Figure 2 Modifications to the embodiments shown are illustrated.

[0066] like Figure 5 As shown in step 510, in response to receiving a container kernel upgrade request, the application container containing the first container kernel to be upgraded is frozen.

[0067] In step 520, global preprocessing is performed on the application container.

[0068] In some embodiments, during global preprocessing, the message receiving function of the application container's driver cache is stopped, and the messages in the driver cache are handed over to the first container kernel. After receiving the handed-over messages, the first container kernel can cache the received messages through state saving, thereby maintaining the consistency of the software and hardware states, ensuring that there is no unprocessed data in the hardware, and thus avoiding data loss due to data being cached in the hardware during container kernel programming / upgrade.

[0069] In some embodiments, during global preprocessing, all cached data of the application container may be discarded, for example, cached data in the file cache may be discarded, in order to accelerate the state preservation process of container kernel data.

[0070] In section 530, pre-processing is performed on application containers. It's important to note that this pre-processing is done on a per-component basis within the application container. For example, file data structures within the container kernel are processed using the same pre-processing logic as file data structures, and so on, as are memory data, process data, and so on.

[0071] In some embodiments, during preprocessing, anomaly detection can be performed on the container state data corresponding to each container component in the current container state data of the application container. Once a data anomaly is detected, the container kernel upgrade process is stopped.

[0072] In some embodiments, during preprocessing, the system startup time and current real-time of the application container can also be recorded. For example, the system startup time m0 and the current real-time time r0 of the application container can be recorded. In this way, during the data recovery process, the time deviation offset = r1 - r0 of the system startup time can be calculated by the difference between the new real-time time r1 and the recorded real-time time r0, so that the recovered system startup time is a continuous time.

[0073] In step 540, the current container state data of the application container is saved. This saved current container state data includes the container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container. Furthermore, the current container state data uses the first data structure defined by the container kernel version of the first container kernel. The process of saving container state data can be referenced above. Figure 2 The description of 220.

[0074] Figure 6This illustration shows an example diagram of the container snapshot generation process for the current container state data (partial data structure) of the first container kernel to be upgraded, according to an embodiment of this specification. Figure 6 The example shown illustrates the container snapshot generation process for the container state data "Cgroup struct" in the lower left corner. Figure 6 In the example, the container state data “Cgroupstruct” has two parameters, namely “CpuNum” and “TotalMem”, with values ​​of “4” and “858993592” respectively.

[0075] In step 550, the frozen application container is restarted using a second container kernel used for container kernel upgrades. The restarted application container's restarted container state data includes the second container kernel state data corresponding to the second container kernel at the time of application container restart, and the restarted container state data has a second data structure defined by the container kernel version of the second container kernel.

[0076] In step 560, the corresponding data field in the data structure of the restarted application container's container state data is updated using the saved current container state data. The process of updating container state data can be referenced above. Figure 2 240 and Figure 4 The description.

[0077] Figure 7 A schematic diagram illustrating an example of the process for updating container state data (partial data structures) of a second container kernel according to an embodiment of this specification is shown.

[0078] Figure 7 The example shown is for Figure 6 The example shown illustrates the container state data update process. Figure 7 In the example, the container state data "Cgroup struct" is modified to have three parameters: "CpuNum", "TotalMem" and "Name", and the updated values ​​are "4", "858993592" and a new data field "TestAfterLoad".

[0079] In 570, post-processing is performed on the restarted application container.

[0080] In some embodiments, during post-processing, the host file that is set to open in the saved current container state data can be reopened.

[0081] In some embodiments, the system startup time of the application container can be determined during post-processing. The time offset of the system startup time, offset = r1 - r0, can be calculated using the difference between the new real-time time r1 and the recorded real-time time r0, thereby recovering the continuous system startup time. In some embodiments, the hardware transceiver function of the application container can be activated.

[0082] In response to the completion of container state data updates and post-processing, at 580, the container application in the frozen application container is re-run in the restarted application container, thereby realizing the programmable container kernel upgrade process.

[0083] As per the above reference Figures 1 to 7 A container kernel upgrade method based on a programmable container kernel, according to embodiments of this specification, is described.

[0084] Figure 8 An example block diagram of a container kernel upgrade apparatus 800 based on a programmable container kernel according to an embodiment of this specification is shown. Figure 8 As shown, the container kernel upgrade device 800 includes a container freezing unit 810, a container state data saving unit 820, a container restart unit 830, a container state data updating unit 840, and an application running recovery unit 850.

[0085] The container freeze unit 810 is configured to freeze the application container containing the first container kernel to be upgraded in response to receiving a container kernel upgrade request. The operation of the container freeze unit 810 can be referenced above. Figure 2 The operation described in 210.

[0086] The container state data storage unit 820 is configured to store the current container kernel data of the application container. This current container state data includes the container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container. Furthermore, the current container state data has a first data structure defined by the container kernel version of the first container kernel. The operation of the container state data storage unit 820 can be referenced above. Figure 2 The operation described in 220.

[0087] Container restart unit 830 is configured to restart application containers using a second container kernel used for container kernel upgrades. The restarted application container's restarted container state data includes the second container kernel state data corresponding to the second container kernel at the time of application container restart, and the restarted container state data has a second data structure defined by the container kernel version of the second container kernel. The operation of container restart unit 830 can be referenced above. Figure 2 The operation described in 230.

[0088] The container state data update unit 840 is configured to update the corresponding data field in the data structure of the restarted application container's restart container state data using the saved current container state data. The operation of the container state data update unit 840 can be referenced above. Figure 2 The operation described in 240.

[0089] The application runtime recovery unit 850 is configured to resume the execution of the frozen container application in the restarted application container in response to the completion of container state data updates. The operation of the application restart unit 850 can be referenced above. Figure 2 The operation described in 250.

[0090] In some embodiments, the container state data storage unit 820 can save the current container state data in a data file as a container snapshot, which is generated by serializing the current container state data. Correspondingly, the container state data update unit 840 may include a container state data recovery module and a container state data update module. The container state data recovery module is configured to deserialize the container snapshot in the data file to recover the current container state data. Then, the container state data update module uses the recovered current container state data to update the corresponding data field in the data structure of the restarted container state data.

[0091] In some embodiments, the current container state data and the restarted container state data are organized as a data tree. Accordingly, the container state data update module is configured to perform the following update process from top to bottom, node by node, starting from the root data node of the restarted container state data data tree: determine whether the current data node has a corresponding data node in the current container state data data tree; in response to the absence of a corresponding data node in the current container state data data tree, not update the data field portion of the current data node; in response to the presence of a corresponding data node in the current container state data data tree, determine whether the current data node has undergone data field changes relative to the corresponding data node; in response to the absence of data field changes relative to the corresponding data node, directly update the data field information of the current data node using the data field information of the corresponding data node; in response to the occurrence of data field changes relative to the corresponding data node, update the data field information of the current data node according to a specified strategy using the data field information of the corresponding data node.

[0092] Figure 9 An example block diagram of a container kernel upgrade apparatus 900 based on a programmable container kernel according to another embodiment of this specification is shown. Figure 9 The illustrated embodiment is Figure 8Modifications to the embodiments shown are illustrated.

[0093] like Figure 9 As shown, the container kernel upgrade device 900 includes a container freezing unit 910, a global preprocessing unit 920, a preprocessing unit 930, a container state data saving unit 940, a container restart unit 950, a container state data updating unit 960, a postprocessing unit 970, and an application running recovery unit 980.

[0094] The container freeze unit 910 is configured to freeze the application container containing the first container kernel to be upgraded in response to receiving a container kernel upgrade request. The operation of the container freeze unit 910 can be referenced above. Figure 5 The operation described in 510.

[0095] The global preprocessing unit 920 is configured to stop the message receiving function of the application container's driver cache before saving the current container state data of the application container, and to hand over the messages in the driver cache to the first container kernel.

[0096] In some embodiments, the global preprocessing unit 920 may also be configured to discard all cached data of the application container, for example, discard cached data in the file cache, to accelerate the state preservation process of the container kernel data.

[0097] The preprocessing unit 930 is configured to perform anomaly detection on the container state data corresponding to each container component of the application container's current container state data. Once a data anomaly is detected, the container kernel upgrade process is stopped. The operation of the preprocessing unit 930 can be referenced above. Figure 5 The operation described in 530.

[0098] In some embodiments, the preprocessing unit 930 may also be configured to record the system startup time and current real-time of the application container. For example, the preprocessing unit 930 may record the system startup time m0 and the current real-time r0 of the application container. In this way, during the data recovery process, the time deviation offset = r1 - r0 of the system startup time can be calculated by the difference between the new real-time r1 and the recorded real-time r0, so that the recovered system startup time is a continuous time.

[0099] The container state data storage unit 940 is configured to store the current container state data of the application container. This current container state data includes the container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container. Furthermore, the current container state data has a first data structure defined by the container kernel version of the first container kernel. The operation of the container state data storage unit 940 can be referenced above. Figure 5 The operation described in 540.

[0100] Container restart unit 950 is configured to restart application containers using a second container kernel used for container kernel upgrades. The restarted application container's restarted container state data includes the second container kernel state data corresponding to the second container kernel at the time of application container restart, and the restarted container state data has a second data structure defined by the container kernel version of the second container kernel. The operation of container restart unit 950 can be referenced above. Figure 5 The operation described in 550.

[0101] The container state data update unit 960 is configured to update the corresponding data field in the data structure of the restarted application container's restart container state data using the saved current container state data. The operation of the container state data update unit 960 can be referenced above. Figure 5 The operation described in 560.

[0102] The post-processing unit 970 is configured to reopen the host file that was set as open in the saved current container state data after the container state data update is complete. The operation of the post-processing unit 970 can be referenced above. Figure 5 The operation of 570.

[0103] In some embodiments, the post-processing unit 970 can be configured to determine the system startup time of the application container. The system startup time offset = r1 - r0 can be calculated using the difference between the new real-time time r1 and the recorded real-time time r0, thereby recovering the continuous system startup time. In some embodiments, the hardware transceiver function of the application container can be activated.

[0104] The application runtime recovery unit 980 is configured to resume the execution of the frozen container application in the restarted application container in response to the completion of container kernel data updates and the completion of post-processing by the post-processing unit 970. The operation of the application restart unit 980 can be referenced above. Figure 5 The operation described in 580.

[0105] It should be noted that in other embodiments of this specification, the following can also be applied: Figure 9 Some components in the embodiments shown have been modified or removed.

[0106] As per the above reference Figures 1 to 9 This specification describes a method and apparatus for upgrading the container kernel of an application container according to embodiments thereof. The container kernel upgrade apparatus described above can be implemented in hardware, software, or a combination of hardware and software.

[0107] Figure 10 An example schematic diagram of a container kernel upgrade apparatus 1000 based on a computer system according to an embodiment of this specification is shown. Figure 9 As shown, the container kernel upgrade apparatus 1000 may include at least one processor 1010, a memory (e.g., non-volatile memory) 1020, a RAM 1030, and a communication interface 1040, and the at least one processor 1010, memory 1020, RAM 1030, and communication interface 1040 are connected together via a bus 1060. The at least one processor 1010 executes at least one computer-readable instruction (i.e., the elements implemented in software described above) stored or encoded in memory.

[0108] In one embodiment, computer-executable instructions are stored in memory, which, when executed, cause at least one processor 1010 to: freeze the application container containing the first container kernel to be upgraded in response to receiving a container kernel upgrade request; save the current container state data of the application container, the current container state data including the first container kernel state data corresponding to the first container kernel and the application state data of all applications running within the application container, and having a first data structure defined by the container kernel version of the first container kernel; restart the application container using a second container kernel for container kernel upgrade, the restarted application container's restarted container state data including the second container kernel state data corresponding to the second container kernel at the time of application container restart, and having a second data structure defined by the container kernel version of the second container kernel; update the corresponding data field in the data structure of the restarted container state data using the saved current container state data; and, in response to the completion of the container state data update, resume running the container applications in the frozen application container in the restarted application container.

[0109] It should be understood that the computer-executable instructions stored in memory, when executed, cause at least one processor 1010 to perform the above-described combinations in the various embodiments of this specification. Figures 1-9 The description includes various operations and functions.

[0110] According to one embodiment, a program product, such as a machine-readable medium (e.g., a non-transitory machine-readable medium), is provided. The machine-readable medium may have instructions (i.e., the elements implemented in software as described above), which, when executed by a machine, cause the machine to perform the above-described combinations of the various embodiments of this specification. Figures 1-9 The various operations and functions described. Specifically, a system or apparatus equipped with a readable storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer or processor of the system or apparatus to read and execute the instructions stored in the readable storage medium.

[0111] In this case, the program code itself, which can be read from a readable medium, can perform the functions of any of the above embodiments. Therefore, the machine-readable code and the readable storage medium storing the machine-readable code constitute a part of the present invention.

[0112] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer or the cloud via a communication network.

[0113] According to one embodiment, a computer program product is provided, the computer program product including a computer program, which, when executed by a processor, causes the processor to perform the above-described combinations of the various embodiments of this specification. Figures 1-9 The description includes various operations and functions.

[0114] Those skilled in the art will understand that the various embodiments disclosed above can be modified and varied without departing from the spirit of the invention. Therefore, the scope of protection of this invention should be defined by the appended claims.

[0115] It should be noted that not all steps and units in the above process and system structure diagrams are mandatory; some steps or units can be omitted according to actual needs. The execution order of each step is not fixed and can be determined as needed. The device structure described in the above embodiments can be a physical structure or a logical structure; that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

[0116] In the above embodiments, the hardware units or modules can be implemented mechanically or electrically. For example, a hardware unit, module, or processor may include permanent dedicated circuitry or logic (such as a dedicated processor, FPGA, or ASIC) to perform the corresponding operation. The hardware unit or processor may also include programmable logic or circuitry (such as a general-purpose processor or other programmable processor), which can be temporarily configured by software to perform the corresponding operation. The specific implementation method (mechanical, dedicated permanent circuitry, or temporarily configured circuitry) can be determined based on cost and time considerations.

[0117] The specific embodiments described above with reference to the accompanying drawings are exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the scope of the claims. The term "exemplary" as used throughout this specification means "serving as an example, instance, or illustration" and does not imply that it is "preferred" or "advantageous" compared to other embodiments. Specific details are included to provide an understanding of the described techniques. However, these techniques can be practiced without these specific details. In some instances, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0118] The foregoing description of this disclosure is provided to enable any person skilled in the art to implement or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but is consistent with the widest scope of the principles and novel features disclosed herein.

Claims

1. A container kernel upgrade method based on programmable container kernels, comprising: in response to receiving a container kernel upgrade request, freezing an application container in which a first container kernel to be upgraded resides; saving current container state data of the application container, the current container state data including first container kernel state data corresponding to the first container kernel and application state data of all application programs running in the application container, and having a first data structure defined by the first container kernel; restarting the application container with a second container kernel for container kernel upgrade, the restarted application container having restarted container state data including second container kernel state data corresponding to the second container kernel at the time of the application container restart, and having a second data structure defined by the second container kernel; updating corresponding data fields in the data structure of the restarted container state data using the saved current container state data; and in response to completion of the container state data update, resuming running of container application programs in the restarted application container that were running in the frozen application container, wherein the first and second container kernels are programmable container kernels, and the second container kernel is obtained by programmatically updating the first container kernel in version, the programmable container kernel including a container kernel whose supported functions and data structure can be customized using programming means, and which can be programmed to have a data structure defined by a current container kernel version so that container state data saved by the container kernel is organized in the defined data structure. The saving of the current container state data of the application container includes:

2. The in-container kernel upgrade method of claim 1, wherein, saving the current container state data in a container snapshot form in a data file, the container snapshot being generated by data serialization of the current container state data, The updating of the restarted container state data using the saved current container state data includes: data deserialization of the container snapshot in the data file to recover the saved current container state data; and updating corresponding data fields in the data structure of the restarted container state data using the recovered current container state data. The current container state data and the restarted container state data are organized as data trees, and the updating of corresponding data fields in the data structure of the restarted container state data using the recovered current container state data includes:

3. The in-container kernel upgrade method of claim 2, wherein, from a root data node of the data tree of the restarted container state data, performing the following updating process from top to bottom for each data node: determining whether a corresponding data node exists in the data tree of the current container state data for the current data node; in response to no corresponding data node existing in the data tree of the current container state data, performing no update processing for a data field part of the current data node, in response to a corresponding data node existing in the data tree of the current container state data, determining whether a data field change occurs for the current data node relative to the corresponding data node, ​ in response to no data field change of the current data node relative to the corresponding data node, directly updating data field information of the current data node by using data field information of the corresponding data node, in response to data field change of the current data node relative to the corresponding data node, updating data field information of the current data node according to a specified strategy by using data field information of the corresponding data node.

4. The in-container kernel upgrade method of claim 2, wherein, The data file includes a memory file or a disk file.

5. The in-container kernel upgrade method of claim 1, wherein, Before saving the current container state data of the application container, the container kernel upgrade method further includes: stopping packet receiving function of the drive cache of the application container, and handing up packets in the drive cache to the first container kernel.

6. The in-container kernel upgrade method of claim 5, wherein, Before saving the current container state data of the application container, the container kernel upgrade method further includes: discarding all cache data of the application container.

7. The in-container kernel upgrade method of claim 1, wherein, Before saving the current container state data of the application container, the container kernel upgrade method further includes: performing exception detection on container state data corresponding to each container component in the current container state data of the application container; and / or recording system startup time and current real-time time of the application container.

8. The in-container kernel upgrade method of claim 1, wherein, After updating the restart container state data by using the saved current container state data, the container kernel upgrade method further includes: reopening host files set as open in the current container state data.

9. The in-container kernel upgrade method of claim 8, wherein, After updating the restart container state data by using the saved current container state data, the container kernel upgrade method further includes: determining system startup time of the application container; and / or starting hardware transceiving function of the application container. 10.A container kernel upgrade apparatus based on a programmable container kernel, comprising: a container freezing unit, in response to receiving a container kernel upgrade request, freezing an application container in which a first container kernel to be upgraded is located; a container state data saving unit, saving current container state data of the application container, the current container state data including first container kernel state data corresponding to the first container kernel and application program state data of all application programs running in the application container, and having a first data structure defined by the first container kernel; a container restarting unit, restarting the application container by using a second container kernel for container kernel upgrade, restart container state data of the restarted application container including second container kernel state data corresponding to the second container kernel when the application container is restarted, and having a second data structure defined by the second container kernel; a container state data updating unit, updating corresponding data fields in a data structure of the restart container state data by using the saved current container state data; and an application program running recovery unit, in response to completion of container state data updating, recovering running of container application programs in the restarted application container from the frozen application container. The first container kernel and the second container kernel are programmable container kernels, and the second container kernel is obtained by programmatically updating the version of the first container kernel. The programmable container kernel includes a container kernel that can be customized to update the functions and data structures supported by the application container kernel using programming means, and can be programmed to have the data structure defined by the current container kernel version, so that the container state data saved by the container kernel is data organized according to the defined data structure.

11. The in-container kernel upgrade apparatus of claim 10, wherein, The container state data saving unit saves the current container state data in the form of a container snapshot in a data file, and the container snapshot is generated by data serialization of the current container state data, The container state data updating unit includes: a container state data recovery module that deserializes the container snapshot in the data file to recover the current container state data; and a container state data updating module that updates the corresponding data field in the data structure of the restart container state data using the current container state data.

12. The in-container kernel upgrade apparatus of claim 11, wherein, The current container state data and the restart container state data are organized as a data tree, and the container state data updating module is configured to: From the root data node of the data tree of the restart container state data, perform the following update process from top to bottom for each data node: Determine whether there is a corresponding data node in the data tree of the current container state data for the current data node; In response to the absence of a corresponding data node in the data tree of the current container state data, no update processing is performed on the data field part of the current data node, In response to the presence of a corresponding data node in the data tree of the current container state data, Determine whether the current data node has changed the data field relative to the corresponding data node, In response to the current data node not having changed the data field relative to the corresponding data node, directly update the data field information of the current data node using the data field information of the corresponding data node, In response to the current data node having changed the data field relative to the corresponding data node, update the data field information of the current data node according to the specified strategy using the data field information of the corresponding data node.

13. The container kernel upgrading apparatus of claim 10, further comprising: a global pre-processing unit that stops the packet receiving function of the drive cache of the application container before saving the current container state data of the application container, and hands over the packets in the drive cache to the first container kernel.

14. The container kernel upgrading apparatus of claim 10, further comprising: a post-processing unit that reopens the host files set to be opened in the current container state data after updating the restart container state data using the saved current container state data.

15. A container kernel upgrading apparatus based on a programmable container kernel, comprising: at least one processor, a memory coupled to the at least one processor, and A computer program stored in the memory, the at least one processor executing the computer program to implement the programmable container kernel-based container kernel upgrade method of any one of claims 1 to 9.

16. A computer-readable storage medium storing executable instructions that, when executed, cause a processor to perform the programmable container kernel-based container kernel upgrade method of any one of claims 1 to 9.

17. A computer program product comprising a computer program that, when executed by a processor, implements the programmable container kernel-based container kernel upgrade method of any one of claims 1 to 9.

Images