流程

1. 从 OpenShift Web 控制台点 Workloads → Pods。

2. 从 Project 下拉列表中选择 openshift-storage。

   注意

   如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。

   有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息，请参阅 表 2.1 “对应 OpenShift Data Foundation 集群的 Pod”。

3. 点 Running 和 Completed 标签页验证以下 pod 是否处于 Running 和 Completed 状态：

   表 2.1. 对应 OpenShift Data Foundation 集群的 Pod

   组件	对应的 pod
   OpenShift Data Foundation Operator	OCS-operator-*（在任何 worker 节点上有 1 个 pod） ocS-metrics-exporter-*（任何 worker 节点上 1 个 pod） odF-operator-controller-manager-*（任何 worker 节点上 1 个 pod） odf-console-* (任何 worker 节点上 1 个 pod)
   Rook-ceph Operator	rook-ceph-operator-* （任何 worker 节点上有 1 个 pod）
   多云对象网关	noobaa-operator-* (任何 worker 节点上 1 个 pod) noobaa-core-* (任何存储节点上 1 个 pod) noobaa-db-pg-* (任何存储节点上 1 个 pod) noobaa-endpoint-* (任何存储节点上 1 个 pod)
   MON	rook-ceph-mon-* （在存储节点间分布 3 个 pod）
   MGR	rook-ceph-mgr-* （任何存储节点上的 1 个 pod）
   MDS	rook-ceph-mds-ocs-storagecluster-cephfilesystem-* （2 个 pod 在存储节点间分布）
   CSI	cephfs csi-cephfsplugin-* (每个 worker 节点上 1 个 pod) csi-cephfsplugin-provisioner-* （2 个 pod 在不同的 worker 节点上分布） rbd csi-rbdplugin-* (每个 worker 节点上 1 个 pod) csi-rbdplugin-provisioner-* （2 个 pod 在不同的 worker 节点上分步）
   rook-ceph-crashcollector	rook-ceph-crashcollector-* （每个存储节点上 1 个 pod）
   OSD	rook-ceph-osd-* (每个设备 1 个 pod) rook-ceph-osd-prepare-ocs-deviceset-* （每个设备 1 个 pod）

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
3. 在 Block and File 选项卡的 Status 卡中，验证 Storage Cluster 是否具有绿色勾号。
4. 在 Details 卡中，验证是否显示集群信息。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。

2. 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。

   1. 在 Object 选项卡的 Status 卡 中，验证 Object Service 和数据弹性 都具有绿色勾号。
   2. 在 Details 卡中，验证是否显示了 MCG 信息。

流程

1. 从 OpenShift Web 控制台左侧窗格中，点击 Storage → Storage Classes。

2. 验证是否在创建 OpenShift Data Foundation 集群时创建了以下存储类：

   • ocs-storagecluster-ceph-rbd
   • ocs-storagecluster-cephfs
   • openshift-storage.noobaa.io

1. 从 OpenShift Web 控制台左侧窗格中，点击 Workloads → Pods。

2. 从 Project 下拉列表中选择 openshift-storage。

   注意

   如果禁用 Show default projects 选项，请使用切换按钮列出所有默认项目。

   有关每个组件预期的 pod 数量及其变化取决于节点数量的更多信息，请参阅 表 3.1 “对应 OpenShift Data Foundation 组件的 Pod”

3. 验证以下 pod 是否处于运行状态：

   表 3.1. 对应 OpenShift Data Foundation 组件的 Pod

   组件	对应的 pod
   OpenShift Data Foundation Operator	OCS-operator-*（在任何 worker 节点上有 1 个 pod） ocS-metrics-exporter-*（任何 worker 节点上 1 个 pod） odF-operator-controller-manager-*（任何 worker 节点上 1 个 pod） odf-console-* (任何 worker 节点上 1 个 pod)
   Rook-ceph Operator	rook-ceph-operator-* （任何 worker 节点上有 1 个 pod）
   多云对象网关	noobaa-operator-* (任何 worker 节点上 1 个 pod) noobaa-core-*（任何 worker 节点上有 1 个 pod） noobaa-db-pg-*（任何 worker 节点上有 1 个 pod） noobaa-endpoint-*（ 任何 worker 节点上有 1 个 pod）
   CSI	cephfs csi-cephfsplugin-* (每个 worker 节点上 1 个 pod) csi-cephfsplugin-provisioner-* （2 个 pod 在不同的 worker 节点上分布） 注意 如果没有在外部集群中部署 MDS，则不会创建 csi-cephfs 插件 pod。 rbd csi-rbdplugin-* (每个 worker 节点上 1 个 pod) csi-rbdplugin-provisioner-* （2 个 pod 在不同的 worker 节点上分步）

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。
3. 在 Block and File 选项卡的 Status 卡中，验证 Storage Cluster 和 Data Resiliency 是否都具有绿色勾号。

4. 在 Details 卡中，验证集群信息是否显示如下。

   + 服务名称：OpenShift Data Foundation 集群名称：: ocs-external-storagecluster Provider:OpenStack 模式：external Version:: ocs-operator-4.9.0

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。

2. 在 Overview 选项卡的 Status 卡中，点 Storage System，然后点弹出框中的存储系统链接。

   1. 在 Object 选项卡的 Status 卡中，验证 Object Service 和数据弹性都具有绿色勾号。
   2. 在 Details 卡中，验证 Multicloud Object Gateway(MCG)信息是否已显示。

