Shulou(Shulou.com)05/31 Report--

How to analyze the virtualization technology Kube-virt based on K8s? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

According to Garnter's latest forecast, 75% of production applications will run on top of the container environment by 2022. Based on this prediction, at least 25% of the architectures will still run above the old ones for technical or perceived reasons, of which virtual machines will account for the majority of them. So at the beginning of the birth of container technology, especially Kubernetes, there have been open source communities developing and contributing to how to use Kubernetes managed virtual machines as an important function.

The protagonist to be introduced today is Kube-virt, so using Kube-virt will mainly help us solve the following two problems:

From a technical point of view, the complete virtual machine management can be perfectly migrated to some applications that cannot be migrated to the container because of the outdated kernel version and language problems.

From the level of management and operation and maintenance, it accords with the traditional operation and maintenance mode, and the previous operation and maintenance methods such as SSH can be perfectly reused.

Architecture

Why can kube-virt seamlessly connect virtual machines to K8S?

First of all, let's introduce its overall structure.

Virt-api

Kubevirt manages vm pod in the form of CRD, and virt-api is the entry point for all virtualization operations, including regular CRD update verification as well as vm start and stop

Virt-controlller

Virt-controller will generate the corresponding virt-lancher pod according to vmi CRD and maintain the status of CRD

Virt-handler

Virt-handler is deployed on each node in the form of Daemonset, and is responsible for monitoring the state changes of each virtual machine instance on the node. Once a state change is detected, it responds and ensures that the required (ideal) state is achieved.

Virt-handler maintains synchronization between the cluster-level VMI Spec and the corresponding libvirt domain; reports changes in the status of the Libvirt domain and the cluster Spec; and invokes node-centric plug-ins to meet the network and storage requirements defined by VMI Spec.

Virt-launcher

Each virt-lanuncher pod corresponds to a VMI. Kubelet is only responsible for the running status of the virt-lanuncher pod and does not care about the creation of the VMI.

Virt-handler will tell virt-lanuncher to use the local libvirtd instance to start VMI according to the CRD parameter configuration, and virt-lanuncher will notify VMI to terminate if pid manages the end of the VMI,pod life cycle.

Each virt-lanuncher pod corresponds to a libvirtd,virt-lanuncher to manage the life cycle of the VM through libvirtd, so that it is decentralized, which is no longer the previous virtual machine practice, a libvirtd to manage multiple VM.

Virtctl

Virctl is kubevirt with a command similar to kubectl, which directly manages vm beyond the virt-lancher pod layer, and can control start, stop, and restart of vm.

Summary: kubevirt connects the VM management interface to kubernetes in the form of CRD, uses libvirtd to manage VM through a pod, realizes the one-to-one correspondence between pod and VM, manages virtual machines like containers, and achieves the same resource management and scheduling planning as containers, which has little relationship with enterprise Iaas and is convenient for enterprises to access.

Process flow

As a matter of fact, the creation process of VM has been partially described in the above architecture, which is sorted out as follows:

1. K8S API creates VMI CRD object

2. When virt-controller listens to the creation of VMI, it will generate pod spec file and create virt-launcher pods based on VMI configuration.

3. After virt-controller discovers that the virt-launcher pod is created, update the VMI CRD status

4. Virt-handler listens for VMI state changes, communicates virt-launcher to create virtual machines, and is responsible for virtual machine lifecycle management.

Storage

Kubevirt provides a variety of storage methods. Storage determines exactly what kernel and version you use a virtual machine to image. Here are three more commonly used forms I see.

RegistryDisk

Define the image to create the root disk of the virtual machine. Virt-controller creates the entry service in registryVolume's container,container in the pod definition, which is responsible for converting spec.volumes.registryDisk.image to qcow2 format, with the path to the pod root directory.

Kubevirt provides the basic image of registryDIsk: registry-disk-v1alpha, which is used to create a virtual machine image in the form of Dockerfile. Here is the window image demo Dockerfile

`Windows-01-15.qcow2 / disk/ FROM kubevirt/registry-disk-v1alpha COPY Windows---server-2012-datacenter-64bit-cn-syspreped---2018 2012dc.img`

In the end, we build this into the mirror name: windows2012dc:latest, which eventually looks like this in CRD:

`kind: VirtualMachineInstance... Spec: domain: devices: disks:\-disk: bus: virtio name: registrydisk volumeName: registryvolume.\-name: registryvolume registryDisk: image: windows2012dc: latest`

PVC

PVC is a form of persistent storage mirror, which is hung in pod and the format must satisfy / disk/*.img so that kubevirt can implement virtual machine storage.

CDI

CDI is a form provided by kubevirt itself, which converts registryDisk to PVC, which takes time to convert images into PVC persistent storage.

The network

The virtual machine network is the pod network, and the network card of the virt-launcher pod network is no longer attached with pod ip, but the physical network card that communicates with the external network as the virtual network card of the virtual machine. Virt-launcher implements a simple single ip dhcp server, that is, starting the dhclient,virt-launcher service in the virtual machine will be assigned to the virtual machine.

Monitor and control

Kube-handler will call the libvirt API of all virtual machines under the current node, obtain the monitoring metrics of virtual machines, and provide metrics interfaces. Finally, the metric data of kube-handler of all nodes are aggregated through kubevirt-prometheus-metrics and provided to prometheus for use.

Transfer

Dynamic migration through CRD: VirtualMachineInstanceMigration (VMIM)

ApiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstanceMigration metadata: name: migration-job spec: vmiName: vmi-fedora

In fact, this form of migration does not specify which nodes to migrate to, and the internal logic should only reschedule virt-lanucher pod, where kubeirt-config can carry out the relevant restrictions of migration, such as the frequency of migration (only several nodes can be migrated at the same time), the network rate of migration (because it may actually be replicated to data disk), and the progress of migration can also be checked through VMIM.

Kubevirt VS Kata Container

Of course, Kube-virt is not the only technology that can practice virtualization on Kuberentes. We also compare it with kata container, which is more popular at present, to facilitate users to make choices according to the actual situation.

This is the answer to the question on how to analyze the virtualization technology Kube-virt based on K8s. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.