ストレージ

1. PV を削除します。

   $ oc delete pv <pv-name>

   AWS EBS、GCE PD、Azure Disk、Cinder ボリュームなどの外部インフラストラクチャーの関連するストレージアセットは、PV の削除後も引き続き存在します。

2. 関連するストレージアセットのデータをクリーンアップします。
3. 関連するストレージアセットを削除します。または、同じストレージアセットを再利用するには、ストレージアセットの定義で新規 PV を作成します。

1. クラスターの永続ボリュームをリスト表示します。

   $ 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

2. 永続ボリュームの 1 つを選択し、その回収ポリシーを変更します。

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

3. 選択した永続ボリュームに正しいポリシーがあることを確認します。

   $ 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 を削除しても、ボリュームは自動的に削除されません。

1. ReadWriteOnce (RWO) ボリュームは複数のノードにマウントできません。ノードに障害が発生すると、システムは、すでに障害が発生しているノードに割り当てられているため、割り当てられた RWO ボリュームを新規ノードにマウントすることはできません。複数割り当てのエラーメッセージが表示される場合には、シャットダウンまたはクラッシュしたノードで Pod を強制的に削除し、動的永続ボリュームの割り当て時などの重要なワークロードでのデータ損失を回避します。
2. AWS EBS に依存する Pod の再作成デプロイメントストラテジーを使用します。
3. RAW ブロックボリュームのみが、ファイバーチャネルおよび iSCSI の ReadWriteMany (RWX) アクセスモードをサポートします。詳細は、ブロックボリュームのサポートを参照してください。
4. 基盤となる vSphere 環境が vSAN ファイルサービスをサポートしている場合、OpenShift Container Platform によってインストールされた vSphere Container Storage Interface (CSI) Driver Operator は ReadWriteMany (RWX) ボリュームのプロビジョニングをサポートします。vSAN ファイルサービスが設定されていない場合に RWX を要求すると、ボリュームの作成に失敗し、エラーがログに記録されます。詳細については、"Using Container Storage Interface" → "VMware vSphere CSI Driver Operator" を参照してください。

手順

1. OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
2. 永続ボリューム要求 (PVC) の概要で、Create Persistent Volume Claim をクリックします。

3. 表示されるページで必要なオプションを定義します。

   1. ドロップダウンメニューから以前に作成されたストレージクラスを選択します。
   2. ストレージ要求の一意の名前を入力します。
   3. アクセスモードを選択します。これにより、作成されたストレージ要求の読み取り/書き込みアクセスが決定されます。
   4. ストレージ要求のサイズを定義します。
4. Create をクリックして永続ボリューム要求 (PVC) を作成し、永続ボリュームを生成します。

手順

1. ストレージクラスを作成します。

   $ cat << EOF | oc create -f -
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <storage-class-name> 1
   parameters:
     fsType: ext4 2
     encrypted: "true"
     kmsKeyId: keyvalue 3
   provisioner: ebs.csi.aws.com
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   EOF

   1

   ストレージクラスの名前を指定します。

   2

   プロビジョニングされたボリューム上に作成されるファイルシステム。

   3

   コンテナー永続ボリュームを暗号化するときに使用するキーの完全な Amazon リソースネーム (ARN) を指定します。キーを指定しないが、暗号化された フィールドが true に設定されている場合、デフォルトの KMS キーが使用されます。AWS ドキュメントの Finding the key ID and key ARN on AWS の検索を参照してください。

2. KMS キーを指定するストレージクラスで persistent volume claim (PVC) を作成します。

   $ cat << EOF | oc create -f -
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: mypvc
   spec:
     accessModes:
       - ReadWriteOnce
     volumeMode: Filesystem
     storageClassName: <storage-class-name>
     resources:
       requests:
         storage: 1Gi
   EOF

3. PVC を使用するワークロードコンテナーを作成します。

   $ cat << EOF | oc create -f -
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
       - name: httpd
         image: quay.io/centos7/httpd-24-centos7
         ports:
           - containerPort: 80
         volumeMounts:
           - mountPath: /mnt/storage
             name: data
     volumes:
       - name: data
         persistentVolumeClaim:
           claimName: mypvc
   EOF

手順

1. OpenShift Container Platform コンソールで、Storage → Storage Classes をクリックします。
2. ストレージクラスの概要では、Create Storage Class をクリックします。

3. 表示されるページで必要なオプションを定義します。

   1. ストレージクラスを参照するための名前を入力します。
   2. オプションの説明を入力します。
   3. 回収ポリシーを選択します。

   4. ドロップダウンリストから kubernetes.io/azure-disk を選択します。

      1. ストレージアカウントのタイプを入力します。これは、Azure ストレージアカウントの SKU の層に対応します。有効なオプションは、Premium_LRS、Standard_LRS、StandardSSD_LRS、および UltraSSD_LRS です。

      2. アカウントの種類を入力します。有効なオプションは shared、dedicated および managed です。

         重要

         Red Hat は、ストレージクラスでの kind: Managed の使用のみをサポートします。

         Shared および Dedicated の場合、Azure はマネージド外のディスクを作成しますが、OpenShift Container Platform はマシンの OS (root) ディスクの管理ディスクを作成します。ただし、Azure Disk はノードで管理ディスクおよびマネージド外ディスクの両方の使用を許可しないため、Shared または Dedicated で作成されたマネージド外ディスクを OpenShift Container Platform ノードに割り当てることはできません。

   5. 必要に応じてストレージクラスの追加パラメーターを入力します。
4. Create をクリックしてストレージクラスを作成します。

手順

1. OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
2. 永続ボリューム要求 (PVC) の概要で、Create Persistent Volume Claim をクリックします。

3. 表示されるページで必要なオプションを定義します。

   1. ドロップダウンメニューから以前に作成されたストレージクラスを選択します。
   2. ストレージ要求の一意の名前を入力します。
   3. アクセスモードを選択します。これにより、作成されたストレージ要求の読み取り/書き込みアクセスが決定されます。
   4. ストレージ要求のサイズを定義します。
4. Create をクリックして永続ボリューム要求 (PVC) を作成し、永続ボリュームを生成します。

手順

1. Azure File の認証情報が含まれる Secret オブジェクトを作成します。

   $ oc create secret generic <secret-name> --from-literal=azurestorageaccountname=<storage-account> \ 1
     --from-literal=azurestorageaccountkey=<storage-account-key> 2

   1

   Azure File ストレージアカウントの名前。

   2

   Azure File ストレージアカウントキー。

2. 作成した Secret オブジェクトを参照する PersistentVolume を作成します。

   apiVersion: "v1"
   kind: "PersistentVolume"
   metadata:
     name: "pv0001" 1
   spec:
     capacity:
       storage: "5Gi" 2
     accessModes:
       - "ReadWriteOnce"
     storageClassName: azure-file-sc
     azureFile:
       secretName: <secret-name> 3
       shareName: share-1 4
       readOnly: false

   1

   永続ボリュームの名前。

   2

   この永続ボリュームのサイズ。

   3

   Azure File 共有の認証情報を含むシークレットの名前。

   4

   Azure File 共有の名前。