1. 删除使用 OpenShift Data Foundation 的卷快照。

   1. 列出所有命名空间中的卷快照

      $ oc get volumesnapshot --all-namespaces

   2. 从上一命令的输出中，识别和删除使用 OpenShift Data Foundation 的卷快照。

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>

2. 删除使用 OpenShift Data Foundation 的 PVC 和 OBC。

   在默认的卸载模式 (graceful) 中，卸载程序会等待所有使用 OpenShift Data Foundation 的 PVC 和 OBC 被删除。

   如果要事先删除 PVC 来删除存储集群，您可以将卸载模式注解设置为"强制"并跳过此步骤。这样做会导致系统中出现孤立 PVC 和 OBC。

   1. 使用 OpenShift Data Foundation 删除 OpenShift Container Platform 监控堆栈 PVC。

      请参阅从 OpenShift Data Foundation 中删除监控堆栈

   2. 使用 OpenShift Data Foundation 删除 OpenShift Container Platform Registry PVC。

      从 OpenShift Data Foundation 中删除 OpenShift Container Platform registry

   3. 使用 OpenShift Data Foundation 删除 OpenShift Container Platform 日志 PVC。

      从 OpenShift Data Foundation 中删除集群日志记录操作器

   4. 删除使用 OpenShift Data Foundation 置备的其他 PVC 和 OBC。

      • 下面是一个示例脚本，用于标识使用 OpenShift Data Foundation 置备的 PVC 和 OBC。该脚本将忽略 OpenShift Data Foundation 内部使用的 PVC 和 OBC。

        #!/bin/bash
        
        RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com"
        CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com"
        NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc"
        RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket"
        
        NOOBAA_DB_PVC="noobaa-db"
        NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc"
        
        # Find all the OCS StorageClasses
        OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}')
        
        # List PVCs in each of the StorageClasses
        for SC in $OCS_STORAGECLASSES
        do
                echo "======================================================================"
                echo "$SC StorageClass PVCs and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done

      • 删除 OBC。

        $ oc delete obc <obc name> -n <project name>

      • 删除 PVC。

        $ oc delete pvc <pvc name> -n <project-name>

        确保您已删除了集群中创建的自定义后备存储、存储桶类等。

3. 删除 Storage Cluster 对象并等待相关资源被删除。

   $ oc delete -n openshift-storage storagesystem --all --wait=true

4. 删除命名空间并等待删除完成。如果 openshift-storage 是活跃的项目，则需要切换到另一个项目。

   例如：

   $ oc project default
   $ oc delete project openshift-storage --wait=true --timeout=5m

   如果以下命令返回了 NotFound 错误，则该项目将被删除。

   $ oc get project openshift-storage

   注意

   卸载 OpenShift Data Foundation 时，如果没有完全删除命名空间并处于 Terminating 状态，请执行 故障排除和删除 Uninstall 过程中剩余的资源 的步骤，以识别阻塞命名空间的对象。

5. 确认已删除使用 OpenShift Data Foundation 置备的所有 PV。如果有任何 PV 处于 Released 状态，请将其删除。

   $ oc get pv
   $ oc delete pv <pv name>

6. 删除 CustomResourceDefinitions。

   $ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io storagesystems.odf.openshift.io --wait=true --timeout=5m

7. 确保完全卸载 OpenShift Data Foundation：

   1. 在 OpenShift Container Platform Web 控制台中点 Storage。
   2. 验证 OpenShift Data Foundation 是否不再出现在 Storage 下。

流程

1. 列出当前在 openshift-monitoring 命名空间中运行的 pod 和 PVC。

   $ oc get pod,pvc -n openshift-monitoring
   NAME                           READY   STATUS    RESTARTS   AGE
   pod/alertmanager-main-0         3/3     Running   0          8d
   pod/alertmanager-main-1         3/3     Running   0          8d
   pod/alertmanager-main-2         3/3     Running   0          8d
   pod/cluster-monitoring-
   operator-84457656d-pkrxm        1/1     Running   0          8d
   pod/grafana-79ccf6689f-2ll28    2/2     Running   0          8d
   pod/kube-state-metrics-
   7d86fb966-rvd9w                 3/3     Running   0          8d
   pod/node-exporter-25894         2/2     Running   0          8d
   pod/node-exporter-4dsd7         2/2     Running   0          8d
   pod/node-exporter-6p4zc         2/2     Running   0          8d
   pod/node-exporter-jbjvg         2/2     Running   0          8d
   pod/node-exporter-jj4t5         2/2     Running   0          6d18h
   pod/node-exporter-k856s         2/2     Running   0          6d18h
   pod/node-exporter-rf8gn         2/2     Running   0          8d
   pod/node-exporter-rmb5m         2/2     Running   0          6d18h
   pod/node-exporter-zj7kx         2/2     Running   0          8d
   pod/openshift-state-metrics-
   59dbd4f654-4clng                3/3     Running   0          8d
   pod/prometheus-adapter-
   5df5865596-k8dzn                1/1     Running   0          7d23h
   pod/prometheus-adapter-
   5df5865596-n2gj9                1/1     Running   0          7d23h
   pod/prometheus-k8s-0            6/6     Running   1          8d
   pod/prometheus-k8s-1            6/6     Running   1          8d
   pod/prometheus-operator-
   55cfb858c9-c4zd9                1/1     Running   0          6d21h
   pod/telemeter-client-
   78fc8fc97d-2rgfp                3/3     Running   0          8d
   
   NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0   Bound    pvc-0d519c4f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1   Bound    pvc-0d5a9825-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2   Bound    pvc-0d6413dc-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0        Bound    pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1        Bound    pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   8d

