Elastic Container Instance：Jalankan alur kerja Argo pada instance kontainer elastis

Deploy Argo di klaster Kubernetes

1. Buat klaster ACK Serverless.

   • (Direkomendasikan) Buat klaster ACK Serverless. Untuk informasi lebih lanjut, lihat Buat klaster ACK Serverless.

   • Buat klaster ACK dan deploy kontroler ack-virtual-node di klaster untuk menghasilkan node virtual. Untuk informasi lebih lanjut, lihat Buat klaster ACK yang dikelola dan Deploy kontroler node virtual dan gunakan untuk membuat pod berbasis Elastic Container Instance.

2. Deploy Argo di klaster Kubernetes.

   • (Direkomendasikan) Instal komponen ack-workflow. Untuk informasi lebih lanjut, lihat ack-workflow.

   • Deploy Argo tanpa menggunakan komponen. Untuk informasi lebih lanjut, lihat Argo Quick Start.

3. Instal perintah Argo. Untuk informasi lebih lanjut, lihat argo-workflows.

Optimalkan konfigurasi infrastruktur

Secara default, setelah Anda menerapkan Argo di klaster Kubernetes, sumber daya tidak ditentukan untuk pod yang sesuai dengan komponen inti argo-server dan workflow-controller. Tingkat kualitas layanan (QoS) dari pod terkait rendah. Jika sumber daya klaster tidak mencukupi, pembunuhan OOM (out-of-memory) dapat terjadi pada komponen dan pod mungkin dievakuasi. Kami merekomendasikan agar Anda menyesuaikan sumber daya pod yang sesuai dengan komponen inti sebelumnya berdasarkan ukuran klaster Anda. Kami juga merekomendasikan agar Anda mengatur permintaan atau batas menjadi 2 vCPU dan 4 GiB memori atau lebih.

Gunakan Bucket OSS sebagai repositori artefak

Secara default, Argo menggunakan MinIO sebagai repositori artefak. Dalam lingkungan produksi, Anda perlu mempertimbangkan stabilitas repositori artefak. ack-workflow memungkinkan Anda menggunakan bucket Object Storage Service (OSS) sebagai repositori artefak. Untuk informasi tentang cara mengonfigurasi bucket OSS sebagai repositori artefak, lihat Mengonfigurasi Alibaba Cloud OSS.

Setelah Anda mengonfigurasi OSS, Anda dapat membuat alur kerja untuk memverifikasi konfigurasi berdasarkan contoh berikut.

1. Buat file bernama workflow-oss.yaml dan salin template berikut ke file:

   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 along with 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"]

2. Buat alur kerja.

   argo -n argo submit workflow-oss.yaml

3. Lihat hasil eksekusi alur kerja.

   argo -n argo list

   Output yang diharapkan:

   

Pilih executor

Pod pekerja yang dibuat oleh Argo berisi setidaknya kontainer berikut:

• Kontainer utama

  Kontainer bisnis yang menjalankan logika bisnis.

• Kontainer tunggu

  Komponen sistem Argo yang disuntikkan ke dalam pod sebagai sidecar. Kontainer tunggu memiliki karakteristik inti berikut:

  • Pada tahap startup pod

    • Memuat artefak dan input yang bergantung pada kontainer utama.

  • Pada tahap runtime pod

    • Menunggu kontainer utama keluar, lalu membunuh kontainer sidecar terkait.

    • Mengumpulkan output dan artefak dari kontainer utama, dan melaporkan status kontainer utama.

Kontainer tunggu menggunakan executor untuk mengakses dan mengelola kontainer utama. Argo mengabstraksi executor menjadi ContainerRuntimeExecutor. Daftar berikut menjelaskan operasi API dari ContainerRuntimeExecutor:

• GetFileContents: mendapatkan parameter output dari kontainer utama menggunakan outputs/parameters.

• CopyFile: mendapatkan output dari kontainer utama menggunakan outputs/artifacts.

• GetOutputStream: mendapatkan output standar (termasuk kesalahan standar) dari kontainer utama.

• Wait: menunggu kontainer utama keluar.

• Kill: membunuh kontainer sidecar terkait.

• ListContainerNames: mencantumkan nama kontainer dalam pod.

