Container Service for Kubernetes:OSS データの高性能ボリュームへのオンデマンドプレフィル

機能の実装

この機能は、ACK の storage-operator によって管理される Kubernetes の Volume Populators を使用します。OSSVolumePopulator (OSSVP) カスタムリソースを参照する PVC を作成すると、storage-operator がリクエストをインターセプトし、データを投入します。

データ投入モードは、ターゲットボリュームのタイプによって異なります。

モード	サポートされるストレージタイプ	説明
bmcpfs-dataflow ネイティブデータフローモード	CPFS for Lingjun	storage-operator は CPFS のネイティブデータフローを利用してデータを投入します。 このモードはクラスターのコンピューティングリソースを使用せず、より効率的です。
generic 汎用 Pod 投入モード	クラウドディスクや CPFS 汎用版など、その他のストレージタイプ	storage-operator は、ack-volume-populator 名前空間に一時 Pod を作成し、新しいボリュームをマウントして指定された OSS データをダウンロードします。データ投入が完了すると、Pod は削除されます。 このモードはクラスターのコンピューティングリソースを消費します。

データ投入が成功すると、PVC のステータスが Pending から Bound に変わります。その後、アプリケーション Pod は PVC をマウントし、プリフェッチされたデータにアクセスできます。

主なシナリオ

この機能には、主に 2 つのユースケースがあります。

ワークフロー

VolumePopulator のコアステップは、どちらのモードでも同様です。

storage-operator で VolumePopulator Feature Gate を有効にします。 VolumePopulator を有効にすると、データ事前投入中の一時的な PVC と Pod のために、ack-volume-populator 名前空間がデフォルトで作成されます。 データ投入タスクのために OSS のアクセス権限を付与します。bmcpfs-dataflow モードでは OSS バケットに特定のタグが必要で、generic モードでは RRSA または AccessKey の設定が必要です。 OSS バケットのパスとデータ投入モードを指定して、OSSVolumePopulator オブジェクトを作成します。 PVC を作成し、StorageClass を指定し、dataSourceRef で OSSVP を参照してデータ事前投入を開始します (タイミングは StorageClass の volumeBindingMode に依存します)。 PVC が Bound 状態になった後、それをマウントするワークロード (Pod、デプロイメントなど) を作成し、高速なデータアクセスを実現します。 データ事前投入は、ボリューム作成時に一度だけ行われます。その後の OSS ソースデータの変更は、作成されたボリュームには同期されません。 タスクが終了した後、PVC を削除します。StorageClass の reclaimPolicy が Delete の場合、関連する高性能ストレージ (CPFS FileSet やクラウドディスクなど) は自動的に削除され、課金が停止します。OSS のソースデータは影響を受けません。

シナリオ 1：CPFS for Lingjun 共有ボリュームへのデータプリフェッチ

読み取り専用で高スループットのモデルトレーニングおよび推論では、CPFS for Lingjun データフローを使用して、OSS からモデルをオンデマンドでプリフェッチすることで、複数の GPU タスクによる高速な読み取りが可能になります。

apiVersion: storage.alibabacloud.com/v1beta1
kind: OSSVolumePopulator
metadata:
  name: qwen3-32b
  # アプリケーションおよび PVC と同じ名前空間に配置する必要があります
  namespace: bmcpfs-dataflow-demo 
spec:
  bucket: <your-bucket-name>
  region: cn-hangzhou
  endpoint: oss-cn-hangzhou-internal.aliyuncs.com
  path: /Qwen3-32B/
  # CPFS for Lingjun ボリューム専用で、そのデータフロー機能を活用します
  mode: bmcpfs-dataflow
  
  # bmcpfs-dataflow モードのオプション詳細設定
  # この例ではデフォルト設定を推奨します。特別な要件がない場合は無視してください。
  # bmcpfsDataflow:
    # データフローの最大スループット (MB/s) 。指定可能な値：600、1200、1500。デフォルト：600
    # throughput: 1200
    # 暗号化転送を有効化します。デフォルト：空 (無効)
    # sourceSecurityType: SSL
    # データプレフィルモード。デフォルト：metadataAndData (完全なプレフィル)
    # メタデータのみのプレフィルの場合は metadata に設定します。
    # dataType: metadataAndData

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: bmcpfs-dataflow-demo
parameters:
  bmcpfsId: bmcpfs-29000z8xz3xxxxxxxxxxx
  vpcMountTarget: cpfs-29000z8xz3xxxxxxxxxxx-vpc-xxxxxx.cn-wulanchabu.cpfs.aliyuncs.com
  mountpointAutoSwitch: "true"
