A method of monitoring a container and a host machine

Abstract

A monitoring method for a container and a host machine, the host machine being deployed with a first container based on a guest kernel, a second container based on a host kernel, a first agent and a trusted module, the method comprising: in response to starting of the host machine, the trusted module generating a plurality of first metric values according to a plurality of first start objects of the host machine, the plurality of first start objects including the first agent, the first metric values being used to determine whether a starting process of the host machine is normal; in response to starting of the first container / second container, the first agent generating a plurality of second metric values / third metric values according to a plurality of second start objects / third start objects corresponding to the first container / second container, and sending the second metric values / third metric values to the trusted module, which are used to determine whether a starting process of the first container / second container is normal; the plurality of second start objects including a second agent based on the guest kernel, which is used to measure running objects in the first container after starting.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer virtualization technology, and more particularly to a method for monitoring containers and a host machine. Background Technology

[0002] Container technology is a lightweight operating system virtualization technology widely used in environments such as cloud computing. With the development of container technology, container types have diversified. Containers used in cloud computing environments can generally be divided into two categories: containers that run on the host operating system kernel and containers that run on an independent kernel outside the host operating system kernel. Current cloud computing environments often deploy both types of containers in a hybrid manner to better balance computing performance and security. However, current container monitoring solutions typically only monitor the operation of a single type of container and lack efficient monitoring solutions for hybrid container deployments. Therefore, a new method for monitoring hybrid container deployments is needed. Summary of the Invention

[0003] The embodiments in this specification aim to provide a method and host machine for monitoring containers, which can monitor the entire lifecycle of hybrid-deployed containers based on the host kernel and containers based on the guest kernel. This allows for the timely detection and handling of potential security issues throughout the lifecycle of hybrid-deployed containers, thereby improving the security of hybrid-deployed containers.

[0004] According to the first aspect, a method for monitoring containers is provided, wherein a first container based on a guest kernel, a second container based on the host kernel, a first agent program, and a trusted module are deployed on the host machine of the container, the method comprising:

[0005] In response to the startup of the host machine, the trusted module generates multiple first metrics based on multiple first startup objects corresponding to the host machine, wherein the multiple first startup objects include a first agent program; the first metrics are used to determine whether the startup process of the host machine is normal.

[0006] In response to the startup of the first container, the first agent program generates multiple second metrics based on multiple second startup objects corresponding to the first container, and sends the second metrics to the trusted module to determine whether the startup process of the first container is normal; the multiple second startup objects include at least a second agent program based on the client kernel, used to measure the running objects corresponding to the first container after the first container starts.

[0007] In response to the startup of the second container, the first agent program generates multiple third metrics based on the multiple third startup objects corresponding to the second container, and sends the third metrics to the trusted module to determine whether the startup process of the second container is normal.

[0008] In one possible implementation, the method further includes:

[0009] After the first container starts, the second agent program generates multiple fourth metrics based on the multiple first running objects corresponding to the first container, and transmits the fourth metrics to the trusted module through the host machine to determine whether the running status of the first running object is normal.

[0010] After the second container starts, the first agent program generates multiple corresponding fifth metrics based on the multiple second running objects corresponding to the second container, and transmits the fifth metrics to the trusted module through the host machine to determine whether the running status of the second running object is normal.

[0011] In one possible implementation, the method further includes: if it is determined that the startup process of the host machine is abnormal, then terminating the startup of the host machine; if it is determined that the startup process of the first container or the second container is abnormal, then terminating the startup process of the first container or the second container.

[0012] In one possible implementation, the plurality of first boot objects further include a basic input / output system, a bootloader, and a host kernel; the plurality of third boot objects include the runtime process on which the second container depends and the image file corresponding to the second container.

[0013] In one possible implementation, the guest kernel runs in a first virtual machine, and the plurality of second startup objects further include the runtime process on which the second container depends and the image file corresponding to the first virtual machine;

[0014] In one possible implementation, the trusted module includes a plurality of first reference values ​​corresponding to the plurality of first launch objects, a plurality of second reference values ​​corresponding to the plurality of second launch objects, and a plurality of third reference values ​​corresponding to the plurality of third launch objects.

