ACK クラスターでの CPFS for Lingjun 静的プロビジョニングボリュームの使用 - Container Service for Kubernetes

Cloud Parallel File System (CPFS) for Lingjun は、エンドツーエンドのリモートダイレクトメモリアクセス (RDMA) ネットワーク高速化により、高スループットかつ高 IOPS のパフォーマンスを実現し、AI 生成コンテンツ (AIGC) や自動運転などの AI およびコンピューティング集約型シナリオに最適です。Container Service for Kubernetes (ACK) では、CPFS for Lingjun ファイルシステムを静的にプロビジョニングされた永続ボリューム (PV) としてマウントできます。

重要

CPFS for Lingjun は招待プレビュー段階であり、特定のリージョンおよびゾーンでのみ利用可能です。アクセスをご希望の場合は、アカウントマネージャーまでお問い合わせください。

マウント方法の選択

Container Storage Interface (CSI) をベースとして、ACK では CPFS for Lingjun ファイルシステムを静的にプロビジョニングされた PV および永続ボリューム要求 (PVC) としてマウントできます。CSI アドオンは、ポッドが配置されるノードのタイプに基づき、最適なマウント方法を自動的に選択します。

マウント方法	対応ノード	要件
仮想ストレージチャネル (VSC)	Lingjun ノードのみ	チケットを送信して、CPFS および Lingjun プロダクトチーム両方にホワイトリストへのアクセスを依頼する必要があります。
VPC	非 Lingjun ノード	クラスターノードと同じ VPC 内に VPC マウントポイントを作成する必要があります。

作業を開始する前に、ご利用のクラスターに該当するパスを確認してください。

ポッドが Lingjun ノード 上で実行される場合 — デフォルトで VSC マウントを使用します。VPC マウントポイントの作成は不要です。
ポッドが 非 Lingjun ノード 上で実行される場合 — VPC マウントが必要です。手順 1 で VPC マウントポイントを作成してください。
ポッドが 両方のノードタイプ 上で実行される場合 — PV に vpcMountTarget および mountpointAutoSwitch: "true" の両方を設定してください。CSI アドオンが自動的に切り替えます。

前提条件

作業を開始する前に、以下の項目を確認してください。

CPFS for Lingjun の制限事項をご確認ください。
Kubernetes 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 アドオンは Elastic File Client (EFC) プロセスを管理し、大量のリソースを消費するため、ストレージパフォーマンスに直接影響します。アドオン管理 ページでリソースを調整してください。
  - CPU：ノードの合計帯域幅に依存します。推奨値：帯域幅 1 Gbps あたり 0.5 コア、メタデータ管理用に追加で 1 コア。
    
    例：帯域幅 100 Gbps のノードの場合、CPU リクエストは 100 × 0.5 + 1 = 51 コアです。
  - メモリ： CPFS for Lingjun は Filesystem in USErspace (FUSE) を使用するため、読み取り/書き込みキャッシュおよびメタデータがメモリを消費します。リクエスト値をノードの合計メモリの 15% に設定してください。
  ワークロードに応じて、必要に応じて調整してください。
  重要
  
  更新時の動作： cnfs-nas-daemon はデフォルトで OnDelete 更新戦略を使用します。アドオン管理 ページで CPU またはメモリを調整した後は、新しい構成で再作成するために、各ノード上の cnfs-nas-daemon ポッドを手動で削除してください。オフピーク時間帯に実施することを推奨します。
  
  中断リスク： cnfs-nas-daemon ポッドを削除または再起動すると、そのノード上の CPFS マウントサービスが一時的に中断されます。
  
  ホットアップグレード未対応のノード^①：アプリケーションポッドが失敗するハード中断が発生します。サービスを復旧させるには、アプリケーションポッドを手動で削除して再起動してください。
  
  ホットアップグレード対応のノード^①： cnfs-nas-daemon が再起動した後、アプリケーションポッドが自動的に回復します。
  
  ①：ノードが以下のすべての条件を満たす場合、ホットアップグレードに対応しています。
  
  ノードのカーネルバージョンが 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 マウントゾーン：ポッドを実行するノードは、CPFS for Lingjun ファイルシステムインスタンスと同じ hpn-zone 内にある必要があります。
