了解持久化存储 | 存储 | AWS 上的 Red Hat OpenShift 服务

持久化存储概述

管理存储与管理计算资源是两个不同的问题。AWS上的Red Hat OpenShift Service使用Kubernetes持久化卷(PV)框架，允许集群管理员为集群配置持久化存储。开发人员可以使用持久化卷声明(PVC)请求PV资源，而无需了解底层存储基础设施的具体知识。

PVC特定于一个项目，由开发人员创建和使用作为使用PV的一种手段。PV资源本身并不局限于任何单个项目；它们可以在整个AWS上的Red Hat OpenShift Service集群中共享，并可以从任何项目中声明。PV绑定到PVC后，就不能再绑定到其他PVC。这使得绑定的PV的作用域限定为单个命名空间，即绑定项目的命名空间。

PV由PersistentVolume API对象定义，该对象表示集群中已存在的存储部分，这些存储部分是由集群管理员静态配置的，或者使用StorageClass对象动态配置的。它就像节点是集群资源一样，是集群中的一个资源。

PV是像Volumes一样的卷插件，但具有独立于使用PV的任何单个pod的生命周期。PV对象捕获存储实现的细节，无论是NFS、iSCSI还是特定于云提供商的存储系统。

基础设施中存储的高可用性留给底层存储提供商。

PVC由PersistentVolumeClaim API对象定义，该对象代表开发人员对存储的请求。它类似于pod，pod消耗节点资源，而PVC消耗PV资源。例如，pod可以请求特定级别的资源，例如CPU和内存，而PVC可以请求特定存储容量和访问模式。例如，它们可以被挂载一次读写或多次只读。

卷和声明的生命周期

PV是集群中的资源。PVC是对这些资源的请求，也充当对资源的声明检查。PV和PVC之间的交互具有以下生命周期。

编辑

配置存储

为了响应开发人员在PVC中定义的请求，集群管理员配置一个或多个动态供应程序，这些供应程序提供存储和匹配的PV。

绑定声明

创建PVC时，您请求特定数量的存储，指定所需的访问模式，并创建一个存储类来描述和分类存储。主服务器中的控制循环监视新的PVC，并将新的PVC绑定到合适的PV。如果不存在合适的PV，则存储类的供应程序将创建一个。

所有PV的大小都可能超过您的PVC大小。对于手动配置的PV尤其如此。为了最大限度地减少冗余，AWS上的Red Hat OpenShift Service将绑定到满足所有其他条件的最小PV。

如果不存在匹配的卷，或者无法使用任何可用的为存储类服务的供应程序创建匹配的卷，则声明将无限期地保持未绑定状态。随着匹配卷的可用，声明将被绑定。例如，具有许多手动配置的50Gi卷的集群将不匹配请求100Gi的PVC。当100Gi PV添加到集群时，可以绑定PVC。

使用pod和已声明的PV

Pod使用声明作为卷。集群检查声明以查找绑定的卷，并为pod挂载该卷。对于支持多种访问模式的卷，必须在将声明用作pod中的卷时指定适用哪种模式。

拥有声明并且该声明已绑定后，绑定的PV将在您需要的时间内属于您。您可以通过在pod的volumes块中包含persistentVolumeClaim来调度pod和访问已声明的PV。

如果将具有大量文件的持久化卷附加到pod，则这些pod可能会失败，或者启动时间可能很长。更多信息，请参见在OpenShift中使用具有大量文件的持久化卷时，为什么pod无法启动或达到“就绪”状态需要过多的时间？。

释放持久化卷

完成卷的操作后，可以从API中删除PVC对象，这允许回收资源。当声明被删除时，卷被认为已释放，但它尚未可用于另一个声明。以前声明者的数据保留在卷上，必须根据策略进行处理。

持久化卷的回收策略

持久化卷的回收策略告诉集群在释放卷后该怎么做。卷的回收策略可以是Retain、Recycle或Delete。

Retain回收策略允许对支持它的卷插件手动回收资源。
Recycle回收策略在卷从其声明中释放后将其回收回未绑定持久化卷的池中。