2. 编辑监控 configmap。

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

   删除引用 OpenShift Data Foundation 存储类的所有 config 部分，如下例所示并保存。

   编辑前

   . . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-external-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .

   编辑后

   . . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .

   在本例中，alertmanagerMain 和 prometheusK8s 监控组件使用 OpenShift Data Foundation PVC。

3. 列出使用 PVC 的 pod。

   在本例中，消耗 PVC 的 alertmanagerMain 和 prometheusK8s pod 处于 Terminating 状态。这些 pod 不再使用 OpenShift Data Foundation PVC后，您可以删除 PVC。

   $ oc get pod,pvc -n openshift-monitoring
   NAME                                               READY   STATUS      RESTARTS AGE
   pod/alertmanager-main-0                            3/3     Terminating   0      10h
   pod/alertmanager-main-1                            3/3     Terminating   0      10h
   pod/alertmanager-main-2                            3/3     Terminating   0      10h
   pod/cluster-monitoring-operator-84cd9df668-zhjfn   1/1     Running       0      18h
   pod/grafana-5db6fd97f8-pmtbf                       2/2     Running       0      10h
   pod/kube-state-metrics-895899678-z2r9q             3/3     Running       0      10h
   pod/node-exporter-4njxv                            2/2     Running       0      18h
   pod/node-exporter-b8ckz                            2/2     Running       0      11h
   pod/node-exporter-c2vp5                            2/2     Running       0      18h
   pod/node-exporter-cq65n                            2/2     Running       0      18h
   pod/node-exporter-f5sm7                            2/2     Running       0      11h
   pod/node-exporter-f852c                            2/2     Running       0      18h
   pod/node-exporter-l9zn7                            2/2     Running       0      11h
   pod/node-exporter-ngbs8                            2/2     Running       0      18h
   pod/node-exporter-rv4v9                            2/2     Running       0      18h
   pod/openshift-state-metrics-77d5f699d8-69q5x       3/3     Running       0      10h
   pod/prometheus-adapter-765465b56-4tbxx             1/1     Running       0      10h
   pod/prometheus-adapter-765465b56-s2qg2             1/1     Running       0      10h
   pod/prometheus-k8s-0                               6/6     Terminating   1      9m47s
   pod/prometheus-k8s-1                               6/6     Terminating   1      9m47s
   pod/prometheus-operator-cbfd89f9-ldnwc             1/1     Running       0      43m
   pod/telemeter-client-7b5ddb4489-2xfpz              3/3     Running       0      10h
   
   NAME                                                      STATUS  VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-0   Bound    pvc-2eb79797-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
   persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-1   Bound    pvc-2ebeee54-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
   persistentvolumeclaim/ocs-alertmanager-claim-alertmanager-main-2   Bound    pvc-2ec6a9cf-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
   persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-0        Bound    pvc-3162a80c-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h
   persistentvolumeclaim/ocs-prometheus-claim-prometheus-k8s-1        Bound    pvc-316e99e2-1fed-11ea-93e1-0a88476a6a64   40Gi       RWO            ocs-external-storagecluster-ceph-rbd   19h

4. 删除相关的 PVC。请确定删除所有消耗存储类的 PVC。

   $ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m

流程

1. 编辑 configs.imageregistry.operator.openshift.io 对象，并删除 storage 部分中的内容。

   $ oc edit configs.imageregistry.operator.openshift.io

   编辑前

   . . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .

   编辑后

   . . . storage: emptyDir: {} . . .

   在本例中，PVC 称为 registry-cephfs-rwx-pvc，现在可以安全地删除。

2. 删除 PVC。

   $ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m

流程

1. 删除命名空间中的 ClusterLogging 实例。

   $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

   openshift-logging 命名空间中的 PVC 现在可以安全地删除。

2. 删除 PVC。

   $ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m

   <pvc-name>

   是 PVC 的名称

1. 进入 Storage → StorageClasses。
2. 点 Create Storage Class。
3. 输入存储类 Name 和 Description。
4. 为 Reclaim Policy 选择 Delete 或 Retain。默认情况下，选择 Delete。
5. 选择 Immediate 或 WaitForFirstConsumer 作为卷绑定模式。WaitForConsumer 设置为默认选项。
6. 选择 RBD Provisioner openshift-storage.rbd.csi.ceph.com，这是用于调配持久卷的插件。
7. 选择 存储池，其中卷数据将存储到列表中或创建新池。

8. 选中 Enable encryption 复选框。有两个选项可用来设置 KMS 连接详情：

   • 选择现有 KMS 连接 ：从下拉列表中选择现有 KMS 连接。该列表填充自 csi-kms-connection-details ConfigMap 中的连接详情。

   • 创建新的 KMS 连接 ：这仅适用于 vaulttoken。

     1. 默认情况下，Key Management Service Provider 设置为 Vault。
     2. 输入唯一的 Vault Service Name、Vault 服务器的主机地址 （https://<hostname 或 ip>）和端口号 。

     3. 展开 Advanced Settings ，以根据您的 Vault 配置输入其他设置和证书详情。

        1. 在 后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
        2. 可选 ：输入 TLS Server Name 和 Vault Enterprise 命名空间。
        3. 通过上传相应的 PEM 编码证书文件提供 CA 证书、客户端证书和客户端私钥。
        4. 单击 Save。
     4. 点击 Save。
9. 点击 Create。

