Kubernetes 存储资源 PV、PVC 和StorageClass详解

Posted 2023-04-25

参考技术A

Kubernetes 官方文档地址:

在 Kubernetes 中，存储资源和计算资源(CPU、Memory)同样重要，Kubernetes 为了能让管理员方便管理集群中的存储资源，同时也为了让使用者使用存储更加方便，所以屏蔽了底层存储的实现细节，将存储抽象出两个 API 资源 PersistentVolume 和 PersistentVolumeClaim 对象来对存储进行管理。

PersistentVolume 类型实现为插件,目前 Kubernetes 支持以下插件：

PV 生命周期总共四个阶段：

Kubernetes 支持多种存储，这里使用最广泛的 NFS 存储为例来介绍，下面是一个 PV 的例子：

PV 可以通过配置 capacity 中的 storage 参数，对 PV 挂多大存储空间进行设置

PV 可以通过配置 volumeMode 参数，对存储卷类型进行设置，可选项包括：

volumeMode: Filesystem

PV 可以通过配置 accessModes 参数，设置访问模式来限制应用对资源的访问权限，有以下机制访问模式：

`accessModes:

不过不同的存储所支持的访问模式也不相同，具体如下：

PV 可以根据不同的存储卷类型，设置不同的挂载参数，每种类型的存储卷可配置参数都不相同。如 NFS 存储，可以设置 NFS 挂载配置，如下：

PV 可以通过配置 storageClassName 参数指定一个存储类 StorageClass 资源，具有特定 StorageClass 的 PV 只能与指定相同 StorageClass 的 PVC 进行绑定，没有设置 StorageClass 的 PV 也是同样只能与没有指定 StorageClass 的 PVC 绑定。

storageClassName: slow

PV 可以通过配置 persistentVolumeReclaimPolicy 参数设置回收策略，可选项如下：

persistentVolumeReclaimPolicy: Recycle

PVC 可以通过在 Selecter 中设置 Laberl 标签，筛选出带有指定 Label 的 PV 进行绑定。 Selecter 中可以指定 matchLabels 或 matchExpressions ，如果两个字段都设定了就需要同时满足才能匹配。

PVC 设置目前只有 requests.storage 一个参数，用于指定申请存储空间的大小。

PVC 要想绑定带有特定 StorageClass 的 PV 时，也必须设定 storageClassName 参数，且名称也必须要和 PV 中的 storageClassName 保持一致。如果要绑定的 PV 没有设置 storageClassName 则 PVC 中也不需要设置。

当 PVC 中如果未指定 storageClassName 参数或者指定为空值，则还需要考虑 Kubernetes 中是否设置了默认的 StorageClass ：

storageClassName: slow

PVC 中可设置的访问模式与 PV 种一样，用于限制应用对资源的访问权限。

PVC 中可设置的存储卷模式与 PV 种一样，分为 Filesystem 和 Block 两种。

这里使用 NFS 存储，创建 StorageClass 示例：

在创建 StorageClass 之前需要 Kubernetes 集群中存在 Provisioner （存储分配提供者）应用，如 NFS 存储需要有 NFS-Provisioner （NFS 存储分配提供者）应用，如果集群中没有该应用，那么创建的 StorageClass 只能作为标记,而不能提供创建 PV 的作用。

provisioner: nfs-client

后端存储提供的参数，不同的 Provisioner 可与配置的参数也是不相同。例如 NFS Provisioner 可与提供如下参数：

在 StorageClass 中，可以根据不同的存储来指定不同的挂载参数，此参数会与 StorageClass 绑定的 Provisioner 创建 PV 时，将此挂载参数与创建的 PV 关联。

可与在 Kubernetes 集群中设置一个默认的 StorageClass，这样当创建 PVC 时如果未指定 StorageClass 则会使用默认的 StorageClass。

PV 是 Kubernetes 集群的存储资源，而 PVC 则是对存储资源的需求，创建 PVC 需要对 PV 发起使用申请，即和 PV 进行绑定。 PV 和 PVC 是一一对应的关系，它们二者的交互遵循如下生命周期：

存储供给（Provisioning）是指为 PVC 准备可用的 PV 的一种机制。Kubernetes 支持 PV 供给方式有 静态供给 和 动态供给 两种：

在静态模式下，在用户定义好 PVC 后，Kubernetes 将根据 PVC 提出的“申请空间的大小”、“访问模式”从集群中寻找已经存在且满足条件的 PV 进行绑定，如果集群中没有匹配的 PV 则 PVC 将处于 Pending 等待状态，知道系统创建了符合条件的 PV 再与其绑定。PV 与 PVC 绑定后就不能和别的 PVC 进行绑定。

在动态模式下，当创建 PVC 并且指定 StorageClass 后，与 StorageClass 关联的存储插件会自动创建对应的 PV 与该 PVC 进行绑定。

完成存储卷的使用目标之后删除 PVC 对象，以便进行资源回收。不过，至于如何操作则取决于 PV 的回收策略 ，目前有三种策略：

一般 Deployment 中使用 PVC，大部分都是静态供给方式创建，即先创建 PV，再创建 PVC 与 PV 绑定，在设置应用于 PVC 关联。

下面是一个 NFS 存储创建 PV 的例子，如下：

创建 PVC 与 PV 进行关联绑定：

创建应用于 PVC 进行关联：

在有状态的应用中，我们经常使用动态供给方式创建 PV 和 PVC，不过提前需要集群拥有:

只有拥有上面两种资源同时存在时才能使用动态存储，本人这里使用的是 NFS 存储，关于如何创建 NFS Provisioner 可以查看 NFS Provisioner 一文 ，假如 Kubernetes 集群中使用 NFS 存储，且存在 Provisioner 的名称为 nfs-client 那就可以下面创建 StorageClass 示例：

然后 StatefulSet 可以按下方式，在 volumeClaimTemplates 参数中指定使用的 StorageClass ，然后与 StorageClass 关联的 NFS Provisioner 会执行创建 PVC 和 PV，然后两者进行绑定，下面是 StatefulSet 方式使用 volumeClaimTemplates 挂载存储的示例：

精品k8s的存储PV与PVC详解

概述

PV（Persistent Volume）一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC（Persistent Volume Claim）是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的细分：
存储：存储工程师维护
PV： kubernetes管理员维护
PVC：kubernetes用户维护

---

Task：

1. 创建名字为pv-svolume的pvc，指定storageClass为csi-hostpath-sc，大小为10Mi
2. 创建Pod，名字为web-server，镜像为nginx，并且挂载该pvc至/usr/share/nginx/html，挂载的权限为ReadWriteOnce。
3. 通过kubectl edit或者kubectl path将pvc改成70Mi，并且记录修改记录。

step

1. 创建pvc

1)创建yaml格式配置清单文件

cat