CN110569111A - virtual machine implementation method, device and system based on traditional container - Google Patents
virtual machine implementation method, device and system based on traditional container Download PDFInfo
- Publication number
- CN110569111A CN110569111A CN201910863832.9A CN201910863832A CN110569111A CN 110569111 A CN110569111 A CN 110569111A CN 201910863832 A CN201910863832 A CN 201910863832A CN 110569111 A CN110569111 A CN 110569111A
- Authority
- CN
- China
- Prior art keywords
- container
- virtual machine
- kata
- agent
- starting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 83
- 230000008569 process Effects 0.000 claims abstract description 47
- 238000005516 engineering process Methods 0.000 claims abstract description 21
- 241001026509 Kata Species 0.000 claims abstract description 20
- 244000035744 Hura crepitans Species 0.000 claims description 17
- 238000004891 communication Methods 0.000 claims description 10
- 238000012544 monitoring process Methods 0.000 claims description 6
- 230000004913 activation Effects 0.000 claims 1
- 238000002955 isolation Methods 0.000 abstract description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000012545 processing Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000011191 terminal modification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a virtual machine implementation method based on a traditional container, which comprises the following steps: when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container; and creating and operating the container according to the virtual machine. In the implementation method, when a starting request of the container is detected, the Kata technology is adopted to start the virtual machine of the container, the container runs in the virtual machine, resources in the virtual machine corresponding to the container are relied on in the starting and running processes of the container, hardware resources and an operating system in a host machine do not need to be shared, resource consumption of the host machine is reduced, and further, the containers are isolated through different virtual machines, so that the safety and isolation problems among the containers are guaranteed.
Description
Technical Field
the invention relates to the technical field of virtualization, in particular to a method, a device and a system for realizing a virtual machine based on a traditional container.
background
At present, container technology and kubernets technology are mature day by day, wherein the container technology is a virtualization technology, and the container technology can help an enterprise to rapidly and horizontally expand services by using a Docker technology, so that the capability of flexibly deploying services is achieved. Kubernetes provides a container-centric management environment, and is a container management platform. It coordinates computing, network, and storage infrastructure on behalf of a user's workload.
the conventional container at present is equivalent to directly starting a process on the basis of a host operating system, each container shares hardware resources and the operating system of the host, dynamic allocation of resources can be realized, starting the container is just starting a process, the speed is high, and application programs directly run in each container without mutual influence. In the container ecology, the main modules of the container are: docker Client, Docker Daemon, Docker Registry, Graph, Driver, libcontainer, and Docker container. But actually docker is just the framework that manages the life cycle of the container, and the real start container is runC, i.e. it is runC that really interacts with the container. That is, runC starts the container on the operating system of the host using the hardware resources of the host. The system structure diagram is shown in fig. 1:
because the traditional container directly opens a process on the basis of the host machine operating system, each container shares the hardware resources and the operating system of the host machine, great pressure and resource consumption are brought to the host machine, the activity of the host machine is greatly reduced, and the resources are not really isolated among the containers, so that the problems of safety and isolation are caused.
disclosure of Invention
in view of this, the present invention provides a method, an apparatus, and a system for implementing a virtual machine based on a traditional container, so as to solve the problems of security and isolation caused by the fact that in the prior art, a device directly opens a process based on an operating system of a host, and each container shares hardware resources and the operating system of the host, thereby bringing great pressure and resource consumption to the host, greatly reducing the activity of the host, and not really achieving resource isolation between the containers. The specific scheme is as follows:
a virtual machine implementation method based on a traditional container comprises the following steps:
when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container;
and creating and operating the container according to the virtual machine.
The above method, optionally, further includes:
And when the container exit process is detected, feeding back the exit reason of the container.
Optionally, the method for starting the virtual machine of the container by using Kata technology includes:
Starting the virtual machine by using a guest kernel;
initrd and rootfs contained in Guest image are acquired.
the above method, optionally, running the container according to the virtual machine, includes;
creating the container in the virtual machine;
adopting the guestkernel to start a mini-OS mirror image, starting a Kata-agent in an initialization process running in the mini-OS mirror image context, creating a target context for running a specified command by the Kata-agent, setting a root file by the Kata-agent, and executing the specified command in the target context.
The above method, optionally, creating the container in the virtual machine, includes:
in the case of the virtual machine running, a Kata-proxy is connected to the virtual machine;
configuring a sandbox inside the virtual machine through the communication between the Kata-proxy and the Kata-agent;
Json is configured according to container open interface specifications, a root file system of an operating system is set by adopting the Kata-agent, then an initialization process is executed in a new context, and the container creation is completed.
A legacy container-based virtual machine implementation apparatus, comprising:
the starting module is used for starting the virtual machine required by the container by adopting Kata technology when detecting the starting request of the container;
and the operation module is used for creating and operating the container according to the virtual machine.
The above apparatus, optionally, the starting module includes:
the first starting unit is used for starting the virtual machine by using a guest kernel;
and the acquisition unit is used for acquiring initrd and rootfs contained in Guest image.
The above apparatus, optionally, the operation module includes:
A creating unit configured to create the container in the virtual machine;
and the operation unit is used for starting a mini-OS mirror image by adopting the guest kernel, starting a Kata-agent by operating an initialization process of the mini-OS mirror image context, creating a target context for operating a specified command by the Kata-agent, setting a root file by the Kata-agent, and executing the specified command in the target context.
The above apparatus, optionally, the creating unit includes:
a second promoter unit, which is used for connecting the Kata-proxy to the virtual machine under the condition that the virtual machine runs;
The configuration subunit is used for configuring the sandbox inside the virtual machine through the communication between the Kata-proxy and the Kata-agent;
Json is configured according to a container open interface specification, a root file system of an operating system is firstly set by adopting the Kata-agent, and then an initialization process is executed in a new context to complete the container creation.
a legacy container-based virtual machine implementation system, comprising: container engine, industry standard container operation, gasket carrier, card tower container operation, container, wherein:
the container engine is used for managing and arranging the cluster and drawing the container into the cluster;
The industry standard container is used for managing the life cycle of the container in the host machine when running;
the gasket carrier is used for monitoring the container process;
when the card tower container is carried out, a user creates and operates the container through the acquired mirror image;
The container is used for storing one or more independently running application programs.
compared with the prior art, the invention has the following advantages:
the invention discloses a virtual machine implementation method based on a traditional container, which comprises the following steps: when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container; and creating and operating the container according to the virtual machine. In the implementation method, when a starting request of the container is detected, the Kata technology is adopted to start the virtual machine of the container, the container runs in the virtual machine, resources in the virtual machine corresponding to the container are relied on in the starting and running processes of the container, hardware resources and an operating system in a host machine do not need to be shared, resource consumption of the host machine is reduced, and further, the containers are isolated through different virtual machines, so that the safety and isolation problems among the containers are guaranteed.
drawings
in order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a block diagram of a prior art virtual machine implementation system based on a conventional container;
FIG. 2 is a block diagram of a system for implementing a virtual machine based on a legacy container according to the present disclosure;
FIG. 3 is a flowchart of a method for implementing a virtual machine based on a conventional container according to an embodiment of the present disclosure;
fig. 4 is a block diagram of a conventional container-based virtual machine implementation apparatus according to an embodiment of the present disclosure.
Detailed Description
the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
the previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
the invention discloses a virtual machine implementation method, a device and a system based on a traditional container, which are applied to the company containerization deployment process, wherein corresponding pod started by each service and containers in the pod are consumed hardware resources of a host, and a plurality of pods of a plurality of services share the resources of the host, because the number of the services and the pods which can be loaded by the host is obviously limited, and the container starting is slower after the host resources are consumed more, the invention provides a virtual machine implementation system based on the traditional container, and the structural block diagram of the system is shown in figure 2 and comprises the following steps:
Container engine, industry standard container operation, gasket carrier, card tower container operation, container, wherein:
the container engine is used for managing and arranging the cluster and drawing the container into the cluster;
The industry standard container is used for managing the life cycle of the container in the host machine when running;
The gasket carrier is used for monitoring the container process;
when the card tower container is carried out, a user creates and operates the container through the acquired mirror image;
in the embodiment of the invention, the main task of Kata-runtime when the card tower container is carried out is to enable the Kata-agent in the virtual machine to start the container. Through the communication between the Kata-proxy and the Kata-agent based on the GRPC protocol, the container load is started in the virtual machine, for example, the starting command is Docker run tiUbuntutop, ReadStdOut of Kata-shim returns the output of the top, WatiProcess () continues to block until the top process exits, and a post-start hook is called.
The container is used for storing one or more independently running application programs.
in the embodiment of the invention, the system is constructed by depending on a structural block diagram of a virtualization implementation mode of a traditional Container, and the lightweight tool run in fig. 1 is replaced by a card tower Container to perform Kata-runtime, wherein the Kata-runtime is used for processing all commands specified by an OCI (Open Container interface) running specification and starting a Kata-shim Instance when a Container compatible with the OCI running specification is operated.
Based on the above virtual machine implementation system based on the traditional container, an embodiment of the present invention provides a virtual machine implementation method based on the traditional container, where an execution flow of the implementation method is shown in fig. 3, and the implementation method includes the steps of:
s101, when a starting request of a container is detected, starting a virtual machine required by the container by adopting Kata technology;
In an embodiment of the present invention, the container detected when the container is started may be one or multiple containers, and when the container is multiple containers, the container exists in the form of pod, where the pod is a minimum unit for running and deploying an application or service in a kubernets cluster, and the following processing is performed for each container in the pod, including:
Firstly, the Hypervisor starts a virtual machine for container operation, wherein the virtual machine comprises: guest kernel and guest image. The container is then really started inside the virtual machine. Wherein the Guest kernel is used for starting the virtual machine. The Kata-container highly optimizes the kernel starting time and the minimum memory occupation, and is only used for the operation of one container. The Guest image contains a temporary Root file system, a virtual RAM disk initrd with the Root file system and a Root file system rootfs, then a Root file system mirror system, a highly optimized container boot micro system based on mirror image Clear Linux which is focused on a container and a cloud, only an initialization process and an agent are run, and a real workload is created by a package libontainer () for container management as same as runc.
Wherein, Kata-container's four subassemblies include: agent, Runtime, proxy and shim, only agent is run in the mini-OS mentioned above. Runtime, proxy and shim are run on the host machine. Each time a container is created, a proxy, agent, and shim are created, while a runtime is only one. Wherein:
Kata-agent is an agent that runs in the guest, manages the operation of containers and process containers. The execution unit of Kata-agent is a sandbox that defines a series of namespaces. Each VM may run multiple containers, supporting the need for k8s to run multiple containers at one pod. However, Kata-runtime is only able to hold one pod per container in docker at present. Kata-agent communicates with other Kata components through the gRPC. Kata-agent manages the life cycle of the container using libontainer, and also reuses most of the code of runc.
kata-runtime is an OCI compliant container runtime that is responsible for processing all commands specified by the OCI runtime specification and launching Kata-shim instances. The configuration file of Kata-runtime is/usr/share/defaults/Kata-associates/configuration. tom, can be modified according to actual requirements,
some of the parameters were extracted as follows:
[hypervisor.qemu]
path＝"/usr/bin/qemu-lite-system-x86_64"
kernel＝"/usr/share/Kata-containers/vmlinuz.container"
initrd＝"/usr/share/Kata-containers/Kata-containers-initrd.img"
machine_type＝"pc"
kernel_params＝""
firmware＝""
machine_accelerators＝""
default_vcpus＝1
default_maxvcpus＝0
default_bridges＝1
block_device_driver＝"virtio-scsi"
[proxy.Kata]
path＝"/usr/libexec/Kata-containers/Kata-proxy"
[shim.Kata]
path＝"/usr/libexec/Kata-containers/Kata-shim"
[runtime]
internetworking_model＝"macvtap"
The parameters that are important are: machine _ type, machine type, Kata-container supports multiple machine types, pc, q35 on x86, virt of ARM, pseries of IBM Power. The default is pc. The connection mode between the internet _ model, the VM and the container can also be configured with bridge in addition to macvtap. But bridge cannot work in the scenarios of macvlan and ipvlan.
by default, virtual-serial and VM communication is used, and a kernel version higher than 4.8 can use vsock, a virtual socket. The VM may run multiple container processes. In the case of a virtio-serial, the I/O streams associated with each process need to be multiplexed and demultiplexed on the host. The Kata-proxy provides multiple Kata-shim and Kata-runtime clients with access to the Kata-agent, and its main role is to route I/O streams and signals between each Kata-shim and Kata-agent. The Kata-proxy is connected to the unitx domain socket of the Kata-agent, which is provided by Kata-runtime when the Kata-proxy is started.
A container process can handle responses like docker's container-shim, provided that the container process can be monitored. runtime runs on a host machine, cannot directly monitor processes running in a virtual machine, and can only see QEMU processes at most. For Kata-container, Kata-shim plays a role in monitoring the progress of the container. Kata-shim needs to process all I/O streams of a container, including stdout, stdin and stderr, and forward all signals to be sent out.
kata-shim also has other functions: and connecting to Kata-proxy through a UNIX domain socket. When Kata-shim starts, the socket is transmitted to Kata-shim by Kata-shim, and carries a contianerID and an execID, wherein the contianerID and the execID are used for identifying which container the shim manages. Reading the output stream and the error stream from the VM internal container process, forwarding the signal from the reader to the Kata-proxy by using a SignalProcessRequest API, monitoring terminal modification, and forwarding the signal to the Kata-proxy by using a grpc TtyWinResize API.
and S102, creating and operating the container according to the virtual machine.
In the embodiment of the invention, after the virtual machine is started, the container is constructed in the virtual machine, further, the Hypervisor starts a Mini-OS mirror image by using a guest kernel, then a system d running in the Mini-OS context starts a Kata-Agent, then the Agent creates a new context for running a specified command (date), finally the Agent sets a root file system of an operating system first, then the date is executed in the new context, and the container is started completely. For example, executing the Docker run ti Ubuntu date command includes:
s11, the Hypervisor starts a mini-OS image by using a guest kernel;
s12, the system running in the Mini-OS context starts the Kata-agent;
s13, Agent will create a new context for running the specified command (date);
s14, agent sets the root file system of ubuntu first, and then executes date in the new context.
In the embodiment of the invention, Kata-agent runs in guest atomically, and manages the running of the container and the processing container. The execution unit of Kata-agent is a sandbox that defines a series of namespaces. The Kata-agent communicates through other components such as the gRPC and Proxy throughout the container lifecycle, which in turn provides multiple shim and runtime clients with access to the agent, whose primary role is to route I/O flows and signals between each shim and agent. proxy connects to agent's unix domain socket, which is provided by runtime at proxy startup. Shim is mainly responsible for monitoring the container process, processing all I/O flows of the container, forwarding all signals to be sent out, and reading the output stream and error stream from the container process inside the VM.
the series of operations are adopted to realize that the replacement run starts the container on the resource of the shared host, each container runs in a light-weight virtual machine, and an independent kernel is used, so that the container has better isolation and safety.
the invention discloses a virtual machine implementation method based on a traditional container, which comprises the following steps: when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container; and creating and operating the container according to the virtual machine. In the implementation method, when a starting request of the container is detected, the Kata technology is adopted to start the virtual machine of the container, the container runs in the virtual machine, resources in the virtual machine corresponding to the container are relied on in the starting and running processes of the container, hardware resources and an operating system in a host machine do not need to be shared, resource consumption of the host machine is reduced, and further, the containers are isolated through different virtual machines, so that the safety and isolation problems among the containers are guaranteed.
In the embodiment of the present invention, an example of creating a container that does not share resources of a host is described, which includes:
s21, after the command is executed, the Kata-runtime creates a sandbox which is used for creating a network name space and starting a virtual machine and a shim process;
S22, calling a pre-start hook, and creating a paired port (path _ pair) between the host network namespace and the just created network namespace;
S23, scanning the network in the network space, and creating a mac vtap connection between the Tap devices of the path and vm virtual machines, where the path pair is a pair of ports, all the data packets entering from one end of the pair of ports will come out from the other end, and the Tap device is a virtual network device in the Linux concept, which is equivalent to an ethernet device, and operates the second layer data packets, such as ethernet data frames. MACVTA refers to a type of network interface that is connected to clear the network in a new network space, facilitating the launching of virtual machines in the network namespace by providing the previously created interface for taps.
s24, starting vm in a network namespace through the created tap equipment;
s25, waiting for the virtual machine to run;
s26, starting a Kata-proxy, connecting the Kata-proxy to a virtual machine, wherein the Kata-proxy process proxies all communications with the virtual machine, and each virtual machine proxies one proxy;
S27, configuring a sandbox inside the virtual machine through Kata-proxy and Kata-agent communication;
json, and Kata-agent communication create container, depending on OCI configuration file config;
s29, start Kata-shim, will connect to the gPC service provided by Kata-proxy. Kata-shim initiates some go coroutines and calls the ReadStdout (), ReadStderr (), WaitProcess () methods in a blocking manner in parallel. ReadStdout (), ReadStderr () are run in dead loop until the container exits. WaitProcess calls only on container retirement and returns the retirement reason.
Further, a kill command may be sent, Kata-runtime sends a UNIX signal to the container process, kill sends a termination signal, such as SIGKILL or sigtherm, to terminate the container process, and for Kata-runtime, it is necessary for both the container and the virtual machine to stop, as follows:
S31, sending a kill request to the Kata-agent through proxy;
s32, waiting for the exit of Kata-shim;
S33, if the Kata-shim overtime does not return, forcibly killing the container process, namely sending a SIGKILL signal to the Kata-agent;
S34, waiting for the exit of Kata-shim, and reporting an error if the exit is overtime;
s35, communicating with the Kata-agent, and deleting the container configuration from the virtual machine;
s36, communicating with the Kata-agent, and deleting the configuration of the sandbox from the virtual machine;
s37, stopping the virtual machine;
s38, deleting all network configurations in the network name space, and deleting the name space;
And S39, executing the post-stop hook.
Furthermore, a Delete instruction can be sent to Delete resources related to all containers, the running container cannot be deleted, and the forced deletion needs to be carried with a force. If the sandbox is not stopped, but the particular container process has returned itself, Kata-runtime will first perform most of the steps required for the termination signal. After this process, or if the sandbox has stopped, the flow at Kata runtime is as follows:
And S41, removing the container resource. Each file is saved in/var/{ lib, run }/virtcontainers/sandbox es/< sandbox ID >/< container ID >.
And S42, deleting the sandbox resource. Each file is saved in/var/{ lib, run }/virtcontainers/sandbox es/< sandbox ID >.
at this point, all content related to the container should be removed from the host system.
based on the foregoing virtual machine implementation method based on the traditional container, an embodiment of the present invention further provides a virtual machine implementation apparatus based on the traditional container, where a structural block diagram of the implementation apparatus is shown in fig. 4, and the virtual machine implementation apparatus includes:
A start module 201 and an operation module 202.
Wherein,
The starting module 201 is configured to start a virtual machine required by a container by using a Kata technology when a starting request of the container is detected;
the running module 202 is configured to create and run the container according to the virtual machine.
the invention discloses a virtual machine implementation device based on a traditional container, which comprises: when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container; and creating and operating the container according to the virtual machine. In the above implementation apparatus, when a start request of a container is detected, the virtual machine of the container is started by using a Kata technology, the container runs in the virtual machine, resources in the virtual machine corresponding to the container are relied on in the container start and running processes, hardware resources and an operating system in a host do not need to be shared, resource consumption of the host is reduced, and further, the containers are isolated by different virtual machines, so that the safety and isolation between the containers are guaranteed.
in this embodiment of the present invention, the starting module 201 includes:
first enabling unit 203 and obtaining unit 204
Wherein,
The first starting unit 203 is configured to start the virtual machine by using a guest kernel;
the obtaining unit 204 is configured to obtain initrd and rootfs included in Guest image.
In this embodiment of the present invention, the operation module 202 includes:
a creation unit 205 and an execution unit 206.
wherein,
The creating unit 205 is configured to create the container in the virtual machine;
the operation unit 206 is configured to start a mini-OS image by using the guest kernel, start a Kata-agent in an initialization process running in the context of the mini-OS image, create a target context for running a specified command by the Kata-agent, set a root file by the Kata-agent, and execute the specified command in the target context.
in this embodiment of the present invention, the creating unit 205 includes:
A second promoter unit 207, a configuration subunit 208 and a creation subunit 209.
wherein,
the second promoter unit 207 is used for connecting the Kata-proxy to the virtual machine under the condition that the virtual machine runs;
the configuration subunit 208 is configured to configure a sandbox inside the virtual machine through communication between the Kata-proxy and the Kata-agent;
json is configured according to a container open interface specification, a root file system of an operating system is first set by using the Kata-agent, and then an initialization process is executed in a new context to complete the container creation.
It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. For the device-like embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
for convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the units may be implemented in the same software and/or hardware or in a plurality of software and/or hardware when implementing the invention.
from the above description of the embodiments, it is clear to those skilled in the art that the present invention can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.
the method, the device and the system for implementing the virtual machine based on the traditional container provided by the invention are described in detail, a specific example is applied in the text to explain the principle and the implementation mode of the invention, and the description of the embodiment is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (10)
1. A virtual machine implementation method based on a traditional container is characterized by comprising the following steps:
when a starting request of a container is detected, a Kata technology is adopted to start a virtual machine required by the container;
and creating and operating the container according to the virtual machine.
2. the method of claim 1, further comprising:
And when the container exit process is detected, feeding back the exit reason of the container.
3. The method of claim 1, wherein starting the virtual machine of the container using Kata techniques comprises:
starting the virtual machine by using a guest kernel;
initrd and rootfs contained in Guest image are acquired.
4. the method of claim 3, wherein running the container in accordance with the virtual machine comprises;
creating the container in the virtual machine;
Adopting the guestkernel to start a mini-OS mirror image, starting a Kata-agent in an initialization process running in the mini-OS mirror image context, creating a target context for running a specified command by the Kata-agent, setting a root file by the Kata-agent, and executing the specified command in the target context.
5. the method of claim 4, wherein creating the container in the virtual machine comprises:
In the case of the virtual machine running, a Kata-proxy is connected to the virtual machine;
Configuring a sandbox inside the virtual machine through the communication between the Kata-proxy and the Kata-agent;
json is configured according to container open interface specifications, a root file system of an operating system is set by adopting the Kata-agent, then an initialization process is executed in a new context, and the container creation is completed.
6. A virtual machine implementation apparatus based on a legacy container, comprising:
The starting module is used for starting the virtual machine required by the container by adopting Kata technology when detecting the starting request of the container;
and the operation module is used for creating and operating the container according to the virtual machine.
7. the apparatus of claim 6, wherein the activation module comprises:
The first starting unit is used for starting the virtual machine by using a guest kernel;
And the acquisition unit is used for acquiring initrd and rootfs contained in Guest image.
8. the apparatus of claim 7, wherein the operation module comprises:
a creating unit configured to create the container in the virtual machine;
And the operation unit is used for starting a mini-OS mirror image by adopting the guest kernel, starting a Kata-agent by operating an initialization process of the mini-OS mirror image context, creating a target context for operating a specified command by the Kata-agent, setting a root file by the Kata-agent, and executing the specified command in the target context.
9. The apparatus of claim 8, wherein the creating unit comprises:
A second promoter unit, which is used for connecting the Kata-proxy to the virtual machine under the condition that the virtual machine runs;
the configuration subunit is used for configuring the sandbox inside the virtual machine through the communication between the Kata-proxy and the Kata-agent;
json is configured according to a container open interface specification, a root file system of an operating system is firstly set by adopting the Kata-agent, and then an initialization process is executed in a new context to complete the container creation.
10. A virtual machine implementation system based on a legacy container, comprising: container engine, industry standard container operation, gasket carrier, card tower container operation, container, wherein:
The container engine is used for managing and arranging the cluster and drawing the container into the cluster;
The industry standard container is used for managing the life cycle of the container in the host machine when running;
the gasket carrier is used for monitoring the container process;
when the card tower container is carried out, a user creates and operates the container through the acquired mirror image;
The container is used for storing one or more independently running application programs.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910863832.9A CN110569111A (en) | 2019-09-12 | 2019-09-12 | virtual machine implementation method, device and system based on traditional container |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910863832.9A CN110569111A (en) | 2019-09-12 | 2019-09-12 | virtual machine implementation method, device and system based on traditional container |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110569111A true CN110569111A (en) | 2019-12-13 |
Family
ID=68779486
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910863832.9A Pending CN110569111A (en) | 2019-09-12 | 2019-09-12 | virtual machine implementation method, device and system based on traditional container |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110569111A (en) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111580930A (en) * | 2020-05-09 | 2020-08-25 | 山东汇贸电子口岸有限公司 | Native cloud application architecture supporting method and system for domestic platform |
| CN112181600A (en) * | 2020-10-21 | 2021-01-05 | 朱领军 | Cloud computing resource management method and system |
| CN112231061A (en) * | 2020-10-22 | 2021-01-15 | 浪潮云信息技术股份公司 | Method for running cloud-native container |
| CN112256405A (en) * | 2020-11-18 | 2021-01-22 | 浪潮云信息技术股份公司 | PAAS platform service management method and related device |
| CN112650554A (en) * | 2020-12-21 | 2021-04-13 | 浪潮云信息技术股份公司 | Method for realizing strong isolation of container |
| CN112817693A (en) * | 2021-01-28 | 2021-05-18 | 浪潮云信息技术股份公司 | Safety container system for function computing service |
| CN113220415A (en) * | 2021-04-25 | 2021-08-06 | 南京南瑞信息通信科技有限公司 | Kata container-oriented persistent data protection method and device |
| CN114461338A (en) * | 2022-01-10 | 2022-05-10 | 北京志凌海纳科技有限公司 | Virtio driver injection method and device |
| CN114629844A (en) * | 2022-02-28 | 2022-06-14 | 浙江大华技术股份有限公司 | Message forwarding method and device and electronic equipment |
| WO2023082389A1 (en) * | 2021-11-12 | 2023-05-19 | 深圳前海微众银行股份有限公司 | Task processing method, device, storage medium, and program product |
| WO2023202179A1 (en) * | 2022-04-21 | 2023-10-26 | 京东科技信息技术有限公司 | Container hot migration method and container hot migration apparatus |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109582441A (en) * | 2018-11-30 | 2019-04-05 | 北京百度网讯科技有限公司 | For providing system, the method and apparatus of container service |
| CN110059453A (en) * | 2019-03-13 | 2019-07-26 | 中国科学院计算技术研究所 | A kind of container virtualization safety reinforced device and method |
-
2019
- 2019-09-12 CN CN201910863832.9A patent/CN110569111A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109582441A (en) * | 2018-11-30 | 2019-04-05 | 北京百度网讯科技有限公司 | For providing system, the method and apparatus of container service |
| CN110059453A (en) * | 2019-03-13 | 2019-07-26 | 中国科学院计算技术研究所 | A kind of container virtualization safety reinforced device and method |
Non-Patent Citations (1)
| Title |
|---|
| 韩卫: "kata containers原理浅析（一）", 《微信公众号 云计算和大数据技术》 * |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111580930A (en) * | 2020-05-09 | 2020-08-25 | 山东汇贸电子口岸有限公司 | Native cloud application architecture supporting method and system for domestic platform |
| CN112181600B (en) * | 2020-10-21 | 2021-07-13 | 甘肃柏隆电子商务科技有限责任公司 | Cloud computing resource management method and system |
| CN112181600A (en) * | 2020-10-21 | 2021-01-05 | 朱领军 | Cloud computing resource management method and system |
| CN112231061A (en) * | 2020-10-22 | 2021-01-15 | 浪潮云信息技术股份公司 | Method for running cloud-native container |
| CN112231061B (en) * | 2020-10-22 | 2023-01-20 | 浪潮云信息技术股份公司 | Method for running cloud-native container |
| CN112256405A (en) * | 2020-11-18 | 2021-01-22 | 浪潮云信息技术股份公司 | PAAS platform service management method and related device |
| CN112650554A (en) * | 2020-12-21 | 2021-04-13 | 浪潮云信息技术股份公司 | Method for realizing strong isolation of container |
| CN112817693A (en) * | 2021-01-28 | 2021-05-18 | 浪潮云信息技术股份公司 | Safety container system for function computing service |
| CN113220415A (en) * | 2021-04-25 | 2021-08-06 | 南京南瑞信息通信科技有限公司 | Kata container-oriented persistent data protection method and device |
| CN113220415B (en) * | 2021-04-25 | 2022-08-09 | 南京南瑞信息通信科技有限公司 | Kata container-oriented persistent data protection method and device |
| WO2023082389A1 (en) * | 2021-11-12 | 2023-05-19 | 深圳前海微众银行股份有限公司 | Task processing method, device, storage medium, and program product |
| CN114461338A (en) * | 2022-01-10 | 2022-05-10 | 北京志凌海纳科技有限公司 | Virtio driver injection method and device |
| CN114461338B (en) * | 2022-01-10 | 2022-10-14 | 北京志凌海纳科技有限公司 | virtio driver injection method and device |
| CN114629844A (en) * | 2022-02-28 | 2022-06-14 | 浙江大华技术股份有限公司 | Message forwarding method and device and electronic equipment |
| CN114629844B (en) * | 2022-02-28 | 2024-04-05 | 浙江大华技术股份有限公司 | Message forwarding method and device and electronic equipment |
| WO2023202179A1 (en) * | 2022-04-21 | 2023-10-26 | 京东科技信息技术有限公司 | Container hot migration method and container hot migration apparatus |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110569111A (en) | virtual machine implementation method, device and system based on traditional container | |
| US11442762B2 (en) | Systems and methods for introspective application reporting to facilitate virtual machine movement between cloud hosts | |
| US9661071B2 (en) | Apparatus, systems and methods for deployment and management of distributed computing systems and applications | |
| US9450783B2 (en) | Abstracting cloud management | |
| US8271653B2 (en) | Methods and systems for cloud management using multiple cloud management schemes to allow communication between independently controlled clouds | |
| US9571332B2 (en) | Methods and apparatuses for remote application provisioning automation over virtualized IT infrastructure | |
| US10768960B2 (en) | Method for affinity binding of interrupt of virtual network interface card, and computer device | |
| WO2020228838A1 (en) | Containerized vnf deployment method and related device | |
| US9081601B2 (en) | Virtual mobile infrastructure and its base platform | |
| US8832459B2 (en) | Securely terminating processes in a cloud computing environment | |
| CN112035172B (en) | Operating system starting method, device, server and storage medium | |
| US20210389970A1 (en) | Vnf lifecycle management method and apparatus | |
| CN103365713A (en) | Resource dispatch and management method and device | |
| US20190250960A1 (en) | Method, apparatus, and server for managing image across cloud servers | |
| US20200136930A1 (en) | Application environment provisioning | |
| US9507624B2 (en) | Notification conversion program and notification conversion method | |
| US11038986B1 (en) | Software-specific auto scaling | |
| US20130318528A1 (en) | Information processing method | |
| US10942831B2 (en) | Automating and monitoring rolling cluster reboots | |
| US8938490B2 (en) | System and method for accessing mainframe system automation from a process automation application | |
| CN110502392A (en) | Cloud platform management and monitoring system | |
| CN115113975A (en) | Cluster management method and device, electronic equipment and storage medium | |
| CN112948008A (en) | Ironic based physical bare computer management method | |
| Solayman et al. | Seamless Integration of DevOps Tools for Provisioning Automation of the IoT Application on Multi-Infrastructures | |
| CN113326098B (en) | Cloud management platform supporting KVM virtualization and container virtualization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191213 |