ファイル・ストレージのタイプ

プロビジョンする File Storage for Classic のタイプを選択します。

ブロンズ、シルバー、およびゴールドのストレージ・クラス

これらのストレージ・クラスはエンデュランス・ストレージをプロビジョンします。 エンデュランス・ストレージの場合、事前定義された IOPS ティアでストレージのサイズ (ギガバイト単位) を選択できます。

カスタム・ストレージ・クラス

このストレージ・クラスはパフォーマンス・ストレージをプロビジョンします。 パフォーマンス・ストレージの場合は、より柔軟にストレージのサイズと IOPS を選択できます。

IOPS

File Storage for Classicのサイズと IOPS を選択します。 IOPS のサイズと数値によって、合計 IOPS (1 秒あたりの入出力操作数) が決まります。これは、ストレージの速度を示す指標となります。 ストレージの合計 IOPS が多いほど、読み取り/書き込み操作の処理が高速になります。

ブロンズ、シルバー、およびゴールドのストレージ・クラス

これらのストレージ・クラスは、ギガバイト当たりの IOPS 数が固定されており、SSD ハード・ディスクにプロビジョンされます。 合計の IOPS 数は、選択したストレージのサイズによって決まります。 指定可能なサイズの範囲内で、任意の整数のギガバイト (20 Gi、256 Gi、11854 Gi など) を選択できます。 合計 IOPS 数を求めるには、選択したサイズと IOPS を乗算します。 例えば、4 IOPS/GB のシルバー・ストレージ・クラスで、1000Gi のFile Storage for Classic・サイズを選択すると、ストレージの合計 IOPS は 4000 になります。

カスタム・ストレージ・クラス

このストレージ・クラスを選択すると、必要なサイズと IOPS をより詳細に制御できます。 サイズについては、指定可能なサイズの範囲内で、任意の整数のギガバイトを選択できます。 選択したサイズに応じて、選択可能な IOPS の範囲が決まります。 指定された範囲にある 100 の倍数で IOPS を選択できます。 選択する IOPS は静的であり、ストレージのサイズに合わせてスケーリングされません。 例えば、40Gi と 100 IOPS を選択した場合、合計 IOPS は 100 のままです。

ギガバイトに対する IOPS の比率によって、プロビジョンされるハード・ディスクのタイプも決まります。 例えば、500Gi を 100 IOPS で選択した場合、ギガバイトに対する IOPS の比率は 0.2 となります。 0.3 以下の比率のストレージは、SATA ハード・ディスクにプロビジョンされます。 0.3 より大きい比率のストレージは、SSD ハード・ディスクにプロビジョンされます。

再利用ポリシー

クラスターまたは永続ボリューム請求 (PVC) が削除された後もデータを保持するかどうかを選択します。

• データを保持する場合、retain ストレージ・クラスを選択します。 PVC を削除すると、PVC のみが削除されます。 PV と、IBM Cloud インフラストラクチャー・アカウント内の物理ストレージ・デバイスと、データは残ります。 ストレージを回収し、クラスターで再使用するには、PV を削除し、既存のFile Storage for Classicを使用する手順に従う必要があります。
• PVC を削除するときに PV、データ、物理 File Storage for Classic デバイスが削除されるようにするには、retain なしのストレージ・クラスを選択します。

課金タイプ

時間単位と月単位のどちらかを選択します。 詳しくは、 料金 を参照してください。

デフォルトでは、すべてのFile Storage for Classic・デバイスが時間単位の課金タイプでプロビジョンされます。

月単位の課金タイプを選択した場合は、永続ストレージを短期間しか使用せずに削除しても、月額料金を支払うことになります。

既存のストレージの準備

アプリへの既存のストレージのマウントを開始するには、その前に、PV に関する必要な情報をすべて取得し、クラスターでストレージにアクセスできるように準備する必要があります。

retain ストレージクラスでプロビジョニングされたストレージの場合。

retain ストレージ・クラスを指定してストレージをプロビジョンした場合、PVC を削除しても、PV と物理ストレージ・デバイスは自動的に削除されません。 そのストレージをクラスターで再使用するには、残っている PV をまず削除する必要があります。

既存のストレージを、プロビジョンしたクラスターとは別のクラスターで使用するには、クラスターの外部で作成されたストレージの手順に従って、ストレージをワーカー・ノードのサブネットに追加してください。

1. 既存の PV をリストします。

   kubectl get pv
   

   対象の永続ストレージに属する PV を探します。 PV は released 状態になっています。

2. PV の詳細情報を取得します。

   kubectl describe pv <pv_name>
   

3. CapacityGb、storageClass、failure-domain.beta.kubernetes.io/region、failure-domain.beta.kubernetes.io/zone、server、path をメモします。

4. PV を削除します。

   kubectl delete pv <pv_name>
   

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

   kubectl get pv
   

クラスタ外でプロビジョニングされた永続ストレージの場合

以前にプロビジョンして、まだクラスターで使用したことがない既存のストレージを使用するには、そのストレージをワーカー・ノードと同じサブネットで使用できるようにする必要があります。

