【Linux39-10】Kubernetes存储之持久卷(pv)及持久卷声明(pvc)、nfs持久化存储

1. pv与pvc

pv持久卷之官方文档

1.1 区别

存储的管理是一个与计算实例的管理完全不同的问题。PersistentVolume 子系统为用户 和管理员提供了一组 API，将存储如何供应的细节从其如何被使用中抽象出来。 为了实现这点，我们引入了两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim

• 持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者 使用存储类（Storage Class）来动态供应。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用 卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
• 持久卷声明（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。

1.2 声明周期

PV 卷是集群中的资源。PVC 声明是对这些资源的请求，也被用来执行对资源的申领检查。

pv卷的提供方式：

• 静态：集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群 用户可用（可见）。PV 卷对象存在于 Kubernetes API 中，可供用户消费（使用）
• 动态：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass
  
  

绑定：

PVC与PV的绑定是一对一的映射。没找到匹配的PV,那么PVC会无限期得处于unbound未绑定状态。

使用：

Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。 用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。

释放：

当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released" 了，但还不能再给另外一个PVC使用。 前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。

回收：

PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained (保留) 、Recycled （再利用）或者Deleted （删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubemetes中移除PV对象，还有对应的外部存储(如AWS EBS，GCE PD，Azure Disk，或者 Cinder volume)。动态供给的卷总是会被删除。

2. pv持久卷

每个 PV 对象都包含：

• spec ：卷的规约
• status ：卷的状态。
  
  

2.1 容量 capacity

一般而言，每个 PV 卷都有确定的存储容量。 容量属性是使用 PV 对象的 capacity 属性来设置的。

目前，存储大小是可以设置和请求的唯一资源。 未来可能会包含 IOPS、吞吐量等属性。

2.2 卷模式 volumeModes

针对 PV 持久卷，Kuberneretes 支持两种卷模式（volumeModes）：

• Filesystem（文件系统） （默认）：volumeMode 属性设置为 Filesystem 的卷会被 Pod 挂载（Mount） 到某个目录。 如果卷的存储来自某块设备而该设备目前为空，Kuberneretes 会在第一次挂载卷之前 在设备上创建文件系统。
• Block（块）：可以将 volumeMode 设置为 Block，以便将卷作为原始块设备来使用。 这类卷以块设备的方式交给 Pod 使用，其上没有任何文件系统。 这种模式对于为 Pod 提供一种使用最快可能方式来访问卷而言很有帮助，Pod 和 卷之间不存在文件系统层。另外，Pod 中运行的应用必须知道如何处理原始块设备。
  
  

2.3 访问模式 accessModes

PersistentVolume 卷可以用资源提供者所支持的任何方式挂载到宿主系统上。 如下表所示，提供者（驱动）的能力不同，每个 PV 卷的访问模式都会设置为 对应卷所支持的模式值。 例如，NFS 可以支持多个读写客户，但是某个特定的 NFS PV 卷可能在服务器 上以只读的方式导出。每个 PV 卷都会获得自身的访问模式集合，描述的是 特定 PV 卷的能力。

访问模式有：

• ReadWriteOnce -该volume只能被单个节点以读写的方式映射
• ReadOnlyMany --该volume可以被多个节点以只读方式映射
• ReadWriteMany -该volume可以被多个节点以读写的方式映射

在命令行接口（CLI）中，访问模式可以简写为:

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany
  
  

重要提醒！ 每个卷只能同一时刻只能以一种访问模式挂载，即使该卷能够支持 多种访问模式。例如，一个 GCEPersistentDisk 卷可以被某节点以 ReadWriteOnce 模式挂载，或者被多个节点以 ReadOnlyMany 模式挂载，但不可以同时以两种模式 挂载。

