k8s中的PV和PVS

前言：

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题。Pod中的容器通过Pause容器共享Volume。

一.PV和PVC的引入

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。

拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息：

当前 Volume 来自 AWS EBS。

EBS Volume 已经提前创建，并且知道确切的 volume-id。

Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：

要么询问管理员。

要么自己就是管理员。

这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。

Kubernetes 给出的解决方案是 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。

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

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

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

二、通过NFS实现持久化存储

2.1配置nfs

需要安装

k8s-master: nfs-server

k8s-node1: nfs-client

k8s-node2: nfs-client

所有节点安装nfs

在master节点创建共享目录

授权共享目录

编辑exports文件

配置生效

启动rpc和nfs（注意顺序）

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

2.1 创建PV

下面创建一个 PV mypv1，配置文件 nfs-pv1.yml 如下：

① capacity 指定 PV 的容量为 1G。

② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：

ReadWriteOnce：PV 能以 read-write 模式 mount 到单个节点。

ReadOnlyMany：PV 能以 read-only 模式 mount 到多个节点。

ReadWriteMany ：PV 能以 read-write 模式 mount 到多个节点。

③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：

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 服务器上对应的目录。

创建 mypv1：

• STATUS 为 Available，表示 mypv1 就绪，可以被 PVC 申请。

2.3 创建PVC

接下来创建 PVC mypvc1，配置文件 nfs-pvc1.yml 如下：

PVC 就很简单了，只需要指定 PV 的容量，访问模式和