Communication method and device

Abstract

The invention provides a communication method and device, and the method comprises the steps: a sandbox corresponding to a first container group is operated, a first parameter used when the sandbox is operated comprises a runtime name of the first container group, and the runtime name of the first container group comprises a container or a virtual machine; a first container is created in the sandbox, a second parameter used when the first container is created comprises first container group annotation information, and the first container group annotation information is used for indicating a script of the life cycle of the virtual machine; the first container group comprises one or more first containers, by adopting the method and the device, coexistence of applications in two forms of a virtual machine and a container can be supported in a cloud platform, and the cost is saved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0002] Before the advent of containers, virtualization technology was arguably the dominant technology. During the evolution from virtual machines to containers, many services still prefer to retain their original virtual machine deployment model due to the high cost and difficulty of containerization.

[0003] Taking Kubernetes as an example, a cloud platform consists of several physical machines. Some of these machines host virtual machines (VMs) running business applications, while others host containers, also running business applications. However, Kubernetes only supports the orchestration of container applications and does not support the coexistence of both VMs and containers. Therefore, how to support the coexistence of VMs and containers in a cloud platform while saving costs is a technical problem that researchers in this field are currently solving. Summary of the Invention

[0004] This application proposes a communication method and apparatus that can support the coexistence of virtual machine and container applications in a cloud platform while saving costs.

[0005] In a first aspect, embodiments of this application provide a communication method applicable to a first node. This method can be executed by the first node, by components within the first node (e.g., processors, chips, circuits, or chip systems), or by a logic module or software capable of implementing all or part of the functions of the first node. The method includes: running a sandbox corresponding to a first container group, wherein a first parameter used when running the sandbox includes a runtime name of the first container group, which includes a container or a virtual machine; creating a first container in the sandbox, wherein a second parameter used when creating the first container includes first container group annotation information, which is a script used to indicate the lifecycle of a virtual machine; the first container group includes one or more first containers.

[0006] In the above method, the runtime name of the first container group (including container or virtual machine) can distinguish between container applications and virtual machine applications. The annotation information of the first container group can determine the lifecycle script of the virtual machine. In short, by abstracting the virtual machine into a virtual container, the virtual machine and the container are kept consistent. The lifecycle of the virtual machine is managed by reusing the lifecycle management logic and process of the container in the cloud platform, such as running sandboxes and creating containers. This allows the virtual machine to be managed by the cloud platform like a container. That is, it can support the coexistence of virtual machine and container applications in the cloud platform without adding additional components. In this way, the reliability is high and the platform resource overhead is small. Furthermore, the virtual machine application is declared using existing resources (such as container group resources). The field definition is simple, easy to understand, and has a low learning cost. There is no need to extend the cloud platform resources and increase the additional understanding and learning cost. In conclusion, the above method can support the coexistence of virtual machine and container applications in the cloud platform and save costs.

[0007] In one possible implementation, the first parameter also includes: the name of the first container group and / or the namespace of the first container group.

[0008] In another possible implementation, the second parameter may include at least one of the following: the sandbox's identification information, the name of the first container, or the container image name.

[0009] In another possible implementation, the runtime name of the first container group includes a virtual machine, and the sandbox corresponding to the first container group includes: determining the sandbox's identification information; establishing a mapping relationship between the sandbox's identification information and the runtime name of the first container group in a first mapping table, the first mapping table including a one-to-one correspondence between the sandbox's identification information and the runtime name of the first container group; and recording the status information of the sandbox corresponding to the sandbox's identification information as "ready" in a second mapping table, the second mapping table including a one-to-one correspondence between the sandbox's identification information and the sandbox's status information.

[0010] In the above method, virtual machines are abstracted into virtual containers, thus maintaining consistency between virtual machines and containers. The lifecycle management logic and processes of containers in the cloud platform are reused to manage the virtual machine lifecycle, such as by running a sandbox. This allows virtual machines to be managed by the cloud platform like containers, enabling the coexistence of both virtual machine and container-based applications within the cloud platform without adding extra components. This approach offers high reliability and low platform resource overhead. Furthermore, by running a sandbox, an isolated sandbox environment is created for the first container group, further protecting against various threats and attacks and ensuring security.

[0011] In another possible implementation, creating the first container in the sandbox includes: determining the runtime name of the first container group corresponding to the sandbox's identification information, including a virtual machine, based on the sandbox's identification information and a first mapping table; determining the script corresponding to create the virtual machine based on the annotation information of the first container group, and running the script to create the virtual machine; and determining the identification information of the virtual machine.

[0012] Among the above methods, the reliability is high, the implementation is simple, and the platform resource consumption is small.

[0013] In another possible implementation, the method further includes: recording the mapping relationship between the virtual machine's identification information and the first container group's annotation information in a third mapping table, wherein the third mapping table includes a one-to-one correspondence between the virtual machine's identification information and the first container group's annotation information; recording the mapping relationship between the virtual machine's identification information and the sandbox's identification information in a fourth mapping table, wherein the fourth mapping table includes a one-to-one correspondence between the virtual machine's identification information and the sandbox's identification information; and recording the virtual machine's status information corresponding to the virtual machine's identification information as "created" in a fifth mapping table, wherein the fifth mapping table includes a one-to-one correspondence between the virtual machine's identification information and the virtual machine's status information corresponding to the virtual machine's identification information.

[0014] Among the above methods, the reliability is high, the implementation is simple, and the platform resource consumption is small.

[0015] In another possible implementation, the method further includes: starting the first container, wherein the third parameter used when starting the first container includes: the identification information of the virtual machine.

[0016] In the above method, the virtual machine is abstracted into a virtual container, so that the virtual machine and the container are consistent. The life cycle of the virtual machine is managed by reusing the life cycle management logic and process of the container in the cloud platform. For example, the first container is started, so that the virtual machine can be managed by the cloud platform like a container. That is, it can support the coexistence of applications in both virtual machine and container forms in the cloud platform without adding additional components. In this way, the reliability is high and the platform resource overhead is small.

[0017] In another possible implementation, the third parameter may also include the name of the first container and / or the container image name.

[0018] In another possible implementation, starting the first container includes: determining the sandbox identifier information corresponding to the virtual machine's identifier information based on the virtual machine's identifier information and a fourth mapping table; determining the runtime name of the first container group corresponding to the sandbox identifier information, including the virtual machine, based on the sandbox identifier information and a first mapping table; determining the first container group annotation information corresponding to the virtual machine's identifier information based on the virtual machine's identifier information and a third mapping table; determining the script corresponding to starting the virtual machine based on the first container group annotation information, and running the script to start the virtual machine corresponding to the virtual machine's identifier information; and recording the status information of the virtual machine corresponding to the virtual machine's identifier information as "running" in a fifth mapping table.

[0019] The above method can start the first container with high reliability, simple implementation, and low resource consumption.

[0020] In another possible implementation, the method further includes: sending a second request message to query whether there are any container groups that need to be started, the first request message including the identification information of the first node; and receiving a second response message including a list of container groups, the list of container groups including the first container group.

[0021] In the above method, the first node can periodically send a second request message to the second node, thereby enabling the first node to effectively monitor and manage whether there are container groups that need to be started in the first node.

[0022] In another possible implementation, the method further includes: sending a third request message for pulling a container image, the third request message including a container image name; and receiving a third response message including a file stream of the container image corresponding to the container image name.

[0023] In the above method, the file stream of the container image corresponding to the container image name can be obtained, thereby quickly creating the container based on the file stream of the container image.

[0024] Secondly, embodiments of this application provide a communication method applicable to a second node. This method can be executed by the second node, by components within the second node (e.g., processors, chips, circuits, or chip systems), or by a logic module or software capable of implementing all or part of the second node's functions. The method includes: receiving a first request message, which requests the creation of a first container group. The first request message includes a runtime name of the first container group and / or annotation information for the first container group. The runtime name of the first container group includes a container or a virtual machine, and the annotation information is a script indicating the lifecycle of the virtual machine. Based on the first request message, resources corresponding to the first container group are created. A first response message is sent, which includes a message indicating successful creation.

[0025] In the above method, the container application or virtual machine application can be distinguished by the runtime name of the first container group, which includes the container or virtual machine. The virtual machine application is declared by existing resources (such as container group resources). The field definition is simple, easy to understand, and has a low learning cost. It does not require the expansion of cloud platform resources, thus avoiding additional understanding and learning costs.

[0026] In one possible implementation, the first request message may also include at least one of the following: the name of the first container group, the namespace of the first container group, or the name of the container image.

[0027] In another possible implementation, the method further includes: receiving a second request message for querying whether there are container groups that need to be started, the first request message including the identification information of the first node; and sending a second response message including a list of container groups, the list of container groups including the first container group.

[0028] In the above method, the first node can periodically send a second request message to the second node, and the second node can return a list of container groups, thereby enabling the first node to effectively monitor and manage whether there are any container groups that need to be started in the first node.

[0029] In another possible implementation, the method further includes: receiving a third request message for pulling a container image, the third request message including a container image name; and sending a third response message including a file stream of the container image corresponding to the container image name.

[0030] In the above method, the second node feeds back the file stream of the container image corresponding to the container image name to the first node, so that the first node can quickly create the container based on the file stream of the container image.

[0031] Thirdly, embodiments of this application provide a communication method applicable to a first node. This method can be executed by the first node, by components within the first node (e.g., processors, chips, circuits, or chip systems), or by a logic module or software capable of implementing all or part of the functions of the first node. The method includes: stopping a first container included in a first container group, wherein a first parameter used when stopping the first container includes: virtual machine identification information; deleting the first container, wherein a second parameter used when deleting the first container includes: the identification information of the virtual machine; the stopping of the first container included in the first container group and / or the deletion of the first container includes: based on the identification information of the virtual machine and a second parameter used when deleting the first container. A fourth mapping table determines the sandbox identification information corresponding to the virtual machine's identification information. This fourth mapping table includes a one-to-one correspondence between the virtual machine's identification information and the sandbox's identification information. Based on the sandbox's identification information and a first mapping table, the runtime name of the first container group corresponding to the sandbox's identification information is determined, which includes the virtual machine. This first mapping table includes a one-to-one correspondence between the sandbox's identification information and the first container group's runtime name. Based on the virtual machine's identification information and a third mapping table, the annotation information of the first container group corresponding to the virtual machine's identification information is determined. This first container group annotation information is used to indicate the scripts of the virtual machine's lifecycle. This third mapping table includes a one-to-one correspondence between the virtual machine's identification information and the first container group annotation information.

[0032] In the above method, virtual machines are abstracted into virtual containers, thus maintaining consistency between virtual machines and containers. The lifecycle management logic and processes of containers in the cloud platform are reused to manage the virtual machine's lifecycle—for example, stopping or deleting the first container. This allows virtual machines to be managed by the cloud platform like containers, enabling the coexistence of both virtual machine and container-based applications within the cloud platform without adding extra components. This approach offers high reliability and low platform resource overhead. Furthermore, virtual machine applications are declared using existing resources (such as container group resources), resulting in simple field definitions, easy understanding, and low learning costs. This eliminates the need to extend cloud platform resources, reducing additional understanding and learning costs. In summary, this method enables the coexistence of both virtual machine and container-based applications within the cloud platform while saving costs.

[0033] In one possible implementation, the first parameter may also include the name of the first container. Alternatively, the first parameter may also include the name of the first group of containers.

[0034] In another possible implementation, the second parameter may also include the name of the first container. Or, the second parameter may also include the name of the first group of containers.

[0035] In another possible implementation, stopping the first container included in the first container group further includes: determining the script corresponding to stopping the virtual machine based on the annotation information of the first container group, and running the script to stop the virtual machine corresponding to the identification information of the virtual machine; recording the status information of the virtual machine corresponding to the identification information of the virtual machine as "exited" in the fifth mapping table, wherein the fifth mapping table includes a one-to-one correspondence between the identification information of the virtual machine and the status information of the virtual machine corresponding to the identification information of the virtual machine.

[0036] The above method can stop the first container, has high reliability, is simple to implement, and has low resource overhead.

[0037] In another possible implementation, deleting the first container further includes: determining the script corresponding to the virtual machine to be deleted based on the annotation information of the first container group, and running the script to delete the virtual machine corresponding to the identification information of the virtual machine; deleting the mapping relationship between the identification information of the virtual machine and the first container group annotation information corresponding to the identification information of the virtual machine in the third mapping table; deleting the mapping relationship between the identification information of the virtual machine and the sandbox identification information corresponding to the identification information of the virtual machine in the fourth mapping table; and deleting the mapping relationship between the identification information of the virtual machine and the status information of the virtual machine corresponding to the identification information of the virtual machine in the fifth mapping table.

[0038] The above method can delete the first container, has high reliability, is simple to implement, and has low resource overhead.

