OpenShift 文档正在迁移，很快将只在 docs.redhat.com （所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

动态配置

关于动态配置

StorageClass资源对象描述和分类可以请求的存储，并提供一种方法，用于按需动态配置存储。StorageClass对象也可以作为一种管理机制，用于控制不同级别的存储和对存储的访问。集群管理员(cluster-admin)或存储管理员(storage-admin)定义和创建用户可以请求的StorageClass对象，而无需了解底层存储卷源的任何详细信息。

OpenShift Container Platform持久卷框架支持此功能，并允许管理员使用持久性存储配置集群。该框架还为用户提供了一种请求这些资源的方法，而无需了解底层基础设施。

OpenShift Container Platform中可以使用许多存储类型作为持久卷。虽然所有这些都可以由管理员静态配置，但某些类型的存储是使用内置提供程序和插件API动态创建的。

可用的动态配置插件

OpenShift Container Platform提供以下配置程序插件，这些插件具有用于动态配置的通用实现，它们使用集群配置的提供程序的API来创建新的存储资源。

存储类型 配置程序插件名称 备注

Red Hat OpenStack Platform (RHOSP) Cinder

kubernetes.io/cinder

RHOSP Manila容器存储接口(CSI)

manila.csi.openstack.org

安装后，OpenStack Manila CSI驱动程序操作符和ManilaDriver会自动为动态配置所需的所有可用Manila共享类型创建所需的存储类。

Amazon Elastic Block Store (Amazon EBS)

kubernetes.io/aws-ebs

在不同区域使用多个集群进行动态配置时，请使用Key=kubernetes.io/cluster/<cluster_name>,Value=<cluster_id>标记每个节点，其中<cluster_name>和<cluster_id>对于每个集群都是唯一的。

Azure磁盘

kubernetes.io/azure-disk

Azure文件

kubernetes.io/azure-file

persistent-volume-binder服务帐户需要权限才能创建和获取秘密以存储Azure存储帐户和密钥。

GCE持久性磁盘(gcePD)

kubernetes.io/gce-pd

在多区域配置中，建议每个GCE项目运行一个OpenShift Container Platform集群，以避免在当前集群中不存在节点的区域创建PV。

IBM Power®虚拟服务器块

powervs.csi.ibm.com

安装后，IBM Power®虚拟服务器块CSI驱动程序操作符和IBM Power®虚拟服务器块CSI驱动程序会自动创建动态配置所需的存储类。

VMware vSphere

kubernetes.io/vsphere-volume

任何选择的配置程序插件也需要根据相关文档配置相关的云、主机或第三方提供程序。

定义存储类

StorageClass对象当前是全局范围的对象，必须由cluster-admin或storage-admin用户创建。

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

以下部分描述了StorageClass对象的**基本定义**以及每个受支持插件类型的具体示例。

基本 StorageClass 对象定义

以下资源显示了用于配置存储类的参数及其默认值。此示例使用 AWS Elastic BlockStore (EBS) 对象定义。

StorageClass 定义示例
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
...
1 (必填) API 对象类型。
2 (必填) 当前 apiVersion。
3 (必填) 存储类的名称。
4 (可选) 存储类的注释。
5 (必填) 与此存储类关联的预配程序类型。
6 (可选) 特定预配程序所需的参数，这会因插件而异。

存储类注释

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

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

例如

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

这使得任何未指定特定存储类的持久卷声明 (PVC) 都能通过默认存储类自动预配。但是，您的集群可以拥有多个存储类，但只有一个可以作为默认存储类。

beta 注释 storageclass.beta.kubernetes.io/is-default-class 仍在运行；但是，它将在将来的版本中删除。

要设置存储类描述，请将以下注释添加到存储类元数据中

kubernetes.io/description: My Storage Class Description

例如

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

RHOSP Cinder 对象定义

cinder-storageclass.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> (1)
provisioner: kubernetes.io/cinder
parameters:
  type: fast  (2)
  availability: nova (3)
  fsType: ext4 (4)
1 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
2 在 Cinder 中创建的卷类型。默认为空。
3 可用区。如果未指定，则卷通常会在 OpenShift Container Platform 集群拥有节点的所有活动区域中进行轮询。
4 在动态预配的卷上创建的文件系统。此值将复制到动态预配的持久卷的 fsType 字段，并在首次挂载卷时创建文件系统。默认值为 ext4。

