CN115617456A

CN115617456A - Method and device for hybrid operation of virtual machine and container, electronic equipment and readable storage medium

Info

Publication number: CN115617456A
Application number: CN202211269224.3A
Authority: CN
Inventors: 朱祁龙; 赵伟; 杨冀龙
Original assignee: Beijing Know Future Information Technology Co ltd
Current assignee: Beijing Know Future Information Technology Co ltd
Priority date: 2022-10-17
Filing date: 2022-10-17
Publication date: 2023-01-17

Abstract

The application provides a method, a device, electronic equipment and a readable storage medium for hybrid operation of a virtual machine and a container, wherein VMI is established when a VMI establishing command sent by a client is received through a k8s service interface; when the virt controller monitors that the VMI is created, a pod specification file is generated according to the VMI specification file to create a pod, and the node name of the VMI is updated according to the scheduling node of the pod; when monitoring that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with a virt starter in the pod; and after the virt starter is communicated with the operator, creating a virtual machine and managing the life cycle of the virtual machine. According to the scheme, the container and the virtual machine can be simultaneously operated in the pod, when an attack and defense target range is built, a host environment for simultaneously operating the virtual machine and the container environment can be simulated, and the existing virtual machine and container mixed application can be translated to a k8s cluster based on the support.

Description

Method and device for hybrid operation of virtual machine and container, electronic equipment and readable storage medium

Technical Field

The invention relates to the technical field of communication, in particular to a method and a device for hybrid operation of a virtual machine and a container, electronic equipment and a readable storage medium.

Background

When complex network environments such as attack and defense shooting ranges are built by using Kubernetes (k 8 s), or original virtualized micro-services of enterprises are transferred to k8s, k8s is required to be used for operating a virtual machine instead of a container such as a docker (application container engine). The existing Kubernetes virtualization technology KubeVirt can turn Kubernetes into an orchestration engine for application containers and virtual machine workloads.

However, in the existing k8s cluster virtualization technology, a mode is adopted in which kubevir t accesses a VM management interface to kubberenets in a CRD form, and a libvirtd management VM mode is used through a pod, so that one-to-one correspondence between the pod and the VM is realized, a virtual machine is managed as a container, and resource management and scheduling planning as the container are realized. Kubesphere virtualization (KSV) is a lightweight virtual machine management platform derived from Kubesphere, supports single-node deployment and multi-node deployment, is convenient and easy to use, and meets enterprise-level virtualization service requirements. Harvest is a hyper-converged infrastructure (HCI) software built by Kubernetes, introduced by Rancher Labs, that provides fully integrated storage and virtualization functionality on bare-machine servers.

In the existing technical scheme, kubevirt can meet the requirement that the same k8s cluster runs a virtual machine and a container at the same time, but the technology realizes that pod is used as the minimum unit of the virtual machine or the container. kubvirt cannot run the virtual machine and the container in the same pod, and when k8s is used for constructing an attack and defense target range virtualization environment, the environment in which the virtual machine and the docker container run simultaneously in the host cannot be simulated. The two k8s virtualization management platforms KSV and Harvestr do not support k8s clusters which manage the mixed operation of virtual machines and containers.

Disclosure of Invention

Objects of the present invention include, for example, providing a method, apparatus, electronic device, and readable storage medium for hybrid running a virtual machine and a container, which are capable of running the container and the virtual machine simultaneously within a Pod.

Embodiments of the invention may be implemented as follows:

in a first aspect, the present invention provides a method for running a virtual machine and a container in a hybrid manner, where the method is applied to a k8s server, where the k8s server includes a k8s service interface, a virt controller, a virt operator, and a virt initiator, and the method includes:

when the k8s service interface receives a VMI creating command sent by a client, VMI creation is carried out based on the VMI creating command;

when the virt controller monitors VMI creation, a pod specification file is generated according to the VMI specification file, a pod is created according to the pod specification file, and the node name of the VMI is updated according to the scheduling node of the pod after the pod is created;

