集群存储之PV与PVC

PV

PV：Persistent Volume 持久卷。资源提供者，根据集群的基础设施变化而变化，由集群管理员进行配置管理。

PV将存储定义为一种容器应用可以使用的资源。PV由管理员创建和配置，它与存储资源提供者的具体实现直接相关。不同提供者提供的PV类型包括NFS、iSCSI、RBD或者由公有云提供的共享存储。

PV与普通的临时卷一样，也是通过插件机制进行实现的，只是PV的生命周期独立于使用它的Pod。

PV并不直接属于某个Pod。如果某个Pod想要使用PV，需要使用PVC来完成申请。随后Kubernetes会完成从PVC到PV的绑定。之后被绑定的PV就可以被申请的Pod使用了。

一个PV只能被一个PVC绑定，被绑定的PV不能再被其他PVC绑定。

PART.01

PV详解

PV作为对存储资源的定义，主要涉及存储能力，访问模式，存储类型，回收策略，后端存储类型等关键信息的设置。

不同类型的PV是以不同的插件进行设计和实现的，主要包括以下几类：

CSI：CSI容器存储借口，由存储资源提供者提供驱动程序和存储管理程序
FC（Fibre channel）：光纤存储设备
hostPath：宿主机目录，仅供单Node测试
iSCSI：iSCSI存储设备
Local：本地持久化存储
NFS：基于NFS协议的网络文件系统

# 示例
apiVersion：v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity: 
    storage: 5Gi
  volumeMode: Filesystem
  accesModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageOptions:
  - hard
  - nfsvers=4.1
  nfs:
    path: /tmp
    server: 10.15.55.55

存储容量（capacity）

存储容量用于描述存储的容量，目前仅支持对存储空间的设置（storage=XX）。

存储卷模式（volumeMode）

可选性只有两个：Filesystem（文件系统，默认值）和Block（块设备）。

文件系统模式的PV将以目录（Directory）形式被挂载到Pod内。

访问模式

ReadWriteOnce（RWO）：读写权限，只能被单个Node挂载（单用户读写）
ReadOnlyMany（ROX）：只读权限，允许被多个Node挂载（多用户只读）
ReadWriteMany（RWX）：读写权限，允许被多个Node挂载（多用户读写）
ReadWriteOncePod（RWOP）：可以被单个Pod以读写方式挂载，仅支持CSI存储卷，用于集群中只有一个Pod时以读写方式使用这种模式的PVC。

某些PV可能同时支持多种访问模式，但PV在挂载时只能使用一种访问模式，多种访问模式不能同时生效。

节点亲和性（nodeAffinity）

PV可以通过设置节点亲和性来实现只能通过某些Node访问Valume，这可以在PV定义的nodeAffinity字段中进行设置。使用这些Volume的Pod将被调度到满足亲和性要求的Node上。

大部分存储驱动提供的volume都已自动完成亲和性的设置，通常无需用户手动设置。对于Local类型的PV，需要手动设置。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorterms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          volues:
          - my-node

PV生命周期

Available：可用状态，还未与某个PVC绑定
Bound：以与某个PVC绑定
Released：与之绑定的PVC已被删除，但未完成资源回收，不能被其他PVC使用
Failed：自动资源回收失败

PART.01

PVC详解

PVC：PersistentVolumeClaim 持久卷声明。资源的使用着，根据业务的需求变化来配置，用户无需知道PV的技术细节，只需要声明你需要什么样的资源资源即可。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
    - { key: environment, operator: In, values: [dev] }

说明

resources：资源请求，描述对存储资源的请求，通过resources.requests.storage字段设置需求的存储空间的大小
accessModes：访问模式，PVC也可以设置访问模式，用于描述用户应用对存储资源的访问权限
volumeMode：存储卷模式，用于描述希望使用的PV存储卷模式，包括文件系统和块设备。PVC设置的存储卷模式最好与PV存储卷模式相同，以实现绑定。如果不同可能会出现无法绑定的结果。
selector：PV选择条件，通过设置Label Selector，可以使PVC对于系统中已经存在的各种PV进行筛选。系统将根据标签选出合适的PV与该PVC进行绑定。对于选择条件，可以通过matchLabels和matchExpressions进行设置。如果两个字段都已设置，则Selector要同时满足才能完成匹配。
Clas：存储类别，在定义PVC时可以设定需要的后端存储类别（通过storageClassName字段进行指定），以减少对后端存储特性的详细信息的依赖。只有设置了Class的PV才能被系统筛选出来，与该PV进行绑定。PVC也可以不设置Class需求，如果storageClassName字段的值被设置为空（storageClassName=""）,则表示该PVC不需求特定的Class，系统只选择未设定Class的PV与之绑定。PVC也可以完成不设置storageClassName字段，此时将根据系统是否启用了名为DefaultStorageClass的Admission Controller进行相应的操作。
1.资源供应
Kubernetes支持两种资源供应模式：静态（static）和动态（Dynamic）模式。资源供应的结果就是将适合的PV与PVC成功绑定。
静态模式：集群管理员预先创建若干PV，在PV的定义中能够体现存储资源的特征。
动态模式：集群管理员无需预先创建PV，而是通过StorageClass的设置对后端存储资源进行描述，标记存储的类型和特征。用户通过创建的PVC对存储类型进行申请。之后，StorageClass中的驱动提供者将自动完成PV的创建工作，并将创建出的PV与PVC进行绑定。

