Gunakan ECI untuk menjalankan alur kerja Argo - Elastic Container Instance

Kubernetes tanpa server menawarkan elastisitas tingkat pod dengan keunggulan seperti startup dalam hitungan detik, penagihan per detik, dan konkurensi hingga 2.000 pod per menit, sehingga menjadi pilihan yang semakin populer untuk menjalankan Argo. Topik ini menjelaskan cara menjalankan alur kerja Argo di Elastic Container Instance (ECI) menggunakan kluster Alibaba Cloud Container Service for Kubernetes (ACK).

Siapkan Kubernetes dan Argo

Siapkan kluster Alibaba Cloud Serverless Kubernetes.
- (Direkomendasikan) Buat kluster ACK Serverless. Untuk informasi selengkapnya, lihat Buat kluster ACK Serverless.
- Buat kluster ACK yang dikelola dan deploy controller ack-virtual-node untuk membuat node virtual. Untuk informasi selengkapnya, lihat Buat kluster ACK yang dikelola dan Deploy controller node virtual dan gunakan untuk membuat pod berbasis Elastic Container Instance.
Deploy Argo di kluster Kubernetes.
- (Direkomendasikan) Instal komponen ack-workflow. Untuk informasi selengkapnya, lihat Argo Workflows.
- Deploy Argo secara manual. Untuk informasi selengkapnya, lihat Argo Quick Start.
Instal CLI Argo. Untuk informasi selengkapnya, lihat argo-workflows.

Optimalkan konfigurasi resource dasar

Secara default, setelah Anda mendeploy Argo, permintaan dan batas resource tidak ditentukan untuk pod komponen inti argo-server dan workflow-controller. Hal ini memberikan kelas Quality of Service (QoS) yang rendah pada pod tersebut, sehingga rentan terhadap pembunuhan Out of Memory (OOM) atau eviksi pod ketika resource kluster tidak mencukupi. Kami merekomendasikan agar Anda menyesuaikan resources untuk kedua pod komponen ini berdasarkan skala kluster Anda. Sebagai titik awal, atur permintaan atau batasnya menjadi minimal 2 vCPU dan memori 4 GiB.

Gunakan OSS sebagai repositori artefak

Secara default, Argo menggunakan MinIO sebagai repositori artefaknya. Di lingkungan produksi, stabilitas repositori artefak sangat penting. Komponen ack-workflow mendukung penggunaan Alibaba Cloud Object Storage Service (OSS) sebagai repositori artefak yang tahan lama dan andal. Untuk petunjuk cara mengonfigurasi OSS sebagai repositori artefak Anda, lihat Mengonfigurasi Alibaba Cloud OSS.

Setelah konfigurasi selesai, gunakan contoh berikut untuk membuat alur kerja dan memverifikasi pengaturannya.

Simpan konten berikut sebagai 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"]

Buat alur kerja tersebut.
```
argo -n argo submit workflow-oss.yaml
```

Lihat hasil eksekusi alur kerja.

argo -n argo list

Output yang diharapkan:

s@xxxxxxxxxid:~$ argo -n argo list
NAME                    STATUS      AGE   DURATION   PRIORITY   MESSAGE
artifact-passing-2746t  Succeeded   3m    30s        0

Pilih executor

Setiap pod pekerja Argo berisi minimal dua kontainer:

Kontainer main

Ini adalah kontainer aplikasi tempat logika bisnis Anda berjalan.
Kontainer wait

Argo menyuntikkan komponen sistem ini ke dalam pod sebagai sidecar. Tanggung jawab utamanya adalah:
- Fase startup
  - Memuat artefak dan input yang dibutuhkan oleh kontainer main.
- Fase berjalan
  - Menunggu kontainer main keluar, lalu menghentikan semua kontainer sidecar terkait.
  - Mengumpulkan output dan artefak dari kontainer main serta melaporkan statusnya.

Executor bertindak sebagai jembatan yang memungkinkan kontainer wait mengakses dan mengontrol kontainer main. Argo mengabstraksikan hal ini ke dalam antarmuka ContainerRuntimeExecutor, yang mendefinisikan operasi berikut:

