独自のストレージクラスを使用したボリュームデータの暗号化

暗号化ボリュームを使用するアプリをデプロイするには、まず独自のストレージクラスを作成します。

以下の手順は、カスタムの暗号化ストレージ・クラスを作成する方法について説明しています。このストレージ・クラスを使用すれば、同じ構成の暗号化ブロック・ストレージ・インスタンスを複数作成できます。 IBM 提供のいずれかのストレージ・クラスを使用して暗号化 PVC を作成したい場合は、PVC で Key Protect の資格情報を直接参照する方法を使用してください。

1. ストレージ構成を決定します。

2. IBMのストレージ・クラスのいずれかをベースとして使用して、暗号化ブロック・ストレージ・インスタンスをプロビジョニングする独自のストレージ・クラスを作成します。 oc get sc <storageclass_name> -o yamlを実行して、ストレージ・クラスの詳細を取得できます。 次の例では、ibmc-block-retain-bronze ストレージ・クラスを基礎にしています。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <name> # Enter the name of the storage class. Example: my_custom_storageclass
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
     encrypted: "true" # Enter "true" to enable encryption.
     encryptionKeySecret: <secret_name> # # #nter the name of the secret that you created earlier.Example: my_secret
     encryptionKeyNamespace: <namespace> # # #nter the namespace where you created your secret. Example: default
   provisioner: ibm.io/ibmc-block
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   

3. クラスター内にストレージ・クラスを作成します。

   oc apply -f storageclass.yaml
   

4. 独自のストレージ・クラスを使ってPVCを作成し、Block Storage for Classicをアプリに追加 します。

5. Block Storage for Classic ボリュームの暗号化を確認します。

Block Storage for Classic シークレットを参照する PVC の作成

Block Storage for Classic の資格情報を含む Kubernetes シークレットを指定した PVC を作成して、暗号化 Key Protect をプロビジョンすることができます。

以下の手順は、Key Protect の資格情報を PVC で参照して、暗号化 Block Storage for Classic インスタンスを作成する方法を示しています。 Key Protect の資格情報を PVC ごとに指定することなく複数の暗号化ボリュームを作成するためには、カスタムの暗号化ストレージ・クラスを作成してください。

1. 提供されている Block Storage for Classic ストレージ・クラスを参照し、どのストレージ・クラスがアプリの要件に最も適しているか判断します。 提供されているストレージ・クラスがアプリの要件を満たしていない場合は、独自のカスタマイズ・ストレージ・クラスを作成できます。

2. Key Protect のサービス資格情報を保管した Kubernetes シークレットを参照する pvc.yaml という名前の PVC 構成ファイルを作成します。 このシークレットを作成するには、Block Storage for Classic の暗号化のセットアップを参照してください。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name> # Enter a name for your PVC.
     annotations:
     volume.beta.kubernetes.io/storage-class: "<storage_class>" # Enter a storage class. To see a list of storageclasses run `kubectl get storageclasses`.
     labels:
       encrypted: "true"
       encryptionKeyNamespace: <namespace> # Enter the namespace where your secret was created.
       encryptionKeySecret: <secret_name> # Enter the name of the secret you created.
   spec:
     accessModes:
       - ReadWriteOnce
       resources:
       requests:
           storage: 20Gi
   

3. クラスター内に PVC を作成します。

   oc apply -f pvc.yaml
   

4. PVC の状況を確認します。

   oc get pvc
   

5. PVC がバインドされるまで待ってから、PVC を使用するデプロイメントを作成します。

6. Block Storage for Classic ボリュームの暗号化を確認します。

Block Storage for Classic ボリュームの暗号化の確認

ボリュームの暗号化を確認するには、ボリューム・マウント・パスを確認します。

1. アプリ・ポッドにログインします。 <pod_name>を、暗号化された Block Storage for Classic ボリュームをマウントするポッドの名前に置き換えます。

   oc exec <pod_name> -it bash
   

2. ポッドのファイル・システムをリストします。

   df -h
   

3. 暗号化 Block Storage for Classic ボリュームのファイル・システムのパスを確認します。

   • 暗号化ボリュームのパス構造は/dev/mapper/<pvc-ID_encrypted>です。 この例では、暗号化ボリュームが、ポッド内の /test ファイル・パスにマウントされています。

     Filesystem                                            Size  Used Avail Use% Mounted on
     overlay                                                98G  8.2G   85G   9% /
     tmpfs                                                  64M     0   64M   0% /dev
     tmpfs                                                 2.0G     0  2.0G   0% /sys/fs/cgroup
     /dev/mapper/pvc-a011a111-1111-1111-111a-aaa1a1111a11_encrypted   20G   45M   20G   1% /test
     

   • 暗号化されていないボリュームのパス構造は dev/mapper/<random_string>です。

     Filesystem                                     Size  Used Avail Use% Mounted on
     overlay                                         98G   16G   78G  17% /
     tmpfs                                           64M     0   64M   0% /dev
     tmpfs                                          7.9G     0  7.9G   0% /sys/fs/cgroup
     /dev/mapper/3600a09803830476e733f4e477370716e   24G   45M   24G   1% /test
     

Kubernetes シークレットを削除しても、ボリューム・データへのアクセス権限は取り消されません。 ポッドのみのデプロイメントを作成した場合は、ポッドを削除する必要があります。 デプロイメントを作成した場合は、デプロイメントを削除する必要があります。

既存のブロック・ストレージの情報の取得

1. IBM Cloud インフラストラクチャー・アカウントの API キーを取得または生成します。

   1. IBM Cloudインフラストラクチャ・ポータルにログインします。
   2. 「アカウント」、「ユーザー」、**「ユーザー・リスト」**の順に選択します。
   3. 自分のユーザー ID を見つけます。
   4. **「API キー」列で、「生成」をクリックして API キーを生成するか、または「表示」**をクリックして既存の API キーを表示します。

