Container Service for Kubernetes:CPFS for Lingjun の動的にプロビジョニングされたボリュームの使用

事前準備

• 「CPFS for Lingjun の使用制限」をご参照ください。

• クラスターが以下の要件を満たしていることを確認します。

  • クラスターバージョン: 1.26 以降。クラスターをアップグレードするには、「クラスターの手動アップグレード」をご参照ください。

  • ノードのオペレーティングシステム: Alibaba Cloud Linux 3。

  • 以下のストレージコンポーネントがインストールされており、バージョン要件を満たしていること。

    バージョンを確認、インストール、またはコンポーネントをアップグレードするには、アドオン管理 ページに移動します。

    • CSI アドオン (csi-plugin および csi-provisioner): v1.33.1 以降。アップグレードするには、「CSI アドオンの管理」をご参照ください。

    • cnfs-nas-daemon アドオン: 0.1.2 以降。

      cnfs-nas-daemon の詳細を表示

      cnfs-nas-daemon アドオンは EFC プロセスを管理します。これはかなりのリソースを消費し、ストレージパフォーマンスに直接影響します。アドオン管理 ページでリソース構成を調整します。以下の推奨事項を使用してください。

      • CPU: CPU リクエストはノード帯域幅の合計に応じてスケーリングされます。メタデータ管理のために 1 Gb/s の帯域幅あたり 0.5 コア、さらに 1 コアを割り当てます。このルールを使用して CPU 設定を調整します。

        たとえば、100 Gb/s NIC を搭載したノードの場合、CPU リクエストを 100 * 0.5 + 1 = 51 コアに設定します。

      • メモリ: CPFS for Lingjun は FUSE を使用します。データ読み書きキャッシュとファイルメタデータはメモリを消費します。メモリリクエストをノードの総メモリの 15% に設定します。

      構成を調整した後、実際のワークロードに基づいてリソースを動的にスケールアップまたはスケールダウンします。

      重要

      • 更新動作: cnfs-nas-daemon DaemonSet は、デフォルトで OnDelete 更新戦略を使用します。アドオン管理 ページで CPU またはメモリ設定を変更した後、各ノード上の既存の cnfs-nas-daemon Pod を手動で削除して再構築をトリガーし、新しい設定を適用します。

        ビジネスの安定性を確保するために、この操作はオフピーク時間中に実行してください。

      • リスク: cnfs-nas-daemon Pod を削除または再起動すると、そのノードでの CPFS マウントが一時的に中断されます。

        • ホットアップグレードをサポートしないノード^①: これによりハードウェア割り込みが発生します。アプリケーション Pod は失敗し、手動削除が必要です。削除後、アプリケーション Pod は自動的に再起動して回復します。

        • ホットアップグレードをサポートするノード^①: cnfs-nas-daemon Pod の再起動後、アプリケーション Pod は自動的に回復します。

        ① ノードが以下のすべての条件を満たしている場合、ホットアップグレードをサポートします。

        • カーネルバージョンが 5.10.134-18 以降であること。

        • bmcpfs-csi-controller および bmcpfs-csi-plugin のバージョンが 1.35.1 以降であること。

        • cnfs-nas-daemon のバージョンが 0.1.9-compatible.1 以降であること。

    • bmcpfs-csi コンポーネント: 1.35.1 以降。

      これには、bmcpfs-csi-controller (コントロールプレーンコンポーネント、ACK によって管理) および bmcpfs-csi-node (ノードサイドコンポーネント、クラスターに DaemonSet としてデプロイ) が含まれます。

注意事項

• VSC マウントを使用する場合、Pod が実行されているノードは、CPFS for Lingjun ファイルシステムインスタンスと同じ hpn-zone に存在する必要があります。

• Lingjun ノードは、初期化中に CPFS for Lingjun ファイルシステムに関連付けられている必要があります。そうでない場合、CSI マウントは失敗します。

• 障害により Lingjun ノードをオフラインにする前に、そこからすべての Pod をドレインしてください。このステップをスキップすると、クラスターメタデータが一貫性のない状態になり、回復不能な Pod リソースが残されます。

