Skip to main content
In this lesson we examine the Argo Workflow specification and how to author reusable automation pipelines as Kubernetes custom resources. Argo Workflows is implemented as a Kubernetes Custom Resource Definition (CRD), which lets you define complex CI/CD and automation pipelines using familiar YAML files. A workflow is a structured sequence of automated tasks that together accomplish a goal — commonly used in DevOps for application deployment, testing, and promotion. Key components of an Argo Workflow manifest:
  • Header: Kubernetes metadata (apiVersion, kind, metadata).
  • spec: Describes workflow behavior and templates that perform work.
The following sections explain the structure, common template types, and how to submit a workflow.

​
Workflow file structure

A typical workflow YAML contains the following top-level parts:
  • Header: apiVersion, kind, and metadata.
  • Metadata: you can specify name or generateName. Use generateName to avoid collisions when submitting the same manifest multiple times — Argo appends a unique suffix.
  • spec: the core of the workflow. Important fields:
    • entrypoint: the name of the template that starts execution.
    • templates: a list of reusable templates. Templates describe tasks and can reference each other.
Use generateName when you want to submit the same workflow multiple times without name collisions. Each submission will get a unique suffix appended to the provided generateName.

​
Template types (overview)

Templates are the building blocks of workflows. Argo supports several template types for different use cases: Templates can be composed — steps or dag templates reference container/script/resource templates to perform tasks.

​
Container templates

Container templates accept the same fields as a Kubernetes Pod container spec. This means you can use:
  • image
  • command and args
  • env and envFrom
  • volumeMounts and volumes
  • resources
Because the container template mirrors Kubernetes, you can use existing YAML knowledge when defining tasks. Example container-template workflow:

​
Submitting a workflow

You can submit workflows with either the Argo UI or the CLI. CLI example (submits to the argo namespace):
The Argo UI is available if your Argo server is exposed; it provides a visual representation of templates, DAGs, and steps.
The entrypoint must match one of the template names defined under templates. If it does not, the workflow will fail to start.

​
Practical tips and best practices

  • Use generateName for recurring or CI-driven workflow submissions to avoid manual name management.
  • Keep templates small and reusable — compose complex workflows from simple building blocks (container/script/steps/dag).
  • Use resources and resourceLimits to avoid noisy scheduling and to communicate expected resource usage.
  • Version control your workflow manifests alongside application code or infrastructure repositories for traceability.

​
Quick reference: spec fields

Notes:
  • The container section within a template maps directly to a Kubernetes container spec and supports env, volumeMounts, and resources.
  • Always ensure the entrypoint value matches a defined template name under templates.

Watch Video