[0015] Determining whether the host machine's startup process is normal includes: determining whether each first startup object starts normally based on the first metric value and the first baseline value corresponding to each first startup object; if any one of the multiple first startup objects fails to start normally, then the host machine's startup process is determined to be abnormal; if all first startup objects start normally, then the host machine's startup process is determined to be normal.

[0016] Determining whether the startup process of the first container is normal includes: determining whether each second startup object starts normally based on the second metric value and the second baseline value corresponding to each second startup object; if any one of the multiple second startup objects fails to start normally, then the startup process of the first container is determined to be abnormal; if all second startup objects start normally, then the startup process of the first container is determined to be normal.

[0017] Determining whether the startup process of the first container is normal includes: determining whether each third startup object starts normally based on the third metric value and the third baseline value corresponding to each third startup object; if any one of the multiple third startup objects starts abnormally, then the startup process of the second container is determined to be abnormal; if all third startup objects start normally, then the startup process of the second container is determined to be normal.

[0018] In one possible implementation, the trusted module includes multiple fourth reference values ​​corresponding to multiple first running objects and multiple fifth reference values ​​corresponding to multiple second running objects.

[0019] Determining whether the operation of the first running object is normal includes: determining whether the operation status of each first running object is normal based on the fourth metric value and the fourth benchmark value corresponding to each first running object;

[0020] Determining whether the operation of the second running object is normal includes: determining whether the operation status of each second running object is normal based on the fifth metric value and the fifth benchmark value corresponding to each second running object.

[0021] In one possible implementation, the method further includes:

[0022] If it is determined that the running state of any first running object is abnormal, then the running state of the first container is determined to be abnormal. If it is determined that the running process of any second running object is abnormal, then the running state of the two containers is determined to be abnormal.

[0023] In one possible implementation, the trusted module is either a trusted platform control module or a trusted platform module configured in the host machine.

[0024] According to the second aspect, a host machine is provided, comprising a first container with a corresponding guest kernel, a second container without a corresponding guest kernel, a first agent program, and a trusted module, wherein...

[0025] The trusted module is configured to, in response to the startup of the host machine, measure multiple first startup objects corresponding to the host machine and generate multiple corresponding first measurement values, wherein the multiple objects include the first agent program; the first measurement values ​​are used to determine whether the startup process of the host machine is normal.

[0026] The first agent program is configured to, in response to the startup of the first container, generate a plurality of corresponding second metrics based on a plurality of second startup objects corresponding to the first container, and send the second metrics to the trusted module to determine whether the startup process of the first container is normal; the plurality of second startup objects include at least a second agent program based on the client kernel for measuring the running objects corresponding to the first container after the first container starts.

[0027] The first agent program is further configured to, in response to the startup of the second container, generate a plurality of corresponding third metrics based on a plurality of third startup objects corresponding to the second container, and send the third metrics to the trusted module to determine whether the startup process of the second container is normal.

[0028] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0029] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0030] By utilizing one or more of the methods, host machines, computing devices, and storage media mentioned above, the entire lifecycle of hybrid-deployed containers based on host kernels and containers based on guest kernels can be monitored in real time. This enables the timely detection and handling of potential security issues throughout the lifecycle of hybrid-deployed containers, greatly improving the security of hybrid-deployed containers throughout their entire lifecycle. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 A schematic diagram of a container monitoring scheme is shown;

[0033] Figure 2 A schematic diagram of another method for monitoring containers is shown;

[0034] Figure 3 A schematic diagram illustrating a method for monitoring a container according to an embodiment of this specification is shown.

[0035] Figure 4 A flowchart illustrating a method for monitoring a container according to an embodiment of this specification is shown;

[0036] Figure 5 This diagram illustrates a method for determining whether the host machine is booting normally according to an embodiment of this specification.

[0037] Figure 6 A structural diagram of a host machine according to an embodiment of this specification is shown. Detailed Implementation

[0038] The solution provided in this invention will now be described with reference to the accompanying drawings.