1. IBM Cloud のインフラストラクチャ・ポータルで、「 ストレージ 」をクリックします。
2. **「File Storage for Classic」をクリックして、「アクション」メニューから「ホストの許可」**を選択します。
3. **「サブネット」**を選択します。
4. ドロップダウン・リストから、ワーカー・ノードが接続されているプライベート VLAN サブネットを選択します。 ワーカー・ノードのサブネットを見つけるには、ibmcloud ks worker ls --cluster <cluster_name> を実行し、ワーカー・ノードの Private IP をドロップダウン・リストで確認したサブネットと比較します。
5. **「送信」**をクリックします。
6. File Storage for Classicの名前をクリックします。
7. Mount Point、size、Locationのフィールドをメモします。 Mount Point フィールドは <nfs_server>:<file_storage_path> と表示されます。

永続ボリュームと永続ボリューム・クレームの作成

1. PV のストレージ構成ファイルを作成します。 先ほど取得した値を含めます。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   作成する PV オブジェクトの名前を入力します。

   labels

   先ほど取得したリージョンとゾーンを入力します。 同じリージョンとゾーンに少なくとも 1 つのワーカー・ノードがなければなりません。

   storage

   先ほど取得した既存の NFS ファイル共有のストレージ・サイズを入力します。 このストレージ・サイズはギガバイト単位 (例えば、20Gi (20 GB) や 1000Gi (1 TB) など) で入力する必要があり、そのサイズは既存のファイル共有のサイズと一致している必要があります。

   accessMode

   以下のいずれかのオプションを指定します。

   • ReadWriteMany: PVC は複数のポッドによってマウントできます。 すべてのポッドは、ボリュームに対する読み取りと書き込みを行うことができます。
   • ReadOnlyMany: PVC は複数のポッドによってマウントできます。 すべてのポッドには読み取り専用アクセス権限があります。
   • ReadWriteOnce: PVC は 1 つのポッドのみによってマウントできます。 このポッドは、ボリュームに対して読み取りと書き込みを行うことができます。

   server

   先ほど取得した NFS ファイル共有サーバーの ID を入力します。

   path

   先ほど取得した NFS ファイル共有のパスを入力します。

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

   kubectl apply -f mypv.yaml
   

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

   kubectl get pv
   

4. PVC を作成するために、別の構成ファイルを作成します。 PVC が、前の手順で作成した PV と一致するようにするには、storage および accessMode に同じ値を選択する必要があります。 storage-class フィールドは空の文字列である必要があります。 これらのフィールドのいずれかがPVと一致しない場合、新しいPVと新しい物理ストレージインスタンスが動的にプロビジョニングされます。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. PVC を作成します。

   kubectl apply -f mypvc.yaml
   

6. PVC が作成され、PV にバインドされたことを確認します。

   kubectl describe pvc mypvc
   

   出力例

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

PV が正常に作成され、PVC にバインドされました。 これで、クラスター・ユーザーがデプロイメントにPVC をマウントして、PV オブジェクトへの読み書きを開始できるようになりました。

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

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

始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

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

   kubectl get statefulset --all-namespaces
   

   出力例

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

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

   kubectl 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:        kubectl.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-file-retain-bronze ストレージ・クラスの仕様に基づいて、20 ギガバイトのFile Storage for Classic・デバイスがプロビジョンされます。 すべてのストレージ・デバイスは dal10 ゾーンでプロビジョンされます。 File Storage for Classic には他のゾーンからアクセスできないため、ステートフル・セットのすべてのレプリカも、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"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           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-file-retain-bronze
   

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

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   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: registry.k8s.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:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

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

   serviceName

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

   replicas

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

   podManagementPolicy

   ステートフル・セットで使用するポッド管理ポリシーを入力します。 次のいずれかのオプションを選択します。

   • OrderedReady: このオプションを指定すると、ステートフル・セット・レプリカが 1 つずつデプロイされます。 例えば、3 つのレプリカを指定した場合、Kubernetes は 1 番目のレプリカの PVC を作成し、PVC がバインドされるまで待機し、ステートフル・セット・レプリカをデプロイし、PVC をレプリカにマウントします。 このデプロイメントが完了したら、2 番目のレプリカがデプロイされます。 このオプションの詳細については、「 OrderedReady のPod管理 」を参照してください。
   • 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 の affinity セクションで、アンチアフィニティー・ルールを指定して、ステートフル・セット・ポッドが複数のワーカー・ノードとゾーンにまたがって分散されるようにします。 この例では、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 セクションで、File Storage for Classicのサイズをギガバイト (Gi) 単位で入力します。

   iops

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

   storageClassName

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

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

   kubectl apply -f statefulset.yaml
   

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

   kubectl describe statefulset <statefulset_name>
   

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

静的プロビジョニング: ステートフル・セットと組み合わせた既存の PVC の使用

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

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

始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

1. ステートフル・セットを作成する前に PVC を事前プロビジョンする場合は、File Storage for Classicをアプリに追加するのステップ 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。

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