when monitoring that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with a virt starter in the pod;

and after the virt starter is communicated with the virt operator, creating a virtual machine and managing the life cycle of the virtual machine.

In an optional embodiment, the VMI creation command includes CRD configuration parameters, and the CRD configuration parameters include IP addresses of the specified pod, pod bridge, and virtual machine.

In an optional embodiment, the step of creating a pod according to the pod specification file includes:

the virt controller determines whether a specified pod exists by searching the CRD configuration parameter;

if the appointed pod exists, a virt starter is established in the appointed pod, and a project Libvirtd for running the virtual machine and a process of the simulation processor software qemu are started;

and if the specified pod does not exist, directly creating the pod based on the pod specification file.

In an optional embodiment, each virt initiator corresponds to a plurality of VMIs, and resources are shared among the VMIs.

In an alternative embodiment, the method further comprises:

and after the virt controller creates the pod, calling the virtual switch to generate a corresponding virtual bridge for the pod.

In an optional embodiment, the step of creating a virtual machine and performing lifecycle management on the virtual machine includes:

the virt starter creates a virtual machine, starts the virtual machine by using a local libvirtd instance based on CRD configuration parameters acquired from the virt operator, and adds an IP address to the virtual machine through a virtual switch;

and the virt starter informs the virtual machine of terminating when the life cycle of the pod is finished so as to realize the life cycle management of the virtual machine.

In an optional embodiment, each virt operator corresponds to a libvirtd, and life cycle management of the virtual machine is performed through the libvirtd, so that decentralization is realized.

In a second aspect, the present invention provides an apparatus for hybrid operation of a virtual machine and a container, where the apparatus is applied to a k8s server, where the k8s server includes a k8s service interface, a virt controller, a virt operator, and a virt initiator, and the apparatus includes:

the creating module is used for creating the VMI based on the VMI creating command when the VMI creating command sent by the client is received through the k8s service interface;

the creating module is further used for generating a pod specification file according to the VMI specification file when the virt controller monitors that the VMI is created, creating a pod according to the pod specification file, and updating the node name of the VMI according to the scheduling node of the pod after the pod is created;

the establishing module is used for establishing communication with a virt starter in the pod when the virt operator monitors that the node name of the VMI is matched with the node where the virt operator is located;

and the management module is used for establishing a virtual machine and performing life cycle management on the virtual machine after the virt starter is communicated with the virt operator.

In a third aspect, the present invention provides an electronic device, comprising: a memory and at least one processor, the memory having instructions stored therein; the at least one processor invokes the instructions in the memory to cause the electronic device to perform a method of hybrid-running a virtual machine and a container as described in any of the preceding embodiments.

In a fourth aspect, the present invention provides a computer-readable storage medium having stored thereon instructions which, when executed by a processor, implement the method for hybrid-running a virtual machine and a container according to any one of the preceding embodiments.

The beneficial effects of the embodiment of the invention include, for example:

the application provides a method, a device, electronic equipment and a readable storage medium for hybrid operation of a virtual machine and a container, wherein when a VMI (virtual machine interface) creation command sent by a client is received through a k8s service interface, VMI creation is carried out based on the VMI creation command; when the virt controller monitors that the VMI is created, a pod specification file is generated according to the VMI specification file, a pod is created according to the pod specification file, and the node name of the VMI is updated according to the scheduling node of the pod after the pod is created; when monitoring that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with a virt starter in the pod; and after the virt starter is communicated with the virt operator, creating a virtual machine and managing the life cycle of the virtual machine. According to the scheme, the container and the virtual machine can be simultaneously operated in the pod, when an attack and defense shooting range is built, a host environment for simultaneously operating the virtual machine and the container environment can be simulated, and the existing virtual machine and container mixed application can be supported to be translated to a k8s cluster based on the scheme.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.

Fig. 1 is a flowchart of a method for hybrid running a virtual machine and a container according to an embodiment of the present application;

