Compare KubeVirt vs. Virtlet for container, VM management

KubeVirt vs. Virtlet

Red Hat originally launched the KubeVirt project, but it is now run by the Cloud Native Computing Foundation and is distributed under the Apache License 2.0. KubeVirt is a Kubernetes add-on that enables developers to build, modify and deploy applications in VMs and containers. With KubeVirt, developers can run both types of applications side by side in the same Kubernetes cluster.

The KubeVirt add-on lets the controllers and agents create, schedule, launch, stop and delete VMs. KubeVirt is a management add-on implemented as a custom resource definition (CRD) that extends the Kubernetes API. KubeVirt VMs are delivered as containerized workloads that run as pods, where they have access to pod resources such as networking and storage.

Virtlet was spearheaded by Mirantis Inc., but is also now available as a free, open source tool under the Apache License 2.0. Virtlet also enables developers to run VM workloads on Kubernetes clusters. But Virtlet is a Kubernetes container runtime interface (CRI) implementation, rather than being an add-on. It builds on higher-level Kubernetes objects and supports most standard kubectl commands, which makes it possible to treat VMs like pods.

The VMs themselves use QEMU Copy On Write version 2 images. Virtlet is a CRI implementation that enables Kubernetes to see VMs much like it does containers. As a result, administrators can use common kubectl commands such as create, get, apply or attach to manage the VMs.

Because their implementation processes differ, KubeVirt and Virtlet contrast in several important ways. For example, Virtlet supports the single root I/O virtualization (SR-IOV) interface -- an extension to the Peripheral Component Interconnect Express specification -- leading to better network performance.

KubeVirt also supports SR-IOV, as well as more volume types including cloudInitNoCloud, cloudInitConfigDrive, persistentVolumeClaim, dataVolume, ephemeral and containerDisk. Virtlet is limited to a custom FlexVolume driver that specifies block devices for VMs, which results in less storage flexibility.

KubeVirt and Virtlet pros and cons

Both technologies -- especially Virtlet -- are still relatively young when compared to more mature products and as such come with limited community support. For some DevOps teams, this raises costs, risks and efficiency concerns. As the technologies improve and integrate into third-party Kubernetes platforms and services, some of these concerns will likely disappear, although it could mean added license or subscription fees.

Because KubeVirt is a CRD implementation, it provides more flexibility to manage and tune VMs, but it also means that the VMs are not as well integrated into Kubernetes as Virtlet; admins must manage them separately from other Kubernetes components, which requires additional processes and commands.

Virtlet offers tighter Kubernetes integration and provides a more podlike experience because it is a CRI implementation. This makes it possible to manage VMs as if they are containers. It also offers better support for high-performance networking, including the SR-IOV interface. It does have limited storage options compared to KubeVirt. Virtlet users are restricted to Kubernetes constructs when they manage the VMs, so they can't take full advantage of a VM's tuning capabilities because the VMs are limited to pod functionality.

Choosing between KubeVirt and Virtlet

The primary use case for KubeVirt or Virtlet is to enable organizations to continue to support their VM-based applications while reducing the overhead that comes with managing multiple technology stacks.

Organizations might have several reasons to continue running their legacy applications in VMs:

• Application migration from VMs to containers can represent a significant investment in time and resources. In some cases, it can be difficult to justify the expense, especially if the application is approaching end of life.
• Some applications are better suited to VMs than to containers, such as certain database systems, directory services or GPU-intensive workloads. Some applications come with security or compliance considerations that warrant VM hosting.
• Even if an organization plans to migrate its legacy applications to containers, such a transition can be slow and risky, and might require a timeline of several years. This means the legacy applications must continue to run in VMs and have support through the transition process.

KubeVirt or Virtlet can prove a viable alternative to maintaining separate technology stacks. However, choosing between the two depends on an organization's storage and networking requirements, as well as on how much functionality they require to manage and tune VMs.

These open source options are both young technologies and there are uncertainties in the implementation process. For this reason, IT and development teams must proceed cautiously with either option. Move VM workloads incrementally and take small steps toward the new environment.