Since the vcluster's syncer synchronizes pods to the underlying host cluster to schedule them, vcluster users can (by default, this can be configured in advanced options) use the storage classes of the underlying host cluster to create persistent volume claims and to mount persistent volumes.
vcluster provides a variety of flags to adjust this behavior, including:
By default, creating persistent volumes in the vcluster will have no effect, as vcluster runs without any cluster scoped access in the host cluster. However, if you create a vcluster with the CLI flag
--create-cluster-role (equivalent to the helm value
rbac.clusterRole.create=true), you can enable persistent volume sync.
values.yaml in the form of:
Then deploy the vcluster with:
When you enable persistent volume sync, vcluster will create persistent volumes that are created in vcluster itself in the host cluster in the form of
vcluster-PERSISTENT_VOLUME_NAME-x-VCLUSTER_NAMESPACE-x-VCLUSTER_NAME to avoid any conflicts with already existing persistent volumes or other vclusters that sync persistent volumes. vcluster will then rewrite persistent volume claims with those new names so that it seems that the virtual name was bound.
This means that when you create a PVC in the form of:
vcluster will rewrite this PVC into the following in the host cluster to prevent any conflicts with already existing storage classes or persistent volumes:
This only happens if persistent volume sync is enabled in the vcluster. There might be cases where you want to disable this automatic rewriting of PVCs (for example if you want to mount an already existing PV of the host cluster to a PVC in the vcluster), for that case you can set the annotation called
true, which will tell vcluster to not rewrite the PVC