Since Kubernetes version 1.14 dynamic volume provisioning is supported to let manage persistent volumes by a provider, such as Azure, AWS, OpenStack among others. Those providers can integrate into the dynamic provisioner API and act as (default) storage class to create and manage provider-specific persistent volumes (PV) and bound them to persistent volume claims (PVC). Provider-specific PVs in this context mean to use native storage services such as Azure Files, AWS EBS, OpenStack Cinder. Kubernetes itself does not offer provisioners by default but the API. Therefore, you always need to make use of a provider to use it as “managed service”.
One of the oldest features and possibilities to assign storage as persistent volume to a pod is based on local storage, or also called hostPath or local which means to consume locally consumed storage of the K8S node. In case you use an Opensource Kubernetes, you will not be able to consume Azure Files except you decide to switch to Azure Kubernetes Service which is the managed Kubernetes offering from Microsoft. Hence, in an Opensource Kubernetes, there are limited ways to make use of dynamic volume provisioning. You could use other tools that are cloud agnostic, like Longhorn, however it is an additional implementation and extension of your environment which requires more effort to implement and maintain.
If you are more interested in a solution for lab, dev and test environments with least overhead which consumes local storage and provide to pods in an automated way compared to cloud providers, you should use local-path-provisioner from rancher which is publicly available.
https://github.com/rancher/local-path-provisioner
What you should consider
Implementation is done quite quickly and described very well. After the first step of applying the new storage class, you will see a running pod which manages new inquiries. You should define this one as your default storage class, If you do not do so, you need to reference this storage class in your future persistent volume claims. If you do not want to care, execute the following command to make local-path-provisioner your default storage class.
kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'Once this is done and you deploy a new pod (or Helm Chart), PVs are automatically created and assigned to the respective PVCs where StorageClass property is not explicitely set, meaning left empty (or set to the newly created StorageClass).
Any persistent volumes will be stored in the default storage location /opt/local-path-provisioner.
This dynamic volume provisioner sets the reclaim policy to delete which means PV is automatically deleted if bounded PVC is deleted. Hence, if you want to keep PVs, you should define the respective reclaim policy in your PVCs.