KubeVirt is a CNCF project that extends Kubernetes with Custom Resource Definitions and controllers to run and manage virtual machines natively alongside container workloads, using QEMU/KVM as the underlying hypervisor. It solves the problem of maintaining separate infrastructure for VMs and containers by making every VM a Kubernetes pod — scheduled, networked, and stored through standard Kubernetes APIs. The key mental model is that KubeVirt does not replace Kubernetes; instead, it delegates scheduling, networking, and storage entirely to Kubernetes and layers only the virtualization logic on top.
What This Cheat Sheet Covers
This topic spans 21 focused tables and 129 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Architecture Components
KubeVirt's architecture follows a service-oriented design: three types of additions — CRDs, cluster-wide controllers, and per-node daemons — layer virtualization on top of an unmodified Kubernetes cluster. Understanding what each component does is essential for troubleshooting and performance tuning.
| Component | Example | Description |
|---|---|---|
kubectl get pods -n kubevirt -l kubevirt.io=virt-controller | • Cluster-wide controller that watches for new VMI objects and creates the corresponding virt-launcher pod • also orchestrates live migrations | |
kubectl get pods -n kubevirt -l kubevirt.io=virt-handler | • DaemonSet agent running on every node • takes over from virt-controller once a VM pod is scheduled locally and manages that VM's lifecycle on the node | |
kubectl get pods -l kubevirt.io=virt-launcher | • Per-VM pod (one per running VMI) • runs libvirtd and the QEMU/KVM process, receiving lifecycle commands from virt-handler | |
kubectl get svc -n kubevirt virt-api | • HTTP API entry point for all virtualization flows • validates and persists VMI and VM resource definitions into Kubernetes |