2. IBM Cloud インフラストラクチャー・アカウントの API ユーザー名を取得します。

   1. **「ユーザー・リスト」**メニューで、自分のユーザー ID を選択します。
   2. **「API アクセス情報」セクションで、自分の「API ユーザー名」**を見つけます。

3. IBM Cloud インフラストラクチャー CLI プラグインにログインします。

   ibmcloud sl init
   

4. IBM Cloud インフラストラクチャー・アカウントのユーザー名と API キーを使用して認証を行うことを選択します。

5. 前の手順で取得したユーザー名と API キーを入力します。

6. 使用可能なブロック・ストレージ・デバイスをリストします。

   ibmcloud sl block volume-list
   

   出力例

   id          username              datacenter   storage_type                capacity_gb   bytes_used   lunId   
   11111111    IBM01AAA1111111-1     wdc07        endurance_block_storage     45            -            2      
   

7. ボリュームの詳細を取得します。 <volume_ID>を、ステップ 6 で取得した Block storage ボリュームの ID に置き換えます。

   ibmcloud sl block volume-detail <volume_ID>
   

   出力例

   ID                         11111111
   User name                  IBM01AAA1111111-1   
   Type                       endurance_block_storage   
   Capacity (GB)              45   
   LUN Id                     2   
   IOPs                       100   
   Datacenter                 wdc07   
   Target IP                  10.XXX.XX.XXX  
   # of Active Transactions   0   
   Replicant Count            0
   

8. クラスターにマウントするボリュームのID、Capacity、LUN Id、Datacenter、およびTarget IPを控えておいてください。 注: 既存のストレージをクラスターにマウントするには、そのストレージと同じゾーンにワーカー・ノードが存在する必要があります。 ワーカー・ノードのゾーンを確認するには、ibmcloud oc worker ls --cluster <cluster_name_or_ID>を実行します。

永続ボリューム (PV) および対応する永続ボリューム要求 (PVC) の作成

1. オプション: retainストレージ・クラスを使用してプロビジョンしたストレージがある場合、PVC を削除しても、PV と物理ストレージ・デバイスは削除されません。 そのストレージをクラスターで再使用するには、まず PV を削除する必要があります。 既存の PV をリストし、対象の永続ストレージに属する PV を探します。 PV は released 状態になっています。

   oc get pv
   

2. PV を削除します。

   oc delete pv <pv_name>
   

3. PV が削除されたことを確認します。

   oc get pv
   

4. PV の構成ファイルを作成します。 前に取得したパラメーターを含めます。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: "block-storage-pv" # Enter a name for your PV. For example, my-static-pv.
     labels:
        failure-domain.beta.kubernetes.io/region: "<region>" # Example us-east.
        failure-domain.beta.kubernetes.io/zone: "<zone>" # Example: wdc04. See /docs/openshift?topic=openshift-regions-and-zones#zones-sz
   spec:
     capacity:
       storage: "<storage>"
     accessModes:
       - ReadWriteOnce
     flexVolume:
       driver: "ibm/ibmc-block"
       fsType: "<fs_type>" # Enter ext or xfs
       options:
         "Lun": "<Lun_ID>"
         "TargetPortal": "<TargetPortal>"
         "VolumeID": "<VolumeID>"
         "volumeName": "block-storage-pv" # Enter the same value as your PV name from metadata.name
   

   name

   PV に名前を付けます。 例えば、block-storage-pv です。 spec.FlexVolume.optionsでは、この値をvolumeNameとしても入力する必要があることに注意してください。

   labels

   先ほど取得したリージョンとゾーンを入力します。 クラスターでストレージをマウントするには、永続ストレージと同じリージョンおよびゾーンに少なくとも 1 つのワーカー・ノードが存在していなければなりません。 ボリューム詳細を取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行してボリュームの詳細を取得します。

   region

   Block Storage が配置されている領域を入力します。 クラスターと Block Storage は同じリージョンになければならないことに注意してください。 クラスターの場所を見つけるには、ibmcloud oc cluster lsを実行します。 使用可能な地域とゾーンについて詳しくは、地域とゾーンを参照してください。 例えば、us-eastなどです。

   zone

   ストレージ・ボリュームが配置されているゾーンを入力します。 ボリューム詳細を取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行してボリュームの詳細を取得します。 Block Storage をクラスターに接続するには、接続するボリュームと同じゾーンにワーカー・ノードがなければならないことに注意してください。 ワーカー・ノードのゾーンを見つけるには、ibmcloud oc worker ls -c <cluster>を実行します。 例えば、wdc04です。

   storage

   クラスターに接続する既存の Block Storage ボリュームのストレージ・サイズを入力します。 このストレージ・サイズはギガバイト単位 (例えば、20Gi (20 GB) や 1000Gi (1 TB) など) で入力する必要があります。 ボリュームの詳細を取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行してボリュームの詳細を取得します。

   fsType

   既存のブロック・ストレージ用に構成されているファイル・システム・タイプを入力します。 ext4 またはxfsのいずれかを選択します。 このオプションを指定しない場合、PV はデフォルトでext4になります。 誤った fsType が定義された場合、PV の作成は成功しますが、PV のポッドへのマウントは失敗します。 ボリューム詳細を取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行してボリュームの詳細を取得します。

   Lun

   Block Storage ボリュームの LUN ID を入力します。 ボリューム詳細を取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行してボリュームの詳細を取得します。

   TargetPortal

   Block Storage の IP アドレスを入力します。 TargetPortalパラメーターを取得するには、ibmcloud sl block volume-listを実行してボリューム ID を取得してから、ibmcloud sl block volume-detail <volume_ID>を実行し、出力内のTarget IPをメモします。

   VolumeId

   Block Storage の ID を入力します。 ボリュームの詳細を取得するには、ibmcloud sl block volume-listを実行します。

   volumeName

   PV 名と同じ値を入力します。 例えば、block-storage-pv です。

5. クラスターに PV を作成します。

   oc apply -f pv.yaml
   

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

   oc get pv
   

