Todos os produtos
Search

Este produto

    Elastic Container Instance:Execute workflows do Argo no ECI

    Central de documentação

    Elastic Container Instance:Execute workflows do Argo no ECI

    Última atualização: Jun 28, 2026

    O Serverless Kubernetes oferece elasticidade no nível de pod, com benefícios como inicialização em segundos, faturamento por segundo e alta concorrência de 2.000 pods por minuto. Essas características tornam essa solução uma escolha cada vez mais popular para executar o Argo. Este tópico descreve como executar workflows do Argo no Elastic Container Instance (ECI) usando um cluster do Alibaba Cloud Container Service for Kubernetes (ACK).

    Configure o Kubernetes e o Argo

    1. Configure um cluster Serverless Kubernetes da Alibaba Cloud.

    2. Implante o Argo no cluster Kubernetes.

    3. Instale a CLI do Argo. Para obter mais informações, consulte argo-workflows.

    Otimize as configurações básicas de recursos

    Por padrão, após a implantação do Argo, os pods dos componentes principais argo-server e workflow-controller não possuem solicitações nem limites de recursos definidos. Isso atribui aos pods uma classe de Qualidade de Serviço (QoS) baixa, tornando-os suscetíveis a encerramentos por falta de memória (OOM) ou evicções quando os recursos do cluster forem insuficientes. Recomendamos ajustar os resources desses dois pods de componentes com base na escala do seu cluster. Como ponto de partida, defina as solicitações ou limites para 2 vCPU e 4 GiB de memória ou mais.

    Use o OSS como repositório de artefatos

    Por padrão, o Argo usa o MinIO como repositório de artefatos. Em um ambiente de produção, a estabilidade desse repositório é crítica. O componente ack-workflow permite usar o Alibaba Cloud Object Storage Service (OSS) como um repositório de artefatos durável e confiável. Para obter instruções sobre como configurar o OSS como seu repositório de artefatos, consulte Configurar o Alibaba Cloud OSS.

    Após concluir a configuração, use o exemplo a seguir para criar um workflow e verificar a configuração.

    1. Salve o conteúdo a seguir como 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"]

    2. Crie o workflow.

      argo -n argo submit workflow-oss.yaml

    3. Visualize o resultado da execução do workflow.

      argo -n argo list

      Saída esperada:

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

    Escolha um executor

    Cada pod worker do Argo contém pelo menos dois contêineres:

    • O contêiner main

      Este é o contêiner da sua aplicação, onde a lógica de negócios é executada.

    • O contêiner wait

      O Argo injeta este componente de sistema no pod como um sidecar. Suas responsabilidades principais são:

      • Fase de inicialização

        • Carregar artefatos e entradas dos quais o contêiner main depende.

      • Fase de execução

        • Aguardar a saída do contêiner main e, em seguida, encerrar quaisquer contêineres sidecar associados.

        • Coletar saídas e artefatos do contêiner main e relatar seu status.

    O executor atua como uma ponte, permitindo que o contêiner wait acesse e controle o contêiner main. O Argo abstrai isso na interface ContainerRuntimeExecutor, que define as seguintes operações:

    • GetFileContents: Obtém parâmetros de saída (outputs/parameters) do contêiner main.

    • CopyFile: Obtém artefatos de saída (outputs/artifacts) do contêiner main.

    • GetOutputStream: Obtém a saída padrão (incluindo erro padrão) do contêiner main.

    • Wait: Aguarda a saída do contêiner main.

    • Kill: Encerra contêineres sidecar associados.

    • ListContainerNames: Lista os nomes dos contêineres dentro do pod.

    O Argo suporta vários executores com diferentes mecanismos subjacentes, todos projetados para arquiteturas Kubernetes padrão. Como a arquitetura do Serverless Kubernetes difere do Kubernetes padrão, você deve escolher um executor compatível. Recomendamos o uso do executor Emissary para executar o Argo em um ambiente Serverless Kubernetes. A tabela a seguir detalha os executores disponíveis:

    Executor

    Descrição

    Emissary

    Funciona compartilhando arquivos por meio de um volume emptyDir.

    Este executor é recomendado porque depende apenas da capacidade padrão emptyDir e não possui outras dependências.

    Kubernetes API

    Usa a API do Kubernetes, mas sua funcionalidade é incompleta.

    Como este executor oferece funcionalidade incompleta e pode sobrecarregar o plano de controle do Kubernetes em escala, seu uso não é recomendado.

    PNS

    Baseia-se no compartilhamento de namespace de processo (PID) e chroot dentro do pod. Essa abordagem polui o espaço de processo do pod e exige privilégios.

    O Serverless Kubernetes impõe um nível mais alto de isolamento de segurança e não suporta contêineres privilegiados. Portanto, este executor é incompatível.

    Docker

    Utiliza a CLI do Docker para executar suas funções, o que requer acesso direto ao runtime de contêiner Docker subjacente.

    Como o Serverless Kubernetes não expõe os nós subjacentes, não é possível acessar o daemon do Docker no nó. Portanto, este executor é incompatível.

    Kubelet

    Utiliza a API do Cliente Kubelet para executar suas funções, o que requer acesso ao componente Kubelet subjacente no nó.

    Como o Serverless Kubernetes não expõe os nós subjacentes, não é possível acessar o componente Kubelet. Portanto, este executor é incompatível.

    Agende tarefas do Argo para o ECI

    Um cluster ACK Serverless agenda automaticamente todos os pods para o ECI, portanto, nenhuma configuração extra é necessária. Para um cluster gerenciado pelo ACK, é necessário configurá-lo para agendar pods para o ECI. Para obter mais informações, consulte Agendar pods para um nó virtual baseado em x86.

    O exemplo YAML a seguir demonstra como usar um rótulo para agendamento:

    • Adicione o rótulo alibabacloud.com/eci: "true": Este rótulo agenda automaticamente o pod para o ECI.

    • (Opcional) Especifique {"schedulerName": "eci-scheduler"}: Esta configuração é recomendada. Durante uma atualização ou alteração do nó virtual, o webhook de admissão pode ficar brevemente indisponível. Essa definição impede que os pods sejam agendados para nós regulares durante essa indisponibilidade temporária.

    apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: parallelism-limit1-
