バケットの作成と削除を理解する

• PVCにバケツ名を指定することで、既存のバケツを利用することができます。
• バケツ名を指定し、そのバケツが存在しない場合は、その名前のバケツが作成される。
• バケット名を指定しない場合、マウンターの種類に応じて、 s3fs-<timestamp>-xxx または rclone-<timestamp>-xxx という命名規則に基づくバケットが作成されます。
• バケットは、ストレージクラスで定義された再生ポリシーに基づいて削除されます。
  • reclaimPolicy: Delete 設定されている場合、PVCが削除されるとバケットは削除される。
  • reclaimPolicy: Retain 設定すると、PVCが削除されてもバケットは保持される。

ノードサーバーのポッドスケジューリングの制限

デフォルトでは、COS CSI ドライバーのノードサーバー ポッドは、クラスター内のすべてのノードにスケジューリングされます。 restrictNodeServerScheduling パラメータを使用すると、ノードサーバーのポッドのスケジューリングを、 cos.csi.ibm.io/csi-node=true というラベルが付けられたノードのみに制限することができます。

restrictNodeServerScheduling の設定は、アドオンを有効にする際に設定するか、後で ConfigMap にパッチを適用して更新することができます。

• アドオンを有効にする際に restrictNodeServerScheduling を設定するには、有効化コマンドに --param フラグを含めてください。

  ibmcloud oc cluster addon enable ibm-object-csi-driver --cluster CLUSTER --param "restrictNodeServerScheduling=true"
  

• アドオンがすでに有効になっている状態で「 restrictNodeServerScheduling 」を更新するには、以下の手順に従ってください。

1. クラスタ内のノードを一覧表示し、COS ドライバーのポッドを実行する場所を決定してください。

   oc get nodes
   

   出力例

   NAME            STATUS   ROLES    AGE    VERSION
   10.241.0.11     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.0.12     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.0.13     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.10   Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.11   Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.9    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.12    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.13    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.14    Ready    <none>   5d2h   v1.35.5+IKS
   

2. すべてのノードで、nodeserver ポッドが現在実行中であることを確認してください。

   oc get pods -n ibm-object-csi-operator -l app.kubernetes.io/component=node -o wide
   

   出力例

   NAME                        READY   STATUS    RESTARTS   AGE    IP              NODE            NOMINATED NODE   READINESS GATES
   ibm-object-csi-node-2pj2j   3/3     Running   0          145m   172.17.14.10    10.241.0.12     <none>           <none>
   ibm-object-csi-node-7bhwh   3/3     Running   0          145m   172.17.1.72     10.241.65.12    <none>           <none>
   ibm-object-csi-node-7l9hc   3/3     Running   0          145m   172.17.17.6     10.241.128.9    <none>           <none>
   ibm-object-csi-node-cxzt7   3/3     Running   0          145m   172.17.39.72    10.241.0.11     <none>           <none>
   ibm-object-csi-node-dw6qs   3/3     Running   0          145m   172.17.46.77    10.241.128.10   <none>           <none>
   ibm-object-csi-node-rpcvr   3/3     Running   0          145m   172.17.32.198   10.241.65.13    <none>           <none>
   ibm-object-csi-node-swqtg   3/3     Running   0          145m   172.17.16.69    10.241.0.13     <none>           <none>
   ibm-object-csi-node-sxbbs   3/3     Running   0          145m   172.17.26.7     10.241.65.14    <none>           <none>
   ibm-object-csi-node-xm8bt   3/3     Running   0          145m   172.17.20.200   10.241.128.11   <none>           <none>
   

3. ノードサーバーのポッドをスケジューリングしたいノードにラベルを付けます。

   oc label nodes NODE-NAME-1 NODE-NAME-2 cos.csi.ibm.io/csi-node=true
   

   出力例

   node/10.241.0.11 labeled
   node/10.241.0.12 labeled
   

4. ConfigMap を更新して、この制限を有効にしてください。

   oc patch cm managed-addon-ibm-object-csi-driver -n kube-system \
     --type merge -p '{"data":{"restrictNodeServerScheduling":"true"}}'
   

   出力例

   configmap/managed-addon-ibm-object-csi-driver patched
   

5. ノードサーバーのポッドが、ラベルが設定されたノードにのみスケジューリングされることを確認してください。

   oc get pods -n ibm-object-csi-operator -l app.kubernetes.io/component=node -o wide
   

   出力例

   NAME                        READY   STATUS    RESTARTS   AGE    IP             NODE           NOMINATED NODE   READINESS GATES
   ibm-object-csi-node-cxzt7   3/3     Running   0          145m   172.17.39.72   10.241.0.11    <none>           <none>
   ibm-object-csi-node-7bhwh   3/3     Running   0          145m   172.17.1.72    10.241.65.12   <none>           <none>
   

