Argo Workflow fundamentals: CAPA practice questions

Argo Workflows is a workflow engine that runs on Kubernetes and is installed as custom resources plus two Deployments. The workflow controller does all of the reconciling: it watches Workflow objects and the Pods they create and moves each run forward. The Argo Server serves the API and the web UI, listening on port 2746, and the controller can run without it. Both normally live in the argo namespace, while the workflows themselves and their Pods can run in other namespaces.

A Workflow resource has two jobs at once. It defines the work to run, and it stores the state of that run in its status, so the documentation describes it as a live object rather than a static manifest. Every step or DAG task that runs a container becomes its own Pod. In the classic layout that Pod has an init container that fetches input artifacts and parameters, the main container that runs the user's image with the argoexec binary wrapped around the command, and a wait container that saves outputs, artifacts and logs when the main container ends. The process that runs inside those Pods is called the executor, and emissary is the only executor left.

Day-to-day work goes through the argo CLI. argo submit creates a Workflow from a file and, with --watch, follows it until it ends; argo list, argo get and argo logs show runs, a single run's tree and container output. A failed run can be retried in place with argo retry, which reruns only the failed parts, or copied into a new run with argo resubmit. argo stop and argo terminate both end a running workflow, but stop still runs exit handlers while terminate skips them.

The Argo Server authenticates requests in one of three modes. client mode, the default, uses the bearer token that the caller sends; server mode uses the server's own service account, or the local kubeconfig when run locally; sso mode signs users in through single sign-on. Several modes can be enabled at once with repeated --auth-mode flags. Knowing which component owns which job, controller for execution and server for the API and UI, settles most architecture questions about the project.