動的ボリュームを使用すると、手動で PV を管理することなく、オンデマンドで CPFS for Lingjun ストレージをプロビジョニングできます。複数のアプリケーションが並行して読み書きできるため、コード、設定ファイル、中間計算結果を共有する必要がある AI トレーニングやビッグデータ分析のワークロードに適しています。
制限事項
これらの制限事項に違反すると、マウントの失敗やクラスターが回復不能な状態に陥ることがあります。
VSC マウントには同じ hpn-zone が必要:Pod が配置されるノードは、CPFS for Lingjun ファイルシステムと同じ hpn-zone にある必要があります。
ノードの初期化:Lingjun ノードは、初期化時に CPFS for Lingjun ファイルシステムに関連付ける必要があります。これを省略すると、CSI のマウントに失敗します。
Pod ごとに 1 つのファイルシステム:1 つの Pod に同じ CPFS for Lingjun ファイルシステムから複数のボリューム (例:同じ
bmcpfsIdを持つ複数の PV) をマウントしないでください。ネイティブプロトコルは、異なるサブディレクトリであっても、同じファイルシステムを 1 つの Pod に複数回マウントすることをサポートしていません。ノードをオフラインにする前のドレイン:障害が発生した Lingjun ノードをオフラインにする前に、すべての Pod をドレインしてください。これを省略すると、回復不能な Pod リソースが残り、クラスターメタデータに不整合が生じます。
前提条件
以下の要件を満たしていることを確認してください。
クラスターバージョンが 1.26 以降であること (アップグレードガイド)。
ノードで Alibaba Cloud Linux 3 が実行されていること。
以下のストレージアドオンを、[アドオン] ページで最小バージョンでインストールまたはアップグレードしてください。
コンポーネント
最小バージョン
CSI アドオン (csi-plugin および csi-provisioner)
v1.33.1
0.1.2
bmcpfs-csi アドオン (Container Service for Kubernetes (ACK) のマネージドコントロールプレーン上の bmcpfs-csi-controller と、クラスターノードに DaemonSet としてデプロイされる bmcpfs-csi-node)
1.35.1
cnfs-nas-daemon のリソース設定
cnfs-nas-daemon は Elastic File Client (EFC) プロセスを管理し、ストレージパフォーマンスに直接影響します。そのリソースは [アドオン] ページで設定します。
CPU:帯域幅 1 Gb/s あたり 0.5 コア、さらにメタデータ管理用に 1 コア。例:100 Gb/s NIC →
100 × 0.5 + 1 = 51コア。メモリ:ノードの合計メモリの 15%。CPFS for Lingjun は FUSE を使用するため、データキャッシングとファイルメタデータの両方がメモリを消費します。
実際のワークロードに基づいてリソース制限を微調整してください。
cnfs-nas-daemon は OnDelete 更新ストラテジーを使用します。[アドオン] ページで設定を変更した後、変更を適用するには、各ノード上の 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+ が必要です。
手順1:CPFS ファイルシステムの作成
CPFS for Lingjun ファイルシステムを作成し、ファイルシステム ID を記録します。
(オプション) Lingjun 以外のノードにマウントするには、クラスターノードと同じ VPC 内に VPC マウントターゲットを作成します。マウントターゲットのドメイン名 (フォーマット:
cpfs-*-vpc-*.<Region>.cpfs.aliyuncs.com) を記録します。すべての Pod が Lingjun ノードで実行される場合、デフォルトで VSC (Virtual Storage Controller) マウントが適用されます。この手順はスキップしてください。
続行する前に、「CPFS for Lingjun の制限事項」を確認してください。
手順2:StorageClass の作成
StorageClass は、ファイルシステム ID や reclaim ポリシーなどのプロビジョニングパラメーターを定義します。
sc.yamlを作成します:パラメーター
必須
説明
bmcpfsIdはい
LINGJUN 向け CPFS ファイルシステム ID。形式:
bmcpfs-xxxxxxxxxまたはcpfs-xxxxxxxxx。パスいいえ
ファイルシステム内のサブディレクトリ。ボリュームは
{path}/{volumeName}/にマウントされ、デフォルトは/{volumeName}/です。allowVolumeExpansionいいえ
予約済みのパラメーターです。現在のバージョンでは動的拡張はサポートされていません。
reclaimPolicyいいえ
Delete(デフォルト): PVC が削除されると、バックエンドファイルセットを削除します。Retain: ファイルセットを保持します。手動でのクリーンアップが必要です。本番環境ではRetainを使用してください。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: alicloud-bmcpfs-test parameters: bmcpfsId: bmcpfs-xxxxxx vpcMountTarget: cpfs-xxxxx-vpc-xxxxx.cn-hangzhou.cpfs.aliyuncs.com provisioner: bmcpfsplugin.csi.alibabacloud.com reclaimPolicy: Delete volumeBindingMode: Immediate allowVolumeExpansion: falseStorageClass を適用します。
kubectl apply -f sc.yaml期待される出力:
storageclass.storage.k8s.io/alicloud-bmcpfs-test created
手順3:PVC の作成
PVC は StorageClass を参照して、動的にプロビジョニングされたストレージを要求します。
pvc.yamlを作成します:パラメーター
説明
accessModesReadWriteManyのみ。複数ポッドによる同時アクセスが可能です。ストレージ要求するストレージ容量。Gi や Ti などの単位をサポートします。
volumeModeFilesystemのみサポートされています。storageClassNameStorageClass 名。動的なボリューム作成をトリガーします。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: bmcpfs-vsc namespace: default spec: accessModes: - ReadWriteMany # 複数のPod間での同時読み書きをサポートします resources: requests: storage: 10Ti # 大容量ストレージ (Tiレベル) をサポートします volumeMode: Filesystem # Filesystemのみがサポートされます storageClassName: alicloud-bmcpfs-test # 手順2で作成したStorageClassと一致させる必要がありますPVC を適用します。
kubectl apply -f pvc.yamlPVC がバインドされていることを確認します。
kubectl get pvc bmcpfs-vsc -n default期待される出力:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE bmcpfs-vsc Bound pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 10Ti RWX alicloud-bmcpfs-test 30sSTATUSがBoundの場合、PV は自動的に作成されます。プロビジョニングを確認します。kubectl describe pvc bmcpfs-vsc -n defaultイベントでプロビジョニング成功というメッセージを確認します。
手順4:ワークロードのデプロイと PVC のマウント
以下の Deployment は、単一の CPFS for Lingjun ボリュームを共有する 3 つのレプリカを実行します。
deploy.yamlを作成します:apiVersion: apps/v1 kind: Deployment metadata: name: cpfs-shared-example spec: replicas: 3 # 3つのレプリカで、複数のPod間で共有ストレージが機能することを確認します selector: matchLabels: app: cpfs-shared-app template: metadata: labels: app: cpfs-shared-app spec: tolerations: - key: node-role.alibabacloud.com/lingjun operator: Exists effect: NoSchedule # オプション:すべてのPodを特定のノードに固定するには、コメントを解除してノード名を設定します # 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 mountPath: /data # 共有ボリュームはコンテナ内の/dataにマウントされます 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: claimName: bmcpfs-vsc # 手順3で作成したPVCを参照しますDeployment を適用します。
kubectl apply -f deploy.yaml期待される出力:
deployment.apps/cpfs-shared-example created
リソースのクリーンアップ
予期しないコストを回避し、データの安全性を確保するために、この順序でリソースを削除してください。
ワークロードの削除 — PVC を使用しているすべてのアプリケーションを停止します。これにより、ボリュームがアンマウントされます。
kubectl delete deployment <your-deployment-name>PVC の削除 — 結果は、StorageClass の
reclaimPolicyによって異なります:保持(推奨): CPFS for LINGJUN のファイルセットとデータは保持されます。ステップ 3 に進み、PV を削除します。削除: バインドされた PV とバックエンドのファイルセットを完全に削除します。この操作は元に戻せません。
kubectl delete pvc <your-pvc-name>PV の削除 (
reclaimPolicyがRetainの場合のみ) — PVC を削除すると、PV はReleasedステータスに移行します。これを削除すると Kubernetes リソースは削除されますが、バックエンドデータに影響はありません。kubectl delete pv <your-pv-name>(オプション) StorageClass の削除 — 不要になった場合は削除します。既存のボリュームには影響しません。
kubectl delete sc <your-sc-name>CPFS for LINGJUN ファイルシステムの削除 —
Retainポリシーによって保持されているデータを含め、すべてのデータが完全に削除されます。依存関係が残っていないことを確認してから、ファイルシステムを削除してください。
トラブルシューティング
PVC が Pending ステータスのままになる
PVC が Pending 状態でスタックしている場合は、プロビジョニングが失敗したことを意味します。通常、PVC イベントで原因を特定できます。
kubectl describe pvc <your-pvc-name> -n <your-namespace>Eventsで警告を確認してください。一般的な原因:
StorageClass not found:storageClassNameが正しくないか、StorageClass が存在しません。provisioning failedまたはfailed to create fileset: バックエンドストレージの問題です。以下に進んでください。
イベントが設定の問題を示している場合は、StorageClass を検査し、CSI ドライバーの登録を確認します。
# StorageClassの設定を確認
kubectl get storageclass <your-sc-name> -o yaml
# CSIドライバーが登録されていることを確認
kubectl get csidriver bmcpfsplugin.csi.alibabacloud.com以下の点を確認します。
provisionerはbmcpfsplugin.csi.alibabacloud.comに一致します。bmcpfsIdが正しく、ファイルシステムが存在します。get csidriverで出力が返されない場合、ドライバーはインストールされていません。[アドオン] ページから bmcpfs-csi-controller、bmcpfs-csi-node、および cnfs-nas-daemon をインストールしてください。
Pod が ContainerCreating のままになる、または MountVolume.Setup に失敗する
Pod はノードに到達しましたが、ボリュームのマウントに失敗しました。以下の手順に従って原因を特定します。
Pod イベントを確認します。
kubectl describe pod <pod-name> -n <your-namespace>EventsでWarningメッセージ (たとえばFailedMountやMountVolume.Setup failed) がないか確認します。PVC がバインドされていることを確認します。
kubectl get pvc <your-pvc-name>STATUSはBoundである必要があります。Pendingの場合は、「PVC が Pending ステータスのままになる」をご参照ください。バインドされている場合は、ノード側の CSI プラグインのログを確認します。
kubectl get pods -n kube-system -l app.kubernetes.io/name=bmcpfs-csi-driver \ --field-selector spec.nodeName=<nodeName> \ -o name | xargs kubectl logs -n kube-system -c csi-pluginこれらのログには、ネットワーク接続、マウントターゲットの権限、I/O エラーに関する情報が表示されます。