在AWS上的Red Hat OpenShift Service 4中已弃用Recycle回收策略。建议使用动态配置来获得同等或更好的功能。

Delete回收策略会删除Red Hat OpenShift Service on AWS中的PersistentVolume对象以及外部基础设施（例如Amazon Elastic Block Store (Amazon EBS)或VMware vSphere）中的关联存储资源。

动态配置的卷总是会被删除。

编辑

手动回收持久卷

当持久卷声明 (PVC) 被删除时，持久卷 (PV) 仍然存在，并被认为是“已释放”。但是，由于先前声明者的数据仍然保留在卷中，因此 PV 尚未可用于其他声明。

步骤

要作为集群管理员手动回收 PV

删除 PV。
```
$ oc delete pv <pv-name>
```
删除 PV 后，外部基础设施（例如 Amazon Elastic Block Store (Amazon EBS) 卷）中的关联存储资源仍然存在。
清理关联存储资源上的数据。
删除关联的存储资源。或者，要重用相同的存储资源，请使用存储资源定义创建一个新的 PV。

回收的 PV 现在可供另一个 PVC 使用。

编辑

更改持久卷的回收策略

要更改持久卷的回收策略

列出集群中的持久卷

$ oc get pv

示例输出

NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
 pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
 pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
 pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim3    manual                     3s

选择一个持久卷并更改其回收策略

$ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

验证所选持久卷是否具有正确的策略

$ oc get pv

示例输出

NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             STORAGECLASS     REASON    AGE
 pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim1    manual                     10s
 pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Delete          Bound     default/claim2    manual                     6s
 pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94   4Gi        RWO           Retain          Bound     default/claim3    manual                     3s

在前面的输出中，绑定到声明 default/claim3 的卷现在具有 Retain 回收策略。当用户删除声明 default/claim3 时，该卷不会被自动删除。

持久卷

每个 PV 包含一个 spec 和 status，它们分别是卷的规范和状态，例如

PersistentVolume 对象定义示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 (1)
spec:
  capacity:
    storage: 5Gi (2)
  accessModes:
    - ReadWriteOnce (3)
  persistentVolumeReclaimPolicy: Retain (4)
  ...
status:
  ...

1	持久卷的名称。
2	可用于卷的存储量。
3	访问模式，定义读写和挂载权限。
4	回收策略，指示释放资源后应如何处理该资源。

编辑

PV 类型

Red Hat OpenShift Service on AWS (ROSA) 支持以下持久卷存储选项

AWS Elastic Block Store (EBS)
AWS Elastic File Store (EFS)

ROSA 与来自其他存储供应商的与 Kubernetes Container Storage Interface (CSI) 兼容的卷供应程序一起运行。有关 ROSA 中 CSI 驱动程序的更多信息，请参阅配置 CSI 卷。

容量

通常，持久卷 (PV) 具有特定的存储容量。这是通过使用 PV 的 capacity 属性设置的。

目前，存储容量是唯一可以设置或请求的资源。未来的属性可能包括 IOPS、吞吐量等等。

访问模式

持久卷可以以资源提供程序支持的任何方式安装在主机上。提供程序具有不同的功能，并且每个 PV 的访问模式都设置为该特定卷支持的特定模式。例如，NFS 可以支持多个读写客户端，但特定 NFS PV 可能会在服务器上以只读方式导出。每个 PV 都有一组自己的访问模式来描述该特定 PV 的功能。

声明与具有相似访问模式的卷匹配。只有两个匹配条件：访问模式和大小。声明的访问模式代表一个请求。因此，您可能会获得更多，但绝不会更少。例如，如果声明请求 RWO，但唯一可用的卷是 NFS PV (RWO+ROX+RWX)，则声明将匹配 NFS，因为它支持 RWO。

始终首先尝试直接匹配。卷的模式必须匹配或包含比您请求的更多模式。大小必须大于或等于预期大小。如果两种类型的卷（例如 NFS 和 iSCSI）具有相同的访问模式集，则它们中的任何一个都可以与具有这些模式的声明匹配。卷类型之间没有顺序，也没有办法选择一种类型而不是另一种类型。

