ACK クラスターにおける CPFS for Lingjun の静的永続ボリュームの使用 - Container Service for Kubernetes

CPFS for Lingjun は、高スループットと高 IOPS パフォーマンスを提供します。エンドツーエンドの RDMA ネットワークアクセラレーションをサポートし、AIGC や自動運転などのインテリジェントコンピューティングシナリオに最適です。Container Service for Kubernetes (ACK) を使用すると、CPFS for Lingjun ファイルシステムをワークロード用の静的永続ボリューム (PV) としてマウントできます。

重要

CPFS for Lingjun は現在、招待プレビュー段階です。一部のリージョンとゾーンでのみ利用可能です。ご利用には、アカウントマネージャーに連絡してアクセスをリクエストしてください。

機能紹介

CSI アドオンを使用して、ACK は PV と PVC を介して CPFS for Lingjun の静的永続ボリュームをワークロードにマウントします。CSI アドオンは、Pod がスケジュールされるノードの種類に基づいて、最適なマウント方法を自動的に選択します。

VSC マウント：Lingjun ノードでのみサポートされます。ホワイトリストを有効にするには、CPFS プロダクトと Lingjun プロダクトの両方にチケットを送信する必要があります。
VPC マウント：Lingjun 以外のノードでサポートされます。マウントを有効にするには、VPC マウントポイントを作成します。同じ VPC 内のノードはすべて、ファイルシステムをマウントしてアクセスできます。

前提条件

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 アドオン：bmcpfs-csi-controller (ACK が管理するコントロールプレーンコンポーネント) と bmcpfs-csi-node (クラスターに DaemonSet としてデプロイされるノード側コンポーネント) が含まれます。

注意事項

VSC マウントを使用する場合、Pod を実行しているノードは、CPFS for Lingjun ファイルシステムインスタンスと同じ hpn-zone にある必要があります。
Lingjun ノードは、初期化時に CPFS for Lingjun ファイルシステムと関連付ける必要があります。そうしないと、CSI マウントが失敗します。
障害により Lingjun ノードをオフラインにする前に、そのノードからすべての Pod をドレインしてください。このステップを省略すると、クラスターのメタデータに不整合が生じ、回復不能な Pod リソースが残ってしまいます。
複数の PV を使用して、同じ CPFS インスタンスの異なるサブディレクトリを 1 つの Pod にマウントすることはできません。ドライバーの制限により、この構成では Pod のマウントが失敗し、Pod が起動できなくなります。

代わりに、CPFS インスタンス用に 1 つの PV/PVC を作成します。次に、Pod 仕様の volumeMounts 構成を使用し、subPath フィールドを設定して、必要なサブディレクトリをマウントします。

subPath フィールドは軽量な bind mount メカニズムを使用します。パフォーマンスのオーバーヘッドは発生しません。

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

CPFS for Lingjun ファイルシステムを作成します。詳細については、「CPFS for Lingjun ファイルシステムの作成」をご参照ください。ファイルシステム ID を記録しておきます。
(オプション) Lingjun 以外のノードにマウントする場合は、VPC マウントポイントを作成し (ご利用のクラスターノードと同じ VPC 内)、マウントポイントのドメイン名を記録します。フォーマットは cpfs-***-vpc-***.<リージョン>.cpfs.aliyuncs.com です。

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

ステップ 2：PV と PVC の作成

既存の CPFS ファイルシステム用に PV と PVC を作成します。

以下の 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 と一致する必要があります。
`resources.requests.storage`	Pod に割り当てられるストレージ容量。PV の容量を超えてはなりません。
`volumeMode`	マウントモード。 `Filesystem` に設定します。
`volumeName`	この PVC にバインドする PV の名前。

PV と PVC を作成します。
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

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 のマウント

シナリオ 1：CPFS ファイルシステム全体のマウント

このシナリオでは、CPFS ファイルシステム全体をコンテナにマウントします。

