存储
pv，pvc， storageClass
PV 实际上就是一些存储设备、文件系统
PV 属于集群的系统资源，是和 Node 平级的一种对象，Pod 对它没有管理权，只有使用权。
但是不同存储差别太大，让 Pod 直接去选择 PV 也很不灵活
于是 Kubernetes 就又增加了两个新对象，PersistentVolumeClaim 和 StorageClass，用的还是“中间层”的思想，把存储卷的分配管理过程再次细化。
PersistentVolumeClaim，简称 PVC，从名字上看比较好理解，就是用来向 Kubernetes 申请存储资源的。PVC 是给 Pod 使用的对象，它相当于是 Pod 的代理，代表 Pod 向系统申请 PV。一旦资源申请成功，Kubernetes 就会把 PV 和 PVC 关联在一起，这个动作叫做“绑定”（bind）。
但是，系统里的存储资源非常多，如果要 PVC 去直接遍历查找合适的 PV 也很麻烦，所以就要用到 StorageClass。
StorageClass 的作用有点像 IngressClass，它抽象了特定类型的存储系统（比如 Ceph、NFS），在 PVC 和 PV 之间充当“协调人”的角色，帮助 PVC 找到合适的 PV。也就是说它可以简化 Pod 挂载“虚拟盘”的过程，让 Pod 看不到 PV 的实现细节
到目前为止，PV 还是需要人工管理。为了使pv的创建自动化，可以用 StorageClass 绑定一个 Provisioner 对象，而这个 Provisioner 就是一个能够自动管理存储、创建 PV 的应用。 Kubernetes 里就是“动态存储卷”的概念。
Kubernetes 里每类存储设备都有相应的 Provisioner 对象。比如nfs，NFS Provisioner 也是以 Pod 的形式运行在 Kubernetes 里的，在 GitHub 的 deploy 目录里是部署它所需的 YAML 文件，一共有三个，分别是 rbac.yaml、class.yaml 和 deployment.yaml。
因为有了 Provisioner，我们就不再需要手工定义 PV 对象了，只需要在 PVC 里指定 StorageClass 对象，它再关联到 Provisioner。我们不需要直接定义 PV 对象，但由于有 NFS Provisioner，它就自动创建一个 PV。
pvc–> storageClass –> provisioner –> pv