FIG. 2 is a flowchart of sub-steps included in step S102 of FIG. 1;

FIG. 3 is a flowchart of sub-steps included in step S104 of FIG. 1;

fig. 4 is a block diagram of an electronic device according to an embodiment of the present disclosure;

fig. 5 is a functional block diagram of an apparatus for hybrid operation of a virtual machine and a container according to an embodiment of the present application.

Icon: 110-a processor; 120-a memory; 130-input/output interface; 140-a network interface; 150-a storage interface; 200-means to run virtual machines and containers in a hybrid; 210-a creation module; 220-establishing a module; 230-management module.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, 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 some, but not all embodiments of the present invention. The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. 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.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

It should be noted that the features of the embodiments of the present invention may be combined with each other without conflict.

The terms of art referred to in this application are explained first below:

k8s: kubernets is an open source for managing containerized applications on multiple hosts in a cloud platform, the goal of kubernets is to make it simple and efficient to deploy containerized applications (powerfull), which provides a mechanism for application deployment, planning, updating, and maintenance.

A container: a container is a sandbox technology, primarily for the purpose of running applications therein, isolated from the outside world, and facilitating that this sandbox can be transferred to other host machines. In essence, it is a special process. Resources, files, devices, states and configurations are divided into a single space by name space (Namespace), control groups (Control groups), and root cut (root) techniques.

KVM: kernel-based Virtual Machine (KVM) is built in

The open source virtualization technique of (1). Specifically, the KVM may transform Linux into a virtual machine monitor, enabling a host computer to run multiple isolated virtual environments, i.e., virtual clients or Virtual Machines (VMs).

Libvirt: at present, libvirt has become the most widely used tool and Application Program Interface (API) for managing various virtual machines, and some common virtual machine management tools (such as virsh, virt-install, virt-manager, and the like) and cloud computing framework platforms (such as OpenStack, openNebula, eucalyptus, and the like) all use libvirt's API at the bottom layer.

NameSpace: nameSpace, also called k8s NameSpace, kubernets supports multiple virtual clusters, whose bottom layer relies on the same physical cluster. These virtual clusters are called namespaces.

Pod: pod is the smallest unit of the Kubernetes schedule. A Pod may contain one or more containers and thus it may be considered a logical host of internal containers. The Pod design concept is to support multiple containers sharing the network and file system in one Pod.

OpenvSwitch: openvSwitch is abbreviated as OVS, which is a high-quality, multi-layer virtual switching software. Its purpose is to support large-scale network automation through programming extensions while also supporting standard management interfaces and protocols.

A Pod bridge: the Pod bridge is a virtual bridge added to a Pod running in k8s through openvswitch, connects a Pod virtual network card with a container network card in the Pod, and allocates fixed ip and vlan tags to specified containers in the Pod, so that an independent local area network is formed between the specified containers, and the Pod bridge can compatibly communicate with the k8s network. Finally, the purpose of simulating the environment of the container running in the host computer is achieved.

KubeVirt: kubevirt is a project of a Redhat open source running a virtual machine in a container mode, and an image registry of a container is used for creating the virtual machine and providing VM life cycle management by using a k8s CRD as a resource type Virtual Machine Instruction (VMI) in a k8s add-on mode. The CRD mode is that management of the kubevir to the virtual machine is not limited to a pod management interface, but the management capability of the pod such as RS DS (remote sensing system) Deployment and the like cannot be used, which means that if the kubevir wants to utilize the pod management capability, the kubevir needs to be realized autonomously, and the kubevir realizes the function similar to the RS at present. The runtime currently supported by kubevir is docker and runv.

In the existing k8s cluster architecture model, kubvirt cannot run the virtual machine and the container in the same pod. When k8s is used for constructing an attack and defense shooting range virtualization environment, the environment in which a virtual machine and a docker container run simultaneously in a host cannot be simulated. Although the k8s virtualization BS architecture management platform in the market currently uses virtualization technologies such as KubeVirt, the management platform can only complete simple k8s virtualization cluster management, and cannot mix a container and a virtual machine in the same container for operation and management. The BS architecture management requirement that the virtual machine micro-service and the container micro-service coexist in the same k8s cluster in actual production cannot be met.

