Run An Argo Workflow

Integrate Kueue with Argo Workflows.

This page shows how to leverage Kueue’s scheduling and resource management capabilities when running Argo Workflows.

This guide is for batch users that have a basic understanding of Kueue. For more information, see Kueue’s overview.

Currently Kueue doesn’t support Argo Workflows Workflow resources directly, but you can take advantage of the ability for Kueue to manage plain pods to integrate them.

Before you begin

  1. Learn how to install Kueue with a custom manager configuration.

  2. Follow steps in Run Plain Pods to learn how to enable and configure the pod integration.

  3. Install Argo Workflows

Workflow definition

a. Targeting a single LocalQueue

If you want the entire workflow to target a single local queue, it should be specified in the spec.podMetadata section of the Workflow configuration.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  podMetadata:
    labels:
      kueue.x-k8s.io/queue-name: user-queue # All pods will target user-queue
  templates:
    - name: whalesay
      container:
        image: docker/whalesay
        command: [ cowsay ]
        args: [ "hello world" ]
        resources:
          limits:
            memory: 32Mi
            cpu: 100m

b. Targeting a different LocalQueue per template

If you prefer to target a different local queue for each step of your Workflow, you can define the queue in the spec.templates[].metadata section of the Workflow configuration.

In this example hello1 and hello2a will target user-queue and hello2b will target user-queue-2.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: steps-
spec:
  entrypoint: hello-hello-hello

  templates:
  - name: hello-hello-hello
    steps:
    - - name: hello1            # hello1 is run before the following steps
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello1"
    - - name: hello2a           # double dash => run after previous step
        template: whalesay
        arguments:
          parameters:
          - name: message
            value: "hello2a"
      - name: hello2b           # single dash => run in parallel with previous step
        template: whalesay-queue-2
        arguments:
          parameters:
          - name: message
            value: "hello2b"

  - name: whalesay
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: user-queue # Pods from this template will target user-queue
    inputs:
      parameters:
      - name: message
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["{{inputs.parameters.message}}"]

  - name: whalesay-queue-2
    metadata:
      labels:
        kueue.x-k8s.io/queue-name: user-queue-2 # Pods from this template will target user-queue-2
    inputs:
      parameters:
      - name: message
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["{{inputs.parameters.message}}"]

c. Limitations

  • Kueue will only manage pods created by Argo Workflows. It does not manage the Argo Workflows resources in any way.
  • Each pod in a Workflow will create a new Workload resource and must wait for admission by Kueue.
  • There is no way to ensure that a Workflow will complete before it is started. If one step of a multi-step Workflow does not have available quota, Argo Workflows will run all previous steps and then wait for quota to become available.
  • Kueue does not understand Argo Workflows suspend flag and will not manage it.
  • Kueue does not manage suspend, http, or resource template types since they do not create pods.

最后修改 July 2, 2025: Cherry-pick website commits from upstream/main (#5825) (cd1b0ecf)