docs/doc/source/kube-virt/kubevirt-architecture-c92c8908e775.rst

KubeVirt Architecture

The following diagram describes the KubeVirt architecture:

virt-api-server

HTTP API server serves as the entry point for all virtualization related flows.

The API server updates the virtualization related custom resource definition (see below).

As the main entry point to KubeVirt it is responsible for defaulting and validation of the provided VMI .

VMI (CRD)

definitions are kept as custom resources inside the Kubernetes API server.

The definition defines all properties of the itself, for example:

• Machine type
• CPU type
• Amount of RAM and
• Number and type of

virt-controller

The virt-controller has all the cluster wide virtualization functionality and it is responsible for monitoring the () and managing the associated pods. Currently, the controller ensure the creation and management of the life-cycle of the pods associated with the objects.

A object will always be associated with a pod during its life-time. However, migration of a the pod instance might change over time.

virt-launcher

For every object one pod is created. This pod's primary container runs the virt-launcher KubeVirt component.

Kubernetes or kubelet is not running the . Instead a daemon on every host in the cluster launches a process for every pod which is associated with a object whenever it is scheduled on a host.

The main purpose of the virt-launcher pod is to provide cgroups and namespaces, used to host the process.

virt-handler signals virt-launcher to start a by passing the 's object to virt-launcher. virt-launcher uses a local libvirtd instance within its container to start the . The virt-launcher monitors the process and terminates once the has exited.

If the Kubernetes runtime attempts to shutdown the virt-launcher pod before has exited, virt-launcher forwards signals from Kubernetes to the process and attempts to hold off the termination of the pod until the has shutdown successfully.

virt-handler

Every host needs a single instance of virt-handler. It can be delivered as a DaemonSet.

Like the virt-controller, the virt-handler is also reactive and watches for changes of the object, once detected it will perform all necessary operations to change a to meet the required state.

This behavior is similar to the choreography between the Kubernetes server and the kubelet.

The functions of the virt-handler are:

• Keeps a cluster-level specification in sync with a corresponding libvirt domain.
• Reports domain state and spec changes to the cluster.
• Invokes node-centric plugins which can fulfill networking and storage requirements defined in specs.

Libvirtd

An instance of libvirtd is present in every pod. virt-launcher uses libvirtd to manage the life-cycle of the process.

Additional components from Kubernetes are:

• Storage
• Networking

Simplified Diagram

Containerized Data Importer

The project provides facilities for enabling to be used as disks for KubeVirt by way of DataVolumes. The three main use cases are:

• Import a disk image from a web server or container registry to a DataVolume.
• Clone an existing to a DataVolume.
• Upload a local disk image to a DataVolume.