Container Service for Kubernetes:OSS データをオンデマンドでパフォーマンス専有型ボリュームにプリフェッチ

機能の実装

本機能は、Kubernetes Volume Populators を活用し、ACK の storage-operator によって管理されます。カスタムリソース 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 を有効化すると、デフォルトで ack-volume-populator 名前空間が作成され、データプリフェッチ中に生成される一時的な PVC および Pod が実行されます。 権限設定：プリフェッチタスク用の OSS アクセス権限を付与します。bmcpfs-dataflow モードでは、OSS バケットに特定のタグを設定する必要があります。generic モードでは、RRSA または AccessKey の設定が必要です。 データソース (OSSVP) の定義：OSS バケットパスおよびプリフェッチモードを指定する OSSVolumePopulator オブジェクトを作成します。 ボリュームの作成およびプリフェッチの開始 (PVC)：StorageClass を指定して PVC を作成し、dataSourceRef フィールドを使用して、前述の OSSVP を参照します。これにより、データプリフェッチプロセスが開始されます（タイミングは StorageClass の volumeBindingMode に依存）。 検証および利用：PVC ステータスが Bound になった後、この PVC をマウントするアプリケーションワークロード（Pod、デプロイメントなど）を作成し、高速なデータアクセスを実現します。 データプリフェッチは、ボリューム作成時の 1 回限りの操作です。その後の OSS ソースデータの変更は、作成済みボリュームには同期されません。 リソースの解放：タスク終了後、PVC を削除します。StorageClass の reclaimPolicy が Delete に設定されている場合、関連するパフォーマンス専有型ストレージリソース（CPFS FileSet やクラウドディスクなど）が自動的に削除され、課金が停止します。OSS ソースデータは影響を受けません。

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

本ソリューションは、モデルのトレーニングおよび推論など、読み取り専用かつ高スループットを要するシナリオを対象としています。CPFS for Lingjun のデータフロー機能を活用して、OSS から CPFS for Lingjun ボリュームへモデルをオンデマンドでプリフェッチし、複数の 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 のみのプリフェッチには 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 になった後、この PVC をマウントするワークロードを作成します。

この例では GPU リソースを使用します。検証のみを目的として、CPU Pod を作成し、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 が設定されているため、この操作によりバックエンドの CPFS FileSet の削除が自動的にトリガーされ、ストレージ容量が解放され、課金が停止します。

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

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

   • CPFS for Lingjun ファイルシステムの確認： NAS コンソール に移動し、ファイルシステム > ファイルシステムリスト を選択し、この PVC に関連付けられた FileSet が削除され、ファイルシステムの使用容量が減少していることを確認します。

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

事前準備

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

  有効化後、システムが関連コンポーネントおよび一時的な Pod に対する必要な RBAC 権限を自動的に付与します。有効化する前に、潜在的なセキュリティリスクを評価してください。

  自動設定される RBAC 権限について

  • ack-volume-populator 名前空間内で storage-operator 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. Container Service Management Console にログインします。左側のナビゲーションウィンドウで クラスターリスト をクリックします。

  2. クラスターリスト ページで、ご利用のクラスター名をクリックします。左側のナビゲーションウィンドウで アドオン管理 をクリックします。

  3. コンポーネント管理 ページで、Argo Workflows を見つけ、画面上の指示に従ってコンポーネントをインストールします。

     インストールが完了したら、左側のナビゲーションウィンドウで アプリケーション > Helm を選択します。ack-workflow の ステータス 列に デプロイ済み と表示されていれば、コンポーネントはインストールされています。

• この例では、データプリフェッチタスクおよびワークフローの実行にサーバーレスコンピューティング（ECI）を使用します。そのため、ack-virtual-node コンポーネント もインストールする必要があります。検証のために非サーバーレスコンピューティングを使用する場合は、リソースから関連ラベル alibabacloud.com/eci: "true" を削除してください。

1. データの事前入力タスクに OSS へのアクセスを承認する

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