[0039] In another possible implementation, the method further includes: stopping the sandbox corresponding to the first container, wherein the third parameter used when stopping the sandbox includes the sandbox's identification information; deleting the sandbox, wherein the fourth parameter used when deleting the sandbox includes the sandbox's identification information.

[0040] In the above method, virtual machines are abstracted into virtual containers, so that virtual machines and containers are consistent. The life cycle of virtual machines is managed by reusing the life cycle management logic and process of containers in the cloud platform. For example, stopping or deleting the sandbox makes the virtual machine managed by the cloud platform like a container. That is, it can support the coexistence of applications in both virtual machine and container forms in the cloud platform without adding additional components. In this way, the reliability is high and the platform resource overhead is small.

[0041] In another possible implementation, stopping the sandbox corresponding to the first container includes: determining the runtime name of the first container group corresponding to the sandbox's identification information, including a virtual machine, based on the sandbox's identification information and a first mapping table; recording the state information of the sandbox corresponding to the sandbox's identification information as not ready in a second mapping table, wherein the second mapping table includes a one-to-one correspondence between the sandbox's identification information and the sandbox's state information.

[0042] The above method can stop the sandbox, has high reliability, is simple to implement, and has low resource consumption.

[0043] In another possible implementation, deleting the sandbox includes: determining, based on the sandbox's identification information and the first mapping table, that the first container group runtime name corresponding to the sandbox's identification information includes a virtual machine; deleting the mapping relationship between the sandbox's identification information and the first container group runtime name corresponding to the sandbox's identification information in the first mapping table; and deleting the mapping relationship between the sandbox's identification information and the sandbox's status information corresponding to the sandbox's identification information in the second mapping table.

[0044] The above method can delete the sandbox, has high reliability, is simple to implement, and has low resource consumption.

[0045] In another possible implementation, the method further includes: sending a second request message for querying whether there are any container groups that need to be deleted, the second request message including the identification information of the first node; receiving a second response message including a list of container groups, the list of container groups including container groups to be deleted, the container groups to be deleted including the first container group.

[0046] In the above method, the first node can periodically send a second request message to the second node, so that the first node can effectively monitor and manage whether there are container groups in the first node that need to be deleted.

[0047] In another possible implementation, the method further includes: sending a third request message for requesting the deletion of template data corresponding to the first container group, wherein the second request message includes the identification information of the first container group and / or the namespace of the first container group.

[0048] Fourthly, embodiments of this application provide a communication method applicable to a second node, including execution by the second node, execution by components in the second node (e.g., processor, chip, circuit, or chip system), or execution by a logic module or software capable of implementing all or part of the functions of the second node. The method includes: receiving a first request message, the first request message being used to request the deletion of a first container group, the first request message including the runtime name of the first container group, the runtime name of the first container group including a virtual machine.

[0049] In the above method, virtual machines are abstracted into virtual containers, thus maintaining consistency between virtual machines and containers. The lifecycle management logic and processes of containers in the cloud platform are reused to manage the virtual machine's lifecycle—for example, stopping or deleting the first container. This allows virtual machines to be managed by the cloud platform like containers, enabling the coexistence of both virtual machine and container-based applications within the cloud platform without adding extra components. This approach offers high reliability and low platform resource overhead. Furthermore, virtual machine applications are declared using existing resources (such as container group resources), resulting in simple field definitions, easy understanding, and low learning costs. This eliminates the need to extend cloud platform resources, reducing additional understanding and learning costs. In summary, this method enables the coexistence of both virtual machine and container-based applications within the cloud platform while saving costs.

[0050] In another possible implementation, the method further includes: receiving a second request message for querying whether there are any container groups that need to be deleted, the second request message including the identification information of the first node; and sending a second response message including a list of container groups, the list of container groups including container groups to be deleted, the container groups to be deleted including the first container group.

[0051] In the above method, the first node can periodically send a second request message to the second node. In response, the second node returns a list of container groups to the first node, so that the first node can effectively monitor and manage whether there are any container groups in the first node that need to be deleted.

[0052] In another possible implementation, the method further includes: receiving a third request message, the third request message being used to request the deletion of template data corresponding to the first container group, the second request message including the identification information of the first container group and / or the namespace of the first container group; and sending a third response message, the third response message including that the template data corresponding to the first container group has been successfully deleted.

[0053] Fifthly, embodiments of this application provide a communication device, which may be a first node, a component of the first node (e.g., a processor, chip, circuit, or chip system), or a logic module or software capable of implementing all or part of the functions of the first node.

[0054] In one possible implementation, the communication device may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions described in the first aspect. These modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0055] In one possible implementation, the communication device includes: a processing unit and a transceiver unit. The processing unit is configured to run a sandbox corresponding to a first container group. A first parameter used when running the sandbox includes a runtime name of the first container group, which includes a container or a virtual machine. The processing unit is configured to create a first container in the sandbox. A second parameter used when creating the first container includes first container group annotation information, which is a script used to indicate the lifecycle of a virtual machine. The first container group includes one or more first containers.

[0056] In one possible implementation, the first container group runtime name includes a virtual machine. The processing unit is used to determine the sandbox identification information; the processing unit is used to establish a mapping relationship between the sandbox identification information and the first container group runtime name in a first mapping table, the first mapping table including a one-to-one correspondence between the sandbox identification information and the first container group runtime name; the processing unit is used to record the sandbox status information corresponding to the sandbox identification information as "ready" in a second mapping table, the second mapping table including a one-to-one correspondence between the sandbox identification information and the sandbox status information.

[0057] In another possible implementation, the processing unit is configured to determine, based on the sandbox's identification information and the first mapping table, the runtime name of the first container group corresponding to the sandbox's identification information, including the virtual machine; the processing unit is configured to determine, based on the first container group's annotation information, the corresponding script for creating the virtual machine, and run the script to create the virtual machine; the processing unit is configured to determine the identification information of the virtual machine.

[0058] In another possible implementation, the processing unit is further configured to record the mapping relationship between the virtual machine's identification information and the first container group's annotation information in a third mapping table, the third mapping table including a one-to-one correspondence between the virtual machine's identification information and the first container group's annotation information; the processing unit is further configured to record the mapping relationship between the virtual machine's identification information and the sandbox's identification information in a fourth mapping table, the fourth mapping table including a one-to-one correspondence between the virtual machine's identification information and the sandbox's identification information; the processing unit is further configured to record the virtual machine's status information corresponding to the virtual machine's identification information as "created" in a fifth mapping table, the fifth mapping table including a one-to-one correspondence between the virtual machine's identification information and the virtual machine's status information corresponding to the virtual machine's identification information.

[0059] In another possible implementation, the processing unit is also used to start the first container, and the third parameter used when starting the first container includes: the identification information of the virtual machine.

[0060] In another possible implementation, the processing unit is configured to: determine the sandbox identifier information corresponding to the virtual machine identifier information based on the virtual machine identifier information and the fourth mapping table; determine the first container group runtime name corresponding to the sandbox identifier information, including the virtual machine, based on the sandbox identifier information and the first mapping table; determine the first container group annotation information corresponding to the virtual machine identifier information based on the virtual machine identifier information and the third mapping table; determine the script corresponding to start the virtual machine based on the first container group annotation information, and run the script to start the virtual machine corresponding to the virtual machine identifier information; and record the status information of the virtual machine corresponding to the virtual machine identifier information as "running" in the fifth mapping table.

[0061] For the technical effects of the fifth aspect or possible implementation, please refer to the introduction of the technical effects of the first aspect or corresponding implementation.

[0062] Sixthly, embodiments of this application provide a communication device, which can be a second node, a component in the second node (e.g., a processor, chip, circuit, or chip system), or a logic module or software capable of implementing all or part of the functions of the second node.

[0063] In one possible implementation, the communication device may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions described in the second aspect. These modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0064] In one possible implementation, the communication device includes: a processing unit and a transceiver unit. The transceiver unit is configured to receive a first request message, which requests the creation of a first container group. The first request message includes a runtime name of the first container group and / or annotation information of the first container group. The runtime name of the first container group includes a container or a virtual machine. The annotation information of the first container group is used to indicate a script for the lifecycle of the virtual machine. The processing unit is configured to create resources corresponding to the first container group based on the first request message. The transceiver unit is further configured to send a first response message, which includes a message indicating successful creation.

[0065] For the technical effects of the sixth aspect or possible implementation, please refer to the introduction of the technical effects of the second aspect or corresponding implementation.

[0066] In a seventh aspect, embodiments of this application provide a communication device, which may be a first node, a component of the first node (e.g., a processor, chip, circuit, or chip system), or a logic module or software capable of implementing all or part of the functions of the first node.

[0067] In one possible implementation, the communication device may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions described in the third aspect. These modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0068] In one possible implementation, the communication device includes: a processing unit and a transceiver unit. The processing unit is configured to: stop a first container included in a first container group, wherein a first parameter used when stopping the first container includes: virtual machine identification information; delete the first container, wherein a second parameter used when deleting the first container includes: virtual machine identification information; determine, based on the virtual machine identification information and a fourth mapping table, the sandbox identification information corresponding to the virtual machine identification information is determined, wherein the fourth mapping table includes a one-to-one correspondence between virtual machine identification information and sandbox identification information; determine, based on the sandbox identification information and the first mapping table, the runtime name of the first container group corresponding to the sandbox identification information includes the virtual machine, wherein the first mapping table includes a one-to-one correspondence between sandbox identification information and the runtime name of the first container group; and determine, based on the virtual machine identification information and a third mapping table, the annotation information of the first container group corresponding to the virtual machine identification information is determined, wherein the annotation information of the first container group is a script used to indicate the lifecycle of the virtual machine, and the third mapping table includes a one-to-one correspondence between virtual machine identification information and the annotation information of the first container group.

[0069] In another possible implementation, the processing unit is further configured to determine the script corresponding to stop the virtual machine based on the first container group annotation information, and run the script to stop the virtual machine corresponding to the identification information of the virtual machine; the processing unit is further configured to record the status information of the virtual machine corresponding to the identification information of the virtual machine as "exited" in the fifth mapping table, the fifth mapping table including a one-to-one correspondence between the identification information of the virtual machine and the status information of the virtual machine corresponding to the identification information of the virtual machine.

[0070] In another possible implementation, the processing unit is further configured to determine the script corresponding to delete the virtual machine based on the first container group annotation information, and run the script to delete the virtual machine corresponding to the identification information of the virtual machine; the processing unit is further configured to delete the mapping relationship between the identification information of the virtual machine and the first container group annotation information corresponding to the identification information of the virtual machine in the third mapping table; the processing unit is further configured to delete the mapping relationship between the identification information of the virtual machine and the sandbox identification information corresponding to the identification information of the virtual machine in the fourth mapping table; the processing unit is further configured to delete the mapping relationship between the identification information of the virtual machine and the status information of the virtual machine corresponding to the identification information of the virtual machine in the fifth mapping table.

[0071] In another possible implementation, the processing unit is further configured to stop the sandbox corresponding to the first container, and the third parameter used when stopping the sandbox includes the sandbox's identification information; the processing unit is further configured to delete the sandbox, and the fourth parameter used when deleting the sandbox includes the sandbox's identification information.

[0072] In another possible implementation, the processing unit is configured to determine, based on the sandbox's identification information and the first mapping table, that the runtime name of the first container group corresponding to the sandbox's identification information includes a virtual machine; the processing unit is configured to record, in the second mapping table, the state information of the sandbox corresponding to the sandbox's identification information as not ready, and the second mapping table includes a one-to-one correspondence between the sandbox's identification information and the sandbox's state information.

[0073] In another possible implementation, the processing unit is configured to determine, based on the sandbox's identification information and the first mapping table, that the first container group runtime name corresponding to the sandbox's identification information includes a virtual machine; the processing unit is configured to delete the mapping relationship between the sandbox's identification information and the first container group runtime name corresponding to the sandbox's identification information in the first mapping table; and the processing unit is configured to delete the mapping relationship between the sandbox's identification information and the sandbox's status information corresponding to the sandbox's identification information in the second mapping table.

[0074] For the technical effects of the seventh aspect or possible implementation, please refer to the introduction of the technical effects of the third aspect or corresponding implementation.

[0075] Eighthly, embodiments of this application provide a communication device, which may be a second node, a component of the second node (e.g., a processor, chip, circuit, or chip system), or a logic module or software capable of implementing all or part of the functions of the second node.

[0076] In one possible implementation, the communication device may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions described in the fourth aspect. These modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0077] In one possible implementation, the communication device includes a processing unit and a transceiver unit, the transceiver unit being configured to receive a first request message, the first request message being configured to request the deletion of a first container group, the first request message including the runtime name of the first container group, the runtime name of the first container group including a virtual machine.

[0078] For the technical effects of the eighth aspect or possible implementation, please refer to the introduction of the technical effects of the fourth aspect or corresponding implementation.

