Container editing method, device, storage medium, and program product

Abstract

The application relates to a container editing method, device, storage medium and program product. The method comprises the following steps: if a target container editing event for a target node is monitored, determining a container type corresponding to the target container editing event; if the container type is a wasm type, calling a wasm engine; calling a wasm runtime by using the wasm engine, and responding to the target container editing event based on the wasm runtime. The method solves the problem that a wasm container cannot run in a traditional container cloud kubernetes, and achieves the purpose of running the wasm container in the traditional container cloud kubernetes.

Description

Technical Field

[0001] This application relates to the field of cloud-native technology, and in particular to a container editing method, device, storage medium, and program product. Background Technology

[0002] Cloud-native is a cloud technology product system built on distributed cloud based on distributed deployment and unified operation, and based on technologies such as containers, microservices, and DevOps. As an important supporting technology for digital transformation in new infrastructure, cloud-native is gradually emerging in emerging fields such as artificial intelligence, big data, edge computing, and 5G. Now, more and more global enterprises are using cloud-native containerized applications in production.

[0003] In traditional cloud-native container cloud architectures, each node can only run traditional Linux containers. However, a new technology, WebAssembly, is gradually emerging in this field. WebAssembly is a new open standard binary format, often referred to as wasm. By design, it boasts advantages such as memory safety, portability, and high efficiency. It can run with near-native performance, and code from other languages ​​can be cross-compiled into wasm. It offers first-class support for Rust, C / C++, and AssemblyScript, and many other compilers are under development.

[0004] Traditional Linux containers aim to provide an operating system-level sandbox environment, relying on the kernel to provide this environment. However, they have certain operational limitations; for example, code compiled for Intel chipsets cannot run on ARM hardware. Wasm provides a portable binary format that can run anywhere, regardless of the underlying hardware. But because it is only a binary format, it cannot provide the same flexibility as an operating system-level sandbox environment. Therefore, Wasm containers cannot run in traditional container clouds like Kubernetes. With the continuous development of cloud-native technologies, this problem urgently needs to be solved. Summary of the Invention

[0005] Therefore, it is necessary to provide a container editing method, device, storage medium, and program product that can run wasm containers in traditional container cloud Kubernetes to address the above-mentioned technical problems.

[0006] Firstly, this application provides a container editing method. The method includes:

[0007] If an edit event for the target container of the target node is detected, the container type corresponding to the edit event is determined. If the container type is a Wasm type, the Wasm engine is invoked. The Wasm engine is used to invoke the Wasm runtime, and the target container edit event is responded to based on the Wasm runtime.

[0008] In one embodiment, determining the container type corresponding to the target container edit event includes: detecting whether the target container edit event contains a wasm type tag; if so, determining that the container type corresponding to the target container edit event is a wasm type.

[0009] In one embodiment, the method further includes: if the container type is container, invoking the Docker engine, using the Docker engine to invoke the Docker runtime, and responding to the target container edit event based on the Docker runtime.

[0010] In one embodiment, the target container edit event is the event of creating the container. The process involves using the Wasm engine to call the Wasm runtime and responding to the target container edit event based on the Wasm runtime, including: using the Wasm engine to create the Wasm runtime; and creating the Wasm container based on the Wasm runtime.

[0011] In one embodiment, creating a Wasm container based on the Wasm runtime includes: obtaining a container image file corresponding to the target container edit event; and creating a Wasm container using the container image file based on the Wasm runtime.

[0012] In one embodiment, the method further includes: if a target container edit event for a target node is detected, the target container edit event is placed in a task queue, wherein the task queue stores multiple container edit events for the target node; container edit events are sequentially extracted from the task queue; when a target container edit event is extracted from the task queue, the method executes the step of determining the container type corresponding to the target container edit event; if the container type is a WASM type, the method calls the WASM engine, uses the WASM engine to call the WASM runtime, and responds to the target container edit event based on the WASM runtime.

[0013] In one embodiment, the wasm runtime includes the wasmtime runtime, the wasmer runtime, the wasmcloud runtime, and the wasm3 runtime.

[0014] In one embodiment, the method further includes: if a response request to a target container deployed in a target node is detected, then, based on the response request, reporting the output results and / or log information of the target container.

[0015] In one embodiment, the method further includes: if an edit event for a target container is detected, periodically reporting the liveness status of the target node and / or the resource consumption status of the target node.

[0016] In one embodiment, the method further includes: if an edit event for a target container on a target node is detected, obtaining an eviction policy; determining a first pod from multiple pods on the target node according to the eviction policy, and deleting the first pod, wherein the pod contains at least one container.

[0017] In one embodiment, the method further includes: if an edit event for a target container on a target node is detected, detecting whether the container image file stored in the target node meets the deletion conditions; and deleting the container image file that meets the deletion conditions from the target node.

[0018] In one embodiment, the method further includes: if an edit event for a target container on a target node is detected, monitoring the liveness status of each container in the target node; and deleting containers that are not live from the target node.

[0019] In one embodiment, the method further includes: if an edit event for the target container of the target node is detected, receiving a state change event for the second pod in the target node; performing a state change processing on the second pod according to the state change event, and reporting the state of the second pod after the change processing.

[0020] Secondly, this application also provides an apparatus. The apparatus includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement any of the steps described in the first aspect.

[0021] Thirdly, this application also provides a storage medium. The storage medium stores a computer program thereon, which, when executed by a processor, implements any of the steps described in the first aspect.

[0022] Fourthly, this application also provides a program product. The program product includes a computer program that, when executed by a processor, implements any of the steps described in the first aspect.