以下の YAML を使用して、cpfs-test.yaml という名前のファイルを作成します。これは、CPFS for Lingjun の静的永続ボリュームをマウントする Deployment を宣言します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpfs-test
  labels:
    app: cpfs-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cpfs-test
  template:
    metadata:
      labels:
        app: cpfs-test
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-cpfs
            mountPath: /data
      volumes:
        - name: pvc-cpfs
          persistentVolumeClaim:
            claimName: bmcpfs

Deployment を作成します。
```
kubectl create -f cpfs-test.yaml
```

Pod のデプロイ状況を確認します。

kubectl get pod -l app=cpfs-test

期待される出力：

NAME                         READY   STATUS    RESTARTS   AGE
cpfs-test-76b77d64b5-2hw96   1/1     Running   0          42s
cpfs-test-76b77d64b5-dnwdx   1/1     Running   0          42s

いずれかの Pod に入り、CPFS for Lingjun の静的永続ボリュームが正常にマウントされたことを確認します。

kubectl exec -it <pod-name> -- mount | grep /data

期待される出力は、マウントが成功したことを示します。

bindroot-f0a5c-******:cpfs-*******-vpc-****.cn-shanghai.cpfs.aliyuncs.com:/ on /data type fuse.aliyun-alinas-efc (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=1048576)

シナリオ 2：CPFS ファイルシステムのサブディレクトリのマウント

マルチテナントやマルチタスキングのセットアップなどの共有ストレージシナリオでは、複数のアプリケーション Pod で 1 つの CPFS ボリュームを共有しつつ、データを別々のディレクトリに隔離することができます。これには volumeMounts.subPath フィールドを使用します。

以下の内容で pod.yaml という名前のファイルを作成します。この Pod は 2 つのコンテナを実行します。それぞれが subPath を使用して、同じ PVC (bmcpfs) の異なるサブディレクトリをマウントします。

subPath ディレクトリ (例：workspace/alpha) が CPFS ファイルシステムに存在しない場合、システムはそれを自動的に作成します。

apiVersion: v1
kind: Pod
metadata:
  name: cpfs-subpath-demo-pod
spec:
  containers:
    - name: task-alpha-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace # コンテナ内のマウントパス
          subPath: workspace/alpha   # ボリューム全体ではなく、workspace/alpha サブディレクトリをマウント

    - name: task-beta-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace # マウントパスは同じでもよい
          subPath: workspace/beta    # ボリューム全体ではなく、workspace/beta サブディレクトリをマウント
  volumes:
    - name: cpfs-storage
      persistentVolumeClaim:
        claimName: bmcpfs # 先に作成した PVC を参照

Pod をデプロイします。
```
kubectl apply -f pod.yaml
```
task-alpha コンテナのマウントと書き込みアクセスの確認
1. task-alpha コンテナに接続します。
```
kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh
```
2. マウントされたファイルシステムをチェックして、CPFS ボリュームが存在することを確認します。
```
df -h
```
  期待される出力は、共有ディレクトリ (/share) がコンテナ内の /data/workspace にマウントされていることを示します。
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
3. マウントポイントの親ディレクトリ構造を確認します。
```
ls -l /data/
```
  期待される出力は、workspace サブディレクトリが /data の下に存在することを示します。
```
total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace
```
4. マウントされたディレクトリにファイルを作成して、書き込みアクセスをテストします。
```
echo "hello from alpha" > /data/workspace/alpha.log
exit
```
task-beta コンテナのマウントとデータ隔離の確認
1. task-beta コンテナに接続します。
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
2. コンテナのマウントポイント (/data/workspace) にファイルを作成します。
```
echo "hello from beta" > /data/workspace/beta.log
```
3. /data/workspace/ 内のファイルを一覧表示します。
```
ls -l /data/workspace/
```
  期待される出力は、beta.log が正常に書き込まれ、alpha.log が存在しないことを示します。データはコンテナ間で隔離されています。
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```