7. PVC を作成するために、別の構成ファイルを作成します。 PVC が、前の手順で作成した PV と一致するようにするには、storage および accessMode に同じ値を選択する必要があります。 storage-class フィールドは空の文字列である必要があります。 これらのフィールドのいずれかが PV と一致しない場合は、代わりに新しい PV が自動的に作成されます。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: block-storage-pvc
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: "20Gi"
     storageClassName: ""
   

8. PVC を作成します。

   oc apply -f static-pvc.yaml
   

9. PVC が作成され、先ほど作成した PV にバインドされたことを確認します。 この処理には数分かかる場合があります。

   oc describe pvc static-pvc
   

   出力例

   Name:          static-pvc
   Namespace:     default
   StorageClass:  
   Status:        Bound
   

10. オプション 以下のポッド構成の例を pod.yamlというファイルとして保存します。

apiVersion: v1
kind: Pod
metadata:
  name: block-storage
  labels:
    app: block-storage
spec:
  containers:
    - name: block-storage
      image: nginx
      command: ["/bin/sh"]
      args: ["-c", "while true; do date \"+%Y-%m-%d %H:%M:%S\"; sleep 3600; done"]
      workingDir: /home
      imagePullPolicy: Always
      ports:
        - containerPort: 80
      volumeMounts:
        - name: block-storage-pv
          mountPath: /home
  volumes:
    - name: block-storage-pv
      persistentVolumeClaim:
        claimName: block-storage-pvc

11. クラスター内にポッドを作成します。

oc create -f pod.yaml

12. ポッドがRunningステータスになったら、ログを取得します。

oc logs

出力例

2022-01-21 16:11:00

PV が正常に作成され、PVC にバインドされました。 次に、その後、Block Storage を使用するアプリをデプロイしました。 クラスター・ユーザーは、デプロイメントに対して PVC のマウントを実行し、永続ボリュームの読み取りと書き込みを開始できるようになりました。

ステートフル・セットの作成時に動的プロビジョニングを使用して PVC を作成する

このオプションは、ステートフル・セットを作成するときに PVC を自動的に作成する場合に使用します。

始める前に、Red Hat OpenShift クラスターにアクセスします。

以下のステップを実行して、クラスター内のすべての既存のステートフル・セットが完全にデプロイされていることを確認します。 ステートフル・セットがまだデプロイされている場合は、ステートフル・セットの作成を開始できません。 予期しない結果が生じるのを避けるため、クラスター内のすべてのステートフル・セットが完全にデプロイされるまで待つ必要があります。

1. クラスター内の既存のステートフル・セットをリストします。

   oc get statefulset --all-namespaces
   

   出力例

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. ステートフル・セットのデプロイメントが完了していることを確かめるため、各ステートフル・セットの Pods Status を確認します。

   oc describe statefulset <statefulset_name>
   

   出力例

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations: oc.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   ...
   

   CLI 出力の Replicas セクションに示されたレプリカの数が、Pods Status セクションの Running ポッドの数と等しい場合は、ステートフル・セットが完全にデプロイ済みです。 ステートフル・セットがまだ完全にデプロイされていない場合は、デプロイメントが完了するまで待ってから、次に進んでください。

