Starting with vSphere 7.0 Update 2a, DevOps engineers can use the VM Service functionality to deploy and run VMs on a namespace through the

kubectl

commands. You can use the

vSphere Supervisor

automation APIs to manage the two VM Service components: VM classes and content libraries. For more information about managing content libraries in the context of

vSphere Supervisor

, see Content Libraries in vSphere Supervisor.

You can use the automation APIs to create and manage VM classes. A VM class specification defines the number of CPUs, memory capacity, and resource reservation settings of the desired virtual machine.

vSphere Supervisor

currently offers twelve ready-to-use VM classes (T-shirt sizes) that are derived from the most popular VMs in Kubernetes. Based on the resource reservation that a VM specification requests, each predefined VM class has two editions: guaranteed and best effort. The guaranteed VM class fully reserves the configured resources. A best effort VM class does not guarantee any resource reservations and allows their overcommitment.

You associate a VM class with a specific namespace to make it available to the DevOps engineers who have access to that namespace. You can assign any number of existing VM classes or create a custom one. Note that VMs deployed by the DevOps engineers through the VM Service can only be managed with the

kubectl

commands. A VM provisioned by DevOps engineers shares the same resources in a namespace as containers.

Use the

VirtualMachineClasses

interface to create and manage a specification of a VM class object. Through these objects you predefine the number of CPUs, memory capacity, and reservation settings. See Create a VM Class in vSphere Supervisor. To make a VM class available to the DevOps engineers for self-service VM deployment, you must associate it with a specific namespace. See Associating a VM Class with a vSphere Namespace.