卷插件	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStore	✓	-	-
AzureFile	✓	✓	✓
AzureDisk	✓	-	-
CephFS	✓	✓	✓
Cinder	✓	-	-
CSI	取决于驱动	取决于驱动	取决于驱动
FC	✓	✓	-
FlexVolume	✓	✓	取决于驱动
Flocker	✓	-	-
GCEPersistentDisk	✓	✓	-
Glusterfs	✓	✓	✓
HostPath	✓	-	-
iSCSI	✓	✓	-
Quobyte	✓	✓	✓
NFS	✓	✓	✓
RBD	✓	✓	-
VsphereVolume	✓	-	- (Pod 运行于同一节点上时可行)
PortworxVolume	✓	-	✓
ScaleIO	✓	✓	-
StorageOS	✓	-	-

2.4 类 storageClassName

每个 PV 可以属于某个类（Class），通过将其 storageClassName 属性设置为某个 StorageClass 的名称来指定。 特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领。 未设置 storageClassName 的 PV 卷没有类设定，只能绑定到那些没有指定特定 存储类的 PVC 申领。

2.5 回收策略

persistentVolumeReclaimPolicy

• Retain：保留，需要手动回收
• Recycle：回收，自动删除卷中敬据
• Delete：删除，相关联的存储资产，如AWS EBS, GCE PD, Azure Disk, or
  OpenStack Cinder卷都会被删除

当前，只有 NFS 和 HostPath 支持回收利用，AWS EBS, GCE PD, Azure Disk 和 OpenStack Cinder卷支持删除（Delete）操作。

2.6 状态

• Available(可用)：空闲的资源，尚未绑定给PVC
• Bound(已绑定)：绑定给了某个PVC
• Released(已释放)：PVC已经删除了，但是PV资源尚未被集群回收
• Failed(失败)：卷的自动回收操作失败

命令行可以显示PV绑定的PVC名称。

3. pvc

每个 PV 对象都包含：

• spec ：卷的规约
• status ：卷的状态。
  
  

访问模式 (accessModes)

申领在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定。

卷模式 (volumeModes)

申领使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用。

资源 (resources)

申领和 Pod 一样，也可以请求特定数量的资源。在这个上下文中，请求的资源是存储。 卷和申领都使用相同的 资源模型

4. nfs持久化存储示例

1）在nfs服务器建立目录 /nfsdata/pv1、/nfsdata/pv2、/nfsdata/pv3，并写入测试页

2）创建pv

• pv1：5Gi，RWO模式，Recycle模式，/nfsdata/pv1
• pv2：10Gi，RWM模式，Recycle模式，/nfsdata/pv2
• pv3：20Gi，ROM模式，Recycle模式，/nfsdata/pv3
  
  

# pv.yml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity: # 容量
    storage: 5Gi
  volumeMode: Filesystem # 卷模式
  accessModes: # 访问模式
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle #回收策略
  storageClassName: nfs #类
  nfs: # nfs服务器
    path: /nfsdata/pv1 # 挂载位置
    server: 192.168.17.250 #服务器地址
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfsdata/pv2
    server: 192.168.17.250
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  capacity:
    storage: 20Gi
  volumeMode: Filesystem
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfsdata/pv3
    server: 192.168.17.250

3）创建pvc

• pvc1：5Gi，RWO（pvc1满足pv1的条件）
• pvc2：10Gi，RWM（pvc2满足pv2的条件）
  
  

# pvc.yml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

4）创建pod：在容器挂载的node节点宿主机一定要安装 nfs-utils

.

• test-pd-1：挂载pvc1
• test-pd-2：挂载pvc2
  
  

apiVersion: v1
kind: Pod
metadata:
  name: test-pd-1
spec:
  containers:
  - image: myapp:v1
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: nfs-pv-1
  volumes:
  - name: nfs-pv-1
    persistentVolumeClaim:
      claimName: pvc1
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pd-2
spec:
  containers:
  - image: myapp:v1
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: nfs-pv-2
  volumes:
  - name: nfs-pv-2
    persistentVolumeClaim:
      claimName: pvc2

5）测试成功！数据共享成功！

6）删除pvc，发现pv的状态变为已释放，过一会会后，资源被回收变为可利用（Available）