Pod 和容器具有临时或临时性，面向无状态应用。临时存储可让管理员和开发人员更好地管理其某些操作的本地存储。如需有关临时存储概述、类型和管理的更多信息，请参阅了解临时存储。

容器中部署的有状态应用需要持久存储。Red Hat OpenShift Service on AWS 使用名为持久性卷 (PV) 的预置备存储框架来允许集群管理员置备持久性存储。这些卷中的数据可能超过单个 pod 的生命周期。开发人员可以使用持久性卷声明(PVC)来请求存储要求。如需有关持久性存储概述、配置和生命周期的更多信息，请参阅了解持久性存储。

临时存储的限制和请求以字节数量来衡量。您可以使用以下后缀之一将存储表示为普通整数或固定点号：E、P、T、G、M、k。您还可以使用两的指数：Ei、Pi、Ti、Gi、Mi Ki。

例如，以下数量全部代表大约相同的值：128974848、129e6、129M 和 123Mi。

以下示例配置文件显示了一个具有两个容器的 pod：

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi" 1
      limits:
        ephemeral-storage: "4Gi" 2
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"
    volumeMounts:
    - name: ephemeral
      mountPath: "/tmp"
  volumes:
    - name: ephemeral
      emptyDir: {}

pod 规格中的设置会影响调度程序如何决定调度 pod 以及 kubelet 驱除 pod。

根据 PVC 中定义的开发人员的请求，集群管理员配置一个或者多个动态置备程序用来置备存储及一个匹配的 PV。

当您创建 PVC 时，您会要求特定的存储量，指定所需的访问模式，并创建一个存储类来描述和分类存储。master 中的控制循环会随时检查是否有新的 PVC，并把新的 PVC 与一个适当的 PV 进行绑定。如果没有适当的 PV，则存储类的置备程序会创建一个适当的 PV。

所有 PV 的大小可能会超过 PVC 的大小。这在手动置备 PV 时尤为如此。为最小化超额，Red Hat OpenShift Service on AWS 绑定到匹配所有其他标准的最小 PV。

如果匹配的卷不存在，或者相关的置备程序无法创建所需的存储，则请求将会处于未绑定的状态。当出现了匹配的卷时，相应的声明就会与其绑定。例如：在一个集群中有多个手动置备的 50Gi 卷。它们无法和一个请求 100Gi 的 PVC 相匹配。当在这个集群中添加了一个 100Gi PV 时， PVC 就可以和这个 PV 绑定。

pod 使用声明（claim）作为卷。集群通过检查声明来找到绑定的卷，并为 pod 挂载相应的卷。对于那些支持多个访问模式的卷，您必须指定作为 pod 中的卷需要使用哪种模式。

一旦您的声明被绑定后，被绑定的 PV 就会专属于您，直到您不再需要它。您可以通过在 pod 的 volumes 定义中包括 persistentVolumeClaim 来调度 pod 并访问声明的 PV。

当不再需要使用一个卷时，您可以从 API 中删除 PVC 对象，这样相应的资源就可以被重新声明。当声明被删除后，这个卷就被认为是已被释放，但它还不可以被另一个声明使用。这是因为之前声明者的数据仍然还保留在卷中，这些数据必须根据相关政策进行处理。

持久性卷重新声明（reclaim）策略指定了在卷被释放后集群可以如何使用它。卷重新声明政策包括 Retain、Recycle 或 Delete。

删除持久性卷生命（PVC）后，持久性卷（PV）仍然存在，并被视为"released（释放）"。但是，由于之前声明的数据保留在卷中，所以无法再使用 PV。

重新声明的 PV 现在可供另一个 PVC 使用。

更改持久性卷的重新声明策略：

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

与其他存储供应商中的 Kubernetes Container Storage Interface (CSI)兼容卷置备程序的 ROSA 功能。如需有关 ROSA 中的 CSI 驱动程序的更多信息，请参阅配置 CSI 卷。

