ストレージ

手順

1. 既存の Azure MachineSet カスタムリソース (CR) をコピーし、次のコマンドを実行して編集します。

   $ oc edit machineset <machine-set-name>

   ここで、<machine-set-name> は、Ultra ディスクとともにマシンをプロビジョニングするマシンセットです。

2. 示された位置に次の行を追加します。

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   spec:
     template:
       spec:
         metadata:
           labels:
             disk: ultrassd 1
         providerSpec:
           value:
             ultraSSDCapability: Enabled 2

   1

   このマシンセットによって作成されるノードを選択するために使用するラベルを指定します。この手順では、この値に disk.ultrassd を使用します。

   2

   これらの行により、Ultra ディスクの使用が可能になります。

3. 次のコマンドを実行して、更新された設定を使用してマシンセットを作成します。

   $ oc create -f <machine-set-name>.yaml

4. 以下の YAML 定義が含まれるストレージクラスを作成します。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ultra-disk-sc 1
   parameters:
     cachingMode: None
     diskIopsReadWrite: "2000" 2
     diskMbpsReadWrite: "320" 3
     kind: managed
     skuname: UltraSSD_LRS
   provisioner: disk.csi.azure.com 4
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer 5

   1

   ストレージクラスの名前を指定します。この手順では、この値に ultra-disk-sc を使用しています。

   2

   ストレージクラスの IOPS の数値を指定します。

   3

   ストレージクラスのスループットを MBps 単位で指定します。

   4

   Azure Kubernetes Service (AKS) バージョン 1.21 以降の場合は、disk.csi.azure.com を使用します。以前のバージョンの AKS の場合は、kubernetes.io/azure-disk を使用します。

   5

   オプション: ディスクを使用する Pod の作成を待機するには、このパラメーターを指定します。

5. 以下の YAML 定義が含まれる、ultra-disk-sc ストレージクラスを参照する永続ボリューム要求 (PVC) を作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: ultra-disk 1
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: ultra-disk-sc 2
     resources:
       requests:
         storage: 4Gi 3

   1

   PVC の名前を指定します。この手順では、この値に ultra-disk を使用しています。

   2

   この PVC は ultra-disk-sc ストレージクラスを参照します。

   3

   ストレージクラスのサイズを指定します。最小値は 4Gi です。

6. 以下の YAML 定義が含まれる Pod を作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-ultra
   spec:
     nodeSelector:
       disk: ultrassd 1
     containers:
     - name: nginx-ultra
       image: alpine:latest
       command:
         - "sleep"
         - "infinity"
       volumeMounts:
       - mountPath: "/mnt/azure"
         name: volume
     volumes:
       - name: volume
         persistentVolumeClaim:
           claimName: ultra-disk 2

   1

   Ultra ディスクの使用を有効にするマシンセットのラベルを指定します。この手順では、この値に disk.ultrassd を使用します。

   2

   この Pod は ultra-disk PVC を参照します。

検証

1. 次のコマンドを実行して、マシンが作成されていることを確認します。

   $ oc get machines

   マシンは Running 状態になっているはずです。

2. 実行中でノードが接続されているマシンの場合、次のコマンドを実行してパーティションを検証します。

   $ oc debug node/<node-name> -- chroot /host lsblk

   このコマンドでは、oc debug node/<node-name> がノード <node-name> でデバッグシェルを開始し、-- を付けてコマンドを渡します。渡されたコマンド chroot /host は、基盤となるホスト OS バイナリーへのアクセスを提供し、lsblk は、ホスト OS マシンに接続されているブロックデバイスを表示します。

手順

1. オブジェクト定義をファイルに保存します。

   cinder-persistentvolume.yaml

   apiVersion: "v1"
   kind: "PersistentVolume"
   metadata:
     name: "pv0001" 1
   spec:
     capacity:
       storage: "5Gi" 2
     accessModes:
       - "ReadWriteOnce"
     cinder: 3
       fsType: "ext3" 4
       volumeID: "f37a03aa-6212-4c62-a805-9ce139fab180" 5

   1

   永続ボリューム要求または Pod によって使用されるボリュームの名前。

   2

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

   3

   Red Hat OpenStack Platform (RHOSP) Cinder ボリュームの cinder を示します。

   4

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

   5

   使用する Cinder ボリューム

   重要

   ボリュームをフォーマットしてプロビジョニングした後には、fstype パラメーターの値は変更しないでください。この値を変更すると、データの損失や、Pod の障害につながる可能性があります。

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

   $ oc create -f cinder-persistentvolume.yaml