[0079] Ninthly, embodiments of this application provide a communication device including at least one processor, which invokes a computer program or instructions stored in a memory to execute the method described in the first aspect or a possible implementation thereof.

[0080] In one possible implementation, the communication device also includes the memory. Alternatively, the memory and processor are integrated together.

[0081] In one possible implementation, the memory is located outside the communication device.

[0082] In a tenth aspect, embodiments of this application provide a communication device including at least one processor that invokes a computer program or instructions stored in a memory to execute the method described in the second aspect or a possible implementation thereof.

[0083] In one possible implementation, the communication device also includes the memory. Alternatively, the memory and processor are integrated together.

[0084] In one possible implementation, the memory is located outside the communication device.

[0085] Eleventhly, embodiments of this application provide a communication device, the communication device including at least one processor, the at least one processor calling a computer program or instructions stored in a memory to execute the method described in the third aspect or a possible implementation of the third aspect.

[0086] In one possible implementation, the communication device also includes the memory. Alternatively, the memory and processor are integrated together.

[0087] In one possible implementation, the memory is located outside the communication device.

[0088] In a twelfth aspect, embodiments of this application provide a communication device including at least one processor that invokes a computer program or instructions stored in a memory to execute the method described in the fourth aspect or a possible implementation thereof.

[0089] In one possible implementation, the communication device also includes the memory. Alternatively, the memory and processor are integrated together.

[0090] In one possible implementation, the memory is located outside the communication device.

[0091] In a thirteenth aspect, embodiments of this application provide a chip device including at least one processor for executing computer programs or instructions to implement any of the above aspects or possible implementations of any of the above aspects.

[0092] In one possible implementation, the input of the chip device corresponds to the receiving operation in any of the above-mentioned aspects or possible implementations, and the output of the chip device corresponds to the transmitting operation in any of the above-mentioned aspects or possible implementations.

[0093] Optionally, the processor is coupled to the memory via an interface.

[0094] Optionally, the chip device may also include a memory storing computer program instructions.

[0095] In a fourteenth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a processor, implement the methods described above.

[0096] In a fifteenth aspect, embodiments of this application provide a computer program product that includes a computer program or instructions that, when executed on a processor, implement the methods described above.

[0097] In a sixteenth aspect, embodiments of this application provide a communication system comprising: the means as described in the ninth aspect and the means as described in the tenth aspect, or the means as described in the eleventh aspect and the means as described in the twelfth aspect. Attached Figure Description

[0098] Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0099] Figure 2 This is a schematic diagram of the architecture of another communication system provided in the embodiments of this application;

[0100] Figure 3 This is a schematic diagram of the Kubernetes architecture;

[0101] Figure 4 This is a schematic diagram illustrating how a container runtime interface works.

[0102] Figure 5 This is a schematic diagram illustrating the orchestration and management of virtual machines;

[0103] Figure 6 This is a schematic diagram of a communication method provided in an embodiment of this application;

[0104] Figure 7 This is a schematic diagram of a Pod template provided in an embodiment of this application;

[0105] Figure 8 This is a schematic diagram of a sandbox corresponding to a first container group running on a first node, provided in an embodiment of this application;

[0106] Figure 9 This is a schematic diagram illustrating how a first node creates a first container in a sandbox, as provided in an embodiment of this application.

[0107] Figure 10 This is a schematic diagram illustrating how a first node starts a first container, as provided in an embodiment of this application.

[0108] Figure 11 This is a schematic diagram of yet another communication method provided in an embodiment of this application;

[0109] Figure 12 This is a schematic diagram of a first node stopping a first container included in a first container group, provided in an embodiment of this application;

[0110] Figure 13 This is a schematic diagram illustrating the deletion of a first container by a first node according to an embodiment of this application;

[0111] Figure 14 This is a schematic diagram of a first node stopping the sandbox corresponding to the first container, provided in an embodiment of this application;

[0112] Figure 15 This is a schematic diagram of a first node deleting a sandbox provided in an embodiment of this application;

[0113] Figures 16-17 This is a schematic diagram of yet another communication method provided in an embodiment of this application;

[0114] Figure 18 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0115] Figure 19 This is a schematic diagram of the structure of another communication device provided in the embodiments of this application. Detailed Implementation

[0116] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0117] References to "one embodiment" or "some embodiments" as described in this application mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0118] In the description of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, and c can be single or multiple.

[0119] It is understood that in this application, "instruction" can include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When describing a certain instruction information to indicate A, it can be understood that the instruction information carries A, directly indicates A, or indirectly indicates A.

[0120] In this application, the information indicated by the instruction information is called the information to be instructed. In specific implementations, there are many ways to instruct the information to be instructed, such as, but not limited to, directly instructing the information to be instructed, such as the information to be instructed itself or its index; indirectly instructing the information to be instructed by instructing other information, where there is a relationship between the other information and the information to be instructed; or instructing only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent.

[0121] The information to be instructed can be sent as a whole or divided into multiple sub-information messages, and the sending period and / or timing of these sub-information messages can be the same or different. This application does not limit the specific sending method. The sending period and / or timing of these sub-information messages can be predefined, for example, according to a protocol, or configured by the transmitting device by sending configuration information to the receiving device.

[0122] It is understood that "send" and "receive" in this application refer to the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information being XX, which can include direct transmission via the air interface or indirect transmission via the air interface from other units or modules. "Receive information from YY" can be understood as the source of the information being YY, which can include direct reception from YY via the air interface or indirect reception from YY via the air interface from other units or modules. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface.

[0123] In other words, sending and receiving can occur between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via buses, wiring, or interfaces.

[0124] It is understandable that information may undergo necessary processing, such as encoding and modulation, between the source and destination, but the destination can understand the valid information from the source. Similar statements in this application can be interpreted in a similar way and will not be elaborated further.

[0125] The communication method provided in this application can be applied to cellular communication systems related to the 3rd Generation Partnership Project (3GPP), such as 4th generation (4G) communication systems, such as Long Term Evolution (LTE) communication systems, and also to 5th generation (5G) communication systems, such as 5G New Radio (NR) communication systems, or to various future communication systems and future communication networks. The method provided in this application can also be applied to Bluetooth systems, Wireless Fidelity (WiFi) systems, LoRa systems, or vehicle-to-everything (V2X) systems, communication systems supporting the integration of multiple wireless technologies, and device-to-device (D2D) systems. The method provided in this application can also be applied to satellite communication systems, wherein the satellite communication system can be integrated with the above-mentioned communication systems. The wireless communication systems involved in this application also include, but are not limited to: narrowband Internet of Things (NB-IoT), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access 2000 (CDMA2000), or Time Division-Synchronization Code Division Multiple Access (TD-SCDMA).

[0126] Please see Figure 1 , Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application, to Figure 1 The application scenario used in this application is illustrated using the communication system architecture shown below. The communication system includes a first node 101 and a second node 102, both of which belong to a Kubernetes cluster. The first node can be a single server or a server cluster, and the second node can also be a single server or a server cluster.

[0127] The second node is the master node in Kubernetes, or simply the master node, responsible for managing and controlling all cluster resources. It can create, schedule, delete, and pull images from containers by sending requests to the first node. The second node contains the API server, scheduler, controller manager, and image repository. The API server, scheduler, and controller manager are components of Kubernetes.

[0128] The first node is the compute node in Kubernetes, also known as the runtime node. It's the node where the business application resides, carrying the actual workload, and exists in the form of containers or virtual machines. The first node is where kube-proxy and kubelet reside. Kube-proxy and kubelet are components in Kubernetes; further details about Kubernetes will be provided later. Figure 1 As shown, the first node includes a lifecycle controller and a lifecycle executor. For example, the lifecycle controller can be a kubelet, and the lifecycle executor can be a container runtime. The kubelet and the lifecycle executor communicate by calling the container runtime interface (CRI) to manage the lifecycle of containers and virtual machines. The lifecycle executor includes a decision-maker, which decides whether to call the container processor to manage the container's lifecycle or the virtual machine processor to manage the virtual machine's lifecycle. For example, the container processor manages the container's lifecycle through interface calls, such as a container engine (e.g., Docker), and the virtual machine processor manages the virtual machine's lifecycle through interface calls, such as a virtual machine manager. Managing the lifecycle of a container can include creating, starting, stopping, and deleting a container, managing its status, listing it, executing container commands, attaching to an existing container, and viewing its logs. Similarly, managing the lifecycle of a virtual machine can include creating, starting, stopping, and deleting a virtual machine, managing its status, listing it, executing virtual machine commands, attaching to an existing virtual machine, and viewing its logs.

[0129] Understandable Figure 1This application only illustrates one possible communication system architecture to which this embodiment can be applied. In other possible scenarios, the communication system architecture may also include other devices. It should be noted that the methods described in this application embodiment are applicable to... Figure 1 The aforementioned communication system.

[0130] Please see Figure 2 , Figure 2 This is a schematic diagram of another communication system architecture provided in this application embodiment. The communication system includes a first node 201 and a second node 202, both belonging to a Kubernetes cluster. The first node is a compute node in Kubernetes, or a runtime node, and is the node where the business application resides. The second node is a master node in Kubernetes, or a master node. The first node can be a single server or a server cluster, and the second node can also be a single server or a server cluster. Kubernetes manages several physical machines. Virtual machines are deployed on some of the physical machines in the first node, running business applications within them. Containers are also deployed on some of the physical machines in the first node, running business applications within them. It is understood that... Figure 2 This application only illustrates one possible communication system architecture to which this embodiment can be applied. In other possible scenarios, the communication system architecture may also include other devices. It should be noted that the methods described in this application embodiment are applicable to... Figure 2 The aforementioned communication system.

[0131] To better understand the solutions provided in the embodiments of this application, some terms, concepts or processes involved in the embodiments of this application will be introduced below.

[0132] First, let's introduce some terms that may be involved.

[0133] Containers: Similar to a lightweight sandbox, Docker can use containers to run and isolate applications.

[0134] A Pod is the smallest deployable unit of computing created and managed in Kubernetes. A Pod can contain one or more containers that can share the same network and storage resources and run on the same host.

[0135] Pod Sandbox: The parent process of all business containers, providing an isolated runtime environment that ensures that containers within the sandbox can only access resources within the sandbox.

[0136] Pod annotations: The parent process of all business containers, providing an isolated runtime environment that ensures that containers within the sandbox can only access resources within that sandbox.

[0137] Virtual Machine: A complete computer system with full hardware system functionality simulated by software, running in a completely isolated environment.

[0138] Image: A container image is a template used to create containers. It is a lightweight, executable, standalone software package that contains everything needed to run a piece of software, including code, runtime, libraries, environment variables, and configuration files.

[0139] Container: A container is a running instance of an image. Simply put, if an image is a class, then a running image is an instance. Containers can be started, stopped, and deleted. Each container is an isolated and secure platform.

[0140] A repository is a centralized place to store image files. There are two types of repositories: public and private. Users can download (pull) images published by others or upload (push) their own images. A repository can be seen as a code control center used to store images.

[0141] The relationship between images, containers, and repositories can be understood as follows: repositories are used to store images, images are templates for containers, and containers are running instances of images. You can pull images from a repository to your local machine, and then start one or more independent containers based on those images to run your application.

[0142] II. Kubernetes Architecture

[0143] Kubernetes, also known as k8s, is an open-source container cluster management system that provides application deployment and maintenance functions. In k8s, multiple containers can be created, each running an application instance. Built-in load balancing strategies enable the management, discovery, and access of this group of application instances. These details are handled by container deployment, eliminating the need for complex manual configuration and processing by operations personnel. Each container is isolated from the others, has its own file system, and processes within containers do not interfere with each other, allowing for the differentiation of computing resources.

[0144] Kubernetes (k8s) provides a convenient way to manage containerized applications running across multiple machines. k8s is a distributed system whose cluster architecture consists of multiple components, each responsible for different tasks. The k8s architecture uses a master-slave model; please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the Kubernetes architecture. In Kubernetes, the master node is used for the management and control of the entire cluster resources. It can create, schedule, delete, and pull images of container resources by sending requests to the master node. Compute nodes are the nodes where business applications reside, carrying the actual workload, and exist in the form of containers or virtual machines.

[0145] (1) Master node: The node where the API server, scheduler, controller manager, and image repository are located.

[0146] API server (kube-apiserver): It can be abbreviated as k8s api-server. It is mainly responsible for providing CRUD interfaces for various resources of the cluster to the outside world. It is the hub for data interaction and communication between various components in the cluster.

[0147] Scheduler (kube-scheduler): This is the scheduler component, often simply referred to as k8s kube-scheduler. It is primarily responsible for scheduling newly created containers to a specific node in the cluster, that is, assigning nodes to newly created containers.

[0148] The Controller Manager (kube-controller-manager) is the internal management and control center of the cluster. It can include multiple controllers and is mainly responsible for resource scheduling within the cluster.