Argo mendukung beberapa executor yang memiliki prinsip kerja berbeda tetapi dirancang untuk bekerja pada arsitektur Kubernetes asli. Arsitektur ACK Serverless berbeda dari arsitektur Kubernetes asli. Anda perlu memilih executor yang sesuai untuk menjalankan alur kerja Argo di klaster ACK Serverless. Kami merekomendasikan agar Anda memilih Emisarry sebagai executor untuk menjalankan alur kerja Argo di klaster ACK Serverless. Tabel berikut menjelaskan executor yang didukung oleh klaster Kubernetes asli:

Jadwalkan tugas Argo untuk dijalankan pada Elastic Container Instance

Secara default, klaster ACK Serverless menjadwalkan semua pod untuk dijalankan pada Elastic Container Instance. Anda tidak perlu melakukan konfigurasi tambahan untuk klaster ini. Jika Anda ingin klaster ACK menjadwalkan pod untuk dijalankan pada Elastic Container Instance, Anda harus mengonfigurasi klaster ACK. Untuk informasi lebih lanjut, lihat Jadwalkan pod ke node virtual berbasis x86.

Dalam contoh berikut, label ditambahkan untuk mengonfigurasi klaster ACK:

• Tambahkan label alibabacloud.com/eci: "true": Setelah label ditambahkan, pod yang memiliki label secara otomatis dijadwalkan untuk dijalankan pada Elastic Container Instance.

• (Opsional) Tentukan {"schedulerName": "eci-scheduler"}: Kami merekomendasikan agar Anda menggunakan pengaturan ini. Saat Anda memperbarui atau mengubah Virtual Kubelet, webhook mungkin tidak tersedia untuk jangka waktu singkat. Jika Anda menggunakan pengaturan ini, pod tidak dijadwalkan ke node nyata.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: parallelism-limit1-
spec:
  entrypoint: parallelism-limit1
  parallelism: 10
  podSpecPatch: '{"schedulerName": "eci-scheduler"}'  # Jadwalkan pod untuk dijalankan pada Elastic Container Instance.
  podMetadata:
    labels:
      alibabacloud.com/eci: "true"   # Tambahkan label untuk menjadwalkan pod dijalankan pada Elastic Container Instance.
  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"]

Tingkatkan tingkat keberhasilan pembuatan pod

Dalam lingkungan produksi, alur kerja Argo mungkin berisi beberapa pod komputasi. Jika sebuah pod dalam alur kerja gagal, seluruh alur kerja gagal. Jika tingkat keberhasilan alur kerja Argo Anda rendah, Anda perlu menjalankan alur kerja Argo beberapa kali. Ini memengaruhi efisiensi eksekusi tugas dan meningkatkan biaya komputasi alur kerja Argo. Anda perlu mengambil langkah-langkah berikut untuk meningkatkan tingkat keberhasilan pembuatan pod:

• Definisikan alur kerja Argo

  • Konfigurasikan kebijakan ulang untuk alur kerja Argo untuk secara otomatis mencoba ulang alur kerja Argo jika alur kerja gagal. Untuk informasi lebih lanjut, lihat Retries.

  • Tentukan periode timeout untuk alur kerja untuk membatasi waktu yang telah berlalu untuk alur kerja. Untuk informasi lebih lanjut, lihat Timeouts.

• Buat pod Elastic Container Instance

  • Konfigurasikan beberapa zona untuk mencegah kegagalan pembuatan pod yang terjadi karena sumber daya tidak mencukupi di satu zona. Untuk informasi lebih lanjut, lihat Deploy pod di beberapa zona.

  • Tentukan beberapa spesifikasi untuk mencegah kegagalan pembuatan pod yang terjadi karena sumber daya tidak mencukupi dari satu spesifikasi. Untuk informasi lebih lanjut, lihat Buat pod dengan menentukan beberapa spesifikasi.

  • Gunakan metode menentukan spesifikasi vCPU dan memori untuk membuat pod. Sistem secara otomatis mencocokkan spesifikasi berdasarkan inventaris.

  • Tentukan 2 vCPU dan 4 GiB memori atau spesifikasi lebih tinggi. Instance spesifikasi ini adalah instance level perusahaan eksklusif yang dapat memberikan performa stabil.

  • Konfigurasikan kebijakan penanganan kesalahan untuk pod untuk menentukan apakah akan membuat ulang pod jika pod gagal dibuat. Untuk informasi lebih lanjut, lihat Konfigurasikan kebijakan penanganan kesalahan untuk pod.