10. 如果 HashiCorp Vault 设置不允许自动检测后端路径使用的 Key/Value(KV)secret 引擎 API 版本，请编辑 ConfigMap 以添加 VAULT_BACKEND 或 vaultBackend 参数。

    注意

    VAULT_BACKEND 或 vaultBackend 是已添加到 configmap 中的可选参数，以指定与后端路径关联的 KV secret 引擎 API 的版本。确保值与为后端路径设置的 KV secret 引擎 API 版本匹配，否则可能会导致持久性卷声明(PVC)创建过程中失败。

    1. 识别新创建的存储类使用的 encryptionKMSID。

       1. 在 OpenShift Web 控制台中，导航到 Storage → Storage Classes。
       2. 点 Storage class name → YAML 标签页。

       3. 捕获存储类使用的 encryptionKMSID。

          例如：

          encryptionKMSID: 1-vault

    2. 在 OpenShift Web 控制台中，导航到 Workloads → ConfigMaps。
    3. 要查看 KMS 连接详情，请单击点击 csi-kms-connection-details。

    4. 编辑 ConfigMap。

       1. 点击 Action 菜单 (⋮) → Edit ConfigMap。

       2. 根据为之前标识的 encryptionKMSID 配置的后端，添加 VAULT_BACKEND 或 vaultBackend 参数。

          您可以为 KV secret engine API、版本 1 和 kv-v2 分配 kv 用于 KV secret engine API（版本 2）。

          例如：

           kind: ConfigMap
           apiVersion: v1
           metadata:
             name: csi-kms-connection-details
           [...]
           data:
             1-vault: |-
               {
                 "KMS_PROVIDER": "vaulttokens",
                 "KMS_SERVICE_NAME": "1-vault",
                 [...]
                 "VAULT_BACKEND": "kv-v2"
               }
             2-vault: |-
               {
                 "encryptionKMSType": "vaulttenantsa",
                 [...]
                 "vaultBackend": "kv-v2"
               }

       3. 点 Save

流程

1. 从 OpenShift Web 控制台左侧窗格中，点击 Administration → Custom Resource Definitions。
2. 在 Custom Resource Definitions 页面中点 ClusterLogging。
3. 在 Custom Resource Definition Overview 页面上，从 Actions 菜单中选择 View Instances，或者点击 Instances 选项卡。

4. 在 Cluster Logging 页面上，点击 Create Cluster Logging。

   您可能需要刷新页面来加载数据。

5. 在 YAML 中，将 storageClassName 替换为使用 provisioner openshift-storage.rbd.csi.ceph.com 的 storageclass。在下例中，storageclass 的名称为 ocs-storagecluster-ceph-rbd ：

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: ocs-storagecluster-ceph-rbd
           size: 200G # Change as per your requirement
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         replicas: 1
     curation:
       type: "curator"
       curator:
         schedule: "30 3 * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd: {}

   如果 OpenShift Data Foundation 节点带有污点，您必须添加容限，以启用为日志调度 daemonset pod。

   spec:
   [...]
     collection:
       logs:
         fluentd:
           tolerations:
           - effect: NoSchedule
             key: node.ocs.openshift.io/storage
             value: 'true'
         type: fluentd

6. 点击 Save。

验证步骤

1. 验证持久卷声明是否已绑定到 elasticsearch Pod。

   1. 进入 Storage → Persistent Volume Claims。
   2. 将 Project 下拉菜单设置为 openshift-logging。

   3. 验证持久卷声明是否可见，状态为 Bound，附加到 elasticsearch-* pod。

      图 6.4. 创建并绑定集群日志记录

      

2. 验证是否在使用新集群日志记录。

   1. 点 Workload → Pods。
   2. 将项目设置为 openshift-logging。
   3. 验证新的 elasticsearch-* Pod 的状态是否为 Running。
   4. 点新的 elasticsearch-* Pod 查看 pod 详情。
   5. 向下滚动到 Volumes，再验证 elasticsearch 卷是否具有与新持久性卷声明匹配的 Type，如 elasticsearch-elasticsearch-cdm-9r624biv-3。
   6. 点 Persistent Volume Claim 名称，然后在 PersistentVolumeClaim Overview 页面中验证存储类名称。

1. 执行以下命令并验证输出中是否存在新节点：

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. 点 Workloads → Pods，确认新节点上的以下 pod 处于 Running 状态 ：

   • csi-cephfsplugin-*
   • csi-rbdplugin-*

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Backing Store 选项卡。
3. 单击 Create Backing Store。

4. 在 Create New Backing Store 页面中执行以下操作：

   1. 输入后端存储名称。
   2. 选择 Provider。
   3. 选择 Region。
   4. 输入 端点.这是可选的。

   5. 从下拉列表中选择一个 Secret，或者创建自己的 secret。另外，您也可以切换到 Credentials 视图来填写所需的 secret。

      有关创建 OCP secret 的更多信息，请参阅 Openshift Container Platform 文档中的 创建 secret 部分。

      每个后备存储都需要不同的机密。有关为特定后备存储创建 secret 的更多信息，请参阅 第 10.4.2 节 “使用 MCG 命令行界面为混合或多云添加存储资源” 并按照使用 YAML 添加存储资源的步骤进行操作。

      注意

      此菜单与 Google Cloud 和本地 PVC 以外的所有供应商相关。

   6. 输入 Target bucket。目标 bucket 是托管在远程云服务的容器存储。它允许您创建一个连接，告诉 MCG 它可以将此存储桶用于系统。
5. 单击 Create Backing Store。

