PersistentVolume：怎么解决数据持久化

Kubernetes 的 Volume 对数据存储已经给出了一个很好的抽象，它只是定义了有这么一个“存储卷”，而这个“存储卷”是什么类型、有多大容量、怎么存储，我们都可以自由发挥。Pod 不需要关心那些专业、复杂的细节，只要设置好 volumeMounts，就可以把 Volume 加载进容器里使用。

PersistentVolume 对象，它专门用来表示持久存储设备，但隐藏了存储的底层实现。作为存储的抽象，PV 实际上就是一些存储设备、文件系统，比如 Ceph、GlusterFS、NFS，甚至是本地磁盘，管理它们已经超出了 Kubernetes 的能力范围，所以，一般会由系统管理员单独维护，然后再在 Kubernetes 里创建对应的 PV。

PV 属于集群的系统资源，是和 Node 平级的一种对象，Pod 对它没有管理权，只有使用权。

PersistentVolumeClaim，简称 PVC，从名字上看比较好理解，就是用来向 Kubernetes 申请存储资源的。PVC 是给 Pod 使用的对象，它相当于是 Pod 的代理，代表 Pod 向系统申请 PV。一旦资源申请成功，Kubernetes 就会把 PV 和 PVC 关联在一起，这个动作叫做“绑定”（bind）。

apiVersion: v1
kind: PersistentVolume
metadata:name: host-10m-pvspec:storageClassName: host-testaccessModes:- ReadWriteOncecapacity:storage: 10MihostPath:path: /tmp/host-10m-pv/

“storageClassName”对存储类型的抽象 StorageClass。这个 PV 是我们手动管理的，名字可以任意起，这里我写的是 host-test，你也可以把它改成 manual、hand-work 之类的词汇。

“accessModes”定义了存储设备的访问模式，简单来说就是虚拟盘的读写权限，和 Linux 的文件访问模式差不多，目前 Kubernetes 里有 3 种：

ReadWriteOnce：存储卷可读可写，但只能被一个节点上的 Pod 挂载。
ReadOnlyMany：存储卷只读不可写，可以被任意节点上的 Pod 多次挂载。
ReadWriteMany：存储卷可读可写，也可以被任意节点上的 Pod 多次挂载。

你要注意，这 3 种访问模式限制的对象是节点而不是 Pod，因为存储是系统级别的概念，不属于 Pod 里的进程。

“capacity”表示存储设备的容量，这里我设置为 10MB。

“hostPath”它指定了存储卷的本地路径，也就是我们在节点上创建的目录。

一个 PVC，要求使用一个 5MB 的存储设备，访问模式是 ReadWriteOnce：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: host-5m-pvcspec:storageClassName: host-testaccessModes:- ReadWriteOnceresources:requests:storage: 5Mi

PVC 的内容与 PV 很像，但它不表示实际的存储，而是一个“申请”或者“声明”，spec 里的字段描述的是对存储的“期望状态”。

PVC 里的 storageClassName、accessModes 和 PV 是一样的，但不会有字段 capacity，而是要用 resources.request 表示希望要有多大的容量。

Kubernetes 就会根据 PVC 里的描述，去找能够匹配 StorageClass 和容量的 PV，然后把 PV 和 PVC“绑定”在一起，实现存储的分配。