[0039] As mentioned earlier, container technology is a lightweight operating system virtualization technology that is widely used in environments such as cloud computing. With the development of container technology, container types have become more diversified. Containers used in cloud computing environments can generally be divided into two categories: one is containers that run based on the host operating system kernel (or simply host kernel), and the other is containers that run based on an independent kernel other than the host operating system kernel.

[0040] Containers, which run on the host operating system kernel, typically share the host kernel. Applications within containers run on top of the existing host kernel, eliminating the need to install and maintain a separate kernel for each container. Containers can achieve resource isolation and relative environmental independence through kernel-provided features such as namespaces and control groups. For example, namespaces allow processes in different containers to see different network configurations and file system mount points. However, because containers share the host kernel, if a malicious program within a container exploits a kernel vulnerability to breach the container's isolation boundaries, it could potentially compromise the security of other containers and even the host machine.

[0041] Containers running on independent kernels typically have their own guest kernel. Each container or the virtual machine it resides in has its own configured kernel. Because in addition to the isolation inherent to the container itself, the guest kernel provides additional isolation, the isolation between the container and the host machine, as well as other containers, is more thorough and offers better security. For example, even if the container's own kernel has a problem, it usually won't directly affect containers on the host machine or other virtual machines. However, independent kernels consume more computing resources; each guest kernel requires a certain amount of memory, disk space, and other resources.

[0042] Therefore, generally speaking, containers based on guest kernels offer better security, while containers based on host kernels consume fewer computing resources and have higher performance. To better balance security and computing performance, current cloud computing environments often deploy both types of containers in combination. For example, in a business system, the order processing subsystem requires high performance to quickly process a large number of orders, which could be achieved using a container based on the host kernel; while the financial subsystem involves a large amount of confidential data and requires better security, thus it could use a container based on a guest kernel.

[0043] However, current monitoring solutions for container operation typically only monitor the operation of a single type of container, and there is a lack of efficient monitoring solutions for hybrid container deployments. For example, Figure 1 A schematic diagram of a container monitoring scheme is shown. (For example...) Figure 1 As shown, a measurement program running on the host operating system can be used to measure the process code of applications contained in containers running on the host machine, and the measurement results can be used to determine whether the applications in the container are running normally. However, this approach has two problems: First, it cannot monitor application processes in containers running on an independent kernel outside the host operating system kernel. Second, it cannot monitor the entire process from host machine startup to container startup and application execution within the container, leaving a vulnerability that can be exploited.

[0044] Figure 2 A schematic diagram of another method for monitoring containers is shown. (For example...) Figure 2As shown, after a container running on an operating system (on a physical machine or virtual machine) starts, its mount path can be obtained. The mount path refers to establishing an association between a specific directory or part of the file system on the physical machine or virtual machine running the container and a directory inside the container, allowing the container's directories to directly access and use the corresponding directory or file resources on the physical machine or virtual machine. Then, files under the container's mount path are scanned, and the container's running status is determined by measuring the scanned files. However, this approach has several problems: First, in hybrid container scenarios, it cannot distinguish which container a file belongs to, making it unsuitable for such scenarios. Second, this approach typically stores file metrics in the file's extended attributes, which are easily tampered with by attackers, resulting in low security. Third, this approach cannot monitor the entire process from host machine startup to application execution within the container, creating a monitoring vulnerability.

[0045] To address the aforementioned technical problems, this specification provides a method for monitoring containers. Figure 3 This diagram illustrates a method for monitoring containers according to an embodiment of this specification. Figure 3 As shown, the host machine can, for example, deploy container A, which depends on the host kernel, and container B, which has a guest kernel. During host machine startup, a trusted module, for example, installed on the host motherboard, can measure multiple startup objects during the startup process, obtaining multiple metric values. For example, the Basic Input Output System (BIOS), Boot Loader, Host Kernel, and the first agent program dependent on the host kernel can be measured sequentially, obtaining their respective metric values. The trusted module can determine whether the host machine startup is normal based on pre-saved baseline values ​​for the BIOS, Boot Loader, and Host Kernel, and their respective metric values. In one example, if the host machine startup is determined to be abnormal, the startup process can be terminated.