3. ステートフル・セットと、そのステートフル・セットを公開するために使用するサービスに関する、構成ファイルを作成します。 下記の例は、3 つのレプリカを伴うステートフル・セットとして NGINX をデプロイする方法を示しています。 レプリカごとに、ibmc-block-retain-bronze ストレージ・クラスで定義された仕様に基づいて、20 ギガバイトのブロック・ストレージ・デバイスがプロビジョンされます。 すべてのストレージ・デバイスは dal10 ゾーンでプロビジョンされます。 他のゾーンから Block Storage にアクセスすることはできないため、ステートフル・セットのすべてのレプリカも、dal10に配置されているワーカー・ノードにデプロイされます。

   apiVersion: v1
   kind: Service
   metadata:
    name: nginx
    labels:
   app: nginx
   spec:
   ports:
   - port: 80
       name: web
   clusterIP: None
   selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
       app: nginx
       billingType: "hourly"
       region: "us-south" # Enter the region where your cluster is located.
       zone: "dal10"
   template:
     metadata:
     labels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
         name: web
       volumeMounts:
       - name: myvol
       mountPath: /usr/share/nginx/html
   volumeClaimTemplates:
   - metadata:
       name: myvol
       spec:
       accessModes:
       - ReadWriteOnce
       resources:
           requests:
           storage: 20Gi
           iops: "300" #required only for performance storage
       storageClassName: ibmc-block-retain-bronze
   

   下記の例は、3 つのレプリカを伴うステートフル・セットとして NGINX をデプロイする方法を示しています。 このステートフル・セットでは、ブロック・ストレージの作成場所であるリージョンとゾーンは指定されません。 代わりに、このステートフル・セットではアンチアフィニティー・ルールを使用して、ポッドが複数のワーカー・ノードとゾーンにまたがって分散されるようにします。 topologykey: failure-domain.beta.kubernetes.io/zoneを定義すると、ワーカー・ノードがapp: nginxラベルを持つポッドと同じゾーンにある場合、Kubernetes スケジューラーはワーカー・ノード上のポッドをスケジュールできません。 各ステートフル・セット・ポッドについて、volumeClaimTemplates セクション内の定義に従って 2 つの PVC が作成されますが、ブロック・ストレージ・インスタンスの作成は、そのストレージを使用するステートフル・セット・ポッドがスケジュールされるまで遅延されます。 この設定は、トポロジーを考慮したボリューム・スケジューリングと呼ばれる。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-block-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-block
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: k8s.gcr.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
   

   name

   ステートフル・セットに対する名前を入力します。 入力した名前は、<volume_name>-<statefulset_name>-<replica_number>という形式で PVC の名前を作成するために使用されます。

   serviceName

   ステートフル・セットを公開するために使用するサービスの名前を入力します。

   replicas

   ステートフル・セットのレプリカの数を入力します。

   podManagementPolicy

   ステートフル・セットで使用するポッド管理ポリシーを入力します。

   • OrderedReady: このオプションを指定すると、ステートフル・セット・レプリカが 1 つずつデプロイされます。 例えば、3 つのレプリカを指定した場合、Kubernetes は 1 番目のレプリカの PVC を作成し、PVC がバインドされるまで待機し、ステートフル・セット・レプリカをデプロイし、PVC をレプリカにマウントします。 このデプロイメントが完了したら、2 番目のレプリカがデプロイされます。 このオプションの詳細については、「 OrderedReady ポッド・マネジメントを参照のこと
   • Parallel: このオプションを指定すると、ステートフル・セット・レプリカのすべてのデプロイメントが同時に開始します。 アプリでレプリカの並行デプロイメントをサポートしている場合は、このオプションを使用して、PVC とステートフル・セット・レプリカをデプロイする時間を節約してください。

   matchLabels

   spec の selector セクションで、ステートフル・セットと PVC に含めるすべてのラベルを入力します。 ステートフル・セットの volumeClaimTemplates に含めたラベルは、Kubernetes によって認識されません。 含めることができるサンプル・ラベルには次のものがあります。

   • regionおよびzone: すべてのステートフル・セット・レプリカと PVC を 1 つの特定のゾーンに作成する場合は、これらのラベルを両方とも追加します。 また、使用するストレージ・クラスでゾーン (zone) とリージョン (region) を指定することもできます。 ゾーンとリージョンを指定せず、複数ゾーン・クラスターを使用している場合、ボリューム要求をすべてのゾーン間で均等に分散させるために、ストレージは、ラウンドロビン・ベースで選択されたゾーンにプロビジョンされます。
   • billingType: PVCに使用する課金タイプを入力します。 hourly または monthly のいずれかを選択します。 このラベルを指定しない場合、すべての PVC が時間単位 (hourly) の課金タイプで作成されます。

   labels

   spec の template の metadata セクションで、spec.selector.matchLabelsセクションに追加したラベルと同じラベルを入力します。

   affinity

   spec の template の spec セクションで、アンチアフィニティー・ルールを指定して、ステートフル・セット・ポッドが複数のワーカー・ノードとゾーンにまたがって分散されるようにします。 この例では、app: nginx ラベルを持つポッドが実行されるワーカー・ノード上でステートフル・セット・ポッドがスケジュールされることが望ましくないアンチアフィニティー・ルールを示しています。 topologykey: failure-domain.beta.kubernetes.io/zone によって、このアンチアフィニティー・ルールがさらに制限されて、このポッドが、app: nginx ラベルを持つポッドと同じゾーン内のワーカー・ノード上でスケジュールされることが防止されます。 このアンチアフィニティー・ルールを使用すると、複数のワーカー・ノードとゾーンにまたがってアンチアフィニティーを実現できます。

   name

   spec の volumeClaimTemplates の metadata セクションで、ボリュームの名前を入力します。 spec.containers.volumeMount.name セクションで定義した名前と同じ名前を使用します。 ここに入力する名前は、<volume_name>-<statefulset_name>-<replica_number>という形式で PVC の名前を作成するために使用されます。

   storage

   spec の volumeClaimTemplates の spec の resources の requests セクションで、ブロック・ストレージのサイズをギガバイト (Gi) 単位で入力します。

   iops

   パフォーマンス・ストレージをプロビジョンする場合は、spec の volumeClaimTemplates の spec の resources の requests セクションで、IOPS 数を入力します。 エンデュランス・ストレージ・クラスを使用することにして IOPS 数を指定した場合は、IOPS 数が無視されます。 その代わりに、そのストレージ・クラスで指定されている IOPS が使用されます。

   storageClassName

   spec の volumeClaimTemplates の spec セクションで、使用するストレージ・クラスを入力します。 既存のストレージ・クラスをリストアップするには、'oc get sc | grep block を実行する。 ストレージ・クラスを指定しない場合、クラスターに設定されているデフォルトのストレージ・クラスを使用して PVC が作成されます。 ブロック・ストレージを使用してステートフル・セットがプロビジョンされるようにするために、デフォルト・ストレージ・クラスで ibm.io/ibmc-block プロビジョナーが使用されていることを確認してください。

4. ステートフル・セットを作成します。

   oc apply -f statefulset.yaml
   

5. ステートフル・セットがデプロイされるまで待ちます。

   oc describe statefulset <statefulset_name>
   

   PVC の現在の状況を確認するには、oc get pvc を実行します。 PVC の名前は、<volume_name>-<statefulset_name>-<replica_number>の形式になります。

既存のPVCとステートフル・セットを使用したスタティック・プロビジョニング

ステートフル・セットを作成する前に PVC を事前プロビジョンするか、既存の PVC をステートフル・セットで使用することができます。

ステートフル・セットの作成時に PVC を動的にプロビジョンする場合は、ステートフル・セット YAML ファイルで使用した値に基づいて、PVC の名前が割り当てられます。 ステートフル・セットによって既存の PVC が使用されるようにするには、PVC の名前が、動的プロビジョニングを使用する場合に自動的に作成される名前と一致していなければなりません。

始める前に、Red Hat OpenShift クラスターにアクセスします。

1. ステートフル・セットを作成する前に、そのステートフル・セット用の PVC を事前プロビジョンする場合は、アプリへのブロック・ストレージの追加のステップ 1 から 3 に従って、各ステートフル・セット・レプリカ用の PVC を作成してください。 <volume_name>-<statefulset_name>-<replica_number>という形式に従った名前で PVC を作成するようにしてください。

   volume_name

   ステートフル・セットのspec.volumeClaimTemplates.metadata.nameセクションで指定する名前 (例えば、nginxvol) を使用します。

   statefulset_name

   ステートフル・セットのmetadata.nameセクションで指定する名前 (例えば、nginx_statefulset) を使用します。

   replica_number

   0 から始まるレプリカの番号を入力します。

   例えば、3 つのステートフル・セット・レプリカを作成する必要がある場合は、次の名前を使用して 3 つの PVC を作成します: nginxvol-nginx_statefulset-0、nginxvol-nginx_statefulset-1、nginxvol-nginx_statefulset-2。

   既存のストレージ・デバイス用の PVC と PV を作成することを検討している場合は、 静的プロビジョニングを使用して PVC と PV を作成してください。