ノードごとの最大ボリューム数の設定

デフォルトでは、COS CSI ドライバーは、単一のノードにマウントできるボリュームの数に制限を設けていません。 maxVolumesPerNode パラメータを使用すると、ノードあたりのボリュームの最大数を設定できます。

maxVolumesPerNode の設定は、アドオンを有効にする際に設定するか、後で ConfigMap にパッチを適用して更新することができます。

• アドオンを有効にする際に maxVolumesPerNode を設定するには、有効化コマンドに --param フラグを含めてください。

  ibmcloud oc cluster addon enable ibm-object-csi-driver --cluster CLUSTER --param "maxVolumesPerNode=VALUE"
  

• アドオンがすでに有効になっている状態で「 maxVolumesPerNode 」を更新するには、管理対象アドオン「 ConfigMap 」にパッチを適用してください。

  oc patch cm managed-addon-ibm-object-csi-driver -n kube-system --type merge -p '{"data":{"maxVolumesPerNode":"VALUE"}}'
  

  出力例

  configmap/managed-addon-ibm-object-csi-driver patched
  

以下を使用するアプリのデプロイ IBM Cloud Object Storage

cos.csi.driver/secret: "<custom-secret>"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cos-secret-1 # Give your PVC the same name as the secret you created in the previous step.
  namespace: <namespace> # The namespace where you want to create the PVC.
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: <storage_class_name> # The storage class you want to use.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cos-csi-pvc1
  namespace: <namespace> # The namespace where you want to create the PVC.
  annotations:
    cos.csi.driver/secret: "<custom-secret>"
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 256Mi
  storageClassName: <storage_class_name> # The storage class you want to use.

IBM Cloud Object Storageアドオンを無効にする

既存のシークレット、PVC、およびデプロイは、アドオンを無効にしたり、パッチを更新したりしても削除されません。 既存のお客様ワークロードに支障をきたすことはない。

1. アドオンを無効にするには、次のコマンドを実行してください。

    ibmcloud oc cluster addon disable ibm-object-csi-driver --cluster CLUSTER
   

   出力例

   Data and resources that you created for the add-on might be deleted when the add-on is disabled. Continue? [y/N]> y
   Disabling add-on ibm-object-csi-driver for cluster XXX...
   OK
   

2. アドオンが削除されたことを確認してください。

   ibmcloud oc cluster addon ls --cluster CLUSTER
   

Helmプラグインからクラスタアドオンへの移行

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

2. PVCの詳細を取得し、移行するPVCを選択します。

   oc get pvc --all-namespaces -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' | tail -n +2 | while read namespace pvc; do kubectl describe pvc "$pvc" -n "$namespace" | grep 'volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs' > /dev/null ; if [ $? -eq 0 ]; then echo "PVC: $pvc in Namespace: $namespace uses ibm.io/ibmc-s3fs storage provisioner"; fi; done
   

   出力例

   PVC: pvc-test in Namespace: default uses ibm.io/ibmc-s3fs storage provisioner
   

3. PVCについて説明し、バケツ名を取得する。

   oc describe pvc <pvc_name> | grep ibm.io/bucket:
   

   出力例

   ibm.io/bucket: test-s3
   

4. バケツの名前も含めて、あなたの秘密を再現してください。

   apiVersion: v1
   kind: Secret
   type: cos-s3-csi-driver
   metadata:
       name: cos-secret-1 # Name your secret.
       namespace: <namespace> # Specify the namespace where you want to create the secret.
   data:
       accessKey: <base64-encoded-HMAC-access-key>
       secretKey: <base64-encoded-HMAC-secret-key>
   stringData:
       bucketName: <bucket-name>
       mountOptions: |
           # uid=3000  # Optional: Run as non-root user. Must match runAsUser in SecurityContext of pod spec.
           key1=value1
           key2=value2
   

5. PVCで使用されているストレージクラスを検索する。

   oc describe pvc <pvc_name> | grep StorageClass:
   

   test-s3 PVCに対するコマンド例。

   oc describe pvc test-s3 | grep StorageClass:
   

   出力例

   StorageClass:  ibmc-s3fs-smart-perf-regional
   

