Container Service for Kubernetes:Argo タスクのデータアクセスを高速化する

制限事項

この機能は、ACK のエラスティックスケジューリング機能と相互排他的です。ACK のエラスティックスケジューリング機能の詳細については、「優先度ベースのリソーススケジューlingの設定」をご参照ください。

ステップ 1: テストデータセットを OSS バケットにアップロードする

1. サイズが 2 GB のテストデータセットを作成します。この例では、テストデータセットを使用します。

2. 作成した OSS バケットにテストデータセットをアップロードします。

   OSS が提供する ossutil ツールを使用してデータをアップロードできます。詳細については、「ossutil のインストール」をご参照ください。

ステップ 2: データセットと JindoRuntime を作成する

ACK クラスターと OSS バケットを設定した後、データセットと JindoRuntime をデプロイする必要があります。デプロイには数分しかかかりません。

1. 次の内容に基づいて、secret.yaml という名前のファイルを作成します。

   このファイルには、OSS バケットへのアクセスに使用される fs.oss.accessKeyId と fs.oss.accessKeySecret が含まれています。

   apiVersion: v1
   kind: Secret
   metadata:
     name: access-key
   stringData:
     fs.oss.accessKeyId: ****
     fs.oss.accessKeySecret: ****

2. 次のコマンドを実行して Secret をデプロイします。

   kubectl create -f secret.yaml

3. 次の内容に基づいて、resource.yaml という名前のファイルを作成します。

   YAML ファイルには、次の情報が格納されます。

   • Dataset: リモートデータストアに保存されているデータセットと Unix ファイルシステム (UFS) の情報を指定します。

   • JindoRuntime: クラスター内のデータキャッシングのために JindoFS を有効にします。

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: serverless-data
   spec:
     mounts:
     - mountPoint: oss://large-model-sh/
       name: demo
       path: /
       options:
         fs.oss.endpoint: oss-cn-shanghai.aliyuncs.com
       encryptOptions:
         - name: fs.oss.accessKeyId
           valueFrom:
             secretKeyRef:
               name: access-key
               key: fs.oss.accessKeyId
         - name: fs.oss.accessKeySecret
           valueFrom:
             secretKeyRef:
               name: access-key
               key: fs.oss.accessKeySecret
     accessModes:
       - ReadWriteMany
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: serverless-data
   spec:
     master:
       disabled: true
     worker:
       disabled: true

   次の表に、上記のコードブロックで指定されているパラメーターの一部を示します。

   パラメーター	説明
   mountPoint	UFS ファイルシステムがマウントされるパス。パスのフォーマットは oss://<oss_bucket>/<bucket_dir> です。 パスにエンドポイント情報を含めないでください。<bucket_dir> は、バケットに直接アクセスできる場合はオプションです。
   fs.oss.endpoint	OSS バケットのパブリックまたはプライベートエンドポイント。 バケットのプライベートエンドポイントを指定して、データセキュリティを強化できます。ただし、プライベートエンドポイントを指定する場合は、OSS が有効化されているリージョンに ACK クラスターがデプロイされていることを確認してください。たとえば、OSS バケットが中国 (杭州) リージョンで作成されている場合、バケットのパブリックエンドポイントは oss-cn-hangzhou.aliyuncs.com で、プライベートエンドポイントは oss-cn-hangzhou-internal.aliyuncs.com です。
   fs.oss.accessKeyId	バケットへのアクセスに使用される AccessKey ID。
   fs.oss.accessKeySecret	バケットへのアクセスに使用される AccessKey Secret。
   accessModes	アクセスモード。有効な値: ReadWriteOnce、ReadOnlyMany、ReadWriteMany、ReadWriteOncePod。デフォルト値: ReadOnlyMany。
   disabled	マスターノードとワーカーノードの両方でこのパラメーターを true に設定すると、キャッシュレスモードが使用されます。

4. 次のコマンドを実行して、データセットと JindoRuntime をデプロイします。

   kubectl create -f resource.yaml