[0023] The aforementioned container editing methods, devices, storage media, and program products, if they detect a target container editing event for a target node, determine the container type corresponding to the target container editing event. If the container type is a Wasm type, they call the Wasm engine, then use the Wasm engine to call the Wasm runtime, and respond to the target container editing event based on the Wasm runtime, thus achieving the goal of running Wasm containers in traditional container cloud Kubernetes. Attached Figure Description

[0024] Figure 1 An application environment diagram of a container editing method provided in this application embodiment;

[0025] Figure 2 A flowchart illustrating a container editing method provided in an embodiment of this application;

[0026] Figure 3 A flowchart illustrating a container editing method provided in this application embodiment;

[0027] Figure 4 A flowchart illustrating the process of placing and extracting editing events of a target container, provided as an embodiment of this application;

[0028] Figure 5 A flowchart illustrating a process for determining the container type corresponding to a target container edit event, provided in an embodiment of this application;

[0029] Figure 6 A flowchart illustrating a method for creating a container, as provided in an embodiment of this application;

[0030] Figure 7 A flowchart illustrating a method for deleting a container image file provided in this application embodiment;

[0031] Figure 8 A flowchart illustrating a container deletion method provided in an embodiment of this application;

[0032] Figure 9 A flowchart illustrating a pod deletion method provided in an embodiment of this application;

[0033] Figure 10 A flowchart illustrating a pod state change processing method provided in an embodiment of this application;

[0034] Figure 11 A flowchart illustrating a container editing method provided in another embodiment of this application;

[0035] Figure 12 An internal structure diagram of a component in a krustlet provided in an embodiment of this application;

[0036] Figure 13 A flowchart illustrating the working process of a Krator component provided in an embodiment of this application;

[0037] Figure 14 A flowchart illustrating the working process of a krustlet component provided in an embodiment of this application;

[0038] Figure 15 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] Currently, cloud computing has entered a mature stage of development. Cloud-native, as a crucial supporting technology for digital transformation under new infrastructure, is gradually emerging in emerging fields such as artificial intelligence, big data, edge computing, and 5G, becoming a powerful engine driving digital infrastructure. Cloud-native is a cloud technology product system built upon distributed cloud based on distributed deployment and unified operation, and based on technologies such as containers, microservices, and DevOps.

[0041] Cloud-native applications are applications designed for the cloud. By using cloud-native technologies, developers don't need to consider the underlying technical implementation, allowing them to fully leverage the elasticity and distributed advantages of the cloud platform. This enables rapid deployment, on-demand scaling, and uninterrupted delivery. More and more global enterprises are now using cloud-native containerized applications in production. As a new technological concept born from the cloud computing era, cloud-native possesses advantages unmatched by traditional IT. It helps enterprises efficiently enjoy the elasticity and flexibility of the cloud, enabling smooth migration, rapid development, and stable operation and maintenance, significantly reducing technical costs and becoming a crucial engine for business growth. Initially, the cloud-native technology ecosystem focused primarily on containers, microservices, and DevOps, but it has now expanded to include numerous branches such as underlying technologies, orchestration and management technologies, security technologies, monitoring and analysis technologies, and scenario-based applications, initially forming a full lifecycle technology chain supporting the cloud-native construction of applications.

[0042] In traditional cloud-native container cloud architectures, each node can only run traditional Linux containers. However, a new technology, WebAssembly, is gradually emerging in this field. WebAssembly is a new open standard binary format, often referred to as wasm. By design, it boasts advantages such as memory safety, portability, and high efficiency. It can run with near-native performance, and code from other languages ​​can be cross-compiled into wasm. It offers first-class support for Rust, C / C++, and AssemblyScript, and many other compilers are under development.

[0043] Traditional Linux containers aim to provide an operating system-level sandbox environment, relying on the kernel to provide this environment. They have certain operational limitations; for example, code compiled for Intel chipsets cannot run on ARM hardware. Wasm, however, provides a portable binary format that can run anywhere, regardless of the underlying hardware. But because it is only a binary format, it cannot offer the same flexibility as an operating system-level sandbox environment, and therefore, Wasm containers cannot run in traditional container clouds like Kubernetes.

[0044] The container editing method provided in this application embodiment enables Wasm containers to run in traditional container cloud Kubernetes, making up for the shortcomings of current technology that cannot run Wasm containers in traditional container cloud Kubernetes, expanding the scope of cloud-native technology, and allowing Wasm containers to enter the field of traditional container cloud Kubernetes.

[0045] The container editing method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown. For example... Figure 1 As shown, this application environment includes Kubernetes API 101 and multiple nodes. Figure 1 In this context, Kubernetes API 101 refers to the API interface through which Kubernetes communicates with other optional components, environments, and applications. These multiple nodes are used to receive requests from the external environment to perform various functions. Specifically, Kubernetes API 101 provides services through an API server, which communicates with the multiple nodes and sends task requests.

[0046] These multiple nodes include node 102 and node 103, where the agent components deployed in node 102 and node 103 are different, such as... Figure 1As shown, the proxy component deployed in node 102 is kubelet, which is used to keep the state of node 102 updated and to handle requests from Kubernetes API 101; the proxy component deployed in node 103 is krustlet, which is used to keep the state of node 103 updated and to handle requests from Kubernetes API 101.

[0047] Furthermore, all of these nodes can deploy containers; however, node 102 can only deploy container containers, such as... Figure 1 As shown, node 102 includes multiple pods. The boxes in the pods shown in the figure are container containers. These container containers can be deployed based on the Docker environment. These container containers belong to the aforementioned traditional Linux containers. Node 103 can deploy container containers (boxes in the pods) and Wasm containers. These Wasm containers are containers written using the Wasm language.

[0048] In one embodiment, such as Figure 2 As shown, a method for editing a container is provided. The execution subject of this container editing method is the target node, which can be... Figure 1 Node 103 in the method includes the following steps:

[0049] Step 201: If an edit event for the target container of the target node is detected, the target node determines the container type corresponding to the edit event.

[0050] The target container edit event can also be called a pod event. A pod event refers to an event specific to a container and may include: adding a container, deleting a container, modifying a container, and querying a container. In practice, the add container event refers to creating a new container; the delete container event refers to stopping or deleting a container, which is necessary when there are runtime environment incompatibilities, container errors, or the need to remove internal applications; the modify container event refers to updating a container, used to modify and update the container to execute new functionality; and the query container event refers to querying a container.

[0051] As mentioned above, the target node has a proxy component krustlet deployed in it. This proxy component krustlet contains a krator component, which can listen to Kubernetes API 101 to determine if there is a target container edit event. When the krator component listens to a target container edit event for the target node, the target node can determine the container type corresponding to the target container edit event and perform the next operation according to the container type.

[0052] To enable nodes to determine the container type corresponding to a container edit event, optionally, in this embodiment, the target container edit event can be tagged. When the Krator component listens to Kubernetes API 101 and receives the target container edit event, it determines the container type by checking whether the target container edit event contains a Wasm type tag. If the target container edit event does not contain a Wasm type tag, the container type is determined to be a container type, and the next step is executed; if the target container edit event contains a Wasm type tag, the container type is determined to be a Wasm type, and the next step is executed.

[0053] Step 202: If the container type is wasm, the target node calls the wasm engine.

[0054] As mentioned above, this container type includes container and wasm container. By identifying the label, if the edit event of the target container contains a wasm type label, then the container type is determined to be wasm type.

[0055] When the container type is Wasm, the target node can invoke the Wasm engine. Optionally, the Wasm engine can be invoked by the proxy component Krustlet in the target node. Furthermore, the proxy component Krustlet can deploy a provider component (response component), through which the Wasm engine can be invoked.

[0056] The provider component is used to call the Wasm engine and the Docker engine. Depending on the container type, different container engines are called. In an optional embodiment of this application, if the container type corresponding to the target container editing event is Wasm, the provider component calls the Wasm engine for the target container editing event; if the container type corresponding to the target container editing event is Container, the provider component calls the Docker engine for the target container editing event.

[0057] Step 203: Use the wasm engine to call the wasm runtime and respond to the target container's edit events based on the wasm runtime.

[0058] In this context, runtime refers to the running state of a program. That is, when a program is opened and run on a computer, that program is at runtime. In some programming languages, certain reusable programs or instances are packaged or rebuilt into "runtime libraries." These instances can be linked or called by any program when they run. In other words, the operation of a container depends on the runtime.

[0059] Although wasm is a bytecode standard proposed to improve the performance of performance-sensitive modules in web pages, it can be used not only in browsers but also in other environments. In these environments, a runtime that supports the wasm system interface is required to execute the running wasm container. In other words, in an optional embodiment of this application, the edit events of the wasm container depend on the wasm runtime.

[0060] In practical applications, the Wasm runtime includes the WasmTime runtime, WasmMer runtime, WasmCloud runtime, and Wasm3 runtime. Since there is currently no unified standard for Wasm containers in the market, different vendors have different specifications regarding networking, threads, etc. Therefore, this application provides multiple optional runtimes to implement different Wasm container solutions according to different needs.

[0061] In order to respond to edit events in the target container, the appropriate wasm runtime needs to be invoked using the wasm engine, which can respond to wasm container edit events.

[0062] In an optional embodiment of this application, the container types include container containers and wasm containers. The container containers are scheduled using the Docker runtime, which is pulled using the Docker engine; the wasm containers are scheduled using the wasm runtime, which is pulled using the wasm engine. Both the Docker runtime and the wasm runtime are supported on the target node simultaneously for scheduling the container containers and wasm containers onto the target node.

[0063] As mentioned above, the proxy component krustlet in the target node deploys a provider component. This provider component is used to call the wasm engine and the docker engine. In addition, this provider component also calls corresponding provider methods (response methods) to respond to target container edit events. These provider methods are based on the container engine called by the provider component. The container engine pulls and runs the corresponding runtime to process the target container edit events. Optionally, the target container edit events include: adding a container, deleting a container, modifying a container, and querying a container. Specifically, for the add container event, the provider method performs a container creation operation based on the runtime called by the container engine; for the delete container event, the provider method performs a stop or delete container operation based on the runtime called by the container engine; for the modify container event, the provider method performs a container update operation based on the runtime called by the container engine; and for the query container event, the provider method performs a container query operation based on the runtime called by the container engine.

[0064] For example, suppose the Krator component listens to Kubernetes API 101 and receives a target container edit event that is an add Wasm container event. The provider component uses the provider method to call the Wasm engine. The Wasm engine pulls and calls the Wasm runtime, and performs the container creation operation through the Wasm runtime to complete the add Wasm container event.

[0065] In the above container editing method, if a target container editing event for the target node is detected, the container type corresponding to the target container editing event is determined. If the container type is a Wasm type, the Wasm engine is called, and then the Wasm runtime is called using the Wasm engine. The Wasm runtime is used to respond to the target container editing event, thus achieving the goal of running Wasm containers in traditional container cloud Kubernetes.

[0066] As mentioned above, the target node can deploy both container and Wasm container. Therefore, in the optional embodiments of this application, the container type corresponding to the target container edit event can be either a Wasm container or a container. Please refer to [link / reference]. Figure 3 It illustrates an optional technical process performed by the target node when the container type is a container, which includes the following steps:

[0067] Step 301: If the container type is container, then call the Docker engine.

[0068] This container type is a traditional Linux container that uses system calls from the UNIX operating system to change the root directory of a process and its child processes to a new location in the file system, allowing these processes to access only this new location, thereby achieving process isolation and realizing the function of a container.