RHOSP Manila 容器存储接口 (CSI) 对象定义

安装后，OpenStack Manila CSI驱动程序操作符和ManilaDriver会自动为动态配置所需的所有可用Manila共享类型创建所需的存储类。

AWS Elastic Block Store (EBS) 对象定义

aws-ebs-storageclass.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> (1)
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1 (2)
  iopsPerGB: "10" (3)
  encrypted: "true" (4)
  kmsKeyId: keyvalue (5)
  fsType: ext4 (6)
1 (必填) 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
2 (必填) 从 io1、gp3、sc1、st1 中选择。默认为 gp3。有关有效的 Amazon 资源名称 (ARN) 值，请参阅 AWS 文档。
3 可选：仅适用于 **io1** 卷。每 GiB 的每秒 I/O 操作数。AWS 卷插件将此值乘以请求卷的大小以计算卷的 IOPS。该值的上限为 20,000 IOPS，这是 AWS 支持的最大值。有关更多详细信息，请参阅 AWS 文档。
4 可选：表示是否加密 EBS 卷。有效值为 true 或 false。
5 可选：加密卷时使用的密钥的完整 ARN。如果没有提供，但 encypted 设置为 true，则 AWS 会生成一个密钥。有关有效的 ARN 值，请参阅 AWS 文档。
6 可选：在动态预配的卷上创建的文件系统。此值将复制到动态预配的持久卷的 fsType 字段，并在首次挂载卷时创建文件系统。默认值为 ext4。

Azure 磁盘对象定义

azure-advanced-disk-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage-class-name> (1)
provisioner: kubernetes.io/azure-disk
volumeBindingMode: WaitForFirstConsumer (2)
allowVolumeExpansion: true
parameters:
  kind: Managed (3)
  storageaccounttype: Premium_LRS (4)
reclaimPolicy: Delete
1 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
2 强烈建议使用 WaitForFirstConsumer。这可以在允许足够的存储空间来将 Pod 调度到来自可用区域的空闲工作节点的同时预配卷。
3 可能的值为 Shared（默认）、Managed 和 Dedicated。

Red Hat 仅支持在存储类中使用 kind: Managed。

对于 Shared 和 Dedicated，Azure 会创建非托管磁盘，而 OpenShift Container Platform 会为机器操作系统（根）磁盘创建托管磁盘。但由于 Azure 磁盘不允许在一个节点上同时使用托管磁盘和非托管磁盘，因此使用 Shared 或 Dedicated 创建的非托管磁盘无法附加到 OpenShift Container Platform 节点。
4 Azure 存储帐户 SKU 层次。默认为空。请注意，高级 VM 可以同时附加 Standard_LRS 和 Premium_LRS 磁盘，标准 VM 只能附加 Standard_LRS 磁盘，托管 VM 只能附加托管磁盘，非托管 VM 只能附加非托管磁盘。

  1. 如果将 kind 设置为 Shared，则 Azure 会在与集群相同的资源组中的一些共享存储帐户中创建所有非托管磁盘。

  2. 如果将 kind 设置为 Managed，则 Azure 会创建新的托管磁盘。

  3. 如果将 kind 设置为 Dedicated 并指定了 storageAccount，则 Azure 会在与集群相同的资源组中为新的非托管磁盘使用指定的存储帐户。为此，需要

    • 指定的存储帐户必须位于同一区域。

    • Azure 云提供商必须对存储帐户具有写入权限。

  4. 如果将 kind 设置为 Dedicated 且未指定 storageAccount，则 Azure 会在与集群相同的资源组中为新的非托管磁盘创建一个新的专用存储帐户。

Azure 文件对象定义

Azure 文件存储类使用密钥来存储创建 Azure 文件共享所需的 Azure 存储帐户名称和存储帐户密钥。这些权限是在以下过程中创建的。

步骤

  1. 定义一个允许访问创建和查看密钥的 ClusterRole 对象

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
#  name: system:azure-cloud-provider
  name: <persistent-volume-binder-role> (1)
