VSphere VM Service: Provision VMs with Kubernetes APIs
Tanzu integration and vSphere VM Service lets developers and admins spin up VMs and guest OSes as desired-state images in vSphere for Kubernetes-based management.
VMs can be easy -- sometimes too easy -- to provision. This makes it essential to have the right management tools to avoid VM sprawl and ensure that each instance meets organizational requirements. VMware's increased integration of Kubernetes within its offerings aims to make this work easier through Tanzu-based features.
In their VMworld 2021 presentation, "The Future of VM Provisioning -- Enabling VM Lifecycle Through Kubernetes," Nikitha Suryadevara, product line manager, and Myles Gray, staff technical marketing architect, explained how current VM provisioning workflows can cause bottlenecks and how vSphere VM Service lets users launch VM-based workloads in applications with Kubernetes APIs.
In past versions, VM provisioning used vSphere APIs or a ticketing system. VM Service now lets users provision VMs with Kubernetes APIs, which means that the VMware admin can define the constructs of the VM, but the developer can also make changes without the need to use advanced vSphere API constructs or be familiar with administrator workflows.
Help desk-based ticketing systems have been built for more traditional applications and customers note that it inhibits a certain level of flexibility -- especially compared to cloud user experiences that allow developers and admins to spin up instances very quickly.
With the integration of Tanzu in vSphere 7.0, admins and developers can now provision VMs through Kubernetes APIs, vSphere VM Service and VM Operator. Admins can have these VMs and guest OSes as desired-state images, which removes the need to convert VMs into an item that Kubernetes can manage.
"VM Service has a whole bunch of goodies inside, from declarative Kubernetes CRD-based VM provisioning, automatic load balancing across multiple VMs, industry standard cloud-init based guest OS customization for developer users all the way to administrative controls for VM Images and VM Classes (think t-shirt sizing) for the vSphere administrator," wrote Gray in a VMware blog.
Make VM launches easier for all
With a ticketing system for VM provisioning, there is a lag time from when developers need VMs to when vSphere admins can launch any necessary VMs. This is not the cloudlike experience developers know and are familiar with, Suryadevara noted.
The VM Service provides Kubernetes support so developers can create and manage VMs. This enables a consistent Kubernetes experience within an interface that developers are already familiar with and removes the need to be familiar with ticketing systems or have asynchronous support. It also closer integrates with other Kubernetes resources such as storage, networks and namespaces.
"The combination of this is one that empowers the developers and assures the administrators," Suryadevara said. "While the DevOps user is interacting with the VMs through Kubernetes and with the YAML files, on the other side of it, the vSphere administrator can still use vCenter to see these VMs that are being deployed and see the running state of the system. Both users get the interface that they are most comfortable using."
Types of VM Service users
Ideally, developers and vSphere admins can be split into two main personas.
A DevOps user has Kubernetes-native APIs and needs a consistent way to manage applications with native K8s, Pods, VMs and Tanzu Kubernetes clusters. They also look for self-service lifecycle management of VMs that adhere to any rules that vSphere admins set.
For vSphere admins, it's much more about overall management. They use the vSphere APIs or UI, and use the namespaces to set resource limits, associate storage classes, VM classes, content libraries and assign DevOps user privileges.
To show what these workflows would look like on both the developer and vSphere admin, the session included a tech demo on how to load up VM Service and how to navigate the software for both types of users.
To start up with VM Service, users must start at the VMware Marketplace to get an image and deploy an open virtual application. The VM Service then uses cloud-init framework so that users can customize a guest OS beyond host name and IP address, such as arbitrary packages and run scripts.
Looking forward with VM Service
Though the demo focused on the current product version, there's still more to come for both developers and vSphere admins, according to Suryadevara.
She detailed out seven potential roadmap items, the first being to open up the types of VM images that the VM Service supports, but the most requested is Windows OS.
Second is added support for GPUs and other hardware accelerator types for the VM Service.
"We would like the VM Service and Kubernetes interface to be able to take advantage of all the advanced VM-level improvements that vSphere has made over the past decade," she said.
The third item is to expand the set of VM configuration options available to users in VM Service. With current vSphere APIs, there are multiple knobs and configurations available for users to modify on VMs, but not all of them are exposed to Kubernetes.
Forth, which is already underway, is bringing about an open source VM Operator.
Fifth is to add support for more content sources. There is currently support for images within vSphere, but there is exploration for being able to use image sources for VMTX, S3 buckets and Bitnami.
Sixth is to pull in existing VMs into Kubernetes-based management. Currently, the VM Service mostly works with greenfield VM deployments -- but customers are looking to pull VMs that admins have already created vSphere properties under Kubernetes.
Seven is to give users the ability to autoscale VMs up and down, like how cloud admins can scale resources as needed.