provisioner: bmcpfsplugin.csi.alibabacloud.com
# 重要：この設定により、PVC 削除後に CPFS Fileset とデータが自動的にクリーンアップされます
reclaimPolicy: Delete
# 推奨：PVC 作成直後にデータプレフィルを開始するには Immediate に設定します
volumeBindingMode: Immediate

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: qwen3-32b
  namespace: bmcpfs-dataflow-demo
spec:
  accessModes:
    - ReadOnlyMany
  dataSourceRef:
    apiGroup: storage.alibabacloud.com
    kind: OSSVolumePopulator
    # 上記で作成した OSSVP 名を参照します
    name: qwen3-32b
  resources:
    requests:
      # OSSVP が参照する OSS データソースのサイズ以上である必要があります
      storage: 80Gi
  storageClassName: bmcpfs-dataflow-demo
  volumeMode: Filesystem

kubectl -n bmcpfs-dataflow-demo describe ossvp qwen3-32b

5. ワークロードの作成とデータの使用

PVC が Bound になったら、それをマウントするワークロードを作成します。

この例では GPU リソースを使用します。検証のみを目的とする場合、CPU ポッドを作成し、kubectl exec を使用してデータを検査します。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: demo-apply-qwen3-32b
  namespace: bmcpfs-dataflow-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-apply-qwen3-32b
  template:
    metadata:
      labels:
        app: demo-apply-qwen3-32b
      # CPFS ボリュームをマウントするには ACS HPN インスタンスタイプを使用します
      # alibabacloud.com/compute-class: "gpu-hpn"
    spec:
      # CPFS ボリュームをマウントするには ACS HPN インスタンスタイプを使用します
      # nodeSelector: 
      #   alibabacloud.com/node-type: reserved
      # tolerations:
      # - key: "virtual-kubelet.io/provider" 
      #   operator: "Exists"
      #   effect: "NoSchedule"
      volumes:
        - name: model-storage
          persistentVolumeClaim:
            # 作成した PVC を指定します
            claimName: qwen3-32b
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 15Gi
      containers:
        - command: ["sh", "-c", "python3 -m sglang.launch_server --model-path /models/Qwen3-32B --tp 2"]
          image: registry.cn-beijing.aliyuncs.com/tool-sys/ossfs-public:demo-env-python3.12.7-sglang0.5.5
          name: sglang
          ports:
            - containerPort: 8000
              name: http
          resources:
            limits:
              nvidia.com/gpu: "2"
            requests:
              nvidia.com/gpu: "2"
          volumeMounts:
            - mountPath: /models/Qwen3-32B
              name: model-storage
            - mountPath: /dev/shm
              name: dshm

リソースのクリーンアップガイド

AI トレーニングまたは推論タスクが完了した後、CPFS for Lingjun 共有ボリュームと関連するワークロードをリリースします。

リリースするリソース：

• 共有ボリュームを使用するワークロード（この例では、StatefulSet）

• データプレフィルに使用した PVC

• PVC によって自動的に作成されたバックエンドストレージリソース (CPFS for Lingjun Fileset)

クリーンアップの手順：

1. ワークロードを削除する

   ボリュームを使用している StatefulSet を削除して、PVC をリリースします。

   kubectl delete statefulset demo-apply-qwen3-32b -n bmcpfs-dataflow-demo

2. PVC を削除する

   StorageClass で reclaimPolicy: Delete を設定した場合、PVC を削除するとバックエンドの CPFS FileSet も削除され、ストレージが解放され、課金が停止します。

   kubectl delete pvc qwen3-32b -n bmcpfs-dataflow-demo

3. リソースのクリーンアップを確認する：

   • NAS コンソールで、ファイルシステム>ファイルシステムリスト を選択し、この PVC の FileSet が削除され、使用容量が減少したことを確認します。

   • OSS コンソールで、データセットがそのまま残っていることを確認してください。

前提条件

• storage-operator で VolumePopulatorPodHandler を有効にします。

  有効にすると、システムは関連コンポーネントと一時的な Pod に必要な RBAC 権限を付与します。有効にする前に、セキュリティリスクを評価してください。

  自動的に設定される RBAC 権限

  • storage-operator に、ack-volume-populator 名前空間での Pod 操作権限を付与します

    - apiGroups: [""]
      resources: [pods]
      verbs: [get, list, watch, create, delete]

  • 一時的なタスク Pod にクラスターレベルのアクセス権限を付与します

    - apiGroups: [""]
      resources: [events]
      verbs: [create, patch, get, list]
    - apiGroups: [volumepopulators.storage.alibabacloud.com]
      resources: [ossvolumepopulators]
      verbs: [get, list, watch]

