Kubernetes Dynamic Volume Provisioning gives a handy way to supply pods with dynamically-allocated storage volumes. For example, NFS Provisioner transparently spins up an NFS server and exposes that storage to client pods with Kubernetes volume interface, on-demand.
But how efficient is that? Does provisioner introduce another network protocol layer to communicate with client pod/container, in addition to NFS client-server communication? Or client pod/container talks directly to NFS server once the persistent volume claim was fulfilled?
As mentioned in the official documentation when you consider to allocate Persistent volumes to the Pods in the cluster there is a requirement to specify StorageClass in order to find appropriate provisioner (volume plugin) for the storage provider. StorageClass defines all the necessary parameters have to be passed to the storage provider and what provisioner: should be selected in Kubernetes API apiVersion: storage.k8s.io/v1 for the successful creation of PersistentVolume which corresponds to PersistentVolumeClaim request. Find a list of the provisioners supported internally by Kubernetes here.
However, you are not limited only with internal volume plugins which are already included in provisioner: kubernetes.io module, but there are a lot of external provisioners which can be used for some specific scenarios, look at kubernetes-incubator/external-storage project.