サーバーレス Kubernetes は Pod レベルの弾力性を提供し、数秒以内の起動、秒単位の課金、毎分 2,000 Pod という高い同時実行性などの利点があります。そのため、Argo の実行環境としてますます人気が高まっています。このトピックでは、Alibaba Cloud Container Service for Kubernetes (ACK) クラスターを使用して、Elastic Container Instance (ECI) 上で Argo ワークフローを実行する方法について説明します。
Kubernetes と Argo のセットアップ
-
Alibaba Cloud サーバーレス Kubernetes クラスターをセットアップします。
-
(推奨) ACK サーバーレスクラスターを作成します。詳細については、「ACK サーバーレスクラスターの作成」をご参照ください。
-
ACK マネージドクラスターを作成し、ack-virtual-node コントローラーをデプロイして仮想ノードを作成します。詳細については、「ACK マネージドクラスターの作成」および「仮想ノードコントローラーをデプロイし、それを使用して Elastic Container Instance ベースの Pod を作成する」をご参照ください。
-
-
Kubernetes クラスターに Argo をデプロイします。
-
(推奨) ack-workflow コンポーネントをインストールします。詳細については、「Argo Workflows」をご参照ください。
-
Argo を手動でデプロイします。詳細については、「Argo クイックスタート」をご参照ください。
-
-
Argo CLI をインストールします。詳細については、「argo-workflows」をご参照ください。
基本リソース構成の最適化
デフォルトでは、Argo をデプロイした後、argo-server および workflow-controller コアコンポーネントの Pod にはリソースリクエストとリミットが指定されていません。これにより、Pod には低いサービス品質 (QoS) クラスが割り当てられ、クラスターリソースが不足した場合に Out of Memory (OOM) キルや Pod のエビクションが発生しやすくなります。クラスターの規模に応じて、これら 2 つのコンポーネント Pod の resources を調整することを推奨します。手始めに、リクエストまたはリミットを 2 vCPU および 4 GiB メモリ以上に設定します。
アーティファクトリポジトリとしての OSS の使用
デフォルトでは、Argo は MinIO をアーティファクトリポジトリとして使用します。本番環境では、アーティファクトリポジトリの安定性が非常に重要です。ack-workflow コンポーネントは、Alibaba Cloud Object Storage Service (OSS) を永続的で信頼性の高いアーティファクトリポジトリとして使用することをサポートしています。OSS をアーティファクトリポジトリとして設定する方法については、「Configuring Alibaba Cloud OSS」をご参照ください。
設定が完了したら、次の例を使用してワークフローを作成し、設定を検証します。
-
次の内容を
workflow-oss.yamlとして保存します。apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: artifact-passing- spec: entrypoint: artifact-example templates: - name: artifact-example steps: - - name: generate-artifact template: whalesay - - name: consume-artifact template: print-message arguments: artifacts: # bind message to the hello-art artifact # generated by the generate-artifact step - name: message from: "{{steps.generate-artifact.outputs.artifacts.hello-art}}" - name: whalesay container: image: docker/whalesay:latest command: [sh, -c] args: ["cowsay hello world | tee /tmp/hello_world.txt"] outputs: artifacts: # generate hello-art artifact from /tmp/hello_world.txt # artifacts can be directories as well as files - name: hello-art path: /tmp/hello_world.txt - name: print-message inputs: artifacts: # unpack the message input artifact # and put it at /tmp/message - name: message path: /tmp/message container: image: alpine:latest command: [sh, -c] args: ["cat /tmp/message"] -
ワークフローを作成します。
argo -n argo submit workflow-oss.yaml -
ワークフローの実行結果を表示します。
argo -n argo list想定される出力：
s@xxxxxxxxxid:~$ argo -n argo list NAME STATUS AGE DURATION PRIORITY MESSAGE artifact-passing-2746t Succeeded 3m 30s 0
エグゼキュータの選択
各 Argo ワーカー Pod には、少なくとも 2 つのコンテナが含まれています：
-
mainコンテナこれは、ビジネスロジックが実行されるアプリケーションコンテナです。
-
waitコンテナArgo はこのシステムコンポーネントをサイドカーとして Pod に挿入します。その主な責務は次のとおりです：
-
起動フェーズ
-
mainコンテナが依存するアーティファクトと入力をロードします。
-
-
実行フェーズ
-
mainコンテナが終了するのを待ち、関連するサイドカーコンテナを強制終了します。 -
mainコンテナから出力とアーティファクトを収集し、そのステータスを報告します。
-
-
エグゼキュータは、wait コンテナが main コンテナにアクセスして制御するためのブリッジとして機能します。Argo はこれを ContainerRuntimeExecutor インターフェイスに抽象化し、次の操作を定義します：
-
GetFileContents：mainコンテナから出力パラメーター (outputs/parameters) を取得します。 -
CopyFile：mainコンテナから出力アーティファクト (outputs/artifacts) を取得します。 -
GetOutputStream：mainコンテナの標準出力 (標準エラーを含む) を取得します。 -
Wait：mainコンテナが終了するのを待ちます。 -
Kill：関連するサイドカーコンテナを強制終了します。 -
ListContainerNames：Pod 内のコンテナの名前をリストします。
Argo は、標準の Kubernetes アーキテクチャ向けに設計された、さまざまな基盤メカニズムを持つ複数のエグゼキュータをサポートしています。サーバーレス Kubernetes のアーキテクチャは標準の Kubernetes とは異なるため、互換性のあるエグゼキュータを選択する必要があります。サーバーレス Kubernetes 環境で Argo を実行するには、Emissary エグゼキュータの使用を推奨します。次の表に、利用可能なエグゼキュータの詳細を示します：
|
エグゼキュータ |
説明 |
|
Emissary |
このエグゼキュータは、標準の |
|
Kubernetes API |
Kubernetes API を使用しますが、その機能は不完全です。 このエグゼキュータは機能が不完全であり、大規模な環境では Kubernetes コントロールプレーンに負荷をかける可能性があるため、推奨されません。 |
|
PNS |
Pod 内のプロセス名前空間 (PID) 共有と サーバーレス Kubernetes はより高いレベルのセキュリティ分離を強制し、特権コンテナをサポートしていません。したがって、このエグゼキュータは互換性がありません。 |
|
Docker |
Docker CLI を使用してその機能を実行します。これには、基盤となる Docker コンテナランタイムへの直接アクセスが必要です。 サーバーレス Kubernetes は基盤となるノードを公開しないため、ノード上の Docker デーモンにアクセスできません。したがって、このエグゼキュータは互換性がありません。 |
|
Kubelet |
Kubelet Client API を使用してその機能を実行します。これには、ノード上の基盤となる Kubelet コンポーネントへのアクセスが必要です。 サーバーレス Kubernetes は基盤となるノードを公開しないため、Kubelet コンポーネントにアクセスできません。したがって、このエグゼキュータは互換性がありません。 |
ECI への Argo タスクのスケジューリング
ACK サーバーレスクラスターは、すべての Pod を自動的に ECI にスケジュールするため、追加の設定は不要です。ACK マネージドクラスターの場合は、Pod を ECI にスケジュールするように設定する必要があります。詳細については、「x86 ベースの仮想ノードへの Pod のスケジューリング」をご参照ください。
次の YAML の例は、スケジューリングにラベルを使用する方法を示しています：
-
ラベル
alibabacloud.com/eci: "true"を追加します：このラベルは Pod を自動的に ECI にスケジュールします。 -
(オプション)
{"schedulerName": "eci-scheduler"}を指定します：これは推奨されます。仮想ノードのアップグレードまたは変更中、アドミッション Webhook が一時的に利用できなくなる可能性があります。この設定により、この一時的な利用不可の間に Pod が通常のノードにスケジュールされるのを防ぎます。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: parallelism-limit1-
spec:
entrypoint: parallelism-limit1
parallelism: 10
podSpecPatch: '{"schedulerName": "eci-scheduler"}' # Pod を ECI にスケジュールします。
podMetadata:
labels:
alibabacloud.com/eci: "true" # ラベルを使用して Pod を ECI にスケジュールします。
templates:
- name: parallelism-limit1
steps:
- - name: sleep
template: sleep
withSequence:
start: "1"
end: "10"
- name: sleep
container:
image: alpine:latest
command: ["sh", "-c", "sleep 30"]Pod 作成成功率の向上
本番環境では、Argo ワークフローには多くの場合、複数のコンピュート Pod が関わります。単一の Pod の障害がワークフロー全体の障害を引き起こす可能性があります。ワークフローの成功率が低い場合、複数回のリランが必要になることがあり、実行効率に影響を与え、コストを増加させます。したがって、Pod 作成の成功率を向上させるための戦略を採用する必要があります：
-
Argo ワークフロー定義で：
-
ECI Pod を作成する際に：
-
単一ゾーンでの在庫不足による Pod 作成の失敗を防ぐために、マルチゾーンを設定します。詳細については、「マルチゾーンでの Pod のデプロイ」をご参照ください。
-
特定のインスタンスタイプの在庫不足による作成失敗を避けるために、複数のインスタンス仕様を指定します。詳細については、「複数の仕様を指定して Pod を作成する」をご参照ください。
-
特定のインスタンスタイプではなく、vCPU とメモリの要件を指定します。ECI は現在の在庫に基づいて、リクエストを自動的に利用可能なインスタンス仕様にマッチングします。
-
2 vCPU および 4 GiB 以上のメモリを持つインスタンス仕様を使用します。これらは専用リソースを持つエンタープライズレベルのインスタンスであり、安定したパフォーマンスを保証します。
-
Pod エラー処理ポリシーを設定して、失敗時に Pod 作成をリトライするかどうかを定義します。詳細については、「Pod のエラー処理ポリシーの設定」をご参照ください。
-
以下は設定例です：
-
eci-profileConfigMap を編集して、マルチゾーンを設定します。kubectl edit -n kube-system cm eci-profiledataセクションで、vSwitchIdsに複数の vSwitch の ID を設定します：data: # ...other configurations... vSwitchIds: vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf**** # 複数の vSwitch ID を指定してマルチゾーンを設定します。 vpcId: vpc-2zeghwzptn5zii0w7**** # ...other configurations... -
Pod を作成する際に、複数の戦略を使用して成功率を向上させます。
-
k8s.aliyun.com/eci-use-specsアノテーションを使用して、複数のインスタンス仕様を指定します。この例では、3 つの仕様がリストされています。ECI は、ecs.c6.large、ecs.c5.large、そして2-4Gi(2 vCPU、4 GiB メモリ) の順にマッチングを試みます。 -
k8s.aliyun.com/eci-schedule-strategyアノテーションを使用して、マルチゾーンスケジューリング戦略を設定します。この例では、設定されたゾーン全体に Pod をランダムにスケジュールするVSwitchRandomを使用します。 -
retryStrategyを設定して、Argo リトライポリシーを設定します。この例では、すべての失敗したステップをリトライするretryPolicy: "Always"を設定します。 -
k8s.aliyun.com/eci-fail-strategyアノテーションを使用して、Pod エラー処理ポリシーを設定します。この例ではfail-fastを使用します。Pod の作成が失敗した場合、システムは即座にエラーを報告し、Pod のステータスはProviderFailedになります。その後、上位のオーケストレーションシステムがリトライするか、Pod を通常のノードにスケジュールするかを決定できます。
apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: parallelism-limit1- spec: entrypoint: parallelism-limit1 parallelism: 10 podSpecPatch: '{"schedulerName": "eci-scheduler"}' podMetadata: labels: alibabacloud.com/eci: "true" annotations: k8s.aliyun.com/eci-use-specs: "ecs.c6.large,ecs.c5.large,2-4Gi" k8s.aliyun.com/eci-schedule-strategy: "VSwitchRandom" k8s.aliyun.com/eci-fail-strategy: "fail-fast" templates: - name: parallelism-limit1 steps: - - name: sleep template: sleep withSequence: start: "1" end: "10" - name: sleep retryStrategy: limit: "3" retryPolicy: "Always" container: image: alpine:latest command: [sh, -c, "sleep 30"] -
Pod コストの最適化
ECI は複数の課金方法をサポートしています。ワークロードに適した課金方法を選択することで、コンピューティングコストを大幅に削減できます。
コスト最適化の方法については、以下のトピックをご参照ください：
Pod 作成の高速化
Pod の起動時間は、多くの場合、イメージのプルに占められます。これは、イメージサイズとネットワーク速度に依存するプロセスです。Pod の作成を高速化するために、ECI はイメージキャッシュ機能を提供します。事前にイメージからイメージキャッシュを作成することで、そのキャッシュを使用する後続の Pod のダウンロード時間を短縮または排除できます。
イメージキャッシュには 2 種類あります：
-
自動作成：この機能は ECI でデフォルトで有効になっています。ECI Pod を作成する際、完全一致するイメージキャッシュが見つからない場合、ECI は Pod のイメージから自動的にイメージキャッシュを作成します。
-
手動作成：Custom Resource Definition (CRD) を使用して、手動でイメージキャッシュを作成できます。
高同時実行性の Argo タスクを実行する前に、手動でイメージキャッシュを作成することを推奨します。イメージキャッシュが作成されたら、Pod 定義でそれを指定し、Pod のイメージプルポリシーを
IfNotPresentに設定できます。これにより、Pod は起動時にイメージのプルステップをスキップでき、Pod の作成が高速化され、Argo タスクの実行時間が短縮され、運用コストが削減されます。詳細については、「ImageCache を使用して Pod の作成を高速化する」をご参照ください。
上記の例をすでに実行している場合、ECI は自動的にイメージキャッシュを作成しています。Elastic Container Instance コンソールにログインして、イメージキャッシュのステータスを確認できます。次の YAML を使用して、既存のキャッシュを活用し、Pod の起動速度をテストするワークフローを作成できます。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: parallelism-limit1-
spec:
entrypoint: parallelism-limit1
parallelism: 100
podSpecPatch: '{"schedulerName": "eci-scheduler"}'
podMetadata:
labels:
alibabacloud.com/eci: "true"
annotations:
k8s.aliyun.com/eci-use-specs: "ecs.c6.large,ecs.c5.large,2-4Gi"
k8s.aliyun.com/eci-schedule-strategy: "VSwitchRandom"
k8s.aliyun.com/eci-fail-strategy: "fail-fast"
templates:
- name: parallelism-limit1
steps:
- - name: sleep
template: sleep
withSequence:
start: "1"
end: "100"
- name: sleep
retryStrategy:
limit: "3"
retryPolicy: "Always"
container:
imagePullPolicy: IfNotPresent
image: alpine:latest
command: [sh, -c, "sleep 30"]ワークフローが作成された後、ECI Pod のイベントを確認して、マッチしたイメージキャッシュの ID を確認できます。イベントはまた、Pod の起動中にイメージのプルプロセスがスキップされたことも示しています。
Events:
Type Reason Age From Message
---- ------ --- ---- -------
Normal SuccessfulHitImageCache 2m22s EciService [eci.imagecache]Successfully hit image cache imc-2zeedp8bxor2kcxxx, eci will be scheduled with this image cache.
Normal Pulled 2m12s kubelet Container image "registry.cn-hangzhou.aliyuncs.com/acs/argoexec:v3.3-0d060b7" already present on machine
Normal Created 2m11s kubelet Created container init
Normal Started 2m11s kubelet Started container init
Normal Pulled 2m11s kubelet Container image "registry.cn-hangzhou.aliyuncs.com/acs/argoexec:v3.3-0d060b7" already present on machine
Normal Created 2m11s kubelet Created container wait
Normal Started 2m10s kubelet Started container wait
Normal Pulled 2m10s kubelet Container image "alpine:latest" already present on machine
Normal Created 2m10s kubelet Created container main
Normal Started 2m10s kubelet Started container mainデータロードの高速化
Argo は AI 推論で広く使用されており、タスクはしばしば大規模なデータセットにアクセスします。コンピューティングとストレージの分離アーキテクチャでは、データロードの効率がタスクの期間とコストに直接影響します。多くの Argo タスクからの同時データアクセスは、ストレージのボトルネックを生み出す可能性があります。たとえば、同時実行中の Argo タスクが OSS からデータをロードし、OSS バケットの帯域幅が飽和状態になると、各コンピュートノードはデータロード段階でブロックされます。これにより、タスクの期間とコンピューティングコストが増加し、効率が低下します。
データアクセラレーションサービスである Fluid は、この問題を解決します。バッチ計算を実行する前に、Fluid データセットを作成してプリロードできます。これにより、OSS からのデータが少数のキャッシュノードに事前にキャッシュされます。その後、同時実行の Argo タスクを開始できます。Argo タスクは、OSS から直接ではなく、キャッシュノードからデータを読み取ります。キャッシュノードは、OSS から利用可能な帯域幅を効果的に拡大し、コンピュートノードのデータロード効率を向上させます。このアプローチは、Argo タスクのパフォーマンスを向上させ、実行コストを削減します。Fluid の詳細については、「Fluid の概要」をご参照ください。
次の例では、Fluid を使用して OSS から 10 GB のテストファイルをロードし、100 の同時タスクでその MD5 ハッシュを計算する方法を示します。
-
Fluid をデプロイします。
-
ACK コンソールにログインします。
-
左側のナビゲーションウィンドウで、ストア>Marketplaceを選択します。
-
ack-fluid カードを見つけてクリックします。
-
ack-fluid ページで、デプロイをクリックします。
-
表示されるパネルで、ターゲットクラスターを選択し、パラメーターを設定して、OK をクリックします。
ack-fluid のデプロイが完了すると、リリース詳細ページにリダイレクトされます。Helm ページに戻ると、ack-fluid のステータスが
Deployedになっていることが確認できます。また、kubectlコマンドを実行して、Fluid が正常にデプロイされたことを確認することもできます。~$ kubectl get pod -n fluid-system NAME READY STATUS RESTARTS AGE dataset-controller-6f9967d766-pm22l 1/1 Running 0 5m18s fluid-webhook-5777b78c-8mt4h 1/1 Running 0 5m18s
-
-
テストデータを準備します。
Fluid をデプロイした後、Fluid データセットを使用してデータアクセスを高速化します。続行する前に、10 GB のテストファイルを OSS バケットにアップロードします。
-
テストファイルを生成します。
dd if=/dev/zero of=/test.dat bs=1G count=10 -
テストファイルを OSS バケットにアップロードします。詳細については、「シンプルアップロード」をご参照ください。
-
-
高速化されたデータセットを作成します。
-
Dataset および JindoRuntime リソースを作成します。
kubectl -n argo apply -f dataset.yaml以下は
dataset.yamlファイルの例です。プレースホルダーの AccessKey と OSS バケット情報を実際の値に置き換えてください。apiVersion: v1 kind: Secret metadata: name: access-key stringData: fs.oss.accessKeyId: *************** # OSS バケットにアクセスする権限を持つ AccessKey ID。 fs.oss.accessKeySecret: ****************** # OSS バケットにアクセスする権限を持つ AccessKey Secret。 --- apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: serverless-data spec: mounts: - mountPoint: oss://oss-bucket-name/ # ご利用の OSS バケットへのパス。 name: demo path: / options: fs.oss.endpoint: oss-cn-shanghai-internal.aliyuncs.com # OSS バケットのエンドポイント。 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 --- apiVersion: data.fluid.io/v1alpha1 kind: JindoRuntime metadata: name: serverless-data spec: replicas: 10 # 作成する JindoRuntime キャッシュノードの数。 podMetadata: annotations: k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge # 適切なインスタンス仕様を指定します。 k8s.aliyun.com/eci-image-cache: "true" labels: alibabacloud.com/eci: "true" worker: podMetadata: annotations: k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge # 適切なインスタンス仕様を指定します。 tieredstore: levels: - mediumtype: MEM # キャッシュ媒体タイプ。メモリには MEM を、ローカルディスクを持つインスタンスを指定する場合は LoadRaid0 を使用します。 volumeType: emptyDir path: /local-storage # キャッシュパス。 quota: 12Gi # 最大キャッシュ容量。 high: "0.99" # ストレージ容量の上限ウォーターマーク。 low: "0.99" # ストレージ容量の下限ウォーターマーク。説明この例では、ECI Pod のメモリをデータキャッシュノードとして使用します。各 ECI Pod は専用の VPC ネットワークインターフェイスを持っているため、その帯域幅は他の Pod の影響を受けません。
-
結果を表示します。
-
データセットのステータスを確認します。
PHASEがBoundであれば、作成が成功したことを示します。kubectl -n argo get dataset想定される出力：
$ kubectl -n argo get dataset NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE serverless-data 10.00GiB 0.00B 24.00GiB 0.0% Bound 92s -
Pod 情報を確認します。データセットによって 10 個の JindoRuntime キャッシュノードが作成されたことがわかります。
kubectl -n argo get pods想定される出力：
~$ kubectl -n argo get pods NAME READY STATUS RESTARTS AGE ack-workflow-ddd86b88c-r8fcj 1/1 Running 0 100m argo-server-84d69d65dd-1f2hj 1/1 Running 0 100m serverless-data-jindofs-master-0 1/1 Running 0 10m serverless-data-jindofs-worker-0 1/1 Running 0 9m20s serverless-data-jindofs-worker-1 1/1 Running 0 9m19s serverless-data-jindofs-worker-2 1/1 Running 0 9m19s serverless-data-jindofs-worker-3 1/1 Running 0 9m19s serverless-data-jindofs-worker-4 1/1 Running 0 9m19s serverless-data-jindofs-worker-5 1/1 Running 0 9m19s serverless-data-jindofs-worker-6 1/1 Running 0 9m19s serverless-data-jindofs-worker-7 1/1 Running 0 9m19s serverless-data-jindofs-worker-8 1/1 Running 0 9m19s serverless-data-jindofs-worker-9 1/1 Running 0 9m19s
-
-
-
データをプリロードします。
データセットの準備ができたら、DataLoad リソースを作成してデータのプリロードをトリガーします。
-
DataLoad リソースを作成してデータのプリロードをトリガーします。
kubectl -n argo apply -f dataload.yaml以下は dataload.yaml ファイルの例です：
apiVersion: data.fluid.io/v1alpha1 kind: DataLoad metadata: name: serverless-data-warmup namespace: argo spec: dataset: name: serverless-data namespace: argo loadMetadata: true -
DataLoad 操作の進捗を確認します。
kubectl -n argo get dataload想定される出力は、テストファイルが 10 GB であっても、データプリロードプロセスが非常に高速であることを示しています。
:~$ kubectl -n argo get dataload NAME DATASET PHASE AGE DURATION serverless-data-warmup serverless-data Complete 30s 14s
-
-
Argo ワークフローを実行します。
データがプリロードされた後、同時実行の Argo タスクを実行できます。最良の結果を得るには、このアプローチをイメージキャッシュと組み合わせます。
-
Argo ワークフロー設定ファイル
argo-test.yamlを準備します。以下は
argo-test.yamlファイルの例です：apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: parallelism-fluid- spec: entrypoint: parallelism-fluid parallelism: 100 podSpecPatch: '{"terminationGracePeriodSeconds": 0, "schedulerName": "eci-scheduler"}' podMetadata: labels: alibabacloud.com/fluid-sidecar-target: eci alibabacloud.com/eci: "true" annotations: k8s.aliyun.com/eci-use-specs: 8-16Gi templates: - name: parallelism-fluid steps: - - name: domd5sum template: md5sum withSequence: start: "1" end: "100" - name: md5sum container: imagePullPolicy: IfNotPresent image: alpine:latest command: ["sh", "-c", "cp /data/test.dat /test.dat && md5sum test.dat"] volumeMounts: - name: data-vol mountPath: /data volumes: - name: data-vol persistentVolumeClaim: claimName: serverless-data -
ワークフローを作成します。
argo -n argo submit argo-test.yaml -
ワークフローの実行結果を表示します。
argo -n argo list想定される出力：
xxx i:~$ argo -n argo list NAME STATUS AGE DURATION PRIORITY MESSAGE parallelism-fluid-56g2q Running 8s 8s 0kubectl get pod -n argo --watchコマンドを使用して、Pod の実行進捗を監視できます。この例では、100 個の Argo タスクが約 2〜4 分で完了します。parallelism-fluid-56g2q-412240702 0/3 Completed 0 3m17s parallelism-fluid-56g2q-563802762 0/3 Completed 0 3m19s parallelism-fluid-56g2q-693297214 0/3 Completed 0 3m17s parallelism-fluid-56g2q-615226358 0/3 Completed 0 3m18s parallelism-fluid-56g2q-982629280 0/3 Completed 0 3m20s parallelism-fluid-56g2q-918428816 0/3 Completed 0 3m16s parallelism-fluid-56g2q-3815880026 0/3 Completed 0 3m18s parallelism-fluid-56g2q-2992875428 0/3 Completed 0 3m19s parallelism-fluid-56g2q-3800105418 0/3 Completed 0 3m19s parallelism-fluid-56g2q-1897482410 0/3 Completed 0 3m17s対照的に、データアクセラレーションなしで同じ Argo タスクを実行し、10 GB のテストファイルを OSS から直接ロードする場合、MD5 ハッシュの計算には約 14〜15 分かかります。
parallelism-fluid-fdr2j-2392572892 0/2 Completed 0 14m parallelism-fluid-fdr2j-1295033972 0/2 Completed 0 14m parallelism-fluid-fdr2j-2462229879 0/2 Completed 0 14m parallelism-fluid-fdr2j-4192350503 0/2 Completed 0 14m parallelism-fluid-fdr2j-4157125527 0/2 Completed 0 14m parallelism-fluid-fdr2j-4173654052 0/2 Completed 0 14m parallelism-fluid-fdr2j-1270167245 0/2 Completed 0 14m parallelism-fluid-fdr2j-1595813521 0/2 Completed 0 14m parallelism-fluid-fdr2j-1829788936 0/2 Completed 0 14mこの比較から、Fluid がコンピューティング効率を向上させ、コストを大幅に削減することがわかります。
-