• Argo Workflows がインストールされていること。

  詳細な手順

  1. ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで、[操作] > [アドオン] の順に選択します。

  3. [アドオン] ページで、[Argo Workflows] を見つけ、画面の指示に従ってインストールします。

• この例では、データプリフィルタスクとワークフローにサーバーレスコンピューティング (ECI) を使用します。 ack-virtual-node アドオン をインストールしてください。サーバーレスでない環境で検証する場合は、リソースから alibabacloud.com/eci: "true" を削除してください。

1. データプリフィルタスクへの OSS アクセス権限の付与

generic モードでは、データプリフィルタスクは ack-volume-populator 名前空間で一時的な Pod として実行されます。これらの Pod に、ソースデータが格納されている OSS バケットへのアクセス権限を付与する必要があります。

• RRSA 方式：Pod に一時的で自動ローテーションされる RAM ロールを動的に割り当て、きめ細やかな権限分離とより高いセキュリティを実現します。

• AccessKey 方式：静的な長期認証情報を Secret に保存します。設定は簡単ですが、セキュリティは低くなります。

2. OSSVolumePopulator (OSSVP) の作成

アプリケーションおよび PVC と同じ名前空間に OSSVolumePopulator を作成します。 mode を generic に設定し、認証を設定します。

apiVersion: storage.alibabacloud.com/v1beta1
kind: OSSVolumePopulator
metadata:
  name: generic-demo
  # アプリケーションおよび PVC と同じ名前空間に配置する必要があります
  namespace: argo 
spec:
  bucket: my-test-bucket
  region: cn-hangzhou
  endpoint: oss-cn-hangzhou-internal.aliyuncs.com
  path: /many-files/
  # 任意のバックエンドストレージボリューム用の汎用モード
  mode: generic
  generic:
    # ECI Pod へのスケジューリングのために、データ投入タスク Pod にラベルを追加します
    labels:
      alibabacloud.com/eci: "true"
    # ECI スペックを設定するために、データ投入タスク Pod にアノテーションを追加します
    annotations:
      k8s.aliyun.com/eci-use-specs: "2-4Gi"
    # secretRef または rrsaConfigs のいずれかを選択します
    # secretRef: oss-secret
    rrsaConfigs:
      # RRSA 認証に使用される RAM ロールの ARN
      roleArn: "acs:ram::1234567*****:role/oss-populator"
      # クラスターの OIDC プロバイダーの ARN
      oidcProviderArn: "acs:ram::1234567*****:oidc-provider/my-oidc-provider"
    # 特定のノードにスケジューリングするために、データ投入タスク Pod の affinity を設定します
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
            - matchExpressions:
                - key: "disktype"
                  operator: NotIn
                  values:
                    - "hdd"
    # データ投入タスク Pod の tolerations を設定します
    tolerations:
      - key: "virtual-kubelet.io/provider"
        operator: Equal
        value: "alibabacloud"
        effect: NoSchedule
    # 最大スループット (MB/s)
    # throughput: 1000

パラメーター：

3. StorageClass の準備

このシナリオでは、クラウドディスクを動的にプロビジョニングするための StorageClass が必要です。ACK は デフォルトの StorageClass を提供し、 StorageClass を手動で作成することも可能です。

• この例では、reclaimPolicy が Delete に、volumeBindingMode が Immediate に設定された alicloud-disk-essd を使用しており、ゾーンを意識しないサーバーレスコンピューティングに適しています。

• サーバーレスでないワークフローの場合、volumeBindingMode が WaitForFirstConsumer に設定された StorageClass (例：alicloud-disk-topology-alltype) を使用して、クラウドディスクとアプリケーション Pod が同じゾーンに作成されるようにします。

4. Argo Workflow の作成

この Workflow の例では、ephemeral な volumeClaimTemplate を使用して、各並列タスク用にデータがプリフィルされた独立したクラウドディスクを作成します。

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: parallel-data-process-with-ossvp-
  namespace: argo