[0069] In one possible implementation, as mentioned above, when the Krator component listens to Kubernetes API 101 and receives an edit event from the target container, it identifies the container type by tag. If the edit event of the target container does not contain a Wasm type tag, then the container type is determined to be a container type. Furthermore, the proxy component Krustlet in the target node deploys a provider component, which calls the Wasm engine to execute the next operation.

[0070] Step 302: Use the Docker engine to call the Docker runtime and respond to the target container's edit events based on the Docker runtime.

[0071] The Docker engine is the core process used to run and manage the Docker runtime. As mentioned above, the operation of a container depends on the runtime; therefore, in an optional embodiment of this application, the edit events of the container depend on the Docker runtime.

[0072] In one possible implementation, the aforementioned provider component may optionally call the corresponding provider method to pull and invoke the Docker runtime using the Docker engine, which can respond to container edit events.

[0073] For example, suppose the Krator component listens to Kubernetes API 101 and receives a target container edit event that is an event to add a container. The provider component uses the provider method to call the Docker engine. The Docker engine pulls and calls the Docker runtime, and performs the container creation operation through the Docker runtime to complete the event of adding a container.

[0074] As mentioned above, the proxy component krustlet can listen to Kubernetes API 101 and determine the target container's edit events. However, the krustlet proxy component requires several detailed steps to execute this listening process; please refer to [link to relevant documentation]. Figure 4 In one embodiment, the monitoring process further includes the following steps:

[0075] Step 401: If a target container edit event for the target node is detected, the target container edit event is placed in the task queue, where the task queue stores multiple container edit events for the target node.

[0076] The listening process is executed by the aforementioned krator component, which listens to Kubernetes API 101 to determine if there are any target container edit events. If a target container edit event for a target node is detected, the target container edit event is placed in a task queue. The task queue stores multiple container edit events for the target node, including edit events for container and / or wasm container.

[0077] In one possible implementation, the listening process is performed concurrently with the process of placing the target container edit event into the task queue. In other words, when the Krator component inserts the target container edit event into the task queue, the listening process does not pause. Instead, the Krator component continues to listen to Kubernetes API 101 and continuously executes the process of placing the target container edit event into the task queue.

[0078] Step 402: Extract container editing events sequentially from the task queue. When a target container editing event is extracted from the task queue, determine the container type corresponding to the target container editing event. If the container type is a Wasm type, call the Wasm engine, use the Wasm engine to call the Wasm runtime, and respond to the target container editing event based on the Wasm runtime.

[0079] The Krator component also performs the process of sequentially retrieving container edit events from the task queue and gradually completing the response to the target container edit events.

[0080] In one possible implementation, the Krator component retrieves container edit events sequentially from the task queue and responds to them one by one. When a target container edit event is retrieved from the task queue, the container type corresponding to the target container edit event is determined. Then, the provider component is called to use the provider method to execute the response to the target container edit event, thus driving the completion of all events in the task queue.

[0081] In an optional embodiment, the provider method performs the following steps: if the container type is wasm, then the wasm engine is invoked, the wasm runtime is invoked using the wasm engine, and the target container edit event is responded to based on the wasm runtime; if the container type is container, then the docker engine is invoked, the docker runtime is invoked using the docker engine, and the target container edit event is responded to based on the docker runtime.

[0082] Edit events for both the container and the wasm container are listened to and placed in the task queue. During the retrieval process from the task queue, it is necessary to determine the container type corresponding to the target container's edit event. In one embodiment, such as... Figure 5 As shown, a method for determining the container type corresponding to a target container edit event is provided, including the following steps:

[0083] Step 501: Detect whether the target container's edit event contains a wasm type tag.

[0084] Here, the wasm type label refers to a specific Kubernetes tolerations. These Kubernetes tolerations are attributes of a pod that allow certain pods to be scheduled onto a specified node. In this embodiment, the specific Kubernetes tolerations serve as a wasm type label for the target container, marking the target container as a wasm container.

[0085] In one possible implementation, the Krator component listens to Kubernetes API 101 to determine if there is an edit event for the target container and detects whether the edit event contains a wasm type tag in order to perform the next step of the judgment.

[0086] Step 502: If yes, then determine that the container type corresponding to the target container edit event is wasm type.

[0087] If not, then the container type corresponding to the target container edit event is determined to be of type container.

[0088] As described above, target container editing events include: adding a container, deleting a container, modifying a container, and querying a container. In an optional embodiment of this application, when the target container editing event is a container creation event, such as... Figure 6 As shown, a method for creating a container is provided, including the following steps:

[0089] Step 601: Create a wasm runtime using the wasm engine.

[0090] In one possible implementation, the aforementioned provider component uses the provider method to call the wasm engine, which pulls and invokes the wasm runtime.

[0091] Step 602: Create a wasm container based on the wasm runtime.

[0092] In one possible implementation, the aforementioned provider component performs the creation of a wasm container through the wasm runtime and completes the wasm container creation event.

[0093] To complete the creation of the wasm container event, the container image file corresponding to the target container editing event must first be obtained. The image file is then pulled from the process or local repository according to the pod's pull strategy. This image file refers to a single file made up of a series of specific files of the wasm container in a certain format. This single file extracts all the files required for the wasm container to run, enabling the wasm container to be created efficiently and comprehensively.

[0094] Furthermore, based on the wasm runtime, wasm containers are created using container image files.

[0095] As mentioned above, creating a Wasm container requires first obtaining the container image file corresponding to the target container's edit event. When this container image file becomes redundant, it needs to be deleted. In one embodiment of this application, such as... Figure 7 As shown, a method for deleting a container image file is provided, including the following steps:

[0096] Step 701: If an edit event for the target container of the target node is detected, check whether the container image file stored in the target node meets the deletion conditions.

[0097] The deletion condition refers to the fact that when the local disk space where the image files are stored reaches a certain threshold, the image files will be recycled, that is, the unused image files will be deleted.

[0098] Step 702: Delete the container image files that meet the deletion criteria from the target node.

[0099] In practical applications, deleting redundant image files is to save local disk space and improve process efficiency.

[0100] In addition to the container image files mentioned above that need to be deleted, containers on a node also need to be deleted when they malfunction. In one embodiment of this application, such as... Figure 8As shown, a method for deleting a container is provided, including the following steps:

[0101] Step 801: If an edit event for the target container of the target node is detected, monitor the survival status of each container in the target node.

[0102] The container's liveness status can optionally include: a container in a normal liveness status, or a container in a non-liveness status due to abnormal circumstances.

[0103] Step 802: Delete containers that are not alive from the target node.

[0104] In practical applications, deleting non-living containers is to ensure the normal operation of living containers on nodes and to avoid abnormal situations.

[0105] Furthermore, when a pod containing multiple containers of the same type in a node experiences an anomaly, it also needs to be deleted. In one embodiment of this application, such as... Figure 9 As shown, a method for deleting a pod is provided, including the following steps:

[0106] Step 901: If an edit event for the target container of the target node is detected, obtain the eviction policy.

[0107] The eviction policy is a process strategy for deleting pods. There are two possible scenarios for the deletion prerequisites. The first is to handle redundant pods. When a pod reaches the resource threshold of the target node, i.e., when resources are insufficient, the eviction policy will perform subsequent deletion processing steps on the redundant pod. The second is to handle abnormal pods. Through probe management, pod health checks are implemented. For example, if the probe detects that a pod is in a non-living state, the eviction policy is obtained through the API server, and the eviction policy will perform subsequent deletion processing steps on the non-living pod.

[0108] Step 902: Determine the first pod from multiple pods in the target node according to the eviction policy, and delete the first pod. The pod contains at least one container.

[0109] Optionally, the first pod can be a redundant or abnormal pod. For example, if the probe detects that the first pod is not alive, the eviction policy can directly delete the first pod.

[0110] As mentioned above, the state of a pod is not static. While a node is running, the state of its internal pods may change depending on various circumstances. Therefore, as... Figure 10As shown, when the pod state changes, embodiments of this application provide a method for handling pod state changes, including the following steps:

[0111] Step 1001: If an edit event for the target container on the target node is detected, then receive a state change event for the second pod on the target node.

[0112] The second pod state change event refers to a pod whose state has changed, such as a pod that becomes non-live due to an exception.

[0113] Step 1002: Modify the state of the second pod according to the state change event, and report the modified state of the second pod.

[0114] This reporting refers to reporting the status of the second pod after the change processing to the API server in Kubernetes API 101.

[0115] In practical applications, the API server receives not only information about pod status changes, but also container log information and node resource consumption messages. Below, embodiments of this application describe methods for reporting container log information and methods for reporting node resource consumption.

[0116] In one embodiment, a method for reporting container log information is provided, the method comprising: if a response request to a target container deployed in a target node is detected, then reporting the output result of the target container and / or the log information of the target container according to the response request.

[0117] In one embodiment, a method for reporting node resource consumption is provided, the method comprising: if an edit event of a target container for a target node is detected, periodically reporting the liveness status of the target node and / or the resource consumption status of the target node.

[0118] In one embodiment, such as Figure 11 As shown, a method for editing a container is provided, including the following steps:

[0119] Step 1101: If a target container edit event for the target node is detected, the target container edit event is placed in the task queue, where the task queue stores multiple container edit events for the target node.

[0120] Step 1102: Extract container edit events sequentially from the task queue and check whether the target container edit event contains a wasm type tag.

[0121] Step 1103: if yes, determine that the container type corresponding to the target container editing event is wasm type.

[0122] Step 1104: the target container editing event is an event for creating a container, and a container image file corresponding to the target container editing event is acquired.

[0123] Step 1105: call a wasm engine, and invoke a wasm runtime by means of the wasm engine, wherein the wasm runtime comprises a wasmtime runtime, a wasmer runtime, a wasmcloud runtime and a wasm3 runtime.

[0124] Step 1106: based on the wasm runtime, create a wasm container by using the container image file.

[0125] It can be seen from the foregoing content that an agent component in a target node is krustlet, and a plurality of components are deployed in the krustlet to perform different functions, such as Figure 12 which shows the plurality of components in the krustlet, hereinafter, in combination with Figure 12 the plurality of components in the krustlet and specific functions thereof are introduced.

[0126] Client (Chinese: 客户端): configured to interact with a kubernetes API 101 and establish communication with an API server.

[0127] Krator (Chinese: 监听组件): configured to listen whether there is a target container editing event of a target node on a kubernetes API 101, coordinate a cluster state and a required state by observing kubernetes resources and running a control loop; when a target container editing event for the target node is listened to, place the target container editing event in a task queue, and extract and execute the events sequentially. The process of listening the target container editing event for the target node is executed in step 201 and step 401 of the foregoing embodiment, and the process of sequentially extracting container editing events from the task queue is executed in step 402.

[0128] Hereinafter, as shown in Figure 13 the specific working process of the krator component is introduced as follows.