[0046] After the host machine starts, when container A starts, the first agent program can measure multiple startup objects during the startup process of container A, obtain multiple corresponding metric values, and send them to the trusted module. These startup objects can be objects that container A depends on, accesses, loads, calls, or executes during the startup process. Therefore, the dependent library files, daemons or management processes, image files, and configuration files of container A can be measured, obtaining their respective metric values. The trusted module can determine whether container A's startup is normal based on pre-saved baseline values ​​for each of container A's dependent library files, daemons or management processes, image files, and configuration files, and their respective metric values. After container A starts, the first agent program can measure the application (running object) in container A and send the obtained metric values ​​to the trusted module to determine whether the application in container A is running normally, thereby determining whether container A is running normally.

[0047] After the host machine starts, when container B starts, the first agent program can measure multiple startup objects during the container B startup process, obtain corresponding metric values, and send them to the trusted module. These startup objects may include container B's dependency library files, container B's daemon or management processes, the image file of the virtual machine loading the guest kernel, and the second agent program. Thus, each startup object can be measured separately, obtaining its corresponding metric value. The trusted module can determine whether container B's startup is normal based on pre-saved baseline values ​​and corresponding metric values ​​for each startup object. After container B starts, the second agent program can measure the applications (running objects) within container B and send the obtained metric values ​​to the trusted module to determine whether the applications within container B are running normally, thereby determining whether container B is operating normally.

[0048] The advantages of this method are as follows: First, it provides a monitoring scheme for hybrid containers deployed on a host machine. It can monitor the entire lifecycle of hybrid containers, from the host machine startup process to the startup process of containers based on the host kernel and containers based on the guest kernel, and then to their operational status after startup. This allows for monitoring of potential security issues throughout the container's lifecycle, enabling timely handling of these issues and significantly improving the overall security of hybrid containers. Second, based on trusted computing, it measures the entire process from the host machine startup process to the startup process of containers based on the host kernel and containers based on the guest kernel, and then to their operational status after startup. This improves the security and reliability of the process for identifying potential security issues based on the measurement results.

[0049] Figure 4 A flowchart illustrating a container monitoring method according to an embodiment of this specification is shown. The container's host machine deploys a first container based on a guest kernel, a second container based on the host kernel, a first agent program, and a trusted module. Figure 4 As shown, the method includes at least the following steps:

[0050] Step S401: In response to the startup of the host machine, the trusted module generates multiple first metrics based on multiple first startup objects corresponding to the host machine, wherein the multiple first startup objects include a first agent program; the first metrics are used to determine whether the startup process of the host machine is normal.

[0051] In step S403, in response to the startup of the first container, the first agent program generates multiple second metrics based on the multiple second startup objects corresponding to the first container, and sends the second metrics to the trusted module to determine whether the startup process of the first container is normal; the multiple second startup objects include at least a second agent program based on the client kernel for measuring the running objects corresponding to the first container after the first container starts.

[0052] In step S405, in response to the startup of the second container, the first agent program generates multiple third metrics based on the multiple third startup objects corresponding to the second container, and sends the third metrics to the trusted module to determine whether the startup process of the second container is normal.

[0053] First, in step S401, in response to the startup of the host machine, the trusted module generates multiple first metrics based on multiple first startup objects corresponding to the host machine. The multiple first startup objects may include a first agent program, and the first metrics can be used to determine whether the startup process of the host machine is normal.

[0054] A host machine is typically a computer with physical resources (such as CPU, memory, disk space, network interfaces, etc.) for running containers. In different embodiments, the host machine can be a physical computer or a logical computer allocated physical resources. A trusted module is a module that can be used for trusted computing. Trusted computing mainly involves building a Root of Trust (RoT) on the computer hardware platform and establishing a trusted environment for the computer system based on the Root of Trust, enabling the trustworthiness of various components (including hardware and software) in the system to be verified. In different embodiments, the specific implementation of the trusted module can vary. In one embodiment, the trusted module can be, for example, a Trust Platform Control Module (TPCM) or a Trust Platform Module (TPM) configured in the host machine. In another embodiment, the trusted module can also be a Trusted Execution Environment (TEE) configured on the host machine.