GetFileContents: Mendapatkan parameter output (outputs/parameters) dari kontainer main.
CopyFile: Mendapatkan artefak output (outputs/artifacts) dari kontainer main.
GetOutputStream: Mendapatkan output standar (termasuk error standar) dari kontainer main.
Wait: Menunggu kontainer main keluar.
Kill: Menghentikan kontainer sidecar terkait.
ListContainerNames: Menampilkan daftar nama kontainer dalam pod.

Argo mendukung beberapa executor dengan mekanisme dasar berbeda, yang semuanya dirancang untuk arsitektur Kubernetes standar. Karena arsitektur Kubernetes tanpa server berbeda dari Kubernetes standar, Anda harus memilih executor yang kompatibel. Kami merekomendasikan penggunaan executor Emissary untuk menjalankan Argo di lingkungan Kubernetes tanpa server. Tabel berikut merinci executor yang tersedia:

Executor	Deskripsi
Emissary	Berfungsi dengan berbagi file melalui volume `emptyDir`. Executor ini direkomendasikan karena hanya bergantung pada kemampuan standar `emptyDir` dan tidak memiliki dependensi lain.
Kubernetes API	Menggunakan Kubernetes API, tetapi fungsionalitasnya tidak lengkap. Karena executor ini menawarkan fungsionalitas yang tidak lengkap dan dapat memberi tekanan pada lapisan kontrol Kubernetes dalam skala besar, executor ini tidak direkomendasikan.
PNS	Mengandalkan berbagi namespace proses (PID) dan `chroot` dalam pod. Pendekatan ini mengotori ruang proses pod dan memerlukan hak istimewa. Kubernetes tanpa server menerapkan tingkat isolasi keamanan yang lebih tinggi dan tidak mendukung kontainer dengan hak istimewa. Oleh karena itu, executor ini tidak kompatibel.
Docker	Menggunakan CLI Docker untuk menjalankan fungsinya, yang memerlukan akses langsung ke runtime kontainer Docker yang mendasari. Karena Kubernetes tanpa server tidak mengekspos node yang mendasari, Anda tidak dapat mengakses daemon Docker di node tersebut. Oleh karena itu, executor ini tidak kompatibel.
Kubelet	Menggunakan Kubelet Client API untuk menjalankan fungsinya, yang memerlukan akses ke komponen Kubelet di node yang mendasari. Karena Kubernetes tanpa server tidak mengekspos node yang mendasari, Anda tidak dapat mengakses komponen Kubelet. Oleh karena itu, executor ini tidak kompatibel.

Jadwalkan tugas Argo ke ECI

Kluster ACK Serverless secara otomatis menjadwalkan semua pod ke ECI, sehingga tidak diperlukan konfigurasi tambahan. Untuk kluster ACK yang dikelola, Anda harus mengonfigurasinya agar menjadwalkan pod ke ECI. Untuk informasi selengkapnya, lihat Jadwalkan pod ke node virtual berbasis x86.

Contoh YAML berikut menunjukkan cara menggunakan label untuk penjadwalan:

Tambahkan label alibabacloud.com/eci: "true": Label ini secara otomatis menjadwalkan pod ke ECI.
(Opsional) Tentukan {"schedulerName": "eci-scheduler"}: Ini direkomendasikan. Selama upgrade atau perubahan node virtual, admission webhook mungkin sementara tidak tersedia. Pengaturan ini mencegah pod dijadwalkan ke node biasa selama periode ketidaktersediaan sementara tersebut.

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

Tingkatkan tingkat keberhasilan pembuatan pod

Di lingkungan produksi, alur kerja Argo sering melibatkan banyak pod komputasi. Kegagalan satu pod saja dapat menyebabkan seluruh alur kerja gagal. Jika tingkat keberhasilan alur kerja Anda rendah, Anda mungkin perlu melakukan beberapa kali rerun, yang berdampak pada efisiensi eksekusi dan meningkatkan biaya. Oleh karena itu, Anda harus menerapkan strategi untuk meningkatkan tingkat keberhasilan pembuatan pod:

Dalam definisi alur kerja Argo Anda:
- Konfigurasikan kebijakan retry Argo untuk secara otomatis mencoba ulang langkah yang gagal. Untuk informasi selengkapnya, lihat Retries.
- Konfigurasikan timeout alur kerja untuk membatasi durasi total eksekusi alur kerja. Untuk informasi selengkapnya, lihat Timeouts.
Saat membuat pod ECI:
- Konfigurasikan beberapa zona untuk mencegah kegagalan pembuatan pod akibat inventaris yang tidak mencukupi di satu zona. Untuk informasi selengkapnya, lihat Deploy pod di beberapa zona.
- Tentukan beberapa spesifikasi instans untuk menghindari kegagalan pembuatan akibat inventaris yang tidak mencukupi untuk tipe instans tertentu. Untuk informasi selengkapnya, lihat Buat pod dengan menentukan beberapa spesifikasi.
- Tentukan kebutuhan vCPU dan memori alih-alih tipe instans tertentu. ECI secara otomatis mencocokkan permintaan Anda dengan spesifikasi instans yang tersedia berdasarkan inventaris saat ini.
- Gunakan spesifikasi instans dengan minimal 2 vCPU dan memori 4 GiB. Ini adalah instans kelas enterprise dengan resource khusus, yang menjamin performa stabil.
- Konfigurasikan kebijakan penanganan kesalahan pod untuk menentukan apakah akan mencoba ulang pembuatan pod jika gagal. Untuk informasi selengkapnya, lihat Konfigurasikan kebijakan penanganan kesalahan untuk pod.

Berikut adalah contoh konfigurasi:

Edit ConfigMap eci-profile untuk mengonfigurasi beberapa zona.

kubectl edit -n kube-system cm eci-profile

Pada bagian data, konfigurasikan vSwitchIds dengan ID beberapa vSwitch:

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