[0129] First, the Krator component initiates a watcher mechanism. This mechanism involves the Krator component continuously monitoring the API server in Kubernetes API 101 for pod spec changes (pod spec changes are container edit events). When it detects generate events (generate events are the aforementioned target container edit events for the target node), the Krator component further sends these generate events to the Kubernetes state control machine. The Kubernetes state control machine performs two functions: the first is to examine the status, which determines whether the generated events contain a WASM type tag to confirm the container type of the generated events, and feeds back the confirmation result to the subsequent container runtime; the second function is to launch a task, which places the generated events in the task queue. After the Kubernetes state control machine completes its two functions, the operator component within the Krator component continuously retrieves the generated events from the task queue and further calls the specific provider component to execute the corresponding response operation using the provider method. During this process, the Krator component reports the pod's status to the API server. Figure 13 The document only shows the `create / kill` response operations, i.e., the creation / deletion operations. Specifically, based on the container type confirmed by the `examine status`, the provider component calls the corresponding container engine, which in turn calls the container runtime to perform the creation / deletion of the container runtime operations, thereby completing the creation / deletion of the container and fulfilling the `generate` event. In addition, the target container edit events also include the aforementioned modification and query events, corresponding to update and query operations, which will not be elaborated upon here.

[0130] Webserver (English: web server): It is configured to act as a server to listen to the requirements for logs or operation results such as kubernetes' log, exec and the like, and feed back to the API server, and executes the step of reporting container log information in the foregoing embodiments.

[0131] Node updater (English: node updater): It is configured to periodically report the survival status and resource consumption of the target node, so that the API server can execute strategies such as load balancing, and executes the step of reporting node resource consumption in the foregoing embodiments.

[0132] Eviction (English: eviction component): It is configured to delete the pod when the node's eviction policy is reached, for example, when the node resource is insufficient, and executes the process of determining a first pod from a plurality of pods on the target node according to the eviction policy and deleting the first pod in step 902 of the foregoing embodiment.

[0133] Device manager (English: device manager): It is configured to manage GPU computing resources on the target node.

[0134] ImageService (English: image server): It is configured to pull images from the registry process or the local repository according to the image pulling policy of the pod, and executes the process of acquiring the container image file corresponding to the target container editing event in step 602 of the foregoing embodiment.

[0135] Volume manager (English: volume manager): It is configured to manage volume storage resources used by the pod on the target node.

[0136] Image GC (English: image garbage collector): It is configured to recover images of the target node. When the local disk space for storing local images reaches a certain threshold, image recovery will be triggered to delete images that are not used by pods, and executes the process of deleting container image files that meet the deletion conditions from the target node in step 702 of the foregoing embodiment.

[0137] ContainerGC (English: container garbage collector): It is configured to process containers in non-survival state on the target node, and automatically clean up residual containers on the target node when the container is in an abnormal state, and executes the process of deleting containers in non-survival state from the target node in step 802 of the foregoing embodiment.

[0138] Status Manager: configured to handle events of pod status change and update the status to the API server, and performs the process of changing the status of the second pod according to the status change event and reporting the status of the second pod after the change processing in step 1002 of the foregoing embodiment.

[0139] ProbeManager: implements the health check function of Pod. Currently, two types of probes are supported: LivenessProbe and ReadinessProbe. The LivenessProbe is used to determine whether a container is alive, and if it detects that the container is unhealthy, it will delete the container and perform corresponding processing according to the container's restart policy; the ReadinessProbe is used to determine whether the container has completed startup. It also performs the process of determining the first pod from a plurality of pods in the target node according to the eviction policy and deleting the first pod in step 902 of the foregoing embodiment.

[0140] Provider: configured to interact with specific runtime engines, optionally including a wasm engine and a docker engine, wherein the runtime engine calls the corresponding runtime to perform CRUD operations on wasm and docker containers, and reports the running status of wasm and container to the Status Manager, and the CRUD operations refer to creating and adding containers, stopping and deleting containers, updating and modifying containers, and querying containers. It performs calling the wasm engine if the container type is wasm type in step 202 of the foregoing embodiment; it performs calling the wasm runtime by means of the wasm engine and responding to the target container editing event based on the wasm runtime in step 203 of the foregoing embodiment; it performs calling the docker engine if the container type is container type in step 301 of the foregoing embodiment; it performs calling the docker runtime by means of the docker engine and responding to the target container editing event based on the docker runtime in step 302 of the foregoing embodiment; it performs creating the wasm runtime by means of the wasm engine in step 601 of the foregoing embodiment; it performs creating the wasm container based on the wasm runtime in step 602 of the foregoing embodiment.

[0141] Generic Runtime: In an optional embodiment of this application, the Generic Runtime includes Wasm Runtime and Docker, namely the aforementioned wasm runtime and docker runtime, wherein the wasm runtime includes wasmtime runtime, wasmer runtime, wasmcloud runtime and wasm3 runtime.

[0142] In summary, as Figure 14 As shown, the specific workflow of the krustlet component is described below, where... Figure 14 The components in the left box are the aforementioned components. Their specific functions will not be described here. They will only be used as examples to introduce the workflow of the krustlet components.

[0143] After the Krustlet component starts, it initiates communication with Kubernetes, creates a Krator component to listen to Kubernetes API 101, initializes relevant configurations within the node, starts the device manager and volume manager, sets up an eviction mechanism for periodically cleaning up pods, then creates a web server to respond to specific calls, and initializes the image service, image GC, container GC, status manager, and probe manager. Finally, it starts the node updater to continuously report node status to the Kubernetes API. In addition, when an edit event for a target container of a node is detected, the provider component is invoked. This provider component uses the provider method to call the wasm engine and the docker engine. Depending on the container type, different container engines are invoked. Optionally, the wasm engine pulls and invokes the wasm runtime to complete the edit event for the target container of the wasm container. The diagram only uses the wasm runtime as an example. The docker engine pulls and invokes the docker runtime to complete the edit event for the target container of the container.

[0144] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0145] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 15 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores container editing data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a container editing method.

