Choosing Between Argo and Tekton Executors in Kubeflow Pipelines

Decision and constraints

When deploying Kubeflow Pipelines you must select a pipeline executor that will run your workflows. The choice affects UI integration, caching capabilities, operational overhead, and compatibility with existing CI/CD tooling. Typical constraints include:

• Kubeflow version (tested with 1.6, but the concepts apply to 1.5‑1.7).
• Target Kubernetes cluster version (1.22‑1.27).
• Whether you already invest in Tekton for other workloads.
• Acceptable resource overhead for the executor control plane.
• Need for advanced UI visualisations (e.g., workflow graphs, artifact lineage).

Comparison of supported options

Feature	Argo executor (default)	Tekton executor
Installation	No extra components; included in the standard Kubeflow Pipelines deployment.	Requires the Tekton add‑on (tekton-pipelines) to be installed in the cluster.
UI integration	Full support for the Kubeflow Pipelines UI, including workflow visualisation, artifact viewing, and run details.	Basic run status is shown, but some UI‑specific visualisations (e.g., detailed DAG) may be missing or fallback to a generic view.
DSL feature coverage	Supports all Kubeflow Pipelines SDK v1 and v2 features, including conditionals, loops, and recursive pipelines.	Most DSL features work; complex v2 conditionals may need workarounds or are partially unsupported.
Task‑level caching	Provides pipeline‑level caching via the Kubeflow Pipelines cache.	Offers native Tekton task‑level caching, which can be finer‑grained and reused across pipelines.
Resource overhead	Adds ~5 % CPU overhead from the Argo workflow controller and sidecar containers.	Adds ~10 % CPU overhead due to extra Tekton controller pods and webhook services.
Maintenance cadence	Maintained by the Kubeflow core team; releases track Kubeflow version bumps closely.	Community‑driven; typically lags Kubeflow releases by 1‑2 months.
Known limits	Workflow pod names may hit length limits on clusters with strict naming policies.	Does not yet support the full Kubeflow Pipelines SDK v2 conditional syntax; complex conditionals may require rewriting.

Trade‑off explanation

If you prioritize a seamless UI experience and want to avoid installing additional operators, the Argo executor is the safer default. It inherits all Kubeflow Pipelines features and receives timely updates from the Kubeflow team.

If your organization already runs Tekton for CI/CD and you want to reuse existing Tekton pipelines, triggers, or benefit from task‑level caching, the Tekton executor can provide those advantages. The trade‑off is a slightly higher resource footprint and potential gaps in UI‑specific visualisations or DSL support that may require pipeline adjustments.

Both executors run on the same Kubernetes version range, so cluster compatibility is not a deciding factor. The decision therefore hinges on operational overhead, existing Tekton investment, and the importance of advanced UI features.

Concrete implementation: enabling the Tekton executor

The following steps show how to switch from the default Argo executor to Tekton on a kind cluster running Kubeflow 1.6. Adjust namespace names and cluster context as needed for your environment.

1. Prerequisites:
   kubectl version ≥1.22, kind installed, and a running kind cluster with Kubeflow 1.6 deployed via the official manifests. You need cluster‑admin permissions to modify the kubeflow-pipelines ConfigMap.
2. Install Tekton add‑on (if not already present):
   

   # Apply Tekton pipelines (version 0.48.0 as an example)
   kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
   

3. Patch the Kubeflow Pipelines ConfigMap to select Tekton:
   

   kubectl -n kubeflow patch configmap kubeflow-pipelines-config \
     --type merge \
     --payload '{"data":{"pipeline-executor":"tekton"}}'
   

4. Validate the change**:
   kubectl -n kubeflow get configmap kubeflow-pipelines-config -o yaml | grep pipeline-executor should return pipeline-executor: tekton.
5. Deploy a simple test pipeline**:
   

   # pipeline.yaml (DSL v2)
   name: hello-world
   components:
   - name: echo
     implementation:
       container:
         image: alpine:latest
         command: ["sh", "-c"]
         args: ["echo 'hello world' > /tmp/message && cat /tmp/message"]
         fileOutputs:
           message: /tmp/message
   

   Compile and create the run:
   

   dsl-compile --py pipeline.py --output pipeline.yaml
   kubectl create -f pipeline.yaml
   

6. Observe Tekton objects**:
   

   # Wait for the run to start, then list Tekton resources
   kubectl -n kubeflow get taskrun
   kubectl -n kubeflow get podrun
   

   You should see a TaskRun whose pod executes the echo container and logs "hello world".
7. Check pod start‑up time (optional)**:
   Record the timestamps of the pod creation and the container ready state using kubectl get pod -w. Compare with a similar run using the Argo executor (default) to see the expected overhead difference.

Limitations and practical verification

• The Tekton executor may not display the full Kubeflow Pipelines DAG in the UI; you can verify this by opening the run details page and checking whether the graphical workflow view appears.
• Complex conditionals from SDK v2 might fail; you can test by authoring a pipeline with nested if statements and observing whether the run proceeds as expected.
• Resource overhead can be measured by monitoring CPU usage of the tekton-pipelines-controller and argo-workflow-controller pods via kubectl top pod over a few minutes of idle time.
• If you need to revert to Argo, simply set pipeline-executor: argo in the same ConfigMap and restart the kubeflow-pipelines-controller deployment (or roll back the ConfigMap change).