所有具有相同模式的卷都被分组，然后按大小排序，从小到大。绑定器获取具有匹配模式的组，并按大小顺序迭代每个组，直到找到一个大小匹配的卷。

卷访问模式描述卷功能。它们不是强制约束。存储提供商负责因资源使用无效而导致的运行时错误。提供商中的错误在运行时显示为挂载错误。

下表列出了访问模式

表 1. 访问模式
访问模式	CLI 缩写	描述
ReadWriteOnce	`RWO`	该卷可以被单个节点以读写方式挂载。
ReadWriteOncePod ^[1]	`RWOP`	该卷可以被单个节点上的单个 Pod 以读写方式挂载。

RWOP 使用 SELinux 挂载功能。此功能取决于驱动程序，并在 ODF、AWS EBS、Azure 磁盘、GCP PD、IBM Cloud 块存储卷、Cinder 和 vSphere 中默认启用。对于第三方驱动程序，请联系您的存储供应商。

表 2. 持久卷支持的访问模式
卷插件	ReadWriteOnce ^[1]	ReadWriteOncePod	ReadOnlyMany	ReadWriteMany
AWS EBS ^[2]	✅	✅
AWS EFS	✅	✅	✅	✅
LVM 存储	✅	✅

ReadWriteOnce (RWO) 卷不能安装在多个节点上。如果节点发生故障，系统不允许将连接的 RWO 卷安装到新节点上，因为它已分配给故障节点。如果因此遇到多附件错误消息，请强制删除关闭或崩溃节点上的 Pod，以避免关键工作负载中的数据丢失，例如动态持久卷附加时。
对于依赖 AWS EBS 的 Pod，请使用重新创建部署策略。
只有原始块卷支持光纤通道和 iSCSI 的 ReadWriteMany (RWX) 访问模式。有关更多信息，请参阅“块卷支持”。

阶段

可以在以下阶段之一中找到卷

表 3. 卷阶段
阶段	描述
可用	尚未绑定到声明的可用资源。
已绑定	该卷已绑定到声明。
已释放	声明已被删除，但资源尚未由集群回收。
失败	该卷的自动回收已失败。

您可以通过运行以下命令查看绑定到 PV 的 PVC 的名称

$ oc get pv <pv-claim>

挂载选项

您可以使用 mountOptions 属性在挂载 PV 时指定挂载选项。

例如

挂载选项示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  mountOptions: (1)
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

1	在将 PV 挂载到磁盘时使用指定的挂载选项。

以下 PV 类型支持挂载选项

AWS Elastic Block Store (EBS)

持久卷声明

每个 PersistentVolumeClaim 对象包含一个 spec 和 status，它们分别是持久卷声明 (PVC) 的规范和状态，例如

PersistentVolumeClaim 对象定义示例

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim (1)
spec:
  accessModes:
    - ReadWriteOnce (2)
  resources:
    requests:
      storage: 8Gi (3)
  storageClassName: gold (4)
status:
  ...

1	PVC 的名称。
2	访问模式，定义读写和挂载权限。
3	可用于 PVC 的存储量。
4	声明所需的 `StorageClass` 的名称。

编辑

存储类

声明可以选择通过在storageClassName属性中指定存储类的名称来请求特定的存储类。只有请求类别的PV（其storageClassName与PVC相同）才能绑定到PVC。集群管理员可以配置动态供应程序来服务一个或多个存储类。集群管理员可以按需创建与PVC中的规范匹配的PV。

集群存储操作员安装默认存储类。此存储类由操作员拥有和控制。除了定义注释和标签外，它不能被删除或修改。如果需要不同的行为，则必须定义自定义存储类。

集群管理员还可以为所有PVC设置默认存储类。当配置默认存储类时，PVC必须显式请求将StorageClass或storageClassName注释设置为""才能绑定到没有存储类的PV。

如果多个存储类被标记为默认存储类，则只有在显式指定storageClassName的情况下才能创建PVC。因此，应只将一个存储类设置为默认存储类。

访问模式

声明在使用特定访问模式请求存储时使用与卷相同的约定。

资源

声明（例如 Pod）可以请求特定数量的资源。在这种情况下，请求的是存储。相同的资源模型适用于卷和声明。

