vSphere IaaS control plane offers a VM Service functionality that enables DevOps engineers to deploy and run VMs, in addition to containers, in a common, shared Kubernetes environment. You can use the VM Service to manage the lifecycle of virtual machines in a namespace. VM Service manages stand-alone VMs and VMs that make up TKG clusters.
The VM Service addresses the needs of DevOps teams that use Kubernetes, but have existing VM-based workloads that cannot be easily containerized. It also helps users reduce the overhead of managing a non-Kubernetes platform alongside a container platform. When running containers and VMs on a Kubernetes platform, DevOps teams can consolidate their workload footprint to just one platform.
Each VM deployed through the VM Service functions as a complete machine running all the components, including its own operating system, on top of the vSphere IaaS control plane infrastructure. The VM has access to networking and storage that a Supervisor provides, and is managed using the standard Kubernetes kubectl command. The VM runs as a fully isolated system that is immune to interference from other VMs or workloads in the Kubernetes environment.
When to Use Virtual Machines on a Kubernetes Platform?
Generally, a decision to run workloads in a container or in a VM depends on your business needs and goals. Among the reasons to use VMs appear the following:
- Your applications cannot be containerized.
- You have specific hardware requirements for your project.
- Applications are designed for a custom kernel or custom operating system.
- Applications are better suited to running in a VM.
- You want to have a consistent Kubernetes experience and avoid overhead. Rather than running separate sets of infrastructure for your non-Kubernetes and container platforms, you can consolidate these stacks and manage them with a familiar kubectl command.
Concepts of VM Service
To describe the state of a VM to be deployed in a vSphere Namespace, you use such parameters as a VM class, a VM image, and a storage class. The VM Service then brings together these specifications to create stand-alone VMs or VMs that support TKG clusters.
- VM Service
-
The VM Service is a component of
vSphere IaaS control plane that provides a declarative, Kubernetes-style API for management of VMs and associated vSphere resources. The VM Service enables the vSphere administrators to deliver resources and provide templates, such as VM classes and VM images, to Kubernetes. DevOps engineers can use these resources to describe the desired state of a VM. After the DevOps engineers specify the VM state, the VM Service converts the desired state in to a realized state against backing infrastructure resources.
A VM created through the VM Service can be managed only from the Kubernetes namespace with the kubectl commands. vSphere administrators cannot manage the VM from the vSphere Client, but can display its details and monitor resources it uses. For information, see Monitor Virtual Machines Available in vSphere IaaS Control Plane.
- VM Class
-
The VM class is a VM specification that can be used to request a set of resources for a VM. The VM class is controlled and managed by a vSphere administrator, and defines such parameters as the number of virtual CPUs, memory capacity, and reservation settings. The defined parameters are backed and guaranteed by the underlying infrastructure resources of a
Supervisor.
A vSphere administrator can create custom VM classes.
In addition, Workload Management offers several default VM classes. Generally, each default class type comes in two editions: guaranteed and best effort. A guaranteed edition fully reserves resources that a VM specification requests. A best effort class edition does not and allows resources to be overcommitted. Typically, a guaranteed type is used in a production environment.
Examples of default VM classes include the following.
Class CPU Memory (GB) Reserved CPU and Memory guaranteed-large4 16 Yes best-effort-large4 16 No guaranteed-small2 4 Yes best-effort-small2 4 No The vSphere administrator can assign any number of existing VM classes to make them available to DevOps engineers within a specific namespace.
The VM class provides a simplified experience for the DevOps engineers. The DevOps don't need to understand the full configuration of each VM that they plan to create. Instead, they can select a VM class from available options, and the VM Service manages the VM configuration.
On the Kubernetes side, the VM classes appear as VirtualMachineClass resource.
- VM Image
-
A VM image is a template that contains a software configuration, including an operating system, applications, and data.
When DevOps engineers create VMs, they can select images from the content library associated with the namespace. To the DevOps, the images are exposed as VirtualMachineImage objects.
A vSphere administrator can create VM images that are compatible with vSphere IaaS control plane and upload them to a content library.
- Content Library
- A DevOps engineer uses a content library as a source of images to create a VM. Similar to VM classes, a vSphere administrator assigns existing content libraries to a namespace or a cluster to make them available to DevOps engineers. The vSphere administrator can also make the namespace content library writable. This additional permission allows DevOps users to publish their images to the library.
- Storage Class
- VM Service uses storage classes for placing virtual disks and dynamically attaching persistent volumes. For more information about storage classes, see Using Persistent Storage with Supervisor Workloads in vSphere IaaS Control Plane.
- VM Specification
- DevOps engineers describe the desired state of a VM in a YAML file that brings together the VM image, the VM class, and the storage class.
- VM Operator for Kubernetes
- VM operator enables management of virtual machines with a Kubernetes-style, declarative API.
- Networking
- VM Service does not have any specific requirements and relies on the network configuration available in vSphere IaaS control plane. VM Service supports both types of networking, the vSphere networking or NSX. When VMs are deployed, an available network provider allocates static IP addresses to the VMs. For information, see Supervisor Networking in the vSphere IaaS Control Plane Concepts and Planning documentation.
VM Service and Supervisor with vSphere Zones
When you create VMs on a three-zone Supervisor, the VM instance is replicated across all available zones. To control the VMs placement through the YAML file, the DevOps team can use the Kubernetes label topology.kubernetes.io/zone. For example, topology.kubernetes.io/zone: zone-a02.
Workflow for Provisioning and Monitoring a VM
As a vSphere administrator, you set guardrails for the policy and governance of the VMs, and deliver VM resources, such as VM classes and VM templates to DevOps engineers. After a VM is deployed, you can monitor it using the vSphere Client.
| Step | Performed by | Description |
|---|---|---|
| 1 | vSphere administrator | Create content libraries and assign them to a namespace or Supervisor |
| 2 | vSphere administrator | Create a VM class and assign it to a namespace To use NVIDIA vGPU, configure a PCI device in the VM class. See Deploying a VM with vGPU and Other PCI Devices in vSphere IaaS Control Plane. |
| 3 | DevOp engineer | Provision a VM in a Kubernetes namespace For TKG cluster VMs, see Using TKG Service with vSphere IaaS Control Plane. |
| 4 | vSphere administrator | Monitor deployed VMs |
| 5 | DevOps engineer | Publish a VM image to a content library |
