A team may need to control Kubernetes APIs and cluster-level objects without receiving ownership of the underlying shared cluster. vCluster provides a virtual Kubernetes cluster with its own control-plane API, giving that team more autonomy than a namespace alone. The relationship with host resources depends on worker placement and synchronization settings. It is useful for development and platform tenancy, but the actual isolation, storage lifecycle and access to host credentials must be evaluated for the chosen topology.
Chart ownership
The project's deployment documentation uses the vcluster chart from https://charts.loft.sh. This is distinct from the vcluster-platform chart for the management platform. Read the edition and feature terms for the chosen deployment instead of assuming every documented platform capability is included.
Before adoption
Decide which resources may synchronize into the host, who can access host credentials, and how storage survives virtual-cluster deletion. Review network access and control-plane persistence. Treat changes to synchronization or datastore configuration as migrations requiring a recovery plan. Compare the operational cost with ordinary namespace tenancy and dedicated clusters.
Consult the configuration documentation and Helm deployment example for the intended topology.
Sources & further reading
Spotted something that needs another look?
Help improve this page →