一般情况下，一个持久性卷（PV）有特定的存储容量。这可以通过使用 PV 的 capacity 属性来设置。

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

一个持久性卷可以以资源供应商支持的任何方式挂载到一个主机上。不同的供应商具有不同的功能，每个 PV 的访问模式可以被设置为特定卷支持的特定模式。例如：NFS 可以支持多个读写客户端，但一个特定的 NFS PV 可能会以只读方式导出。每个 PV 都有自己一组访问模式来描述指定的 PV 功能。

声明会与有类似访问模式的卷匹配。用来进行匹配的标准只包括访问模式和大小。声明的访问模式代表一个请求。比声明要求的条件更多的资源可能会匹配，而比要求的条件更少的资源则不会被匹配。例如：如果一个声明请求 RWO，但唯一可用卷是一个 NFS PV（RWO+ROX+RWX），则该声明与这个 NFS 相匹配，因为它支持 RWO。

系统会首先尝试直接匹配。卷的模式必须与您的请求匹配，或包含更多模式。大小必须大于或等于预期值。如果两个卷类型（如 NFS 和 iSCSI）有相同的访问模式，则一个要求这个模式的声明可能会与其中任何一个进行匹配。不同的卷类型之间没有匹配顺序，在同时匹配时也无法选择特定的一个卷类型。

所有有相同模式的卷都被分组，然后按大小（由小到大）进行排序。绑定程序会获取具有匹配模式的组群，并按容量顺序进行查找，直到找到一个大小匹配的项。。

下表列出了访问模式：

卷可以处于以下几个阶段：

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

$ oc get pv <pv-claim>

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

另外，通过在 storageClassName 属性中指定存储类的名称，声明可以请求一个特定的存储类。只有具有请求的类的 PV（ storageClassName的值与 PVC 中的值相同）才会与 PVC 绑定。集群管理员可配置动态置备程序为一个或多个存储类提供服务。集群管理员可根据需要创建与 PVC 的规格匹配的 PV。

集群管理员也可以为所有 PVC 设置默认存储类。当配置了默认存储类时， PVC 必须明确要求将存储类 StorageClass 或 storageClassName设为 ""， 以便绑定到没有存储类的 PV。

声明在请求带有特定访问权限的存储时，使用与卷相同的格式。

象 pod 一样，声明可以请求具体数量的资源。在这种情况下，请求用于存储。同样的资源模型适用于卷和声明。

pod 通过将声明作为卷来访问存储。在使用声明时，声明需要和 pod 位于同一个命名空间。集群在 pod 的命名空间中找到声明，并使用它来使用这个声明后台的PersistentVolume。卷被挂载到主机和 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

存储类用于区分和划分存储级别和使用。通过定义存储类，用户可以获得动态置备的持久性卷。

在 Red Hat OpenShift Service on AWS 挂载卷并将其传递给容器之前，它会检查卷是否包含由持久性卷定义中 fsType 参数指定的文件系统。如果没有使用文件系统格式化该设备，该设备中的所有数据都会被删除，并使用指定的文件系统自动格式化该设备。

此验证可让您将未格式化的 AWS 卷用作持久性卷，因为 Red Hat OpenShift Service on AWS 在首次使用前会进行格式化。

默认情况下，Red Hat OpenShift Service on AWS 支持最多 39 个 EBS 卷附加到一个节点。这个限制与 AWS 卷限制一致。卷限制取决于实例类型。

有关访问额外存储选项（如卷快照）的详情，请参考 AWS Elastic Block Store CSI Driver Operator。

在部署到 AWS 时，定义在 AWS 上加密容器持久性卷的 KMS 密钥很有用。

CSI 驱动程序通常由容器镜像提供。这些容器不知道其运行的 AWS 上的 Red Hat OpenShift Service。要在 Red Hat OpenShift Service on AWS 中使用与 CSI 兼容的存储后端，集群管理员必须部署几个组件，作为 Red Hat OpenShift Service on AWS 和存储驱动程序间的桥接。

