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.
Leave a Reply