Sunsetting Docker Executor Support in Argo Workflows

What you need to know about sunsetting our Docker support.

A lovely sunset

One of the key configuration settings in Argo Workflows is which executor to use. This choice determines how secure, fast and feature rich your user experience is. You might use the Kubernetes API executor for security, or the PNS executor for performance.

One of the executors, the default executor, is the Docker executor. But you may have heard, Docker is going away. Kubernetes already deprecated it in v1.20 and removed it in v1.22, which has recently been released. Users of Argo Workflows with default settings will also need to get ready:

• Find out if you are impacted.
• Choose a new executor.
• Maybe upgrade to ≥ v3.1.
• Test the new executor.

Users who use the Docker socket /var/run/docker.sock , e.g. to build images, or run DIND, may be especially affected. You might consider buildkit (example workflow template).

Argo Workflows is used by hundreds of Kubernetes apps, so it’s hard to predict who might be affected. If you are affected, let us know is the comments below.

Just some of the apps in the Argo Workflow eco-system.

How Long Do I Have?

You may be affected when you upgrade to Kubernetes v1.22. This is unlikely to be tomorrow, but we’d recommend that you check ahead of time within the next couple of months.

Am I Impacted?

Check your configuration as follows:

kubectl get configmap workflow-controller-configmap -o yaml|grep containerRuntimeExecutor

If the result is empty, then you’ll be using the default. This is docker in ≤ v3.2.

• If you see pns or emissary , then happy days! Nothing needs to change.
• If you seedocker then you must migrate by changing this setting.
• If you see k8sapi or kubelet you’ll want to migrate too. These have limited functionality, poor performance at scale.

Make Some Changes

Select An Executor

What are your options? Today, there are two recommendations:

Use pns.

• This is battle-tested.
• It doesn’t work on Windows.
• It doesn’t work well with containers which run for less than 15s.
• It doesn’t support the new Container Set template.
• It won’t support the new debug pause feature.

Use emissary .

• This is designed to be faster than pns.
• It scales better because it does not make any Kubernetes API calls.
• It doesn’t work well with injected sidecars (e.g. ISTIO and Vault), yet. You may need to disable ISTIO sidecar injection.
• You many need to set the command on your workflow steps.
• Available in v3.1.

Learn more about executors.

Test Your Selection

If you’re running v3.1 you can test your choice by adding this configuration item to the workflow-controller-configmap:

containerRuntimeExecutors: |
    - name: emissary
      selector:
        matchLabels:
          workflows.argoproj.io/container-runtime-executor: emissary
    - name: pns
      selector:
        matchLabels:
          workflows.argoproj.io/container-runtime-executor: pns

Workflows that have the matched labels will use the specified executor, e.g:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: my-wf-
  labels:
    workflows.argoproj.io/container-runtime-executor: pns

Verify which executor was used in your logs or the wait container.

$ kubectl logs hello-world-z8qxt -c wait | grep executorType
time="2021-10-20T20:42:19.510Z" level=info msg="Starting Workflow Executor" executorType=emissary

Reconfigure The Default Executor

If you’re happy that migration will work, make your choice the default:

kubectl patch configmap workflow-controller-configmap --patch '{"data":{"containerRuntimeExecutor":"emissary"}}'

Your workflow controller should reload configuration automatically, but you can also restart it manually:

kubectl rollout restart deploy workflow-controller

Summary

Congratulations! You should now be running workflows that are faster, cheaper, more secure, and you’ll be getting exciting new features!

Don’t forget to show your love by staring Argo Workflows on Github! ⭐️ ❤️

Bonus

Instructions for updating Kubeflow Pipelines.