手順

1. サービスアカウントを作成して、そのアカウントを SCC に追加します。

   $ oc create serviceaccount <service_account>

   $ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>

2. アプリケーションのデプロイ設定で、サービスアカウント名と securityContext を指定します。

   apiVersion: v1
   kind: ReplicationController
   metadata:
     name: frontend-1
   spec:
     replicas: 1  1
     selector:    2
       name: frontend
     template:    3
       metadata:
         labels:  4
           name: frontend 5
       spec:
         containers:
         - image: openshift/hello-openshift
           name: helloworld
           ports:
           - containerPort: 8080
             protocol: TCP
         restartPolicy: Always
         serviceAccountName: <service_account> 6
         securityContext:
           fsGroup: 7777 7

   1

   実行する Pod のコピー数です。

   2

   実行する Pod のラベルセレクターです。

   3

   コントローラーが作成する Pod のテンプレート。

   4

   Pod のラベル。ラベルセレクターからのラベルを組み込む必要があります。

   5

   パラメーター拡張後の名前の最大長さは 63 文字です。

   6

   作成したサービスアカウントを指定します。

   7

   Pod の fsGroup を指定します。

手順

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

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

   1. thin ストレージクラスを選択します。
   2. ストレージ要求の一意の名前を入力します。
   3. アクセスモードを選択し、作成されるストレージ要求の読み取り/書き込みアクセスを決定します。
   4. ストレージ要求のサイズを定義します。
4. Create をクリックして永続ボリューム要求を作成し、永続ボリュームを生成します。

手順 (CLI)

1. 以下の内容でファイル pvc.yaml を作成して VMware vSphere PersistentVolumeClaim を定義できます。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: pvc 1
   spec:
     accessModes:
     - ReadWriteOnce 2
     resources:
       requests:
         storage: 1Gi 3

   1

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

   2

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

   3

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

2. 次のコマンドを入力して、ファイルから PersistentVolumeClaim オブジェクトを作成します。

   $ 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
         forceWipeDevicesAndDestroyAllData: false 4
         volumeMode: Filesystem 5
         fsType: xfs 6
         devicePaths: 7
           - /path/to/device 8

   1

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

   2

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

   3

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

   4

   この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator (LSO) プロビジョニングに使用できるようにする、winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。ノードを複数回再デプロイできるシングルノード OpenShift (SNO) クラスター環境や、オブジェクトストレージデバイス (OSD) として使用する予定のディスクに以前のデータを残すことができる OpenShift Data Foundation (ODF) を使用する場合も、これに該当します。

   5

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

   注記

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

   6

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

   7

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

   8

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

   注記

   RHEL KVM を使用して 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: "local-sc" 3
         forceWipeDevicesAndDestroyAllData: false 4
         volumeMode: Block 5
         devicePaths: 6
           - /path/to/device 7

   1

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

   2

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

   3

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

   4

   この設定は、パーティションテーブルの署名 (マジックストリング) を削除してディスクを Local Storage Operator (LSO) プロビジョニングに使用できるようにする、winefs を呼び出すかどうかを定義します。署名以外のデータは消去されません。デフォルトは "false" です (wipefs は呼び出されません)。再利用する必要がある以前のデータをディスク上に残す場合、forceWipeDevicesAndDestroyAllData を "true" に設定すると便利です。このようなシナリオでは、このフィールドを true に設定すると、管理者はディスクを手動で消去する必要がありません。ノードを複数回再デプロイできるシングルノード OpenShift (SNO) クラスター環境や、オブジェクトストレージデバイス (OSD) として使用する予定のディスクに以前のデータを残すことができる OpenShift Data Foundation (ODF) を使用する場合も、これに該当します。

   5

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

   6

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

   7

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

   注記

   RHEL KVM を使用して 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-sc 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-sc 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-sc            3m47s
   example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-sc            12h
   example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-sc            12h
   example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-sc            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 内で永続ボリューム要求を宣言します。

   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

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

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

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

手順

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

   1. Operators → Installed Operators をクリックします。
   2. openshift-local-storage namespace で Local Storage をクリックします。
   3. Local Volume Discovery タブをクリックします。
   4. Create Local Volume Discovery をクリックし、Form view または YAML view のいずれかを選択します。
   5. LocalVolumeDiscovery オブジェクトパラメーターを設定します。

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

      Local Storage Operator は、auto-discover-devices という名前のローカルボリューム検出インスタンスを作成します。

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

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

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

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

3. 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 の調整が正常に行われたことが示唆されます。