In order to solve the problems in the prior art, the present application provides a method for hybrid running a virtual machine and a container, as shown in fig. 1, which is a flowchart of the method for hybrid running a virtual machine and a container provided in the embodiment of the present application, and the method can be implemented by a k8s server. The k8s server comprises a k8s service interface, a virt controller, a virt operator and a virt starter. The specific process shown in FIG. 1 will be described in detail below.

S101, when the k8S service interface receives a VMI creating command sent by a client, VMI creation is carried out based on the VMI creating command.

S102, when the virt controller monitors VMI creation, a pod specification file is generated according to the VMI specification file, a pod is created according to the pod specification file, and after the pod is created, the node name of the VMI is updated according to the scheduling node of the pod.

And S103, when the virt operator monitors that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with the virt starter in the pod.

And S104, after the virt starter is communicated with the virt operator, creating a virtual machine and managing the life cycle of the virtual machine.

k8s is a container-based cluster management platform that provides a mechanism for application deployment, planning, updating, maintenance with the goal of making container-deployed applications simple and efficient. The k8s has the core characteristic that the container can be managed autonomously to ensure that the container in the cloud platform operates according to the expected state of the user.

In this embodiment, regarding the k8s service interface (virt-api), kubevir is to manage vm (virtual machine) pod in the form of CRD (Custom Resources Definition), and virt-api is the entry of all virtualization operations, including conventional CRD update verification and vm start, stop, and so on. And the virt-controller (virt-controller) generates a corresponding virt-lancher pod according to the vmi CRD, and maintains the state of the CRD.

A virt-handler (virt-handler) is deployed on each node in the form of Daemonset, and is responsible for monitoring the state change of each virtual machine instance on the node, and once the state change is detected, responding and ensuring that the corresponding operation can reach the required (ideal) state. The virt-handler maintains synchronization between the cluster-level VMI Spec and the corresponding Libvirt domain, reports changes to the Libvirt domain state and the cluster Spec, and invokes a node-centric plug-in to meet network and storage requirements defined by the VMI Spec.

virt initiator (virt-launcher): in this embodiment, the virt-landercher is modified, and the virt-landercher corresponds to a plurality of VMIs, which share resources. kubel is only responsible for the virt-lanuncher pod run state and does not care about VMI creation.

In this embodiment, the user may configure the CRD parameter at the user side and specify the pod name of the virtual machine. The user side may send a VMI create command to create a VMI to the k8s service interface. The VMI create command contains CRD configuration parameters, which may include IP addresses of the specified pod, pod bridge, and virtual machine. Wherein the pod may be already running or not created. And under the condition that the IP address and the pod bridge configuration item are not added in the CRD configuration parameter, the virtual machine defaults to share pod IP resources and only needs to perform port mapping.

And after receiving the VMI creation command sent by the user side, the k8s service interface creates the VMI based on the VMI creation command.

And when monitoring the VMI creation, the virt controller generates a pod specification file (pod spec file) according to the VMI specification file (VMI spec file) to create the pod.

As can be seen from the above, the specified pod included in the CRD configuration parameter may be already-running or not created. If the pod is already running, then the pod created based on the pod specification file is essentially a modification of the already running pod. And if the pod is not created, the pod created based on the pod specification file is substantially the newly created pod.

And after the pod is created or modified, the virt controller will update the node Name of the VMI according to the scheduling node of the pod.

And the virt operator continuously monitors the node name change of the VMI, and communicates with the virt initiator in the pod when the monitored node name of the VMI is matched with the node where the virt operator is positioned. After establishing communication, the virt initiator will perform creation of the virtual machine within the pod, and configure IP address and the like for the virtual machine, and take charge of the lifecycle management of the virtual machine.

