PersistentVolume和PersistentVolumeClaim如何实现关注点分离
这个只是用一个和传统场景进行对比的场景来讨论PV和PVC如何实现关注点分离的。并非讨论其原理。
我们可以导出名称空间中应用程序的配置到一个YAML文件，然后在新的名称空间导入该YAML文件。如果应用程序直接使用nfs类型的数据卷，则该nfs的server和path配置随应用程序一起导出到YAML文件中（我还没有使用过nfs类型的存储卷），到新的名称空间导入的应用程序还是对应原来的nfs配置（除非导入后手工修改nfs数据卷的server/path参数）（不排除有人就是有这个需求）。
如果应用程序使用PersistentVolumeClaim声明该应用需要使用一个存储卷，导出成YAML后，可以等到在新的名称空间再导入该YAML时，再决定应该使用什么类型的PersistentVolume以及对应的参数。（新的名称空间中，可能使用cephfs或glusterfs，而不是nfs）（从这个角度看，PV是命名空间资源，但是PV其实是集群资源，这样，这个案例其实不能很好的说明PV和PVC如何实现关注点分离的）
通过PersistentVolume和PersistentVolumeClaim，Kubernetes分离了提供存储和使用存储着两个关注点：
-
PersistentVolumeClaim必须定义在与应用程序相同的名称空间中，关注应用程序如何使用存储，通常由应用程序管理员或开发人员负责
-
PersistentVolume只能定义在集群层面，关注集群如何提供存储，通常由集群管理员或者运维人员负责
理解PV和PVC
PersistentVolume是集群中的一块存储空间，由集群管理员管理、或者由StorageClass自动管理。PV和Node一样，是集群中的资源（Kubernetes集群由存储资源和计算资源组成）。
PersistentVolumeClaim是一种类型的Volume（这一句有点难以理解），PersistentVolumeClaim引用的PersistentVolume有自己的生命周期，该生命周期独立于任何使用它的容器组。PersistentVolume描述了如何提供存储的细节信息（NFS、cephfs等存储的具体参数）。
PersistentVolumeClaim代表用户使用存储的请求。Pod容器组消耗Node计算资源，PVC存储卷声明消耗 PersistentVolume存储资源。Pod容器组可以请求特定数量的计算资源（CPU / 内存）；PVC可以请求特定大小/特定访问模式（只能被单节点读写/可被多节点只读/可被多节点读写）的存储资源。
根据应用程序的特点不同，其所需要的存储资源也存在不同的要求，例如读写性能等。集群管理员必须能够提供关于 PersistentVolume的更多选择，无需用户关心存储卷背后的实现细节。为了解决这个问题，Kubernetes引入了 StorageClass的概念
理解PV与PVC之间的关系
-
PersistentVolume是集群中的存储资源，通常由集群管理员创建和管理
-
StorageClass用于对PersistentVolume进行分类，如果正确配置，StorageClass也可以根据PersistentVolumeClaim的请求动态创建PersistentVolume（所以我们可以设置声明时是立即创建还是延迟创建）
-
PersistentVolumeClaim是使用该资源的请求，通常由应用程序提出请求，并指定对应的StorageClass和需求的空间大小
-
PersistentVolumeClaim可以做为数据卷的一种，被挂载到容器组/容器中使用（这个我是第一次听说）