下图显示了在 Red Hat OpenShift Service on AWS 集群中在 pod 中运行的组件的高级概述。

对于不同的存储后端，可以运行多个 CSI 驱动程序。每个驱动程序需要其自身的外部控制器部署，以及带驱动程序和 CSI 注册器的守护进程集。

Red Hat OpenShift Service on AWS 默认安装某些 CSI 驱动程序，为用户提供树状卷插件无法进行的存储选项。

要创建挂载到这些支持的存储资产中的 CSI 置备持久性卷，Red Hat OpenShift Service on AWS 默认安装必要的 CSI 驱动程序 Operator、CSI 驱动程序和所需的存储类。如需有关 Operator 和驱动程序的默认命名空间的更多信息，请参阅特定 CSI Driver Operator 的文档。

下表描述了在 AWS 上安装 Red Hat OpenShift Service 的 CSI 驱动程序及其支持的 CSI 功能，如卷快照和调整大小。

除了上表中列出的驱动程序外，ROSA 功能以及第三方存储供应商提供的 CSI 驱动程序。红帽不会监督第三方置备程序或连接的 CSI 驱动程序，供应商完全控制源代码、部署、操作和 Kubernetes 兼容性。这些卷置备程序被视为客户管理，相应的供应商负责提供支持。如需更多信息，请参阅 AWS 上的 Red Hat OpenShift Service 的共享职责。

动态置备持久性存储取决于 CSI 驱动程序和底层存储后端的功能。CSI 驱动程序的供应商应该记录如何在 Red Hat OpenShift Service on AWS 中创建存储类以及进行配置的参数。

创建的存储类可以被配置为启用动态置备。

以下示例在没有对该模板进行任何修改的情况下安装了一个默认的 MySQL 模板，。

管理默认存储类可让您完成几个不同的目标：

要实现这些目标，您可以更改 ClusterCSIDriver 对象中的 spec.storageClassState 字段的设置。此字段可能的设置有：

oc patch clustercsidriver $DRIVERNAME --type=merge -p "{\"spec\":{\"storageClassState\":\"${STATE}\"}}" 1

使用以下步骤更改默认存储类。

例如，如果您有两个定义的存储类 gp3 和 standard，并且您要将默认存储类从 gp3 改为 标准。

Red Hat OpenShift Service on AWS 可以使用 AWS EBS CSI 驱动程序置备持久性卷 (PV)。

在使用 Container Storage Interface (CSI) Operator 和驱动时，我们建议用户需要熟悉持久性存储和配置 CSI 卷。

要创建挂载到 AWS EBS 存储资产中的 CSI 置备 PV，Red Hat OpenShift Service on AWS 在 openshift-cluster-csi-drivers 命名空间中默认安装 AWS EBS CSI Driver Operator (Red Hat operator)和 AWS EBS CSI 驱动程序。

在过去，存储厂商一般会把存储驱动作为 Kubernetes 的一个部分提供。随着容器存储接口 (CSI) 的实现，第三方供应商可以使用标准接口来提供存储插件，而无需更改核心 Kubernetes 代码。

CSI Operator 为 Red Hat OpenShift Service on AWS 用户存储选项（如卷快照）提供树内卷插件无法实现。

有关在 AWS 上的 Red Hat OpenShift Service 中动态置备 AWS EBS 持久性卷的详情，请参考使用 Amazon Elastic Block Store 的持久性存储。

Red Hat OpenShift Service on AWS 可以使用 AWS EFS CSI 驱动程序置备持久性卷 (PV)。

在使用 CSI Operator 和驱动程序时，建议先熟悉 持久性存储 和配置 CSI 卷。