Konfigurasi sampel:

1. Ubah eci-profile untuk mengonfigurasi beberapa zona.

   kubectl edit -n kube-system cm eci-profile

   Tentukan beberapa ID vSwitch sebagai nilai dari vSwitchIds di bagian data.

   data:
   ......
     vSwitchIds: vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf****  # Tentukan beberapa ID vSwitch untuk mengonfigurasi beberapa zona.
     vpcId: vpc-2zeghwzptn5zii0w7****
   ......

2. Gunakan beberapa kebijakan untuk meningkatkan tingkat keberhasilan saat Anda membuat pod.

   • Gunakan anotasi k8s.aliyun.com/eci-use-specs untuk menentukan beberapa spesifikasi. Dalam contoh ini, tiga spesifikasi ditentukan. Sistem mencocokkan sumber daya inventaris dari ecs.c6.large, ecs.c5.large, dan 2-4Gi secara berurutan.

   • Gunakan anotasi k8s.aliyun.com/eci-schedule-strategy untuk mengonfigurasi kebijakan penjadwalan multi-zona. Dalam contoh ini, kebijakan penjadwalan VSwitchRandom digunakan untuk menjadwalkan pod ke zona acak.

   • Gunakan parameter retryStrategy untuk mengonfigurasi kebijakan ulang alur kerja Argo. Dalam contoh ini, nilai Always ditentukan untuk mencoba ulang semua langkah yang gagal.

   • Gunakan anotasi k8s.aliyun.com/eci-fail-strategy untuk mengonfigurasi kebijakan penanganan kesalahan untuk pod. Dalam contoh ini, nilai fail-fast menentukan kegagalan cepat. Jika pod gagal dibuat, sistem melaporkan kesalahan. ProviderFailed ditampilkan sebagai status pod. Orkestrasi lapisan atas menentukan apakah akan mencoba ulang pembuatan pod atau menjadwalkan pod ke node nyata.

   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"]

Optimalkan biaya pod

Elastic Container Instance mendukung beberapa metode penagihan. Anda dapat merencanakan beban kerja berdasarkan metode penagihan yang berbeda untuk mengurangi biaya sumber daya komputasi.

Untuk informasi tentang cara mengoptimalkan biaya pod, lihat:

• Buat instance kontainer elastis preemptible

• Gunakan instance cadangan

• Gunakan rencana hemat

Percepat pembuatan pod

Sistem harus menarik gambar kontainer yang ditentukan sebelum pod dimulai. Penarikan gambar adalah operasi utama yang membutuhkan waktu lama selama startup pod karena faktor seperti kondisi jaringan atau ukuran gambar. Untuk mempercepat pembuatan pod, Elastic Container Instance menyediakan fitur cache gambar. Anda dapat membuat cache gambar untuk gambar. Kemudian, Anda dapat menggunakan cache gambar untuk membuat pod. Dengan cara ini, Anda tidak perlu mengunduh lapisan gambar atau hanya perlu mengunduh lebih sedikit lapisan gambar. Ini mempercepat pembuatan pod.

Cache gambar diklasifikasikan ke dalam jenis berikut:

• Cache gambar yang dibuat secara otomatis: Secara default, pembuatan otomatis cache gambar diaktifkan untuk instance kontainer elastis. Jika tidak ada gambar yang cocok persis saat Anda membuat pod Elastic Container Instance, sistem secara otomatis menggunakan gambar yang sesuai dengan pod untuk membuat cache gambar.

• Cache gambar yang dibuat secara manual: Anda dapat menggunakan definisi sumber daya kustom (CRD) untuk membuat cache gambar.

  Kami merekomendasikan agar Anda membuat cache gambar secara manual sebelum Anda mengeksekusi tugas Argo yang sangat konkuren. Setelah cache gambar dibuat, tentukan cache gambar dan atur kebijakan penarikan gambar pod ke IfNotPresent. Dengan cara ini, pod tidak perlu menarik gambar selama startup. Ini mempercepat pembuatan pod, mengurangi waktu jalannya tugas Argo, dan mengurangi biaya operasional. Untuk informasi lebih lanjut, lihat Gunakan ImageCache untuk mempercepat pembuatan pod.