• 単一の Pod で同じ CPFS for Lingjun ファイルシステムから複数のボリュームをマウントしないでください (たとえば、同じ bmcpfsId を含む StorageClass によって作成された複数の PV)。ネイティブプロトコルの制限により、同じ Pod が同じファイルシステムインスタンスを複数回マウントしようとすると (異なるサブディレクトリであっても)、予期せぬ動作につながります。

ステップ 1: CPFS ファイルシステムの作成

1. CPFS for Lingjun ファイルシステムを作成します。「CPFS for Lingjun ファイルシステムの作成」をご参照ください。ファイルシステム ID を記録します。

2. (オプション) Lingjun 以外のノードにマウントする場合は、VPC マウントターゲットを作成し (VPC マウントターゲットの作成)、マウントターゲットドメイン名を記録します。形式は cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com です。

   Pod が Lingjun ノードにスケジュールされる場合、VSC マウントがデフォルトで使用されます。このステップはスキップします。

ステップ 2: StorageClass の作成

StorageClass オブジェクトをストレージテンプレートとして作成します。

1. 以下の内容を使用して sc.yaml を作成できます。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: alicloud-bmcpfs-test
   provisioner: bmcpfsplugin.csi.alibabacloud.com
   parameters:
     # CPFS for Lingjun file system ID
     bmcpfsId: bmcpfs-29000z8xz3lf5nj*****  
     # Specify the subdirectory within the file system
     # path: "/shared"  
   # Allow subsequent expansion
   allowVolumeExpansion: true  
   # Delete (automatic cleanup) or Retain (keep data)
   reclaimPolicy: Delete  

   パラメーターの説明:

   パラメーター	必須	説明
   bmcpfsId	はい	BMCPFS ファイルシステム ID。形式は bmcpfs-xxxxxxxxx または cpfs-xxxxxxxxx です。
   path	いいえ	ファイルシステム内のサブディレクトリ。 指定されている場合: ボリュームは {path}/{volumeName}/ パスに作成されます。 指定されていない場合: ボリュームは /{volumeName}/ パスに作成されます。
   allowVolumeExpansion	いいえ	後で PVC を介した自動拡張を許可します。 現在のバージョンでは動的拡張はサポートされていません。これは予約済みパラメーターです。
   reclaimPolicy	いいえ	Delete (デフォルト): PVC を削除すると、バックエンドファイルシステム内のファイルセットが自動的に削除されます。 Retain: PVC を削除しても、バックエンドファイルシステム内のファイルセットは保持されます。手動でクリーンアップします。本番環境での使用を推奨します。

2. StorageClass を作成します。

   kubectl apply -f sc.yaml

ステップ 3: PVC の作成

アプリケーションは PVC を介してボリュームをリクエストし、StorageClass を構成テンプレートとして参照します。

1. 以下の内容を使用して pvc.yaml を作成できます。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: bmcpfs-vsc
     namespace: default
   spec:
     accessModes:
       # CPFS for Lingjun volumes support multiple pods reading and writing simultaneously
       - ReadWriteMany  
     resources:
       requests:
         # Supports large-capacity storage (Ti level)
         storage: 10Ti  
     # Only supports Filesystem
     volumeMode: Filesystem
     # Specify the StorageClass created earlier
     storageClassName: alicloud-bmcpfs-test

   パラメーターの説明:

   以下のパラメーターは必須です。

   パラメーター	説明
   accessModes	ReadWriteMany のみをサポートします。これは、複数の Pod が同時にマウントして読み書きできることを意味します。
   storage	リクエストされたストレージ容量。Gi や Ti などの単位をサポートします。
   volumeMode	Filesystem のみをサポートします。
   storageClassName	使用する StorageClass を指定し、動的ボリューム作成をトリガーします。

2. PVC を作成します。

   kubectl apply -f pvc.yaml

