A workflow executor is a process that conforms to a specific interface that allows Argo to perform certain actions like monitoring pod logs, collecting artifacts, managing container lifecycles, etc..
The executor to be used in your workflows can be changed in the configmap under the containerRuntimeExecutor
key.
v3.1 and after
default in >= v3.3
This is the most fully featured executor.
- Reliability:
- Works on GKE Autopilot
- Does not require
init
process to kill sub-processes.
- More secure:
- No
privileged
access - Cannot escape the privileges of the pod's service account
- Can
runAsNonRoot
.
- No
- Scalable:
- It reads and writes to and from the container's disk and typically does not use any network APIs unless resource type template is used.
- Artifacts:
- Output artifacts can be located on the base layer (e.g.
/tmp
).
- Output artifacts can be located on the base layer (e.g.
- Configuration:
command
must be specified for containers.
You can determine values as follows:
docker image inspect -f '{{.Config.Entrypoint}} {{.Config.Cmd}}' argoproj/argosay:v2
Learn more about command and args
If the emissary cannot determine which command to run, because you did not specify it in your workflow spec, then it will look it up in the image index. This is nothing more fancy than a configuration item.
The emissary will exit with code 64 if it fails. This may indicate a bug in the emissary.
default in <= v3.2
- Least secure:
- It requires
privileged
access todocker.sock
of the host to be mounted which. Often rejected by Open Policy Agent (OPA) or your Pod Security Policy (PSP). - It can escape the privileges of the pod's service account
- It cannot
runAsNonRoot
.
- It requires
- Equal most scalable:
- It communicates directly with the local Docker daemon.
- Artifacts:
- Output artifacts can be located on the base layer (e.g.
/tmp
).
- Output artifacts can be located on the base layer (e.g.
- Configuration:
- No additional configuration needed.
Note: when using docker as workflow executors, messages printed in both stdout
and stderr
are captured in the Argo variable .outputs.result
.
- Secure
- No
privileged
access - Cannot escape the privileges of the pod's service account
runAsNonRoot
- TBD, see #4186
- No
- Scalable:
- Operations performed against the local Kubelet
- Artifacts:
- Output artifacts must be saved on volumes (e.g. emptyDir) and not the base image layer (e.g.
/tmp
)
- Output artifacts must be saved on volumes (e.g. emptyDir) and not the base image layer (e.g.
- Step/Task result:
- Warnings that normally goes to stderr will get captured in a step or a dag task's
outputs.result
. May require changes if your pipeline is conditioned onsteps/tasks.name.outputs.result
- Warnings that normally goes to stderr will get captured in a step or a dag task's
- Configuration:
- Additional Kubelet configuration maybe needed
- Reliability:
- Works on GKE Autopilot
- Most secure:
- No
privileged
access - Cannot escape the privileges of the pod's service account
- Can
runAsNonRoot
- No
- Least scalable:
- Log retrieval and container operations performed against the remote Kubernetes API
- Artifacts:
- Output artifacts must be saved on volumes (e.g. emptyDir) and not the base image layer (e.g.
/tmp
)
- Output artifacts must be saved on volumes (e.g. emptyDir) and not the base image layer (e.g.
- Step/Task result:
- Warnings that normally goes to stderr will get captured in a step or a dag task's
outputs.result
. May require changes if your pipeline is conditioned onsteps/tasks.name.outputs.result
- Warnings that normally goes to stderr will get captured in a step or a dag task's
- Configuration:
- No additional configuration needed.
- More secure:
- No
privileged
access - cannot escape the privileges of the pod's service account
- Can
runAsNonRoot
, if you use volumes (e.g. emptyDir) for your output artifacts - Processes are visible to other containers in the pod. This includes all information visible in /proc, such as passwords that were passed as arguments or environment variables. These are protected only by regular Unix permissions.
- No
- Scalable:
- Most operations use local
procfs
. - Log retrieval uses the remote Kubernetes API
- Most operations use local
- Artifacts:
- Output artifacts can be located on the base layer (e.g.
/tmp
) - Cannot capture artifacts from a base layer which has a volume mounted under it
- Cannot capture artifacts from base layer if the container is short-lived.
- Output artifacts can be located on the base layer (e.g.
- Configuration:
- No additional configuration needed.
- Process will no longer run with PID 1
- Doesn't work for Windows containers.
https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/