Introduction to KubeVirt Architecture

A few days ago, I gave a long-overdue KubeVirt 101 talk at the Cloud Native Taiwan User Group. The more I play with it, the more interesting I find this project. Here, I plan to condense the content of that KubeVirt 101 talk and write an introduction focusing on its architecture. I highly recommend everyone try out this operator for running VM workloads on Kubernetes.

Contents

Basic Introduction

Original text from the official website:

KubeVirt is a virtual machine management add-on for Kubernetes. Its goal is to provide a common foundation for virtualization solutions on top of Kubernetes.

Simply put, KubeVirt is a Kubernetes operator that allows users to run virtual machine applications on Kubernetes. This enables users to run applications that haven't been containerized yet or require a specific kernel. The biggest advantage is that all operational concepts are similar to standard Kubernetes container applications, significantly lowering the learning curve for operations personnel.

CRD

First, let's briefly introduce the commonly used CRDs in KubeVirt.

Virtual Machine

VirtualMachine
VirtualMachineInstance
VMI ReplicaSet
VMI Preset

VirtualMachineInstance (VMI) is the most basic building block of an instance. In most cases, users do not create this CRD directly; instead, it is created by higher-level CRDs, such as VirtualMachine and VMI ReplicaSet.

VirtualMachine typically defines a stateful VM, which retains its data after being stopped and restarted, though it can also be used to create stateless VMs.

VMI ReplicaSet is similar to a Kubernetes ReplicaSet; it is a CRD used to provide a group of stateless VMs with similar configurations.

VMI Preset acts as the 'flavor' for an instance, allowing you to pre-configure and reuse resources like CPU and RAM required by the VM.

Main Components

The general architecture diagram looks like this:

KubeVirt consists of the following components:

virt-api
virt-controller
virt-handler
virt-launcher
libvirtd

virt-api

virt-api is responsible for providing KubeVirt-specific APIs, such as console, vnc, startvm, stopvm , etc.

virt-controller

virt-controller is primarily responsible for monitoring the status of VMIs (CRDs) and managing pods related to them. It handles the pod lifecycle (create, delete) and is also responsible for updating the node name within the VMI object.

virt-handler

virt-handler is a DaemonSet that runs on worker nodes. Its main purpose is to watch for changes to VM objects in the Kubernetes API server and ensure the VM matches the desired state. When starting a VM, virt-handler provides the VMI object to signal virt-launcher to start a VMI, after which the task is handed over to virt-launcher.

virt-launcher

Each VMI object corresponds to a pod, and the container within that pod runs the virt-launcher component. The virt-launcher pod is responsible for providing the cgroups and namespaces required to run the VMI process. It is also the primary component that communicates with libvirtd; upon receiving signals, it uses libvirtd to start the VMI, monitors the status of the VMI process, and terminates it when it exits.

libvirtd

As the name suggests, libvirtd is a libvirt daemon responsible for providing APIs to create virtual machines.

Conclusion

The overall architecture of KubeVirt is not overly complex, and it is very easy to use. Readers who need to run VM workloads in a Kubernetes environment should consider giving it a try. I will likely write more articles in the future covering network architecture and usage. For those who can't wait, you can first go to CNTUG YouTube Channel watch the recording of the previous online session.

Reference

https://github.com/kubevirt/kubevirt/blob/master/docs/architecture.md
https://kubernetes.io/blog/2018/05/22/getting-to-know-kubevirt/
https://github.com/kubevirt/kubevirt/blob/master/docs/components.md