Kubernetes--存储之PV-PVC

前言：

K8S引入了一组叫作Persistent Volume Claim(PVC)和Persistent Volume（PV）的API对象，大大降低了用户声明和使用持久化Volume的门槛。

概念

Persistent Volume（PV）

PersistentVolume（PV）是群集中由管理员配置的一块存储。它是集群中的资源，就像节点是集群资源一样。 PV是容量插件，如Volumes，但其生命周期独立于使用PV的任何单个pod。此API对象捕获存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。

Persistent Volume Claim(PVC)

PersistentVolumeClaim（PVC）是由用户进行存储的请求。它类似于一个pod。Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）

虽然PVC允许用户使用抽象存储资源，但是PersistentVolumes(PV)对于不同的问题，用户通常需要具有不同属性（例如性能）。群集管理员需要能够提供各种PersistentVolumes不同的方式，而不仅仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有StorageClass 资源。

可以通过两种方式配置PV：静态或动态。
静态：
集群管理员创建了许多PV。它们包含可供群集用户使用的实际存储的详细信息。它们存在于Kubernetes API中，可供使用。

动态：
当管理员创建的静态PV都无法与PVC匹配时，群集可能会尝试为PVC动态配置卷。此配置基于StorageClasses：PVC必须请求存储类，并且管理员必须已创建并配置该类，以便进行动态配置。请求该类的声明""有效地禁用了它们自己的动态配置。

要启用基于存储级别的动态存储配置，集群管理员需要启用API Server上的DefaultStorageClass[准入控制器]。例如，通过确保DefaultStorageClass位于API Server组件的--admission-control标志，使用逗号分隔的有序值列表中，可以完成此操作。

PVC和PV

PVC：描述 Pod想要使用的持久化属性，比如存储大小、读写权限等
PV：描述一个具体的Volume属性，比如Volume的类型、挂载目录、远程存储服务器地址等
StorageClass：充当PV的模板，自动为PVC创建PV

关于PV创建的流程

大多数情况，持久化Volume的实现，依赖于远程存储服务，如远程文件存储（NFS、GlusterFS）、远程块存储（公有云提供的远程磁盘）等。
K8s需要使用这些存储服务，来为容器准备一个持久化的宿主机目录，以供以后挂载使用，创建这个目录分为两阶段：
1、创建一个远程块存储，相当于创建了一个磁盘，称为Attach
由Volume Controller负责维护，不断地检查每个Pod对应的PV和所在的宿主机的挂载情况。可以理解为创建了一块NFS磁盘，相当于执行

gcloud compute instances attach-disk < 虚拟机名字 > --disk < 远程磁盘名字 >

为了使用这块磁盘，还需要挂载操作

2、将这个磁盘设备挂载到宿主机的挂载点，称为Mount
将远程磁盘挂载到宿主机上，发生在Pod对应的宿主机上，是kubelet组件一部分，利用goroutine执行，不会阻塞主我看一下
相当于执行

mount -t nfs :/ /var/lib/kubelet/pods//volumes/kubernetes.io~/

通过这个挂载操作，Volume的宿主机目录就成为了一个远程NFS目录的挂载点，以后写入的所有文件，都会被保存在NFS服务器上
如果是已经有NFS磁盘，第一步可以省略.
同样，删除PV的时候，也需要Umount和Dettach两个阶段处理

绑定
master中的控制环路监视新的PVC，寻找匹配的PV（如果可能），并将它们绑定在一起。如果为新的PVC动态调配PV，则该环路将始终将该PV绑定到PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量，一旦PV和PVC绑定后，Persistent Volume Claim绑定是排它性的，不管它们是如何绑定的，PVC和PV绑定是一对一映射的。

持久化卷声明的保护

PVC保护的目的是确保由Pod正在使用的PVC不会冲系统中移除，因为如果被移除的话可能会导致数据的丢失，当启用PVC保护alpha功能时，如果用户删除了一个Pod正在使用的PVC，则该PVC不会被立即删除，PVC的删除将会被推迟，直到PVC不再被任何Pod使用

注意：当Pod状态为Pending，并且Pod已经分配给节点或Pod为Running状态时，PVC处于活动状态。

生命周期

pv和pvc遵循以下生命周期：

供应准备。通过集群外的存储系统或者云平台来提供存储持久化支持。

静态提供：管理员手动创建多个PV，供PVC使用。
动态提供：动态创建PVC特定的PV，并绑定。

绑定。用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
使用。用户可在pod中像volume一样使用pvc。
释放。用户删除pvc来回收存储资源，pv将变成“released”状态。由于还保留着之前的数据，这些数据需要根据不同的策略来处理，否则这些存储资源无法被其他pvc使用。
回收(Reclaiming)。pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。