3. 作成した永続ボリュームにマップする PersistentVolumeClaim オブジェクトを作成します。

   apiVersion: "v1"
   kind: "PersistentVolumeClaim"
   metadata:
     name: "claim1" 1
   spec:
     accessModes:
       - "ReadWriteOnce"
     resources:
       requests:
         storage: "5Gi" 2
     storageClassName: azure-file-sc 3
     volumeName: "pv0001" 4

   1

   永続ボリューム要求 (PVC) の名前。

   2

   この永続ボリューム要求 (PVC) のサイズ。

   3

   永続ボリュームのプロビジョニングに使用されるストレージクラスの名前。PersistentVolume 定義で使用されるストレージクラスを指定します。

   4

   Azure File 共有を参照する既存の PersistentVolume オブジェクトの名前。

1. この実行可能ファイルがクラスター内のすべてのノードに存在することを確認します。
2. この実行可能ファイルをボリュームプラグインのパス (/etc/kubernetes/kubelet-plugins/volume/exec/<vendor>~<driver>/<driver>) に配置します。

手順

1. OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
2. 永続ボリューム要求 (PVC) の概要で、Create Persistent Volume Claim をクリックします。

3. 表示されるページで必要なオプションを定義します。

   1. ドロップダウンメニューから以前に作成されたストレージクラスを選択します。
   2. ストレージ要求の一意の名前を入力します。
   3. アクセスモードを選択します。これにより、作成されたストレージ要求の読み取り/書き込みアクセスが決定されます。
   4. ストレージ要求のサイズを定義します。
4. Create をクリックして永続ボリューム要求 (PVC) を作成し、永続ボリュームを生成します。

手順

1. 永続ボリューム (PV) を定義します。PersistentVolume オブジェクト定義を使用して pv.yaml ファイルを作成します。

     apiVersion: v1
     kind: PersistentVolume
     metadata:
       name: task-pv-volume 1
       labels:
         type: local
     spec:
       storageClassName: manual 2
       capacity:
         storage: 5Gi
       accessModes:
         - ReadWriteOnce 3
       persistentVolumeReclaimPolicy: Retain
       hostPath:
         path: "/mnt/data" 4

   1

   ボリュームの名前。この名前は永続ボリューム要求 (PVC) または Pod で識別されるものです。

   2

   永続ボリューム要求 (PVC) をこの永続ボリュームにバインドするために使用されます。

   3

   ボリュームはシングルノードで read-write としてマウントできます。

   4

   設定ファイルでは、ボリュームがクラスターのノードの /mnt/data にあるように指定します。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これにより、ホストシステムを破壊する可能性があります。ホストをマウントするには、/host を使用するのが安全です。

2. ファイルから PV を作成します。

   $ oc create -f pv.yaml

3. 永続ボリューム要求 (PVC) を定義します。PersistentVolumeClaim オブジェクト定義を使用して、ファイル pvc.yaml を作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: task-pvc-volume
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi
     storageClassName: manual

4. ファイルから PVC を作成します。

   $ oc create -f pvc.yaml

手順

1. openshift-local-storage プロジェクトを作成します。

   $ oc adm new-project openshift-local-storage

2. オプション: インフラストラクチャーノードでのローカルストレージの作成を許可します。

   ロギングやモニタリングなどのコンポーネントに対応するために、ローカルストレージ Operator を使用してインフラストラクチャーノードでボリュームを作成する必要がある場合があります。

   ローカルストレージ Operator にワーカーノードだけでなくインフラストラクチャーノードが含まれるように、デフォルトのノードセレクターを調整する必要があります。

   ローカルストレージ Operator がクラスター全体のデフォルトセレクターを継承しないようにするには、以下のコマンドを実行します。

   $ oc annotate namespace openshift-local-storage openshift.io/node-selector=''

3. オプション: 単一ノードデプロイメントの CPU の管理プールでローカルストレージを実行できるようにします。

   シングルノードデプロイメントで Local Storage Operator を使用し、literal プールに属する CPU の使用を許可します。この手順は、管理ワークロードパーティショニングを使用する単一ノードインストールで実行します。

   Local Storage Operator が管理 CPU プールで実行できるようにするには、次のコマンドを実行します。

   $ oc annotate namespace openshift-local-storage workload.openshift.io/allowed='management'

1. OpenShift Container Platform Web コンソールにログインします。
2. Operators → OperatorHub に移動します。
3. Local Storage をフィルターボックスに入力して、ローカルストレージ Operator を見つけます。
4. Install をクリックします。
5. Install Operator ページで、A specific namespace on the cluster を選択します。ドロップメニューから openshift-local-storage を選択します。
6. Update Channel および Approval Strategy の値を必要な値に調整します。
7. Install をクリックします。

CLI からの操作

1. CLI からローカルストレージ Operator をインストールします。

   1. ローカルストレージ Operator の Operator グループおよびサブスクリプションを定義するために、オブジェクト YAML ファイル (例: openshift-local-storage.yaml) を作成します。

      例: openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        channel: stable
        installPlanApproval: Automatic 1
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

      1

      インストール計画のユーザー認可ポリシー。

