<h1>What I would like to do</h1>

<p>I would like to create a Kubernetes workflow where <strong>users could POST jobs whenever they wanted</strong>, and they might do it at any time, not necessarily scheduling anything (<code>CronJobs</code>), or specifying parallelism or completion requirements, i.e., users could create Jobs on demand.</p>

<h1>How I would do it right now</h1>

<p>The way I'm thinking about accomplishing this is by simply applying the <code>Jobs</code> to the Kubernetes cluster (I also have to make sure the job doesn't have the same name of a current one because otherwise Kubernetes will think it's a mistake and won't create another one). However, this feels improper because the <code>Jobs</code> will be kind of scattered on the cluster and I would lose control over them (though Kubernetes would supposedly automatically manage them optimally).</p>

<h1>Is there a better, proper a way?</h1>

<p>I imagine a more proper way of configuring all this is to <strong>create some sort of <code>Deployment</code> and <code>Service</code> on top of the <code>Jobs</code></strong>, but is that an existing feature on Kubernetes? Huge companies probably have had this problem in the past so I wonder: <strong>what are the best practices for this Kubernetes Jobs On Demand use case?</strong></p>

Philippe Fanaro
<p>Not a full answer but you might be interested in this project: <a href="https://github.com/ivoscc/kubernetes-task-runner" rel="nofollow noreferrer">https://github.com/ivoscc/kubernetes-task-runner</a>.</p>

<p>It provides an API to launch one-time tasks as Jobs on a Kubernetes cluster, handles input/output files via GCS and periodically cleans up finished Jobs.</p>
