Deploy VM in and via Kubernetes

Deploy VM in and via Kubernetes

Applications are often made up of Kubernetes PODs and VMs. The most common example that we find is, a database in the form of a VM and the rest of the application in the form of PODs. By reflex, rightly or wrongly, what requires data persistence is put in the form of VMs.

The vSphere with Tanzu platform is also a platform that allows simultaneous and native hosting of Kubernetes PODs and VMs.

Until now, VMs and PODs were deployed using different methods and connected to different networks, which could cause developers to delay development environment provisioning and the risk of connection failures. Indeed, developers had to ask the team that manages the infrastructure, the deployment of a VM with an expression of need.

To reduce the time impact and the risk of errors, the infrastructure teams have implemented automation tools via a ticketing system or via a self-service portal to give a certain autonomy. Deployment is much simpler but it is not yet sufficient because it involves the developer learning and using additional tools and retrieving the details of connections to the deployed VM. The self-service portal is not obsolete though, it has many other values ​​such as governance management, I hope I will have the opportunity to write an article on it for details.


Diagram showing a developer who clicks on his portal to deploy a VM that will be connected to a network.
This same developer uses the Kubernetes kubectl command to deploy their PODs. Kubernetes uses its own network.


Since vSphere 7U2a it is now possible to provision VMs in the same way as one deploys PODs, using the Kubernetes kubectl command. To be more precise, since the beginning of vSphere with Tanzu (originally it was called Project Pacific) it was possible to deploy Virtual Machines from Kubernetes, they were however reserved for internal Kubernetes use as for creation by Tanzu Kubernetes Cluster.

Now the developer can also deploy his own virtual machines, they will also be connected to the same network as the pods. The waste of time and the risk of error are thus eliminated. I did the test on my demo environment which is shared with my other colleagues, it takes less than 3 minutes to have a freshly installed MongoDB database from a completely virgin Linux Ubuntu.


Diagram showing a developer who uses both the Kubernetes kubectl command to deploy their PODs and VMs.
Everything will be connected to the same Kubernetes network.
What are the perimeters of each persona?
There are two, the resource provider and the consumer. The resource provider is the infrastructure administrator who will present the resources to be consumed and, if necessary, cap them. The consumer is the developer who will use these resources through Kubernetes to develop their application.
The person of the infrastructure with his usual tool (vSphere client), creates a namespace of resources, grants access rights to the developer, defines the classes of service (number of CPU, amount of RAM) to which the developer will have the right to use and the VM image library that he will be able to use.
The developer connects via his account to the Namespace provided and thus creates his YAML files in order to define his resource needs for his virtual machine (s) and if they wish, he can customize it or them in order to install his tools and the services he needs.
In summary, vSphere with Tanzu leaves the choice to the developer to have its application components developed and hosted on PODs or on VMs using the same tool, the same network and the same platform. This saves time for deployment, development and offer more agility.
If you want to lift the hood, I invite you to read this article: Steps for creating VM through Kubectl

Leave a Reply