[0146] Those skilled in the art will understand that Figure 15 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0147] In one embodiment, an apparatus is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to perform the following steps:

[0148] If an edit event for the target container of the target node is detected, the container type corresponding to the edit event is determined. If the container type is a Wasm type, the Wasm engine is invoked. The Wasm engine is used to invoke the Wasm runtime, and the target container edit event is responded to based on the Wasm runtime.

[0149] In one embodiment, when the processor executes a computer program, it performs the following steps: detecting whether the target container edit event contains a wasm type tag; if so, determining that the container type corresponding to the target container edit event is wasm type.

[0150] In one embodiment, when the processor executes a computer program, it performs the following steps: if the container type is container, it invokes the Docker engine, invokes the Docker runtime using the Docker engine, and responds to the target container edit event based on the Docker runtime.

[0151] In one embodiment, the target container edit event is the event for creating the container, and the processor executes the following steps when executing a computer program: creating a Wasm runtime using the Wasm engine; and creating a Wasm container based on the Wasm runtime.

[0152] In one embodiment, the processor executes the following steps when executing a computer program: obtaining a container image file corresponding to the target container edit event; and creating a wasm container using the container image file based on the wasm runtime.

[0153] In one embodiment, when the processor executes a computer program, it performs the following steps: if a target container edit event for a target node is detected, the target container edit event is placed in a task queue, wherein the task queue stores multiple container edit events for the target node; container edit events are sequentially retrieved from the task queue; when a target container edit event is retrieved from the task queue, the processor determines the container type corresponding to the target container edit event; if the container type is a Wasm type, the processor calls the Wasm engine, uses the Wasm engine to call the Wasm runtime, and responds to the target container edit event based on the Wasm runtime.

[0154] In one embodiment, the wasm runtime includes the wasmtime runtime, the wasmer runtime, the wasmcloud runtime, and the wasm3 runtime.

[0155] In one embodiment, when the processor executes a computer program, it performs the following steps: if a response request for a target container deployed in a target node is detected, the processor reports the output results and / or log information of the target container according to the response request.

[0156] In one embodiment, when the processor executes a computer program, it performs the following steps: if an edit event for a target container of a target node is detected, it periodically reports the liveness status of the target node and / or the resource consumption status of the target node.

[0157] In one embodiment, when the processor executes a computer program, it performs the following steps: if an edit event for a target container on a target node is detected, it obtains an eviction policy; determines a first pod from multiple pods on the target node according to the eviction policy, and deletes the first pod, wherein the pod contains at least one container.

[0158] In one embodiment, when the processor executes a computer program, it performs the following steps: if an edit event for a target container on a target node is detected, it checks whether the container image file stored in the target node meets the deletion criteria; and deletes the container image file that meets the deletion criteria from the target node.

[0159] In one embodiment, when the processor executes a computer program, it performs the following steps: if an edit event for a target container of a target node is detected, it monitors the liveness status of each container in the target node; and deletes containers that are not alive from the target node.

[0160] In one embodiment, when the processor executes a computer program, it performs the following steps: if an edit event for a target container on a target node is detected, it receives a state change event for a second pod on the target node; it performs a state change processing on the second pod according to the state change event, and reports the state of the second pod after the state change processing.

[0161] In one embodiment, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0162] If an edit event for the target container of the target node is detected, the container type corresponding to the edit event is determined. If the container type is a Wasm type, the Wasm engine is invoked. The Wasm engine is used to invoke the Wasm runtime, and the target container edit event is responded to based on the Wasm runtime.

[0163] In one embodiment, when the computer program is executed by the processor, it performs the following steps: detecting whether the target container edit event contains a wasm type tag; if so, determining that the container type corresponding to the target container edit event is wasm type.

[0164] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if the container type is container, it invokes the Docker engine, invokes the Docker runtime using the Docker engine, and responds to the target container edit event based on the Docker runtime.

[0165] In one embodiment, the target container edit event is the event that creates the container, and when the computer program is executed by the processor, it performs the following steps: creating a Wasm runtime using the Wasm engine; and creating a Wasm container based on the Wasm runtime.

[0166] In one embodiment, when the computer program is executed by the processor, it performs the following steps: obtaining a container image file corresponding to the target container edit event; and creating a wasm container using the container image file based on the wasm runtime.

[0167] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if a target container edit event for a target node is detected, the target container edit event is placed in a task queue, wherein the task queue stores multiple container edit events for the target node; container edit events are sequentially retrieved from the task queue; when a target container edit event is retrieved from the task queue, the process of determining the container type corresponding to the target container edit event is executed; if the container type is a Wasm type, the Wasm engine is invoked; the Wasm runtime is invoked using the Wasm engine; and the process of responding to the target container edit event based on the Wasm runtime is executed.

[0168] In one embodiment, the wasm runtime includes the wasmtime runtime, the wasmer runtime, the wasmcloud runtime, and the wasm3 runtime.

[0169] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if a response request for the target container deployed in the target node is detected, the output result and / or log information of the target container are reported according to the response request.

[0170] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for the target container of the target node is detected, it periodically reports the liveness status of the target node and / or the resource consumption status of the target node.

[0171] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container on a target node is detected, it obtains an eviction policy; determines a first pod from multiple pods on the target node according to the eviction policy, and deletes the first pod, wherein the pod contains at least one container.

[0172] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container on a target node is detected, it checks whether the container image file stored in the target node meets the deletion conditions; and deletes the container image file that meets the deletion conditions from the target node.

[0173] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container of a target node is detected, it monitors the liveness status of each container in the target node; and deletes containers that are not alive from the target node.

[0174] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for the target container of the target node is detected, it receives a state change event for the second pod in the target node; it performs a change processing on the state of the second pod according to the state change event, and reports the changed state of the second pod.

