Table of Contents
The idea of virtual Kubernetes clusters (vClusters) is to spin up a fully-functional cluster within another Kubernetes clusters to provide an efficient abstraction and direct Kubernetes access on top of a shared underlying cluster.
I have already described the benefits and use cases use of such virtual clusters for development, and specifically for cloud-native development, CI/CD, and ML/AI experimentation. However, since vClusters are similarly flexible as regular Kubernetes clusters and namespaces, they can also be used in many situations apart from development.
In this article, I want to describe some of these production use cases that I believe virtual clusters are most valuable for.
Replacing clusters by vClusters to save cost
Running fewer Kubernetes clusters is generally cheaper because fewer clusters lead to less redundancy and higher utilization. Moreover, they are easier to manage by the cluster admins.
However, people are still not running everything on just one cluster for good reasons. Often, this reason is that you had to run everything in namespaces, which do not provide sufficient isolation in many situations. Compared to namespaces, vClusters improve the isolation of tenants and so facilitate the implementation of a harder form of Kubernetes multi-tenancy. This allows you to pool some parts of an application in one cluster that are currently separated due to isolation concerns. (Of course, this does not mean that you should run everything on just one cluster.)
Another reason to separate applications on different clusters is that they require individual configurations of the cluster. While this is not possible with namespaces, virtual clusters can be configured differently and flexibly, e.g. it is even possible to use different Kubernetes versions for the virtual clusters. This again lets you pool applications reducing the number of clusters and thus saves cost.
For this, a virtual cluster solution might also be interesting for hosting and cloud providers who want to provide their customers flexible Kubernetes environments but can also sell such an experience with vClusters at a lower price as not every customer will need an actual physical cluster but just full Kubernetes access.
I wrote a dedicated article about further options to reduce your Kubernetes cost.
Replacing namespaces by vClusters to improve stability
When it is not strictly necessary to separate (parts of) applications on clusters, namespaces are often used as a cheaper and easier approach to run the software. In these situations, the namespaces could be replaced by virtual clusters because they help to improve the security of the system due to their better isolation and provide a more flexible configuration of the different parts of the application.
Virtual clusters Clusters thus do not only allow you to share clusters more often but also are useful to optimize your production system. Therefore, vClusters often are “the better namespace”.
Reaching higher scalability
If you run very large clusters with a lot of network traffic and load, you can reach a technical limit of scalability. Naturally, this mostly happens in production use cases with many users or customers.
In such a situation, you usually need additional clusters to handle the huge amounts of traffic. However, just because, for example, the Kubernetes API server or the etcd of your cluster reach their limit, it does not have to be optimal to run additional clusters. Instead, it could be more efficient to run multiple API servers or etcds to handle the load.
Since each virtual cluster has its own API server and etcd, it is possible to implement efficient Kubernetes cluster sharding with vClusters. This is possible as requests to a virtual cluster are generally handled by the virtual cluster itself, which reduces the load on the underlying cluster because only some requests are passed through and handled by it. You can so “spread” the load on different virtual clusters avoiding an early bottleneck issue from the physical cluster.
Therefore, it is possible to push the technical limits of how much traffic your cluster can handle, which allows you to save costs and optimize your system by only adding clusters if it is really sensible.
Providing managed products easier and cheaper
While the first production use cases for virtual clusters were rather general, there are also more specific scenarios they are very useful for. One of these is the provisioning of a managed product to your customers.
There are generally two main technical approaches to provide your customers with a Software-as-a-Service (SaaS) experience: Multi-tenancy and multi-instances.
If you provide your SaaS-product with a multi-tenancy approach, you run one instance of a system and a database that is shared by different customers. Here, vClusters can again help you by providing better tenant isolation and by allowing more scalability to improve the efficiency of your system.
With the multi-instance approach, every customer gets an own instance of your system and database. Virtual clusters allow you to do this quite easily as you can replicate your system in virtual clusters. So, every customer gets a dedicated instance of your software but all instances are still running on a single cluster, which reduces the management effort for your system. Since no new cluster has to be started for each customer, the setup of a new instance is also faster and the whole system runs more efficiently as the underlying computing resources can be shared and thus do not run idly.
Overall, vClusters are therefore useful to provide SaaS products to your customers no matter which architectural approach you want to use.
Running interactive demos fast and easy
A last production use case for virtual Kubernetes clusters is spinning up interactive demos for your product. Even though demos are not really production systems, their use and functionality are closer to classical production scenarios than to development, which is why I want to mention them here.
If you sell an on-premise product, your customers (especially in B2B) usually want to see a demo before they decide to buy it or even before they set it up themselves on their infrastructure. Such demo versions of your product can either be used by salespeople or by the customers themselves.
In any case, it usually makes sense if the demo always starts in the same clean state and is available anytime, i.e. does not have to be provisioned by admins first.
These requirements make them a very good use case for virtual clusters: vClusters can be started within just a few seconds from scratch instead of several minutes that “real” clusters need to be started in cloud environments. They are also always available if the underlying cluster is running.
Additionally, as there is only one underlying cluster needed for many vClusters, several salespeople (or customers) can start a demo independently on-demand so that there is not only one demo application that always has to be reset after each demonstration. When the demo is finished, the whole demo environment, i.e. the vCluster, can thus also be deleted, a process that even can be automized with an automatic delete setting. Alternatively, it is also possible to keep the environment if it shall be used again to continue at the same stage.
In sum, running demos in virtual clusters is thus cheap due to the shared infrastructure and the automatic cleanup and easy due to the independent environments that are available on-demand. This makes the use of demos during your sales activities more attractive, which will ultimately help to drive sales and revenues.
Conclusion
Virtual clusters have many benefits that make them useful not only for development scenarios but also for various production settings. They can be used to improve your system technically by providing more isolation and thus stability or by increasing the limits to the scalability of your clusters. Additionally, virtual clusters are efficient in reducing your cost if you can replace whole clusters with vClusters. They can also support you in solving the practical problems of how to efficiently provide managed products and product demos to your customers.
Overall and given the abundance of Kubernetes applications, I believe there are also many more use cases for virtual clusters during production that even have not been explored yet.