验证步骤

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Backing Store 选项卡，以查看所有后备存储。

流程

1. 在 MCG 命令行界面中运行以下命令：

   noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>

   1. 要获取 <RGW ACCESS KEY> 和 <RGW SECRET KEY>，请使用您的 RGW 用户 secret 名称运行以下命令：

      oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage

   2. 解码 Base64 中的访问密钥 ID 和访问密钥，并保留它们。
   3. 将 <RGW USER ACCESS KEY> 和 <RGW USER SECRET ACCESS KEY> 替换为上一步中的相应已解码数据。
   4. 将 <bucket-name> 替换为现有的 RGW 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。

   5. 要获取 <RGW endpoint>，请参阅访问 RADOS 对象网关 S3 端点。

      输出结果类似如下：

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "rgw-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"

1. 创建 CephObjectStore 用户。这还会创建一个包含 RGW 凭证的 secret：

   apiVersion: ceph.rook.io/v1
   kind: CephObjectStoreUser
   metadata:
     name: <RGW-Username>
     namespace: openshift-storage
   spec:
     store: ocs-storagecluster-cephobjectstore
     displayName: "<Display-name>"

   1. 将 <RGW-Username> 和 <Display-name> 替换为唯一的用户名和显示名称。

2. 为 S3-Compatible 后备存储应用以下 YAML:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <backingstore-name>
     namespace: openshift-storage
   spec:
     s3Compatible:
       endpoint: <RGW endpoint>
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       signatureVersion: v4
       targetBucket: <RGW-bucket-name>
     type: s3-compatible

   1. 将 <backingstore-secret-name> 替换为上一步中使用 CephObjectStore 创建的 secret 的名称。
   2. 将 <bucket-name> 替换为现有的 RGW 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。
   3. 要获取 <RGW endpoint>，请参阅访问 RADOS 对象网关 S3 端点。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 在 Storage Systems 选项卡中，选择 storage 系统，然后点 Overview → Object 选项卡。
3. 选择 Multicloud Object Gateway 链接。

1. 选择左侧的资源选项卡，突出显示下方。从填充的列表中，选择 Add Cloud Resource。

   

2. 选择 Add new connection。

   

3. 选择相关的原生云供应商或 S3 兼容选项并填写详情。

   

4. 选择新创建的连接并将其映射到现有存储桶。

   
5. 重复这些步骤，根据需要创建任意数量的后备存储。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Bucket Class 选项卡。
3. 点 Create Bucket Class。

4. 在 Create new Bucket Class 页面中，执行以下操作：

   1. 选择 bucket 类类型，再输入 bucket 类名称。

      1. 选择 BucketClass 类型。选择以下选项之一：

         • Standard ：数据将由多云对象网关(MCG)使用，已取消、压缩和加密。

         • Namespace ：数据存储在 Namespace 存储中，而无需执行重复数据删除、压缩或加密。

           默认选择 Standard。

      2. 输入 Bucket Class Name。
      3. 点 Next。

   2. 在 放置策略 中，选择 Tier 1 - Policy Type 并单击 Next。您可以根据要求选择任一选项。

      • Spread 允许在选定资源之间分散数据。
      • Mirror 允许在选定资源中完全重复数据。
      • 单击 Add Tier 以添加另一个策略层。

   3. 如果您为 Spread 选择了 Tier 1 - Policy Type，从可用列表中选择至少一个 Backing Store 资源并点 Next。或者，您也可以创建新的后备存储。

      注意

      当在上一步中选择 Policy Type 作为 Mirror 时，至少需要选择 2 个后备存储。

   4. 检查并确认 Bucket 类设置。
   5. 点 Create Bucket Class。

验证步骤

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Bucket Class 选项卡，再搜索新的 Bucket 类。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Bucket Class 选项卡。
3. 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。
4. 点 Edit Bucket Class。
5. 您将被重定向到 YAML 文件，在此文件中进行必要的更改并点 Save。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 单击 Bucket Class 选项卡。

3. 点击您要编辑的 Bucket 类旁边的 Action Menu (⋮)。

   
4. 点 Edit Bucket Class Resources。

5. 在 Edit Bucket Class Resources 页面中，通过添加后备存储到存储桶类或从存储桶类中删除后备存储来编辑存储桶类资源。您还可以编辑使用一或两个分层和不同的放置策略创建的 bucket 类资源。

   • 要将后备存储添加到 bucket 类，请选择后备存储的名称。

   • 要从存储桶类中删除后备存储，请清除后备存储的名称。

     
6. 点击 Save。

流程

1. 登录 OpenShift Web 控制台。
2. 点 Storage → OpenShift Data Foundation。

3. 点 Namespace Store 选项卡创建要在命名空间存储桶中使用的 namespacestore 资源。

   1. 单击 Create namespace store。
   2. 输入命名空间存储名称。
   3. 选择一个供应商。
   4. 选择一个地区。
   5. 选择现有的 secret，或者点击 Swith to credentials 通过输入 secret key 和 secret access key 来创建 secret。
   6. 选择目标存储桶。
   7. 点击 Create。
   8. 验证命名空间存储是否处于 Ready 状态。
   9. 重复这些步骤，直到您拥有所需的资源量。

4. 点击 Bucket Class 选项卡 → Create a new Bucket Class。

   1. 选择 Namespace 单选按钮。
   2. 输入 Bucket 类名称。
   3. 添加描述（可选）。
   4. 点 Next。
5. 为您的命名空间存储桶选择一个命名空间策略类型，然后单击 Next。

