Container Service for Kubernetes:静的にプロビジョニングされた CPFS for LINGJUN ボリュームを使用する

仕組み

Container Storage Interface (CSI) コンポーネントに基づいて、ACK は PV と永続ボリューム要求 (PVC) を使用して、ワークロードが静的にプロビジョニングされた CPFS for Lingjun ボリュームをマウントできるようにします。CSI コンポーネントは、Pod がスケジュールされるノードタイプに基づいて、最適なマウントメソッドを自動的に選択します。

• Virtual Storage Channel (VSC) マウント: Lingjun ノード専用で使用されます。このメソッドでは、CPFS for Lingjun と Lingjun サービスの両方への許可リストアクセスが必要です。このメソッドを使用するには、チケットを送信してください。

• Virtual Private Cloud (VPC) マウント: 他のすべてのノードタイプで使用されます。このメソッドでは、ファイルシステム用に VPC マウントポイントを作成する必要があり、同じ VPC 内の任意のノードがマウントしてアクセスできるようになります。

前提条件

• CPFS for Lingjun の制限について精通していること。

• クラスターが Kubernetes バージョン 1.26 以降を実行していること。必要に応じてクラスターをアップグレードしてください。

• 次のストレージコンポーネントがクラスターにインストールされており、最小バージョン要件を満たしていること。

  クラスターの [アドオン] ページで、コンポーネントのバージョンを確認し、コンポーネントをインストールまたは更新できます。

  • CSI コンポーネント (csi-plugin および csi-provisioner): csi-plugin のバージョンが 1.33.1 以降であること。必要に応じて csi-plugin を更新してください。

  • cnfs-nas-daemon: バージョンが 0.1.2 以降であること。

    説明

    • cnfs-nas-daemon コンポーネントは Elastic Fabric Controller (EFC) プロセスを管理し、リソースを大量に消費する可能性があります。そのリソース消費量は、期待されるストレージパフォーマンスに直接関係します。次のガイドラインとワークロードのパフォーマンスおよび実際のメモリ消費量に基づいて、[アドオン] ページでこのコンポーネントのリソース割り当てを調整してください。

      • CPU: cnfs-nas-daemon Pod の CPU 要件は、ノードの合計ネットワーク帯域幅によって決まります。帯域幅 1 Gbps ごとに 0.5 CPU コアが必要で、メタデータ管理には 1 CPU コアが必要です。この数式に従って CPU リクエストと制限を構成します。

      • メモリ: CPFS for Lingjun は、データキャッシングとファイルメタデータにシステムメモリを使用する Filesystem in Userspace (FUSE) を介してアクセスされます。ノードの合計メモリの約 15% を cnfs-nas-daemon Pod に割り当てることをお勧めします。

    • cnfs-nas-daemon DaemonSet のデフォルトの更新戦略は OnDelete です。CPU またはメモリ構成への変更を適用するには、各ノード上の既存の cnfs-nas-daemon Pod を手動で削除する必要があります。その後、Kubernetes は新しいリソース設定でそれらを自動的に再作成します。

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

重要な考慮事項

• VSC マウントを使用する場合、Pod は CPFS for Lingjun ファイルシステムと同じ hpn-zone にある Lingjun ノードにスケジュールする必要があります。

• Lingjun ノードは、初期化中に CPFS for Lingjun ファイルシステムに関連付ける必要があります。そうしないと、CSI コンポーネントを使用してファイルシステムをマウントすることはできません。

• 障害のために Lingjun ノードをオフラインにする前に、まずノードから Pod をドレインする必要があります。これを行わないと、クラスターのメタデータに不整合が生じ、適切にガベージコレクションできない孤立した Pod リソースが残ってしまいます。

• 同じ CPFS ファイルシステムの複数のサブディレクトリを、単一の Pod 内で個別の PV としてマウントしないでください。基盤となるドライバーの制限により、Pod のマウントと起動が失敗します。代わりに、PV と PVC を 1 つだけ作成して、CPFS ボリューム全体を一度マウントします。次に、Pod の volumeMounts 構成で、subPath フィールドを使用して、必要なサブディレクトリを個別にマウントします。

  subPath 機能は、軽量の bind mount メカニズムに基づいて実装されており、余分なパフォーマンスオーバーヘッドは発生しません。

ステップ 1: CPFS ファイルシステムを作成する

1. CPFS for Lingjun ファイルシステムを作成するの手順に従ってファイルシステムを作成します。ファイルシステム ID を記録します。

2. (オプション) 非 Lingjun ノードにファイルシステムをマウントするには、クラスターノードと同じ VPC に VPC マウントポイントを作成します。マウントポイントのドメインを記録します。ドメインフォーマットは cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com です。

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

ステップ 2: PV と PVC を作成する

1. 次の内容で bmcpfs-pv-pvc.yaml という名前のファイルを作成します。

   • volumeHandle の値をファイルシステム ID に置き換えます。

   • VPC マウントポイントを使用する場合は、vpcMountTarget の値をマウントポイントドメインに置き換えます。Lingjun ノードのみを使用している場合は、このフィールドを省略します。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: bmcpfs
   spec:
     accessModes:
     - ReadWriteMany
     capacity:
       storage: 10Ti
     claimRef:
       name: bmcpfs
       namespace: default
     csi:
       driver: bmcpfsplugin.csi.alibabacloud.com
       volumeAttributes:
          # このフィールドは、Pod が非 Lingjun ノードにスケジュールされている場合に必要です。Lingjun のみのクラスターの場合は省略します。
         vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
       # volumeHandle をファイルシステム ID に置き換えます。
       volumeHandle: bmcpfs-*****
     mountOptions: []
   
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: bmcpfs
     namespace: default
   spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 10Ti
     volumeMode: Filesystem
     volumeName: bmcpfs

   • PV パラメータ

     パラメーター	説明
     accessModes	PV のアクセスモード。
     capacity.storage	ボリュームの宣言された容量。これは宣言のみであり、実際の容量には影響しません。
     csi.driver	ドライバーのタイプ。CPFS for Lingjun ファイルシステムをマウントする場合は、これを bmcpfsplugin.csi.alibabacloud.com に設定します。
     csi.volumeAttributes.vpcMountTarget	CPFS ファイルシステムの VPC マウントポイントのドメイン名。空のままにすると、非 Lingjun ノードでのマウントが失敗します。 Pod が Lingjun ノードにスケジュールされている場合は、このパラメーターを省略します。
     csi.volumeHandle	CPFS ファイルシステムの ID。
     mountOptions	マウントパラメータ。

   • PVC パラメータ

     パラメータ	説明
     accessModes	PVC が PV に要求するアクセスモード。これは PV のアクセスモードと一致する必要があります。
     resources.requests.storage	Pod に割り当てられるストレージ容量。これは PV の容量より大きくすることはできません。
     volumeMode	マウントモード。これを Filesystem に設定します。
     volumeName	PVC がアタッチされる PV の名前。

2. マニフェストを適用して PV と PVC を作成します。

   kubectl apply -f bmcpfs-pv-pvc.yaml

3. PVC が PV にバインドされていることを確認します。

   kubectl get pvc bmcpfs

   予期される出力:

   NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   bmcpfs   Bound    bmcpfs   10Ti       RWX                           <unset>                 51s

   STATUS は Bound である必要があります。

ステップ 3: アプリケーションで CPFS ファイルシステムをマウントする