ノード初期化： Lingjun ノードは、初期化時に CPFS for Lingjun ファイルシステムに関連付けられている必要があります。関連付けられていない場合、CSI マウントは失敗します。
ノードのドレイン：不具合のある Lingjun ノードを廃棄する前に、そのノードからすべてのポッドをドレインしてください。この手順を省略すると、クラスターメタデータが不整合となり、孤立したポッドリソースがクリーンアップできなくなります。
CPFS インスタンスあたり 1 つの PV：同じ CPFS ファイルシステムの複数のサブディレクトリを個別の PV として 1 つのポッドにマウントすることはサポートされていません。ドライバーの制限により、ポッドの起動に失敗します。1 つの PV/PVC を作成し、volumeMounts.subPath を使用してサブディレクトリをマウントしてください。subPath はパフォーマンスオーバーヘッドのない軽量な bind mount を使用します。

手順 1： CPFS ファイルシステムの作成

CPFS for Lingjun ファイルシステムを作成し、ファイルシステム ID を記録します。
（任意）非 Lingjun ノードの場合、クラスターノードと同じ VPC 内に VPC マウントポイントを作成し、マウントポイントのドメイン名 を記録します。形式：cpfs-*-vpc-*.<Region>.cpfs.aliyuncs.com。

ポッドが Lingjun ノード上で実行される場合（デフォルトで VSC マウント）は、この手順は不要です。

手順 2： PV および PVC の作成

以下のテンプレートを bmcpfs-pv-pvc.yaml として保存し、プレースホルダーをファイルシステム ID および（必要に応じて）VPC マウントポイントに置き換えます。

PV パラメーター

パラメーター	説明	必須
`accessModes`	PV のアクセスモード。	はい
`capacity.storage`	宣言されたストレージ容量。実際の容量には影響しません。	はい
`csi.driver`	ドライバーの種類。CPFS for Lingjun の場合は `bmcpfsplugin.csi.alibabacloud.com` を使用します。	はい
`csi.volumeHandle`	CPFS for Lingjun ファイルシステムの ID。	はい
`csi.volumeAttributes.vpcMountTarget`	VPC マウントポイントのドメイン名。非 Lingjun ノードでは必須です。ポッドが Lingjun ノードにのみスケジュールされる場合は省略します。	条件付き
`csi.volumeAttributes.mountpointAutoSwitch`	VSC と VPC マウントポイント間の自動切り替えを有効にします。`vpcMountTarget` と共に使用します。	いいえ
`mountOptions`	マウントオプション。	いいえ

PVC パラメーター

パラメーター	説明	必須
`accessModes`	PVC が要求するアクセスモード。PV と一致している必要があります。	はい
`resources.requests.storage`	ポッドに割り当てられるストレージ容量。PV 容量を超えてはいけません。	はい
`volumeMode`	マウントモード。`Filesystem` に設定します。	はい
`volumeName`	この PVC にバインドする PV の名前。	はい

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:
      # ポッドが非 Lingjun ノードにスケジュールされる場合、またはゾーン間の自動 VPC 切り替えが有効な場合は必須。
      # ポッドが Lingjun ノードにのみスケジュールされる場合は省略。
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
      # VSC と VPC マウントポイント間の自動切り替えを有効にします。
      # vpcMountTarget と共に使用します。
      mountpointAutoSwitch: "true"
    # ご利用の 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

構成を適用します。
```
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 であるため、PVC が PV にバインドされていることが確認できます。

手順 3：ワークロードのデプロイ

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

すべてのコンテナが CPFS ファイルシステムへのフルアクセスを必要とする場合に、この方法を使用します。

以下の YAML テンプレートを cpfs-test.yaml として保存します。

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

デプロイメントを作成します。
```
kubectl create -f cpfs-test.yaml
```

両方のポッドが実行中であることを確認します。

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

ポッド内で CPFS ボリュームのマウントを確認します。
```
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)
```
fuse.aliyun-alinas-efc タイプで /data にマウントされているため、CPFS ボリュームがマウントされていることが確認できます。

シナリオ 2：データ隔離のためのサブディレクトリのマウント

マルチテナントやマルチタスキングなどの共有ストレージシナリオでは、複数のコンテナが 1 つの CPFS ボリュームを共有しながら、別々のディレクトリでデータを隔離できます。同じ PVC から異なるコンテナに異なるサブディレクトリをマウントするには、volumeMounts.subPath を使用します。

subPath ディレクトリ（例：workspace/alpha）が存在しない場合、自動的に作成されます。

以下の YAML テンプレートを pod.yaml として保存します。このポッドは 2 つのコンテナを実行し、それぞれが同じ PVC（bmcpfs）の異なるサブディレクトリをマウントします。

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 を参照

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