共享存储原理
PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”， 比如Node也是一种容器应用可以“消费”的资源。PV由管理员创建和配 置，它与共享存储的具体实现直接相关，例如GlusterFS、iSCSI、RBD 或GCE或AWS公有云提供的共享存储，通过插件式的机制完成与共享 存储的对接，以供应用访问和使用
PVC则是用户对存储资源的一个“申请”。就像Pod“消费”Node的资 源一样，PVC能够“消费”PV资源。PVC可以申请特定的存储空间和访问 模式
，StorageClass和动态资源供应的机制得到了完 善，实现了存储卷的按需创建，在共享存储的自动化管理进程中实现了 重要的一步，通过StorageClass的定义，管理员可以将存储资源定义为某种类别 （Class），正如存储设备对于自身的配置描述（Profile），例如“快速 存储”“慢速存储”“有数据冗余”“无数据冗余”等。用户根据StorageClass 的描述就能够直观地得知各种存储资源的特性，就可以根据应用对存储 资源的需求去申请存储资源了
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
nfs:
path: /tmp
server: 172.17.0.2
1.存储能力（Capacity）
描述存储设备具备的能力，目前仅支持对存储空间的设置 （storage=xx），未来可能加入IOPS、吞吐率等指标的设置
2.存储卷模式（Volume Mode）
Kubernetes从1.13版本开始引入存储卷类型的设置 （volumeMode=xxx），可选项包括Filesystem（文件系统）和Block（块 设备），默认值为Filesystem
目前有以下PV类型支持块设备类型:◎ AWSElasticBlockStore ◎ AzureDisk ◎ FC ◎ GCEPersistentDisk ◎ iSCSI ◎ Local volume ◎ RBD（Ceph Block Device） ◎ VsphereVolume（alpha）
apiVersion: v1
kind: PersestentVolume
metadata:
name: pv2
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
volumeMode: Block
fc:
targetWWNs: ["50060e801049cdf1"]
lun: 0
readOnly: false
3.访问模式（Access Modes） 对PV进行访问模式的设置，用于描述用户的应用对存储资源的访 问权限。访问模式如下
◎ ReadWriteOnce（RWO）：读写权限，并且只能被单个Node挂 载。◎ ReadOnlyMany（ROX）：只读权限，允许被多个Node挂载。 ◎ ReadWriteMany（RWX）：读写权限，允许被多个Node挂载。
某些PV可能支持多种访问模式，但PV在挂载时只能使用一种访问 模式，多种访问模式不能同时生效
PV可以设定其存储的类别，通过storageClassName参数指定一个 StorageClass资源对象的名称。具有特定类别的PV只能与请求了该类别 的PVC进行绑定。未设定类别的PV则只能与不请求任何类别的PVC进行绑定
5.回收策略（Reclaim Policy）
通过PV定义中的persistentVolumeReclaimPolicy字段进行设置，可 选项如下。◎ 保留：保留数据，需要手工处理。 ◎ 回收空间：简单清除文件的操作（例如执行rm -rf /thevolume/* 命令）。◎ 删除：与PV相连的后端存储完成Volume的删除操作（如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder等设备的内部Volume清 理）。目前，只有NFS和HostPath两种类型的存储支持Recycle策略；AWS EBS、GCE PD、Azure Disk和Cinder volumes支持Delete策略
6.挂载参数（Mount Options）
在将PV挂载到一个Node上时，根据后端存储的特点，可能需要设 置额外的挂载参数，可以根据PV定义中的mountOptions字段进行设置
apiVersion: v1
kind: PersistentVolume
metadata:
name: gce-disk-l
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
mountOptions:
- hard
- nolock
- nfservers=3
gcePersistentDisk:
fsType: ext4
pdName: gce-disk-l
目前，以下PV类型支持设置挂载参数:
◎ AWSElasticBlockStore ◎ AzureDisk ◎ AzureFile ◎ CephFS ◎ Cinder (OpenStack block storage) ◎ GCEPersistentDisk ◎ Glusterfs ◎ NFS ◎ Quobyte Volumes ◎ RBD (Ceph Block Device) ◎ StorageOS◎ VsphereVolume ◎ iSCSI
7.节点亲和性（Node Affinity）
PV可以设置节点亲和性来限制只能通过某些Node访问Volume，可 以在PV定义中的nodeAffinity字段进行设置。使用这些Volume的Pod将 被调度到满足条件的Node上
某个PV在生命周期中可能处于以下4个阶段（Phaes）之一。 ◎ Available：可用状态，还未与某个PVC绑定。 ◎ Bound：已与某个PVC绑定。 ◎ Released：绑定的PVC已经删除，资源已释放，但没有被集群 回收。◎ Failed：自动资源回收失败。
PVC作为用户对存储资源的需求申请，主要包括存储空间请求、访 问模式、PV选择条件和存储类别等信息的设置。下例声明的PVC具有 如下属性：申请8GiB存储空间，访问模式为ReadWriteOnce，PV 选择条 件为包含标签“release=stable”并且包含条件为“environment In [dev]”的 标签，存储类别为“slow”（要求在系统中已存在名为slow的 StorageClass）
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
request:
storage: 8Gi
storageClassName: slow
selector:
matchLabels:
release: "stable"
matchExpressions:
- {key: environment,operator: In,values: [dev]}
PVC的关键配置参数说明如下。
◎ 资源请求（Resources）：描述对存储资源的请求，目前仅支持 request.storage的设置，即存储空间大小。
◎ 访问模式（Access Modes）：PVC也可以设置访问模式，用于描述用户应用对存储资源的访问权限。其三种访问模式的设置与PV的 设置相同
◎ 存储卷模式（Volume Modes）：PVC也可以设置存储卷模式， 用于描述希望使用的PV存储卷模式，包括文件系统和块设备
◎ PV选择条件（Selector）：通过对Label Selector的设置，可使 PVC对于系统中已存在的各种PV进行筛选。系统将根据标签选出合适 的PV与该PVC进行绑定。选择条件可以使用matchLabels和 matchExpressions进行设置，如果两个字段都设置了，则Selector的逻辑 将是两组条件同时满足才能完成匹配
◎ 存储类别（Class）：PVC 在定义时可以设定需要的后端存储 的类别（通过storageClassName字段指定），以减少对后端存储特性的 详细信息的依赖。只有设置了该Class的PV才能被系统选出，并与该 PVC进行绑定
PVC也可以不设置Class需求。如果storageClassName字段的值被设 置为空（storageClassName=""），则表示该PVC不要求特定的Class，系 统将只选择未设定Class的PV与之匹配和绑定。PVC也可以完全不设置 storageClassName字段，此时将根据系统是否启用了名为 DefaultStorageClass的admission controller进行相应的操作
◎ 未启用DefaultStorageClass：等效于PVC设置storageClassName 的值为空（storageClassName=""），即只能选择未设定Class的PV与之 匹配和绑定
◎ 启用DefaultStorageClass：要求集群管理员已定义默认的 StorageClass。如果在系统中不存在默认的StorageClass，则等效于不启 用DefaultStorageClass的情况。如果存在默认的StorageClass，则系统将 自动为PVC创建一个PV（使用默认StorageClass的后端存储），并将它 们进行绑定。集群管理员设置默认StorageClass的方法为，在StorageClass的定义中加上一个annotation“storageclass.kubernetes.io/is- default-class= true”。如果管理员将多个StorageClass都定义为default，则 由于不唯一，系统将无法为PVC创建相应的PV
PV和PVC的生命周期
我们可以将PV看作可用的存储资源，PVC则是对存储资源的需 求，PV和PVC的相互关系遵循如图8.1所示的生命周期
◎ 静态模式：集群管理员手工创建许多PV，在定义PV时需要将 后端存储的特性进行设置
◎ 动态模式：集群管理员无须手工创建PV，而是通过 StorageClass的设置对后端存储进行描述，标记为某种类型。此时要求 PVC对存储的类型进行声明，系统将自动完成PV的创建及与PVC的绑 定。PVC可以声明Class为""，说明该PVC禁止使用动态模式
资源绑定
在用户定义好PVC之后，系统将根据PVC对存储资源的请求（存储 空间和访问模式）在已存在的PV中选择一个满足PVC要求的PV，一旦 找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用 这个PVC了。如果在系统中没有满足PVC要求的PV，PVC则会无限期处 于Pending状态，直到等到系统管理员创建了一个符合其要求的PV。PV 一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行 绑定了。在这种情况下，当PVC申请的存储空间比PV的少时，整个PV 的空间就都能够为PVC所用，可能会造成资源的浪费。如果资源供应使 用的是动态模式，则系统在为PVC找到合适的StorageClass后，将自动创 建一个PV并完成与PVC的绑定
资源使用
Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使 用。Volume的类型为persistentVolumeClaim，在后面的示例中再进行详 细说明。在容器应用挂载了一个PVC后，就能被持续独占使用。不过， 多个Pod可以挂载同一个PVC，应用程序需要考虑多个实例共同访问一 块存储空间的问题
资源释放
当用户对存储资源使用完毕后，用户可以删除PVC，与该PVC绑定 的PV将会被标记为“已释放”，但还不能立刻与其他PVC进行绑定。通过 之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV 才能再次使用
资源回收
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释 放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收， 才能供新的PVC绑定和使用。回收策略详见下节的说明
下面通过两张图分别对在静态资源供应模式和动态资源供应模式 下，PV、PVC、StorageClass及Pod使用PVC的原理进行说明
图8.2描述了在静态资源供应模式下，通过PV和PVC完成绑定，并 供Pod使用的存储管理机制
图8.3描述了在动态资源供应模式下，通过StorageClass和PVC完成 资源动态绑定（系统自动生成PV），并供Pod使用的存储管理机制
StorageClass详解
StorageClass作为对存储资源的抽象定义，对用户设置的PVC申请屏 蔽后端存储的细节，一方面减少了用户对于存储资源细节的关注，另一 方面减轻了管理员手工管理PV的工作，由系统自动完成PV的创建和绑 定，实现了动态的资源供应。基于StorageClass的动态资源供应模式将 逐步成为云平台的标准存储配置模式