安装 AWS EFS CSI Driver Operator 后，Red Hat OpenShift Service on AWS 在 openshift-cluster-csi-drivers 命名空间中默认安装 AWS EFS CSI Operator 和 AWS EFS CSI 驱动程序。这可让 AWS EFS CSI Driver Operator 创建挂载到 AWS EFS 资产中的 CSI 置备 PV。

在过去，存储厂商一般会把存储驱动作为 Kubernetes 的一个部分提供。随着容器存储接口 (CSI) 的实现，第三方供应商可以使用标准接口来提供存储插件，而无需更改核心 Kubernetes 代码。

CSI Operator 为 Red Hat OpenShift Service on AWS 用户存储选项（如卷快照）提供树内卷插件无法实现。

存储类用于区分和划分存储级别和使用。通过定义存储类，用户可以获得动态置备的持久性卷。

安装后，AWS EFS CSI Driver Operator （一个 Red Hat operator） 不会默认创建存储类。但是，您可以手动创建 AWS EFS 存储类。

此流程解释了如何在 AWS 中创建和配置 EFS 卷，以便在 Red Hat OpenShift Service on AWS 中使用它们。

AWS EFS CSI 驱动程序支持不同于其他 CSI 驱动程序的动态置备形式。它将新 PV 调配为预先存在的 EFS 卷的子目录。PV 相互独立。但是，它们共享相同的 EFS 卷。删除卷时，置备的所有 PV 也会被删除。EFS CSI 驱动程序为每个此类子目录创建一个 AWS Access Point。由于 AWS AccessPoint 限制，您只能从一个 StorageClass/EFS 卷动态置备 1000 个 PV。

如果您在设置动态置备时遇到问题，请参阅 Amazon Elastic File Storage 故障排除。

可以使用 Amazon Elastic File Storage (Amazon EFS)卷作为单个 PV，而无需动态置备。整个卷挂载到 pod。

如果您在设置静态 PV 时遇到问题，请参阅 Amazon Elastic File Storage 故障排除。

以下信息对于 Amazon Elastic File Storage (Amazon EFS)安全非常重要。

例如，在使用接入点（例如，使用前面描述的动态置备）时，Amazon 会自动将文件的 GID 替换为接入点的 GID。此外，EFS 在评估文件系统权限时，会考虑访问点的用户 ID、组 ID 和次要组 ID。EFS 忽略 NFS 客户端的 ID。有关接入点的详情请参考 https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html。

因此，EFS 卷静默忽略 FSGroup；Red Hat OpenShift Service on AWS 无法将卷上文件的 GID 替换为 FSGroup。任何可以访问挂载的 EFS 接入点的 pod 都可以访问其中的任何文件。

与此无关，传输中的加密默认是启用的。如需更多信息，请参阅 https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html。

以下信息提供了有关如何对 Amazon Elastic File Storage (Amazon EFS)问题进行故障排除的指导：

卸载 AWS EFS CSI Driver Operator （红帽操作器）后，无法访问所有 EFS PV。

以下资源显示了用来配置存储类的参数和默认值。这个示例使用 AWS ElasticBlockStore (EBS) 对象定义。

kind: StorageClass 1
apiVersion: storage.k8s.io/v1 2
metadata:
  name: <storage-class-name> 3
  annotations: 4
    storageclass.kubernetes.io/is-default-class: 'true'
    ...
provisioner: kubernetes.io/aws-ebs 5
parameters: 6
  type: gp3
...

要将存储类设置为集群范围的默认值，请在存储类元数据中添加以下注解：

storageclass.kubernetes.io/is-default-class: "true"

例如：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
...

这允许任何没有指定特定存储类的持久性卷声明（PVC）通过默认存储类自动置备。但是，您的集群可以有多个存储类，但只有其中一个是默认存储类。

要设置存储类描述，请在存储类元数据中添加以下注解：

kubernetes.io/description: My Storage Class Description

例如：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubernetes.io/description: My Storage Class Description
...