spec:
  # 入力パラメーターを定義
  arguments:
    parameters:
      - name: number
        value: 2

  entrypoint: main
  # ワークフロー内の各同時実行レプリカのボリューム要求テンプレートを定義
  volumes:
    - name: scratch-volume
      # エフェメラルボリュームとして宣言し、ワークフロー完了後に自動的に削除
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              diskType: scratch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            # サーバーレスでないコンピューティングの場合、alicloud-disk-topology-alltype に置き換えます
            storageClassName: "alicloud-disk-essd"
            resources:
              requests:
                # OSSVP によって参照される OSS データソースのサイズ以上である必要があります
                storage: 20Gi
            # データソースとして OSSVP を参照
            dataSourceRef:
              apiGroup: storage.alibabacloud.com
              kind: OSSVolumePopulator
              name: generic-demo

  templates:
    - name: main
      dag:
        tasks:
          # 複数の echo タスクを並行して実行
          - name: echo-task
            template: echo-template
            arguments:
              parameters:
                - name: index
                  value: "{{item}}"
            withSequence:
              count: "{{workflow.parameters.number}}"

    - name: echo-template
      metadata:
        labels:
          # ECI でタスクを実行
          alibabacloud.com/eci: "true" 
      container:
        image: mirrors-ssl.aliyuncs.com/busybox:latest
        command:
          - sh
          - -c
        args:
          - |
            echo "Subtask started, ID: {{inputs.parameters.index}}"
            echo "Creating a new log file..."
            touch /scratch-volume/"{{inputs.parameters.index}}-logs"
            echo "Listing contents from the disk populated by OSSVP:"
            ls /scratch-volume
            echo "Subtask completed, ID: {{inputs.parameters.index}}"
        volumeMounts:
        - name: scratch-volume
          mountPath: /scratch-volume
        resources:
          limits:
            cpu: '4'
            memory: 16Gi
          requests:
            cpu: '4'
            memory: 16Gi
      inputs:
        parameters:
          - name: index

Workflow を作成した後、いずれかのタスク Pod からログを確認し、プリフィルされたデータの読み取りが成功したことを確認します。

本番環境では、Argo Workflows Artifact を使用して最終的な計算結果を OSS に永続化します。

# <your-workflow-pod-name> を実際の Pod 名に置き換えます
kubectl -n argo logs <your-workflow-pod-name>

期待される出力：

Subtask started, ID: 1
Creating a new log file...
Listing contents from the disk populated by OSSVP:
1-logs
lost+found
results-2025-04-16T07:48:00Z
...
Subtask completed, ID: 1

結果の分析：

• 1-logs：タスクによって書き込まれたファイルで、並列タスク間の読み書きアクセスと独立したストレージを確認します。

• results-2025-04-16T07:48:00Z および同様のファイル：OSS からクラウドディスクにプリフィルされたデータ。

• lost+found：ファイルシステムのフォーマット中に作成されたディレクトリ。無視してください。

リソース解放ガイド

バッチ処理タスクが完了したら、独立したクラウドディスクボリュームと Argo Workflow インスタンスを解放します。

解放するリソース：

• Argo Workflow インスタンス

• ワークフローによって自動的に作成された一時的な PVC

• PVC によって自動的に作成されたバックエンドストレージリソース (クラウドディスク)。

解放手順：

1. Argo Workflow の削除：

   Workflow リソースを削除します。ephemeral ボリューム要求を使用すると、削除はすべての PVC にカスケードされます。StorageClass の reclaimPolicy: Delete により、バックエンドのクラウドディスクが削除され、リソースが解放されて課金が停止します。

   # <workflow-name> を実際の Workflow 名に置き換えます
   kubectl -n argo delete workflow <workflow-name>

2. リソース解放の確認：

   • kubectl -n argo get pvc を実行して、ワークフロー関連のすべての PVC が削除されたことを確認します。

   • クラウドディスクリソースの確認：[ECS コンソール - ブロックストレージ - ディスク] に移動し、このワークフローからのクラウドディスクリソースが残っていないことを確認します。

   • OSS のソースデータは影響を受けません。 OSS コンソール で、データセットがそのまま残っていることを確認します。

事前入力の完了後、OSS のソースファイルを更新すると、ボリューム内のデータは自動的に同期されますか？

いいえ。データの事前入力は、ボリューム作成時に 1 回限り行われます。ポピュレーション後、ボリュームの内容は OSS のソースデータから分離され、その後の OSS の変更は同期されません。

PVC が Pending ステータスのままなのはなぜですか？

Pending は、データの事前入力中は正常な状態です。この状態が続く場合は、次のようにトラブルシューティングしてください：

1. kubectl describe pvc <pvc-name> -n <namespace>：PVC のイベントをチェックして、ポピュレーターのエラーを確認してください。

2. kubectl describe ossvp <ossvp-name> -n <namespace>：OSSVP のステータスとイベントをチェックして、ポピュレーションの進捗や失敗を確認してください。

3. generic モードでは、ack-volume-populator 名前空間で失敗したポッドを確認し、ログを確認します。一般的な原因として、OSS の権限不足、ネットワークの問題、またはストレージ容量の不足などが挙げられます。