KubeVirt is an open source project that allows Virtual Machines (VMs) to be run and managed as pods inside a Kubernetes cluster. This is a particularly important innovation as traditional VM workloads can be moved into Kubernetes alongside already containerized workloads, thereby taking advantage of Kubernetes as an orchestration engine. There are three common classes of application where this might be of particular benefit:
- applications destined for conversion to containers in due course
- legacy applications which will not/cannot be converted to containers
- applications which much live in a VM, for example those which require specific kernel settings
Aside from shifting VM bound workloads, KubeVirt can be used to run Kubernetes in Kubernetes, by running Kubernetes in the KubeVirt VMs. That’s right it’s Kubes in Kubes! This can be useful for creating developer environments, testing Kubernetes upgrades or testing changes made to Infrastructure-as-Code.
Why KubeVirt Benefits from Persistent Storage
KubeVirt VMs are seeded from disk images that can reside on a variety of ephemeral or persistent disks. For instance; disk images can exist as ephemeral containerDisks or be located on a Kubernetes worker node as a hostDisk. ContainerDisks are not persistent between VM restarts and hostDisks limit a VM to running on a specific worker node. However by backing the VM with a StorageOS volume, the VM data persists through restarts of the VM and rescheduling of the pod that the VM is running inside. Furthermore, the VM disk image can actually be cloned, using CDI, to a second persistent volume for testing or development purposes.
Using Ondat allows for the dynamic provisioning of volumes that can be automatically prepared by the Containerized Data Importer (CDI) when VMs are created. Using CDI when a VM is created referencing a dataVolume as its disk, CDI will download the disk image from a URL onto a PersistentVolume. The PersistentVolume that the disk image is located on is then mounted by a VM pod and used by the VM to boot. The URL that CDI pulls the image from could be a repository such as Docker Registry or Artifactory hosted inside the Kubernetes cluster or a public URL.
StorageOS replicas allow the creation of highly available, persistent VMs as loss of the node holding a replicated master volume will trigger a volume failover that is transparent to the VM. This feature could be particularly valuable for legacy VM workloads that have been lifted and shifted to Kubernetes.
The StorageOS upcoming ReadWriteMany volumes feature will allow KubeVirt Live Migration to be used. Live Migration allows a VM to be rescheduled onto a new node without interrupting the VM. The Live Migration feature is only available to VMs that are using ReadWriteMany volumes. For an example of a Live Migration eligible VM see our KubeVirt usecase.
If you are lucky enough to be joining us at KubeCon then please come speak to us, if you’d be interested to see a KubeVirt Live Migration demo.
KubeVirt is very much in it’s early stages, but we think it’s clear why it’s such an exciting project. It has recently become a CNCF sandbox project (there are also some very interesting use cases for KubeVirt discussed in the pull request on GitHub) and is integrated directly into OpenShift. Given the announcement of other projects like VMWare Tanzu, it seems clear that there’s a future in managing VMs alongside applications as Kubernetes resources.
Let us know what you plan to use KubeVirt for or what you’d like to build with KubeVirt on Twitter!