[0149] (2) Compute node: The node where kube-proxy and kubelet are located.

[0150] kube-proxy: Primarily used to implement container network proxy on nodes, maintain network rules, and perform load balancing.

[0151] kubelet: Communicates with the master node and is a proxy service running on each node. It is mainly responsible for managing and monitoring containers on the node, including container lifecycle management, such as creating, starting, stopping, and destroying containers. It can also be used to monitor the status of containers and perform corresponding operations as needed to ensure that containers run normally.

[0152] III. Container Runtime Interface

[0153] Kubernetes (k8s) does not have a separate container engine. k8s itself does not provide a container runtime; instead, it runs and manages containers through container runtimes compatible with the Container Runtime Interface (CRI). CRI is a set of gRPC interfaces defined by k8s. The kubelet, as a client, manages containers by communicating with the container runtime via sockets, based on the gRPC framework. A container runtime is a type of software component that implements CRI for managing containers. Common container runtimes include Docker, Containerd, and CRI-O. Docker provides extensive functionality and tools for creating, packaging, and running containers. Containerd is a lightweight container runtime and one of the core components of Docker. It provides basic container management functionality and can be integrated with k8s as a container runtime for k8s. CRI-O is a lightweight container runtime specifically designed for k8s, conforming to the CRI specification and focusing on providing minimal container runtime functionality. CRI can be understood as three sets of gRPC interfaces: Sandbox interface, Container interface, and Image interface. It mainly includes two categories of services: runtime services and image services, as detailed below:

[0154] (1) Runtime service: mainly used to manage the lifecycle of sandboxes and containers, including sandbox startup (RunPodSandbox), sandbox stop (StopPodSandbox), sandbox deletion (RemovePodSandbox), and container creation (CreateContainer), container startup (StartContainer), container stop (StopContainer), container deletion (RemoveContainer) in a specified sandbox.

[0155] RunPodSandbox: When a kubelet requests a container to run, it creates a new Pod sandbox, providing network and file system isolation.

[0156] StopPodSandbox: The kubelet requests the container to stop a Pod sandbox.

[0157] RemovePodSandbox: The kubelet requests the container to remove a Pod sandbox.

[0158] Container creation (CreateContainer): When kubelet requests a container, it creates a new container in the Pod sandbox.

[0159] Container Startup (StartContainer): The kubelet starts an already created container when it requests a container to run.

[0160] StopContainer: The kubelet requests the container to stop the currently running container.

[0161] Container deletion (RemoveContainer): When kubelet requests a container to delete a stopped container.

[0162] (2) Image service: mainly used for container image management, including image download (PullImage), image query (ListImage), image deletion (RemoveImage), etc.

[0163] PullImage: The kubelet requests the container runtime to pull the specified container image.

[0164] Image lookup (ListImage): The kubelet requests the container runtime to list all container images stored locally.

[0165] RemoveImage: The kubelet requests the container runtime to delete the specified container image.

