Kubernetes之PV和PVC

Volume提供了非常好的数据持久化方案，不过在可管理性上还有不足。Pod通常是由应用的开发人员维护，而Volume则通常是由存储系统的管理员维护。开 发人员要获得上面的信息，要么询问管理员，要么自己就是管理员。这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系 统规模较小或者对于开发环境，这样的情况还可以接受，当集群规模变大，特别是对于生成环 境，考虑到效率和安全性，这就成了必须要解决的问题。Kubemetes 给出的解决方案是PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume (PV)是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV具有持久性，生命周期独立于Pod。

PersistentVolumeClaim (PVC)是对PV的申请(Claim)。PVC通常由普通用户创建 和维护。需要为Pod分配存储资源时，用户可以创建一个PVC,指明存储资源的容量大小 和访问模式(比如只读)等信息，Kubemetes会查找并提供满足条件的PV。

有了 PersistentVolumeClaim,用户只需要告诉Kubemetes需要什么样的存储资源，而不 必关心真正的空间从哪里分配、如何访问等底层细节信息。这些Storage Provider的底层信息 交给管理员来处理，只有管理员才应该关心创建PersistentVolume的细节信息。

---

NFS PersistentVolume

作为准备工作，我们己经在k8s-master节点上搭建了一个NFS服务器，目录为/nfsdata：

下面创建一个PV mypvl,配置文件nfs-pvl.yml

• capacity指定PV的容量为1GB。
• accessModes指定访问模式为ReadWriteOnce,支持的访问模式有3种：ReadWriteOnce 表示PV能以read-write模式mount到单个节点，ReadOnlyMany表示PV能以read-only 模式mount到多个节点,ReadWriteMany表示PV能以read-write模式mount到多个节点。
• persistentVolumeReclaimPolicy指定当PV的回收策略为Recycle,支持的策略有3种： Retain表示需要管理员手工回收；Recycle表示清除PV中的数据，效果相当于执行rm -rf /thevolume/*； Delete 表示删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、 Azure Disk> OpenStack Cinder Volume 等。
• storageClassName指定PV的class为nfs。相当于为PV设置了一个分类，PVC可 以指定class申请相应class的PV。
• 指定PV在NFS服务器上对应的目录。

创建mypvl

STATUS为Available,表示mypvl就绪，可以被PVC申请。 接下来创建PVC mypvcl,配置文件nfs・pvcl.yml

 

PVC就很简单了，只需要指定PV的容量、访问模式和class即可。创建mypvcl：

从kubectl get pvc和kubectl get pv的输出可以看到mypvcl已经Bound到mypvl,申请成功。接下来就可以在Pod中使用存储了，Pod配置文件podl.yml：

与使用普通Volume的格式类似，在volumes中通过persistentVolumeClaim指定使用 mypvc 1 申请的 Volume。创建mypodl

验证PV是否可用

可见，在Pod中创建的文件/mydata/hello确实已经保存到了 NFS服务器目录 /nfsdata/pvl 中。

 

---

回收 PV

当不需要使用PV时，可用删除PVC回收PV

当 PVC mypvc 1 被删除后，我们发现 Kubernetes 启动了一个新 Pod recycler-for-mypv 1,这 个Pod的作用就是清除PV mypvl的数据。此时mypvl的状态为Released,表示已经解除了 与mypvc 1的Bound,正在清除数据，不过此时还不可用。

当数据清除完毕，mypvl的状态重新变为Available,此时可以被新的PVC申请。

/nfsdata/pvl中的hello文件已经被删除了。

因为PV的回收策略设置为Recycle,所以数据会被清除，但这可能不是我们想要的结果。 如果我们希望保留数据，可以将策略设置为Retain

通过kubectl apply更新PV

回收策略已经变为Retain,通过下面的步骤验证其效果

• 重新创建mypvcl o
• 在mypvl中创建文件helloo
• mypvl状态变为Releasedo
• Kubernetes 并没有启动 Pod recycler-fbr-mypvl o
• PV中的数据被完整保留。

虽然mypvl中的数据得到了保留，但其PV状态会一直处于Released,不能被其他 PVC申请。为了重新使用存储资源，可以删除并重新创建mypvl0删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。

新建的mypvl状态为Available,如图9-21所示，已经可以被PVC申请。

PV还支持Delete的回收策略，会删除PV在Storage Provider上对应的存储空间。NFS的 PV 不支持 Delete,支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk>OpenStack Cinder Volume 等。

---

 

PV动态供给

在前面的例子中，我们提前创建了 PV,然后通过PVC申请PV并在Pod中使用，这 种方式叫作静态供给(Static Provision) 。

与之对应的是动态供给(Dynamical Provision),即如果没有满足PVC条件的PV,会 动态创建PVo相比静态供给，动态供给有明显的优势：不需要提前创建PV,减少了管理员 的工作量，效率高。

动态供给是通过StorageClass实现的，StorageClass定义了如何创建PV,下面给出两个 例子。

(1) StorageClass standard,

(2 ) StorageClass slow

这两个StorageClass都会动态创建AWS EBS,不同点在于standard创建的是gp2类型 的EBS,而slow创建的是iol类型的EBSo不同类型的EBS支持的参数可参考AWS官 方文档。

StorageClass 支持 Delete 和 Retain 两种 reclaimPolicy,默认是 Delete o

与之前一样，PVC在申请PV时，只需要指定StorageClass.容量以及访问模式即可