[0055] In this step, after the host machine starts up, the trusted module can generate multiple first metric values ​​based on the multiple first boot objects corresponding to the host machine. The multiple first boot objects can be multiple software, hardware, or a combination of software and hardware that are sequentially started by the host machine during the boot process. In different embodiments, the specific objects included in the multiple first boot objects can differ depending on the specific configuration of the host machine. For example, in one embodiment, the multiple first boot objects may also include a Basic Input Output System (BIOS), a Boot Loader, and a Host Kernel. In an embodiment, the normal boot process of the host machine may include, for example, the startup of the BIOS, the startup of the Boot Loader, the startup of the Host Kernel, and the startup of the first agent program. In different embodiments, the specific method of generating the multiple first metric values ​​based on the multiple first boot objects can differ. In one embodiment, for example, a corresponding hash value can be generated for each first boot object as the first metric value corresponding to each boot object.

[0056] The first metric value can be used to determine whether the host machine's boot process is normal. In different embodiments, the specific method for determining whether the host machine's boot process is normal based on the first metric value may vary. In one embodiment, the trusted module may further include multiple first benchmark values ​​corresponding to the plurality of first boot objects. Therefore, based on the first metric value and the first benchmark value corresponding to each first boot object, it can be determined whether each first boot object has booted normally. Specifically, if any one of the plurality of first boot objects boots abnormally, it can be determined that the host machine's boot process is abnormal; if all first boot objects boot normally, it can be determined that the host machine's boot process is normal.

[0057] After determining that the host machine's boot process is abnormal, corresponding processing can be applied to the boot process. In different embodiments, the applied processing methods may differ. In one embodiment, if the host machine's boot process is determined to be abnormal, the boot process can be terminated, such as... Figure 5 As shown.

[0058] After the host machine starts, in step S403, in response to the startup of the first container, the first agent program generates multiple second metrics based on multiple second startup objects corresponding to the first container. These multiple second startup objects include at least one second agent program based on the client kernel, used to measure the running objects corresponding to the first container after its startup. The second metrics are then sent to the trusted module to determine whether the startup process of the first container is normal.

[0059] In this step, after the host machine starts, a first container that depends on the guest kernel can be started. In different embodiments, the first container can be a different specific type of container that depends on the guest kernel; this specification does not limit this. The first agent program that has already started during the host machine's startup process can generate multiple corresponding second metrics based on the multiple second startup objects corresponding to the first container.

[0060] The second startup object can be an object that the startup process of the first container depends on, accesses, loads, calls, or executes. In different embodiments, the multiple second startup objects corresponding to the first container can be different. In one embodiment, the guest kernel can be a guest kernel running in a specific virtual machine (e.g., the first virtual machine). The multiple second startup objects corresponding to the first container may include runtime processes (e.g., container daemons or management processes) that the second container depends on, the image file corresponding to the first virtual machine, the container process corresponding to the second container, and a second agent. The second agent can run based on the guest kernel and is used to measure the objects running in the first container after the first container starts.

[0061] The first agent program, which has already started during the host machine's startup process, can generate multiple corresponding second metrics based on multiple second startup objects and send them to the trusted module during this step. Similar to generating the first metric, the specific method for generating the multiple corresponding second metrics based on multiple second startup objects can differ in different embodiments. In one embodiment, for example, a corresponding hash value can be generated for each second startup object, serving as the second metric for each second startup object.

[0062] The trusted module can determine whether the startup process of the first container is normal based on multiple received second metrics. In different embodiments, the specific method for determining whether the startup of the first container is normal can vary. For example, in one embodiment, the trusted module may include multiple second benchmark values ​​corresponding to the multiple second startup objects. Furthermore, based on the second metrics and second benchmark values ​​corresponding to each second startup object, it can be determined whether each second startup object has started normally; if any one of the multiple second startup objects fails to start normally, the startup process of the first container is determined to be abnormal; if all second startup objects start normally, the startup process of the first container is determined to be normal.

