Kubeflow for Machine Learning

Appendix A. Argo Executor Configurations and Trade-Offs

Until recently, all Kubernetes implementations supported Docker APIs. The initial Argo implementation depended on them. With the introduction of OpenShift 4, which doesn’t support the Docker APIs, the situation changed. To support the absence of Docker APIs, Argo introduced several new executors: Docker, Kubelet, and Kubernetes APIs. The containerRuntimeExecutor config value in the Argo parameters file controls which executor is used. The pros and cons of each executor (based on the information here) are summarized in Table A-1. This table should help you pick the correct value of the Argo executor.

Table A-1. Argo and Kubernetes APIs

Executor	Docker	Kubelet	Kubernetes API	PNC
Pros	Supports all workflow examples. Most reliable, well tested, very scalable. Communicates with Docker daemon for heavy lifting.	Secure. Can’t escape pod’s service account privileges. Medium scalability. Log retrieval and container polling are done against Kubelet.	Secure. Can’t escape privileges of pod’s service account. No extra configuration.	Secure. Can’t escape service account privileges. Artifact collection can be done from base image layer. Scalable: process polling is done over procfs, not kubelet/k8s API.
Cons	Least secure. Requires docker.sock of host to be mounted (often rejected by OPA).	Additional kubelet configuration may be required. Can only save params/artifacts in volumes (e.g., emptyDir), and not the base image layer (e.g., ...