[0166] Software that implements this set of interfaces can be used as a container runtime to interface with kubelet, working together with kubelet to manage the entire lifecycle of the container. Please see [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of how a container runtime interface works. For example, kubelet acts as a client and communicates with the container runtime using CRI. Specifically, communication can be via the gRPC protocol, such as Containerd or CRI-O. The container runtime acts as a server, and it implements the logic of how to create the container. For example, the container engine on the node is Docker. Docker creates the container by calling components such as shim and runc, such as calling Docker's container creation interface (CreateContainer), and finally fulfilling the kubelet's request to create the container.

[0167] IV. Coexistence of Containers and Virtual Machines

[0168] Before the advent of containers, virtualization technology was virtually dominant. During the evolution from virtual machines to containers, many services still prefer to retain the original virtual machine application deployment model due to the high cost and difficulty of containerization. Many cloud vendors, including telecom cloud platforms, still require diversified application deployment models in the long term, meaning that virtual machine applications and container applications coexist on the same cloud platform. Taking a Kubernetes (k8s) cloud platform as an example, a cloud platform includes several physical machines. Some of these physical machines deploy virtual machines running business applications; others deploy containers, also running business applications. However, there are some issues: Kubernetes only supports the orchestration of container applications and does not support the coexistence of both virtual machine and container applications. Please see [link to relevant documentation]. Figure 5 , Figure 5 This diagram illustrates the orchestration and management of virtual machines. As shown, it involves Kubernetes and Kubevirt. Kubevirt includes virt-controller, virt-handler, and virt-launcher. The virt-controller is the controller, primarily used to manage and monitor Virtual Machine Instance (VMI) objects and their associated Pods, updating their status. The virt-handler is mainly used to manage all virtual machine instances on the host machine by monitoring the VMI and instance resources. The virt-launcher is mainly used to create virtual machines and is responsible for virtual machine lifecycle management. It should be noted that 1, 2, 3, ..., 15 in the diagram represent steps 1, 2, 3, ..., 15, each step as follows:

[0169] Step 1: The user determines the virtual machine's resource file, for example, the name of which can be kubectlapply -f vm.yaml, which calls the kube-apiserver interface in k8s to create the resource.

[0170] Step 2: After receiving the request, the Kubernetes API server will create a virtual machine (VM) resource object.

[0171] Step 3: virt-controller monitors VM resource objects.

[0172] Among them, virt-controller detected the creation of new VM resource objects.

[0173] Step 4: The virt-controller calls the k8s api-server to create a VMI object.

[0174] Step 5: Create VMI resources on the k8s api-server.

[0175] Step 6: virt-controller monitors VMI resources.

[0176] Among them, virt-controller detected the creation of a new VMI object.

[0177] Step 7: The virt-controller calls the k8s api-server to create the virt-launcher-xpod.

[0178] Step 8: The Kubernetes API server initiates the pod scheduling process.

[0179] This can be understood as follows: after the pod object is created, the k8s kube-scheduler will schedule the pod to a certain node.

[0180] Step 9: Create a virt-launcher pod on each node.

[0181] This can be understood as the virt-launcher on each node monitoring the pods bound to that node.

[0182] Step 10: virt-launcher updates the node name.

[0183] This can be understood as the virt-launcher updating the nodeName field of the corresponding VMI object.

[0184] Step 11: The virt-handler on each node monitors the node name of the VMI object to ensure it matches itself.

[0185] This can be understood as the virt-handler on each node listening for new VMI objects being created on its own node through the Informer.

[0186] Step 12: virt-handler sends a gRPC message to virt-launcher to start the virtual machine.

[0187] The gRPC message includes configuration information for the VMI object.

[0188] Step 13: virt-launcher calls the Libvirt API to start the virtual machine.

[0189] After receiving the configuration information of the VMI object, virt-launcher converts the configuration information of the VMI object into an XML file of the virtual machine, and then virt-launcher calls the Libvirt API to start the virtual machine.

[0190] Step 14: Start the virtual machine using the Libvirt API.

[0191] Step 15: Libvirt VM updates the virtual machine status of VMI.

[0192] The above method supports the coexistence of applications in both virtual machine and container forms. However, declaring virtual machine applications through custom virtual machine resources involves complex field definitions, is difficult to understand, and has a high learning curve. Moreover, this custom virtual machine lifecycle management process has a long call chain, low reliability, and high platform resource overhead. Therefore, how to support the coexistence of applications in both virtual machine and container forms while saving costs is a technical problem that those skilled in the art are currently solving. To solve the above problems, the embodiments of this application propose the following solutions.

[0193] Please see Figure 6 , Figure 6 This is a schematic diagram of a communication method provided in an embodiment of this application. The method includes, but is not limited to, the following steps:

[0194] Step S601: The second node receives the first request message.

[0195] Optionally, the second node receives a first request message from the user. This first request message is used to request the creation of a first container group, and includes the runtime name of the first container group and / or annotation information for the first container group. By sending the first request message to the second node, the user declares the desired virtual machine application to the second node.

[0196] The first container group runtime name includes either a container or a virtual machine. Alternatively, it can be described as indicating a container or a virtual machine. In one example, the first container group runtime name including a virtual machine could mean that the container group template includes the field `runtimeClassName`, and `runtimeClassName` is a virtual machine, for example, `pod.spec.runtimeClassName = vm`. In another example, if the container group template does not include the `runtimeClassName` field, it means that the first container group runtime name includes a container. In yet another example, if the container group template includes the field `runtimeClassName`, and `runtimeClassName = container`, it means that the first container group runtime name includes a container.

[0197] The first container group annotation information is used to indicate the scripts for the virtual machine's lifecycle. For example, the virtual machine's lifecycle includes creating a virtual machine, starting a virtual machine, stopping a virtual machine, removing a virtual machine, the virtual machine's status information, listing virtual machines, executing virtual machine commands, attaching to an existing virtual machine, and viewing virtual machine logs.

[0198] Optionally, the first request message may also include at least one of the following: the first container group name, the first container group namespace, or the container image name. The first container group namespace is an isolation mechanism in Kubernetes, where each container has its own separate namespace, and applications running within it function as if they were running in an independent operating system. Namespaces ensure that containers do not interfere with each other. In one example, container group 1 (pod1) and container group 2 (pod1) belong to namespace 1, and pod1 and pod2 can communicate with each other. Container group 3 (pod3) and container group 4 (pod4) belong to namespace 2, and pod3 and pod4 can communicate with each other. However, container groups under different namespaces cannot communicate; for example, pod3 and pod4 cannot communicate with pod1 and pod2. The container image name refers to the name of the template used to create the container. Container images are generally obtained through the image repository in the second node. For explanations of containers, images, and repositories, please refer to the above descriptions, which will not be repeated here.

[0199] In one possible implementation, the method further includes: the user configuring a container group template for the virtual machine application.

[0200] For example, before sending the first request message to the second node, the user configures the container group template for the virtual machine application. See also... Figure 7 , Figure 7This is a schematic diagram of a Pod template provided in an embodiment of this application. The container group template includes parameter information such as API version, type, metadata, and specifications. The metadata includes annotations, names, and namespaces. The annotations refer to the annotation information of the first container group, the names refer to the name of the first container group, and the namespaces refer to the namespace of the first container group. The specifications include containers, node selection, restart policies, and runtime names. Containers include images, image pull policies, and image names. Node selection includes the project name. The runtime name is the runtime name of the first container group. In one example, the user configures the runtime name of the virtual machine application's container group template to be vm, for example, pod.spec.runtimeClassName = vm, and the annotation (pod.metadata.annotations) configures the virtual machine's lifecycle script.

[0201] Step S602: The second node creates the resources corresponding to the first container group based on the first request message.

[0202] For example, the kube-apiserver in the second node creates the resources corresponding to the first container group based on the first request message. This creation of the resources by the second node based on the first request message can be understood as the second node storing key-value pairs in a database. The key of each key-value pair includes the namespace and name of the first container group, and the corresponding value includes the user-configured container group template.

[0203] Step S603: The second node sends a first response message to the first node.

[0204] The first response message includes "creation successful," which can be understood as the first container group being created successfully, and "creation successful" can be understood as the second node successfully storing the key-value pairs in the database.

[0205] Step S604: The first node runs the sandbox corresponding to the first container group.

[0206] In this context, the sandbox corresponding to the first container group, running on the first node, can refer to the kubelet on the second node. It communicates with the container runtime via the gpRC protocol, and the container runtime on the first node can call interfaces (e.g., runsandboxes) to run the sandbox environment corresponding to the first container group. In this way, an isolated sandbox environment can be created for the first container group.

[0207] The first parameter used when the first node runs the sandbox includes the runtime name of the first container group, which includes a container or a virtual machine. This first parameter may also include the name of the first container group and / or the namespace of the first container group.

[0208] For example, the runtime name of the first container group includes virtual machines, and the first node runs the sandbox corresponding to the first container group. Please refer to [link / reference]. Figure 8 , Figure 8 This is a schematic diagram of a sandbox corresponding to a first container group running on a first node, provided in an embodiment of this application, including steps S6041-S6043, as follows:

[0209] Step S6041: Determine the sandbox identification information.

[0210] Among them, determining the sandbox's identification information can refer to the identification information generated by the first node for the sandbox. The sandbox's identification information can be called the sandbox identity document (ID).

[0211] Step S6042: Establish a mapping relationship between the sandbox identification information and the runtime name of the first container group in the first mapping table.

[0212] The first mapping table can also be described as a runtime mapping table. The first mapping table includes a one-to-one correspondence between the sandbox's identification information and the runtime name of the first container group. In other words, the first mapping table includes a mapping relationship between the sandbox's identification information and the runtime name of the first container group. It can also be understood as the first mapping table containing key-value pairs, where the key contains the sandbox's identification information and the value corresponding to that key is the runtime name of the first container group. For example, please refer to Table 1, which is an example diagram of a first mapping table. As shown in the diagram, when the sandbox's identification information is SX1, the runtime name of the first container group corresponding to SX1 is vm.

[0213] Table 1

[0214] Serial Number Sandbox identification information First container group runtime name 1 SX1 vm 2 SX2 vm … … …

[0215] Step S6043: Record the status information of the sandbox corresponding to the sandbox's identification information as "ready" in the second mapping table.

[0216] The second mapping table can also be described as a sandbox status information (SandboxStatus) mapping table, and the record can also be described as a tag; this embodiment of the application does not limit this. The second mapping table includes a one-to-one correspondence between the sandbox's identification information and its status information, or in other words, the second mapping table includes a mapping relationship between the sandbox's identification information and its status information. It can also be understood that the second mapping table includes key-value pairs, where the key in the key-value pair includes the sandbox's identification information, and the value corresponding to the key is the sandbox's status information. For example, please refer to Table 2, which is an example diagram of a second mapping table. As shown in the diagram, when the sandbox's identification information is SX1, the status information of the sandbox corresponding to SX1 is "ready".

[0217] Table 2

[0218] Serial Number Sandbox identification information Sandbox status information 1 SX1 Ready 2 SX2 Not ready … … …

[0219] It should be noted that the above is for illustrative purposes only, and there is no obvious order between steps S6042 and S6043.

[0220] The above method enables the operation of a sandbox, thereby creating an isolated sandbox environment for the first container group, further protecting against various threats and attacks, and ensuring security.

[0221] In one possible implementation, the method further includes: the first node sending a second request message to the second node.

[0222] Optionally, this second request message may also be referred to as a query request message or a container group query request message.

[0223] For example, before the first node runs the sandbox corresponding to the first container group, the first node sends a second request message to the second node. The first node may periodically send the second request message to the second node.

[0224] The second request message is used to check if there are any container groups that need to be started. This second request message includes the identification information of the first node. Correspondingly, after receiving the second request message from the first node, the second node sends a second response message to the first node. This second response message includes a list of container groups, which includes the first container group. After receiving the second response message from the second node, the first node runs the sandbox corresponding to each newly created container group in the container group list. For example, if the container group list includes the first container group, and the first container group is a newly created container group, and this newly created container group is determined to be a container group of the first node, then the first node runs the sandbox corresponding to the first container group.

[0225] In the above method, the first node can periodically send a second request message to the second node, thereby enabling the first node to effectively monitor and manage whether there are container groups that need to be started in the first node.

[0226] Step S605: The first node creates the first container in the sandbox.

[0227] In this context, the creation of the first container in the sandbox by the first node can refer to the kubelet in the second node communicating with the container runtime via the gpRC protocol. The container runtime in the first node can call an interface (e.g., createContainer) to create the first container in the sandbox.

[0228] The second parameter used when creating the first container includes first container group annotation information, which is used to indicate the scripts for the virtual machine's lifecycle. The first container group includes one or more containers. Creating the first container in the sandbox by the first node can mean creating the first container group in the sandbox, where the first container group includes the first container. The second parameter may also include at least one of the following: sandbox identification information, the name of the first container, or the container image name.

[0229] For example, the first node creates the first container in the sandbox; see [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram of a first node creating a first container in a sandbox, provided by an embodiment of this application, including steps S6051-S6056, as detailed below:

[0230] Step S6051: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including the virtual machine, based on the sandbox's identification information and the first mapping table.

[0231] This process can be understood as searching the first mapping table based on the sandbox's identification information to determine the runtime name of the first container group corresponding to the sandbox's identification information, which includes virtual machines. In one example, as shown in Table 1, the sandbox's identification information is SX1. Based on SX1, searching the first mapping table determines that the runtime name of the first container group corresponding to SX1 is vm, indicating that the runtime name of the first container group corresponding to SX1 includes virtual machines.

[0232] Step S6052: Determine the corresponding script for creating the virtual machine based on the annotation information of the first container group, and run the script to create the virtual machine.

[0233] The first container group annotation information is used to indicate the scripts for the lifecycle of the virtual machine. That is, the first container group annotation information is used to indicate the scripts for creating the virtual machine, starting the virtual machine, stopping the virtual machine, and deleting the virtual machine. This process can be understood as parsing the first container group annotation information to determine the script for creating the virtual machine, running the script for creating the virtual machine, and thus creating the virtual machine.

[0234] For example, the first node can call the virtual machine management module in the first node to run the script to create a virtual machine.

[0235] Step S6053: Determine the identification information of the virtual machine.

[0236] In this context, determining the identification information of a virtual machine can be understood as the second node generating identification information for the virtual machine, which can be called the virtual machine ID.

[0237] Step S6054: Record the mapping relationship between the virtual machine's identification information and the first container group's annotation information in the third mapping table.

[0238] The third mapping table can also be described as an annotation mapping table, a container group annotation mapping table, etc., and the record can also be described as a tag; this application embodiment does not limit this. The third mapping table includes a one-to-one correspondence between the virtual machine's identification information and the first container group annotation information. In other words, the third mapping table includes a mapping relationship between the virtual machine's identification information and the first container group annotation information. It can also be understood as the third mapping table including key-value pairs, where the key includes the virtual machine's identification information, and the value corresponding to that key is the first container group annotation information. For example, please refer to Table 3, which is an example diagram of a third mapping table. As shown in the diagram, when the virtual machine's identification information is VM1, the first container group annotation information corresponding to VM1 is the virtual machine's lifecycle script.

[0239] Table 3

[0240] Serial Number Virtual machine identification information First container group annotation information 1 VM1 scripts for the virtual machine lifecycle 2 VM2 scripts for the virtual machine lifecycle … … …

[0241] Step S6055: Record the mapping relationship between the identification information of the virtual machine and the identification information of the sandbox in the fourth mapping table.

[0242] The fourth mapping table can also be described as a sandbox mapping table, and the record can be described as a tag; this embodiment of the application does not limit this. The fourth mapping table includes a one-to-one correspondence between the identification information of the virtual machine and the identification information of the sandbox. In other words, the fourth mapping table includes a mapping relationship between the identification information of the virtual machine and the identification information of the sandbox. It can also be understood as the fourth mapping table including key-value pairs, where the key in the key-value pair includes the identification information of the virtual machine, and the value corresponding to the key is the identification information of the sandbox. For example, please refer to Table 4, which is an example diagram of a fourth mapping table. As shown in the diagram, the identification information of the virtual machine is VM1, and the identification information of the sandbox corresponding to VM1 is SX1.

[0243] Table 4

[0244] Serial Number Virtual machine identification information Sandbox identification information 1 VM1 SX1 2 VM2 SX2 … … …

[0245] Step S6056: Record the virtual machine status information corresponding to the virtual machine's identification information as "created" in the fifth mapping table.

[0246] The fifth mapping table can also be described as a virtual machine status (VMStatus) mapping table, and the records can also be described as tags; this embodiment does not limit the description. The fifth mapping table includes a one-to-one correspondence between the identification information of a virtual machine and the corresponding virtual machine status information. Alternatively, the fifth mapping table includes a mapping relationship between the identification information of a virtual machine and the corresponding virtual machine status information. It can also be understood as including key-value pairs, where the key contains the identification information of the virtual machine, and the value corresponding to that key is the status information of the virtual machine. For example, please refer to Table 5, which is an example diagram of a fifth mapping table. As shown in the diagram, the identification information of the virtual machine is VM1, and the status information of the virtual machine corresponding to VM1 is "created".

[0247] Table 5

[0248] Serial Number Virtual machine identification information Virtual machine status information 1 VM1 Created 2 VM2 Running … … …

[0249] It should be noted that the above is for illustrative purposes only, and there is no obvious order between steps S6054, S6055, and S6056.

[0250] The above method enables the creation of the first container in the sandbox, offering high reliability, simple implementation, and low platform resource overhead.

[0251] In one possible implementation, the method further includes: the first node sending a third request message.

[0252] The third request message is used to pull the container image, and the third request message includes the container image name.

[0253] Optionally, before creating the first container in the sandbox, the first node sends a third request message to the second node, and the second node receives the third request message from the first node. Optionally, sending the third request message from the first node to the second node could mean the first node sends a third request message to the image repository in the second node. After receiving the third request message from the first node, the second node sends a third response message to the first node. The third response message includes the file stream of the container image corresponding to the container image name. Accordingly, the first node can create the first container based on the file stream of the container image corresponding to that container image name.

[0254] In the above method, the file stream of the container image corresponding to the container image name can be obtained, thereby quickly creating the container based on the file stream of the container image.

[0255] Step S606: The first node starts the first container.

[0256] In this context, "starting the first container on the first node" refers to the kubelet in the second node communicating with the container runtime via the gpRC protocol. The container runtime in the first node can call an interface (e.g., startContainer) to start the first container.

[0257] The third parameter used when the first node starts the first container includes the identification information of the virtual machine. Optionally, the identification information of the virtual machine can also be referred to as the identification information of the container. The third parameter may also include the name of the first container and / or the container image name.

[0258] For example, the first node starts the first container; see [link to relevant documentation]. Figure 10 , Figure 10 This is a schematic diagram of a first node starting a first container according to an embodiment of this application, including steps S6061-S6065, as detailed below:

[0259] Step S6061: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0260] This process can be understood as retrieving the sandbox identifier information corresponding to the virtual machine's identifier information from the fourth mapping table. In one example, see Table 4, where the virtual machine's identifier information is VM1, and the sandbox identifier information corresponding to VM1 is determined to be SX1 from the fourth mapping table.

[0261] Step S6062: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0262] This process can be understood as follows: based on the sandbox's identification information, the first container group runtime name corresponding to the sandbox's identification information is searched from the first mapping table to determine if it includes virtual machines. For details, please refer to the relevant description in step S6051. In one example, as shown in Table 1, the sandbox's identification information is SX1. Based on SX1, the first container group runtime name corresponding to SX1 is determined from the first mapping table to be vm, indicating that the first container group runtime name corresponding to SX1 includes virtual machines.

[0263] Step S6063: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0264] This process can be understood as using the virtual machine's identification information to look up the first container group annotation information corresponding to the virtual machine's identification information from the third mapping table.

[0265] Step S6064: Determine the script corresponding to start the virtual machine based on the annotation information of the first container group, and run the script to start the virtual machine corresponding to the identification information of the virtual machine.

[0266] This process can be understood as parsing the annotation information of the first container group to determine the corresponding script for starting the virtual machine, running the corresponding script for starting the virtual machine, and thus starting the virtual machine.

[0267] For example, the first node can call the virtual machine management module in the first node to run the script to start the virtual machine.

[0268] Step S6065: Record the virtual machine status information corresponding to the virtual machine's identification information as "running" in the fifth mapping table.

[0269] In this application, the record can also be replaced with a marker, which is not limited in this embodiment. For example, before the virtual machine's status information corresponding to the virtual machine's identification information is recorded as "running" in the fifth mapping table, the first node searches the fifth mapping table based on the virtual machine's identification information to determine the virtual machine's status information corresponding to the virtual machine's identification information, and modifies the found virtual machine's status information from "created" to "running". For example, if the virtual machine's identification information is VM1, and the fifth mapping table shows that the virtual machine's status information corresponding to VM1 is "created", then the virtual machine's status information from "created" is modified to "running".

[0270] The above method enables the startup of the first container with high reliability, simple implementation, and low platform resource overhead.

[0271] In summary, the mapping tables involved in the embodiments of this application are described below. Please refer to Table 6, which specifically includes a first mapping table, a second mapping table, a third mapping table, a fourth mapping table, and a fifth mapping table. For example, the first mapping table includes key-value pairs, where the key in each key-value pair includes the sandbox's identification information, and the value corresponding to that key is the runtime name of the first container group. The second mapping table includes key-value pairs, where the key in each key-value pair includes the sandbox's identification information, and the value corresponding to that key is the sandbox's status information. The third mapping table includes key-value pairs, where the key in each key-value pair includes the virtual machine's identification information, and the value corresponding to that key is the first container group's annotation information. The fourth mapping table includes key-value pairs, where the key in each key-value pair includes the virtual machine's identification information, and the value corresponding to that key is the sandbox's identification information. The fifth mapping table includes key-value pairs, where the key in each key-value pair includes the virtual machine's identification information, and the value corresponding to that key is the virtual machine's status information.

[0272] Table 6

[0273]