[0063] If it is determined that the startup of the first container is abnormal, processing can be applied to the startup process of the first container. In different embodiments, the specific processing methods can differ. For example, in one embodiment, if it is determined that the startup process of the first container is abnormal, the startup process of the first container can be terminated.

[0064] After the host machine starts, in step 405, in response to the startup of the second container, the first agent program generates multiple third metrics based on the multiple third startup objects corresponding to the second container, and sends the third metrics to the trusted module to determine whether the startup process of the second container is normal.

[0065] In this step, after the host machine starts, a second container that depends on the host kernel can be started. In different embodiments, the second container can be a different specific type of container that depends on the host kernel; this specification does not limit this. The first agent program, which has already started during the host machine's startup process, can generate multiple corresponding third metrics based on the multiple third startup objects corresponding to the second container.

[0066] The third startup object can be an object that the startup process of the second container depends on, accesses, loads, calls, or executes. In different embodiments, the multiple third startup objects corresponding to the second container can be different. In one embodiment, the guest kernel can be a guest kernel running in a specific virtual machine (e.g., the first virtual machine). The multiple third startup objects corresponding to the second container may include runtime processes that the second container depends on and the image file corresponding to the second container.

[0067] The first agent program, which has already started during the host machine's startup process, can generate multiple corresponding third metrics based on multiple third-stage startup objects and send them to the trusted module during this step. Similar to generating the first metric, the specific method for generating the multiple corresponding third metrics based on multiple third-stage startup objects can differ in different embodiments. In one embodiment, for example, a corresponding hash value can be generated for each third-stage startup object, serving as the third metric for that object.

[0068] The trusted module can determine whether the startup process of the first container is normal based on multiple received second metrics. In different embodiments, the specific method for determining whether the startup of the first container is normal can vary. For example, in one embodiment, the trusted module may include multiple third benchmark values ​​corresponding to the multiple third startup objects; in another embodiment, it can determine whether each third startup object has started normally based on the third metric value and the third benchmark value corresponding to each third startup object; if any one of the multiple third startup objects fails to start normally, the startup process of the second container is determined to be abnormal; if all third startup objects start normally, the startup process of the second container is determined to be normal.

[0069] If it is determined that the startup of the second container is abnormal, processing can be applied to the startup process of the second container. The specific processing methods applied may differ in different embodiments. For example, in one embodiment, if it is determined that the startup process of the second container is abnormal, the startup process of the second container can be terminated.

[0070] It should be noted that steps S403 and S405 are not limited to being executed sequentially. In different embodiments, steps S403 and S405 can be executed in any order or in parallel.

[0071] After the first container starts, in order to detect whether the running state of the first container is safe, in one embodiment, after the first container starts, the second agent program can generate multiple corresponding fourth metrics based on multiple first running objects corresponding to the first container, and transmit the fourth metrics to the trusted module through the host machine to determine whether the running process of the first running object is normal. Furthermore, if it is determined that the running state of any one of the first running objects is abnormal, then the running state of the first container is determined to be abnormal.

[0072] In different embodiments, the first running object corresponding to the first container can be different. For example, it can be multiple applications running in the first container. In one embodiment, the trusted module can include multiple fourth benchmark values ​​corresponding to multiple first running objects respectively. Furthermore, based on the fourth metric value and the fourth benchmark value corresponding to the first running object, it can be determined whether the running process of the first running object is normal.

[0073] After the second container starts, in order to detect whether the running status of the second container is safe, in one embodiment, after the second container starts, the first agent program can generate multiple corresponding fifth metrics based on multiple second running objects corresponding to the second container, and transmit the fifth metrics to the trusted module through the host machine to determine whether the running process of the second running object is normal. If it is determined that the running status of any second running object is abnormal, then the running status of the second container is determined to be abnormal.

[0074] In different embodiments, the second running object corresponding to the second container can be different. For example, it can be multiple applications running in the second container. In one embodiment, the trusted module may further include multiple fifth benchmark values ​​corresponding to the multiple second running objects respectively. Furthermore, the normality of the operation of the second running object can be determined based on the fifth metric value and the fifth benchmark value corresponding to the second running object.