2. 動的プロビジョニング: ステートフル・セット作成時の PVC の作成のステップに従って、ステートフル・セットを作成します。 PVC の名前は、<volume_name>-<statefulset_name>-<replica_number>という形式になります。 PVC 名に含まれている次の値を必ず使用してステートフル・セットを指定してください。 spec.volumeClaimTemplates.metadata.name : PVC 名の<volume_name>を入力します。

   metadata.name

   PVC 名の<statefulset_name>を入力します。

   spec.replicas

   ステートフル・セット用に作成するレプリカの数を入力します。 レプリカの数は、先ほど作成した PVC の数と等しくなければなりません。

   PVC が異なるゾーンにある場合は、ステートフル・セットにリージョン、またはゾーンのラベルを含めないでください。

3. クラスター内のポッドをリストして、ステートフル・セット・レプリカ・ポッドで PVC が使用されていることを確認します。 ステートフル・セットに属するポッドを確認します。

   oc get pods
   

4. 既存の PVC がステートフル・セット・レプリカにマウントされていることを確認します。 CLI 出力の ClaimName セクションで Volumes を確認してください。

   oc describe pod <pod_name>
   

   出力例

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
     Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
     ClaimName:  myvol-nginx-0
   ...
   

定期的なスナップショットをセットアップする

ブロック・ストレージの定期的なスナップショットをセットアップできます。スナップショットとは、特定の時点のインスタンスの状態をキャプチャーした読み取り専用のイメージです。

スナップショットを保管するには、ブロック・ストレージでスナップショット・スペースを要求する必要があります。 スナップショットは、同じゾーン内の既存のストレージ・インスタンスに保管されます。 ユーザーがボリュームから重要なデータを誤って削除した場合に、スナップショットからデータをリストアすることができます。 \n \n ** ボリュームのスナップショットを作成するには、以下の手順を実行します。

1. Red Hat OpenShift クラスターにアクセスします。

2. ibmcloud sl CLI にログインします。

   ibmcloud sl init
   

3. クラスター内の既存の PV をリストします。

   oc get pv
   

4. スナップショット・スペースを作成する PV の詳細を取得し、ボリューム ID、サイズ、および IOPS をメモします。 サイズと IOPS は CLI 出力の Labels セクションに表示されます。

   oc describe pv <pv_name>
   

5. ボリューム ID は、CLI 出力の ibm.io/network-storage-id アノテーションで確認します。

6. 前のステップで取得したパラメーターを使用して、既存のボリュームのスナップショット・サイズを作成します。

   ibmcloud sl block snapshot-order <volume_ID> --size <size> --tier <iops>
   

7. スナップショット・サイズが作成されるまで待ちます。 CLI 出力の Snapshot Size (GB) が 0 から注文したサイズに変更されていれば、スナップショット・サイズは正常にプロビジョンされています。

   ibmcloud sl block volume-detail <volume_ID>
   

8. ボリュームのスナップショットを作成し、作成されたスナップショットの ID をメモします。

   ibmcloud sl block snapshot-create <volume_ID>
   

9. スナップショットが正常に作成されたことを確認します。

   ibmcloud sl block snapshot-list <volume_ID>
   

10. スナップショット・スケジュールを設定します。 スナップショット・スケジュールで使用可能なオプションについて詳しくは、 CLI の資料 を参照してください。

    ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
    

11. スナップショットのデータを既存のボリュームにリストアするには、次のコマンドを実行します。

    ibmcloud sl block snapshot-restore <volume_ID> <snapshot_ID>
    

別のゾーンへのスナップショットのレプリケーション

ゾーンの障害からデータを保護するために、別のゾーンにセットアップしたブロック・ストレージのインスタンスにスナップショットをレプリケーションすることができます。

データは、1 次ストレージからバックアップ・ストレージにのみレプリケーションできます。 複製された Block Storage インスタンスをクラスターにマウントすることはできません。 1 次ストレージに障害が発生した場合には、レプリケーションされたバックアップ・ストレージを 1 次ストレージに手動で設定できます。 すると、そのファイル共有をクラスターにマウントできます。 1 次ストレージがリストアされたら、バックアップ・ストレージからデータをリストアできます。

ストレージの複製

元のストレージ・インスタンスと同じゾーンに、ブロック・ストレージ・インスタンスを複製できます。

複製インスタンスのデータは、それを作成した時点の元のストレージ・インスタンスと同じです。 レプリカとは異なり、複製インスタンスは、元のインスタンスから独立したストレージ・インスタンスとして使用します。 複製するには、まず、ボリュームのスナップショットをセットアップします。

IBM Cloud® Object Storage へのデータのバックアップ

Helm チャート ibm-backup-restore を使用して、バックアップとリストアのためのポッドをクラスター内で起動できます。

このポッドには、クラスター内の任意の永続ボリューム請求 (PVC) のために 1 回限りのバックアップまたは定期バックアップを実行するスクリプトが含まれています。 データは、ゾーンにセットアップした IBM Cloud® Object Storage インスタンスに保管されます。

ブロック・ストレージは、RWO アクセス・モードでマウントされます。 このアクセスでは、一度に 1 つのポッドしかブロック・ストレージにマウントできません。 データをバックアップするには、ストレージからアプリ・ポッドをアンマウントし、バックアップ・ポッドにマウントしてデータをバックアップしてから、アプリ・ポッドに再マウントする必要があります。