Jika Anda melakukan operasi sebelumnya di bagian "Jadwalkan tugas Argo untuk dijalankan pada Elastic Container Instance" atau "Tingkatkan tingkat keberhasilan pembuatan pod", cache gambar dibuat. Anda dapat masuk ke Konsol Elastic Container Instance untuk memeriksa status cache gambar. Anda dapat menggunakan template YAML berikut untuk membuat alur kerja yang berisi cache gambar yang ada, lalu uji kecepatan startup 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"]

Setelah alur kerja dibuat, Anda dapat melihat ID cache gambar yang cocok di event pod alur kerja. Proses penarikan gambar dilewati saat pod dimulai.

Percepat pemuatan data

Argo digunakan di sektor inferensi AI. Dalam skenario berbasis AI, tugas komputasi memerlukan akses ke volume data yang besar. Dalam arsitektur pemisahan komputasi-penyimpanan yang populer, efisiensi pemuatan data pada node komputasi secara langsung memengaruhi waktu dan biaya untuk seluruh batch tugas. Jika sejumlah besar tugas Argo perlu mengakses data di penyimpanan secara paralel, masalah bottleneck terjadi untuk bandwidth dan performa sistem penyimpanan. Misalnya, jika tugas Argo memuat data di OSS secara paralel dan masalah bottleneck terjadi untuk bandwidth bucket OSS, node komputasi tugas Argo diblokir pada fase pemuatan data. Setiap node komputasi memerlukan waktu lebih lama. Ini memengaruhi efisiensi komputasi dan meningkatkan biaya komputasi.

Anda dapat menggunakan Fluid untuk menyelesaikan masalah ini. Sebelum Anda mengeksekusi batch tugas komputasi, Anda dapat membuat dan memuat dataset Fluid dan mempramuat data di OSS ke beberapa node cache. Lalu, Anda dapat memulai tugas Argo secara konkuren. Di Fluid, Argo membaca data dari node cache. Node cache dapat memperluas bandwidth OSS dan meningkatkan efisiensi pemuatan data node komputasi. Ini membantu meningkatkan efisiensi eksekusi tugas Argo dan mengurangi biaya operasional tugas Argo. Untuk informasi lebih lanjut, lihat Ikhtisar Fluid.

Dalam contoh berikut, 100 tugas konkuren dikonfigurasi untuk memuat file tes 10 GB dari OSS, dan hash MD5 dihitung.

1. Deploy Fluid.

   1. Masuk ke Konsol ACK.

   2. Di panel navigasi kiri, pilih Marketplace > Marketplace.

   3. Temukan ack-fluid dan klik kartu yang sesuai.

   4. Di halaman ack-fluid, klik Deploy.

   5. Di panel yang muncul, pilih klaster tempat Anda ingin menerapkan Fluid, konfigurasikan parameter, dan klik OK.

      Setelah Fluid diterapkan, Anda diarahkan ke halaman detail publikasi komponen ack-fluid. Kembali ke halaman Helm. Anda dapat melihat komponen ack-fluid dalam keadaan Deployed. Anda juga dapat menjalankan perintah kubectl untuk memeriksa apakah Fluid telah diterapkan.

      

2. Siapkan data untuk pengujian.

   Setelah Fluid diterapkan, Anda dapat menggunakan dataset Fluid untuk mempercepat data. Anda perlu mengunggah file tes 10 GB ke bucket OSS sebelum melakukan operasi selanjutnya.

   1. Buat file tes.

      dd if=/dev/zero of=/test.dat bs=1G count=10

   2. Unggah file tes ke bucket OSS. Untuk informasi lebih lanjut, lihat Unggah sederhana.

