Argo Workflows

Argo Workflows is a Kubernetes-native workflow engine designed for orchestrating parallel jobs. It is particularly useful for tasks like batch processing, CI/CD pipelines, machine learning workflows, and any job automation that benefits from running steps as a DAG (Directed Acyclic Graph).

By leveraging Kubernetes as the underlying scheduler, Argo enables scalable and resilient workflow execution using familiar Kubernetes tooling.

Workflow objects must be created in the same namespace where the Argo controller is running. It also means that ClusterWorkflow resources are not supported. This is a limitation of the managed cluster setup at CERIT-SC. Currently, deploying a controller that watches multiple namespaces is not supported.

Access Requirements

Running Argo Workflows requires elevated privileges, as the necessary RBAC (Role-Based Access Control) permissions are not included in the default user setup.

To gain access, contact the administrators at k8s@cerit-sc.cz. Once approved, the appropriate RBAC rules will be configured for your Project namespace. This access model helps reduce excessive role bindings across the cluster.

Repository with Starter-kit Manifests

This setup is provided in the repository https://github.com/CERIT-SC/argo-workflows-example, which serves as a starter-kit demo for using Argo Workflows on the CERIT-SC managed Kubernetes cluster. It is intended to be extended and customized to fit your specific needs.

The repository is organized as follows:

.
├── controller-manifests/ # Argo Workflow controller configuration
│ ├── controller-install.yaml
│ └── workflow-controller-configmap.yaml
└── example/
  ├── runner-rbac.yaml # Service account and RBAC setup
  └── hello-world.yaml # Sample workflow definition

1. Install the Argo Workflow Controller

To deploy the Argo controller, apply the manifests in the controller-manifests directory:

kubectl apply -f controller-manifests/ -n [your-namespace]

The controller deployment consists of:

controller-install.yaml: Installs the Argo controller and required components.
workflow-controller-configmap.yaml: Defines controller behavior. You may need to adjust this to match your specific use case.

The controller-install.yaml file uses a hardcoded Argo Workflows version v3.6.7. This version may become outdated over time. Be sure to monitor the Argo Releases for updates and modify the manifest if necessary.

2. Set Up RBAC for Workflow Execution

Apply the RBAC policy that allows the workflows to run using a specific service account:

kubectl apply -f example/runner-rbac.yaml -n [your-namespace]

Ensure that your workflow YAML files reference the correct service account name (the same name as in the runner-rbac.yaml). You may also customize the roles and permissions based on your namespace’s access needs.

3. Run the Example Workflow

After deploying the controller and setting up RBAC, test the setup by deploying the example workflow:

kubectl create -f example/hello-world.yaml -n [your-namespace]

This minimal “Hello World” example should validate that your controller and RBAC setup are working correctly.

In namespaces where resource quotas are enforced (which is true for all user namespaces at CERIT-SC), the workflow may fail if the pod created by the workflow (the workflow runner) does not specify resource requests/limits. If your namespace does not have default container resources defined, you must either:

Configure namespace-level default resource requests/limits, or
Add explicit resources: section in your workflow definition (CPU, memory).

This issue is rare but can occur in new or custom namespaces.