3. 以下のコマンドを実行して PVC ステータスを確認できます。

   • kubectl get pvc bmcpfs-vsc -n default を実行して PVC ステータスを表示します。STATUS が Bound の場合、システムが対応する PV を自動的に作成したことを示します。

   • kubectl describe pvc bmcpfs-vsc -n default を実行し、Events に Provisioning succeeded メッセージがあることを確認します。

ステップ 4: ワークロードの作成と PVC のマウント

PVC 作成後、サンプルワークロードをデプロイし、PVC にバインドされた PV をアプリケーションにマウントできます。

1. 以下の内容を使用して deploy.yaml を作成できます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: cpfs-shared-example
   spec:
     # Create 3 replicas to verify shared storage for multiple pods
     replicas: 3
     selector:
       matchLabels:
         app: cpfs-shared-app
     template:
       metadata:
         labels:
           app: cpfs-shared-app
       spec:
         # Ensure the pod can be scheduled to a Lingjun node
         tolerations:
           - key: node-role.alibabacloud.com/lingjun
             operator: Exists
             effect: NoSchedule
         # Optional: To schedule all pods to a specific node, uncomment this line and modify the node name
         # nodeName: cn-hangzhou.10.XX.XX.226
         containers:
         - name: app-container
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
           volumeMounts:
             - name: pvc-cpfs
               # Mount the shared volume to the /data directory inside the container
               mountPath: /data
           # Simple lifecycle command to verify data writing and sharing
           # After the pod starts, it writes a file containing its hostname to the shared directory
           lifecycle:
             postStart:
               exec:
                 command:
                   - /bin/sh
                   - -c
                   - >
                     echo "Data written by $(hostname)" > /data/$(hostname).txt && 
                     echo "Deployment is running, check shared data in /data." && 
                     sleep 3600
         volumes:
           - name: pvc-cpfs
             persistentVolumeClaim:
               # Reference the PVC created earlier
               claimName: bmcpfs-vsc

2. Deployment を作成します。

   kubectl apply -f deploy.yaml

リソース解放ガイド

予期せぬコストを回避し、データセキュリティを確保するために、以下の手順に従って未使用のリソースを解放します。

1. ワークロードの削除

   • 操作: 関連する PVC を使用しているすべてのアプリケーション (Deployment や StatefulSet など) を削除して、アプリケーションを停止し、ボリュームをアンマウントします。

   • コマンド例: kubectl delete deployment <your-deployment-name>

2. PVC の削除

   • 操作: アプリケーションに関連付けられた PVC を削除します。バックエンドデータの処理は、StorageClass のリクレームポリシー (reclaimPolicy) によって異なります。

     • Retain (推奨): PVC を削除しても、バックエンドの CPFS for Lingjun ファイルセットとそのデータはそのまま残ります。

     • Delete: PVC を削除すると、バインドされた PV とバックエンドの CPFS for Lingjun ファイルセットが完全に削除されます。この操作は元に戻せません。注意して使用してください。

   • コマンド例: kubectl delete pvc <your-pvc-name>

3. PV の削除 (リクレームポリシーが Retain の場合)

   • 操作: リクレームポリシーが Retain の場合、PVC を削除した後、PV は Released ステータスに変わります。手動で PV を削除する必要があります。この操作は Kubernetes 内のリソース定義を削除するだけであり、バックエンドデータには影響しません。

   • コマンド例: kubectl delete pv <your-pv-name>

4. StorageClass の削除 (オプション)

   • 操作: このストレージクラスが不要になった場合、StorageClass を削除できます。この操作はすでに作成されたボリュームには影響しません。

   • コマンド例: kubectl delete sc <your-sc-name>

5. バックエンドの CPFS for Lingjun ファイルシステムの削除

   • 操作: この操作は、ファイルシステム上のすべてのデータ (Retain ポリシーによって保持されたデータを含む) を完全に削除し、回復できません。実行する前に、ファイルシステムにビジネス依存関係がないことを確認します。詳細については、「ファイルシステムの削除」をご参照ください。

よくある質問