spec:
  entrypoint: parallelism-limit1
  parallelism: 10
  podSpecPatch: '{"schedulerName": "eci-scheduler"}'  # Schedule the pod to ECI.
  podMetadata:
    labels:
      alibabacloud.com/eci: "true"   # Use a label to schedule the pod to 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"]

    Aumente a taxa de sucesso na criação de pods

    Em um ambiente de produção, um workflow do Argo geralmente envolve vários pods de computação. A falha de qualquer pod individual pode causar a falha de todo o workflow. Se a taxa de sucesso do seu workflow for baixa, talvez seja necessário realizar várias reexecuções, o que impacta a eficiência da execução e aumenta os custos. Portanto, adote estratégias para melhorar a taxa de sucesso na criação de pods:

    • Na definição do seu workflow do Argo:

      • Configure uma política de nova tentativa do Argo para repetir automaticamente as etapas com falha. Para obter mais informações, consulte Novas tentativas.

      • Configure um tempo limite de workflow para limitar o tempo total de execução. Para obter mais informações, consulte Tempos limite.

    • Ao criar pods do ECI:

      • Configure múltiplas zonas para evitar falhas na criação de pods devido a estoque insuficiente em uma única zona. Para obter mais informações, consulte Implantar pods em múltiplas zonas.

      • Especifique múltiplas especificações de instância para evitar falhas de criação devido a estoque insuficiente de um tipo específico de instância. Para obter mais informações, consulte Criar pods especificando múltiplas especificações.

      • Especifique requisitos de vCPU e memória em vez de um tipo de instância específico. O ECI corresponde automaticamente sua solicitação a uma especificação de instância disponível com base no estoque atual.

      • Utilize especificações de instância com 2 vCPU e 4 GiB de memória ou mais. Trata-se de instâncias de nível empresarial com recursos dedicados, o que garante desempenho estável.

      • Configure uma política de tratamento de falhas de pod para definir se a criação do pod deve ser tentada novamente em caso de falha. Para obter mais informações, consulte Configurar uma política de tratamento de falhas para um pod.

    Veja um exemplo de configuração:

    1. Edite o ConfigMap eci-profile para configurar múltiplas zonas.

      kubectl edit -n kube-system cm eci-profile

      Na seção data, configure vSwitchIds com os IDs de múltiplos vSwitches:

      data:
  # ...other configurations...
  vSwitchIds: vsw-2ze23nqzig8inprou****,vsw-2ze94pjtfuj9vaymf****  # Specify multiple vSwitch IDs to configure multiple zones.
  vpcId: vpc-2zeghwzptn5zii0w7****
  # ...other configurations...

    2. Use múltiplas estratégias para melhorar a taxa de sucesso ao criar um pod.

      • Utilize a anotação k8s.aliyun.com/eci-use-specs para especificar múltiplas especificações de instância. Neste exemplo, três especificações estão listadas. O ECI tenta correspondê-las em ordem: ecs.c6.large, ecs.c5.large e, em seguida, 2-4Gi (2 vCPU, 4 GiB de memória).

      • Utilize a anotação k8s.aliyun.com/eci-schedule-strategy para definir a estratégia de agendamento multizona. Este exemplo usa VSwitchRandom, que agenda pods aleatoriamente nas zonas configuradas.

      • Configure retryStrategy para definir a política de nova tentativa do Argo. Este exemplo define retryPolicy: "Always", que repete todas as etapas com falha.

      • Utilize a anotação k8s.aliyun.com/eci-fail-strategy para definir a política de tratamento de falhas do pod. Este exemplo usa fail-fast. Se a criação do pod falhar, o sistema relata imediatamente um erro e o status do pod torna-se ProviderFailed. O sistema de orquestração de nível superior pode então decidir se deve tentar novamente ou agendar o pod para um nó regular.

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

    Otimize os custos dos pods

    O ECI suporta vários métodos de faturamento. Ao escolher o método de faturamento adequado para sua carga de trabalho, é possível reduzir significativamente seus custos de computação.

    Para obter mais informações sobre métodos de otimização de custos, consulte os seguintes tópicos:

    Acelere a criação de pods

    O tempo de inicialização de um pod é frequentemente dominado pelo pull da imagem, um processo dependente do tamanho da imagem e da velocidade da rede. Para acelerar a criação de pods, o ECI fornece um recurso de cache de imagem. Ao criar um cache de imagem a partir de uma imagem antecipadamente, você reduz ou elimina o tempo de download para pods subsequentes que utilizam esse cache.

    Existem dois tipos de caches de imagem:

    • Criação automática: Este recurso está habilitado por padrão no ECI. Quando você cria um pod do ECI, se um cache de imagem exato não for encontrado, o ECI cria automaticamente um a partir da imagem do pod.

    • Criação manual: É possível criar caches de imagem manualmente usando uma Definição de Recurso Personalizado (CRD).

      Recomendamos criar manualmente um cache de imagem antes de executar tarefas do Argo de alta concorrência. Após a criação do cache de imagem, especifique-o na definição do seu pod e defina a política de pull de imagem do pod como IfNotPresent. Isso permite que o pod pule a etapa de pull de imagem durante a inicialização, acelerando a criação do pod, reduzindo o tempo de execução das tarefas do Argo e diminuindo os custos operacionais. Para obter mais informações, consulte Usar ImageCache para acelerar a criação de pods.

    Se você já executou os exemplos anteriores, o ECI criou automaticamente um cache de imagem para você. Faça login no console do Elastic Container Instance para verificar o status do cache de imagem. Use o YAML a seguir para criar um workflow que aproveite o cache existente e teste a velocidade de inicialização do 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"]

    Após a criação do workflow, verifique os eventos do pod do ECI para ver o ID do cache de imagem correspondente. Os eventos também mostram que o processo de pull de imagem foi ignorado durante a inicialização do 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

    Acelere o carregamento de dados

    O Argo é amplamente utilizado em inferência de IA, onde as tarefas frequentemente acessam grandes conjuntos de dados. Em arquiteturas de separação entre computação e armazenamento, a eficiência do carregamento de dados impacta diretamente a duração e o custo da tarefa. O acesso simultâneo a dados por muitas tarefas do Argo pode criar um gargalo de armazenamento. Por exemplo, quando tarefas concorrentes do Argo carregam dados do OSS e a largura de banda do bucket do OSS fica saturada, cada nó de computação fica bloqueado na etapa de carregamento de dados. Isso aumenta a duração da tarefa e os custos de computação, além de reduzir a eficiência.

    O Fluid, um serviço de aceleração de dados, resolve esse problema. Antes de executar uma computação em lote, crie e pré-carregue um conjunto de dados do Fluid. Isso pré-armazena em cache os dados do OSS em um pequeno número de nós de cache. Em seguida, inicie suas tarefas concorrentes do Argo. As tarefas do Argo leem dados dos nós de cache em vez de ler diretamente do OSS. Os nós de cache expandem efetivamente a largura de banda disponível do OSS, melhorando a eficiência do carregamento de dados para os nós de computação. Essa abordagem aumenta o desempenho das tarefas do Argo e reduz os custos de execução. Para obter mais informações sobre o Fluid, consulte Visão geral do Fluid.

    O exemplo a seguir demonstra como usar o Fluid para carregar um arquivo de teste de 10 GB do OSS e calcular seu hash MD5 em 100 tarefas concorrentes.

    1. Implante o Fluid.

      1. Faça login no console do ACK.

      2. No painel de navegação à esquerda, escolha Marketplace>Marketplace.

      3. Localize e clique em no cartão ack-fluid.

      4. Na página ack-fluid, clique em Deploy.

      5. No painel exibido, selecione seu cluster de destino, configure os parâmetros e clique em OK.

        Após a conclusão da implantação, você será redirecionado para a página de detalhes da versão do ack-fluid. Se retornar à página Helm, você verá que o status do ack-fluid é Deployed. Também é possível executar um comando kubectl para verificar se o Fluid foi implantado com sucesso.

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

    2. Prepare os dados de teste.

      Após implantar o Fluid, use um conjunto de dados do Fluid para acelerar o acesso aos dados. Antes de prosseguir, faça upload de um arquivo de teste de 10 GB para o seu bucket do OSS.

      1. Gere um arquivo de teste.

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

      2. Faça upload do arquivo de teste para o seu bucket do OSS. Para obter mais informações, consulte Upload simples.

    3. Crie um conjunto de dados acelerado.

      1. Crie os recursos Dataset e JindoRuntime.

        kubectl -n argo apply -f dataset.yaml

        Veja um exemplo do arquivo dataset.yaml. Substitua as informações de AccessKey e bucket do OSS pelos seus valores.

        apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ***************         # The AccessKey ID that has permissions to access the OSS bucket.
  fs.oss.accessKeySecret: ******************  # The AccessKey secret that has permissions to access the OSS bucket.