6. 选择目标资源。

   • 如果您的命名空间策略类型是 Single，则需要选择一个读取资源。
   • 如果您的命名空间策略类型是 Multi，则需要选择读取资源和写入资源。
   • 如果命名空间策略类型是 Cache，则需要选择一个定义命名空间存储桶读取和写入目标的 Hub 命名空间存储。
7. 点 Next。
8. 检查您的新 bucket 类，然后点击 Create Bucketclass。
9. 在 BucketClass 页面中，验证新创建的资源是否处于 Created 阶段。
10. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
11. 在 Status 卡中，单击 Storage System，再单击弹出窗口中的 storage 系统链接。
12. 在 Object 选项卡中，点 Multicloud Object Gateway → Buckets → Namespace Buckets 选项卡。

13. 点 Create Namespace Bucket。

    1. 在 Choose Name 选项卡中，指定命名空间存储桶的名称，再单击 Next。

    2. 在 Set Placement 标签页中：

       1. 在 Read Policy 下，选中在第 5 步中创建的每个命名空间资源应从中读取数据的复选框。
       2. 如果您使用的命名空间策略类型是 Multi，在 Write Policy 下指定要将数据写入的命名空间资源。
       3. 点 Next。
    3. 点击 Create。

1. 在 Multicloud Object Gateway(MCG)命令行界面中，运行以下命令来创建带有镜像策略的存储桶类：

   $ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror

2. 将新创建的存储桶类设置为一个新的存储桶声明，生成一个新的存储桶，该存储桶将在两个位置之间进行镜像：

   $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

1. 应用以下 YAML。此 YAML 是一个混合示例，在本地 Ceph 存储和 AWS 之间镜像数据：

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: <bucket-class-name>
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - <backing-store-1>
         - <backing-store-2>
         placement: Mirror

2. 将以下行添加到标准 Object Bucket Claim (OBC) 中：

   additionalConfig:
     bucketclass: mirror-to-aws

   有关 OBCs 的更多信息，请参阅 第 10.8 节 “对象 Bucket 声明”。

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 在 Status 卡中，单击 Storage System，再单击弹出窗口中的 storage 系统链接。
3. 在 Object 选项卡中，点 Multicloud Object Gateway 链接。

4. 在 NooBaa 页面中，单击左侧的存储 桶 图标。您可以看到存储桶列表：

   
5. 点击您要更新的存储桶。

6. 点击 Edit Tier 1 Resources:

   

7. 选择 Mirror 并检查您要用于这个存储桶的相关资源。在以下示例中，在 RGW 和 AWS-backingstore 中被镜像的 noobaa-default-backing-store 间的数据会被镜像：

   
8. 点击 Save。

1. 以 JSON 格式创建 bucket 策略。请参见以下示例：

   {
       "Version": "NewVersion",
       "Statement": [
           {
               "Sid": "Example",
               "Effect": "Allow",
               "Principal": [
                       "john.doe@example.com"
               ],
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::john_bucket"
               ]
           }
       ]
   }

   bucket 策略有许多可用元素，与访问权限有关。

   有关这些元素的详细信息，以及如何使用它们控制访问权限的示例，请参阅 AWS 访问策略语言概述。

   如需存储桶策略的更多示例，请参阅 AWS Bucket 策略示例。

   有关创建 S3 用户的说明，请参阅 第 10.7.3 节 “在 Multicloud 对象网关中创建 AWS S3 用户”。

2. 使用 AWS S3 客户端，使用 put-bucket-policy 命令将存储桶策略应用到 S3 存储桶：

   # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy

   1. 将 ENDPOINT 替换为 S3 端点。
   2. 将 MyBucket 替换为 bucket，以设置策略。
   3. 将 BucketPolicy 替换为 bucket 策略 JSON 文件。

   4. 如果您使用默认的自签名证书，请添加 --no-verify-ssl。

      例如：

      # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

      如需有关 put-bucket-policy 命令的更多信息，请参阅有关 put-bucket-policy 的 AWS CLI 命令参考。

      注意

      principal 元素指定允许或拒绝访问某一资源的用户，如存储桶。目前，只有 NooBaa 帐户才能用作主体。对于对象存储桶声明，NooBaa 会自动创建一个帐户 obc-account.<generated bucket name>@noobaa.io。

      注意

      不支持 bucket 策略条件。

流程

1. 在 OpenShift Web 控制台中，点 Storage → OpenShift Data Foundation。
2. 在 Status 卡中，单击 Storage System，再单击弹出窗口中的 storage 系统链接。
3. 在 Object 选项卡中，点 Multicloud Object Gateway 链接。

4. 在 Accounts 选项卡下，单击 Create Account。

   

5. 选择 S3 Access Only，提供 帐户名称，例如 john.doe@example.com。点 Next。

   

6. 选择 S3 默认放置，例如 noobaa-default-backing-store。选择 Buckets Permissions。可以选择特定的存储桶或所有存储桶。点击 Create。

   

流程

1. 在应用程序 YAML 中添加以下行：

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <obc-name>
   spec:
     generateBucketName: <obc-bucket-name>
     storageClassName: openshift-storage.noobaa.io

   这些线是 OBC 本身。

   1. 将 <obc-name> 替换为唯一的 OBC 名称。
   2. 将 <obc-bucket-name> 替换为 OBC 的唯一存储桶名称。