[0274] exist Figure 6 In the described method, the runtime name of the first container group (including container or virtual machine) can distinguish between container applications and virtual machine applications. The annotation information of the first container group can determine the script for the lifecycle of the virtual machine. In short, by abstracting the virtual machine into a virtual container, the virtual machine is kept consistent with the container. The lifecycle of the virtual machine is managed by reusing the lifecycle management logic and process of the container in the cloud platform. Through the above process, the process of managing the creation and startup of virtual machines in the cloud platform can be realized. For example, the process of managing the creation and startup of virtual machines in the cloud platform is implemented through the container runtime interface, so that the virtual machine is managed by the cloud platform like a container. That is, it can support the coexistence of applications in both virtual machine and container forms in the cloud platform without adding additional components. In this way, the reliability is high and the platform resource overhead is small. Furthermore, the virtual machine application is declared using existing resources (such as container group resources). The field definition is simple, easy to understand, and has a low learning cost. There is no need to extend the cloud platform resources and increase the additional understanding and learning cost. In short, through the above method, it is possible to support the coexistence of applications in both virtual machine and container forms in the cloud platform and save costs. In other words, it provides a diversified application deployment model for cloud platforms at low cost, enabling virtual machine applications and container applications to coexist, and providing transition capabilities for completing the cloud-native migration.

[0275] Please see Figure 11 , Figure 11 This is a schematic diagram of another communication method provided in an embodiment of this application, which includes, but is not limited to, the following steps:

[0276] Step S1101: The second node receives the first request message.

[0277] For example, the second node receives a first request message from the user.

[0278] The first request message is used to request the deletion of the first container group. The first request message includes the runtime name of the first container group, which includes the virtual machine. Optionally, the first request message may also include the first container group name and / or the first container group namespace. For details regarding the first container group runtime name, the first container group name, and the first container group namespace, please refer to the relevant description in step S601, which will not be repeated here. Through this first request message, the user can declare to the Kubernetes cluster that they wish to delete the virtual machine application.

[0279] In another possible implementation, the method further includes: the user determining a container group whose runtime name includes a virtual machine, and determining the container group name and the container group namespace. In one example, the user determines a container group that satisfies the condition pod.spec.runtimeClassName = vm, determines the container group name as the first container group, and the container group namespace as namespace 1.

[0280] In another possible implementation, the method further includes: the first node sending a second request message.

[0281] Optionally, this second request message may also be referred to as a query request message or a container group query request message.

[0282] The second request message is used to query whether there are any container groups that need to be deleted. The second request message includes the identification information of the first node.

[0283] For example, the first node sending a second request message can mean that the first node sends a second request message to the second node. Correspondingly, the second node receives the second request message from the first node and sends a second response message to the first node. This second response message includes a list of container groups, which includes container groups to be deleted, including the first container group. The containers included in the container groups to be deleted include the first containers in the first container group. Accordingly, the first node determines that the container groups to be deleted belong to this node based on the container group list, and for the container groups to be deleted, it begins stopping the containers under those container groups.

[0284] Step S1102: The first node stops the first container included in the first container group.

[0285] The first parameter used when stopping the first container includes the virtual machine's identification information. Optionally, this virtual machine identification information can also be called the container's identification information, or simply the container ID. The first parameter may also include the name of the first container. This method allows for the cleanup of container group resources.

[0286] For example, the first node stops the first container included in the first container group; see [link to relevant documentation]. Figure 12 , Figure 12 This is a schematic diagram of a first node stopping a first container in a first container group, provided by an embodiment of this application, including steps S11021-10025, as follows:

[0287] Step S11021: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0288] The fourth mapping table includes a one-to-one correspondence between the identification information of virtual machines and the identification information of sandboxes. For a related explanation of the fourth mapping table, please refer to the above description, which will not be repeated here.

[0289] For example, determining the sandbox identifier information corresponding to the virtual machine's identifier information based on the virtual machine's identifier information and the fourth mapping table can be understood as searching the fourth mapping table based on the virtual machine's identifier information to determine the sandbox identifier information corresponding to the virtual machine's identifier information. In one example, please refer to Table 4. The virtual machine's identifier information is VM1. Searching the fourth mapping table, the sandbox identifier information corresponding to VM1 is determined to be SX1.

[0290] Step S11022: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0291] The first mapping table includes a one-to-one correspondence between the sandbox identification information and the runtime name of the first container group. For a related explanation of the first mapping table, please refer to the above description, which will not be repeated here.

[0292] For example, determining that the first container group runtime name corresponding to the sandbox's identification information includes virtual machines, based on the sandbox's identification information and the first mapping table, can be understood as searching the first mapping table based on the sandbox's identification information to determine the first container group runtime name corresponding to the sandbox's identification information, and this first container group runtime name includes virtual machines. In one example, please refer to Table 1. The sandbox's identification information is SX1. Searching the first mapping table, it is determined that the first container group runtime name corresponding to SX1 is vm, that is, it is determined that the first container group runtime name includes virtual machines.

[0293] Step S11023: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0294] The first container group annotation information is used to indicate the lifecycle of the virtual machine. The third mapping table includes a one-to-one correspondence between the identification information of the virtual machine and the first container group annotation information. For relevant explanations of the first container group annotation information and the first mapping table, please refer to Table 1 above. It will not be repeated here.

[0295] For example, determining the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table can be understood as searching the third mapping table based on the virtual machine's identification information to determine the first container group annotation information corresponding to the virtual machine's identification information. In one example, please refer to Table 3, where the virtual machine's identification information is VM1, and the first container group annotation information corresponding to VM1 is determined by searching the third mapping table.

[0296] Step S11024: Determine the script corresponding to stop the virtual machine based on the annotation information of the first container group, and run the script to stop the virtual machine corresponding to the identification information of the virtual machine.

[0297] This process can be understood as parsing the annotation information of the first container group to determine the corresponding script for stopping the virtual machine, running the corresponding script for stopping the virtual machine, and thus stopping the virtual machine.

[0298] For example, the first node can call the virtual machine management module in the first node to run the script to stop the virtual machine.

[0299] Step S11025: Record the virtual machine status information corresponding to the virtual machine's identification information as "exited" in the fifth mapping table.

[0300] The fifth mapping table includes a one-to-one correspondence between the identification information of the virtual machine and the status information of the virtual machine corresponding to the identification information. For a description of the fifth mapping table, please refer to the above description, which will not be repeated here.

[0301] For example, the record can also be replaced with a tag, which is not limited in this embodiment. For example, before the status information of the virtual machine corresponding to the identification information of the virtual machine is recorded as "exited" in the fifth mapping table, the first node searches the fifth mapping table based on the identification information of the virtual machine to determine the status information of the virtual machine corresponding to the identification information of the virtual machine, and modifies the status information of the found virtual machine from "running" to "exited". For example, if the identification information of the virtual machine is VM1, the status information of the virtual machine corresponding to VM1 is found to be "running" in the fifth mapping table, and the status information of the virtual machine "running" is modified to "exited".

[0302] The above method can stop the first container, has high reliability, is simple to implement, and has low resource overhead.

[0303] Step S1103: The first node deletes the first container.

[0304] The second parameter used when deleting the first container includes the virtual machine's identification information. This second parameter may also include the name of the first container. Alternatively, it may include the name of the first container group. Deleting the first container from the first node can also mean that the first node deletes the first container group, or that it deletes the containers included in the first container group.

[0305] For example, the first node deletes the first container; see [link to example]. Figure 13 , Figure 13 This is a schematic diagram of a first node deleting a first container according to an embodiment of this application, including steps S11031-S11037, as detailed below:

[0306] Step S11031: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0307] Step S11032: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0308] Step S11033: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0309] For details regarding steps S11031-S11033, please refer to the relevant descriptions in steps S11021-S11023; they will not be repeated here.

[0310] Step S11034: Determine the script corresponding to delete the virtual machine based on the annotation information of the first container group, and run the script to delete the virtual machine corresponding to the identification information of the virtual machine.

[0311] This process can be understood as parsing the annotation information of the first container group to determine the corresponding script for deleting the virtual machine, running the corresponding script for deleting the virtual machine, and thus deleting the virtual machine.

[0312] For example, the first node can call the virtual machine management module in the first node to run the script to delete the virtual machine.

[0313] Step S11035: Delete the mapping relationship between the virtual machine's identification information and the first container group annotation information corresponding to the virtual machine's identification information in the third mapping table.

[0314] The relevant description of the third mapping table can be found above and will not be repeated here. In one example, please refer to Table 3. The identification information of the virtual machine is VM1. The mapping relationship between VM1 and the first container group annotation information corresponding to VM1 is deleted.

[0315] Step S11036: Delete the mapping relationship between the identification information of the virtual machine and the identification information of the sandbox corresponding to the identification information of the virtual machine in the fourth mapping table.

[0316] The relevant description of the fourth mapping table can be found above and will not be repeated here. In one example, please refer to Table 4. The identification information of the virtual machine is VM1, and the identification information of the sandbox corresponding to VM1 is SX1. The mapping relationship between VM1 and SX1 corresponding to SM1 is deleted.

[0317] Step S11037: Delete the mapping relationship between the virtual machine's identification information and the virtual machine's status information corresponding to the virtual machine's identification information in the fifth mapping table.

[0318] The relevant description of the fourth mapping table can be found above and will not be repeated here. Optionally, the status information corresponding to the virtual identifier can be "exited". In one example, the virtual machine identifier is VM1, and the status information of the virtual machine corresponding to VM1 is "exited". The mapping relationship between VM1 and the "exited" status of VM1 is deleted.

[0319] It should be noted that the above is for illustrative purposes only, and there is no obvious order between steps S11035, S11036, and S11037.

[0320] The above method can delete the first container, has high reliability, is simple to implement, and has low resource overhead.

[0321] Step S1104: The first node stops the sandbox corresponding to the first container.

[0322] The third parameter used when stopping a sandbox includes the sandbox's identification information. Stopping the sandbox corresponding to the first container can also mean stopping the sandbox corresponding to the first container group.

[0323] For example, the first node stops the sandbox corresponding to the first container; please refer to [link / reference]. Figure 14 , Figure 14 This is a schematic diagram of a first node stopping the sandbox corresponding to the first container according to an embodiment of this application, including steps S11041-S11042, as follows:

[0324] Step S11041: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0325] The relevant description of the first mapping table can be found above, and will not be repeated here.

[0326] This process can be understood as follows: based on the sandbox's identification information, a lookup is performed in the first mapping table to determine that the first container group runtime name corresponding to the sandbox's identification information includes virtual machines. In one example, please refer to Table 1. The sandbox's identification information is SX1. A lookup in the first mapping table determines that the first container group runtime name corresponding to SX1 is vm, that is, the first container group runtime name includes virtual machines.

[0327] Step S11042: Record the status information of the sandbox corresponding to the sandbox's identification information as "not ready" in the second mapping table.

[0328] The second mapping table includes a one-to-one correspondence between the sandbox's identification information and its status information. For a description of the second mapping table, please refer to the above description, which will not be repeated here.

[0329] This process can be understood as follows: based on the sandbox's identification information, the status information of the sandbox corresponding to the identification information of the sandbox is found in the second mapping table, and the status information of the sandbox corresponding to the found sandbox's identification information is recorded as "not ready".

[0330] The above method can stop the sandbox, has high reliability, is simple to implement, and has low resource consumption.

[0331] Step S1105: Delete the sandbox in the first node.

[0332] The fourth parameter used when the first node deletes a sandbox includes the sandbox's identification information.

[0333] For example, the first node deletes the sandbox; see [link to relevant documentation]. Figure 15 , Figure 15 This is a schematic diagram of a first node deleting a sandbox according to an embodiment of this application, including steps S11051-S11053, as follows:

[0334] Step S11051: Based on the sandbox's identification information and the first mapping table, determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines. The relevant description of the first mapping table can be found above and will not be repeated here. This step can be specifically referred to in step S11041, and will not be repeated here.

[0335] Step S11052: Delete the mapping relationship between the sandbox identification information and the runtime name of the first container group corresponding to the sandbox identification information in the first mapping table.

[0336] In one example, the sandbox identifier is SX1, and the runtime name of the first container group corresponding to SX1 in the first mapping table is vm. The mapping relationship between SX1 and the vm corresponding to SX1 is deleted.

[0337] Step S11053: Delete the mapping relationship between the sandbox identification information and the state information of the sandbox corresponding to the sandbox identification information in the second mapping table.

[0338] In one example, the sandbox is identified as SX1, and the state information of the sandbox corresponding to SX1 in the second mapping table is "not ready". The mapping relationship between SX1 and the "not ready" corresponding to SX1 is deleted.

[0339] It should be noted that the above is for illustrative purposes only, and there is no obvious order between steps S11052 and S11053.

[0340] The above method can delete the sandbox, has high reliability, is simple to implement, and has low resource consumption.

[0341] In another possible implementation, the method further includes: the first node sending a third request message.

[0342] For example, the first node sending a third request message includes the first node sending a third request message to the second node.

[0343] The third request message is used to request the deletion of the template data corresponding to the first container group. The third request message includes the name of the first container group and / or the namespace of the first container group.