In one possible implementation, if a solution that virtual machines and containers exist in the k8s cluster at the same time is desired, the solution can be implemented by adding kubevir to k8s, and then adding virt-launcher pod using kubevir. However, in this solution, the virtual machine and the container are respectively in different pods, and in the solution provided by this embodiment, the container and the virtual machine can be simultaneously run in the same pod.

Furthermore, in one possible implementation, if it is desired to simulate a host environment where the same host runs both kvm and container in an existing attack and defense shooting range, it is possible to add the virtual machine to the k8s cluster by running the kvm virtual environment and the container environment in the same virtual machine and then using kubevir t. However, in such a scheme, resources such as networks and files between virtual machines cannot be shared, server resources are wasted, and the performance of a shooting range is affected.

In the method for hybrid operation of the virtual machine and the container, by expanding kubvirt, an original function of kubvirt is combined with openvswitch and an original pass (pod network resource sharing interface) of k8 s. The container and the virtual machine can be simultaneously operated in the pod, when an attack and defense shooting range is built, a host environment in which the virtual machine and the container are simultaneously operated can be simulated, and the existing virtual machine and container mixed application can be supported to be translated to a k8s cluster based on the scheme.

As can be seen from the above, the specified pod and the information related to the pod may be included in the CRD configuration parameter. Referring to fig. 2, in the present embodiment, when creating a pod, the pod may be implemented in the following manner:

s1021, the virt controller determines whether there is a specified pod by looking up the CRD configuration parameter.

And S1022, if the specified pod exists, creating a virt starter in the specified pod, and starting a process for running the project Libvirtd of the virtual machine and the simulation processor software qemu.

And S1023, if the specified pod does not exist, directly creating the pod based on the pod specification file.

In this embodiment, when the virt controller generates a pod, the specified pod is searched through the service interface, and if the specified pod exists, a virt starter (virt-launcher) is added to the specified pod to start the Libvirtd and the qemu. That is, in the case where there is a specified pod, the act of generating the pod is an act of modifying on the basis of the specified pod.

However, if there is no specific pod, the pod can be created directly. That is, the action that created the pod is the newly created action.

On this basis, in this embodiment, after creating a pod, the virt controller invokes a virtual switch (OVS) to generate a corresponding virtual bridge for the pod.

In the original architecture, each virt-launcher pod corresponds to one VMI, and in this embodiment, each virt initiator corresponds to multiple VMIs, and resources are shared among the multiple VMIs.

Referring to fig. 3, in this embodiment, when creating a virtual machine and performing lifecycle management on the virtual machine, a virt initiator may be implemented in the following manner:

s1041, the virt initiator creates a virtual machine, starts the virtual machine by using a local libvirtd instance based on the CRD configuration parameters acquired from the virt operator, and adds an IP address to the virtual machine through a virtual switch.

And S1042, when the lifecycle of the pod is finished, the virt starter informs the virtual machine to terminate so as to realize lifecycle management of the virtual machine.

In this embodiment, the virt operator (virt-handler) may notify the virt launcher (virt-launcher) to use the local libvirtual instance to start the VMI according to the CRD configuration parameter. In this embodiment, a function of adding an ip address to the VMI through the OVS is added in this process. virt-lanuncher will manage VMI through pid.

If the pod lifecycle is over, virt-lanuncher will also notify the VMI to terminate.

In addition, in this embodiment, each virt operator corresponds to one libvirtd, and life cycle management of the virtual machine is performed through the libvirtd, so as to achieve decentralization.

The method for hybrid operation of the virtual machine and the container provided in this embodiment makes up for the defect that only the container service or the virtual machine service can be operated in the k8s cluster pod, and enables the container and the virtual machine to be operated in the pod at the same time. And networking or network resource sharing can be performed between the container and the virtual machine.