2. 以下のコマンドを実行して、ローカルストレージ Operator オブジェクトを作成します。

   $ oc apply -f openshift-local-storage.yaml

   この時点で、Operator Lifecycle Manager (OLM) はローカルストレージ Operator を認識できるようになります。Operator の ClusterServiceVersion (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

3. すべての Pod およびローカルストレージ Operator が作成されていることを確認して、ローカルストレージのインストールを検証します。

   1. 必要な Pod すべてが作成されていることを確認します。

      $ oc -n openshift-local-storage get pods

      出力例

      NAME                                      READY   STATUS    RESTARTS   AGE
      local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

   2. ClusterServiceVersion (CSV) YAML マニフェストをチェックして、ローカルストレージ Operator が openshift-local-storage プロジェクトで利用できることを確認します。

      $ oc get csvs -n openshift-local-storage

      出力例

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
      local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

手順

1. ローカルボリュームリソースを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

   注記

   同じデバイスに別のストレージクラス名を使用しないでください。これを行うと、複数の永続ボリューム (PV) が作成されます。

   例: ファイルシステム

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "openshift-local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-140-183
             - ip-10-0-158-139
             - ip-10-0-164-33
     storageClassDevices:
       - storageClassName: "local-sc" 3
         volumeMode: Filesystem 4
         fsType: xfs 5
         devicePaths: 6
           - /path/to/device 7

   1

   ローカルストレージ Operator がインストールされている namespace。

   2

   オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。

   3

   永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。

   4

   ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。

   注記

   raw ブロックボリューム (volumeMode: Block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

   5

   ローカルボリュームの初回マウント時に作成されるファイルシステム。

   6

   選択するローカルストレージデバイスの一覧を含むパスです。

   7

   この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: /dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。

   注記

   RHEL KVM を使用して IBM Z で OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

   例: ブロック

   apiVersion: "local.storage.openshift.io/v1"
   kind: "LocalVolume"
   metadata:
     name: "local-disks"
     namespace: "openshift-local-storage" 1
   spec:
     nodeSelector: 2
       nodeSelectorTerms:
       - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - ip-10-0-136-143
             - ip-10-0-140-255
             - ip-10-0-144-180
     storageClassDevices:
       - storageClassName: "localblock-sc" 3
         volumeMode: Block 4
         devicePaths: 5
           - /path/to/device 6

   1

   ローカルストレージ Operator がインストールされている namespace。

   2

   オプション: ローカルストレージボリュームが割り当てられているノードの一覧が含まれるノードセレクター。以下の例では、oc get node から取得したノードホスト名を使用します。値が定義されない場合、ローカルストレージ Operator は利用可能なすべてのノードで一致するディスクの検索を試行します。

   3

   永続ボリュームオブジェクトの作成時に使用するストレージクラスの名前。

   4

   ローカルボリュームのタイプを定義するボリュームモード (Filesystem または Block)。

   5

   選択するローカルストレージデバイスの一覧を含むパスです。

   6

   この値を、LocalVolume リソースby-idへの実際のローカルディスクのファイルパスに置き換えます (例: dev/disk/by-id/wwn)。プロビジョナーが正常にデプロイされると、これらのローカルディスク用に PV が作成されます。

   注記

   RHEL KVM を使用して IBM Z で OpenShift Container Platform を実行している場合は、VM ディスクにシリアル番号を割り当てる必要があります。そうしないと、再起動後に VM ディスクを識別できません。virsh edit <VM> コマンドを使用して、<serial>mydisk</serial> 定義を追加できます。

2. OpenShift Container Platform クラスターにローカルボリュームリソースを作成します。作成したばかりのファイルを指定します。

   $ oc create -f <local-volume>.yaml

3. プロビジョナーが作成され、対応するデーモンセットが作成されていることを確認します。

   $ oc get all -n openshift-local-storage

   出力例

   NAME                                          READY   STATUS    RESTARTS   AGE
   pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
   pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
   pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
   pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m
   
   NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m
   
   NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s
   
   NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/local-storage-operator   1/1     1            1           14m
   
   NAME                                                DESIRED   CURRENT   READY   AGE
   replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

   デーモンセットプロセスの必要な数と現在の数に注意してください。必要な数が 0 の場合、これはラベルセレクターが無効であることを示します。

4. 永続ボリュームが作成されていることを確認します。

   $ oc get pv

   出力例

   NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
   local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
   local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
   local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

手順

1. PV を定義します。PersistentVolume オブジェクト定義を使用して、example-pv-filesystem.yaml または example-pv-block.yaml などのファイルを作成します。このリソースは、ノードおよびローカルボリュームへのパスを定義する必要があります。

   注記

   同じデバイスに別のストレージクラス名を使用しないでください。同じ名前を使用すると、複数の PV が作成されます。

   example-pv-filesystem.yaml

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: example-pv-filesystem
   spec:
     capacity:
       storage: 100Gi
     volumeMode: Filesystem 1
     accessModes:
     - ReadWriteOnce
     persistentVolumeReclaimPolicy: Delete
     storageClassName: local-storage 2
     local:
       path: /dev/xvdf 3
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - example-node

   1

   PV のタイプを定義するボリュームモード (Filesystem または Block)。

   2

   PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用にしてください。

   3

   選択するローカルストレージデバイスのリスト、またはディレクトリーが含まれるパスです。Filesystem volumeMode のディレクトリーのみを指定できます。

   注記

   raw ブロックボリューム (volumeMode: block) はファイルシステムでフォーマットされません。このモードは、Pod で実行しているすべてのアプリケーションが raw ブロックデバイスを使用できる場合にのみ使用します。

   example-pv-block.yaml

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: example-pv-block
   spec:
     capacity:
       storage: 100Gi
     volumeMode: Block 1
     accessModes:
     - ReadWriteOnce
     persistentVolumeReclaimPolicy: Delete
     storageClassName: local-storage 2
     local:
       path: /dev/xvdf 3
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: kubernetes.io/hostname
             operator: In
             values:
             - example-node

   1

   PV のタイプを定義するボリュームモード (Filesystem または Block)。

   2

   PV リソースの作成時に使用するストレージクラスの名前。この PV のセットを一意に特定するストレージクラスを使用するようにしてください。

   3

   選択するローカルストレージデバイスの一覧を含むパスです。

2. OpenShift Container Platform クラスターに PV リソースを作成します。作成したばかりのファイルを指定します。

   $ oc create -f <example-pv>.yaml

3. ローカル PV が作成されていることを確認します。

   $ oc get pv

   出力例

   NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
   example-pv-filesystem   100Gi      RWO            Delete           Available                        local-storage            3m47s
   example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-storage            12h
   example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-storage            12h
   example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-storage            12h

手順

1. 対応するストレージクラスを使用して PVC を作成します。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: local-pvc-name 1
   spec:
     accessModes:
     - ReadWriteOnce
     volumeMode: Filesystem 2
     resources:
       requests:
         storage: 100Gi 3
     storageClassName: local-sc 4

   1

   PVC の名前。

   2

   PVC のタイプ。デフォルトは Filesystem です。

   3

   PVC に利用できるストレージの量。

   4

   要求で必要になるストレージクラスの名前。

2. 作成したファイルを指定して、PVC を OpenShift Container Platform クラスターに作成します。

   $ oc create -f <local-pvc>.yaml

手順

1. 定義された要求をリソースの仕様に追加します。以下の例では、Pod 内で永続ボリューム要求 (PVC) を宣言します。

   apiVersion: v1
   kind: Pod
   spec:
   # ...
     containers:
       volumeMounts:
       - name: local-disks 1
         mountPath: /data 2
     volumes:
     - name: local-disks
       persistentVolumeClaim:
         claimName: local-pvc-name 3
   # ...

   1

   マウントするボリュームの名前。

   2

   ボリュームがマウントされる Pod 内のパス。コンテナーのルート (/) や、ホストとコンテナーで同じパスにはマウントしないでください。これは、コンテナーに十分な特権が付与されている場合、ホストシステムを破壊する可能性があります (例: ホストの /dev/pts ファイル)。ホストをマウントするには、/host を使用するのが安全です。

   3

   使用する既存の永続ボリューム要求 (PVC) の名前。

2. 作成したファイルを指定して、OpenShift Container Platform クラスターにリソースを作成します。

   $ oc create -f <local-pod>.yaml

手順

1. Web コンソールからローカルデバイスの自動検出を有効にするには、以下を行います。

   1. Administrator パースペクティブで、Operators → Installed Operators に移動し、Local Volume Discovery タブをクリックします。
   2. Create Local Volume Discovery をクリックします。

   3. 利用可能なディスクをすべてのノードまたは特定のノードのどちらで検出する必要があるかに応じて、All nodes または Select nodes のいずれかを選択します。

      注記

      All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。

   4. Create をクリックします。

1. ノードで利用可能なデバイスの連続リストを表示するには、以下を実行します。

   1. OpenShift Container Platform Web コンソールにログインします。
   2. Compute → Nodes に移動します。
   3. 開くノードの名前をクリックします。Node Details ページが表示されます。

   4. Disks タブを選択して、選択したデバイスのリストを表示します。

      ローカルディスクを追加または削除しても、デバイスリストの更新が継続的に行われます。名前、ステータス、タイプ、モデル、容量、およびモードでデバイスをフィルターできます。

2. Web コンソールから検出されたデバイスのローカルボリュームを自動的にプロビジョニングするには、以下を実行します。

   1. Operators → Installed Operators に移動し、Operator のリストから Local Storage を選択します。
   2. Local Volume Set → Create Local Volume Set を選択します。
   3. ボリュームセット名とストレージクラス名を入力します。

   4. All nodes または Select nodes を選択し、適宜フィルターを適用します。

      注記

      All nodes または Select nodes を使用してフィルターするかどうかにかかわらず、ワーカーノードのみが利用可能になります。

   5. ローカルボリュームセットに適用するディスクタイプ、モード、サイズ、および制限を選択し、Create をクリックします。

      メッセージが数分後に表示され、Operator reconciled successfully という Operator の調整が正常に行われたことが示唆されます。

3. または、CLI から検出されたデバイスのローカルボリュームをプロビジョニングするには、以下を実行します。

   1. 以下の例に示されるように、オブジェクト YAML ファイルを作成し、local-volume-set.yaml などのローカルボリュームセットを定義します。

      apiVersion: local.storage.openshift.io/v1alpha1
      kind: LocalVolumeSet
      metadata:
        name: example-autodetect
      spec:
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                    - worker-0
                    - worker-1
        storageClassName: example-storageclass 1
        volumeMode: Filesystem
        fsType: ext4
        maxDeviceCount: 10
        deviceInclusionSpec:
          deviceTypes: 2
            - disk
            - part
          deviceMechanicalProperties:
            - NonRotational
          minSize: 10G
          maxSize: 100G
          models:
            - SAMSUNG
            - Crucial_CT525MX3
          vendors:
            - ATA
            - ST2000LM

      1

      検出されたデバイスからプロビジョニングされる永続ボリューム用に作成されるストレージクラスを判別します。ローカルストレージ Operator は、ストレージクラスが存在しない場合にこれを自動的に作成します。このローカルボリュームのセットを一意に識別するストレージクラスを使用するようにしてください。

      2

      ローカルボリュームセット機能を使用する場合、ローカルストレージ Operator は論理ボリューム管理 (LVM) デバイスの使用をサポートしません。

   2. ローカルボリュームセットオブジェクトを作成します。

      $ oc apply -f local-volume-set.yaml

   3. ローカル永続ボリュームがストレージクラスに基づいて動的にプロビジョニングされていることを確認します。

      $ oc get pv

      出力例

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS           REASON   AGE
      local-pv-1cec77cf   100Gi      RWO            Delete           Available           example-storageclass            88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           example-storageclass            82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           example-storageclass            48m

1. 以下の例に示されるように、Pod を定義する YAML ファイルを変更し、LocalVolume 仕様を追加します。

     apiVersion: "local.storage.openshift.io/v1"
     kind: "LocalVolume"
     metadata:
       name: "local-disks"
       namespace: "openshift-local-storage"
     spec:
       tolerations:
         - key: localstorage 1
           operator: Equal 2
           value: "localstorage" 3
       storageClassDevices:
           - storageClassName: "localblock-sc"
             volumeMode: Block 4
             devicePaths: 5
               - /dev/xvdg

   1

   ノードに追加したキーを指定します。

   2

   Equal Operator を指定して、key/value パラメーターが一致するようにします。Operator が Exists の場合、システムはキーが存在することを確認し、値を無視します。Operator が Equal の場合、キーと値が一致する必要があります。

   3

   テイントのマークが付けられたノードの値 local を指定します。

   4

   ボリュームモード (Filesystem または Block) で、ローカルボリュームのタイプを定義します。

   5

   選択するローカルストレージデバイスの一覧を含むパスです。

2. オプション: テイントのマークが付けられたノードでのみローカル永続ボリュームを作成するには、以下の例のように YAML ファイルを変更し、LocalVolume 仕様を追加します。

   spec:
     tolerations:
       - key: node-role.kubernetes.io/master
         operator: Exists

手順

1. PV のオブジェクト定義を作成します。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv0001 1
   spec:
     capacity:
       storage: 5Gi 2
     accessModes:
     - ReadWriteOnce 3
     nfs: 4
       path: /tmp 5
       server: 172.17.0.2 6
     persistentVolumeReclaimPolicy: Retain 7

   1

   ボリュームの名前。これは、各種の oc <command> pod コマンドの PV アイデンティティーです。

   2

   このボリュームに割り当てられるストレージの量。

   3

   これはボリュームへのアクセスの制御に関連するように見えますが、実際はラベルの場合と同様に、PVC を PV に一致させるために使用されます。現時点では、accessModes に基づくアクセスルールは適用されていません。

   4

   使用されているボリュームタイプ。この場合は nfs プラグインです。

   5

   NFS サーバーがエクスポートしているパス。

   6

   NFS サーバーのホスト名または IP アドレス

   7

   PV の回収ポリシー。これはボリュームのリリース時に生じることを定義します。

   注記

   各 NFS ボリュームは、クラスター内のスケジュール可能なすべてのノードによってマウント可能でなければなりません。

2. PV が作成されたことを確認します。

   $ oc get pv

   出力例

   NAME     LABELS    CAPACITY     ACCESSMODES   STATUS      CLAIM  REASON    AGE
   pv0001   <none>    5Gi          RWO           Available                    31s

3. 新規 PV にバインドされる永続ボリューム要求 (PVC) を作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: nfs-claim1
   spec:
     accessModes:
       - ReadWriteOnce 1
     resources:
       requests:
         storage: 5Gi 2
     volumeName: pv0001
     storageClassName: ""

   1

   アクセスモードはセキュリティーを実施するのではなく、PV を PVC と一致させるラベルとして機能します。

   2

   この要求は 5Gi 以上の容量を提供する PV を検索します。

4. 永続ボリューム要求 (PVC) が作成されたことを確認します。

   $ oc get pvc

   出力例

   NAME         STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   nfs-claim1   Bound    pv0001   5Gi        RWO                           2m

手順

1. 仮想マシンディスクを作成します。VMware vSphere ボリュームを静的にプロビジョニングする前に、仮想マシンディスク (VMDK) を手動で作成する必要があります。以下の方法のいずれかを使用します。

   • vmkfstools を使用して作成します。セキュアシェル (SSH) を使用して ESX にアクセスし、以下のコマンドを使用して vmdk ボリュームを作成します。

     $ vmkfstools -c <size> /vmfs/volumes/<datastore-name>/volumes/<disk-name>.vmdk

   • vmware-diskmanager を使用して作成します。

     $ shell vmware-vdiskmanager -c -t 0 -s <size> -a lsilogic <disk-name>.vmdk

2. VMDK を参照する永続ボリュームを作成します。PersistentVolume オブジェクト定義を使用して pv1.yaml ファイルを作成します。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv1 1
   spec:
     capacity:
       storage: 1Gi 2
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     vsphereVolume: 3
       volumePath: "[datastore1] volumes/myDisk"  4
       fsType: ext4  5

   1

   ボリュームの名前。この名前は永続ボリューム要求 (PVC) または Pod で識別されるものです。

   2

   このボリュームに割り当てられるストレージの量。

   3

   vSphere ボリュームの vsphereVolume で使用されるボリュームタイプ。ラベルは vSphere VMDK ボリュームを Pod にマウントするために使用されます。ボリュームの内容はアンマウントされても保持されます。このボリュームタイプは、VMFS データストアと VSAN データストアの両方がサポートされます。

   4

   使用する既存の VMDK ボリューム。vmkfstools を使用した場合、前述のようにボリューム定義で、データストア名を角かっこ [] で囲む必要があります。

   5

   マウントするファイルシステムタイプです。ext4、xfs、または他のファイルシステムなどが例になります。

   重要

   ボリュームをフォーマットしてプロビジョニングした後に fsType パラメーターの値を変更すると、データ損失や Pod にエラーが発生する可能性があります。

3. ファイルから PersistentVolume オブジェクトを作成します。

   $ oc create -f pv1.yaml

4. 直前の手順で作成した永続ボリュームにマップする永続ボリューム要求 (PVC) を作成します。PersistentVolumeClaim オブジェクト定義を使用して、ファイル pvc1.yaml を作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc1 1
   spec:
     accessModes:
       - ReadWriteOnce 2
     resources:
      requests:
        storage: "1Gi" 3
     volumeName: pv1 4

   1

   永続ボリューム要求 (PVC) を表す一意の名前。

   2

   永続ボリューム要求 (PVC) のアクセスモード。ReadWriteOnce では、ボリュームはシングルノードによって読み取り/書き込みパーミッションでマウントできます。

   3

   永続ボリューム要求 (PVC) のサイズ。

   4

   既存の永続ボリュームの名前。

5. ファイルから PersistentVolumeClaim オブジェクトを作成します。

   $ oc create -f pvc1.yaml

手順

1. Pod オブジェクト定義を作成し、これをファイルに保存します。

2. CSI インラインの一時ボリュームをファイルに埋め込みます。

   my-csi-app.yaml

   kind: Pod
   apiVersion: v1
   metadata:
     name: my-csi-app
   spec:
     containers:
       - name: my-frontend
         image: busybox
         volumeMounts:
         - mountPath: "/data"
           name: my-csi-inline-vol
         command: [ "sleep", "1000000" ]
     volumes: 1
       - name: my-csi-inline-vol
         csi:
           driver: inline.storage.kubernetes.io
           volumeAttributes:
             foo: bar

   1

   Pod で使用されるボリュームの名前。

3. 直前のステップで保存したオブジェクト定義ファイルを作成します。

   $ oc create -f my-csi-app.yaml

手順

1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedSecret CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

   注記

   現在、 kubectlとocには、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedSecret CR インスタンスの使用に必要なロールを作成することはできません。

   $ oc apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: shared-resource-my-share
     namespace: my-namespace
   rules:
     - apiGroups:
         - sharedresource.openshift.io
       resources:
         - sharedsecrets
       resourceNames:
         - my-share
       verbs:
         - use
   EOF

2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

   $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

3. Pod から SharedSecret CR インスタンスにアクセスします。

   $ oc apply -f - <<EOF
   kind: Pod
   apiVersion: v1
   metadata:
     name: my-app
     namespace: my-namespace
   spec:
     serviceAccountName: default
   
   # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
   
       volumes:
       - name: my-csi-volume
         csi:
           readOnly: true
           driver: csi.sharedresource.openshift.io
           volumeAttributes:
             sharedSecret: my-share
   
   EOF

手順

1. クラスター内の namespace 間で共有する設定マップの SharedConfigMap CR インスタンスを作成します。

   $ oc apply -f - <<EOF
   apiVersion: sharedresource.openshift.io/v1alpha1
   kind: SharedConfigMap
   metadata:
     name: my-share
   spec:
     configMapRef:
       name: <name of configmap>
       namespace: <namespace of configmap>
   EOF

手順

1. YAML コンテンツと共に oc apply を使用して、その Pod で SharedConfigMap CR インスタンスを使用するための、特定のサービスアカウント RBAC パーミッションを付与します。

   注記

   現在、 kubectlとocには、use 動詞を Pod セキュリティーを中心としたロールに制限する特別な場合のロジックがハードコーディングされています。したがって、oc create role …​ を使用して、SharedConfigMap CR インスタンスの使用に必要なロールを作成することはできません。

   $ oc apply -f - <<EOF
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: shared-resource-my-share
     namespace: my-namespace
   rules:
     - apiGroups:
         - sharedresource.openshift.io
       resources:
         - sharedconfigmaps
       resourceNames:
         - my-share
       verbs:
         - use
   EOF

2. oc コマンドを使用して、ロールに関連付けられた RoleBinding を作成します。

   oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

3. Pod から SharedConfigMap CR インスタンスにアクセスします。

   $ oc apply -f - <<EOF
   kind: Pod
   apiVersion: v1
   metadata:
     name: my-app
     namespace: my-namespace
   spec:
     serviceAccountName: default
   
   # containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume
   
       volumes:
       - name: my-csi-volume
         csi:
           readOnly: true
           driver: csi.sharedresource.openshift.io
           volumeAttributes:
             sharedConfigMap: my-share
   
   EOF

1. 以下の YAML によって記述される VolumeSnapshotClass オブジェクトを使用してファイルを作成します。

   volumesnapshotclass.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: csi-hostpath-snap
   driver: hostpath.csi.k8s.io 1
   deletionPolicy: Delete

   1

   この VolumeSnapshotClass オブジェクトのスナップショットを作成するために使用される CSI ドライバーの名前。名前は、スナップショットが作成される PVC に対応するストレージクラスの Provisioner フィールドと同じである必要があります。

   注記

   永続ストレージの設定に使用したドライバーによっては、追加のパラメーターが必要になる場合があります。既存の VolumeSnapshotClass オブジェクトを使用することもできます。

2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

   $ oc create -f volumesnapshotclass.yaml

3. VolumeSnapshot オブジェクトを作成します。

   volumesnapshot-dynamic.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: mysnap
   spec:
     volumeSnapshotClassName: csi-hostpath-snap 1
     source:
       persistentVolumeClaimName: myclaim 2

   1

   ボリュームスナップショットによる特定クラスの要求。volumeSnapshotClassName 設定がなく、デフォルトのボリュームスナップショットクラスがある場合、スナップショットはデフォルトのボリュームスナップショットクラス名で作成されます。ただし、フィールドがなく、デフォルトのボリュームスナップショットクラスが存在しない場合には、スナップショットは作成されません。

   2

   永続ボリュームにバインドされる PersistentVolumeClaim オブジェクトの名前。これは、スナップショットの作成に使用する内容を定義します。スナップショットの動的プロビジョニングに必要です。

4. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

   $ oc create -f volumesnapshot-dynamic.yaml

1. 上記のようにボリュームスナップショットクラスを定義するだけでなく、volumeSnapshotContentName パラメーターの値をスナップショットのソースとして指定します。

   volumesnapshot-manual.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: snapshot-demo
   spec:
     source:
       volumeSnapshotContentName: mycontent 1

   1

   事前にプロビジョニングされたスナップショットには、volumeSnapshotContentName パラメーターが必要です。

2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

   $ oc create -f volumesnapshot-manual.yaml

1. 作成したボリュームスナップショットの詳細を表示するには、以下のコマンドを実行します。

   $ oc describe volumesnapshot mysnap

   以下の例は、mysnap ボリュームスナップショットについての詳細を表示します。

   volumesnapshot.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshot
   metadata:
     name: mysnap
   spec:
     source:
       persistentVolumeClaimName: myclaim
     volumeSnapshotClassName: csi-hostpath-snap
   status:
     boundVolumeSnapshotContentName: snapcontent-1af4989e-a365-4286-96f8-d5dcd65d78d6 1
     creationTime: "2020-01-29T12:24:30Z" 2
     readyToUse: true 3
     restoreSize: 500Mi

   1

   コントローラーによって作成された実際のストレージコンテンツへのポインター。

   2

   スナップショットが作成された時間。スナップショットには、このタイミングで利用できるボリュームコンテンツが含まれます。

   3

   値が true に設定されている場合、スナップショットを使用して新規 PVC として復元できます。
   値が false に設定されている場合、スナップショットが作成されています。ただし、ストレージバックエンドは、スナップショットを新規ボリュームとして復元できるようにするために、追加のタスクを実行してスナップショットを使用できる状態にする必要があります。たとえば、Amazon Elastic Block Store データを別の低コストの場所に移動する場合があり、これには数分の時間がかかる可能性があります。

2. ボリュームのスナップショットが作成されたことを確認するには、以下のコマンドを実行します。

   $ oc get volumesnapshotcontent

   実際のコンテンツへのポインターが表示されます。boundVolumeSnapshotContentName フィールドにデータが設定される場合、VolumeSnapshotContent オブジェクトが存在し、スナップショットが作成されています。

3. スナップショットの準備が完了していることを確認するには、VolumeSnapshot オブジェクトに readyToUse: true があることを確認します。

手順

1. 以下の例のように、VolumeSnapshotClass オブジェクトで必要な削除ポリシーを指定します。

   volumesnapshotclass.yaml

   apiVersion: snapshot.storage.k8s.io/v1
   kind: VolumeSnapshotClass
   metadata:
     name: csi-hostpath-snap
   driver: hostpath.csi.k8s.io
   deletionPolicy: Delete 1

   1

   ボリュームスナップショットの削除時に Delete 値を設定すると、VolumeSnapshotContent オブジェクトと共に基礎となるスナップショットが削除されます。Retain 値を設定すると、基礎となるスナップショットと VolumeSnapshotContent オブジェクトの両方が残ります。
   Retain 値を設定し、対応する VolumeSnapshotContent オブジェクトを削除せずに VolumeSnapshot オブジェクトを削除すると、コンテンツは残ります。スナップショット自体はストレージバックエンドにも保持されます。

2. 以下のコマンドを入力してボリュームスナップショットを削除します。

   $ oc delete volumesnapshot <volumesnapshot_name>

   出力例

   volumesnapshot.snapshot.storage.k8s.io "mysnapshot" deleted

3. 削除ポリシーが Retain に設定されている場合は、以下のコマンドを入力してボリュームスナップショットのコンテンツを削除します。

   $ oc delete volumesnapshotcontent <volumesnapshotcontent_name>

4. オプション: VolumeSnapshot オブジェクトが正常に削除されていない場合は、以下のコマンドを実行して残されているリソースのファイナライザーを削除し、削除操作を続行できるようにします。

   重要

   永続ボリューム要求 (PVC) またはボリュームスナップショットのコンテンツのいずれかから VolumeSnapshot オブジェクトへの既存の参照がない場合にのみファイナライザーを削除します。--force オプションを使用する場合でも、すべてのファイナライザーが削除されるまで削除操作でスナップショットオブジェクトは削除されません。

   $ oc patch -n $PROJECT volumesnapshot/$NAME --type=merge -p '{"metadata": {"finalizers":null}}'

   出力例

   volumesnapshotclass.snapshot.storage.k8s.io "csi-ocs-rbd-snapclass" deleted

   ファイナライザーが削除され、ボリュームスナップショットが削除されます。

手順

1. 以下のように PVC に VolumeSnapshot データソースを指定します。

   pvc-restore.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: myclaim-restore
   spec:
     storageClassName: csi-hostpath-sc
     dataSource:
       name: mysnap 1
       kind: VolumeSnapshot 2
       apiGroup: snapshot.storage.k8s.io 3
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi

   1

   ソースとして使用するスナップショットを表す VolumeSnapshot オブジェクトの名前。

   2

   VolumeSnapshot の値に設定する必要があります。

   3

   snapshot.storage.k8s.io の値に設定する必要があります。

2. 以下のコマンドを実行して PVC を作成します。

   $ oc create -f pvc-restore.yaml

3. 以下のコマンドを実行して、復元された PVC が作成されていることを確認します。

   $ oc get pvc

   myclaim-restore などの新規 PVC が表示されます。

1. 以下の YAML によって記述される PersistentVolumeClaim オブジェクトを使用してファイルを作成し、保存します。

   pvc-clone.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-1-clone
     namespace: mynamespace
   spec:
     storageClassName: csi-cloning 1
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 5Gi
     dataSource:
       kind: PersistentVolumeClaim
       name: pvc-1

   1

   ストレージのバックエンドをプロビジョニングするストレージクラスの名前。デフォルトのストレージクラスを使用でき、storageClassName は仕様で省略できます。

2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

   $ oc create -f pvc-clone.yaml

   新規の PVC pvc-1-clone が作成されます。

3. 以下のコマンドを実行して、ボリュームクローンが作成され、準備状態にあることを確認します。

   $ oc get pvc pvc-1-clone

   pvc-1-clone は、これが Bound であることを示します。

   これで、新たにクローン作成された PVC を使用して Pod を設定する準備が整いました。

4. YAML によって記述される Pod オブジェクトと共にファイルを作成し、保存します。以下に例を示します。

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
       - name: myfrontend
         image: dockerfile/nginx
         volumeMounts:
         - mountPath: "/var/www/html"
           name: mypd
     volumes:
       - name: mypd
         persistentVolumeClaim:
           claimName: pvc-1-clone 1

   1

   CSI ボリュームのクローン作成の操作時に作成されるクローン作成された PVC。

   作成された Pod オブジェクトは、元の dataSource PVC とは別に、クローンされた PVC の使用、クローン、スナップショット、または削除を実行できるようになりました。

1. Web コンソールにログインします。

2. AWS EFS CSI Operator をインストールします。

   1. Operators → OperatorHub をクリックします。
   2. フィルターボックスにAWS EFS CSIと入力して、AWS EFS CSI Operator を探します。

   3. AWS EFS CSI Driver Operatorボタンをクリックします。

      重要

      AWS EFS OperatorではなくAWS EFS CSI Driver Operatorを必ず選択してください。AWS EFS Operatorはコミュニティー Operator であり、Red Hat ではサポートしていません。

   4. AWS EFS CSI Driver OperatorページでInstallをクリックします。

   5. Install Operatorのページで、以下のことを確認してください。

      • All namespaces on the cluster (default)が選択されている。
      • Installed Namespaceがopenshift-cluster-csi-driversに設定されている。

   6. Install をクリックします。

      インストールが終了すると、AWS EFS CSI Operator が Web コンソールのInstalled Operatorsに表示されます。

3. AWS Security Token Service (STS) と共に AWS EFS を使用している場合は、AWS EFS CSI ドライバーを STS で設定する必要があります。詳細は、AWS EFS CSI ドライバー と STS の設定を参照してください。

4. AWS EFS CSI ドライバーをインストールします。

   1. administration → CustomResourceDefinitions → ClusterCSIDriverをクリックします。
   2. InstancesタブでCreate ClusterCSIDriverをクリックします。

   3. 以下の YAML ファイルを使用します。

      apiVersion: operator.openshift.io/v1
      kind: ClusterCSIDriver
      metadata:
          name: efs.csi.aws.com
      spec:
        managementState: Managed

   4. Create をクリックします。

   5. 以下の条件が "true"に変わるのを待ちます。

      • AWSEFSDriverCredentialsRequestControllerAvailable
      • AWSEFSDriverNodeServiceControllerAvailable
      • AWSEFSDriverControllerServiceControllerAvailable

1. STS とクラスターのインストールに使用した OpenShift Container Platform リリースイメージから CCO ユーティリティー (ccoctl) バイナリーをデプロイメントします。詳細は、Cloud Credential Operator ユーティリティーの設定を参照してください。

2. 以下の例に示されているように EFS CredentialsRequest YAML ファイルを作成および保存してから、それを credrequests ディレクトリーに配置します。

   例

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: openshift-aws-efs-csi-driver
     namespace: openshift-cloud-credential-operator
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - action:
         - elasticfilesystem:*
         effect: Allow
         resource: '*'
     secretRef:
       name: aws-efs-cloud-credentials
       namespace: openshift-cluster-csi-drivers
     serviceAccountNames:
     - aws-efs-csi-driver-operator
     - aws-efs-csi-driver-controller-sa

3. ccoctl ツールを実行して AWS に新規の IAM ロールを生成し、その YAML ファイルをローカルファイルシステムに作成します (<path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml)。

   $ ccoctl aws create-iam-roles --name=<name> --region=<aws_region> --credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests --identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com

   • name=<name> は、追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
   • region=<aws_region> は、クラウドリソースが作成される AWS リージョンです。
   • dir=<path_to_directory_with_list_of_credentials_requests>/credrequests は、前のステップの EFS CredentialsRequest ファイルが含まれるディレクトリーです。

   • <aws_account_id> は AWS アカウント ID です。

     例

     $ ccoctl aws create-iam-roles --name my-aws-efs --credentials-requests-dir credrequests --identity-provider-arn arn:aws:iam::123456789012:oidc-provider/my-aws-efs-oidc.s3.us-east-2.amazonaws.com

     出力例

     2022/03/21 06:24:44 Role arn:aws:iam::123456789012:role/my-aws-efs -openshift-cluster-csi-drivers-aws-efs-cloud- created
     2022/03/21 06:24:44 Saved credentials configuration to: /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml
     2022/03/21 06:24:45 Updated Role policy for Role my-aws-efs-openshift-cluster-csi-drivers-aws-efs-cloud-

4. AWS EFS クラウド認証情報およびシークレットを作成します。

   $ oc create -f <path_to_ccoctl_output_dir>/manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml

   例

   $ oc create -f /manifests/openshift-cluster-csi-drivers-aws-efs-cloud-credentials-credentials.yaml

   出力例

   secret/aws-efs-cloud-credentials created

1. AWS のコンソールで、https://console.aws.amazon.com/efs を開きます。

2. Create file systemをクリックします。

   • ファイルシステムの名前を入力します。
   • Virtual Private Cloud(VPC)には、OpenShift Container Platform の仮想プライベートクラウド (VPC) を選択します。
   • その他の選択項目については、デフォルト設定を受け入れます。

3. ボリュームとマウントターゲットが完全に作成され終わるのを待ちます。

   1. https://console.aws.amazon.com/efs#/file-systems にアクセスしてください。
   2. ボリュームをクリックし、Networkタブで、すべてのマウントターゲットが利用可能になるまで待ちます (最長で 1 - 2 分間)。
4. Networkタブでセキュリティーグループ ID をコピーします (次のステップで必要になります)。
5. https://console.aws.amazon.com/ec2/v2/home#SecurityGroups にアクセスし、EFS ボリュームで使用されているセキュリティーグループを探します。

6. Inbound rulesタブで[Edit inbound rules] をクリックし、OpenShift Container Platform ノードが EFS ボリュームにアクセスできるようにするために、次の設定で新しいルールを追加します。

   • Type: NFS
   • Protocol: TCP
   • Port range: 2049

   • Source: ノードのカスタム/IP アドレス範囲 (例:"10.0.0.0/16")

     このステップで、OpenShift Container Platform がクラスターから NFS ポートを使用できるようになります。

7. ルールを保存します。

1. Web コンソールにログインします。
2. AWS EFS PV を使用するすべてのアプリケーションを停止します。

3. すべての AWS EFS PV を削除します。

   1. Storage → PersistentVolumeClaims をクリックします。
   2. AWS EFS CSI ドライバー Operator が使用している各 PVC を選択し、PVC の右端にあるドロップダウンメニューをクリックして、Delete PersistentVolumeClaimsをクリックします。

4. AWS EFS CSI ドライバーをアンインストールします。

   注記

   Operator をアンインストールする前に、まず CSI ドライバーを削除する必要があります。

   1. administration → CustomResourceDefinitions → ClusterCSIDriverをクリックします。
   2. Instancesタブのefs.csi.aws.comの左端にあるドロップダウンメニューをクリックし、Delete ClusterCSIDriverをクリックします。
   3. プロンプトが表示されたら、Deleteをクリックします。

5. AWS EFS CSI Operator をアンインストールします。

   1. Operators → Installed Operators をクリックします。
   2. Installed Operatorsページで、スクロールするか、Search by nameボックスに AWS EFS CSI と入力してオペレーターを見つけ、クリックします。
   3. Installed Operators > Operator detailsページの右上にあるActions → Uninstall Operatorをクリックします。

   4. Uninstall Operator ウィンドウでプロンプトが表示されたら、Uninstall ボタンをクリックして namespace から Operator を削除します。Operator によってクラスターにデプロイされたアプリケーションは手動でクリーンアップする必要があります。

      アンインストールすると、AWS EFS CSI ドライバー Operator が Web コンソールの Installed Operators セクションにリスト表示されなくなります。

1. 次のような YAML ファイルを使用して、ストレージアカウントの種類を指定するストレージクラスを作成します。

   $ oc create -f - << EOF
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <storage-class> 1
   provisioner: disk.csi.azure.com
   parameters:
     skuName: <storage-class-account-type> 2
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   EOF

   1

   ストレージクラス名。

   2

   ストレージアカウントの種類。これは、Azure ストレージアカウントの SKU レベル Standard_LRS、Premium_LRS、StandardSSD_LRS、UltraSSD_LRS、Premium_ZRS、StandardSSD_ZRS に対応しています。

2. ストレージクラスを一覧表示して、ストレージクラスが作成されたことを確認します。

   $ oc get storageclass

   出力例

   $ oc get storageclass
   NAME                    PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   azurefile-csi           file.csi.azure.com   Delete          Immediate              true                   68m
   managed-csi (default)   disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   68m
   sc-prem-zrs             disk.csi.azure.com   Delete          WaitForFirstConsumer   true                   4m25s 1

   1

   ストレージアカウントタイプを使用する新しいストレージクラス。

1. Cloud KMS キーを使用してストレージクラスを作成します。以下の例では、暗号化されたボリュームの動的プロビジョニングを有効にします。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: csi-gce-pd-cmek
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: "WaitForFirstConsumer"
   allowVolumeExpansion: true
   parameters:
     type: pd-standard
     disk-encryption-kms-key: projects/<key-project-id>/locations/<location>/keyRings/<key-ring>/cryptoKeys/<key> 1

   1

   このフィールドは、新規ディスクの暗号化に使用されるキーのリソース識別子である必要があります。値では、大文字と小文字が区別されます。キー ID の値を指定する方法についての詳細は、Retrieving a resource's ID および Getting a Cloud KMS resource ID を参照してください。

   注記

   disk-encryption-kms-key パラメーターは既存のストレージクラスに追加することはできません。ただし、ストレージクラスを削除し、同じ名前および異なるパラメーターセットでこれを再作成することができます。これを実行する場合、既存クラスのプロビジョナーは pd.csi.storage.gke.io である必要があります。

2. oc コマンドを使用して、ストレージクラスを OpenShift Container Platform クラスターにデプロイします。

   $ oc describe storageclass csi-gce-pd-cmek

   出力例

   Name:                  csi-gce-pd-cmek
   IsDefaultClass:        No
   Annotations:           None
   Provisioner:           pd.csi.storage.gke.io
   Parameters:            disk-encryption-kms-key=projects/key-project-id/locations/location/keyRings/ring-name/cryptoKeys/key-name,type=pd-standard
   AllowVolumeExpansion:  true
   MountOptions:          none
   ReclaimPolicy:         Delete
   VolumeBindingMode:     WaitForFirstConsumer
   Events:                none

3. 直前の手順で作成したストレージクラスオブジェクトの名前に一致する pvc.yaml という名前のファイルを作成します。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: csi-gce-pd-cmek
     resources:
       requests:
         storage: 6Gi

   注記

   新規ストレージクラスをデフォルトとしてマークした場合は、storageClassName フィールドを省略できます。

4. PVC をクラスターに適用します。

   $ oc apply -f pvc.yaml

5. PVC のステータスを取得し、これが作成され、新規にプロビジョニングされた PV にバインドされていることを確認します。

   $ oc get pvc

   出力例

   NAME      STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     AGE
   podpvc    Bound     pvc-e36abf50-84f3-11e8-8538-42010a800002   10Gi       RWO            csi-gce-pd-cmek  9s

   注記

   ストレージクラスで volumeBindingMode フィールドが WaitForFirstConsumer に設定されている場合、これを検証する前に PVC を使用するために Pod を作成する必要があります。

1. ストレージクラスをリスト表示します。

   $ oc get storageclass

   出力例

   NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   standard(default)      cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h
   standard-csi           kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h

2. 以下の例に示されるように、デフォルトストレージクラスについてアノテーション storageclass.kubernetes.io/is-default-class の値を false に変更します。

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

3. アノテーションを追加するか、アノテーションを storageclass.kubernetes.io/is-default-class=true として変更することで、別のストレージクラスをデフォルトにします。

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

4. デフォルトで PVC が CSI ストレージクラスを参照していることを確認します。

   $ oc get storageclass

   出力例

   NAME                   PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   standard               kubernetes.io/cinder       Delete          WaitForFirstConsumer   true                   46h
   standard-csi(default)  cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   46h

5. オプション: ストレージクラスを指定することなく新規 PVC を定義できます。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: cinder-claim
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 1Gi

   特定のストレージクラスを指定しない PVC は、デフォルトのストレージクラスを使用して自動的にプロビジョニングされます。

6. オプション: 新規ファイルを設定した後に、クラスター内にこのファイルを作成します。

   $ oc create -f cinder-claim.yaml

1. OpenShift Container Platform コンソールで、Storage → Persistent Volume Claims をクリックします。
2. 永続ボリューム要求 (PVC) の概要で、Create Persistent Volume Claim をクリックします。

3. 結果のページで必要なオプションを定義します。

   1. 適切なストレージクラスを選択します。
   2. ストレージ要求の一意の名前を入力します。

   3. アクセスモードを選択し、作成する PVC の読み取りおよび書き込みアクセスを指定します。

      重要

      この PVC を満たす永続ボリューム (PV) をクラスター内の複数ノードの複数 Pod にマウントする必要がある場合には、RWX を使用します。

4. ストレージ要求のサイズを定義します。
5. Create をクリックして永続ボリューム要求 (PVC) を作成し、永続ボリュームを生成します。

1. 以下の YAML によって記述される PersistentVolumeClaim オブジェクトを使用してファイルを作成し、保存します。

   pvc-manila.yaml

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-manila
   spec:
     accessModes: 1
       - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     storageClassName: csi-manila-gold 2

   1

   この PVC を満たす永続ボリューム (PV) をクラスター内の複数ノードの複数 Pod にマウントする必要がある場合には、RWX を使用します。

   2

   ストレージのバックエンドをプロビジョニングするストレージクラスの名前。Manila ストレージクラスは Operator によってプロビジョニングされ、これには csi-manila- 接頭辞があります。

2. 以下のコマンドを実行して、直前の手順で保存されたオブジェクトを作成します。

   $ oc create -f pvc-manila.yaml

   新規 PVC が作成されます。

3. ボリュームが作成され、準備状態にあることを確認するには、以下のコマンドを実行します。

   $ oc get pvc pvc-manila

   pvc-manila は、これが Bound であることを示します。

手順

1. サードパーティーの vSphere CSI Driver(VMware vSphere Container Storage プラグイン) の Deployment および Daemonset オブジェクトを削除します。
2. サードパーティーの vSphere CSI Driver で以前にインストールされた configmap およびシークレットオブジェクトを削除します。

3. サードパーティーの vSphere CSI ドライバー CSIDriver オブジェクトを削除します。

   ~ $ oc delete CSIDriver csi.vsphere.vmware.com

   csidriver.storage.k8s.io "csi.vsphere.vmware.com" deleted