• RRSA メソッド：アプリケーションレベルの細かい権限分離を実現する、動的かつ自動ローテーションする RAM ロールを Pod に割り当てます。セキュリティ性が高くなります。

• AccessKey メソッド：静的かつ長期的な認証情報をシークレットに保存します。設定が簡単ですが、セキュリティ性は低くなります。

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:
      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 の手動作成 もサポートしています。

• この例では、alicloud-disk-essd を使用します。これは reclaimPolicy を Delete に、volumeBindingMode を Immediate に設定しており、ゾーン認識を必要としないサーバーレスコンピューティングのシナリオに適しています。

• 非サーバーレスコンピューティング上でワークフローを実行する場合は、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
  # Workflow 内の各並列レプリカ用のボリューム要求テンプレートの定義
  volumes:
    - name: scratch-volume
      # 一時的なボリュームとして宣言し、Workflow 完了後に自動的に削除
      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 "サブタスク開始、ID: {{inputs.parameters.index}}"
            echo "新しいログファイルを作成中..."
            touch /scratch-volume/"{{inputs.parameters.index}}-logs"
            echo "OSSVP でプリフェッチされたディスクからの内容一覧:"
            ls /scratch-volume
            echo "サブタスク完了、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>

期待される出力：

サブタスク開始、ID: 1
新しいログファイルを作成中...
OSSVP でプリフェッチされたディスクからの内容一覧:
1-logs
lost+found
results-2025-04-16T07:48:00Z
...
サブタスク完了、ID: 1

結果の分析：

• 1-logs：タスクによって新規に書き込まれたファイルで、ボリュームが読み書き可能であることおよび並列タスク間でストレージが隔離されていることを検証します。

• results-2025-04-16T07:48:00Z および同様のファイル：OSS からクラウドディスクへプリフェッチされたデータで、プリフェッチ機能が正しく動作していることを確認します。

• lost+found：ファイルシステムのフォーマット後に自動的に生成されるディレクトリです。無視してください。

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

バッチ処理タスクの完了後、Argo Workflow によって動的に作成された隔離されたクラウドディスクボリュームおよび関連ワークフローを速やかに解放してください。

解放するリソース：

• Argo Workflow インスタンス

• Workflow によって自動的に作成された一時的な PVC

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

リリースフロー:

1. Argo Workflow の削除：

   このシナリオでは、通常は Workflow リソースを削除するだけで十分です。Workflow が ephemeral ボリューム要求を使用しているため、Workflow の削除により、それが作成したすべての PVC がカスケード削除されます。StorageClass で reclaimPolicy: Delete が設定されているため、さらにバックエンドのクラウドディスクの自動削除がトリガーされ、リソースが解放され、課金が停止します。

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

2. リソースのクリーンアップ確認：

   • PVC の確認： kubectl -n argo get pvc を実行し、この Workflow に関連するすべての PVC が削除されたことを確認します。

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

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

プリフェッチ完了後、OSS のソースファイルを更新しても、ボリューム内のデータは自動同期されますか？

いいえ。データプリフェッチはボリューム作成時の 1 回限りの操作です。ボリュームが作成およびプリフェッチされた後、その内容は OSS のソースデータから切り離されます。その後の OSS の変更は、作成済みボリュームには同期されません。

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

Pending は、データプリフェッチ中の正常な状態です。長期間 Pending のままの場合、以下の手順でトラブルシューティングを行ってください。

1. kubectl describe pvc <pvc-name> -n <namespace>：PVC Events を確認し、Populator 関連のエラーメッセージを調べます。

2. kubectl describe ossvp <ossvp-name> -n <namespace>：OSSVP の Status および Events を確認し、プリフェッチタスクのステータス、進行状況、または失敗原因を調べます。

3. generic モードを使用している場合、ack-volume-populator 名前空間内で失敗した Pod を確認し、そのログを確認します。一般的な原因には、OSS 権限の不足、ネットワーク障害、ストレージ容量の不足などがあります。