1. 動的プロビジョニング: ステートフル・セット作成時の 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 が異なるゾーンにある場合は、ステートフル・セットにリージョン、またはゾーンのラベルを含めないでください。

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

   kubectl get pods
   

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

   kubectl 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
   ...
   

特定の NFS バージョンを使用したカスタムストレージクラスの作成

1. プロビジョンする NFS バージョンを指定して、カスタマイズしたストレージ・クラスを作成します。

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

   kubectl apply -f nfsversion_storageclass.yaml
   

3. カスタマイズしたストレージ・クラスが作成されたことを確認します。

   kubectl get sc
   

4. カスタマイズしたストレージ・クラスでFile Storage for Classicをプロビジョンします。

既存のPVを、別の NFS バージョンを使用するように変更する

1. NFS バージョンを変更するFile Storage for Classicの PV を取得し、PV の名前をメモします。

   kubectl get pv
   

2. PV にアノテーションを追加します。 <version_number> を、使用する NFS バージョンに置き換えます。 例えば、NFS バージョン 3.0 に変更するには、3 を入力します。

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. File Storage for Classicを使用するポッドを削除し、ポッドを再作成します。

   1. ポッド YAML をローカル・マシンに保存します。

       kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
       ```
   2. ポッドを削除します。
   
   ```sh {: pre}
       kubectl deleted pod <pod_name>
       ```
   3. ポッドを再作成します。
   
   ```sh {: pre}
       kubectl apply -f pod.yaml
       ```
   

4. ポッドがデプロイされるまで待ちます。 status が Running に変更されたら、ポッドは完全にデプロイされています。

   kubectl get pods
   

5. ポッドにログインします。

   kubectl exec -it <pod_name> sh
   

6. 以前指定した NFS バージョンでFile Storage for Classicがマウントされたことを確認します。

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   出力例

   nfs vers=3.0
   

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

File Storage for Classicの定期的なスナップショットをセットアップできます。スナップショットとは、特定の時点のインスタンスの状態をキャプチャーした読み取り専用のイメージです。 スナップショットを保管するには、File Storage for Classicでスナップショット・スペースを要求する必要があります。 スナップショットは、同じゾーン内の既存のストレージ・インスタンスに保管されます。 ユーザーが誤って重要なデータをボリュームから削除した場合に、スナップショットからデータをリストアできます。

ボリュームのスナップショットを作成するには、以下の手順を実行します。

1. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

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

   ibmcloud sl init
   

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

   kubectl get pv
   

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

   kubectl describe pv <pv_name>
   

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

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

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

   ibmcloud sl file volume-detail <volume_ID>
   

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

   ibmcloud sl file snapshot-create <volume_ID>
   

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

   ibmcloud sl file snapshot-list <volume_ID>
   

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

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

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

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

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

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

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

ストレージの複製

元のストレージ・インスタンスと同じゾーンに、File Storage for Classic・インスタンスを複製できます。

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

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

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

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

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

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

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

始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。 -c でコンテナーを指定しない場合、コマンドはポッド内の最初の使用可能なコンテナーを使用します。

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

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

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

kubectl cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

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

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

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

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

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

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

エンデュランス・File Storage for Classicの例。

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

パフォーマンス・File Storage for Classicの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
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

複数ゾーン・クラスターのゾーンを指定する

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

特定のゾーン内でFile Storage for Classicを静的にプロビジョンする場合は、カスタマイズされたストレージ・クラスを使用してください。 その他の場合は、PVC で直接ゾーンを指定してください。

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

エンデュランス・File Storage for Classicの例。

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

パフォーマンス・File Storage for Classicの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  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: Immediate

デフォルトの NFS バージョンの変更

次のカスタマイズされたストレージ・クラスでは、プロビジョンする NFS バージョンを指定できます。 例えば、NFS バージョン 3.0 をプロビジョンするには、<nfs_version> を 3.0 に置き換えます。

エンデュランス・File Storage for Classicの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

パフォーマンス・File Storage for Classicの例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  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]"
  mountOptions: nfsvers=<nfs_version>

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

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 アカウントから削除します。

始める前に

• 保持するデータをすべてバックアップしたことを確認します。
• アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

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

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

   kubectl 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 を確認します。

   kubectl describe storageclass <storageclass_name>
   

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

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

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

   kubectl 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 を使用するポッドを削除します。 ポッドがデプロイメントの一部である場合は、デプロイメントを削除します。

   kubectl delete pod <pod_name>
   

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

   kubectl get pods
   

6. PVC を削除します。

   kubectl delete pvc <pvc_name>
   

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

   kubectl get pv <pv_name>
   

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

   kubectl delete pv <pv_name>
   

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

   kubectl get pv
   

10. PV が指している物理ストレージ・インスタンスをリストし、物理ストレージ・インスタンスの**id**を書き留めます。

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

    File Storage for Classicの出力例。

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

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

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

    "region":"us-south"

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

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

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

    "type":"Endurance"

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

    "ns":"default"

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

    "pvc":"mypvc"

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

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

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

    "storageclass":"ibmc-file-gold"

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

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

    ibmcloud sl file volume-cancel <classic_file_id>
    

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

    ibmcloud sl file volume-list
    

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