rules:
- apiGroups: ['']
  resources: ['secrets']
  verbs:     ['get','create']
    1 查看和创建密钥的集群角色的名称。

  2. 将集群角色添加到服务帐户

    $ oc adm policy add-cluster-role-to-user <persistent-volume-binder-role> system:serviceaccount:kube-system:persistent-volume-binder

  3. 创建 Azure File StorageClass 对象

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <azure-file> (1)
provisioner: kubernetes.io/azure-file
parameters:
  location: eastus (2)
  skuName: Standard_LRS (3)
  storageAccount: <storage-account> (4)
reclaimPolicy: Delete
volumeBindingMode: Immediate
    1 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
    2 Azure 存储帐户的位置，例如 eastus。默认为空，这意味着将在 OpenShift Container Platform 集群的位置创建一个新的 Azure 存储帐户。
    3 Azure 存储帐户的 SKU 层次，例如 Standard_LRS。默认为空，这意味着将使用 Standard_LRS SKU 创建一个新的 Azure 存储帐户。
    4 Azure 存储帐户的名称。如果提供了存储帐户，则忽略 skuName 和 location。如果没有提供存储帐户，则存储类将搜索与资源组关联的任何存储帐户，以查找与定义的 skuName 和 location 匹配的任何帐户。

使用 Azure 文件时的注意事项

默认 Azure 文件存储类不支持以下文件系统功能

  • 符号链接

  • 硬链接

  • 扩展属性

  • 稀疏文件

  • 命名管道

此外，已挂载的 Azure 文件目录的所有者用户标识符 (UID) 与容器的进程 UID 不同。可以在 StorageClass 对象中指定 uid 挂载选项，以定义要用于已挂载目录的特定用户标识符。

以下 StorageClass 对象演示了修改用户和组标识符以及为已挂载目录启用符号链接。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
mountOptions:
  - uid=1500 (1)
  - gid=1500 (2)
  - mfsymlinks (3)
provisioner: kubernetes.io/azure-file
parameters:
  location: eastus
  skuName: Standard_LRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
1 指定要用于已挂载目录的用户标识符。
2 指定要用于已挂载目录的组标识符。
3 启用符号链接。

GCE PersistentDisk (gcePD) 对象定义

gce-pd-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage-class-name> (1)
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard (2)
  replication-type: none
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete
1 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
2 选择pd-standard或pd-ssd。默认值为pd-standard。

VMware vSphere 对象定义

vsphere-storageclass.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: <storage-class-name> (1)
provisioner: csi.vsphere.vmware.com (2)
1 存储类的名称。持久卷声明使用此存储类来预配关联的持久卷。
2 有关在 OpenShift Container Platform 中使用 VMware vSphere CSI 的更多信息，请参见Kubernetes 文档。

更改默认存储类

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

例如，如果您定义了两个存储类gp3和standard，并且您想将默认存储类从gp3更改为standard。

先决条件

  • 访问具有集群管理员权限的集群。

步骤

更改默认存储类

  1. 列出存储类

    $ oc get storageclass
    示例输出
    NAME                 TYPE
gp3 (default)        kubernetes.io/aws-ebs (1)
standard             kubernetes.io/aws-ebs
    1 (default)表示默认存储类。

  2. 将所需的存储类设置为默认存储类。

    对于所需的存储类，通过运行以下命令将storageclass.kubernetes.io/is-default-class注释设置为true

    $ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

    您可以在短时间内拥有多个默认存储类。但是，您应该确保最终只有一个默认存储类。

    如果存在多个默认存储类，任何请求默认存储类的持久卷声明 (PVC) (pvc.spec.storageClassName=nil) 将获取最近创建的默认存储类，而不管该存储类的默认状态如何，管理员会在警报仪表盘中收到有关存在多个默认存储类的警报MultipleDefaultStorageClasses。

  3. 从旧的默认存储类中删除默认存储类设置。

    对于旧的默认存储类，通过运行以下命令将storageclass.kubernetes.io/is-default-class注释的值更改为false

    $ oc patch storageclass gp3 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'

  4. 验证更改

    $ oc get storageclass
    示例输出
    NAME                 TYPE
gp3                  kubernetes.io/aws-ebs
standard (default)   kubernetes.io/aws-ebs