CN112000439A - Method for realizing cloud native application management virtual machine - Google Patents
Method for realizing cloud native application management virtual machine Download PDFInfo
- Publication number
- CN112000439A CN112000439A CN202010857671.5A CN202010857671A CN112000439A CN 112000439 A CN112000439 A CN 112000439A CN 202010857671 A CN202010857671 A CN 202010857671A CN 112000439 A CN112000439 A CN 112000439A
- Authority
- CN
- China
- Prior art keywords
- virtual machine
- pod
- cloud
- native application
- application management
- 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
Images
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/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
-
- 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/45562—Creating, deleting, cloning virtual machine instances
-
- 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/4557—Distribution of virtual machine instances; Migration and load balancing
-
- 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
Abstract
The invention discloses a method for realizing cloud native application management of a virtual machine, which belongs to the technical field of cloud computing, wherein the virtual machine runs in Pod when using an existing container; using a self-defined declarative API to manage the virtual machine, and realizing a virtual machine special API and a corresponding workload controller through a virtual machine controller, a virtual machine processing program and a virtual machine starting program: the virtual machine controller realizes a self-defined Kubernetes Operator which is used for processing the virtualization function in the cluster; the virtual machine handler is responsible for dispatching the request from the virtual machine manager and executing necessary operations to change the virtual machine to meet the required state; each virtual machine object created creates a Pod that runs a virtual machine initiator. The invention can effectively realize the appeal of the customers of public cloud, private cloud and mixed cloud manufacturers to the application of the traditional virtual machine, and improve the user satisfaction.
Description
Technical Field
The invention relates to the technical field of cloud computing, in particular to a method for realizing cloud native application management of a virtual machine.
Background
With the wider application of cloud computing and virtualization in various production environments on a larger scale, the inherent security problem of implementing virtualization technology based on linux namespace + cgroup represented by a container is increasingly prominent.
Disclosure of Invention
The technical task of the invention is to provide a method for realizing cloud native application management of a virtual machine, which can effectively realize the appeal of customers of public cloud, private cloud and mixed cloud manufacturers to the application of the traditional virtual machine, and simultaneously can keep the quick starting speed of containerized application, follow the use habit of container arrangement and improve the user satisfaction.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a method for managing virtual machine by cloud native application is provided,
the virtual machine runs in Pod using the existing container runtime;
using a self-defined declarative API to manage the virtual machine, and realizing a virtual machine special API and a corresponding workload controller through a virtual machine controller, a virtual machine processing program and a virtual machine starting program:
the virtual machine controller realizes a self-defined Kubernetes Operator which is used for processing the virtualization function in the cluster; the virtual machine handler is responsible for dispatching the request from the virtual machine manager and executing necessary operations to change the virtual machine to meet the required state; each virtual machine object created creates a Pod that runs a virtual machine initiator.
The method is combined with the container management technology to manage the traditional virtual machine, so that the original virtualization of the container is realized, the virtual machine is brought into the containerization workflow, and the problems that the traditional virtual machine and the virtual machine cannot be solved independently can be solved.
Preferably, persistent storage is provided by the PVC mechanism to deliver the virtual machine disk. The virtual machine needs a permanent disk and the user should be able to stop the virtual machine, start the virtual machine and retain the data. Kubernets has a storage abstraction called PVC (persistent volume declaration) that allows persistent storage to be attached to a Pod, meaning that by placing a virtual machine in a Pod, we can use existing PVC mechanisms to provide persistent storage to deliver our virtual machine disk.
Preferably, the virtual machine needs to access the cluster network, and provides Pod network interfaces which are directly bound into the Pod network through the CNI.
Further, a virtual machine running in the Pod is made to access the Pod network using a default CNI assigned network interface already existing in the Pod environment.
Preferably, the CPU and memory are allocated to the virtual machine by using resource requests/restrictions on the Pod specification. Users need to be able to allocate cpu and memory resources to virtual machines, and we can allocate cpu and memory to Pod using resource requests/restrictions on Pod specification, which means we can also directly allocate resources to virtual machines by using container resource requests/restrictions.
Preferably, when a new virtual machine object is created, the virtual machine controller will create a Pod for the virtual machine to run in, and after the Pod is scheduled to a particular node, the virtual machine controller updates the virtual machine object with the node name that is scheduled on it, and hands over control to the node-specific VM-launcher component that runs on each node in the virtual machine.
Preferably, the virtual machine handler creates a corresponding domain in the Pod from the virtual machine description file, and when the Pod is deleted from the node on which it is running, it also deletes the domain.
Preferably, the virtual machine startup program provides a cgroup and a name space required by a virtual machine process, the virtual machine handler transfers the CRD of the virtual machine to the virtual machine startup program, and the virtual machine startup program starts the virtual machine at the time using the local libvirtual instance in its container. The virtual machine launcher program looks closely to the virtual machine process and terminates after the virtual machine exits. In some cases, kubernets runtime may attempt to shut down the virtual machine launcher pod before the virtual machine process exits, and when this occurs, the virtual machine launcher may pass a kill signal to the virtual machine process and attempt to postpone the termination of the pod until the virtual machine process is normally shut down.
The invention also requires a device for realizing the cloud native application management virtual machine, which comprises: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor, when executing the method, is configured to invoke the machine-readable program to perform the method recited above.
The invention also claims a computer readable medium having stored thereon computer instructions which, when executed by a processor, cause the processor to perform the above-described method.
Compared with the prior art, the method for realizing the cloud native application management virtual machine has the following beneficial effects:
the method combines the container management technology kubernets and the virtual machine management technology into a management platform, makes full use of the characteristics of simplicity and rapidness of the container and the container arrangement technology, and can provide application services for the design and operation of the virtual machine;
the method can effectively achieve appeal of customers of public cloud, private cloud and mixed cloud manufacturers to the traditional virtual machine application, can keep the quick starting speed of containerized application, continues to use the use habit of container arrangement, and improves user satisfaction.
Drawings
Fig. 1 is an architecture diagram of a method for implementing a cloud native application management virtual machine according to an embodiment of the present invention.
Detailed Description
The invention is further described with reference to the following figures and specific examples.
The embodiment of the invention provides a method for realizing cloud native application management of a virtual machine, which aims at combining a container management technology kubernets and a virtual machine management technology into a management platform in a cloud computing scene, makes full use of the characteristics of simplicity and rapidness of the container and the container arrangement technology, can serve applications designed and operated on the virtual machine, and has numerous applications running on the virtual machine at present.
The method is combined with the container management technology to manage the traditional virtual machine, so that the original virtualization of the container is realized, the virtual machine is brought into the containerization workflow, and the problems that the traditional virtual machine and the virtual machine cannot be solved independently can be solved.
The virtual machine runs in Pod using the existing container runtime. This decision is made while other kubernets virtualization efforts are creating their own virtualization-specific CRI runtime, and running virtual machines in Pod environments can use the latest technology and capabilities of existing and future container runtimes.
In Kubernets, there is no virtual machine, only pod and container, fundamentally the virtual machine is the same as any other containerized application in the rest of the cluster. Therefore, the benefit of running the virtual machine as a Pod in the Kubernetes Pod is huge, how to provide the Pod with access to network, storage, host device, CPU, memory, etc. the entire ecosystem is continuously developing, which means that the scheme can benefit from running the virtual machine in the Pod every time a problem or function is added to the Pod.
And (3) storing:
persistent storage is provided through a PVC mechanism to deliver virtual machine disks. The virtual machine needs a permanent disk and the user should be able to stop the virtual machine, start the virtual machine and retain the data. Kubernets has a storage abstraction called PVC (persistent volume declaration) that allows persistent storage to be attached to a Pod, meaning that by placing a virtual machine in a Pod, we can use existing PVC mechanisms to provide persistent storage to deliver our virtual machine disk.
Network:
the virtual machine needs to access the cluster network and provide Pod network interfaces, which are directly bound into the Pod network through the CNI. The virtual machine running in the Pod is made to access the Pod network using the default CNI assigned network interface already present in the Pod environment.
CPU/memory:
the user needs to be able to allocate cpu and memory resources to the virtual machine. We can allocate CPU and memory to Pod using resource requests/restrictions on Pod specifications. This means that by using container resource requests/restrictions, we can also allocate resources directly to the virtual machine.
The virtual machine is managed using a custom "kubernets-like" declarative API, and a virtual machine-specific API and corresponding workload controller are implemented through a virtual machine controller, a virtual machine handler, and a virtual machine launcher.
Previously, imperative APIs were the de facto standard of how other platforms manage virtual machines. However, in order to use and enjoy the benefits of the true cloud native API managed by existing kubernets tools (e.g., kubecect), the declarative workflow must be fully followed.
Virtual machines can be completed not only once in operation, virtual machines have states that they can be started, stopped, and restarted any number of times, virtual machines also have the notion of live migration, and further, if a node running on a virtual machine dies, it is expected that the identical virtual machine will be restored on another node that maintains its state, and thus a pod can only run once, and a virtual machine will always exist.
To implement a kubernets-like declarative API to manage virtual machines, a virtual machine specific API and corresponding workload controller need to be implemented. The user publishes the description of the virtual machine object (also in yaml format) to the cluster. (Note here that the most important difference from how the pod is managed is that the declaration of the virtual machine object may define a different state. for example, it may be declared that the virtual machine is to be "started" by setting "running: true" to the description file of the virtual machine object. likewise, it may be declared that the virtual machine is to be "stopped" by setting "running: false" to the description file of the virtual machine object
Through the two points above, the API and the controller know how to revive the "stopped" virtual machine by constructing a Pod with all the correct network, storage volume, CPU and memory, thus accurately managing the entire lifecycle of the virtual machine.
Based on the two points, the technical scheme needs to develop the following three components based on kubernets CRD (custom resource extension): a virtual machine controller (VM-controller), a virtual machine handler (VM-handler), and a virtual machine launcher (VM-launcher).
Virtual machine controller (VM-controller):
and the user-defined Kubernetes Operator is realized and is used for processing the virtualization function in the cluster. When a new VM object is created, VM-controller will create a Pod in which the virtual machine will run. After the Pod is scheduled to a particular node, the VM-controller will update the VM object with the node name that it plans on, and hand over control to the node-specific VM-launcher component that runs on each node in the virtual machine.
Virtual machine handler (VM-handler):
the virtual machine handler is responsible for requests scheduled from vm-controller. The VM-handler then performs the necessary operations to change the VM to meet the required state. It is responsible for creating the corresponding domain from the VM description file in the pod. When a Pod is deleted from the node it runs on, it also deletes the domain.
Virtual machine boot (VM-launcher):
each VM object created creates a pod that runs what is called the virtual machine boot program. This component provides the cgroup and namespace required by the VM process. The VM-handler passes the virtual machine's CRD to the VM-launcher, which then uses the local libvirtual instance in its container to start the actual VM. VM-launchers focus closely on VM processes and terminate after VM exit. In some cases, the Kubernetes runtime may attempt to turn off the VM-launcher pod before the VM process exits. When this happens, the VM-launcher will pass a kill signal to the VM process and attempt to postpone the termination of the pod until the VM process is normally shut down.
The method can effectively realize the appeal of customers of public cloud, private cloud and mixed cloud manufacturers to the application of the traditional virtual machine, and can keep the quick starting speed of containerized application, follow the use habit of container arrangement and improve the user satisfaction.
The embodiment of the present invention further provides a device for implementing cloud native application management on a virtual machine, including: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor is configured to invoke the machine readable program to execute the method for implementing the cloud native application management virtual machine according to the above embodiment of the present invention.
An embodiment of the present invention further provides a computer-readable medium, where a computer instruction is stored on the computer-readable medium, and when the computer instruction is executed by a processor, the processor is caused to execute the method for implementing a cloud native application management virtual machine in the foregoing embodiment of the present invention. Specifically, a system or an apparatus equipped with a storage medium on which software program codes that realize the functions of any of the above-described embodiments are stored may be provided, and a computer (or a CPU or MPU) of the system or the apparatus is caused to read out and execute the program codes stored in the storage medium.
In this case, the program code itself read from the storage medium can realize the functions of any of the above-described embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.
Examples of the storage medium for supplying the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (e.g., CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD + RW), a magnetic tape, a nonvolatile memory card, and a ROM. Alternatively, the program code may be downloaded from a server computer via a communications network.
Further, it should be clear that the functions of any one of the above-described embodiments may be implemented not only by executing the program code read out by the computer, but also by causing an operating system or the like operating on the computer to perform a part or all of the actual operations based on instructions of the program code.
Further, it is to be understood that the program code read out from the storage medium is written to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion unit connected to the computer, and then causes a CPU or the like mounted on the expansion board or the expansion unit to perform part or all of the actual operations based on instructions of the program code, thereby realizing the functions of any of the above-described embodiments.
While the invention has been shown and described in detail in the drawings and in the preferred embodiments, it is not intended to limit the invention to the embodiments disclosed, and it will be apparent to those skilled in the art that various combinations of the code auditing means in the various embodiments described above may be used to obtain further embodiments of the invention, which are also within the scope of the invention.
Claims (10)
1. A method for realizing cloud native application management virtual machine is characterized in that,
the virtual machine runs in Pod using the existing container runtime;
using a self-defined declarative API to manage the virtual machine, and realizing a virtual machine special API and a corresponding workload controller through a virtual machine controller, a virtual machine processing program and a virtual machine starting program:
the virtual machine controller realizes a self-defined Kubernetes Operator which is used for processing the virtualization function in the cluster; the virtual machine handler is responsible for dispatching the request from the virtual machine manager and executing necessary operations to change the virtual machine to meet the required state; each virtual machine object created creates a Pod that runs a virtual machine initiator.
2. The method for implementing cloud native application management virtual machine according to claim 1, wherein the virtual machine disk is delivered by providing persistent storage through a PVC mechanism.
3. The method for implementing the cloud-native application management virtual machine according to claim 1 or 2, wherein Pod network interfaces are provided, and the interfaces are directly bound into a Pod network through CNI.
4. The method of claim 3, wherein the default CNI-allocated network interface already existing in the Pod environment is used to enable the virtual machine running in the Pod to access the Pod network.
5. The method for realizing cloud-native application management virtual machine according to claim 1 or 2, wherein CPU and memory are allocated to the virtual machine by using resource request/limitation on Pod specification.
6. The method of claim 1, wherein when creating a new virtual machine object, the virtual machine controller creates a Pod for the virtual machine to run in, and after the Pod is scheduled to a specific node, the virtual machine controller updates the virtual machine object with the node name that is scheduled on it and hands over control to a node-specific VM-launcher component that runs on each node in the virtual machine.
7. The method for managing the virtual machine according to the cloud native application of claim 1 or 6, wherein the virtual machine handler creates a corresponding domain according to the virtual machine description file in the Pod.
8. The method for implementing cloud-native application management virtual machine according to claim 7, wherein the virtual machine startup program provides cgroup and name space required by the virtual machine process, the virtual machine handler passes the CRD of the virtual machine to the virtual machine startup program, and the virtual machine startup program starts the virtual machine of the opportunity using the local libvirtual instance in its container.
9. An apparatus for implementing a cloud native application management virtual machine, comprising: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor, configured to invoke the machine readable program to perform the method of any of claims 1 to 8.
10. Computer readable medium, characterized in that it has stored thereon computer instructions which, when executed by a processor, cause the processor to carry out the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010857671.5A CN112000439A (en) | 2020-08-24 | 2020-08-24 | Method for realizing cloud native application management virtual machine |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010857671.5A CN112000439A (en) | 2020-08-24 | 2020-08-24 | Method for realizing cloud native application management virtual machine |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112000439A true CN112000439A (en) | 2020-11-27 |
Family
ID=73471699
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010857671.5A Pending CN112000439A (en) | 2020-08-24 | 2020-08-24 | Method for realizing cloud native application management virtual machine |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112000439A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113296809A (en) * | 2021-05-21 | 2021-08-24 | 南京大学 | Declarative universal Kubernetes tuning method |
| CN114816665A (en) * | 2022-04-22 | 2022-07-29 | 北京志凌海纳科技有限公司 | Hybrid arrangement system and virtual machine container resource hybrid arrangement method under super-fusion architecture |
| CN115033348A (en) * | 2022-08-10 | 2022-09-09 | 北京腾达泰源科技有限公司 | Method, system, equipment and medium for unified management of virtual machines and containers |
| US11693649B2 (en) | 2021-04-06 | 2023-07-04 | International Business Machines Corporation | Autonomous Kubernetes operator creation and management |
-
2020
- 2020-08-24 CN CN202010857671.5A patent/CN112000439A/en active Pending
Non-Patent Citations (1)
| Title |
|---|
| JASON BROOKS: "Getting to Know Kubevirt", 《KUBERNETES BLOG》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11693649B2 (en) | 2021-04-06 | 2023-07-04 | International Business Machines Corporation | Autonomous Kubernetes operator creation and management |
| CN113296809A (en) * | 2021-05-21 | 2021-08-24 | 南京大学 | Declarative universal Kubernetes tuning method |
| CN113296809B (en) * | 2021-05-21 | 2023-12-12 | 南京大学 | Declarative general Kubernetes tuning method |
| CN114816665A (en) * | 2022-04-22 | 2022-07-29 | 北京志凌海纳科技有限公司 | Hybrid arrangement system and virtual machine container resource hybrid arrangement method under super-fusion architecture |
| CN115033348A (en) * | 2022-08-10 | 2022-09-09 | 北京腾达泰源科技有限公司 | Method, system, equipment and medium for unified management of virtual machines and containers |
| CN115033348B (en) * | 2022-08-10 | 2022-10-25 | 北京腾达泰源科技有限公司 | Method, system, equipment and medium for unified management of virtual machine and container |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11405274B2 (en) | Managing virtual network functions | |
| CN112000439A (en) | Method for realizing cloud native application management virtual machine | |
| US8301746B2 (en) | Method and system for abstracting non-functional requirements based deployment of virtual machines | |
| US11146620B2 (en) | Systems and methods for instantiating services on top of services | |
| US8533701B2 (en) | Virtual machine image update service | |
| KR101116615B1 (en) | Resource management system and method for applications and threads in JAVA Virtual Machine | |
| CN108089913B (en) | Virtual machine deployment method of super-fusion system | |
| WO2012065815A1 (en) | Method and system for generating a virtual machine based on templates | |
| US11221866B2 (en) | Accelerator loading method, system, and apparatus | |
| WO2014075875A1 (en) | Automatic template creation based on new feeds | |
| CN103885833A (en) | Method and system for managing resources | |
| US10728169B1 (en) | Instance upgrade migration | |
| WO2022041507A1 (en) | 3d rendering method and system | |
| KR20130097555A (en) | Application management apparatus and method for mobile terminal for supporting different type guest operating system | |
| US20210326161A1 (en) | Apparatus and method for multi-cloud service platform | |
| CN111213127B (en) | Virtualized operation for directly assigned devices | |
| CN111880891A (en) | Micro-kernel-based extensible virtual machine monitor and embedded system | |
| US20190310874A1 (en) | Driver management method and host | |
| CN113360893B (en) | Container-based intelligent contract execution method and device and storage medium | |
| US20150381766A1 (en) | Application transfer system, application transfer method, terminal, and program | |
| CN114816665B (en) | Hybrid arrangement system and virtual machine container resource hybrid arrangement method under super-fusion architecture | |
| EP3460659A1 (en) | Creating or modifying artifacts on mounted operating system volumes | |
| US11435997B2 (en) | Desired state model for managing lifecycle of virtualization software installed in heterogeneous cluster of hosts | |
| CN109542588B (en) | Method and device for managing virtual equipment in cloud environment | |
| KR20240025213A (en) | Multiple and Single Tenant SaaS Service Management |
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: 20201127 |