I've previously used both types, I've also read through the docs at:
https://kubernetes.io/docs/concepts/storage/persistent-volumes/ https://kubernetes.io/docs/concepts/storage/volumes/
However it's still not clear what the difference is, both seem to support the same storage types, the only thing that comes to mind is there seems to be a 'provisioning' aspect to persistent volumes.
What is the practical difference? Are there advantages / disadvantages between the two - or for what use case would one be better suited to than the other?
Is it perhaps just 'synctactic sugar'?
For example NFS could be mounted as a volume, or a persistent volume. Both require a NFS server, both will have it's data 'persisted' between mounts. What difference would be had in this situation?
They are two different implementations which can provide some similar common functionality (hence a lot of confusion).
Persistent volumes:
StorageClassemptyDir volume type (https://github.com/kubernetes/kubernetes/issues/75378)Volumes:
Volume decouples the storage from the Container. Its lifecycle is coupled to a pod. It enables safe container restarts and sharing data between containers in a pod.
Persistent Volume decouples the storage from the Pod. Its lifecycle is independent. It enables safe pod restarts and sharing data between pods.
A volume exists in the context of a pod, that is, you can't create a volume on its own. A persistent volume on the other hand is a first class object with its own lifecycle, which you can either manage manually or automatically.
The way I understand it is that the concept of a Persistent Volumes builds on that of a Volume and that the difference is that a Persistent Volume is more decoupled from Pods using it. Or as expressed in the introduction of the documentation page about Persistent Volumes:
PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV.
A Volume's lifecycle on the other hand depends on the lifecycle of the Pod using it:
A Kubernetes volume [...] has an explicit lifetime - the same as the Pod that encloses it.
NFS is not really relevant here. Both Volumes and Persistent Volumes are Kubernetes resources. They provide an abstraction of a data storage facility. So for using the cluster, it doesn't matter which concrete operating system resource is behind that abstraction. That's in a way the whole point of Kubernetes.
It might also be relevant here to keep in mind that Kubernetes and its API are still evolving. The Kubernetes developers might sometimes choose to introduce new concepts/resources that differ only subtly from existing ones. I presume one reason for this is to maintain backwards compatibility while still being able to fine tune basic API concepts. Another example for this are Replication Controllers and Replica Sets, which conceptually largely overlap and are therefore redundant to some extent. Although, what's different to the Volume/Persitent Volume matter is that Replication Controllers are explicitly deprecated now.