[0075] In one embodiment, after the first container / second container starts, the first agent program can also generate corresponding metrics based on one or more of the objects that the first container / second container depends on for its operation, such as container runtime processes, virtual machine processes, executable and linkable format (ELF) files, shared object (SO) files, and kernel object (KO) files. Based on the obtained metrics, it can determine whether the first container / second container is running normally.

[0076] After determining that the operation of the first / second container is abnormal, further processing can be applied to the first / second container. In different embodiments, the specific methods of applying processing to the first / second container may differ; for example, the operation of the first / second container may be terminated, or a warning message may be issued regarding its operating status. In different specific embodiments, the format of the warning message or the specific content used for the warning may differ, and this specification does not limit this.

[0077] Furthermore, in one embodiment, after the host machine starts up, the first agent program can also measure the applications running on the host machine and determine whether the running status of the applications on the host machine is normal based on the obtained measurement values. For example, it can determine whether the applications running on the host machine are normal based on the baseline value and measurement value corresponding to the applications running on the host machine, and it can also determine whether the host machine is running normally based on whether the applications running on the host machine are normal. In one embodiment, after determining that the host machine's running process is abnormal, it can also apply processing to the host machine's running process, such as terminating the host machine's operation or issuing a warning message regarding its running status.

[0078] The above describes a method for monitoring containers provided by embodiments of this specification. Another embodiment of this specification also provides a host machine. Figure 6 A structural diagram of a host machine according to an embodiment of this specification is shown. Figure 6 As shown, the host machine 600 may include a first container 61 based on a guest kernel, a second container 62 based on the host machine kernel, a first agent program 63, and a trusted module 64.

[0079] Trusted module 64 is configured to, in response to the startup of the host machine, generate multiple first metrics based on multiple first startup objects corresponding to the host machine, wherein the multiple first startup objects include a first agent program; the first metrics are used to determine whether the startup process of the host machine is normal.

[0080] The first agent program 63 is configured to, in response to the startup of the first container, generate a plurality of corresponding second metrics based on a plurality of second startup objects corresponding to the first container, and send the second metrics to the trusted module to determine whether the startup process of the first container is normal; the plurality of second startup objects include at least a second agent program based on the client kernel for measuring the running objects corresponding to the first container after the first container starts.

[0081] The first agent program 63 is further configured to, in response to the startup of the second container, generate a plurality of corresponding third metrics based on a plurality of third startup objects corresponding to the second container, and send the third metrics to the trusted module to determine whether the startup process of the second container is normal.

[0082] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform any of the methods described above.

[0083] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements any of the methods described above.

[0084] It should be understood that the descriptions such as "first" and "second" in this article are merely for the sake of simplicity in description and to distinguish similar concepts, and do not have any other limiting function.

[0085] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0086] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for monitoring containers, wherein the host machine of the container deploys a first container based on a guest kernel, a second container based on the host kernel, a first agent program, and a trusted module, the method comprising: In response to the startup of the host machine, the trusted module generates multiple first metrics based on multiple first startup objects corresponding to the host machine, wherein the multiple first startup objects include a first agent program; the first metrics are used to determine whether the startup process of the host machine is normal. In response to the startup of the first container, the first agent program generates multiple second metrics based on multiple second startup objects corresponding to the first container, and sends the second metrics to the trusted module to determine whether the startup process of the first container is normal; the multiple second startup objects include at least a second agent program based on the client kernel, used to measure the running objects corresponding to the first container after the first container starts. In response to the startup of the second container, the first agent program generates multiple third metrics based on the multiple third startup objects corresponding to the second container, and sends the third metrics to the trusted module to determine whether the startup process of the second container is normal. After the first container starts, the second agent program generates multiple fourth metrics based on the multiple first running objects corresponding to the first container, which include multiple applications running in the first container, and transmits the fourth metrics to the trusted module through the host machine to determine whether the running status of the first running object is normal.

