Use the PNS Executor in Argo Workflows (2026)

The PNS Executor in Argo Workflows allows you to run containers within your workflow steps, but it does so by leveraging a sidecar container that acts as a proxy, forwarding requests to the actual container.

Let’s see this in action. Imagine you have a simple Argo Workflow definition like this:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: pns-executor-example-
spec:
  entrypoint: main
  templates:
    - name: main
      container:
        image: alpine:latest
        command: ["sh", "-c"]
        args: ["echo 'Hello from the main container!'; sleep 5; echo 'Done.'"]

When Argo executes this workflow, it doesn’t directly launch the alpine:latest container. Instead, it first spins up a PNS Executor sidecar container. This sidecar is responsible for setting up the environment, mounting volumes, and then launching your actual alpine:latest container. It then acts as an intermediary, handling communication between the Kubernetes API and your container.

The core problem the PNS Executor solves is abstracting away the complexities of container execution within the Kubernetes Pod. Instead of Argo directly interacting with the Kubernetes exec API or managing container lifecycle details, the PNS Executor handles it. This allows Argo to focus on workflow orchestration while the executor deals with the nitty-gritty of running individual steps.

Internally, the PNS Executor runs as a distinct container within the same Pod as your workflow step’s container. It listens for commands from the Argo controller, which tells it what container to run, what arguments to use, what environment variables to set, and how to handle I/O. When your workflow step needs to execute a command, the Argo controller doesn’t talk to your container directly; it talks to the PNS Executor. The executor then translates these commands into the necessary Kubernetes API calls to start, stop, and interact with your workflow step’s container.

Here’s how you can control its behavior:

• image: This is the most direct control. It specifies the container image for your workflow step. The PNS Executor will pull and run this image.
• command and args: These define the entrypoint and arguments for your container, just like in a standard Kubernetes Pod definition. The executor ensures these are passed correctly to your container.
• env: Environment variables can be set for your container. The executor injects these when launching the container.
• volumeMounts: If your workflow requires persistent storage or shared volumes, these are defined here and mounted by the executor into your container.

The real power of the PNS Executor comes into play when you consider more advanced scenarios like:

• Resource management: Kubernetes resource requests and limits are still applied to the Pod, and the executor ensures your container respects them.
• Security contexts: You can define securityContext for your containers, and the executor will apply these settings.

What most people don’t realize is that the PNS Executor doesn’t just run your container; it actively manages its lifecycle and I/O. When your workflow step produces stdout or stderr, it’s captured by the executor and then streamed back to the Argo controller. Similarly, if your step needs to read from stdin, the executor facilitates that communication. This means that even though you define your container in the workflow, there’s a crucial intermediary ensuring everything runs smoothly and predictably within the Kubernetes environment.

The next logical step after understanding how the PNS Executor manages individual containers is to explore how Argo Workflows handles parallel execution of these steps.