Container Service for Kubernetes:Lingjun 向け CPFS の静的永続ボリュームの使用

機能紹介

ACK は、Container Storage Interface (CSI) コンポーネントに基づいて、PV と PersistentVolumeClaim (PVC) を使用して、CPFS for Lingjun の静的 PV をワークロードにアタッチすることをサポートします。CSI は、Pod がスケジュールされるノードタイプに基づいて、最適なマウント方法を自動的に選択します。

• VSC マウント：このマウント方法は Lingjun ノードでのみサポートされています。この機能を有効にするには、チケットを送信して、CPFS および Lingjun プロダクトチームにホワイトリストへの追加を依頼する必要があります。

• VPC マウント：このマウント方法は Lingjun 以外のノードでサポートされています。VPC マウントポイントを作成することで実現され、同じ VPC 内のすべてのノードがファイルシステムをマウントしてアクセスできるようになります。

前提条件

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

• クラスターが次の要件を満たしていること：

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

  • ノードのオペレーティングシステム：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 は Filesystem in Userspace (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 コンポーネント：このコンポーネントには、ACK によって管理されるコントロールプレーンコンポーネントである bmcpfs-csi-controller と、クラスターに DaemonSet としてデプロイされるノード側コンポーネントである bmcpfs-csi-node が含まれます。

注意事項

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

• 初期化中に、Lingjun ノードは CPFS for Lingjun インスタンスに関連付けられている必要があります。そうでない場合、インスタンスは CSI を使用してマウントできません。

• 障害が発生した Lingjun ノードをオフラインにする前に、まず Pod をドレインする必要があります。そうしないと、クラスターのメタデータに不整合が生じ、Pod リソースが残ってしまい、回収できなくなります。

• 同じ Pod 内で複数の PV を使用して、同じ CPFS インスタンスから異なるサブディレクトリをマウントすることはサポートされていません。基盤となるドライバーの制限により、この構成では Pod のマウントと起動に失敗します。

  CPFS インスタンスに対しては 1 つの PV/PVC のみを作成できます。その後、Pod の volumeMounts 構成で subPath フィールドを使用して、必要なサブディレクトリを個別にマウントできます。

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

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

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

2. (オプション) Lingjun 以外のノードからマウントするには、クラスターノードと同じ VPC に VPC マウントポイントを作成し、マウントポイントのドメイン名を記録します。ドメイン名は cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com の形式です。

   Pod が Lingjun ノードにスケジュールされる場合、デフォルトで VSC マウントが使用されます。この場合、この手順は不要です。

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

1. 既存の CPFS ファイルシステムに基づいて PV と PVC を作成できます。

   1. 次の YAML サンプルを修正し、bmcpfs-pv-pvc.yaml として保存します。

      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 以外のノードにスケジュールされる場合、またはクロスドメインの自動 VPC スイッチオーバーが有効になっている場合に必須です。そうでない場合、マウントは失敗します。
            vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
            # Pod が現在の bmcpfs とは異なるゾーンのノードにスケジュールされた場合、vpcMountTarget マウントポイントが自動的に使用され、CPFS ストレージにアクセスします。
            mountpointAutoSwitch: "true"
          # volumeHandle を CPFS for Lingjun ファイルシステムの 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.volumeAttributes.mountpointAutoSwitch	bmcpfs が VSC マウントポイント (デフォルトで作成および取得) と VPC マウントポイント (指定が必要) を自動的に切り替えることを許可するかどうかを指定します。 csi.volumeAttributes.vpcMountTarget と組み合わせて使用します。
        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

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

   kubectl get pvc bmcpfs

   予期される出力:

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

   STATUS が Bound であることは、PV と PVC が正常にバインドされたことを示します。

手順3：アプリケーションを作成し、CPFS をマウントする