6. アドオンで使用できる 新しいストレージクラスを確認 し、置換クラスを選択します。

   • flex を使用していた場合は、新しい smart クラスのいずれかを選択してください。
   • standard を使用している場合は、新しい standard クラスのいずれかを選択してください。
   • cold と vault のクラスはアドオンでは利用できなくなりました。代わりに smart または standard のクラスを選択してください。

7. PVCの詳細を確認する。

   oc describe pvc test-s3
   

   出力例

   Name:          pvc-test
   Namespace:     default
   StorageClass:  ibmc-s3fs-smart-perf-regional
   Status:        Bound
   Volume:        pvc-c625474d-31f0-4929-bc3e-feace1fb42fb
   Labels:        <none>
   Annotations:   ibm.io/auto-create-bucket: true
               ibm.io/auto-delete-bucket: true
               ibm.io/bucket: bha-test-s23
               ibm.io/secret-name: satstoragesecret
               pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs
   Finalizers:    [kubernetes.io/pvc-protection]
   Capacity:      3Gi
   Access Modes:  RWO
   VolumeMode:    Filesystem
   Used By:       test-pod
   Events:        <none>
   

8. 新しいストレージ・クラスを使用し、以前に作成したシークレットを参照する置換PVCを作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
   name: cos-csi-pvc1
   namespace: <namespace> # The namespace where you want to create the PVC.
   annotations:
       cos.csi.driver/secret: "cos-secret-1"  # Secret created in step 4
   spec:
   accessModes:
   - ReadWriteOnce
   resources:
       requests:
       storage: 256Mi
   storageClassName: <storage_class_name> # The storage class you picked based on old storage class mapping.
   

9. PVCが Bound であることを確認する。

   oc get pvc
   

10. アプリの詳細を確認してください。

    oc get pods
    

11. アプリをゼロまで縮小する。

    kubectl scale deployment --replicas=0 my-app
    

12. 前の手順で作成した PVC を参照する置換配置を作成します。

13. 新しい配置が実行されたら、古い配置を削除できます。

14. 移行したい各PVCについて、これらの手順を繰り返してください。

IBM Cloud Object Storageクラスタ・アドオン・ストレージクラス

IBM Cloud Object Storage クラスタ・アドオンは、 s3fs および rclone マウンタ用のストレージ・クラスを提供します。 データ・アクセス要件に合ったストレージ・クラスを選択します。 ストレージクラスは、ワークロード用に作成されたバケットのバケットクラス、リクレイムポリシー、デフォルトのマウント動作を決定します。

Standard

頻繁にアクセスされる「ホットデータ」に使用します。 Web アプリやモバイル・アプリが一般的なユース・ケースです。

ボールト

月に1回以下など、アクセス頻度の低いワークロードや「クールデータ」に利用してください。 アーカイブ、短期データ保存、デジタル資産の保持、テープの交換、および災害復旧が一般的なユース・ケースです。

Cold

アクセス頻度が低い（90日に1回以下）データや、非アクティブなデータに使用します。 アーカイブ、長期バックアップ、コンプライアンスのために保持する履歴データ、またはめったにアクセスされないワークロードとアプリが一般的なユース・ケースです。

スマート

特定の使用パターンに従わないワークロードやデータ、あるいは使用パターンの予測が困難な場合に使用する。

バケットに格納されるデータの回復力のレベルを決定します。 詳細については、リージョンおよびエンドポイントを参照してください。

クロスリージョン

お客様のデータは、最高の可用性を確保するため、1つの地理的エリア内の3つのリージョンに分散して保存されます。 複数のリージョンに分散されたワークロードがある場合、要求は最も近いリージョンのエンドポイントにルーティングされます。 位置情報取得用の IBM Cloud Object Storage エンドポイントは、クラスターが置かれている場所に基づいて自動的に設定されます。 たとえば、クラスターが「 US South 」にある場合、ストレージクラスは、バケットに対して US GEO エンドポイントを使用するように設定されます。 名前に「 cross-region 」が含まれるストレージクラスを選択してください。

リージョン

お客様のデータは、1つのリージョン内の複数のゾーンに複製されます。 同じリージョンに複数のワークロードがある場合は、Cross-region のセットアップよりも待ち時間が低くなり、パフォーマンスが向上します。 リージョンのエンドポイントは、クラスターが配置されている場所に基づいて自動的に設定されます。 たとえば、クラスタが US South にある場合、ストレージクラスは、バケットのリージョンエンドポイントとして US South を使用するように設定されます。 名前に「 cross-region 」が含まれていないストレージクラスを選択してください。

ストレージクラスの詳細なバケット設定を確認するには、 oc describe storageclass <storageclass_name> または oc describe storageclass <storageclass_name> を実行します。