データの可用性をさらに高め、アプリをゾーン障害から保護するには、2 つ目の Object Storage インスタンスをセットアップして、ゾーン間でデータを複製します。 Object Storage インスタンスからデータをリストアする必要がある場合は、この Helm チャートで提供されるリストア・ポッドを使用します。

ポッドやコンテナーとの間のデータのコピー

oc cp コマンドを使うと、クラスタ内のポッドや特定のコンテナとの間でファイルやディレクトリをコピーできる。

Red Hat OpenShift クラスターにアクセスします。

oc cpコマンドを実行するときに、-cでコンテナーを指定しない場合、コマンドはポッド内の最初の使用可能なコンテナーを使用します。

ローカル・マシンからクラスター内のポッドにデータをコピーする。

oc cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

クラスター内のポッドからローカル・マシンにデータをコピーする。

oc cp <namespace>/<pod>:<pod_filepath>/<filename> <local_filepath>/<filename>

ローカル・マシンからクラスター内のポッドで実行される特定のコンテナーにデータをコピーする。

oc cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

ブロンズ

名前

ibmc-block-bronze

ibmc-block-retain-bronze

タイプ

エンデュランス・ストレージ

ファイル・システム

ext4

IOPS/GB

2

サイズの範囲 (ギガバイト単位)

20 から 12000 Gi

ハード・ディスク

SSD

再利用ポリシー

ibmc-block-bronze: 削除

ibmc-block-retain-bronze: 保持

シルバー

名前

ibmc-block-silver

ibmc-block-retain-silver

タイプ

エンデュランス・ストレージ

ファイル・システム

ext4

IOPS/GB

4

サイズの範囲 (ギガバイト単位)

20 から 12000 Gi

ハード・ディスク

SSD

再利用ポリシー

ibmc-block-silver: 削除

ibmc-block-retain-silver: 保持

ゴールド

名前

ibmc-block-gold

ibmc-block-retain-gold

タイプ

エンデュランス・ストレージ

ファイル・システム

ext4

IOPS/GB

10

サイズの範囲 (ギガバイト単位)

20 から 4000 Gi

ハード・ディスク

SSD

再利用ポリシー

ibmc-block-gold: 削除

ibmc-block-retain-gold: 保持

カスタム

名前

ibmc-block-custom

ibmc-block-retain-custom

タイプ

パフォーマンス・ファイル・システム

ext4

IOPS とサイズ

サイズ範囲 (ギガバイト単位) /IOPS 範囲 (100 の倍数)

• 20 から 39 Gi / 100 から 1000 IOPS
• 40 から 79 Gi / 100 から 2000 IOPS
• 80 から 99 Gi / 100 から 4000 IOPS
• 100 から 499 Gi / 100 から 6000 IOPS
• 500 から 999 Gi / 100 から 10000 IOPS
• 1000 から 1999 Gi / 100 から 20000 IOPS
• 2000 から 2999 Gi / 200 から 40000 IOPS
• 3000 から 3999 Gi / 200 から 48000 IOPS
• 4000 から 7999 Gi / 300 から 48000 IOPS
• 8000 から 9999 Gi / 500 から 48000 IOPS
• 10000 から 12000 Gi / 1000 から 48000 IOPS

ハード・ディスク

ギガバイトに対する IOPS の比率によって、プロビジョンされるハード・ディスクのタイプが決まります。 ギガバイトに対する IOPS の比率を求めるには、IOPS をストレージ・サイズで除算します。

例: 100 IOPS のストレージの 500Gi を選択したとします。 比率は 0.2 です (100 IOPS/500Gi)。

比率ごとのハード・ディスク・タイプの概要:

• 0.3 以下: SATA
• 0.3 より大: SSD

再利用ポリシー

ibmc-block-custom: 削除

ibmc-block-retain-custom: 保持

トポロジー対応ストレージの作成

マルチゾーン・クラスターでブロック・ストレージを使用するには、ブロック・ストレージ・インスタンスと同じゾーン内でポッドがスケジュールされる必要があります。その結果として、ボリュームの読み取りと書き込みが可能になります。 Kubernetes でトポロジー対応ボリューム・スケジューリングが導入される前は、ストレージの動的プロビジョニングによって、PVC の作成時にブロック・ストレージ・インスタンスが自動的に作成されていました。 その当時は、ポッドを作成したときに、Kubernetes スケジューラーはそのポッドをブロック・ストレージ・インスタンスと同じデータ・センターにデプロイしようとしていました。

ポッドの制約事項を知らずにブロック・ストレージ・インスタンスを作成すると、望ましくない結果が生じる可能性があります。 例えば、ご使用のストレージと同じワーカー・ノードに対してポッドをスケジュールできない場合があります。その理由は、そのワーカー・ノードのリソースが不十分であるか、そのワーカー・ノードにテイントが適用されているためそのワーカー・ノードではそのポッドのスケジューリングが許可されないからです。 トポロジー対応ボリューム・スケジューリングを使用すると、該当ストレージを使用する最初のポッドが作成されるまで、ブロック・ストレージ・インスタンスが遅延されます。

トポロジー対応ボリューム・スケジューリングを使用するためには、IBM Cloud Block Storage プラグイン・バージョン 1.2.0 以降をインストールしている必要があります。

次の例では、当該ストレージを使用する最初のポッドがスケジュール可能になるまで、ブロック・ストレージ・インスタンスの作成を遅延させるストレージ・クラスを作成する方法を示しています。 作成を遅延させるには、volumeBindingMode: WaitForFirstConsumer オプションを含める必要があります。 このオプションを指定しない場合、volumeBindingModeは自動的にImmediateに設定され、PVC の作成時に Block Storage インスタンスが作成されます。

エンデュランス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-bronze-delayed
  parameters:
    billingType: hourly
    classVersion: "2"
    fsType: ext4
    iopsPerGB: "2"
    sizeRange: '[20-12000]Gi'
    type: Endurance
  provisioner: ibm.io/ibmc-block
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