2. The method according to claim 1, further comprising: After the second container starts, the first agent program generates multiple corresponding fifth metrics based on the multiple second running objects corresponding to the second container, and transmits the fifth metrics to the trusted module through the host machine to determine whether the running status of the second running object is normal.

3. The method according to claim 1, further comprising: If it is determined that the startup process of the host machine is abnormal, then the startup of the host machine shall be terminated. If it is determined that the startup process of the first container or the second container is abnormal, then the startup process of the first container or the second container is terminated.

4. The method according to claim 1, wherein, The plurality of first boot objects also include a basic input / output system, a bootloader, and a host kernel; the plurality of third boot objects include the runtime process on which the second container depends and the image file corresponding to the second container.

5. The method according to claim 1, wherein, The guest kernel runs in the first virtual machine, and the plurality of second startup objects also include the runtime process that the second container depends on and the image file corresponding to the first virtual machine.

6. The method according to claim 1, wherein, The trusted module includes multiple first reference values ​​corresponding to the multiple first launch objects, multiple second reference values ​​corresponding to the multiple second launch objects, and multiple third reference values ​​corresponding to the multiple third launch objects. Determining whether the host machine's startup process is normal includes: determining whether each first startup object starts normally based on the first metric value and the first baseline value corresponding to each first startup object; if any one of the multiple first startup objects fails to start normally, then the host machine's startup process is determined to be abnormal; if all first startup objects start normally, then the host machine's startup process is determined to be normal. Determining whether the startup process of the first container is normal includes: determining whether each second startup object starts normally based on the second metric value and the second baseline value corresponding to each second startup object; if any one of the multiple second startup objects fails to start normally, then the startup process of the first container is determined to be abnormal; if all second startup objects start normally, then the startup process of the first container is determined to be normal. Determining whether the startup process of the second container is normal includes: determining whether each third startup object starts normally based on the third metric value and the third baseline value corresponding to each third startup object; if any one of the multiple third startup objects fails to start normally, then the startup process of the second container is determined to be abnormal; if all third startup objects start normally, then the startup process of the second container is determined to be normal.

7. The method according to claim 2, wherein, The trusted module includes multiple fourth reference values ​​corresponding to multiple first running objects and multiple fifth reference values ​​corresponding to multiple second running objects. Determining whether the operation of the first running object is normal includes: determining whether the operation status of each first running object is normal based on the fourth metric value and the fourth benchmark value corresponding to each first running object; Determining whether the operation of the second running object is normal includes: determining whether the operation status of each second running object is normal based on the fifth metric value and the fifth benchmark value corresponding to each second running object.

8. The method according to claim 2, further comprising: If it is determined that the running state of any first running object is abnormal, then the running state of the first container is determined to be abnormal. If it is determined that the operation of any second running object is abnormal, then the operation status of the second container is determined to be abnormal.

9. The method according to claim 1, wherein, The trusted module is either a trusted platform control module or a trusted platform module configured in the host machine.

10. A host machine, wherein a first container based on a guest kernel, a second container based on the host machine kernel, a first agent program, and a trusted module are deployed on the host machine, wherein, The trusted module is configured to, in response to the startup of the host machine, generate multiple first metrics based on multiple first startup objects corresponding to the host machine, wherein the multiple first startup objects include a first agent program; the first metrics are used to determine whether the startup process of the host machine is normal. The first agent program is configured to, in response to the startup of the first container, generate a plurality of corresponding second metrics based on a plurality of second startup objects corresponding to the first container, and send the second metrics to the trusted module to determine whether the startup process of the first container is normal; the plurality of second startup objects include at least a second agent program based on the client kernel for measuring the running objects corresponding to the first container after the first container starts. The first agent program is further configured to, in response to the startup of the second container, generate a plurality of corresponding third metrics based on a plurality of third startup objects corresponding to the second container, and send the third metrics to the trusted module to determine whether the startup process of the second container is normal. The second agent program is configured to, after the first container starts, generate multiple fourth metrics based on multiple first running objects corresponding to the first container, the multiple first running objects including multiple applications running in the first container, and transmit the fourth metrics to the trusted module through the host machine to determine whether the running status of the first running object is normal.

11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-9.

12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images