4. または、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: local-sc 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           local-sc                88m
      local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
      local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                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: "local-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. PersistentVolume オブジェクト定義を含む pv.yaml ファイルを作成して、永続ボリューム (PV) を定義します。

   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

   ボリュームの名前。この名前は、永続ボリューム (PV) 要求または Pod がボリュームが識別するために使用されます。

   2

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

   3

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

   4

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

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

   $ oc create -f pv.yaml

3. PersistentVolumeClaim オブジェクト定義を含む pvc.yaml ファイルを作成して PVC を定義します。

   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 CLI (oc) にログインします。

2. PersistentVolumeClaim オブジェクトを作成します。

   PersistentVolumeClaim オブジェクトの例

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: lvm-block-1 1
     namespace: default
   spec:
     accessModes:
       - ReadWriteOnce
     volumeMode: Block 2
     resources:
       requests:
         storage: 10Gi 3
       limits:
         storage: 20Gi 4
     storageClassName: lvms-vg1 5

   1

   PVC の名前を指定します。

   2

   ブロック PVC を作成するには、このフィールドを Block に設定します。ファイル PVC を作成するには、このフィールドを Filesystem に設定します。

   3

   ストレージサイズを指定します。値が最小ストレージサイズより小さい場合、要求されるストレージサイズは最小ストレージサイズに切り上げられます。プロビジョニングできる合計ストレージサイズは、Logical Volume Manager (LVM) シンプールのサイズとオーバープロビジョニング係数によって制限されます。

   4

   オプション: ストレージ制限を指定します。このフィールドには、最小ストレージサイズ以上の値を設定します。それ以外の場合、PVC の作成はエラーが発生して失敗します。

   5

   storageClassName フィールドの値は lvms-<device_class_name> の形式である必要があります。ここで、<device_class_name> は、LVMCluster CR の deviceClasses.name フィールドの値になります。たとえば、deviceClasses.name フィールドが vg1 に設定されている場合、storageClassName フィールドを lvms-vg1 に設定する必要があります。

   注記

   ストレージクラスの volumeBindingMode フィールドは WaitForFirstConsumer に設定されます。

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

   # oc create -f <file_name> -n <application_namespace>

   注記

   作成された PVC は、それらを使用する Pod をデプロイするまで Pending 状態のままになります。

手順

1. OpenShift CLI (oc) にログインします。

2. 次のコマンドを実行して、spec.resources.requests.storage フィールドの値を現在の値より大きい値に更新します。

   $ oc patch <pvc_name> -n <application_namespace> -p \ 1
   '{ "spec": { "resources": { "requests": { "storage": "<desired_size>" }}}} --type=merge' 2

   1

   <pvc_name> を、拡張する PVC の名前に置き換えます。

   2

   <desired_size> を、新しいサイズに置き換えて PVC を拡張します。

手順

1. OpenShift CLI (oc) にログインします。

2. 次のコマンドを実行して、PVC を削除します。

   $ oc delete pvc <pvc_name> -n <namespace>

手順

1. OpenShift CLI (oc) にログインします。

2. 次のコマンドを実行して、LVM Storage のインストール時に作成した Subscription カスタムリソース (CR) を更新します。

   $ oc patch subscription lvms-operator -n openshift-storage --type merge --patch '{"spec":{"channel":"<update_channel>"}}' 1

   1

   <update_channel> を、インストールする LVM Storage のバージョンに置き換えます。たとえば、stable-4.16 などです。

3. 次のコマンドを実行して、更新イベントを表示し、インストールが完了していることを確認します。

   $ oc get events -n openshift-storage

   出力例

   ...
   8m13s       Normal    RequirementsUnknown   clusterserviceversion/lvms-operator.v4.16   requirements not yet checked
   8m11s       Normal    RequirementsNotMet    clusterserviceversion/lvms-operator.v4.16   one or more requirements couldn't be found
   7m50s       Normal    AllRequirementsMet    clusterserviceversion/lvms-operator.v4.16   all requirements found, attempting install
   7m50s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.16   waiting for install components to report healthy
   7m49s       Normal    InstallWaiting        clusterserviceversion/lvms-operator.v4.16   installing: waiting for deployment lvms-operator to become ready: deployment "lvms-operator" waiting for 1 outdated replica(s) to be terminated
   7m39s       Normal    InstallSucceeded      clusterserviceversion/lvms-operator.v4.16   install strategy completed with no errors
   ...

手順

