CNCF KubeVirt v1.4, VMs Are Now Just Another Kubernetes Resource
In line with KubeCon + CloudNativeCon North America this month in Salt Lake City, Utah, the CNCF announced the version 1.4 iteration of KubeVirt.
KubeVirt is a deeply open-source community-based project designed to help cloud-native developers and virtualization-focused software engineering operations teams that want to adopt Kubernetes, but are struggling with existing virtual machine-based workloads that cannot be easily containerized.
A VMware Divert?
Although the etymological naming convention behind KubeVert is simply a portmanteau of Kubernetes + Virtual (Machine), its proximity to sounding like a VMware “divert or convert” tool must surely be pleasing to some who want to free up their orchestration layer with mass adoption and innovation technology, rather than one that has arguably left somewhat less loved through the spoils of war in the Broadcom acquisition.
Does it really sound like a VMware workaround though? Well yes, because the technology provides a unified development platform that developers can use to build, modify and deploy applications residing in both application containers, as well as VMs in one common and shared environment.
To put that slightly differently for extra clarification, developers can create, run and manage VMs in a Kubernetes cluster; so that’s basically saying that they can consider VMs as just another form of Kubernetes resource. That’s a positive because it means those Kubernetes resources (sorry, those VMs) can then be managed with standard Kubernetes tools like kubectl, the developer’s command line tool for communicating with a Kubernetes cluster’s control plane, using the Kubernetes API.
“Benefits are broad and significant. Teams with a reliance on existing virtual machine-based workloads are empowered to rapidly containerize applications. With virtualized workloads placed directly in development workflows, teams can decompose them over time while still leveraging remaining virtualized components as is comfortably desired,” explains the KubeVert team, in its core technology proposition statement.
What’s in Release v1.4?
This update release comes about for logical reasons, it follows the wider release cadence of Kubernetes itself which of course has this year been steered towards supporting more AI workloads and a more cloud-neutral future. With performance optimizations, complexity control considerations and a mature design that enables Kubernetes to act as a host for more APIs to enable developers to be even more agile, some or all of these progressions would surely have been in the mind of the KubeVirt team.
This KubeVirt aligns with Kubernetes v1.31 and is the sixth KubeVirt release to follow the Kubernetes release cadence. Suitably upbeat about the increasing number of commits seen in the KubeVirt repositories, the team used KubeCon this week to host a series of project “maintainer talk” sessions where project maintainers went into other recent enhancements in KubeVirt.
“Recent features in KubeVirt include: ‘VM rollout strategy’, which changes the update management for running virtual machines; ‘VM Volume migration’, which provides a declarative API to move data between volumes; and we also now introduce the ‘Application-Aware Quota’ operator, a solution that addresses the limitations of Kubernetes’ native resource quota system and provides an alternative implementation of resource counting,” explain Vladik Romanovsky, senior principle software engineer at Red Hat and a maintainer of the KubeVirt project alongside David Vossel, senior principal software engineer, also at Red Hat and also a core contributor to the open source KubeVirt project.
New General Availability
This release marks the graduation of several features to general availability. One such is deprecating the feature gate (for turning off functionalities that have been retired, superseded by another feature or become obsolete) and network hotplug, a function to add network interfaces to (and remove them from) running virtual machines.
The KubeVirt devs have also pushed common instance types to general availability to simplify virtual machine creation with a predefined set of resource, performance, and runtime settings. It has also introduced a single configurable for cluster admins to explicitly disable this feature if required. Described by the team as “an oldie but a goodie”, GPU assignment also moves forward to enable users to assign GPUs and vGPUs to virtual machines.
“If you’ve ever wanted to migrate your virtual machine volume from one storage type to another then you’ll be interested in our volume migration feature. For scale and performance, our SIG scale and performance team has added performance benchmarks for resource utilization of virt-controller and virt-api components. Furthermore, the test suite was enhanced by integrating KWOK with SIG-scale tests to simulate nodes and VMIs for testing KubeVirt performance while using minimum resources in test infrastructure,” rounds out the update.
With a whole smörgåsbord of updates to feast on here – and with existing virtual machines potentially languishing in a less-than-productive state across enterprise technology stacks far and wide – the KubeVirt has thanked every contributor large and small.