声明作为卷

Pod 通过使用声明作为卷来访问存储。声明必须与使用该声明的 Pod 位于相同的命名空间中。集群在 Pod 的命名空间中查找声明，并使用它来获取支持该声明的PersistentVolume。例如，卷会被挂载到主机和 Pod 中。

将卷挂载到主机和 Pod 中的示例

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html" (1)
        name: mypd (2)
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim (3)

1	在 Pod 内挂载卷的路径。
2	要挂载的卷的名称。不要挂载到容器根目录`/`或主机和容器中相同的任何路径。如果容器具有足够的权限（例如主机`/dev/pts`文件），这可能会损坏您的主机系统。使用`/host`挂载主机是安全的。
3	要使用的PVC名称，该名称存在于相同的命名空间中。

编辑

块卷支持

Red Hat OpenShift Service on AWS 可以静态配置原始块卷。这些卷没有文件系统，并且可以为直接写入磁盘或实现自身存储服务的应用程序提供性能优势。

通过在 PV 和 PVC 规范中指定volumeMode: Block来配置原始块卷。

使用原始块卷的 Pod 必须配置为允许特权容器。

下表显示哪些卷插件支持块卷。

表 4. 块卷支持
卷插件	手动配置	动态配置	完全支持
Amazon Elastic Block Store (Amazon EBS)	✅	✅	✅
Amazon Elastic File Storage (Amazon EFS)
LVM 存储	✅	✅	✅

编辑

块卷示例

PV 示例

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block (1)
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

1	必须将`volumeMode`设置为`Block`以指示此 PV 是原始块卷。

PVC 示例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block (1)
  resources:
    requests:
      storage: 10Gi

1	必须将`volumeMode`设置为`Block`以指示请求原始块 PVC。

Pod规范示例

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  (1)
        - name: data
          devicePath: /dev/xvda (2)
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc (3)

1	对于块设备，使用`volumeDevices`而不是`volumeMounts`。只有`PersistentVolumeClaim`源可以与原始块卷一起使用。
2	`devicePath`而不是`mountPath`表示将原始块映射到系统的物理设备的路径。
3	卷源必须是`persistentVolumeClaim`类型，并且必须与 PVC 的预期名称匹配。

表 5. `volumeMode` 的接受值
值	默认值
文件系统	是
块	否

表 6. 块卷的绑定场景
PV `volumeMode`	PVC `volumeMode`	绑定结果
文件系统	文件系统	绑定
未指定	未指定	绑定
文件系统	未指定	绑定
未指定	文件系统	绑定
块	块	绑定
未指定	块	未绑定
块	未指定	未绑定
文件系统	块	未绑定
块	文件系统	未绑定

未指定的值将导致默认值Filesystem。

编辑

使用 fsGroup 减少 Pod 超时

如果存储卷包含许多文件（约 1,000,000 个或更多），您可能会遇到 Pod 超时。

出现这种情况的原因是，默认情况下，当挂载卷时，Red Hat OpenShift Service on AWS 会递归地更改每个卷内容的所有权和权限，以匹配 Pod 的securityContext中指定的fsGroup。对于大型卷，检查和更改所有权和权限可能非常耗时，从而减慢 Pod 启动速度。您可以使用securityContext内的fsGroupChangePolicy字段来控制 Red Hat OpenShift Service on AWS 检查和管理卷的所有权和权限的方式。

fsGroupChangePolicy定义了在卷暴露在 Pod 内之前更改其所有权和权限的行为。此字段仅适用于支持fsGroup控制的所有权和权限的卷类型。此字段有两个可能的值

OnRootMismatch：只有当根目录的权限和所有权与卷的预期权限不匹配时才更改权限和所有权。这有助于缩短更改卷的所有权和权限所需的时间，从而减少 Pod 超时。
Always：挂载卷时始终更改卷的权限和所有权。

fsGroupChangePolicy 示例

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch" (1)
  ...

1	`OnRootMismatch` 指定跳过递归权限更改，从而有助于避免 Pod 超时问题。

fsGroupChangePolicy字段对临时卷类型（例如 secret、configMap 和 emptydir）无效。