2. 您可以在 YAML 文件中添加更多行来自动使用 OBC。以下示例是存储桶声明结果之间的映射，这是一个带有凭证数据和 secret 的配置映射。此特定作业从 NooBaa 声明 Object Bucket，它将创建一个存储桶和帐户。

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: testjob
   spec:
     template:
       spec:
         restartPolicy: OnFailure
         containers:
           - image: <your application image>
             name: test
             env:
               - name: BUCKET_NAME
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_NAME
               - name: BUCKET_HOST
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_HOST
               - name: BUCKET_PORT
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_PORT
               - name: AWS_ACCESS_KEY_ID
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_ACCESS_KEY_ID
               - name: AWS_SECRET_ACCESS_KEY
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_SECRET_ACCESS_KEY

   1. 将 <obc-name> 的所有实例替换为您的 OBC 名称。
   2. 将 <your application image> 替换为您的应用程序镜像。

3. 应用更新的 YAML 文件：

   # oc apply -f <yaml.file>

   将 <yaml.file> 替换为 YAML 文件的名称。

4. 要查看新配置映射，请运行以下命令：

   # oc get cm <obc-name> -o yaml

   将 obc-name 替换为您的 OBC 的名称。

   您可以在输出中预期以下环境变量：

   • BUCKET_HOST - 应用程序中使用的端点。

   • BUCKET_PORT - 可供应用使用的端口。

     • 端口与 BUCKET_HOST 相关。例如，如果 BUCKET_HOST 是 https://my.example.com，BUCKET_PORT 为 443，则对象服务的端点将是 https://my.example.com:443。
   • BUCKET_NAME - 请求或生成的存储桶名称。
   • AWS_ACCESS_KEY_ID - 作为凭据一部分的访问密钥。
   • AWS_SECRET_ACCESS_KEY - 属于凭据的 Secret 访问密钥。

流程

1. 使用命令行界面生成新 bucket 和凭据的详细信息。运行以下命令：

   # noobaa obc create <obc-name> -n openshift-storage

   将 <obc-name> 替换为唯一的 OBC 名称，如 myappobc。

   另外，您可以使用 --app-namespace 选项指定创建 OBC 配置映射和 secret 的命名空间，如 myapp-namespace。

   输出示例：

   INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

   MCG 命令行界面已创建了必要的配置，并已向 OpenShift 告知新的 OBC。

2. 运行以下命令来查看 OBC:

   # oc get obc -n openshift-storage

   输出示例：

   NAME        STORAGE-CLASS                 PHASE   AGE
   test21obc   openshift-storage.noobaa.io   Bound   38s

3. 运行以下命令查看新 OBC 的 YAML 文件：

   # oc get obc test21obc -o yaml -n openshift-storage

   输出示例：

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     generation: 2
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     resourceVersion: "40756"
     selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
     uid: 64f04cba-f662-11e9-bc3c-0295250841af
   spec:
     ObjectBucketName: obc-openshift-storage-test21obc
     bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     generateBucketName: test21obc
     storageClassName: openshift-storage.noobaa.io
   status:
     phase: Bound

4. 在 openshift-storage 命名空间内，您可以找到配置映射和 secret 来使用此 OBC。CM 和 secret 的名称与 OBC 相同。运行以下命令来查看 secret：

   # oc get -n openshift-storage secret test21obc -o yaml

   输出示例：

   Example output:
   apiVersion: v1
   data:
     AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
     AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
   kind: Secret
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40751"
     selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
     uid: 65117c1c-f662-11e9-9094-0a5305de57bb
   type: Opaque

   该机密为您提供了 S3 访问凭据。

5. 运行以下命令来查看配置映射：

   # oc get -n openshift-storage cm test21obc -o yaml

   输出示例：

   apiVersion: v1
   data:
     BUCKET_HOST: 10.0.171.35
     BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     BUCKET_PORT: "31242"
     BUCKET_REGION: ""
     BUCKET_SUBREGION: ""
   kind: ConfigMap
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40752"
     selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
     uid: 651c6501-f662-11e9-9094-0a5305de57bb

   配置映射包含应用的 S3 端点信息。

流程

1. 登录 OpenShift Web 控制台。

2. 在左侧导航栏中，点击 Storage → Object Bucket Claims → Create Object Bucket Claim。

   1. 输入对象存储桶声明的名称，并根据您的部署（内部或外部）从下拉菜单中选择适当的存储类：

      内部模式

      

      以下存储类是在部署后创建的，可供使用：

      • OCS-storagecluster-ceph-rgw 使用 Ceph 对象网关 (RGW)
      • openshift-storage.noobaa.io 使用 Multicloud 对象网关(MCG)

      外部模式

      

      以下存储类是在部署后创建的，可供使用：

      • ocs-external-storagecluster-ceph-rgw 使用 RGW

      • openshift-storage.noobaa.io 使用 MCG

        注意

        RGW OBC 存储类仅可用于全新安装的 OpenShift Data Foundation 版本 4.5。它不适用于从以前的 OpenShift 数据基础版本升级的集群。

   2. 点击 Create。

      创建 OBC 后，您会被重定向到其详情页面：

      

流程

1. 在左侧导航栏中，点击 Storage → Object Bucket Claims。

2. 单击您创建的 OBC 旁边的操作菜单 (⋮)。

   1. 从下拉菜单中选择 Attach to Deployment。

      

   2. 从 Deployment Name 列表中选择所需的部署，然后单击 Attach。

      

流程

1. 登录 OpenShift Web 控制台。

2. 在左侧导航栏中，点击 Storage → Object Buckets。

   

   或者，您还可以导航到特定 OBC 的详细信息页面，再单击 Resource 链接来查看该 OBC 的对象存储桶。