[0175] In one embodiment, a program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0176] If an edit event for the target container of the target node is detected, the container type corresponding to the edit event is determined. If the container type is a Wasm type, the Wasm engine is invoked. The Wasm engine is used to invoke the Wasm runtime, and the target container edit event is responded to based on the Wasm runtime.

[0177] In one embodiment, when the computer program is executed by the processor, it performs the following steps: detecting whether the target container edit event contains a wasm type tag; if so, determining that the container type corresponding to the target container edit event is wasm type.

[0178] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if the container type is container, it invokes the Docker engine, invokes the Docker runtime using the Docker engine, and responds to the target container edit event based on the Docker runtime.

[0179] In one embodiment, the target container edit event is the event that creates the container, and when the computer program is executed by the processor, it performs the following steps: creating a Wasm runtime using the Wasm engine; and creating a Wasm container based on the Wasm runtime.

[0180] In one embodiment, when the computer program is executed by the processor, it performs the following steps: obtaining a container image file corresponding to the target container edit event; and creating a wasm container using the container image file based on the wasm runtime.

[0181] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if a target container edit event for a target node is detected, the target container edit event is placed in a task queue, wherein the task queue stores multiple container edit events for the target node; container edit events are sequentially retrieved from the task queue; when a target container edit event is retrieved from the task queue, the process of determining the container type corresponding to the target container edit event is executed; if the container type is a Wasm type, the Wasm engine is invoked; the Wasm runtime is invoked using the Wasm engine; and the process of responding to the target container edit event based on the Wasm runtime is executed.

[0182] In one embodiment, the wasm runtime includes the wasmtime runtime, the wasmer runtime, the wasmcloud runtime, and the wasm3 runtime.

[0183] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if a response request for the target container deployed in the target node is detected, the output result and / or log information of the target container are reported according to the response request.

[0184] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for the target container of the target node is detected, it periodically reports the liveness status of the target node and / or the resource consumption status of the target node.

[0185] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container on a target node is detected, it obtains an eviction policy; determines a first pod from multiple pods on the target node according to the eviction policy, and deletes the first pod, wherein the pod contains at least one container.

[0186] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container on a target node is detected, it checks whether the container image file stored in the target node meets the deletion criteria; and deletes the container image file that meets the deletion criteria from the target node.

[0187] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for a target container on a target node is detected, it monitors the liveness status of each container in the target node; and deletes containers that are not alive from the target node.

[0188] In one embodiment, when the computer program is executed by the processor, it performs the following steps: if an edit event for the target container of the target node is detected, it receives a state change event for the second pod in the target node; it performs a change processing on the state of the second pod according to the state change event, and reports the changed state of the second pod.

[0189] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0190] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0191] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A container editing method, characterized in that, A krustlet proxy component for deployment on a target node that supports both Docker and WASM runtimes. The krustlet proxy component includes a krator component, a Kubernetes state controller, an operator component, a provider component, and a status manager. The method includes: The Krator component listens for pod spec changes on the API server in the Kubernetes API, obtains the target container edit event for the target node, and sends the target container edit event to the Kubernetes state controller. The Kubernetes state controller detects whether the target container edit event contains a wasm type tag and places the target container edit event in a task queue. The wasm type tag is a specific Kubernetes tolerations. The task queue stores multiple container edit events and / or wasm container edit events for the target node. If the target container editing event contains the wasm type tag, then the container type corresponding to the target container editing event is determined to be wasm type; if the target container editing event does not contain the wasm type tag, then the container type corresponding to the target container editing event is determined to be container type. The operator component sequentially extracts container edit events from the task queue, and when the target container edit event is extracted, the provider component is invoked to perform the response operation using the provider method; If the container type is WASM, then the provider component calls the WASM engine, the WASM engine calls the WASM runtime, and the WASM runtime responds to the target container's edit event. If the container type is container, then the provider component calls the Docker engine, the Docker engine calls the Docker runtime, and the Docker runtime responds to the target container's edit event. The target container editing events include add container events, delete container events, modify container events, and query container events. The provider method, based on the container runtime corresponding to the container type, performs container creation operation, stop or delete container operation, update container operation, and query container operation on the target container editing events respectively. The provider component reports the running status of the wasm container and the container container to the StatusManager, and the Status Manager processes pod status change events and updates the processed pod status to the API server.

2. The method according to claim 1, characterized in that, The target container edit event is the event that creates the container. The step of using the Wasm engine to call the Wasm runtime and responding to the target container edit event based on the Wasm runtime includes: The wasm runtime is created using the wasm engine; Create a wasm container based on the wasm runtime.

3. The method according to claim 2, characterized in that, The creation of the wasm container based on the wasm runtime includes: Obtain the container image file corresponding to the target container edit event; Based on the wasm runtime, the wasm container is created using the container image file.

4. The method according to any one of claims 1 to 3, characterized in that, The wasm runtime includes the wasmtime runtime, the wasmer runtime, the wasmcloud runtime, and the wasm3 runtime.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If a response request for the target container deployed in the target node is detected, the output result of the target container and / or the log information of the target container will be reported according to the response request.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If an edit event for the target container of the target node is detected, the liveness status of the target node and / or the resource consumption status of the target node are periodically reported.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If an edit event for the target container of the target node is detected, the eviction policy is obtained; According to the eviction policy, a first pod is determined from multiple pods in the target node, and the first pod is deleted. The pod contains at least one container.

8. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If an edit event for the target container of the target node is detected, check whether the container image file stored in the target node meets the deletion conditions; Delete the container image files that meet the deletion conditions from the target node.

9. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If an edit event for the target container of the target node is detected, the liveness status of each container in the target node is monitored. Remove containers that are not alive from the target node.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images