[0344] Optionally, after deleting the sandbox, the first node sends a third request message to the second node. The second node receives the third request message from the first node and then deletes the template data corresponding to the first container group from the database. Optionally, the second node sends a third response message to the user, indicating that the template data corresponding to the first container group has been successfully deleted. Thus, the virtual machine deletion is complete.

[0345] exist Figure 11The method described above abstracts virtual machines into virtual containers, ensuring consistency between virtual machines and containers. It manages the virtual machine lifecycle by reusing the container lifecycle management logic and processes within the cloud platform. This process enables the management of virtual machine shutdown and deletion within the cloud platform. For example, the process is implemented through the container runtime interface, allowing for the deletion of the first container. This enables virtual machines to be managed by the cloud platform like containers, supporting the coexistence of both virtual machine and container applications without adding extra components. This approach offers high reliability and low platform resource overhead. Furthermore, virtual machine applications are declared using existing resources (such as container group resources), resulting in simple field definitions, easy understanding, and low learning costs. This eliminates the need to extend cloud platform resources, reducing additional understanding and learning costs. In short, this method supports the coexistence of both virtual machine and container applications within the cloud platform while saving costs. It provides a low-cost, diversified application deployment model for the cloud platform, enabling the coexistence of virtual machine and container applications and providing transitional capabilities for cloud-native migration.

[0346] Please see Figure 16 , Figure 16 This is a schematic diagram of another communication method provided in an embodiment of this application, which includes, but is not limited to, the following steps:

[0347] Step S1601: The user configures the container group template for the virtual machine application.

[0348] For details, please refer to the relevant description in step S601.

[0349] Step S1602: The user sends a first request message to the second node.

[0350] Accordingly, the second node receives a first request message from the user. This first request message is used to request the creation of a first container group, as detailed in step S601.

[0351] Step S1603: The second node creates the resources corresponding to the first container group based on the first request message.

[0352] For details, please refer to the relevant description in step S602.

[0353] Step S1604: The second node sends a first response message to the first node.

[0354] Accordingly, the first node receives a first response message from the second node. The first response message includes a success message, which can be found in the relevant description in step S603.

[0355] Step S1605: The first node sends a second request message to the second node.

[0356] Accordingly, the second node receives a second request message from the first node. This second request message is used to check if there are any container groups that need to be started. The second request message includes the identification information of the first node, as detailed in the relevant description in step S604.

[0357] Step S1606: The second node sends a second response message to the first node.

[0358] Accordingly, the first node receives a second response message from the second node, which includes a list of container groups. See step S604 for details.

[0359] Step S1607: The first node runs the sandbox corresponding to the first container group.

[0360] For details, please refer to the relevant description in step S604.

[0361] For example, the first node running the sandbox corresponding to the first container group includes steps S16071-S16073, as follows:

[0362] Step S16071: Determine the sandbox identification information.

[0363] Step S16072: Establish a mapping relationship between the sandbox identification information and the runtime name of the first container group in the first mapping table.

[0364] Step S16073: Record the status information of the sandbox corresponding to the sandbox's identification information as "ready" in the second mapping table.

[0365] For details regarding steps S16071-S16073, please refer to the relevant descriptions in steps S6041-S6043.

[0366] Step S1608: The first node sends a third request message to the second node.

[0367] Correspondingly, the second node receives a third request message from the first node. This third request message is used to pull the container image and includes the container image name. See step S605 for details.

[0368] Step S1609: The second node sends a third response message to the first node.

[0369] Accordingly, the first node receives a third response message from the second node, which includes the file stream of the container image corresponding to the container image name. See step S605 for details.

[0370] Step S1610: The first node creates the first container in the sandbox.

[0371] For details, please refer to the relevant description in step S605.

[0372] For example, the creation of the first container in the sandbox by the first node includes steps S16101-S16106, as follows:

[0373] Step S16101: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0374] Step S16102: Determine the corresponding script for creating the virtual machine based on the annotation information of the first container group, and run the script to create the virtual machine.

[0375] Step S16103: Determine the identification information of the virtual machine.

[0376] Step S16104: Record the mapping relationship between the virtual machine's identification information and the first container group's annotation information in the third mapping table.

[0377] Step S16105: Record the mapping relationship between the identification information of the virtual machine and the identification information of the sandbox in the fourth mapping table.

[0378] Step S16106: Record the virtual machine status information corresponding to the virtual machine's identification information as "created" in the fifth mapping table.

[0379] For a detailed description of steps S16101-S16106, please refer to the relevant descriptions in steps S6051-S6056.

[0380] Step S1611: The first node starts the first container.

[0381] For details, please refer to the relevant description in step S606.

[0382] For example, the first node starts the first container, including steps S16111-S16115, as follows:

[0383] Step S16111: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0384] Step S16112: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0385] Step S16113: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0386] Step S16114: Determine the script corresponding to start the virtual machine based on the annotation information of the first container group, and run the script to start the virtual machine corresponding to the identification information of the virtual machine.

[0387] Step S16115: Record the virtual machine status information corresponding to the virtual machine's identification information as "running" in the fifth mapping table.

[0388] For a detailed description of steps S16111-S16115, please refer to the relevant descriptions in steps S6061-S6065.

[0389] exist Figure 16 In the described method, the runtime name of the first container group (including container or virtual machine) can distinguish between container applications and virtual machine applications. The annotation information of the first container group can determine the script for the lifecycle of the virtual machine. In short, by abstracting the virtual machine into a virtual container, the virtual machine is kept consistent with the container. The lifecycle of the virtual machine is managed by reusing the lifecycle management logic and process of the container in the cloud platform. Through the above process, the process of managing the creation and startup of virtual machines in the cloud platform can be realized. For example, the process of managing the creation and startup of virtual machines in the cloud platform is implemented through the container runtime interface, so that the virtual machine is managed by the cloud platform like a container. That is, it can support the coexistence of applications in both virtual machine and container forms in the cloud platform without adding additional components. In this way, the reliability is high and the platform resource overhead is small. Furthermore, the virtual machine application is declared using existing resources (such as container group resources). The field definition is simple, easy to understand, and has a low learning cost. There is no need to extend the cloud platform resources and increase the additional understanding and learning cost. In short, through the above method, it is possible to support the coexistence of applications in both virtual machine and container forms in the cloud platform and save costs. In other words, it provides a diversified application deployment model for cloud platforms at low cost, enabling virtual machine applications and container applications to coexist, and providing transition capabilities for completing the cloud-native migration.

[0390] Please see Figure 17 , Figure 17 This is a schematic diagram of another communication method provided in an embodiment of this application, which includes, but is not limited to, the following steps:

[0391] Step S1701: The user determines a container group whose runtime name includes a virtual machine and satisfies the requirement of a first container group.

[0392] For details, please refer to the relevant description in step S1101.

[0393] Step S1702: The user sends a first request message to the second node.

[0394] Accordingly, the second node receives a first request message from the user, which requests the deletion of the first container group. See step S1101 for details.

[0395] Step S1703: The first node sends a second request message to the second node.

[0396] Accordingly, the second node receives a second request message from the first node. This second request message is used to query whether there are any container groups that need to be deleted. The second request message includes the identification information of the first node. For details, please refer to the relevant description in step S1101.

[0397] Step S1704: The second node sends a second response message to the first node.

[0398] Accordingly, the first node receives a second response message from the second node, which includes a list of container groups, including container groups to be deleted, as described in step S1101.

[0399] Step S1705: The first node stops the first container included in the first container group.

[0400] For details, please refer to the relevant description in step S1102.

[0401] For example, the first node stops the first container included in the first container group, including steps S17051-S17055, as follows:

[0402] Step S17051: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0403] Step S17052: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0404] Step S17053: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0405] Step S17054: Determine the script corresponding to stop the virtual machine based on the annotation information of the first container group, and run the script to stop the virtual machine corresponding to the identification information of the virtual machine.

[0406] Step S17055: Record the virtual machine status information corresponding to the virtual machine's identification information as "exited" in the fifth mapping table.

[0407] For details regarding steps S17051-S17055, please refer to the relevant descriptions of steps S11021-S11025.

[0408] Step S1706: The first node deletes the first container.

[0409] For details, please refer to the relevant description in step S1103.

[0410] For example, the deletion of the first container by the first node includes steps S17061-S17067, as follows:

[0411] Step S17061: Determine the sandbox identification information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the fourth mapping table.

[0412] Step S17062: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0413] Step S17063: Determine the first container group annotation information corresponding to the virtual machine's identification information based on the virtual machine's identification information and the third mapping table.

[0414] Step S17064: Determine the script corresponding to delete the virtual machine based on the annotation information of the first container group, and run the script to delete the virtual machine corresponding to the identification information of the virtual machine.

[0415] Step S17065: Delete the mapping relationship between the virtual machine's identification information and the first container group annotation information corresponding to the virtual machine's identification information in the third mapping table.

[0416] Step S17066: Delete the mapping relationship between the identification information of the virtual machine and the identification information of the sandbox corresponding to the identification information of the virtual machine in the fourth mapping table.

[0417] Step S17067: Delete the mapping relationship between the virtual machine's identification information and the virtual machine's status information corresponding to the virtual machine's identification information in the fifth mapping table.

[0418] For details regarding steps S17061-S17067, please refer to the relevant descriptions of steps S11031-S11037.

[0419] Step S1707: The first node stops the sandbox corresponding to the first container.

[0420] For details, please refer to the relevant description in step S1104.

[0421] For example, stopping the sandbox corresponding to the first container on the first node includes steps S17071-S17072, as follows:

[0422] Step S17071: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0423] Step S17072: Record the status information of the sandbox corresponding to the sandbox's identification information as "not ready" in the second mapping table.

[0424] For details regarding steps S17071-S17072, please refer to the relevant descriptions of steps S11041-S11042.

[0425] Step S1708: Delete the sandbox in the first node.

[0426] For details, please refer to the relevant description in step S1105.

[0427] For example, the first node deletes the sandbox, including steps S17081-S17083, as follows:

[0428] Step S17081: Determine the runtime name of the first container group corresponding to the sandbox's identification information, including virtual machines, based on the sandbox's identification information and the first mapping table.

[0429] Step S17082: Delete the mapping relationship between the sandbox identification information and the runtime name of the first container group corresponding to the sandbox identification information in the first mapping table.

[0430] Step S17083: Delete the mapping relationship between the sandbox identification information and the state information of the sandbox corresponding to the sandbox identification information in the second mapping table.

[0431] For details regarding steps S17081-S17083, please refer to the relevant descriptions of steps S11051-S11053.

[0432] Step S1709: The first node sends a third request message to the second node.

[0433] Correspondingly, the second node receives a third request message from the first node. This third request message requests the deletion of the template data corresponding to the first container group. The third request message includes the name of the first container group and / or its namespace. For details, please refer to the relevant description in step S605.

[0434] Step S1710: The second node sends a third response message to the user.

[0435] This step is optional. The third response message includes a message indicating that the template data corresponding to the first container group has been successfully deleted.

[0436] exist Figure 17The described method abstracts virtual machines into virtual containers, ensuring consistency between virtual machines and containers. It manages the virtual machine lifecycle by reusing the container lifecycle management logic and processes within the cloud platform. This process enables the management of virtual machine shutdown and deletion within the cloud platform. For example, the container runtime interface facilitates this process, allowing the deletion of the first container and enabling virtual machines to be managed by the cloud platform like containers. This allows for the coexistence of both virtual machine and container-based applications within the cloud platform without requiring additional components. This approach offers high reliability and low platform resource overhead. Furthermore, virtual machine applications are declared using existing resources (such as container group resources), resulting in simple field definitions, easy understanding, and low learning costs. This eliminates the need to extend cloud platform resources, reducing additional understanding and learning costs. In short, this method supports the coexistence of both virtual machine and container-based applications within the cloud platform while saving costs. It provides a low-cost, diversified application deployment model for the cloud platform, enabling the coexistence of virtual machine and container applications and providing transitional capabilities for cloud-native migration.

[0437] The methods of the embodiments of this application have been described in detail above, and the apparatus of the embodiments of this application is provided below.

[0438] Please see Figure 18 , Figure 18 This is a schematic diagram of the structure of a communication device 1800 provided in an embodiment of this application. The communication device 1800 may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions executed by the first node or the second node in the above method embodiments. The modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0439] In one possible implementation, the communication device 1800 may include a processing unit 1801 and a transceiver unit 1802, the specific details of which are as follows:

[0440] The processing unit 1801 is used for data processing. The transceiver unit 1802 can implement corresponding communication functions. The transceiver unit 1802 can also be called a communication interface or a communication module.

[0441] Optionally, the communication device 1800 may further include a storage unit, which can be used to store instructions and / or data. The processing unit 1801 can read the instructions and / or data in the storage module to enable the implementation of the aforementioned method embodiments.

[0442] Optionally, the transceiver unit 1802 may include a sending unit and a receiving unit. The sending unit is used to perform the sending operation in the above method embodiments. The receiving unit is used to perform the receiving operation in the above method embodiments.