3. 选择您要查看详细信息的对象 bucket。您可以导航到 Object Bucket Details 页面。

流程

1. 在左侧导航栏中，点击 Storage → Object Bucket Claims。

2. 点击您要删除的 Object Bucket Claim(OBC ) 旁边的 Action 菜单 (⋮)。

   
   1. 选择 Delete Object Bucket Claim。
   2. 点击 Delete。

流程

1. 创建 NamespaceStore 资源。NamespaceStore 代表底层存储，用作 MCG 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令：

   noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>

   1. 将 <namespacestore> 替换为命名空间存储的名称。
   2. 将 <AWS ACCESS KEY> 和 <AWS SECRET ACCESS KEY> 替换为您为此创建的 AWS 访问密钥 ID 和 secret 访问密钥。

   3. 将 <bucket-name> 替换为现有的 AWS 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先使用凭证创建 secret：

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
        AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供并编码您自己的 AWS 访问密钥 ID 和 secret 访问密钥，并使用结果代替 <AWS ACCESS KEY ID ENCODED IN BASE64> 和 <AWS SECRET ACCESS KEY ENCODED IN BASE64>。

      使用一个唯一的名称替换 <namespacestore-secret-name>。

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        awsS3:
          secret:
            name: <namespacestore-secret-name>
            namespace: <namespace-secret>
          targetBucket: <target-bucket>
        type: aws-s3

   4. 将 <namespacestore> 替换为唯一的名称。
   5. 将 <namespacestore-secret-name> 替换为上一步中创建的 secret。
   6. 将 <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
   7. 将 <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。

2. 运行以下命令来创建存储桶类：

   noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>

   1. 将 <my-cache-bucket-class> 替换为唯一的存储桶类名称。
   2. 将 <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
   3. 将 <namespacestore> 替换为上一步中创建的命名空间存储。

3. 运行以下命令，以使用 Object Bucket Claim (OBC) 资源创建 bucket，该资源使用第 2 步中定义的 bucket 类。

   noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>

   1. 将 <my-bucket-claim> 替换为唯一名称。
   2. 将 <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

流程

1. 创建 NamespaceStore 资源。NamespaceStore 代表底层存储，用作 MCG 命名空间存储桶中数据的读取或写入目标。在 MCG 命令行界面中运行以下命令：

   noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>

   1. 将 <namespacestore> 替换为 NamespaceStore 的名称。
   2. 将 <IBM ACCESS KEY>、、<IBM SECRET ACCESS KEY>、<IBM COS ENDPOINT> 替换为 IBM 访问密钥 ID、机密访问密钥和对应于现有 IBM 存储桶位置的适当区域端点。

   3. 将 <bucket-name> 替换为现有的 IBM 存储桶名称。此参数告知 MCG 将哪一个存储桶用作其后备存储的目标存储桶，以及随后数据存储和管理。

      您还可以通过应用 YAML 来添加存储资源。首先，使用凭证创建一个 secret：

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
        IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      您必须使用 Base64 提供和编码您自己的 IBM COS 访问密钥 ID 和 secret 访问密钥，并使用结果代替 <IBM COS ACCESS KEY ID ENCODED IN BASE64> 和 <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>。

      使用一个唯一的名称替换 <namespacestore-secret-name>。

      然后应用以下 YAML:

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        s3Compatible:
          endpoint: <IBM COS ENDPOINT>
          secret:
            name: <backingstore-secret-name>
            namespace: <namespace-secret>
          signatureVersion: v2
          targetBucket: <target-bucket>
        type: ibm-cos

   4. 将 <namespacestore> 替换为唯一的名称。
   5. 将 <IBM COS ENDPOINT> 替换为适当的 IBM COS 端点。
   6. 将 <backingstore-secret-name> 替换为上一步中创建的 secret。
   7. 将 <namespace-secret> 替换为用于在上一步中创建 secret 的命名空间。
   8. 将 <target-bucket> 替换为您为命名空间存储创建的 AWS S3 存储桶。

2. 运行以下命令来创建存储桶类：

   noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>

   1. 将 <my-bucket-class> 替换为唯一的存储桶类名称。
   2. 将 <backing-store> 替换为相关的后备存储。您可以在此字段中列出一个或多个以逗号分开的后备存储。
   3. 将 <namespacestore> 替换为上一步中创建的命名空间存储。

3. 运行以下命令，以使用 Object Bucket Claim 资源创建 bucket，该资源使用第 2 步中定义的 bucket 类。

   noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>

   1. 将 <my-bucket-claim> 替换为唯一名称。
   2. 将 <custom-bucket-class> 替换为在第 2 步中创建的 bucket 类的名称。

流程

1. 登录 OpenShift Web 控制台。
2. 在 MCG 用户界面中，点击 Overview → Add Storage Resources。
3. 在窗口中，单击 Deploy Kubernetes Pool。
4. 在 Create Pool 步骤中，为将来安装的节点创建目标池。
5. 在 Configure 步骤中，配置请求的 pod 数以及每个 PV 的大小。对于每个新 pod，将创建一个 PV。
6. 在 Review 步骤中，您可以找到新池的详细信息，再选择要使用的部署方法：本地或外部部署。如果选择了本地部署，Kubernetes 节点将在集群内部署。如果选择了外部部署，您将获得 YAML 文件，供外部运行。
7. 所有节点都会分配给您在第一步中选择的池，并可在 Resources → Storage resources → Resource name 下找到。