Argo Workflows can execute steps using different underlying engines, and switching to the Emissary Executor offers a more streamlined and resource-efficient way to run your workflow tasks.
Let’s see this in action. Imagine a simple workflow that just prints a message:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: emissary-hello-world-
spec:
entrypoint: main
templates:
- name: main
container:
image: alpine:latest
command: ["sh", "-c"]
args: ["echo 'Hello from Emissary!'"]
# This is the crucial part for Emissary
executor:
emissary: {}
When you submit this workflow, Argo Workflows doesn’t spin up a separate argoexec container for each step. Instead, the emissary container, which is already running as part of your Argo Workflows controller or a dedicated emissary pod, directly executes the containerized command. This means fewer pods, less overhead, and faster task startup.
The core problem Emissary solves is the resource bloat associated with the traditional argoexec sidecar pattern. In that model, every single step in a workflow that needed to run a container would provision a new argoexec pod alongside the actual task container. This quickly consumes valuable Kubernetes resources, especially for workflows with many short-lived steps or when running many workflows concurrently. Emissary consolidates this execution logic, allowing a single emissary instance to manage multiple task executions.
Internally, the Emissary Executor works by having the Argo Workflows controller communicate with the Emissary process. When a workflow step needs to run a container, the controller sends a request to the Emissary. The Emissary then uses its own Kubernetes client to create and manage the pod for that specific task. Once the task pod completes, the Emissary collects its logs and status, and reports it back to the controller. This abstraction hides the pod creation and management details from the individual workflow steps, making the entire process more efficient.
To enable the Emissary Executor, you primarily configure it in your Workflow or WorkflowTemplate CRD. The executor field is where you specify which executor to use. For Emissary, it’s as simple as executor: emissary: {}. There are no complex command-line arguments or environment variables to manage on the task containers themselves. The decision is made at the workflow definition level.
You can also configure Emissary at a cluster-wide level through the Argo Workflows controller’s configuration. This allows you to set Emissary as the default executor for all workflows, unless explicitly overridden by a workflow definition. This is typically done by modifying the workflow-controller-configmap in your Argo Workflows installation. Look for parameters related to executor.default and set it to emissary.
The emissary field itself can accept configuration parameters, though for basic usage, an empty object {} is sufficient. More advanced configurations might involve specifying timeouts for task execution or defining how Emissary should handle specific resource constraints, but these are less common for typical use cases. The primary benefit comes from the reduction in sidecar pods.
One of the subtle but powerful aspects of Emissary is how it handles artifact passing. When using the argoexec sidecar, artifacts are often staged through volumes mounted by both the argoexec and the task container. Emissary, by managing the task pod lifecycle more directly, can optimize this process. It can, for instance, orchestrate the creation of the task pod in a way that pre-stages artifacts before the main container entrypoint is even invoked, reducing the perceived latency of artifact retrieval for your workflow steps. This is often an implementation detail you don’t need to worry about, but it contributes to faster and more reliable artifact handling.
The next logical step after adopting Emissary is to explore how its efficiency translates to managing more complex workflow patterns like DAGs and Steps, and how it integrates with artifact repositories.