如果PVC声明的Class为空，则说明PVC不适用动态模式。Kubernetes支持设置集群范围内默认的StorageClass，为用户创建的PVC设置一个默认的存储类StrongClass。

2.资源绑定

在用户定义好PVC后，系统将根据PVC对存储资源的请求（存储空间和访问模式），在已存在的PV中选择一个满足PVC要求的PV。一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。如果系统中没有满足PVC要求的PV，那么PVC会无限期处在pending状态，直到系统为其创建了一个满足要求的PV。

PV一旦与某个PVC完成绑定，就会被这个PVC独占，不能再与其他的PVC绑定。PVC与PV的绑定关系是一对一的，不会存在一对多的情况。但是同一个PVC可以被多个Pod同时挂载（应用需要处理完成多个进程访问同一个存储的问题）。

如果PVC申请的存储空间比PV拥有的存储空间少，则整个PV的空间都能为PVC所用。但是这可能造成一定的资源浪费。

如果资源供应使用的是动态模式，那么系统在为PVC找到合适的StorageClass后，将自动创建一个PV并完成与PVC的绑定。

3.资源使用

当Pod需要使用存储资源时，需要在Volume的定义中引用PVC类型的Volume，将PVC挂载到容器内的某个路径下进行使用。Volume的类型字段为“persistentVolumeClaim”。

Pod在被挂载了PVC后，就可以使用存储资源了。

4.资源回收

用户使用完存储资源后，可以删除PVC。与该PVC绑定的PV会被标记为“已释放”，但它还不能立刻与其他PVC绑定。Pod在该PVC中生成的数据可能还被保留在PV对应的存储设备上。只有在清楚了这些数据后，才能再次使用该PV。

PV的回收策略

Retain（保留）
Delete（删除）
Retain策略 表示在删除PVC后，与之绑定的PV不会被删除，仅被标记为已释放（released）。PV中的数据仍然存在，在清空数据之前不能被新的PVC使用，需要管理员手动清理之后才能继续使用。

清理步骤：

删除PV资源对象，此时与该PV关联的某些外部存储资源提供者的后端存储资产（Asset）中的数据仍然存在。
手动清理PV后端存储资产中的数据。
手动删除后端存储资产。如果希望重用该资产，可以创建一个新的PV与之关联。
Delete策略 表示自动删除PV资源对象和相关后端存储资产，同时会删除与该PV关联的后端存储资产。但并不是所有类型的存储资源都支持Delete策略。
通过动态供应机制创建的PV将继承StorageClass的回收策略，默认为delete策略。管理员应该基于用户的需求来设置StorageClass的回收策略，或者在创建出PV后手动更新其回收策略。

存储对象保护机制

存储资源（PV、PVC）相对于容器应用（Pod）是可以独立管理的资源，可以单独将其删除。在执行删除操作时，系统会检测存储资源当前是否正在被使用，如果仍被使用，则相关资源对象的删除操作会被推迟，直到没有被使用才会执行删除操作。这样可以确保资源在仍被使用的情况下，不会被直接删除而导致数据丢失，这个机制被称为使用中的存储对象的保护机制（Storage Object in Use Protection）。

对于PVC的删除操作将等到使用它的Pod被删除后再执行。当用户删除一个正在使用中的PVC时，PVC资源对象不会被立即立即删除，查看PVC资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pvc-protection”，说明PVC资源对象处于被保护状态。
对PV的删除操作将等到绑定的PVC删除之后再执行。当用户删除一个仍被PVC绑定的PV时，PV对象不会立即被删除，查看PV资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pv-protection”，说明PV资源对象处于被保护状态。

总的来说，PV与PVC的删除顺序是这样的：先删除正在使用PVC的Pod，再删除PVC，最后删除PV。