保留策略：允许人工处理保留的数据。
删除策略：将删除pv和外部关联的存储资源，需要插件支持。
回收策略：将执行清除操作，之后可以被新的pvc使用，需要插件支持。
目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

PV类型

pv支持以下类型：

GCEPersistentDisk
AWSElasticBlockStore
NFS
iSCSI
RBD (Ceph Block Device)
Glusterfs
AzureFile
AzureDisk
CephFS
Cinder
FC
FlexVolume
Flocker
PhotonPersistentDisk
Quobyte
VsphereVolume
HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)

持久卷演示代码：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: show
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 127.0.0.1

PV访问模式

Persistent Volume可以以资源提供者支持的任何方式挂载到主机上，如下所示，供应商具有不同的功能，每个PV的访问模式都将被设置为该卷支持的特定模式。例如，NFS可以支持多个读/写客户端，但特定的NFS PV可能以只读方式导出到服务器上，每个PV都有一套自己用来描述特定功能的访问模式。

ReadWriteOnce：该卷可以被单个节点以读/写模式挂载
ReadOnlyMany：该卷可以被多个节点以只读模式挂载
ReadWriteMany：该卷可以被多个节点以读/写模式挂载

在命令行中，访问模式缩写为：

RWO -- ReadWriteOnce
ROX -- ReadOnlyMany
RWX -- ReadWriteMany
注意：一个卷一次只能使用一种访问模式挂载，即使它支持很多种访问模式。例如：GCEPersistentDisk可以由单个节点作为ReadWriteOnce模式挂载，或由多个节点以ReadOnlyMany模式挂载，但不能同时挂载。

Volume插件	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStore	√	-	-
AzureFile	√	√	√
AzureDisk	√	-	-
CephFS	√	√	√
Cinder	√	-	-
FC	√	√	-
FlexVolume	√	√	-
Flocker	√	-	-
GCEPersistentDisk	√	√	-
Glusterfs	√	√	√
HostPath	√	-	-
iSCSI	√	√	-
PhotonPersistentDisk	√	-	-
Quobyte	√	√	√
NFS	√	√	√
RBD	√	√	-
VsphereVolume	√	-	-(当Pod并列时有效)
PortworxVolume	√	-	√
ScalelO	√	√	-
StorageOS	√	-	-

回收策略

pv可以设置三种回收策略：

Retain（保留）：手动回收
Recycle（回收）：基本擦除
Delete（删除）：关联的存储资产（例如，AWS EBS，GCE PD，Azure Disk和OpenStack Cinder卷）将被删除

目前只有NFS和HostPath类型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持删除(Delete)策略。

PV属性:

访问模式,与pv的语义相同。在请求资源时使用特定模式。
资源,申请的存储资源数额。

PV卷阶段状态：

Available（可用） – 资源尚未被claim使用
Bound（已绑定） – 卷已经被绑定到claim了
Released（已释放） – claim被删除，卷处于释放状态，但未被集群回收。
Failed（失败） – 卷自动回收失败
命令行会显示绑定到PV的PVC的名称

定义NFS PV 资源(静态):

#pv定义如下:
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

定义pvc资源:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  resources:
    requests:
      storage: 1Gi

pvc和pv匹配规则：

PV 和 PVC 的 spec 字段。比如，PV 的存储（storage）大小，必须满足 PVC的要求。
PV 和 PVC 的 storageClassName 字段必须一样。

StorageClass介绍

StorageClass为管理员提供了一种描述他们提供的存储“类”的方法。不同的类可能映射到服务质量级别，或备份策略，或者由集群管理员确定的任意策略。Kubernetes本身对于什么类代表是不受任何影响的。这个概念有时在其他存储系统中称为“配置文件”。

StorageClass资源

每个都StorageClass包含字段provisioner，parameters和 reclaimPolicy，当PersistentVolume需要动态配置属于该类时使用的字段。
StorageClass对象的名称很重要，用户可以如何请求特定的类。管理员在首次创建StorageClass对象时设置类的名称和其他参数，并且在创建对象后无法更新这些对象。

定义StorageClass资源：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

总结：

PVC和PV相当于面向对象的接口和实现
用户创建的Pod声明了PVC，K8S会找一个PV配对，如果没有PV，就去找对应的StorageClass，帮它创建一个PV，然后和PVC完成绑定
新创建的PV，要经过Master节点Attach为宿主机创建远程磁盘，再经过每个节点kubelet组件把Attach的远程磁盘Mount到宿主机目录

参考：
https://www.cnblogs.com/menkeyi/p/10903647.html

https://www.cnblogs.com/cheyunhua/p/10023750.html

https://www.cnblogs.com/chenqionghe/p/11609008.html