---
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: serverless-data
spec:
  mounts:
  - mountPoint: oss://oss-bucket-name/            # The path to your OSS bucket.
    name: demo
    path: /
    options:
      fs.oss.endpoint: oss-cn-shanghai-internal.aliyuncs.com  # The endpoint of the OSS bucket.
    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         # The number of JindoRuntime cache nodes to create.
  podMetadata:
    annotations:
      k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge  # Specify a suitable instance specification.
      k8s.aliyun.com/eci-image-cache: "true"
    labels:
      alibabacloud.com/eci: "true"
  worker:
    podMetadata:
      annotations:
        k8s.aliyun.com/eci-use-specs: ecs.g6.2xlarge # Specify a suitable instance specification.
  tieredstore:
    levels:
      - mediumtype: MEM          # Cache medium type. Use MEM for memory, or LoadRaid0 if you specify an instance with local disks.
        volumeType: emptyDir
        path: /local-storage     # Cache path.
        quota: 12Gi              # Maximum cache capacity.
        high: "0.99"             # High watermark for storage capacity.
        low: "0.99"              # Low watermark for storage capacity.
        Nota

        Este exemplo usa a memória dos pods do ECI como nós de cache de dados. Como cada pod do ECI possui uma interface de rede VPC dedicada, sua largura de banda não é afetada por outros pods.

      2. Visualize os resultados.

        • Verifique o status do conjunto de dados. Um PHASE com valor Bound indica criação bem-sucedida.

          kubectl -n argo get dataset

          Saída esperada:

          $ 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

        • Verifique as informações dos pods. Você pode ver que 10 nós de cache do JindoRuntime foram criados pelo conjunto de dados.

          kubectl -n argo get pods

          Saída esperada:

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

    4. Pré-carregue os dados.

      Depois que o conjunto de dados estiver pronto, crie um recurso DataLoad para acionar o pré-carregamento de dados.

      1. Crie um recurso DataLoad para acionar o pré-carregamento de dados.

        kubectl -n argo apply -f dataload.yaml

        Veja um exemplo do arquivo 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. Verifique o progresso da operação DataLoad.

        kubectl -n argo get dataload

        A saída esperada mostra que, embora o arquivo de teste tenha 10 GB, o processo de pré-carregamento de dados é muito rápido.

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

    5. Execute o workflow do Argo.

      Após o pré-carregamento dos dados, execute as tarefas concorrentes do Argo. Para obter melhores resultados, combine essa abordagem com um cache de imagem.

      1. Prepare o arquivo de configuração do workflow do Argo, argo-test.yaml.

        Veja um exemplo do arquivo 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. Crie o workflow.

        argo -n argo submit argo-test.yaml

      3. Visualize o resultado da execução do workflow.

        argo -n argo list

        Saída esperada:

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

        Use o comando kubectl get pod -n argo --watch para monitorar o progresso da execução dos pods. Neste exemplo, as 100 tarefas do Argo são concluídas em cerca de 2 a 4 minutos.

        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

        Em contraste, executar as mesmas tarefas do Argo sem aceleração de dados — carregando o arquivo de teste de 10 GB diretamente do OSS — leva cerca de 14 a 15 minutos para calcular o 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

        Essa comparação mostra que o Fluid melhora a eficiência da computação e reduz significativamente os custos.