In addition, the enterprise can be assisted to translate the existing virtual machine and container hybrid application to the k8s cluster, or can directly translate the existing virtual machine service to add to the existing pod + container environment.

Further, when k8s is used for building an attack and defense target range, the technology can be used for simulating a host environment for simultaneously running a kvm virtual machine and a container environment.

Referring to fig. 4, an electronic device, which may be embodied as a general-purpose computing device, is provided in an embodiment of the present application. The electronic device may be used to implement the method for hybrid running of the virtual machine and the container of the above embodiment. The electronic device includes a memory 120, a processor 110, and a bus connecting the various system components.

The memory 120 may include, for example, system memory 120, non-volatile storage media, and the like. The system memory 120 stores, for example, an operating system, an application program, a Boot Loader (Boot Loader), and other programs. The system memory 120 may include volatile storage media such as random access memory 120 (RAM) and/or cache memory 120. The non-volatile storage medium stores, for example, instructions to perform corresponding embodiments of the above-described method of hybrid-running a virtual machine and a container. Non-volatile storage media include, but are not limited to, magnetic disk storage 120, optical storage 120, flash memory, and the like.

The processor 110 may be implemented as discrete hardware components, such as a general purpose processor 110, a digital signal processor 110 (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gates or transistors, or the like. Accordingly, each of the modules, such as the judging module and the determining module, may be implemented by a central processing unit 110 (CPU) executing instructions in the memory 120 for performing the corresponding step, or may be implemented by a dedicated circuit for performing the corresponding step.

The bus may use any of a variety of bus architectures. For example, bus structures include, but are not limited to, industry Standard Architecture (ISA) bus, micro Channel Architecture (MCA) bus, and Peripheral Component Interconnect (PCI) bus.

The electronic device may also include an input-output interface 130, a network interface 140, a storage interface 150, and the like. The input/output interface 130, the network interface 140, the storage interface 150, and the memory 120 may be connected to the processor 110 via a bus. The input/output interface 130 may provide a connection interface for input/output devices such as a display, a mouse, and a keyboard. The network interface 140 provides a connection interface for various networking devices. The storage interface 150 provides a connection interface for external storage devices such as a floppy disk, a usb disk, and an SD card.

Further, as shown in fig. 5, an apparatus 200 for hybrid-running a virtual machine and a container is further provided in an embodiment of the present application, and includes a creating module 210, an establishing module 220, and a managing module 230.

A creating module 210, configured to create a VMI based on a VMI creating command sent by a client when the VMI creating command is received through the k8s service interface;

the creating module 210 is further configured to, when monitoring that the VMI is created through the virt controller, generate a pod specification file according to the VMI specification file, create a pod according to the pod specification file, and update the node name of the VMI according to a scheduling node of the pod after the pod is created.

It is to be understood that the creating module 210 may be configured to perform the above steps S101 and S102, and for detailed implementation of the creating module 210, reference may be made to the above contents related to the steps S101 and S102.

The establishing module 220 is configured to establish communication with the virt initiator in the pod when the virt operator monitors that the node name of the VMI matches the node where the virt operator is located.

It is understood that the establishing module 220 may be configured to perform the step S103, and as to the detailed implementation of the establishing module 220, reference may be made to what is described above with respect to the step S103.

A management module 230, configured to create a virtual machine and perform life cycle management on the virtual machine after communicating with the virt operator through the virt initiator.

It is understood that the management module 230 can be used to execute the step S104, and for the detailed implementation of the management module 230, reference can be made to the above-mentioned contents related to the step S104.

In one possible implementation, the VMI create command includes CRD configuration parameters, which include IP addresses of the specified pod, pod bridge, and virtual machine.

In a possible implementation manner, the creating module 210 may specifically be configured to:

if the specified pod exists, a virt starter is created in the specified pod, and a project Libvirtd for running the virtual machine and a process of the software qemu of the simulation processor 110 are started;

In a possible implementation manner, each virt initiator corresponds to a plurality of VMIs, and resources are shared among the VMIs.

In one possible implementation, the apparatus 200 for hybrid-running a virtual machine and a container further includes a generating module, which may be configured to:

and after the pod is created through the virt controller, calling a virtual switch to generate a corresponding virtual bridge for the pod.

In a possible implementation manner, the management module 230 may specifically be configured to:

In a possible implementation manner, each virt operator corresponds to a libvirtd, and the life cycle management of the virtual machine is performed through the libvirtd, so as to realize decentralization.

Embodiments of the present application also provide a readable storage medium, in which machine-executable instructions are stored, and when the machine-executable instructions are executed, the method of any one of the above-mentioned items is executed.

Optionally, in this embodiment, the above-mentioned readable storage medium may be configured to store executable instructions for performing the following steps:

when the virt operator monitors that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with a virt starter in the pod;

Optionally, in this embodiment, the storage medium may include but is not limited to: a U-disk, a Read Only Memory 120 (ROM), a Random Access Memory 120 (RAM), a removable hard disk, a magnetic disk, or an optical disk, and various media capable of storing program codes.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation manners, and this embodiment is not described herein again.

To sum up, according to the method, the apparatus, the electronic device, and the readable storage medium for hybrid operation of a virtual machine and a container provided in the embodiment of the present application, when a VMI creation command sent by a client is received through a k8s service interface, VMI creation is performed based on the VMI creation command; when the virt controller monitors that the VMI is created, a pod specification file is generated according to the VMI specification file, a pod is created according to the pod specification file, and the node name of the VMI is updated according to the scheduling node of the pod after the pod is created; when monitoring that the node name of the VMI is matched with the node where the virt operator is located, the virt operator establishes communication with a virt starter in the pod; after communicating with the virt operator, the virt starter establishes a virtual machine and performs life cycle management of the virtual machine. According to the scheme, the container and the virtual machine can be simultaneously operated in the pod, when an attack and defense shooting range is built, a host environment for simultaneously operating the virtual machine and the container environment can be simulated, and the existing virtual machine and container mixed application can be supported to be translated to a k8s cluster based on the scheme.

The above description is only for the specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.

Claims

1. A method for hybrid operation of a virtual machine and a container, which is applied to a k8s server, wherein the k8s server comprises a k8s service interface, a virt controller, a virt operator and a virt initiator, and the method comprises the following steps:

2. The method of claim 1, wherein the VMI create command includes CRD configuration parameters, and wherein the CRD configuration parameters include a specified pod, pod bridge, and IP address of the virtual machine.

3. The method of hybrid operating a virtual machine and a container according to claim 2, wherein the step of creating a pod from the pod specification file comprises:

4. The method of claim 1, wherein each virt initiator corresponds to a plurality of VMIs, and wherein resources are shared between the VMIs.

5. The method of hybrid-running a virtual machine and a container according to claim 1, further comprising:

6. The method of claim 1, wherein the step of creating a virtual machine and performing lifecycle management for the virtual machine comprises:

and when the lifecycle of the pod is finished, the virt starter informs the virtual machine of terminating so as to realize lifecycle management of the virtual machine.

7. The method for hybrid operation of virtual machines and containers according to claim 6, wherein each virt manipulator corresponds to a libvirtd, and life cycle management of the virtual machines is performed through the libvirtd to achieve decentralization.

8. An apparatus for hybrid operation of a virtual machine and a container, applied to a k8s server, wherein the k8s server includes a k8s service interface, a virt controller, a virt operator, and a virt initiator, and the apparatus comprises:

9. An electronic device, characterized in that the electronic device comprises: a memory and at least one processor, the memory having instructions stored therein; the at least one processor invokes the instructions in the memory to cause the electronic device to perform the method of hybrid-running a virtual machine and a container of any of claims 1-7.

10. A computer readable storage medium having instructions stored thereon, wherein the instructions, when executed by a processor, implement a method of hybrid-running a virtual machine and a container according to any one of claims 1 to 7.