Gunakan beberapa strategi untuk meningkatkan tingkat keberhasilan saat membuat pod.
- Gunakan anotasi k8s.aliyun.com/eci-use-specs untuk menentukan beberapa spesifikasi instans. Dalam contoh ini, tiga spesifikasi dicantumkan. ECI akan mencoba mencocokkannya secara berurutan: ecs.c6.large, ecs.c5.large, lalu 2-4Gi (2 vCPU, memori 4 GiB).
- Gunakan anotasi k8s.aliyun.com/eci-schedule-strategy untuk mengatur strategi penjadwalan multi-zona. Contoh ini menggunakan VSwitchRandom, yang menjadwalkan pod secara acak di zona yang telah dikonfigurasi.
- Konfigurasikan retryStrategy untuk mengatur kebijakan retry Argo. Contoh ini menetapkan retryPolicy: "Always", yang mencoba ulang semua langkah yang gagal.
- Gunakan anotasi k8s.aliyun.com/eci-fail-strategy untuk mengatur kebijakan penanganan kesalahan pod. Contoh ini menggunakan fail-fast. Jika pembuatan pod gagal, sistem segera melaporkan error, dan status pod menjadi ProviderFailed. Sistem orkestrasi tingkat atas kemudian dapat memutuskan apakah akan mencoba ulang atau menjadwalkan pod ke node biasa.
```
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

ECI mendukung beberapa metode penagihan. Dengan memilih metode penagihan yang tepat untuk workload Anda, Anda dapat secara signifikan mengurangi biaya komputasi.

Untuk informasi selengkapnya tentang metode optimasi biaya, lihat topik berikut:

Percepat pembuatan pod

Waktu startup pod sering didominasi oleh proses pull image, yang bergantung pada ukuran image dan kecepatan jaringan. Untuk mempercepat pembuatan pod, ECI menyediakan fitur cache gambar. Dengan membuat cache gambar dari sebuah image terlebih dahulu, Anda dapat mengurangi atau menghilangkan waktu unduh untuk pod berikutnya yang menggunakan cache tersebut.

Terdapat dua jenis cache gambar:

Pembuatan otomatis: Fitur ini diaktifkan secara default di ECI. Saat Anda membuat pod ECI, jika cache gambar yang persis sama tidak ditemukan, ECI secara otomatis membuatnya dari image pod tersebut.
Pembuatan manual: Anda dapat membuat cache gambar secara manual menggunakan Custom Resource Definition (CRD).

Kami merekomendasikan agar Anda membuat cache gambar secara manual sebelum menjalankan tugas Argo dengan konkurensi tinggi. Setelah cache gambar dibuat, Anda dapat menentukannya dalam definisi pod dan mengatur kebijakan pull image pod menjadi IfNotPresent. Hal ini memungkinkan pod melewati langkah pull image saat startup, mempercepat pembuatan pod, mengurangi durasi tugas Argo, dan menurunkan biaya operasional. Untuk informasi selengkapnya, lihat Gunakan ImageCache untuk mempercepat pembuatan pod.

Jika Anda telah menjalankan contoh sebelumnya, ECI telah secara otomatis membuat cache gambar untuk Anda. Anda dapat login ke Konsol Elastic Container Instance untuk memeriksa status cache gambar. Anda dapat menggunakan YAML berikut untuk membuat alur kerja yang memanfaatkan cache yang ada dan menguji 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 memeriksa event pod ECI untuk melihat ID cache gambar yang cocok. Event tersebut juga menunjukkan bahwa proses pull image dilewati selama startup 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

Percepat pemuatan data

Argo banyak digunakan dalam inferensi AI, di mana tugas-tugasnya sering mengakses dataset besar. Dalam arsitektur pemisahan komputasi dan penyimpanan, efisiensi pemuatan data secara langsung memengaruhi durasi dan biaya tugas. Akses data konkuren dari banyak tugas Argo dapat menciptakan bottleneck penyimpanan. Misalnya, ketika tugas Argo konkuren memuat data dari OSS dan bandwidth bucket OSS terjenuhkan, setiap node komputasi akan terblokir pada tahap pemuatan data. Hal ini meningkatkan durasi tugas dan biaya komputasi sekaligus mengurangi efisiensi.

Fluid, layanan akselerasi data, menyelesaikan masalah ini. Sebelum menjalankan komputasi batch, Anda dapat membuat dan memuat awal dataset Fluid. Hal ini menyimpan data dari OSS ke sejumlah kecil node cache. Kemudian, Anda dapat menjalankan tugas Argo konkuren Anda. Tugas Argo tersebut kemudian membaca data dari node cache alih-alih langsung dari OSS. Node cache secara efektif memperluas bandwidth yang tersedia dari OSS, meningkatkan efisiensi pemuatan data untuk node komputasi. Pendekatan ini meningkatkan performa tugas Argo dan mengurangi biaya operasional. Untuk informasi selengkapnya tentang Fluid, lihat Ikhtisar Fluid.

Contoh berikut menunjukkan cara menggunakan Fluid untuk memuat file uji 10 GB dari OSS dan menghitung hash MD5-nya melalui 100 tugas konkuren.

Deploy Fluid.
1. Login ke Konsol ACK.
2. Di panel navigasi sebelah kiri, pilih Marketplace>Marketplace.
3. Temukan dan klik kartu ack-fluid.
4. Di halaman ack-fluid, klik Deploy.
5. Di panel yang muncul, pilih kluster target Anda, konfigurasikan parameter, lalu klik OK.
  
  Setelah deployment selesai, Anda akan diarahkan ke halaman detail rilis untuk ack-fluid. Jika Anda kembali ke halaman Helm, Anda dapat melihat bahwa status ack-fluid adalah Deployed. Anda juga dapat menjalankan perintah kubectl untuk memverifikasi bahwa Fluid berhasil dideploy.
```
~$ 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
```
Siapkan data uji.

Setelah Fluid dideploy, gunakan dataset Fluid untuk mempercepat akses data. Sebelum melanjutkan, unggah file uji 10 GB ke bucket OSS Anda.
1. Hasilkan file uji.
```
dd if=/dev/zero of=/test.dat bs=1G count=10
```
2. Unggah file uji ke bucket OSS Anda. Untuk informasi selengkapnya, lihat Simple upload.

Buat dataset yang dipercepat.

Buat resource Dataset dan JindoRuntime.

kubectl -n argo apply -f dataset.yaml

Berikut adalah contoh file dataset.yaml. Ganti placeholder AccessKey dan informasi bucket OSS dengan nilai Anda.

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ***************         # ID AccessKey yang memiliki izin untuk mengakses bucket OSS.
  fs.oss.accessKeySecret: ******************  # Rahasia AccessKey yang memiliki izin untuk mengakses bucket OSS.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: serverless-data
spec:
  mounts:
  - mountPoint: oss://oss-bucket-name/            # Path ke 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 akan dibuat.
  podMetadata:
    annotations:
      k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge  # Tentukan spesifikasi instans yang sesuai.
      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 instans yang sesuai.
  tieredstore:
    levels:
      - mediumtype: MEM          # Jenis media cache. Gunakan MEM untuk memori, atau LoadRaid0 jika Anda menentukan instans dengan disk lokal.
        volumeType: emptyDir
        path: /local-storage     # Path cache.
        quota: 12Gi              # Kapasitas cache maksimum.
        high: "0.99"             # Watermark tinggi untuk kapasitas penyimpanan.
        low: "0.99"              # Watermark rendah untuk kapasitas penyimpanan.

Catatan

Contoh ini menggunakan memori pod ECI sebagai node cache data. Karena setiap pod ECI memiliki antarmuka jaringan VPC khusus, bandwidth-nya tidak terpengaruh oleh pod lain.

Lihat hasilnya.

Periksa status dataset. PHASE bernilai Bound menunjukkan pembuatan berhasil.

kubectl -n argo get dataset

Output yang diharapkan:

$ 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

Periksa informasi pod. Anda dapat melihat bahwa 10 node cache JindoRuntime telah dibuat oleh dataset.

kubectl -n argo get pods

Output yang diharapkan:

~$ 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

Muat data terlebih dahulu.

Setelah dataset siap, buat resource DataLoad untuk memicu pemuatan awal data.

Buat resource DataLoad untuk memicu pemuatan awal data.

kubectl -n argo apply -f dataload.yaml

Berikut adalah 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

Periksa progres operasi DataLoad.

kubectl -n argo get dataload

Output yang diharapkan menunjukkan bahwa meskipun file uji berukuran 10 GB, proses pemuatan awal data sangat cepat.

:~$ kubectl -n argo get dataload
NAME                      DATASET          PHASE      AGE   DURATION
serverless-data-warmup    serverless-data  Complete   30s   14s

Jalankan alur kerja Argo.

Setelah data dimuat, Anda dapat menjalankan tugas Argo konkuren. Untuk hasil terbaik, kombinasikan pendekatan ini dengan cache gambar.

Siapkan file konfigurasi alur kerja Argo, argo-test.yaml.

Berikut adalah 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

Buat alur kerja tersebut.
```
argo -n argo submit argo-test.yaml
```

Lihat hasil eksekusi alur kerja.

argo -n argo list

Output yang diharapkan:

xxx i:~$ argo -n argo list
NAME                     STATUS    AGE   DURATION  PRIORITY  MESSAGE
parallelism-fluid-56g2q  Running   8s    8s        0

Anda dapat menggunakan perintah kubectl get pod -n argo --watch untuk memantau progres eksekusi pod. Dalam contoh ini, 100 tugas Argo selesai dalam waktu sekitar 2 hingga 4 menit.

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

Sebagai perbandingan, menjalankan tugas Argo yang sama tanpa akselerasi data—memuat file uji 10 GB langsung dari OSS—membutuhkan waktu sekitar 14 hingga 15 menit untuk menghitung hash MD5.

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

Perbandingan ini menunjukkan bahwa Fluid meningkatkan efisiensi komputasi dan secara signifikan mengurangi biaya.