パフォーマンス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-performance-storageclass
  labels:
  kubernetes.io/cluster-service: "true"
  provisioner: ibm.io/ibmc-block
  parameters:
    billingType: "hourly"
    classVersion: "2"
    sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
    type: "Performance"
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

ゾーンとリージョンの指定

特定のゾーン内でブロック・ストレージを作成する場合は、カスタマイズされたストレージ・クラス内でそのゾーンとリージョンを指定できます。

IBM Cloud Block Storage プラグインのバージョン 1.0.0 を使用する場合、または特定のゾーンでブロック・ストレージを静的にプロビジョンする場合には、カスタマイズ・ストレージ・クラスを使用します。 その他の場合は、PVC で直接ゾーンを指定してください。

次の .yaml ファイルでカスタマイズしているストレージ・クラスは、非 retain の ibm-block-silver ストレージ・クラスに基づいています。type は "Endurance"、iopsPerGB は 4、sizeRange は "[20-12000]Gi"、reclaimPolicy の設定は "Delete" です。 ゾーンは dal12 と指定しています。 別のストレージ・クラスをベースとして使用するには、ストレージ・クラス・リファレンスを参照してください。

ご使用のクラスターおよびワーカー・ノードと同じリージョンおよびゾーン内にストレージ・クラスを作成します。 クラスターのリージョンを取得するには、ibmcloud oc cluster get --cluster <cluster_name_or_ID>を実行し、マスター URL でリージョンプレフィックス (https://c2.eu-de.containers.cloud.ibm.com:11111のeu-de など) を確認します。 ワーカー・ノードのゾーンを取得するには、ibmcloud oc worker ls --cluster <cluster_name_or_ID>を実行します。

エンデュランス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-silver-mycustom-storageclass
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-block
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
reclaimPolicy: "Delete"

パフォーマンス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-block-performance-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-block
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Performance"
  sizeIOPSRange: |-
  "[20-39]Gi:[100-1000]"
  "[40-79]Gi:[100-2000]"
  "[80-99]Gi:[100-4000]"
  "[100-499]Gi:[100-6000]"
  "[500-999]Gi:[100-10000]"
  "[1000-1999]Gi:[100-20000]"
  "[2000-2999]Gi:[200-40000]"
  "[3000-3999]Gi:[200-48000]"
  "[4000-7999]Gi:[300-48000]"
  "[8000-9999]Gi:[500-48000]"
  "[10000-12000]Gi:[1000-48000]"
reclaimPolicy: "Delete"

XFS ファイル・システムを使用してブロック・ストレージをマウントする

次の例では、XFS ファイル・システムを使用するブロック・ストレージをプロビジョンするストレージ・クラスを作成します。

エンデュランス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
labels:
  addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  fsType: "xfs"
reclaimPolicy: "Delete"

パフォーマンス・ブロック・ストレージの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  classVersion: "2"
  type: "Performance"
  sizeIOPSRange: |-
    [20-39]Gi:[100-1000]
    [40-79]Gi:[100-2000]
    [80-99]Gi:[100-4000]
    [100-499]Gi:[100-6000]
    [500-999]Gi:[100-10000]
    [1000-1999]Gi:[100-20000]
    [2000-2999]Gi:[200-40000]
    [3000-3999]Gi:[200-48000]
    [4000-7999]Gi:[300-48000]
    [8000-9999]Gi:[500-48000]
    [10000-12000]Gi:[1000-48000]
  fsType: "xfs"
reclaimPolicy: "Delete"

ストレージ削除オプションについて

IBM Cloud アカウントから永続ストレージを削除する方法は、ストレージをプロビジョンした方法と、どのコンポーネントを既に削除したかによって異なります。

クラスタを削除すると永続ストレージは削除されますか？

クラスターの削除中に、永続ストレージの削除を選択できます。 ただし、ストレージをプロビジョンした方法によっては、ストレージの削除にすべてのストレージ・コンポーネントが含まれない場合があります。 reclaimPolicy: Delete 設定したストレージクラスでストレージを動的にプロビジョニングした場合、クラスターを削除すると、PVC、PV、ストレージインスタンスが自動的に削除されます。 静的にプロビジョニングされたストレージ、または「reclaimPolicy: Retain 設定したストレージクラスでプロビジョニングしたストレージの場合、クラスタを削除するとPVCとPVは削除されますが、ストレージインスタンスとデータは残ります。 ストレージ・インスタンスは引き続き課金されます。 また、クラスターを正常でない状態で削除した場合は、ストレージを削除することを選択していても、ストレージがまだ存在している可能性があります。

クラスターを維持したい場合、ストレージを削除するにはどうすればよいですか？

reclaimPolicy: Delete を設定するストレージ・クラスを使用してストレージを動的にプロビジョンした場合、PVC を削除することにより、永続ストレージの削除プロセスを開始できます。 PVC、PV、およびストレージ・インスタンスは自動的に削除されます。 静的にプロビジョニングされたストレージ、または「reclaimPolicy: Retain 設定したストレージクラスでプロビジョニングしたストレージについては、さらなる課金を避けるために、PVC、PV、およびストレージインスタンスを手動で削除する必要があります。

ストレージを削除した後、課金はどのように停止されますか？

削除するストレージ・コンポーネントとそのタイミングによっては、請求処理サイクルが即時に停止しない場合があります。 PVC と PV を削除しても、IBM Cloud アカウントのストレージ・インスタンスを削除しなかった場合は、そのインスタンスがまだ存在するので課金されます。

PVC、PV、およびストレージ・インスタンスを削除すると、ストレージのプロビジョン時に選択した billingType およびストレージの削除方法に応じて、請求処理サイクルが停止します。

• IBM CloudコンソールまたはCLIから永続ストレージインスタンスを手動でキャンセルすると、以下のように課金が停止します：

  • 時間単位のストレージの場合: 課金は即座に停止されます。 ストレージが取り消された後も、最大で 72 時間、コンソールに引き続きそのストレージ・インスタンスが表示される可能性があります。
  • 月単位のストレージの場合: 即時取り消しまたは確定日に取り消しのいずれかを選択できます。 いずれの場合も、現在の請求処理サイクルの終わりまで課金され、次の請求処理サイクルで課金が停止します。 ストレージを取り消した後も、最大 72 時間、コンソールまたは CLI に引き続きそのストレージ・インスタンスが表示される可能性があります。
  • 即時キャンセル: ストレージを即時に削除するには、このオプションを選択します。 お客様もお客様のユーザーも、ストレージの使用やデータのリカバリーをすることとができなくなります。
  • 確定日: 次の確定日にストレージを取り消すには、このオプションを選択します。 ストレージ・インスタンスは次回の確定日までアクティブのままになり、この日付までは引き続き使用できます (例えば、チームにデータのバックアップを作成する時間を与えることができます)。

• reclaimPolicy: Delete を設定するストレージ・クラスを使用してストレージを動的にプロビジョンし、PVC の削除を選択すると、PV およびストレージ・インスタンスは即時に削除されます。 時間単位で課金されるストレージの場合、請求処理は即時に停止します。 月単位で課金されるストレージの場合、その月の最後まで引き続き請求されます。 ストレージが削除されて請求処理が停止した後も、最大で 72 時間、コンソールまたは CLI に引き続きそのストレージ・インスタンスが表示される可能性があります。

永続的ストレージを削除する前に注意すべきことは？

永続ストレージをクリーンアップすると、保管されているすべてのデータが削除されます。 データのコピーが必要な場合は、バックアップを作成してください。

ストレージインスタンスを削除した。 自分のインスタンスがまだ表示されるのはなぜですか？

永続ストレージを削除した後、削除の処理が完了して、そのストレージが IBM Cloud コンソールまたは CLI に表示されなくなるまでに、最大 72 時間かかる可能性があります。

永続ストレージのクリーンアップ

永続ストレージに対する追加料金が発生することを回避するために、PVC、PV、およびストレージ・インスタンスを IBM Cloud アカウントから削除します。

始める前に

• 保持するデータをすべてバックアップしたことを確認します。
• Red Hat OpenShift クラスターにアクセスします。

永続データをクリーンアップするには、次の手順を実行します。

1. クラスターの PVC をリストし、PVC の NAME、STORAGECLASS、および PVC にバインドされていて VOLUME として表示されている PV の名前をメモします。

   oc get pvc
   

   出力例

   NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
   claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
   claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
   claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d
   

2. ストレージ・クラスの ReclaimPolicy と billingType を確認します。

   oc describe storageclass <storageclass_name>
   

   回収ポリシーが Delete の場合は、PVC を削除すると、PV と物理ストレージも削除されます。 回収ポリシーが Retain の場合、またはストレージ・クラスを指定せずにストレージをプロビジョンした場合は、PVC を削除しても、PV と物理ストレージは削除されません。 PVC、PV、および物理ストレージを個別に削除する必要があります。

   ストレージの課金が月単位の場合は、課金サイクルの終了前にストレージを削除しても、その月の月額料金が課金されます。

3. PVC をマウントするすべてのポッドを削除します。 PVC をマウントするポッドをリストします。 CLI 出力でポッドが返されない場合は、PVC を使用するポッドがありません。

   oc get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   出力例

   depl-12345-prz7b:    claim1
   

4. PVC を使用するポッドを削除します。 ポッドがデプロイメントの一部である場合は、デプロイメントを削除します。

   oc delete pod <pod_name>
   

5. ポッドが削除されたことを確認します。

   oc get pods
   

6. PVC を削除します。

   oc delete pvc <pvc_name>
   

7. PV の状況を確認します。 先ほど取得した PV の名前を、VOLUME として使用します。 PVC を削除すると、PVC にバインドされている PV はリリースされます。 PV の状態は、ストレージをプロビジョンした方法に応じて、PV が自動的に削除された場合は Deleting 状態になり、PV を手動で削除する必要がある場合は Released 状態になります。 注: 自動的に削除される PV の場合、削除が終わる前に一時的に状況が Released と表示されることがあります。 数分後にコマンドを再実行し、PV が削除されたことを確認してください。

   oc get pv <pv_name>
   

8. PV が削除されていない場合は、手動で PV を削除します。

   oc delete pv <pv_name>
   

9. PV が削除されたことを確認します。

   oc get pv
   

10. PV が指していた物理ストレージ・インスタンスをリストし、物理ストレージ・インスタンスの id をメモします。

    ibmcloud sl block volume-list --columns id --columns notes | grep <pv_name>
    

    出力例

    12345678   {"plugin":"ibmcloud-block-storage-plugin-689df949d6-4n9qg","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"block-storage-pvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-block-silver","reclaim":"Delete"}
    

    Notes フィールドの情報について

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    クラスターが使用するストレージ・プラグイン。

    "region":"us-south"

    クラスターが存在するリージョン。

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    ストレージ・インスタンスに関連付けられているクラスター ID。

    "type":"Endurance"

    ファイル・ストレージまたは Block Storage のタイプ (Endurance または Performance)。

    "ns":"default"

    ストレージ・インスタンスのデプロイ先の名前空間。

    "pvc":"block-storage-pvc"

    ストレージ・インスタンスに関連付けられている PVC の名前。

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    ストレージ・インスタンスに関連付けられている PV。

    "storageclass":"ibmc-file-gold"

    ストレージ・クラスのタイプ (ブロンズ、シルバー、ゴールド、またはカスタム)。

11. 物理ストレージ・インスタンスを削除します。

    ibmcloud sl block volume-cancel <classic_block_id>
    

12. 物理ストレージ・インスタンスが削除されたことを確認します。

削除処理は、完了するまでに最大 72 時間かかることがあります。

ibmcloud sl block volume-list