[0443] It should be noted that the communication device 1800 may include a transmitting unit but not a receiving unit. Alternatively, the communication device 1800 may include a receiving unit but not a transmitting unit. Specifically, it depends on whether the above-described scheme executed by the communication device 1800 includes both transmitting and receiving actions.

[0444] Processing unit 1801 is used to perform the above. Figure 6 , Figure 11 , Figure 16 or Figure 17 In the illustrated embodiment, the transceiver unit 1802 is used to execute the processing operations performed by the first node or the second node as described above. Figure 6 , Figure 11 , Figure 16 or Figure 17 The embodiments shown depict the send / receive operations performed by the first or second node. For details, please refer to the relevant descriptions in the above method embodiments; they will not be elaborated upon here.

[0445] It should be noted that the module division in this embodiment is illustrative and is only a logical functional division. In actual implementation, there may be other division methods.

[0446] The processing unit 1801 in the above embodiments can be implemented by at least one processor or processor-related circuitry. The transceiver unit 1802 can be implemented by a transceiver or transceiver-related circuitry. The transceiver unit 1802 can also be referred to as a communication module or communication interface. The storage module can be implemented by at least one memory.

[0447] Please see Figure 19 , Figure 19 This is a schematic diagram of the structure of a communication device 1900 provided in an embodiment of this application. The communication device 1900 may include modules, units, or means that correspond one-to-one with the methods / operations / steps / actions executed by the first node or the second node in the above method embodiments. The modules, units, or means may be hardware circuits, software, or a combination of hardware circuits and software.

[0448] The communication device 1900 includes at least one processor 1901. Optionally, it includes a communication interface 1903, and optionally, it also includes a memory 1902. The processor 1901, memory 1902, and communication interface 1903 are interconnected via a bus 1904. Optionally, the processor 1901 and memory 1902 can be integrated together.

[0449] The memory 1902 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and is used for related computer programs and data. The communication interface 1903 is used for receiving and transmitting data.

[0450] Processor 1901 can be one or more central processing units (CPUs). If processor 1901 is a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0451] The processor 1901 in the communication device 1900 is used to read computer programs or instructions stored in the memory 1902 to implement the functions of the aforementioned processing unit, and the communication interface 1903 in the communication device 1900 is used to implement the functions of the aforementioned transceiver unit.

[0452] This application also provides a chip device including at least one processor, which is used to call a computer program or instructions stored in a memory to cause the processor to execute the method provided in the above embodiments.

[0453] In one possible implementation, the input of the chip device corresponds to the receiving operation in any of the above embodiments, and the output of the chip device corresponds to the sending operation in any of the above embodiments.

[0454] Optionally, the processor is coupled to the memory via an interface.

[0455] Optionally, the chip device may also include a memory storing computer program instructions.

[0456] This application also provides a computer-readable storage medium storing a computer program or instructions that, when executed on a processor, implement the method executed by the first node or the second node in the above method embodiments.

[0457] This application also provides a computer program product, which includes a computer program or instructions that, when run on a processor, implement the method executed by the first node or the second node in the above method embodiments.

[0458] This application also provides a communication system, which includes a first node and a second node as described in the above embodiments. The first node is used to execute some or all of the operations performed by the first node in the above method embodiments, and the second node is used to execute some or all of the operations performed by the second node in the above method embodiments.

[0459] It is understood that the processor in the embodiments of this application may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0460] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a base station or terminal. Of course, the processor and storage medium can also exist as discrete components in the base station or terminal.

[0461] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0462] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0463] In the description of this application, terms such as "first", "second", "S601" or "S602" are used only for the purpose of distinguishing descriptions and for the convenience of context. Different sequence numbers do not have specific technical meanings themselves and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying the order of execution of operations. The order of execution of each process should be determined by its function and internal logic.

Claims

1. A communication method characterized by comprising: The method is applied to a first node and comprises: running a sandbox corresponding to a first container group, wherein a first parameter used when the sandbox is run comprises a first container group runtime name, and the first container group runtime name comprises a container or a virtual machine; creating a first container in the sandbox, wherein a second parameter used when the first container is created comprises first container group annotation information, and the first container group annotation information is used to indicate a script of a life cycle of the virtual machine; and the first container group comprises one or more first containers.

2. The method of claim 1, wherein, The first container group runtime name comprises a virtual machine, and the running of the sandbox corresponding to the first container group comprises: determining identification information of the sandbox; establishing a mapping relationship between the identification information of the sandbox and the first container group runtime name in a first mapping table, wherein the first mapping table comprises a one-to-one correspondence relationship between the identification information of the sandbox and the first container group runtime name; recording, in a second mapping table, state information of the sandbox corresponding to the identification information of the sandbox as being ready, wherein the second mapping table comprises a one-to-one correspondence relationship between the identification information of the sandbox and the state information of the sandbox.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: determining, based on the identification information of the sandbox and the first mapping table, that the first container group runtime name corresponding to the identification information of the sandbox comprises a virtual machine; determining a corresponding script for creating the virtual machine based on the first container group annotation information, and running the script to create the virtual machine; determining identification information of the virtual machine.

4. The method of claim 3, wherein, The method further comprises: recording, in a third mapping table, a mapping relationship between the identification information of the virtual machine and the first container group annotation information, wherein the third mapping table comprises a one-to-one correspondence relationship between the identification information of the virtual machine and the first container group annotation information; recording, in a fourth mapping table, a mapping relationship between the identification information of the virtual machine and the identification information of the sandbox, wherein the fourth mapping table comprises a one-to-one correspondence relationship between the identification information of the virtual machine and the identification information of the sandbox; recording, in a fifth mapping table, state information of the virtual machine corresponding to the identification information of the virtual machine as being created, wherein the fifth mapping table comprises a one-to-one correspondence relationship between the identification information of the virtual machine and the state information of the virtual machine corresponding to the identification information of the virtual machine.

5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: starting the first container, wherein a third parameter used when the first container is started comprises the identification information of the virtual machine.

6. The method of claim 5, wherein, The starting of the first container comprises: determining, based on the identification information of the virtual machine and the fourth mapping table, identification information of the sandbox corresponding to the identification information of the virtual machine; determining, based on the identification information of the sandbox and the first mapping table, that the first container group runtime name corresponding to the identification information of the sandbox comprises a virtual machine; determining, based on the identification information of the virtual machine and the third mapping table, first container group annotation information corresponding to the identification information of the virtual machine; determining a corresponding script for starting the virtual machine based on the first container group annotation information, and running the script to start the virtual machine corresponding to the identification information of the virtual machine; recording, in the fifth mapping table, state information of the virtual machine corresponding to the identification information of the virtual machine as being in operation.

7. A communication method characterized by comprising: The method is applied to a second node and comprises: receiving a first request message, the first request message being used to request to create a first container group, the first request message comprising a first container group runtime name and / or first container group annotation information, the first container group runtime name comprising a container or a virtual machine, the first container group annotation information being used to indicate a script of a lifecycle of the virtual machine; creating a resource corresponding to the first container group based on the first request message; sending a first response message, the first response message comprising a creation success.

8. A communication method characterized by comprising: The application is applied to a first node, and comprises: stopping a first container included in the first container group, a first parameter used when the first container is stopped comprising identification information of the virtual machine; deleting the first container, a second parameter used when the first container is deleted comprising the identification information of the virtual machine; The stopping of the first container included in the first container group and / or the deletion of the first container comprises: determining, based on the identification information of the virtual machine and a fourth mapping table, identification information of a sandbox corresponding to the identification information of the virtual machine, the fourth mapping table comprising a one-to-one correspondence relationship between the identification information of the virtual machine and the identification information of the sandbox; determining, based on the identification information of the sandbox and a first mapping table, that the first container group runtime name comprising the virtual machine corresponds to the identification information of the sandbox, the first mapping table comprising a one-to-one correspondence relationship between the identification information of the sandbox and the first container group runtime name; determining, based on the identification information of the virtual machine and a third mapping table, that the first container group annotation information corresponding to the identification information of the virtual machine, the first container group annotation information being used to indicate a script of a lifecycle of the virtual machine, the third mapping table comprising a one-to-one correspondence relationship between the identification information of the virtual machine and the first container group annotation information.

9. The method of claim 8, wherein, The stopping of the first container included in the first container group further comprises: determining, based on the first container group annotation information, a corresponding script for stopping the virtual machine, and running the script to stop the virtual machine corresponding to the identification information of the virtual machine; recording, in a fifth mapping table, state information of the virtual machine corresponding to the identification information of the virtual machine as having exited, the fifth mapping table comprising a one-to-one correspondence relationship between the identification information of the virtual machine and the state information of the virtual machine corresponding to the identification information of the virtual machine.

10. The method of claim 8, wherein, The deletion of the first container further comprises: determining, based on the first container group annotation information, a corresponding script for deleting the virtual machine, and running the script to delete the virtual machine corresponding to the identification information of the virtual machine; deleting, in the third mapping table, a mapping relationship between the identification information of the virtual machine and the first container group annotation information corresponding to the identification information of the virtual machine; deleting, in the fourth mapping table, a mapping relationship between the identification information of the virtual machine and the identification information of the sandbox corresponding to the identification information of the virtual machine; deleting, in the fifth mapping table, a mapping relationship between the identification information of the virtual machine and the state information of the virtual machine corresponding to the identification information of the virtual machine.

11. The method according to any one of claims 8-10, characterized in that, The method further comprises: stopping a sandbox corresponding to the first container, a third parameter used when the sandbox is stopped comprising the identification information of the sandbox; The sandbox is deleted, and a fourth parameter used when the sandbox is deleted includes identification information of the sandbox.

12. The method of claim 11, wherein, The stopping of the sandbox corresponding to the first container includes: The first container group runtime name corresponding to the identification information of the sandbox is determined based on the identification information of the sandbox and the first mapping table, and the first container group runtime name includes a virtual machine. The state information of the sandbox corresponding to the identification information of the sandbox is recorded in the second mapping table as unready, and the second mapping table includes a one-to-one correspondence between the identification information of the sandbox and the state information of the sandbox.

13. The method according to claim 11 or 12, characterized in that, The sandbox is deleted, and a fourth parameter used when the sandbox is deleted includes identification information of the sandbox. The first container group runtime name corresponding to the identification information of the sandbox is determined based on the identification information of the sandbox and the first mapping table, and the first container group runtime name includes a virtual machine. The mapping relationship between the identification information of the sandbox and the first container group runtime name corresponding to the identification information of the sandbox is deleted in the first mapping table. The mapping relationship between the identification information of the sandbox and the state information of the sandbox corresponding to the identification information of the sandbox is deleted in the second mapping table.

14. A communication method, comprising: The application is applied to a second node, and includes: A first request message is received, and the first request message is used to request to delete a first container group, and the first request message includes a first container group runtime name, and the first container group runtime name includes a virtual machine.

15. A communications device, characterized by The device includes a transceiver unit and a processing unit, the processing unit is used to execute the processing operation in the method of any one of claims 1-6, and the transceiver unit is used to execute the transceiving operation in the method of any one of claims 1-6.

16. A communications device, characterized by The device includes a transceiver unit and a processing unit, the processing unit is used to execute the processing operation in the method of claim 7, and the transceiver unit is used to execute the transceiving operation in the method of claim 7.

17. A communications device, characterized by The device includes a transceiver unit and a processing unit, the processing unit is used to execute the processing operation in the method of any one of claims 8-13, and the transceiver unit is used to execute the transceiving operation in the method of any one of claims 8-13.

18. A communications device, characterized by The device includes a transceiver unit and a processing unit, the processing unit is used to execute the processing operation in the method of claim 14, and the transceiver unit is used to execute the transceiving operation in the method of claim 14.

19. A communications device, characterized by The device includes at least one processor, and the at least one processor invokes a computer program or instruction stored in a memory to execute the method of any one of claims 1-6.

20. A communications device, characterized by The device includes at least one processor, and the at least one processor invokes a computer program or instruction stored in a memory to execute the method of claim 7.

21. A communications device, characterized by The device includes at least one processor, and the at least one processor invokes a computer program or instruction stored in a memory to execute the method of any one of claims 8-13.

22. A communications device, characterized by The device includes at least one processor, and the at least one processor invokes a computer program or instruction stored in a memory to execute the method of claim 14.

23. A communication system, characterized by The communication system comprises the apparatus of claim 19 and the apparatus of claim 20, or the apparatus of claim 21 and the apparatus of claim 22.

24. A computer-readable storage medium, characterized in that, The computer program or instructions are stored in the computer readable storage medium, and when executed on the processor, implement the method of any one of claims 1-14.

25. A computer program product, characterised in that, The computer program or instructions are stored in the computer program product, and when executed on the computer, implement the method of any one of claims 1-14.

Images