5. 次のコマンドを実行して、データセットがデプロイされているかどうかを確認します。

   kubectl get dataset serverless-data

   想定される出力:

   NAME              UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   serverless-data                                                                  Bound   1d

   出力の PHASE 列に Bound が表示されます。これは、データセットがデプロイされていることを示します。

6. 次のコマンドを実行して、JindoRuntime がデプロイされているかどうかを確認します。

   kubectl get jindo serverless-data

   想定される出力:

   NAME              MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
   serverless-data                                 Ready        3m41s

   出力の FUSE 列に Ready が表示されます。これは、JindoRuntime がデプロイされていることを示します。

ステップ 3: OSS にアクセスするための Argo タスクを作成する

アプリケーションコンテナーを作成して JindoFS 高速化サービスを使用するか、機械学習ジョブを送信して関連機能を使用できます。このトピックでは、OSS にアクセスする Argo タスクを例として使用します。

1. 次の内容で workflow.yaml という名前のファイルを作成します。

   apiVersion: argoproj.io/v1alpha1
   kind: Workflow
   metadata:
     generateName: serverless-workflow-
   spec:
     entrypoint: serverless-workflow-example
     volumes:
     - name: datadir
       persistentVolumeClaim:
         claimName: serverless-data
   
     templates:
     - name: serverless-workflow-example
       steps:
       - - name: copy
           template: copy-files
       - - name: check
           template: check-files
   
     - name: copy-files
       metadata:
         labels:
          alibabacloud.com/fluid-sidecar-target: eci
          alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["time cp -r /data/ /tmp"]
         volumeMounts:
         - name: datadir
           mountPath: /data
   
     - name: check-files
       metadata:
         labels:
           alibabacloud.com/fluid-sidecar-target: eci
           alibabacloud.com/eci: "true"
         annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       container:
         image: debian:buster
         command: [bash, -c]
         args: ["du -sh /data; md5sum /data/*"]
         volumeMounts:
         - name: datadir
           mountPath: /data

2. 次のコマンドを実行してワークフローを作成します。

   kubectl create -f workflow.yaml

3. 次のコマンドを実行して、起動ログを表示します。

   kubectl logs serverless-workflow-85sbr-4093682611

   想定される出力:

   real    0m24.966s
   user    0m0.009s
   sys     0m0.677s

   出力は、ファイルコピー時間 (real) が 0m24.966s であることを示しています。コピー時間は、ネットワーク遅延と帯域幅によって異なります。データアクセスを高速化するには、「キャッシュモードを使用して Argo タスクのデータアクセスを高速化する」をご参照ください。

4. Fluid を使用して読み取られたファイルがローカルファイルと一致することを確認します。

   1. 次のコマンドを実行して、Fluid を使用して読み取られたファイルの MD5 検証値を表示します。

      kubectl logs serverless-workflow-85sbr-1882013783

      想定される出力:

      1.2G    /data
      871734851bf7d8d2d1193dc5f1f692e6  /data/wwm_uncased_L-24_H-1024_A-16.zip

   2. 次のコマンドを実行して、ローカルファイルの MD5 検証値を表示します。

      md5sum ./wwm_uncased_L-24_H-1024_A-16.zip

      想定される出力:

      871734851bf7d8d2d1193dc5f1f692e6  ./wwm_uncased_L-24_H-1024_A-16.zip

      出力は、MD5 検証値が一致していることを示しています。これは、Fluid を使用して読み取られたファイルがローカルファイルと同じであることを示します。

ステップ 4: 環境をクリーンアップする

データアクセス機能が不要になったら、環境をクリーンアップしてリソースを解放します。次の操作を実行します。

1. 次のコマンドを実行して、アプリケーションコンテナーを削除します。

   kubectl delete workflow serverless-workflow-85sbr

2. 次のコマンドを実行して、データセットを削除します。

   kubectl delete dataset serverless-data