1. 次のコマンドを実行して、LVM Storage Operator の currentCSV の値を取得します。

   $ oc get subscription.operators.coreos.com lvms-operator -n <namespace> -o yaml | grep currentCSV

   出力例

   currentCSV: lvms-operator.v4.15.3

2. 次のコマンドを実行して、サブスクリプションを削除します。

   $ oc delete subscription.operators.coreos.com lvms-operator -n <namespace>

   出力例

   subscription.operators.coreos.com "lvms-operator" deleted

3. 次のコマンドを実行して、ターゲット namespace 内の LVM Storage Operator の CSV を削除します。

   $ oc delete clusterserviceversion <currentCSV> -n <namespace> 1

   1

   <currentCSV> は、LVM Storage Operator の currentCSV 値に置き換えます。

   出力例

   clusterserviceversion.operators.coreos.com "lvms-operator.v4.15.3" deleted

手順

1. OpenShift Container Platform Web コンソールにログインします。
2. Operators → Installed Operators をクリックします。
3. openshift-storage namespace で LVM Storage をクリックします。
4. Details タブをクリックします。
5. Actions メニューから、Uninstall Operator を選択します。
6. オプション: プロンプトが表示されたら、Delete all operand instances for this operator チェックボックスを選択して、LVM Storage のオペランドインスタンスを削除します。
7. Uninstall をクリックします。

手順

1. OpenShift CLI (oc) にログインします。

2. 次のコマンドを使用して、LVM Storage のインストールと設定用に作成した RHACM Policy CR を削除します。

   $ oc delete -f <policy> -n <namespace> 1

   1

   <policy> は、Policy CR YAML ファイルの名前に置き換えます。

3. LVM Storage をアンインストールするための設定を含む Policy CR YAML ファイルを作成します。

   LVM Storage をアンインストールするための Policy CR の例

   apiVersion: apps.open-cluster-management.io/v1
   kind: PlacementRule
   metadata:
     name: placement-uninstall-lvms
   spec:
     clusterConditions:
     - status: "True"
       type: ManagedClusterConditionAvailable
     clusterSelector:
       matchExpressions:
       - key: mykey
         operator: In
         values:
         - myvalue
   ---
   apiVersion: policy.open-cluster-management.io/v1
   kind: PlacementBinding
   metadata:
     name: binding-uninstall-lvms
   placementRef:
     apiGroup: apps.open-cluster-management.io
     kind: PlacementRule
     name: placement-uninstall-lvms
   subjects:
   - apiGroup: policy.open-cluster-management.io
     kind: Policy
     name: uninstall-lvms
   ---
   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     annotations:
       policy.open-cluster-management.io/categories: CM Configuration Management
       policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
       policy.open-cluster-management.io/standards: NIST SP 800-53
     name: uninstall-lvms
   spec:
     disabled: false
     policy-templates:
     - objectDefinition:
         apiVersion: policy.open-cluster-management.io/v1
         kind: ConfigurationPolicy
         metadata:
           name: uninstall-lvms
         spec:
           object-templates:
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: v1
               kind: Namespace
               metadata:
                 name: openshift-storage
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: operators.coreos.com/v1
               kind: OperatorGroup
               metadata:
                 name: openshift-storage-operatorgroup
                 namespace: openshift-storage
               spec:
                 targetNamespaces:
                 - openshift-storage
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: operators.coreos.com/v1alpha1
               kind: Subscription
               metadata:
                 name: lvms-operator
                 namespace: openshift-storage
           remediationAction: enforce
           severity: low
     - objectDefinition:
         apiVersion: policy.open-cluster-management.io/v1
         kind: ConfigurationPolicy
         metadata:
           name: policy-remove-lvms-crds
         spec:
           object-templates:
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: apiextensions.k8s.io/v1
               kind: CustomResourceDefinition
               metadata:
                 name: logicalvolumes.topolvm.io
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: apiextensions.k8s.io/v1
               kind: CustomResourceDefinition
               metadata:
                 name: lvmclusters.lvm.topolvm.io
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: apiextensions.k8s.io/v1
               kind: CustomResourceDefinition
               metadata:
                 name: lvmvolumegroupnodestatuses.lvm.topolvm.io
           - complianceType: mustnothave
             objectDefinition:
               apiVersion: apiextensions.k8s.io/v1
               kind: CustomResourceDefinition
               metadata:
                 name: lvmvolumegroups.lvm.topolvm.io
           remediationAction: enforce
           severity: high

4. 次のコマンドを実行して Policy CR を作成します。

   $ oc create -f <policy> -ns <namespace>