3. Buat dataset yang dipercepat.

   1. Buat dataset dan JindoRuntime.

      kubectl -n argo apply -f dataset.yaml

      Kode sampel berikut memberikan contoh file dataset.yaml. Tentukan nilai aktual untuk pasangan AccessKey dan bucket OSS di file YAML.

      apiVersion: v1
      kind: Secret
      metadata:
        name: access-key
      stringData:
        fs.oss.accessKeyId: ***************         # ID AccessKey yang digunakan untuk mengakses bucket OSS.
        fs.oss.accessKeySecret: ******************  # Rahasia AccessKey yang digunakan untuk mengakses bucket OSS.
      ---
      apiVersion: data.fluid.io/v1alpha1
      kind: Dataset
      metadata:
        name: serverless-data
      spec:
        mounts:
        - mountPoint: oss://oss-bucket-name/            # Jalur bucket OSS Anda.
          name: demo
          path: /
          options:
            fs.oss.endpoint: oss-cn-shanghai-internal.aliyuncs.com  # Titik akhir bucket 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         # Jumlah node cache JindoRuntime yang ingin Anda buat.
        podMetadata:
          annotations:
            k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge  # Tentukan spesifikasi untuk pod.
            k8s.aliyun.com/eci-image-cache: "true"
          labels:
            alibabacloud.com/eci: "true"
        worker:
          podMetadata:
            annotations:
              k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge # Tentukan spesifikasi untuk pod.
        tieredstore:
          levels:
            - mediumType: MEM # Jenis cache. Jika Anda menentukan spesifikasi yang menggunakan disk lokal, nilai ini bisa menjadi LoadRaid0
              volumeType: emptyDir
              path: /local-storage     # Jalur cache.
              quota: 12Gi              # Kapasitas maksimum cache.
              high: "0.99"             # Batas atas kapasitas penyimpanan.
              low: "0.99"              # Batas bawah kapasitas penyimpanan.

      Catatan

      Dalam contoh ini, memori dari pod Elastic Container Instance digunakan sebagai node cache. Setiap pod Elastic Container Instance menggunakan antarmuka jaringan VPC (NIC) khusus. Bandwidth setiap pod tidak terpengaruh oleh pod lainnya.

   2. Lihat hasilnya.

      • Periksa status dataset yang dipercepat. Jika nilai PHASE adalah Bound, dataset yang dipercepat telah dibuat.

        kubectl -n argo get dataset

        Output yang diharapkan:

        

      • Periksa informasi tentang pod. 10 node cache JindoRuntime dibuat menggunakan dataset yang dipercepat.

        kubectl -n argo get pods

        Output yang diharapkan:

        

4. Pemuatan data awal.

   Setelah dataset yang dipercepat dibuat, Anda dapat membuat DataLoad untuk memicu pemuatan data awal.

   1. Buat DataLoad untuk memicu pemuatan data awal.

      kubectl -n argo apply -f dataload.yaml

      Kode sampel berikut memberikan contoh file 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

   2. Periksa kemajuan pemuatan data awal pada DataLoad.

      kubectl -n argo get dataload

      Gambar berikut menunjukkan contoh output. File tes berukuran 10 GB, tetapi kecepatan pemuatan sangat cepat.

      

5. Jalankan alur kerja Argo.

   Setelah data dimuat, Anda dapat menjalankan tugas Argo secara konkuren. Kami merekomendasikan agar Anda menggunakan fitur cache gambar bersama dengan Fluid untuk menguji alur kerja Argo.

   1. Siapkan file konfigurasi argo-test.yaml untuk alur kerja Argo.

      Kode sampel berikut memberikan contoh file 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

   2. Buat alur kerja Argo.

      argo -n argo submit argo-test.yaml

   3. Lihat hasil eksekusi alur kerja.

      argo -n argo list

      Output yang diharapkan:

      

      Jalankan perintah kubectl get pod -n argo --watch untuk melihat kemajuan eksekusi tugas. 100 tugas Argo dalam skenario sampel diselesaikan dalam waktu 2 hingga 4 menit.

      

      Jika Fluid tidak digunakan untuk rangkaian tugas Argo yang sama, diperlukan waktu 14 hingga 15 menit untuk memuat file tes 10 GB dari OSS dan menghitung hash MD5.

      

      Hasil pengujian menunjukkan bahwa Fluid dapat meningkatkan efisiensi komputasi dan mengurangi biaya komputasi.